1. 从“跑得动”到“跑得快”推理优化到底在解决什么问题很多人第一次把大模型跑起来的时候注意力全在“能不能出结果”上。等模型真的能对话了才发现另一个更现实的问题同样的硬件为什么别人一秒能吐几十个token我这里像挤牙膏一样这就是推理优化要解决的核心矛盾——在有限的算力预算下把吞吐量拉上去、把延迟压下来、把显存占用控制住。先把概念理清楚。大模型推理分两个阶段Prefill预填充和Decode解码。Prefill阶段处理你输入的整段prompt是一次性的矩阵运算算力密集Decode阶段逐token生成输出每次只算一个token但要把之前所有token的KV缓存读一遍是典型的显存带宽瓶颈。这两个阶段的优化思路完全不同很多人一上来就调batch size结果Prefill撑爆显存、Decode还是慢就是因为没分清瓶颈在哪。我见过太多团队在推理优化上走弯路根本原因是没有建立指标体系。你至少得盯住这几个数指标含义优化方向TTFT首token延迟影响交互体感Prefill优化TPOT每token输出时间影响生成速度Decode优化吞吐量每秒总token数影响服务成本批处理优化显存占用模型KV缓存影响并发数量化分页搞不清这四个数的关系优化就是盲人摸象。比如你把batch size从1调到32吞吐量可能涨了5倍但TTFT从200ms涨到2秒交互场景直接不可用。所以优化的第一步不是动手改代码而是先明确你的场景到底在乎什么——是单用户低延迟还是高并发吞吐还是显存受限下的最大并发数。这个训练营之所以强调“实战”就是因为推理优化不是背几个参数就完事的。它需要你在真实硬件上、真实模型上、真实业务负载下反复测量、假设、验证。下面我按自己踩过的坑和总结的方法论把这条链路拆开讲。2. 量化用精度换速度的第一把刀2.1 为什么量化是性价比最高的起点如果你只能做一件事来加速推理那大概率是量化。原因很简单大模型推理的Decode阶段是显存带宽瓶颈模型权重占的显存越大每次读取越慢。把FP16的权重压到INT8甚至INT4显存占用直接减半或减到四分之一带宽压力同步下降速度提升立竿见影。但量化不是无脑压。我见过有人直接把模型转成INT4就上线结果输出质量崩得没法看。这里的关键是分清权重量化和激活量化。权重可以离线量化精度损失相对可控激活值是运行时动态产生的量化难度大得多。所以大多数实战方案走的是Weight-only Quantization也就是只量化权重激活保持FP16。2.2 GPTQ、AWQ、GGUF到底怎么选这三个词你肯定不陌生但它们的适用场景差别很大GPTQ基于二阶信息的后训练量化适合GPU推理4bit下质量保持不错。缺点是量化过程需要校准数据集且对某些模型结构敏感。AWQ激活感知的权重量化核心思路是保护那些“重要”的权重通道。实测在同等bit下AWQ的困惑度通常比GPTQ略好尤其在小模型上。GGUF这是llama.cpp生态的格式主打CPUGPU混合推理适合本地部署和边缘设备。它的量化等级从Q2到Q8Q4_K_M是质量和体积的甜点。选型逻辑很简单GPU服务端用GPTQ或AWQ本地/边缘用GGUF。如果你用的是vLLM这类推理引擎它原生支持GPTQ和AWQ直接加载量化模型即可。如果是ollama这类工具它底层就是llama.cpp用的就是GGUF。注意量化后的模型不是“越小越好”。Q2级别的量化在复杂推理任务上会出现明显的逻辑断裂我建议生产环境最低用Q4对话类任务Q5_K_M更稳妥。2.3 量化的实操细节与避坑量化过程中最容易忽略的是校准集的选择。校准集应该尽量贴近你的实际业务分布。如果你做的是代码生成校准集里全是通用中文语料量化后的模型在代码任务上可能掉点严重。我一般会从业务日志里抽500-1000条真实prompt作为校准集效果比用公开数据集好很多。另一个坑是KV缓存量化。很多人只量化了权重忽略了KV缓存。在长上下文场景下KV缓存可能比权重还大。把KV缓存量化到INT8显存能再省一半但要注意某些推理引擎对KV量化的支持不完善可能出现精度异常。建议先在测试环境验证输出一致性再上生产。3. 批处理与调度把GPU喂饱的艺术3.1 静态批处理为什么不够用最朴素的批处理是攒够N个请求一起送进GPU。但大模型推理的请求长度差异极大有的prompt只有十几个token有的上万。静态批处理会导致短请求等长请求GPU利用率忽高忽低。更麻烦的是Decode阶段。每个请求生成的token数不同有的生成10个就停了有的要生成500个。静态batch里只要有一个请求没结束整个batch都得等着这就是所谓的长尾效应。我实测过一个场景batch size16其中15个请求在50步内结束剩下1个跑了300步GPU利用率从90%掉到30%。3.2 Continuous Batching的核心机制Continuous Batching连续批处理就是为解决这个问题生的。它的核心思想是不等整个batch结束而是以token为粒度调度。某个请求生成完了立刻把它踢出去腾出的位置马上塞新请求进来。这样GPU始终处于满负荷状态。vLLM是把这个机制做得最成熟的引擎之一。它的PagedAttention把KV缓存分成固定大小的block像操作系统管理内存页一样管理显存。好处是显存碎片大幅减少并发数能提升2-4倍。我做过对比同样一张24G卡跑7B模型朴素方案并发8路就OOMvLLM能跑到20路以上。但Continuous Batching不是银弹。它引入了调度开销在请求量很低的时候反而比单请求慢。所以低负载场景直接单请求跑高负载再开批处理这个阈值需要根据你的QPS来调。3.3 调度策略的实战调参vLLM暴露了不少调度相关参数我挑几个关键的讲max_num_seqs同时处理的最大请求数。调太大显存扛不住调太小GPU吃不饱。建议从16开始逐步往上压测。max_num_batched_tokens一个batch里最多塞多少token。这个值直接影响Prefill的吞吐但太大会导致TTFT飙升。gpu_memory_utilization显存利用率上限默认0.9。如果你还要在同一张卡上跑其他服务得留出余量。我的调参顺序是先固定max_num_seqs压测找到吞吐拐点再调max_num_batched_tokens平衡TTFT和吞吐最后根据显存余量微调gpu_memory_utilization。整个过程要盯着监控别拍脑袋。4. KV缓存优化长上下文场景的生死线4.1 KV缓存为什么是显存杀手Transformer的自注意力机制需要缓存每个token的Key和Value向量避免重复计算。这个缓存的大小是KV缓存 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 精度字节数以一个7B模型为例32层、32头、头维度128、FP16精度序列长度4096时单个请求的KV缓存就是2×32×32×128×4096×2 ≈ 2GB。如果并发20路光KV缓存就40GB比模型权重还大。这就是为什么长上下文场景下显存永远是第一个爆的。4.2 PagedAttention与显存碎片治理传统KV缓存是连续分配的每个请求预留最大长度的空间。但实际生成长度往往远小于最大值造成大量浪费。PagedAttention把KV缓存切成固定大小的block比如16个token一块按需分配用多少占多少。这个思路和操作系统的虚拟内存分页一模一样。好处有三个内部碎片几乎消除、不同请求可以共享block比如相同的system prompt、显存利用率大幅提升。vLLM的实测数据显示PagedAttention能把显存浪费从60%-80%降到4%以下。但分页也有代价block table的查找有开销而且对注意力kernel的实现有要求。如果你自己写推理代码实现PagedAttention的复杂度不低。所以我的建议是直接用成熟引擎别重复造轮子。4.3 长上下文的取舍策略即使有PagedAttention长上下文依然昂贵。实战中我会做几件事滑动窗口注意力只保留最近N个token的KV缓存超出部分丢弃。适合对话场景因为很久之前的对话内容对当前回复影响有限。KV缓存量化把FP16的KV压到INT8显存直接减半。但要注意某些模型对KV量化敏感需要验证。前缀缓存如果多个请求共享相同的system prompt把这部分KV缓存复用能省不少显存和Prefill时间。提示滑动窗口会破坏模型的全局注意力能力在需要长文档理解的场景慎用。我一般只在纯对话场景开文档问答场景保持全量缓存。5. 推理引擎选型vLLM、TGI、TensorRT-LLM怎么挑5.1 三个引擎的定位差异市面上的推理引擎不少但真正在生产环境站住脚的就这么几个引擎优势劣势适用场景vLLM易用、社区活跃、PagedAttention对非Transformer结构支持一般通用GPU服务端TGIHuggingFace生态、部署简单定制化能力弱快速上线、标准模型TensorRT-LLM极致性能、NVIDIA官方优化编译复杂、模型转换麻烦追求极限吞吐的生产环境vLLM是我最常用的原因是开箱即用。一行命令就能起服务OpenAI兼容的API直接对接现有系统。TGI适合已经在用HuggingFace生态的团队部署体验很顺滑。TensorRT-LLM性能确实强但模型转换和编译的坑很多适合有专门推理优化工程师的团队。5.2 选型时容易忽略的维度除了性能还有几个维度值得考虑模型支持范围vLLM对新模型的支持通常最快TensorRT-LLM需要等官方适配。多卡并行TensorRT-LLM的Tensor Parallel做得最成熟vLLM也支持但配置稍复杂。量化支持vLLM原生支持GPTQ/AWQ/FP8TensorRT-LLM的量化路径更依赖官方工具链。运维成本vLLM的日志和监控更友好出问题好排查。我的建议是先用vLLM跑通遇到性能瓶颈再考虑TensorRT-LLM。不要一上来就追求极致先把链路跑顺。5.3 部署形态的选择推理服务的部署形态也影响优化策略单机单卡最简单适合中小规模。优化重点是量化和批处理。单机多卡用Tensor Parallel把模型切到多张卡。注意卡间通信开销NVLink比PCIe快很多。多机多卡用Pipeline Parallel或专家并行。网络带宽是瓶颈建议用高速互联。我踩过的一个坑是在PCIe环境下做Tensor Parallel通信开销吃掉了大部分并行收益4卡还不如2卡快。所以多卡之前先确认互联带宽别盲目堆卡。6. 实测调优从指标异常到根因定位6.1 一个真实的排查案例有次我帮一个团队看推理服务现象是QPS上不去GPU利用率只有40%但显存已经快满了。直觉告诉我这是显存瓶颈导致的调度受限但具体在哪需要数据说话。排查链路是这样的看显存分布用nvidia-smi发现显存占用高但GPU计算利用率低。说明卡在等数据不是算力不够。看KV缓存占用通过vLLM的metrics发现KV缓存占了70%显存。问题定位到长上下文请求。看请求分布日志显示少数请求的prompt长度超过8000token把KV缓存撑爆了。根因没有对输入长度做限制少数超长请求拖垮了整个服务。解决方案是对输入长度做硬限制超长请求走单独的队列并且给KV缓存设置上限超过就排队等待。调整后GPU利用率从40%拉到85%QPS翻了3倍。6.2 常见指标异常的对照表现象可能原因排查方向GPU利用率低但显存满KV缓存占用过大限制并发/长度开PagedAttentionTTFT高但TPOT正常Prefill计算量大减batch token数开chunked prefill吞吐高但延迟抖动大调度不公平调调度策略设优先级显存缓慢增长内存泄漏检查KV缓存释放逻辑这张表是我自己总结的基本覆盖了80%的常见问题。遇到异常先对号入座能省不少时间。6.3 压测方法论优化离不开压测但压测本身也有讲究用真实数据别用固定长度的假数据真实请求的长度分布才是关键。分阶段加压从低QPS开始逐步加观察指标拐点。盯P99而不是均值均值好看没用长尾延迟才是用户体验的杀手。记录每次变更调了什么参数、指标怎么变都要记下来否则调着调着就乱了。我一般用locust或wrk做压测配合PrometheusGrafana看实时指标。压测环境尽量贴近生产否则数据参考价值有限。7. 训练营里我会重点讲的那些“反直觉”经验7.1 不是所有模型都值得优化听起来很废话但确实有人在一个已经很快的小模型上死磕优化投入产出比极低。优化的前提是模型本身有优化空间。如果一个3B模型在目标硬件上已经能满足延迟要求那就别折腾了把精力放在业务上。反过来如果一个70B模型在单卡上跑不动那优化的第一优先级是换硬件或换模型而不是调参数。我见过团队花两周调参最后发现换张卡就解决了。7.2 精度和速度的平衡点因任务而异量化到INT4在对话任务上可能看不出差别但在数学推理或代码生成上可能掉点明显。不要用通用benchmark代替业务验证。我的做法是准备一套业务相关的评测集量化前后各跑一遍看关键指标是否可接受。7.3 缓存和预计算能解决很多问题有些请求是重复的比如固定的system prompt、常见的FAQ。把这些的KV缓存或结果缓存起来能省大量计算。vLLM的前缀缓存就是干这个的。更激进一点对于完全相同的请求直接返回缓存结果连推理都省了。7.4 监控比优化本身更重要优化是一个持续过程不是一锤子买卖。上线后流量模式会变、模型会更新、硬件会调整。没有监控的优化是盲目的。至少要盯住TTFT、TPOT、吞吐、显存、GPU利用率这几个核心指标设置告警阈值。8. 从训练营到生产你需要准备的技能栈如果你打算系统学习大模型推理优化我建议按这个顺序补技能基础层Transformer结构、注意力机制、KV缓存原理。不懂这些优化就是瞎调。工具层vLLM/TensorRT-LLM的使用、量化工具链、压测工具。系统层GPU架构、显存管理、CUDA基础、网络通信。业务层你的场景到底在乎什么指标怎么定义SLA。训练营的价值在于把这条链路串起来用真实项目带你走一遍。光看文档和视频遇到实际问题还是懵。我自己的经验是优化能力是在一次次排查异常中练出来的不是看会的。最后说个实在的推理优化这个方向现在需求很大但真正能落地的人不多。大部分人停留在“会部署”的层面能定位性能瓶颈、能调参、能压测的人薪资和机会都好很多。如果你已经在做相关的工作把这块补起来回报很直接。