量化感知训练(QAT)与量化微调:伪量化、STE 与 QLoRA 实战
训练后量化(PTQ)在精度敏感场景常常失手,量化感知训练(QAT)则让模型在训练阶段就『学会』适应量化噪声,是工业界把 INT8 精度损失压到 1% 以内的关键手段。本文从伪量化算子与直通估计器(STE)讲起,给出 QAT 完整流程,讲解蒸馏+量化组合,并深入 LoRA 量化微调(QLoRA)与工业实践。一、QAT 背景与动机
posts
训练后量化(PTQ)在精度敏感场景常常失手,量化感知训练(QAT)则让模型在训练阶段就『学会』适应量化噪声,是工业界把 INT8 精度损失压到 1% 以内的关键手段。本文从伪量化算子与直通估计器(STE)讲起,给出 QAT 完整流程,讲解蒸馏+量化组合,并深入 LoRA 量化微调(QLoRA)与工业实践。一、QAT 背景与动机
当推理发生在手机、摄像头、车载设备上,约束从『算得快』变成『在有限功耗和内存内算得好』。本文聚焦边缘端推理:对比 TFLite / ONNX Runtime Mobile / ExecuTorch / OpenVINO 等移动框架,讲解 Qualcomm 与 Apple NPU 的异构调度,给出端侧量化与模型压缩的组合拳,并拆解目标检测、端侧 LLM、语音助手三类典型应用。一、边缘推理的约束
『我的推理服务到底能扛多大流量?』『加一张卡值不值?』『P99 为什么这么差?』这些问题都需要一套科学的基准测试方法。本文讲解 LLM 推理的核心性能指标 TTFT / ITL / TPOT,分析延迟与吞吐曲线,演示 LLM Perf 与 Locust 两类压测工具,最后给出容量规划与成本建模的完整方法。一、推理性能指标体系
在 GPU 推理中,最贵的往往不是计算,而是数据搬运:每一个算子都要把中间结果写回显存、再读出来,内存带宽成为瓶颈。算子融合就是把多个算子合并成一个 kernel,减少显存往返,是 TensorRT、vLLM、PyTorch 编译器都在做的事。本文从融合原理讲起,拆解 FlashAttention 类融合,再到 CUDA Graph 与自定义 kernel 开发流程。一、为什么需要算子融合
当单卡放不下一个 70B 模型,或单卡无法满足线上吞吐时,分布式推理就从『可选优化』变成『必选项』。本文系统讲解张量并行、流水线并行与专家并行三大策略的通信代价与适用场景,介绍连续批处理在集群中的落地,并深入 KServe 与 Ray Serve 两类 GPU 调度器的架构与配置。一、为什么需要分布式推理
大语言模型的文本能力已经被充分挖掘,而让模型『看懂图』的多模态推理,正在成为企业级应用的新战场:文档解析、商品识别、自动驾驶、智能客服。本文从图像如何变成 Token 讲起,深入视觉语言模型(VLM)的联合推理机制、多模态 KV Cache 显存管理,再到生产级多模态推理服务部署。一、从单模态到多模态:VLM 推理的挑战
在深度学习落地过程中,模型体积与推理延迟往往是最大的拦路虎。一个经过充分训练的 ResNet-50 FP32 模型约有 98 MB,而大型语言模型的参数规模更是以 GB 甚至 TB 计。
引言:为什么需要模型压缩 深度学习模型的参数量正在以指数级增长。从 AlexNet 的 6000 万参数,到 GPT-4 的万亿级参数,模型能力的提升往往伴随着体积的膨胀。然而,在生产环境中部署这些庞大模型时,我们面临着严峻的现实约束: 边缘设备的硬件限制。
模型训练完成后,真正的挑战才刚刚开始:如何让模型在生产环境中跑得又快又稳?选择一个合适的推理引擎,往往比换一块更贵的显卡带来的收益更大。本文将深入对比业界三大主流推理引擎 —— TensorRT、ONNX Runtime 和 OpenVINO,从延迟、吞吐、硬件兼容性到量化策略逐一拆解,并给出可直接
大语言模型(LLM)推理服务的扩展性瓶颈,往往不在计算吞吐量,而在 GPU 显存。传统推理框架将 KV Cache 以连续张量形式预分配,造成大量内存浪费,导致 batch size 被严重限制。
大语言模型(LLM)的推理部署是 AI 基础设施的核心挑战之一。随着模型参数量从数十亿增长到数千亿,如何在保证低延迟和高吞吐的前提下高效运行这些模型,成为生产环境的必答题。NVIDIA 推出的 TensorRT-LLM 正是为了解决这一痛点而诞生的专用推理框架。
1. TensorRT 简介 TensorRT 是 NVIDIA 推出的高性能深度学习推理 SDK,核心目标是将训练好的模型转化为能够在 NVIDIA GPU 上高效执行的推理引擎。与基于 PyTorch、TensorFlow 的原生推理相比,TensorRT 通过层融合(Layer Fusion)
引言 随着深度学习模型越来越多地部署到边缘设备与多样化硬件之上,模型格式与推理引擎的统一化已成为工程落地的关键瓶颈。PyTorch 和 TensorFlow 各自拥有庞大的生态系统,但训练后时将模型转换为一个与框架无关的中间表示,才能真正实现「一次导出、到处运行」
在 AI 模型落地的最后一公里,推理服务的稳定性、吞吐量和延迟直接决定了用户体验。NVIDIA Triton Inference Server(以下简称 Triton)作为企业级推理框架的代表,已经成为大型生产系统的标配组件。
随着大型语言模型(LLM)从实验室走向生产环境,构建一个高吞吐、低延迟、可弹性伸缩的推理服务架构,已成为 AI 工程团队的核心命题。与传统的请求-响应式服务不同,LLM 推理具有内存占用高、计算密集、延迟不可预测等特点,这要求我们在架构设计时必须引入一套全新的技术范式。
大型语言模型(LLM)的推理性能已经成为生产环境部署中的核心挑战。在 Transformer 架构中,自注意力机制(Self-Attention)虽然在建模长距离依赖方面表现出色,但其计算和内存开销随序列长度呈平方增长。
使用 70 GB 显存才能跑一次的 Llama-2-70B,量化后可以塞进 24 GB 的消费级显卡。这不是魔法,而是大语言模型(LLM)权重量化带来的实际收益。本文将深入讲解 GPTQ、AWQ、SmoothQuant、W4A16 等主流量化方案的原理与实战,帮助你在生产环境中实现 4 倍模型压缩而
在大模型推理与训练日益普及的今天,GPU 已不再是游戏玩家的专属硬件,而是 AI 基础设施的核心。理解 CUDA 编程,是每一位希望深入 AI 系统优化的工程师必经之路。本文从零开始,带你掌握 GPU 并行计算的核心概念与实战代码。一、为什么要用 GPU 计算?
在现代 GPU 计算中,内存访问模式往往是决定内核性能的首要因素。算法复杂度相同的两个 CUDA Kernel,仅仅因为访问显存的方式不同,执行时间可能相差数倍甚至一个数量级。本文将系统梳理 CUDA 编程中各类内存的访问特性,深入讲解合并访问(Coalesced Access)与 Bank Con
在 CUDA C++ 应用开发中,开发者很少从零编写核函数。NVIDIA 官方提供了一套经过深度优化的加速库,覆盖线性代数、深度学习、信号处理、并行算法等核心场景。这套库不仅性能卓越,而且经过大量生产环境验证。