推理部署

NVIDIA 官方反复强调，GB300 NVL72 那 $0.123/百万 token、约 116 TPS/用户的数字，是用 Dynamo 加 TensorRT-LLM 打出来的，不是开箱即用的通用框架。TensorRT-LLM 的核心动作是「先编译 engine，再加载服务」——这和一条命令拉起的范式完全不同。想在自己的 Blackwell 卡上逼近官方数字，就得过 build engine 这一关。 TensorRT-LLM 为什么要先编译后运行？ 第一步，把开源模型转成中间 checkpoint，再 build 成针对你这套 GPU 拓扑优化的 engine。关键编译参数包括：最大批大小、最大序列长度、张量并行度、是否开启分页 KV cache。这些参数一旦定死，engine 就定型了，改任何一个都要重新编译。第二步，用编译好的 engine 起推理服务，这时你会发现启动快得多——因为重活已经在 build 时干完了。 哪三个参数最容易踩错？ 最大序列长度设太大会让 engine 体积暴涨、显存预留过多；按业务真实 P99 长度设，不要拍脑袋给一个远超需要的值。张量并行度要和你实际卡数一致，八卡机器别 build 成四路并行。分页 KV cache 的块大小影响显存碎片，默认值通常够用，但长上下文场景值得微调。 编译报错该怎么一步步排查？ build 阶段最常见的错是模型与算子不兼容——某些自定义算子在新架构上需要最新版 TensorRT-LLM。遇到算子不支持，先查版本，别急着改模型。另一个坑是 build 很吃磁盘和显存，build 时最好独占机器，别和别的任务抢显存。 编译耗时和版本升级要注意什么？ 要有心理准备：编译 engine 在大模型上可能要几十分钟甚至更久，这是一次性成本，但团队会因此倾向于少改配置。建议把常用配置固化成脚本和模板，build 过程放进缓存——同一套参数、同一版本工具链，不必每次重编。另外，工具链小版本升级后，旧 engine 未必能加载，升级前先在测试环境重新编译一遍验证，别在生产上原地升级，否则一次启动失败就是全站事故。 什么场景才值得用 TensorRT-LLM？ TensorRT-LLM 的性能上限确实高，但它把灵活性换成了「编译期定型」。对追求极限单 token 成本、流量波形平稳的在线服务，值得投入；对需要频繁换模型、频繁调参的研发环境，通用动态框架仍然更顺手。选哪个，看你是要稳态产能还是要迭代速度。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：TensorRTLLM部署

部署架构的重要性 模型再好，部署不好也白搭。推理部署架构决定了服务的延迟、吞吐、可用性和成本。从单卡到大规模集群，每个规模都有不同的最优架构。 部署规模分层 Tier 1：单卡部署 适用场景： 小规模应用、开发测试、边缘计算 硬件配置： GPU: RTX 3090/4090 (24GB) 或 A10G (24GB) 模型: 7B Q4量化 并发: 5-10 QPS 延迟: 50-200ms/token 架构： [用户] → [Nginx] → [vLLM/Ollama] → [GPU] 优化要点： INT4量化减小模型大小 使用vLLM的PagedAttention 设置合理的max_batch_size 启用prefix caching Tier 2：多卡部署 适用场景： 中等规模生产环境 硬件配置： GPU: 2-8张 A100/H100 (80GB) 模型: 70B Q4 或 7B FP16 并发: 50-100 QPS 延迟: 30-100ms/token 架构选择： 方案A：Tensor Parallel（张量并行） 单模型分布在多GPU上: GPU1: 模型层1-40 (矩阵上半部分) GPU2: 模型层1-40 (矩阵下半部分) 每次forward需要GPU间通信 适合: 单模型多GPU场景 # vLLM张量并行 python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-3-70B \ --tensor-parallel-size 4 方案B：Pipeline Parallel（流水线并行） 模型按层切分: GPU1: 层1-20 GPU2: 层21-40 GPU3: 层41-60 GPU4: 层61-80 流水线处理多个请求 适合: 超大模型 方案C：数据并行（多副本） 4张GPU各运行一个完整模型副本: GPU1: 完整7B模型 ←→ 请求1-100 GPU2: 完整7B模型 ←→ 请求101-200 GPU3: 完整7B模型 ←→ 请求201-300 GPU4: 完整7B模型 ←→ 请求301-400 负载均衡分发请求 适合: 7B级别的多副本部署 Tier 3：集群部署 适用场景： 大规模生产环境 ...

