【PyTorch】 源码详解三Agent 开发实战——推理加速、量化部署与 vLLM从能跑到能服务写在前面前两篇我们拆完了 PyTorch 的四层架构c10→ATen→Autograd→torch.nn、张量引擎Storage/Strides/Offset、Autograd 计算图和 nn.Module 参数管理。今天我们进入系列的终章——Agent 开发实战。训练好的模型怎么加速推理怎么量化压缩怎么部署服务vLLM 的 PagedAttention 为什么能让 KV Cache 显存利用率从 20% 提升到接近 100%Continuous Batching 为什么能让吞吐提升 2-4x这些问题的答案决定了你的 Agent 是能跑还是能服务。 文章目录⚡ 一、推理加速四板斧从 Eager Mode 到极致优化 二、模型量化INT4/INT8 的选择与实战 三、vLLM 与生产部署从 PagedAttention 到 Agent 服务化 四、系列终章回顾⚡ 一、推理加速四板斧从 Eager Mode 到极致优化1.1 第一板斧torch.no_grad()——禁用 Autograd第一篇我们讲了 Autograd 的计算图机制——前向传播时每个 Function 节点都会保存saved_tensors用于反向传播。推理时不需要梯度但默认情况下 PyTorch 仍然会构建计算图和保存中间张量——这是纯粹的浪费。torch.no_grad()的作用禁用 Autograd Dispatcher 的拦截——所有操作不再创建 Function 节点、不再保存saved_tensors、不再设置grad_fn。效果显存占用降低 30-50%不再保存中间激活推理速度提升 10-30%不再构建计算图。这是推理加速的最低配置——任何推理代码都必须加torch.no_grad()。不加就是浪费。1.2 第二板斧半精度推理FP16/BF16——Tensor Core 加速现代 GPUNVIDIA V100 及以后内置 Tensor Core——专门执行矩阵乘法的硬件单元对 FP16/BF16 数据类型的吞吐量是 FP32 的 2-8 倍。FP16Float16。16 位浮点数范围 ±65504精度约 3 位十进制。优点是 Tensor Core 加速明显缺点是范围小容易溢出和精度低。需要配合 Loss Scaling 使用。BF16BFloat16。16 位浮点数范围与 FP32 相同8 位指数精度约 2 位十进制。优点是不溢出、不需要 Loss Scaling缺点是精度更低。A100/H100 原生支持 BF16 Tensor Core。混合精度推理。权重用 FP16/BF16 存储关键操作如 LayerNorm、Softmax用 FP32 计算。这是 LLM 推理的标准做法——model.half()或model.bfloat16()一行搞定。效果显存占用降低 50%权重从 FP32 变 FP16推理速度提升 1.5-3xTensor Core 加速。1.3 第三板斧torch.compile——算子融合PyTorch 2.0 引入的torch.compile()是推理加速的游戏规则改变者——它将 Eager Mode 的逐算子执行编译为融合的 Triton Kernel。Eager Mode 的问题。每个算子都是一次 Python→C 调用中间结果需要写回显存再读出。例如y gelu(x w b)在 Eager Mode 下需要 4 次显存读写xw 写出中间结果、b 读入写出、gelu 读入写出。torch.compile 的优化。将多个算子融合为一个 Triton Kernel——中间结果留在 GPU 寄存器/共享内存中不写回显存。y gelu(x w b)编译后只需 1 次显存读写。效果推理速度提升 1.5-3x减少 Python 开销 算子融合显存占用降低 20-40%减少中间张量。1.4 第四板斧导出部署——极致优化torch.compile仍然依赖 PyTorch 运行时。要获得极致性能需要将模型导出为独立格式ONNX Runtime。torch.onnx.export()导出 ONNX 格式ONNX Runtime 执行。跨平台CPU/GPU/Edge算子级优化。适合嵌入式和边缘部署。TensorRT。ONNX→TensorRT 编译。极致算子融合、Kernel Auto-Tuning、INT8/FP8 量化。NVIDIA GPU 上最快的推理方案。编译时间长分钟级但推理延迟最低。torch.export。PyTorch 2.x 的新导出 API导出torch.export.ExportedProgram保留 PyTorch 的动态特性。适合 TorchServe 和进一步编译优化。效果推理速度提升 3-5x极致优化 INT8 量化但需要额外的编译/导出步骤。1.5 四板斧是叠加关系四板斧不是互斥关系而是叠加关系——每一层都在上一层的基础上加速torch.no_grad()→ 禁用 Autograd → 基础加速FP16/BF16 → Tensor Core → 显存减半 计算加速torch.compile()→ 算子融合 → 减少 Python 开销导出部署 → 极致优化 → 跨平台推理Agent 开发者至少要做到前两层——no_grad FP16是推理的最低配置。 二、模型量化INT4/INT8 的选择与实战2.1 为什么需要量化一个 7B 参数的 LLMFP16 权重需要 14GB 显存。加上 KV Cache 和运行时开销单卡推理至少需要 24GBA10/A100-40G 勉强80G 舒适。但大多数 Agent 场景不需要 FP16 的全部精度——INT4 量化后7B 模型只需 3.5GB 显存单卡可以跑多个实例。量化的核心权衡精度损失 vs 资源节省。INT4 量化通常只损失 1-3% 的任务精度但显存降低 75%。对于 Agent 推理INT4 几乎总是正确的选择——省下的显存可以给 KV Cache。2.2 四种量化方案对比GPTQGPT Quantization。训练后量化PTQ需要校准数据集128-256 条样本。INT4 量化分组大小 128。量化过程逐层量化用 Hessian 矩阵近似最小化重建误差。优点是量化质量高1-2% 精度损失vLLM/TensorRT-LLM 原生支持。缺点是量化过程慢7B 模型约 30 分钟需要 GPU。AWQActivation-aware Weight Quantization。训练后量化考虑激活值分布。核心洞察不是所有权重同等重要——激活值大的通道对应的权重更重要应该保留更高精度。AWQ 对重要通道做缩放后再量化保留关键信息。优点是量化速度快比 GPTQ 快 2-3x质量接近 GPTQ。缺点是校准数据集要求与 GPTQ 类似。bitsandbytesNF4/FP4。即时量化无需校准数据集。NF4NormalFloat4是 QLoRA 论文提出的 4 位格式针对正态分布权重优化。加载模型时一行代码量化load_in_4bitTrue。优点是零额外步骤适合快速实验和 QLoRA 微调。缺点是推理速度不如 GPTQ/AWQ缺少专用 Kernel 优化vLLM 不原生支持。GGUFllama.cpp 格式。CPU/Apple Silicon 友好的量化格式。多种量化等级Q4_0/Q5_1/Q8_0在精度和大小之间灵活选择。Ollama 的底层格式。优点是 CPU 推理最快Mac M 系列芯片优化。缺点是 GPU 推理不如 GPTQ/AWQ。2.3 量化选择决策树量化选择取决于部署场景GPU 服务器 vLLMGPTQ/AWQ INT4 → vLLM 原生支持吞吐最高消费级 GPU 单卡bitsandbytes NF4 → 快速实验无需校准CPU/Mac 本地推理GGUF Q4_0 → llama.cpp/OllamaCPU 最优训练微调 QLoRAbitsandbytes NF4 → 4 位基座 16 位 LoRA2.4 量化的 Agent 实战Agent 场景下量化不只是压缩模型——它直接影响你能服务多少并发请求。一个 7B 模型 FP16 占 14GBINT4 占 3.5GB——省下的 10.5GB 可以给 KV Cache支持更长的上下文和更多的并发请求。# GPTQ 量化 vLLM 部署Agent 首选fromvllmimportLLM,SamplingParams llmLLM(modelTheBloke/Llama-2-7B-Chat-GPTQ,quantizationgptq,dtypefloat16,gpu_memory_utilization0.9,) 三、vLLM 与生产部署从 PagedAttention 到 Agent 服务化3.1 传统推理服务的瓶颈传统 LLM 推理服务如 HuggingFace TGI 早期版本面临三大瓶颈KV Cache 碎片化。为每个请求预分配最大长度的连续显存如 2048 Token。但大多数请求远短于最大长度——平均 200 Token 的请求也占用 2048 Token 的空间。内部碎片率高达 60-80%。静态批处理。等整批请求全部完成才能处理下一批。一个长请求2000 Token会拖慢整批短请求。GPU 利用率低。无前缀共享。多个请求共享相同 System Prompt 时每个请求都独立存储一份 KV Cache——重复浪费显存。3.2 PagedAttentionKV Cache 的虚拟内存vLLM 的核心创新是PagedAttention——将操作系统的虚拟内存分页思想应用到 KV Cache 管理。传统方式为每个请求预分配连续的 KV Cache 内存块。最大长度固定内部碎片严重。PagedAttention将 KV Cache 分割为固定大小的 Block默认 16 Token维护逻辑 Block→物理 Block 的映射表。逻辑 Block 不需要连续物理 Block 按需分配。PagedAttention 的三大优势消除内部碎片。最后一个 Block 可能不满但浪费最多 15 个 Token 的空间vs 传统方式浪费数百个 Token。显存利用率从 20-40% 提升到接近 100%。支持前缀共享。多个请求共享相同前缀System Prompt RAG 文档时只需存储一份物理 Block逻辑 Block 通过 Copy-on-Write 共享。这就是 vLLM 的 Automatic Prefix Caching。按需分配。请求生成多少 Token 就分配多少 Block不需要预分配最大长度。短请求不会浪费长请求的空间。3.3 Continuous Batching请求级调度传统批处理是静态的——等整批完成才能处理下一批。Continuous Batching 是动态的——每个 Decode 步骤结束后完成的请求立即移出新请求立即加入。效果GPU 利用率从 30-50% 提升到接近 100%吞吐提升 2-4x。长请求不再拖慢短请求。3.4 Speculative Decoding用小模型猜、大模型验Speculative Decoding 的思路用一个小的 Draft Model 快速生成 K 个候选 Token然后用大的 Target Model 一次前向验证所有候选。如果全部接受相当于一次前向生成了 K 个 Token——延迟降低 2-3x精度无损。3.5 四种部署方案对比vLLMPagedAttention Continuous Batching Prefix Caching。OpenAI 兼容 API。GPTQ/AWQ 原生支持。Agent 首选——吞吐最高、延迟最低、功能最全。TensorRT-LLMNVIDIA 极致优化。Kernel Auto-Tuning。INT8/FP8 量化。延迟最低但编译时间长分钟级灵活性不如 vLLM。TorchServePyTorch 官方。多模型管理。A/B 测试。模型版本控制。适合传统 ML 模型和非 LLM 场景。ONNX Runtime跨平台。CPU/GPU/Edge。模型导出后独立运行。适合嵌入式和边缘部署。3.6 Agent 生产部署最佳实践Agent 的推理链路通常是用户输入→Tokenizer→Embedding→Transformer Prefill→Transformer Decode→采样→输出。其中 Transformer Decode 是瓶颈——逐 Token 生成KV Cache 不断增长。生产部署的完整链路量化GPTQ/AWQ INT4 → 显存降 75%推理引擎vLLM → PagedAttention Continuous Batching缓存优化Prefix Caching → 命中率 80-98%延迟优化Speculative Decoding → 延迟降 2-3x监控KV Cache 命中率 延迟 P99 吞吐 QPS 四、系列终章回顾三篇文章的脉络理解发动机→理解传动→理解驾驶。第一篇四层架构与张量引擎。c10 提供基础数据结构ATen 提供算子与后端解耦Autograd 提供自动微分torch.nn 提供神经网络抽象。Tensor 的三件套Storage/Strides/Offset实现零拷贝。Dispatcher 根据 Dispatch Key 路由到不同 Kernel。第二篇Autograd 计算图与 nn.Module。前向传播即时构建计算图Function 节点 next_functions 边 saved_tensors 缓存反向传播沿图反向遍历执行 VJP。saved_tensors 是显存爆炸的元凶。nn.Module 是 Agent 与 PyTorch 的接口层——参数注册、钩子系统、序列化、设备迁移。第三篇Agent 开发实战。推理加速四板斧no_grad→FP16→torch.compile→导出部署模型量化四种方案GPTQ/AWQ/bitsandbytes/GGUFvLLM 三大核心PagedAttention/Continuous Batching/Speculative Decoding四种部署方案vLLM/TensorRT-LLM/TorchServe/ONNX Runtime。PyTorch 是 Agent 的发动机——它定义了模型怎么算。vLLM 是变速箱——它定义了模型怎么服务。理解发动机、理解传动、理解驾驶——这就是从能跑到能服务的完整路径。 总结速查卡PyTorch Agent 开发核心概念概念一句话解释no_grad禁用 Autograd——推理的最低配置FP16/BF16半精度——Tensor Core 加速 显存减半torch.compile算子融合——减少 Python 开销1.5-3x 加速GPTQ训练后 INT4 量化——vLLM 原生支持Agent 首选AWQ激活感知 INT4 量化——比 GPTQ 快 2-3xPagedAttentionKV Cache 分页管理——显存利用率接近 100%Continuous Batching请求级调度——吞吐提升 2-4xSpeculative Decoding小模型猜大模型验——延迟降 2-3x一句话总结PyTorch Agent 开发的完整链路推理加速四板斧no_grad→FP16→torch.compile→导出部署是叠加关系至少做到前两层。模型量化选择取决于场景——GPU 服务器用 GPTQ/AWQ INT4 vLLM消费级 GPU 用 bitsandbytes NF4CPU/Mac 用 GGUF。vLLM 的 PagedAttention 将 KV Cache 分页管理显存利用率从 20% 提升到接近 100%Continuous Batching 实现请求级调度吞吐提升 2-4xSpeculative Decoding 用小模型猜大模型验延迟降 2-3x。四种部署方案各有侧重——vLLM 是 Agent 首选TensorRT-LLM 是极致性能TorchServe 是官方方案ONNX Runtime 是跨平台。PyTorch 是 Agent 的发动机vLLM 是变速箱——理解发动机、理解传动、理解驾驶这就是从能跑到能服务的完整路径。参考链接vLLM 官方文档PagedAttention 论文torch.compile 文档GPTQ 论文AWQ 论文TensorRT-LLMTorchServe
【PyTorch】 源码详解（三）：Agent 开发实战——推理加速、量化部署与 vLLM，从“能跑“到“能服务“
【PyTorch】 源码详解三Agent 开发实战——推理加速、量化部署与 vLLM从能跑到能服务写在前面前两篇我们拆完了 PyTorch 的四层架构c10→ATen→Autograd→torch.nn、张量引擎Storage/Strides/Offset、Autograd 计算图和 nn.Module 参数管理。今天我们进入系列的终章——Agent 开发实战。训练好的模型怎么加速推理怎么量化压缩怎么部署服务vLLM 的 PagedAttention 为什么能让 KV Cache 显存利用率从 20% 提升到接近 100%Continuous Batching 为什么能让吞吐提升 2-4x这些问题的答案决定了你的 Agent 是能跑还是能服务。 文章目录⚡ 一、推理加速四板斧从 Eager Mode 到极致优化 二、模型量化INT4/INT8 的选择与实战 三、vLLM 与生产部署从 PagedAttention 到 Agent 服务化 四、系列终章回顾⚡ 一、推理加速四板斧从 Eager Mode 到极致优化1.1 第一板斧torch.no_grad()——禁用 Autograd第一篇我们讲了 Autograd 的计算图机制——前向传播时每个 Function 节点都会保存saved_tensors用于反向传播。推理时不需要梯度但默认情况下 PyTorch 仍然会构建计算图和保存中间张量——这是纯粹的浪费。torch.no_grad()的作用禁用 Autograd Dispatcher 的拦截——所有操作不再创建 Function 节点、不再保存saved_tensors、不再设置grad_fn。效果显存占用降低 30-50%不再保存中间激活推理速度提升 10-30%不再构建计算图。这是推理加速的最低配置——任何推理代码都必须加torch.no_grad()。不加就是浪费。1.2 第二板斧半精度推理FP16/BF16——Tensor Core 加速现代 GPUNVIDIA V100 及以后内置 Tensor Core——专门执行矩阵乘法的硬件单元对 FP16/BF16 数据类型的吞吐量是 FP32 的 2-8 倍。FP16Float16。16 位浮点数范围 ±65504精度约 3 位十进制。优点是 Tensor Core 加速明显缺点是范围小容易溢出和精度低。需要配合 Loss Scaling 使用。BF16BFloat16。16 位浮点数范围与 FP32 相同8 位指数精度约 2 位十进制。优点是不溢出、不需要 Loss Scaling缺点是精度更低。A100/H100 原生支持 BF16 Tensor Core。混合精度推理。权重用 FP16/BF16 存储关键操作如 LayerNorm、Softmax用 FP32 计算。这是 LLM 推理的标准做法——model.half()或model.bfloat16()一行搞定。效果显存占用降低 50%权重从 FP32 变 FP16推理速度提升 1.5-3xTensor Core 加速。1.3 第三板斧torch.compile——算子融合PyTorch 2.0 引入的torch.compile()是推理加速的游戏规则改变者——它将 Eager Mode 的逐算子执行编译为融合的 Triton Kernel。Eager Mode 的问题。每个算子都是一次 Python→C 调用中间结果需要写回显存再读出。例如y gelu(x w b)在 Eager Mode 下需要 4 次显存读写xw 写出中间结果、b 读入写出、gelu 读入写出。torch.compile 的优化。将多个算子融合为一个 Triton Kernel——中间结果留在 GPU 寄存器/共享内存中不写回显存。y gelu(x w b)编译后只需 1 次显存读写。效果推理速度提升 1.5-3x减少 Python 开销 算子融合显存占用降低 20-40%减少中间张量。1.4 第四板斧导出部署——极致优化torch.compile仍然依赖 PyTorch 运行时。要获得极致性能需要将模型导出为独立格式ONNX Runtime。torch.onnx.export()导出 ONNX 格式ONNX Runtime 执行。跨平台CPU/GPU/Edge算子级优化。适合嵌入式和边缘部署。TensorRT。ONNX→TensorRT 编译。极致算子融合、Kernel Auto-Tuning、INT8/FP8 量化。NVIDIA GPU 上最快的推理方案。编译时间长分钟级但推理延迟最低。torch.export。PyTorch 2.x 的新导出 API导出torch.export.ExportedProgram保留 PyTorch 的动态特性。适合 TorchServe 和进一步编译优化。效果推理速度提升 3-5x极致优化 INT8 量化但需要额外的编译/导出步骤。1.5 四板斧是叠加关系四板斧不是互斥关系而是叠加关系——每一层都在上一层的基础上加速torch.no_grad()→ 禁用 Autograd → 基础加速FP16/BF16 → Tensor Core → 显存减半 计算加速torch.compile()→ 算子融合 → 减少 Python 开销导出部署 → 极致优化 → 跨平台推理Agent 开发者至少要做到前两层——no_grad FP16是推理的最低配置。 二、模型量化INT4/INT8 的选择与实战2.1 为什么需要量化一个 7B 参数的 LLMFP16 权重需要 14GB 显存。加上 KV Cache 和运行时开销单卡推理至少需要 24GBA10/A100-40G 勉强80G 舒适。但大多数 Agent 场景不需要 FP16 的全部精度——INT4 量化后7B 模型只需 3.5GB 显存单卡可以跑多个实例。量化的核心权衡精度损失 vs 资源节省。INT4 量化通常只损失 1-3% 的任务精度但显存降低 75%。对于 Agent 推理INT4 几乎总是正确的选择——省下的显存可以给 KV Cache。2.2 四种量化方案对比GPTQGPT Quantization。训练后量化PTQ需要校准数据集128-256 条样本。INT4 量化分组大小 128。量化过程逐层量化用 Hessian 矩阵近似最小化重建误差。优点是量化质量高1-2% 精度损失vLLM/TensorRT-LLM 原生支持。缺点是量化过程慢7B 模型约 30 分钟需要 GPU。AWQActivation-aware Weight Quantization。训练后量化考虑激活值分布。核心洞察不是所有权重同等重要——激活值大的通道对应的权重更重要应该保留更高精度。AWQ 对重要通道做缩放后再量化保留关键信息。优点是量化速度快比 GPTQ 快 2-3x质量接近 GPTQ。缺点是校准数据集要求与 GPTQ 类似。bitsandbytesNF4/FP4。即时量化无需校准数据集。NF4NormalFloat4是 QLoRA 论文提出的 4 位格式针对正态分布权重优化。加载模型时一行代码量化load_in_4bitTrue。优点是零额外步骤适合快速实验和 QLoRA 微调。缺点是推理速度不如 GPTQ/AWQ缺少专用 Kernel 优化vLLM 不原生支持。GGUFllama.cpp 格式。CPU/Apple Silicon 友好的量化格式。多种量化等级Q4_0/Q5_1/Q8_0在精度和大小之间灵活选择。Ollama 的底层格式。优点是 CPU 推理最快Mac M 系列芯片优化。缺点是 GPU 推理不如 GPTQ/AWQ。2.3 量化选择决策树量化选择取决于部署场景GPU 服务器 vLLMGPTQ/AWQ INT4 → vLLM 原生支持吞吐最高消费级 GPU 单卡bitsandbytes NF4 → 快速实验无需校准CPU/Mac 本地推理GGUF Q4_0 → llama.cpp/OllamaCPU 最优训练微调 QLoRAbitsandbytes NF4 → 4 位基座 16 位 LoRA2.4 量化的 Agent 实战Agent 场景下量化不只是压缩模型——它直接影响你能服务多少并发请求。一个 7B 模型 FP16 占 14GBINT4 占 3.5GB——省下的 10.5GB 可以给 KV Cache支持更长的上下文和更多的并发请求。# GPTQ 量化 vLLM 部署Agent 首选fromvllmimportLLM,SamplingParams llmLLM(modelTheBloke/Llama-2-7B-Chat-GPTQ,quantizationgptq,dtypefloat16,gpu_memory_utilization0.9,) 三、vLLM 与生产部署从 PagedAttention 到 Agent 服务化3.1 传统推理服务的瓶颈传统 LLM 推理服务如 HuggingFace TGI 早期版本面临三大瓶颈KV Cache 碎片化。为每个请求预分配最大长度的连续显存如 2048 Token。但大多数请求远短于最大长度——平均 200 Token 的请求也占用 2048 Token 的空间。内部碎片率高达 60-80%。静态批处理。等整批请求全部完成才能处理下一批。一个长请求2000 Token会拖慢整批短请求。GPU 利用率低。无前缀共享。多个请求共享相同 System Prompt 时每个请求都独立存储一份 KV Cache——重复浪费显存。3.2 PagedAttentionKV Cache 的虚拟内存vLLM 的核心创新是PagedAttention——将操作系统的虚拟内存分页思想应用到 KV Cache 管理。传统方式为每个请求预分配连续的 KV Cache 内存块。最大长度固定内部碎片严重。PagedAttention将 KV Cache 分割为固定大小的 Block默认 16 Token维护逻辑 Block→物理 Block 的映射表。逻辑 Block 不需要连续物理 Block 按需分配。PagedAttention 的三大优势消除内部碎片。最后一个 Block 可能不满但浪费最多 15 个 Token 的空间vs 传统方式浪费数百个 Token。显存利用率从 20-40% 提升到接近 100%。支持前缀共享。多个请求共享相同前缀System Prompt RAG 文档时只需存储一份物理 Block逻辑 Block 通过 Copy-on-Write 共享。这就是 vLLM 的 Automatic Prefix Caching。按需分配。请求生成多少 Token 就分配多少 Block不需要预分配最大长度。短请求不会浪费长请求的空间。3.3 Continuous Batching请求级调度传统批处理是静态的——等整批完成才能处理下一批。Continuous Batching 是动态的——每个 Decode 步骤结束后完成的请求立即移出新请求立即加入。效果GPU 利用率从 30-50% 提升到接近 100%吞吐提升 2-4x。长请求不再拖慢短请求。3.4 Speculative Decoding用小模型猜、大模型验Speculative Decoding 的思路用一个小的 Draft Model 快速生成 K 个候选 Token然后用大的 Target Model 一次前向验证所有候选。如果全部接受相当于一次前向生成了 K 个 Token——延迟降低 2-3x精度无损。3.5 四种部署方案对比vLLMPagedAttention Continuous Batching Prefix Caching。OpenAI 兼容 API。GPTQ/AWQ 原生支持。Agent 首选——吞吐最高、延迟最低、功能最全。TensorRT-LLMNVIDIA 极致优化。Kernel Auto-Tuning。INT8/FP8 量化。延迟最低但编译时间长分钟级灵活性不如 vLLM。TorchServePyTorch 官方。多模型管理。A/B 测试。模型版本控制。适合传统 ML 模型和非 LLM 场景。ONNX Runtime跨平台。CPU/GPU/Edge。模型导出后独立运行。适合嵌入式和边缘部署。3.6 Agent 生产部署最佳实践Agent 的推理链路通常是用户输入→Tokenizer→Embedding→Transformer Prefill→Transformer Decode→采样→输出。其中 Transformer Decode 是瓶颈——逐 Token 生成KV Cache 不断增长。生产部署的完整链路量化GPTQ/AWQ INT4 → 显存降 75%推理引擎vLLM → PagedAttention Continuous Batching缓存优化Prefix Caching → 命中率 80-98%延迟优化Speculative Decoding → 延迟降 2-3x监控KV Cache 命中率 延迟 P99 吞吐 QPS 四、系列终章回顾三篇文章的脉络理解发动机→理解传动→理解驾驶。第一篇四层架构与张量引擎。c10 提供基础数据结构ATen 提供算子与后端解耦Autograd 提供自动微分torch.nn 提供神经网络抽象。Tensor 的三件套Storage/Strides/Offset实现零拷贝。Dispatcher 根据 Dispatch Key 路由到不同 Kernel。第二篇Autograd 计算图与 nn.Module。前向传播即时构建计算图Function 节点 next_functions 边 saved_tensors 缓存反向传播沿图反向遍历执行 VJP。saved_tensors 是显存爆炸的元凶。nn.Module 是 Agent 与 PyTorch 的接口层——参数注册、钩子系统、序列化、设备迁移。第三篇Agent 开发实战。推理加速四板斧no_grad→FP16→torch.compile→导出部署模型量化四种方案GPTQ/AWQ/bitsandbytes/GGUFvLLM 三大核心PagedAttention/Continuous Batching/Speculative Decoding四种部署方案vLLM/TensorRT-LLM/TorchServe/ONNX Runtime。PyTorch 是 Agent 的发动机——它定义了模型怎么算。vLLM 是变速箱——它定义了模型怎么服务。理解发动机、理解传动、理解驾驶——这就是从能跑到能服务的完整路径。 总结速查卡PyTorch Agent 开发核心概念概念一句话解释no_grad禁用 Autograd——推理的最低配置FP16/BF16半精度——Tensor Core 加速 显存减半torch.compile算子融合——减少 Python 开销1.5-3x 加速GPTQ训练后 INT4 量化——vLLM 原生支持Agent 首选AWQ激活感知 INT4 量化——比 GPTQ 快 2-3xPagedAttentionKV Cache 分页管理——显存利用率接近 100%Continuous Batching请求级调度——吞吐提升 2-4xSpeculative Decoding小模型猜大模型验——延迟降 2-3x一句话总结PyTorch Agent 开发的完整链路推理加速四板斧no_grad→FP16→torch.compile→导出部署是叠加关系至少做到前两层。模型量化选择取决于场景——GPU 服务器用 GPTQ/AWQ INT4 vLLM消费级 GPU 用 bitsandbytes NF4CPU/Mac 用 GGUF。vLLM 的 PagedAttention 将 KV Cache 分页管理显存利用率从 20% 提升到接近 100%Continuous Batching 实现请求级调度吞吐提升 2-4xSpeculative Decoding 用小模型猜大模型验延迟降 2-3x。四种部署方案各有侧重——vLLM 是 Agent 首选TensorRT-LLM 是极致性能TorchServe 是官方方案ONNX Runtime 是跨平台。PyTorch 是 Agent 的发动机vLLM 是变速箱——理解发动机、理解传动、理解驾驶这就是从能跑到能服务的完整路径。参考链接vLLM 官方文档PagedAttention 论文torch.compile 文档GPTQ 论文AWQ 论文TensorRT-LLMTorchServe
