从最早跑通一个 7B 模型的推理到后来把几十B、上百B的模型塞进有限的显存里还要保证吞吐不掉链子这几年在大模型优化这条路上踩的坑、趟过的河真不少。每次看到新入行的朋友问“显存不够怎么办”“推理太慢怎么办”我都想说大模型优化从来不是单点技巧而是一套从训练到推理、从算法到工程的全链路平衡术。这篇就把我这些年沉淀下来的大模型相关优化技术做一次系统总结从并行训练、显存管理、量化压缩、推理加速到服务架构把每一项技术的适用场景、核心思路和实操要点讲清楚希望能给正要入坑或者已经在坑里的朋友一些可落地的参考。1. 优化到底在优化什么先想清楚瓶颈再动手很多人一上来就急着调量化、上并行结果折腾半天效果反而更差。我个人的习惯是接到一个优化任务先回答三个问题模型能不能训起来、能不能跑起来、跑得快不快。这三个问题对应的其实是三组完全不同的优化维度混在一起做只会顾此失彼。模型能不能训起来核心是显存和算力的问题。显存不够要么换并行策略要么省激活值内存要么降低精度算力不够就要考虑通信占比、计算效率、数据加载是不是在拖后腿。模型能不能跑起来核心是推理引擎和服务框架的问题量化精度够不够、KV Cache怎么分配、批处理调度怎么设计。跑得快不快核心是吞吐和延迟的平衡问题这里又牵扯到动态批大小、投机采样、前缀缓存、请求调度策略。这三层之间不是孤立的。比如你做了量化模型变小了显存省下来KV Cache就能开更大批处理吞吐就能提上去但量化带来的精度损失可能让业务端效果变差。又比如你上了 PD 分离推理延迟降了但调度复杂度上去了显存碎片增加出了问题也更难定位。所以优化这件事本质上是在一组互相拉扯的指标里找平衡点而不是某个单一指标拉到极限。拿我经手的一个场景举例某模型的推理服务目标是首 token 延迟低于 300ms吞吐尽量高同时批处理时延不能把长尾请求拖死。一开始团队只盯着吞吐优化把动态批开到很大结果 TTFT 飙到 800ms业务方直接投诉。后来调整了调度策略把请求按预估输出长度分成不同队列配合 PD 分离和前缀缓存才把延迟和吞吐同时稳住。这个例子想说明的是先定义好要优化的指标再谈技术手段才是优化工作的正确打开方式。我建议任何团队在做大模型优化前先建立一套简单的性能基线单机单卡能跑多大模型、吞吐多少、TTFT 和 TPOT 分别是多少、显存占用分布在哪。没有基线后面所有优化都像在漆黑的房间里找开关撞到哪个算哪个。2. 训练侧的优化让算力真正用来学东西训练优化是很多做大模型应用的人容易忽略的环节因为多数人拿到的都是预训练好的开源模型。但实际上如果你做 SFT、继续预训练或者 RLHF训练侧的优化手段直接决定了你能不能跑起来、跑多快。2.1 并行策略不是越高阶越好是越匹配越好并行训练最基础的几个策略分别是数据并行、张量并行、流水线并行和序列并行。数据并行就是每个 GPU 放一份完整的模型各自吃不同的数据批次然后梯度同步。这个方案实现简单但显存门槛摆在那里模型一大就放不下了。张量并行是把一个 Transformer 层的矩阵运算切分到多张卡上比如按行切、按列切每张卡只算一部分然后通过 AllReduce 把结果拼起来。这种方式适合单机多卡因为通信量很大跨机走网线就很容易让通信时间超过计算时间。流水线并行则是按层切分每个 GPU 只负责模型的一部分层数据像流水线一样依次流过。它的通信量相对小但存在“气泡”问题——后面阶段的 GPU 要等前面算完才开始。微批次设计得好的话可以把气泡压到很低。我见过不少团队一上来就上 3D 并行数据并行 张量并行 流水线并行结果通信开销爆炸加速比还不如纯数据并行加梯度累积。我的建议是先看单卡能不能放下模型放得下就直接数据并行放不下再考虑张量并行跨机场景优先流水线并行而不是跨机张量并行。并行策略跟模型大小、集群拓扑强相关没有银弹。2.2 显存优化ZeRO 的思路值得吃透DeepSpeed 的 ZeRO 系列是我个人认为训练侧最有代表性的显存优化思路。它的核心洞察是数据并行里每张卡都存一份完整的模型状态参数、梯度、优化器状态这些状态其实是可以分片的。ZeRO-1 只分片优化器状态ZeRO-2 连梯度也分片ZeRO-3 把参数也分片了。分片之后每张卡只需要保存自己负责的那部分状态用到哪块参数再通过通信去取。代价是通信量增加所以 ZeRO-3 通常要配合 NVLink 或高速网络才能发挥价值。FSDP 是 PyTorch 官方的实现思路和 ZeRO-3 一致接口更友好适合 PyTorch 生态的团队。还有一个常被忽略的点是激活值显存。训练一个大模型中间层的激活值占的显存甚至比模型参数还多。主动重计算Activation Checkpointing的思路是前向的时候不保存全部激活值只存关键节点的输出反向计算到那一层时再重新算一遍。时间换空间换来的往往是显存减半甚至更多。在实际训练中重计算加 ZeRO 基本是标配组合省下的显存可以换更大的 batch最终反而训得更快。2.3 混合精度别迷信 FP16BF16 才是大模型的好朋友早期大模型训练流行 FP16 混合精度因为 FP16 能省一半显存计算也快。但 FP16 有两个先天问题表示范围小容易出现梯度下溢精度不够累加误差在大模型上会被放大。BF16 把指数位放大到和 FP32 一样表示范围几乎相同虽然尾数位少了导致精度略降但在训练场景下稳定性远远优于 FP16。尤其是大批次训练BF16 基本是当前大模型预训练和继续训练的主流选择。你看很多框架默认精度从 FP16 切到 BF16不是没有原因的。FP8 是更进一步的尝试常用于在 H 系列等新硬件上做训练加速。它有两种常用格式E4M3 适合前向E5M2 适合反向切换用不好会出数值问题。我的建议是FP8 训练不要轻易上除非你的算子和框架已经对 FP8 做过充分适配和验证否则上线排错会耗尽你的耐心。2.4 数据配比和训练技巧优化器不是越高级越好训练侧的优化不止是工程层面数据配比的影响常常被低估。同样是二次预训练数据顺序、领域占比、去重质量对结果的影响可能比模型结构改动还大。我的经验是数据清洗和采样策略值得投入比调参更多的时间——反正调参有天花板而数据质量几乎没有天花板。优化器选择上很多人默认用 AdamW。AdamW 稳定是稳定但显存开销大因为要保存一阶和二阶动量。如果你显存吃紧可以试试 Adafactor它通过分解二阶动量来省显存或者狮身人面像优化器 SignSGD 系列的变体通信量更小。代价是需要更多调参经验新项目建议先用 AdamW 跑通再考虑替换。2.5 训练加速实操清单把你手头训练速度上不去的问题按照下面顺序排查大概率能快速定位看 GPU 利用率是否接近预期如果长期低于 80%考虑数据加载和预处理是否成为瓶颈看通信占比大规模并行时通信时间超过 20% 就要优化并行策略看显存是否够用显存紧张导致 batch 放不下的优先上重计算和梯度累积看精度配置BF16 是否开启、Loss Scaling 是否设置合理看日志和监控前几个 step 的 loss 曲线是否异常震荡3. 推理侧的优化把模型压缩到能上线训练完的模型要面对另一个现实问题——怎么在这个显卡上跑得动、跑得快。推理优化是整个产业链上大家感知最强的部分也是技术栈最丰富的方向。3.1 量化压缩模型最直接的手段量化是把模型的权重和激活从 FP16 压到 INT8、INT4 甚至更低精度。压缩之后模型体积变小显存占用降低相同显存能塞进更大的模型或者更大的 KV Cache推理吞吐通常也能提上去。量化的路线大体分两种训练后量化PTQ和量化感知训练QAT。PTQ 不需要重新训练拿一批校准数据算一下缩放因子就行成本低、上线快是最常用的手段。QAT 需要在训练中模拟量化误差让模型参数主动去适应低精度表达效果通常更好但成本高适合那些对精度极其敏感的模型。实际工程里GPTQ 和 AWQ 是 INT4 权重量化里比较流行的方案。GPTQ 基于近似二阶信息做逐层量化目标是减小量化误差对输出的影响AWQ 则更聪明地识别出少数对精度影响大的“敏感权重”在量化时给它们保留更高精度。两者效果接近AWQ 的校准成本低一些更容易落地。有一个容易踩的坑是只量化权重、不量化激活。权重一次性加载量化计算可以在加载时完成但激活是动态产生的如果不配合激活量化实际运算是 FP16 和 INT4 混合的显存和速度的收益会打折扣。所以做推理优化时一定要看清楚框架到底量化了哪些部分。3.2 剪枝和稀疏化效果和收益之间的博弈剪枝的思路很直观把模型里不重要的参数去掉模型变小、计算变少。非结构化剪枝把不重要的单个权重置零压缩率可以很高但权重矩阵变成稀疏的实际加速需要专门的稀疏算子支持否则反向更慢。结构化剪枝按行、按列、按通道删结构规整容易利用硬件加速但精度损失往往更大。在大模型推理里稀疏化的应用不如量化广泛。一个重要原因是显存和算力瓶颈可以通过量化更好地解决剪枝的精度风险更高收益却不那么明显。不过模型蒸馏后配合剪枝做小模型替换大模型在小尺寸模型场景是有价值的。3.3 蒸馏用大模型教出小模型蒸馏是把大模型的“知识”迁移到小模型里。常见的做法是用大模型对一批数据生成输出再用这些软标签训练小模型。这样做出来模型体积小、推理快而且在某些任务上能保留接近大模型的效果。蒸馏分为白盒蒸馏和黑盒蒸馏。白盒蒸馏能拿到大模型的中间层输出和注意力图对齐更细粒度但只能用于同架构或者可对比架构黑盒蒸馏只拿最终输出适合那些只能通过 API 访问的大模型。对实战来说黑盒蒸馏更符合商业场景因为开源大模型可能不够强而商业 API 只给你输入输出。有一点要提醒蒸馏出来的小模型在泛化能力上通常不如大模型特别是在分布外数据上会脆弱很多。如果业务数据分布稳定、任务相对单一蒸馏是个很好的手段如果数据五花八门还是老老实实上大模型加量化更靠谱。3.4 KV Cache 优化推理性能的隐形冠军自回归生成的特点是每生成一个 token都要拿之前所有 token 的 Key 和 Value 去算注意力。如果每次都重新计算计算量随着序列长度平方级增长根本扛不住。KV Cache 就是把这些历史 Key/Value 缓存下来避免重复计算。但 KV Cache 很吃显存。长上下文场景下KV Cache 的显存占用很容易超过模型权重本身。这就催生了一堆优化方向第一缓存复用。多轮对话场景里前面轮次的 KV 可以复用不用每次重新计算。前缀缓存就是把相同前缀的请求 KV 缓存共享做对话系统和 RAG 场景收益很可观。第二更好的显存管理。PagedAttention 的思路类似操作系统里的分页把 KV Cache 切成小块按需分配减少显存碎片提高利用率。这个技术是当前很多主流推理框架吞吐提升的核心原因之一。第三KV Cache 量化。把 KV Cache 的精度从 FP16 压到 INT8 甚至更低的 INT4省显存效果显著但对精度的影响要实测验证。长上下文场景下 KV Cache 量化尤其值得试因为省下来的显存可以大幅提升批量大小。3.5 投机采样用“草稿”提速自回归自回归生成是一步步来的每步只能生成一个 tokenGPU 的算力被严重浪费。投机采样的思路是先用一个很小的草稿模型快速生成多个候选 token再由大模型一次性验证。如果草稿模型预测得准一次前向就能确认多个 token生成速度成倍提升。这套方案对草稿模型的准确性要求很高。草稿模型和大模型的分布差异越大接受率越低收益越小。实际工程里草稿模型一致率能做到 60%-80% 就很不错了。还有一种不需要额外草稿模型的自投机方法利用模型自己的浅层去预测后续 token实现更简单但接受率看模型结构。这块在短序列场景收益不明显因为草稿模型的前向开销可能抵消收益但在需要生成大量文本的场景比如代码生成、长文写作提速非常明显。3.6 连续批处理和动态调度吞吐提升的秘密武器最早期的推理服务是静态批处理一个 batch 里的请求必须全部完成后才能换下一批。这导致 GPU 利用率很低早完成的请求只能空等新来的请求再急也得排队。连续批处理打破了这种模式一个请求生成完了就立刻离开新请求马上补进来。GPU 永远在处理活跃请求吞吐提升通常很可观。再加上基于预估长度的动态调度短请求优先、长请求延后尾延迟也能得到控制。这类技术在主流推理框架里基本是标配了做推理服务时如果没有连续批处理说明你用的框架比较旧建议尽早切换。4. 服务架构层面的优化不止是模型本身的优化模型层面优化做到一定程度你会发现瓶颈开始转移到服务架构上。这里聊几个架构层面的关键优化点。4.1 Prefill-Decoding 分离让两个阶段各得其所自回归推理的两个阶段 Prefill 和 Decode 对算力的需求截然不同。Prefill 阶段一次性处理所有输入 token计算密集适合高算力 GPUDecode 阶段逐个生成输出 token访存密集算力需求不高但延迟敏感。PD 分离就是把两个阶段拆开部署到不同的实例上。Prefill 实例用强大的计算卡Decode 实例用大显存卡中间通过队列衔接。这样 Prefill 可以更大批量处理Decode 实例的显存也更充裕首 token 延迟和生成吞吐同时受益。PD 分离带了一个业务价值降低了多用户场景下的排队时间和资源浪费。代价是架构复杂多了一个调度组件显存和磁盘 IO 的衔接也需要额外关注。我建议在业务量级较大、并发请求比较多的时候考虑 PD 分离如果并发量不大传统一体式推理加合理的批处理调度已经够用没必要给自己加复杂度。4.2 前缀缓存与多级缓存对话系统、Agent 场景中请求往往共享相同的前缀。比如系统提示词很长、用户的历史消息不变这些内容对应的 KV Cache 如果每来一个请求都重新计算一遍计算和时间开销都很大。前缀缓存就是把公共部分算好存起来新请求来了直接拼接。更进一步的思路是多级缓存热数据放显存温数据放内存冷数据放磁盘。把不同频次访问的内容放到不同层级能大幅提升平均缓存命中率。配合请求调度让相同前缀的请求优先命中同一台实例缓存收益会更高。这类优化的上线效果经常被低估。我实测过一个对话产品开启前缀缓存后 TTFT 平均下降了三到四成吞吐也有明显改善而且几乎不需要改动模型只是工程层面积累的收益。4.3 模型路由与级联别让大模型干所有活很多时候不需要最高级的模型来处理所有请求。简单问题用小模型回答复杂问题才路由到大模型这种模型路由方案能省下大量推理成本。路由判断可以用规则的意图分类器也可以用一个小模型来做打分。级联的思路更进一步先让低成本模型回答如果置信度足够高就直接返回置信度低再升级到大模型。这套方案在客服、问答等场景效果非常好成本能下降不少但需要设计好置信度评估和降级策略避免用户反复得到错误答案。模型路由这块和纯工程优化不同它属于策略层面的优化需要业务数据的支撑。它带来的收益是用更低的成本达到相近的效果在成本和性能之间做权衡特别适合有量级业务、对成本敏感的团队。4.4 输入输出侧的多模态优化多模态模型推理时图片、音频等输入需要经过预处理编码。编码过程如果不优化会成为新的瓶颈。常见的手段包括提前对图片做缩放归一化、采用更轻量的视觉编码器、缓存重复出现的视觉特征。输出侧也值得关注。通过早期退出机制对一些高置信度的简单 token 提前生成而不必每步都跑完整模型这类思路在部分场景能带来额外加速。不过工程复杂度高一般只有在标准手段都用尽之后才值得尝试。5. 优化工具链选型用什么框架决定了你的效率边界工欲善其事必先利其器。大模型优化的工具链选型直接影响团队能否快速落地。这里聊聊几个主流方向的特点和适用场景。5.1 训练侧工具DeepSpeed 是当前训练优化绕不开的名字。它的 ZeRO 系列、梯度压缩、混合精度、并行策略集成都在一个框架里文档也比较全。PyTorch 的 FSDP 更为原生和 PyTorch 生态结合最紧密如果团队本来就用 PyTorch 做研发FSDP 上手成本更低。轻量化微调工具方面Unsloth 这类工具专门针对 LoRA 等参数高效微调做优化。它们的卖点是在保证效果的前提下降低显存占用和微调时间。实测下来一些场景下同等 batch 的显存占用能降低不少微调速度也有提升。对于只需要做指令微调、算力紧张的团队很友好。5.2 推理侧工具推理引擎的选择直接决定了你能吃到多少优化红利。vLLM 是当前最流行的开源推理框架之一PagedAttention 和连续批处理的收益基本属于用了就回不去。它的缺点是调度策略和批处理逻辑是黑盒调好的想深度定制不如自研灵活。TensorRT-LLM 在 GPU 上做了深度算子融合和底层指令优化单卡或单机场景的延迟和吞吐通常表现突出。缺点是构建和调优的复杂度高而且对硬件和 CUDA 版本有要求新手直接上手会有些吃力。llama.cpp 的价值在于极致的轻量化和跨平台部署CPU 推理也能跑适合本地部署、边缘设备场景。它的优化思路和工业级部署不太一样更偏向“在这种简陋的硬件上也能跑起来”。5.3 服务化框架在推理引擎之上还需要一层服务化框架来处理并发、负载均衡、模型管理。这个层级的功能包括动态批处理、请求队列、监控告警、弹性扩缩容。很多团队直接用推理引擎自带的服务模块先用起来再逐步替换成更成熟的方案。工具选型没有最好的只有最合适的。我给团队的选型建议是先看团队的工程能力再看硬件约束最后看性能目标。工程能力弱的选集成度高的方案硬件是老款卡优先考虑兼容性性能目标苛刻才值得投入做深度定制。6. 常见问题与排查技巧实录来分享一些实操中反复遇到的问题和我的排查思路这些经验比理论更“值钱”。6.1 显存不够怎么办显存不足是优化工作中概率最高的问题。排查路径建议从简单到复杂先确认是模型权重、KV Cache 还是激活值占的显存。用监控工具看显存分类占比别盲目优化模型权重大的先做 INT8/INT4 量化或者缩小模型版本KV Cache 占用大的调低缓存大小、开启 KV Cache 量化或复用缓存激活值占用的在训练侧开重计算在推理侧检查 batch 大小有一个反直觉的经验显存不够时不要把 batch 调得太小因为批处理太小会导致 GPU 利用率低下反而需要更多轮次处理请求。更合理的做法是保持合适 batch 并配合量化省显存。6.2 量化后效果崩了量化后模型输出明显变差先别怀疑量化方法本身。排查顺序是校准数据选得是否合理敏感权重是否被保护量化范围是否覆盖真实输入分布。校准数据是最容易被忽视的环节它必须尽量贴近业务真实分布拿一套无关的通用数据校准上线效果差很正常。另外一个容易被忽略的点是量化的不仅是权重。激活量化、KV Cache 量化都可能引入误差逐步关闭这些位的量化做对比实验能快速锁定是哪一层引入了问题。6.3 吞吐上不去吞吐低一般几个原因GPU 利用率低、显存带宽受限制、请求排队不合理。先看 GPU 利用率和显存带宽再看批处理是否足够大、连续批处理是否开启。另外一个常见原因是请求长度差异大长序列请求把批处理里的短请求全拖慢了。动态队列调度是解决这个问题的有效手段。6.4 首 token 延迟高TTFT 高通常出在 Prefill 阶段太长或者排队等待时间过长。如果输入文本很长Prefill 计算量大考虑换更强的算力卡或者把公共前缀缓存起来。如果排队等待时间长检查批处理调度策略让新请求能被更早调度。6.5 长上下文场景显存暴增长上下文是显存杀手。KV Cache 随序列长度线性增长如果有人输入一个 100K 的上下文KV Cache 可以直接吃掉几十 GB 显存。应对手段包括限制上下文长度、KV Cache 量化、缓存复用。对于大多数业务实际经常用到的上下文长度并不需要拉到硬件极限设置合理的上限是明智的。7. 从我的实操体会出发的几点建议优化工作做得久了越来越觉得技术选型之外有一些更底层的经验值得分享。第一做优化之前一定要做 profiling。很多团队拿个小数据集一测发现显存不够就急着上量化结果量化完精度差到不可用又回头骂量化不行。事实是有时候只是 batch 设置不对或者显存碎片太多根本不关量化的事。花在 profiling 上的时间永远不亏。第二指标要量化优化要有对照。每个优化动作上线前把延迟、吞吐、显存、精度的变化记录下来形成一张对照表。没有对照你根本不知道是哪个改动起了作用下次换场景又得从头试。第三想清楚为什么优化比怎么优化更重要。你是要降成本、降延迟还是提吞吐目标不同手段完全不同。降成本靠量化加模型路由降延迟靠前缀缓存加 PD 分离提吞吐靠连续批处理和 KV Cache 优化。以终为始才不会在优化过程中迷失方向。大模型优化是一个不断做填空题的过程永远在成本和效果的平衡木上移动。把基础技术吃透把 profiling 做扎实剩下的就是用时间换经验了。希望这篇总结能让你少走一些我走过的弯路。