模型量化是大模型部署最核心的优化技术之一。通过降低模型参数的数值精度，量化可以大幅减少模型体积、降低内存带宽需求、提升推理速度。2026年，随着大模型参数量持续增长和端侧部署需求加剧，量化技术的重要性愈发突出。本文从原理到实践，全面解析主流量化技术。 量化的数学基础 量化的本质是将连续的浮点数值映射到有限的离散值集合。给定浮点值x和量化位宽b，量化过程可以表示为： x_q = clip(round(x / s) + z, -2^(b-1), 2^(b-1)-1) 其中s是缩放因子，z是零点偏移。反量化过程为：x ≈ s · (x_q - z)。 对称量化 vs 非对称量化 对称量化将零点固定为0，量化范围对称分布。适用于权重等分布近似对称的张量。公式简化为x_q = clip(round(x / s), -2^(b-1), 2^(b-1)-1)。 非对称量化允许零点偏移，可以更精确地表示非对称分布的张量（如ReLU后的激活值，全部为非负数）。但非对称量化的计算略复杂，需要处理零点偏移。 实践中，权重通常使用对称量化（分布近似对称且计算更高效），激活值可以使用非对称量化以获得更好精度。 逐张量量化 vs 逐通道量化 逐张量量化为整个张量使用统一的缩放因子，实现简单但精度损失较大——不同通道的数值范围可能差异显著。 逐通道量化为每个输出通道使用独立的缩放因子，精度更高但需要存储更多缩放因子。对于权重量化，逐通道量化已成为标准做法，因为额外存储开销很小但精度提升显著。 主流量化方法 PTQ：训练后量化 训练后量化（Post-Training Quantization）在模型训练完成后进行，不需要重新训练，部署最便捷。 RTN（Round-to-Nearest） 最简单的量化方法——直接将浮点权重舍入到最近的量化级别。RTN不需要校准数据，速度最快，但在低位宽（INT4及以下）下精度损失严重。 GPTQ GPTQ基于二阶信息（Hessian矩阵）进行逐层量化优化。其核心思想是：在量化一个权重时，考虑量化误差对后续层输出的影响，通过调整未量化的权重来补偿量化误差。 GPTQ的量化流程： 使用少量校准数据（约128个样本）计算每层的Hessian矩阵 逐列量化权重，每量化一列就调整剩余列以补偿误差 量化顺序基于Hessian对角元素排序（敏感度高的最后量化） GPTQ在INT4量化中表现出色，Llama 70B的INT4 GPTQ量化在标准基准上性能损失不到1%。 AWQ（Activation-Aware Weight Quantization） AWQ的核心观察是：并非所有权重同等重要，与大幅值激活值对应的权重对量化误差更敏感。AWQ通过以下步骤实现激活感知量化： 使用校准数据分析激活值分布 识别"重要"权重通道（对应大幅值激活的通道） 对重要通道进行缩放保护，使其在量化后保持较高精度 相应缩放非重要通道以保持整体数值平衡 AWQ的优势是不需要修改量化算法本身，只是通过预处理调整权重分布。这使得AWQ可以与任何后端量化内核兼容。 SmoothQuant SmoothQuant针对激活值量化中的异常值问题。大模型激活值中存在少量极端大的异常值，导致激活量化困难。SmoothQuant通过将激活值的平滑因子"迁移"到权重上——将激活值除以一个平滑因子使分布更均匀，同时将权重乘以同样的因子保持数学等价。 SmoothQuant使得权重和激活值都可以量化到INT8而几乎无精度损失，是W8A8量化的首选方法。 QAT：量化感知训练 量化感知训练（Quantization-Aware Training）在训练过程中模拟量化效果，让模型适应量化带来的精度损失。QAT的精度通常优于PTQ，但需要完整的训练流程。 QAT的关键技术： 直通估计器（STE）：量化操作的梯度为零（round函数不可导），STE通过直接传递梯度绕过这一问题——前向传播使用量化值，反向传播使用浮点梯度。 学习型量化参数：将缩放因子作为可学习参数参与训练，让模型自动找到最优的量化范围。 渐进式量化：从高精度（INT8）开始训练，逐步降低到目标精度（INT4），给模型适应时间。 ...