大模型推理性能如何优化?
- **事实修正**：将“A80”改成“A100”；将“AIME满分成绩”改成更准确的“准确率”表述。
- **数据保持**：所有数字、加速比、模型参数等经核对在合理范围内，予以保留。
- **打散排比**：那四个“问自己”的问题重新组织，不再是一模一样的句式，读起来更顺。
- **去AI味**：原文本身网络感较强，没有出现你列出的那些空洞短语，所以只微调了少量过于规整的过渡，让语气更真实。
大模型推理优化，我替你踩了这些坑，看完少掉三层皮！
这事儿还得从去年说起。当时接了个客户，上来就甩需求：70B模型上线，首token延迟50ms以内，还得每秒处理20个并发。
我一开始心想：这不简单？vLLM怼上去完事儿！
结果呢？你猜怎么着？
首token倒是够快——啪的一下就出来了。但生成速度？跟乌龟爬似的，还动不动显存爆掉。我当时盯着监控面板，整个人都不好了。
然后我花了一周时间，把市面上能试的优化方案全撸了一遍。有些方案真香，有些就是坑。今天把这些经验写出来，省得你重走我的弯路，真的，兄弟，有些弯路走一次就够够的。
先说个大实话：七个葫芦娃，没有万能药
你看，我根据测试和业界经验，总结了七个优化方向。每个方向解决不同的问题，但绝对不是一招鲜。
它们分别是：并行策略（TP/PP）、量化、投机解码、稀疏注意力、MoE架构、编译器优化、KV Cache优化。
但我要给你泼盆冷水：没有银弹！ 每次拿到一个新方案，我都会先想清楚几个问题：
- 它到底优化了啥？延迟还是吞吐，首token还是后续速度？
- 我现在的痛点是不是这个？是显存不够还是计算不够？
- 它牺牲了什么？量化牺牲精度，投机解码牺牲兜底质量，增大batch牺牲用户感知的TPS。
- 最后是场景——高并发、低延迟、长上下文，答案完全不同。
说到这儿，我直接给你上干货，具体说说我测过的几个方案——有惊喜，也有翻车翻得我脸疼的。
并行策略：TP和PP怎么搭，我真切体会了一把
我第一次拿70B模型在8卡A100上测。单机内部用Tensor Parallelism，每张卡分到1/8的模型参数，延迟很低，首token大概30ms，生成速度每秒20个token左右。舒服。
后来换了个175B模型，单机8卡装不下，必须跨两台机器（16卡）。这时候我试了两套方案——
方案一：16路TP。 结果呢？机器之间走的是InfiniBand，但通信延迟还是高得离谱，有效利用率掉到40%以下。垃圾。 我当时看着时间线，大片大片的空白，真想砸键盘。
方案二：机器内部8路TP，两台机器之间2路PP。 你看，TP做细粒度切分，享受高带宽；PP做粗粒度流水线，跨机通信量小。这么一搭，利用率回到75%以上。
建议很直接： 能塞进单机就别跨机！跨机了就用机器内TP + 机器间PP，别反过来。这个顺序错了，性能崩给你看。
量化：INT8省显存是真，但小心精度陷阱
我在Llama-2 7B和13B上分别测了GPTQ (4bit)、AWQ、SmoothQuant几个量化方案。
权重量化（W8A16）几乎无损，推理速度快了30%-50%，显存省一半！ 7B模型用FP16时显存吃掉14GB，INT8只要7GB，刚好塞进一张RTX 3060。当时我就感叹：这才是穷人福音啊！
但到4bit就出问题了。
你想想，Llama-2 13B用GPTQ 4bit，在MMLU上掉了3个点。AWQ好一点，掉1个点。兄弟，看业务场景！ 做聊天可以忍，做数学推理绝对不能忍。你想想客户发现准确率下降，不得找你拼命？
KV Cache量化我也试了。公式你自己算：对于LLaMA2-7B，缓存一个Token的KV大约0.5MB。上下文越长，Cache越大。我用FP8量化KV Cache，显存占用减半，长文本（32K）下吞吐提升70%！精度损失？我测了BLEU，几乎没变。这个真香。
反直觉吧？大家以为量化越低越好，其实INT8才是甜点，4bit反而可能翻车。
投机解码：惊喜和翻车并存，我差点被坑哭
这个idea刚出来时我就很激动。你想，大模型一个token一个token生成，每步都要读一遍全部参数，显存带宽是瓶颈。投机解码用一个小模型（比如1B的所谓“草稿模型”）先快速猜出几个token，然后大模型一次性验证。
小模型生成快，大模型验证可以并行，理论上加速比取决于小模型的猜中率。论文说好的配对能做到2x加速。
我拿自己同源训练的一个0.5B小模型和7B主模型试，在我自己的测试集（代码生成和QA）上，猜中率大概40%，实际加速1.3x。离宣称的2x差远了。
后来我仔细分析trace，发现问题出在数据分布。 代码生成的猜中率比闲聊低得多，因为代码的token分布更广，小模型难猜。如果一段文本里有很多新词汇（比如API名），小模型直接翻车，大模型还得全部重新生成——比不用投机解码还慢！ 你感受一下那种心情：花了功夫优化，结果更慢了。
建议： 如果你的业务场景比较固定（比如合同模板、客服问答），投机解码值得一试。但如果是开放域、或者数据分布特别散，别抱太大期望。别像我一样，信了论文的数据就往上冲。
稀疏注意力：RTPurbo确实有点东西，我眼前一亮
最近看RTPurbo这个工作，我眼前一亮。之前我们都觉得Full Attention模型要做稀疏化就必须从头预训练，但这篇证明了——通过轻量级适配，Full Attention也能动态稀疏执行！
我虽然没有直接复现，但根据他们的数据，你看：
- 在32K上下文下，Prefill阶段比FlashAttention快2.83x
- 1M上下文时加速到9.36x
- Decode阶段也有1.47x到2.01x的增益
最厉害的是什么？它的稀疏策略是动态的！简单任务（大海捞针）平均只保留468个Active Tokens；复杂任务（Multi-K）自动扩到2462个。这比静态Top-k聪明太多了，你想想，静态Top-k管你任务简不简单，都算同样多，浪费啊。
他们还在AIME上保持了86.67的准确率，跟Full Attention一致。说明稀疏化后并没丢能力，至少在这个基准上。
说实话，这是我今年看到最有落地潜力的非训练优化方案，没有之一！
MoE：省钱不省显存，穷逼慎入
Mixtral 8x7B出来时我也跑了一遍。总参数47B，但每个token只激活两个专家（约14B参数），推理速度接近13B的水平，效果接近70B dense模型。听起来很牛对吧？
但注意：显存占用还是按总参数来的！ 47B用FP16要94GB显存，你至少需要两张A100（80G）才能装下。计算是省了，但显存没省。对于部署来说，如果你GPU不够大，MoE其实更费卡。
所以MoE适合的场景是：你有足够大的显存（或者很多卡），想要更大的模型容量，但不希望计算量线性增长。穷逼慎入——这是我最大的感悟，别看着参数小就冲。
最后说点工具层面的，别盲目抄作业
我测过vLLM、SGLang、TensorRT-LLM几个框架。vLLM的PagedAttention确实能显著提高显存利用率，尤其是多用户并行时。但它的调度开销在小batch下会比较明显，这个坑我也踩过。
调优的第一步永远是跑profile trace！ 看时间线上计算窗口占多少、通信占多少、Host调度和同步等待又占多少。如果大片空白，说明调度或通信是瓶颈；如果kernel很密但achieved FLOPS低，那问题在计算利用率。
比如有一次我开TP时发现rms norm的kernel反复调用，出现冗余计算。换成SP（Sequence Parallelism）后，通信量没增加但计算冗余消除了，延迟降了15%。这种细节，你不跑profile根本发现不了。
总结成一句话？不，我想给你一个带走念头的金句
大模型推理优化没有捷径，只有系统性去梳理自己的瓶颈。你用的模型多大？卡的型号和数量？业务场景是低延迟还是高吞吐？上下文是长是短？每个变量都可能决定哪个方案最优。
我踩过的最大坑就是轻信别人的最优配置。同样的70B，在A100上最优的并行方案和H100上完全不同，因为H100的NVLink带宽更高。你只能自己测。
好了，如果你正在折腾推理优化，记住这句话：
别人的银弹，可能是你的毒药。跑个profile，别盲目抄作业。
（好了，就说到这儿。要是觉得有用，转发给你那些还在坑里挣扎的兄弟，他们懂。）
读者评论 2