1. 先搞清楚：大模型优化到底在解决什么问题

我参与的模拟项目X是一个典型的文档智能助手：输入几百页PDF，要求模型能总结、能问答、能抽取关键信息。最初直接用7B规模的基座模型，离线测试效果不错，一上并发就卡得没法用。这一轮折腾下来，我的感受是：大模型优化并不是某一项技术单独能解决的，它是一整套从训练到部署的手段组合。而且大多数项目真正缺的往往不是“更多算力”，而是对显存容量和传输带宽的管理能力。

很多人一听“优化”，第一反应是“省钱”。实际情况更复杂：显存容量决定模型能不能放得下，显存带宽决定每次存取数据要等多久，计算量才对应真正“算得快不快”。三者互相牵制，只看算力是不够的。举个例子，一张7B模型在FP16下光权重就要占14GB左右，单卡放是放得下，但一旦开启长文本推理，KV Cache和临时缓冲区加进来，显存立刻吃紧。容量不够，后面所有优化都免谈。

1.1 显存容量、带宽和计算量：三个瓶颈要分清

我习惯把显存比作仓库，把带宽比作仓库门口的传送带，算力则是仓库里打包的速度。三个环节都可能成为瓶颈：仓库太小，货没地方放；传送带太窄，GPU空转等数据；打包太慢，整体吞吐被计算卡住。大多数优化技术，本质上是在调整这三者的平衡。

带宽因素很容易被忽略。训练时每次迭代要读完整模型参数、写回梯度，推理时每个token生成都要扫描一遍全部权重。如果带宽不足，GPU算力再强也会被“等数据”拖死。这也是为什么“只增加GPU数量”解决不了所有问题——卡间通信一旦成为瓶颈，多卡反而比单卡更慢。尤其是张量并行这类细粒度并行方式，每一步都要同步通信，对卡间互联速度极其敏感。

所以我在项目里做优化前，先做一次基础测量：单卡上模型前向传播一次要多长时间，显存峰值是多少，卡间通信带宽能跑到多少。有了这些数据，后续的优化方案选择才有依据，而不是靠感觉“应该用哪个技巧”。

1.2 精度、速度、成本的不可能三角

任何优化手段，本质都是在这三者之间找平衡：精度上尽量不掉点，速度上尽量快，成本上尽量低。量化能提速省显存，但可能掉点；蒸馏能换小模型，但训练阶段要额外花精力；分布式能扩大规模，但通信和运维成本明显上升。没有一个优化手段是“全都要”的。

我采用的思路是先建立基线，再逐项优化。所谓基线，就是不加任何优化，用最原生的方式把模型跑通，记录三类数据：延迟（单次请求多久返回）、吞吐（单位时间能处理多少token）、显存峰值。然后每做一步优化，都拿基线数据做对比，判断这步优化到底值不值得上线。没有基线的优化，很容易被“感觉变快了”误导，实际上掉点严重或者偶发OOM，反而更不可控。

在模拟项目X里，我做了三轮优化迭代：第一轮搞定显存，让模型能在大并发下稳定跑起来；第二轮压低延迟，让首字响应进到一秒以内；第三轮压成本，用量化把单卡服务能力提上去。整个过程中，精度、速度、成本始终在互相拉扯，最后稳态方案是一个综合折中的结果，这也是大多数真实项目的常态。

2. 训练侧优化：把显存从“不够用”变成“刚刚好”

训练阶段的优化逻辑和推理完全不同。训练时最怕的是OOM，也就是显存溢出；推理时最怕的是延迟高。训练侧的核心矛盾在于：参数、梯度、优化器状态、激活值四个大项都在抢显存。以7B模型为例，如果不开任何优化，光是参数、梯度和优化器状态就已经超过50GB，单卡完全装不下，而且这个数字会随着模型规模线性增长。

这一节我把训练侧最常用、也最值得优先考虑的优化手段拆开讲。重点不是堆名词，是讲清楚每个技术到底省了哪部分显存、代价是什么、什么时候该用。

2.1 显存都去哪了：一份可以照着算的账

训练显存大致分成四块：模型参数、梯度、优化器状态、激活值。很多人只知道模型参数占多少，以为7B模型“不过14GB”，这是最容易翻车的地方。

我用一个估算脚本把账算清楚：

# 估算7B模型在FP16混合精度训练下的显存占用 param_size = 7e9 # 7B参数 fp16_bytes = 2 # FP16占2字节 fp32_bytes = 4 # FP32占4字节 # 模型参数（FP16） params_gb = param_size * fp16_bytes / 1024**3 # 约13.04GB # 梯度（FP16） grads_gb = params_gb # Adam优化器状态：m和v两个动量，且以FP32保存 optimizer_gb = param_size * fp32_bytes * 2 / 1024**3 # 约52.18GB # 参数+梯度+优化器状态 base_gb = params_gb + grads_gb + optimizer_gb print(f"参数+梯度+优化器状态约: {base_gb:.1f}GB") # 激活值另算，和batch size、序列长度直接相关

这个结果通常让很多人意外：优化器状态才是训练期的“显存大头”。Adam优化器要为每个参数保存一阶动量m和二阶动量v，而且默认用FP32精度，于是消耗急剧放大。所以训练侧第一优先级的优化方向，就是尽量减少优化器状态和梯度的存储冗余，其次才是激活值。

2.2 混合精度与梯度缩放：训练优化的第一层地基

混合精度是性价比最高的第一步。简单说就是前向计算和梯度存储用FP16或BF16，但优化器状态和主权重保留FP32，避免数值不稳定。FP16的精度范围比较窄，训练时很容易出现梯度下溢，所以需要loss scaling——把loss放大若干倍再反向传播，让梯度落入FP16能表达的范围内，更新完再缩小回去。

如果硬件支持BF16，我通常优先选BF16。BF16的指数范围和FP32一样，动态范围大，基本不需要loss scaling，训练稳定性好很多。缺点是尾数精度低，个别任务需要配合“主权重保持FP32”来补偿。实际操作上，不要一开始就裸跑FP16，先打开现成框架里的自动混合精度模块，观察训练loss曲线和每一层的梯度范数。如果发现某些层梯度特别小，多半是缩放因子没调好，再针对性修改。

混合精度之后，如果显存还是紧张，下一步就进入更激进的显存优化手段。

2.3 重计算、优化器状态分片与注意力分块：显存优化三板斧

显存优化在工程上最常用的三招：重计算、优化器状态分片、注意力分块计算。

重计算也叫激活重计算，思路很简单：前向传播时不全量保留激活值，只保留若干关键节点；反向传播需要用到中间结果时，再重新做一遍前向计算把它算出来。这是典型的“以时间换显存”，显存峰值通常能降低30%到50%，训练时间增加20%左右。在模型特别大、batch size起不来的时候，这是保住吞吐的首选。

优化器状态分片是另一条路线。它的核心洞察是：优化器状态在多卡之间是重复存放的，每个GPU都存了一份完整的Adam状态，完全没必要。于是把优化器状态切分成多份，每张卡只维护自己负责的那部分，通信时再做一个全量聚合。这个思路后来被整理成分布式训练的若干阶段：第一阶段只分片优化器状态，第二阶段连梯度也分片，第三阶段连模型参数也分片。分片越彻底，单卡显存压力越小，但对通信调度要求越高。

注意力分块计算则是从算子层面省显存。标准注意力需要构建一个完整的“注意力分数矩阵”，序列越长，这个矩阵越大。分块计算的思路是：不一次性算出完整矩阵，而是把查询、键、值切成块，分块计算并累积最终结果，过程中不需要保存完整矩阵。这在长序列训练里收益极其明显，同时也顺带降低了内存访问量，训练速度反而能提升。业界一般称之为Flash Attention思路，如今已经是长上下文训练的事实标准。

2.4 分布式并行策略怎么选：数据并行、流水线并行、张量并行

单卡显存终究有限，多卡并行是绕不开的。但并行不是把模型往外一放就行，选错策略，通信开销会吃掉所有收益。

数据并行最直观：每张卡都放一份完整模型，分别吃不同batch的数据，算完梯度再同步。优点是实现简单、扩展性好；缺点是每张卡都要放完整模型，显存瓶颈没有解决。对大模型而言，数据并行通常要搭配优化器状态分片一起用，否则还是放不下。

张量并行是把一层的权重矩阵切到多张卡上，每张卡算一部分，最后拼接结果。这种方式能压单层显存，适合超大单层、卡间通信带宽很高的场景。但它每一步都涉及大量通信，对卡间互联非常敏感，一般只在模型大到单卡放不下时使用。

流水线并行则是按层切分：第0到10层放卡0，11到20层放卡1，数据像流水线一样在卡间传递。它通信频率比张量并行低，但会引入“流水线气泡”——某些卡在等上游计算完成时处于空闲状态。通过把batch再切分为多个微批次，可以有效填充气泡，提升利用率。

我的选择经验大致是：30B以下的模型，优先用数据并行加优化器状态分片，简单稳定；更大模型再考虑张量并行和流水线并行。并行策略没有绝对最优，完全取决于模型规模、卡的数量以及卡间拓扑。小规模集群强行用张量并行，很可能因为通信瓶颈导致加速比极差。

2.5 MoE与长序列训练的几个实战细节

在训练侧，还有两个容易踩坑的进阶场景：MoE模型和长序列训练。

MoE（混合专家）把原本稠密的前馈网络替换成多个专家子网络，每次只激活其中一部分。好处是参数量可以做得很大，但计算量不会线性膨胀。实际操作中最大的坑是“专家不均衡”：少数几个专家被频繁激活，绝大多数专家长期闲置，模型退化成一个只有少数专家在干活的小模型。解决思路是在损失函数里加负载均衡项，鼓励路由分配更均匀，同时定期观察每个专家的token分配占比，判断是否需要调整路由的缩放系数或top-k数量。

长序列训练则完全围绕“减少中间张量”展开。序列越长，注意力矩阵越容易爆炸，激活值占用的显存也越大。除了用注意力分块计算之外，还需要在序列维度上做并行切分，让不同设备处理不同段，再做注意力结果的拼接和同步。训练时注意选择合适的位置编码，同时把重计算范围细化到每个Transformer层，按需开启，避免对整个模型笼统地开重计算，造成不必要的性能损耗。

3. 推理侧优化：让模型跑得快、跑得省、跑得稳

训练阶段的模型要上线，推理侧优化才是直接面对用户的关卡。推理时没有梯度、没有优化器状态，按理说显存压力应该小很多，但自回归生成会带来一个新的显存消耗主力——KV Cache。如果不做优化，即使模型不大，长上下文并发场景也能把显存迅速吃光。

推理优化的评价标准也变了：不再只看训练收敛速度，而是看首字延迟、每个token的输出速度、并发吞吐、显存占用这四个核心指标。下面的技术点基本都是围绕这些指标展开的。

3.1 KV Cache：推理时真正吃显存的东西

大模型生成是逐token进行的，每生成一个新token，都要基于之前所有token的Key和Value重新计算注意力。为了避免每一步都重复计算历史token的K和V，推理引擎会把它们缓存下来，这就是KV Cache。

KV Cache的显存占用可以用这个公式估算：

层数 × 注意力头数 × 头维度 × 2 × 当前序列长度 × 字节数

其中乘2是因为Key和Value各一份。以一个常见的7B模型配置为例，单层多头的KV参数数量并不小，序列长度达到4096时，单条请求的KV Cache可能达到几百MB。并发请求一多，这部分显存立刻变成主要压力。

优化KV Cache有几个方向。一是减少单token所需缓存的字节数，例如对KV Cache做量化，从FP16降到INT8；二是从模型结构上减少KV头数量，GQA（分组查询注意力）就是让多个查询头共享一组Key和Value，显著压缩缓存占用；三是在服务端做缓存管理，比如分页式缓存，把连续显存拆成固定大小的块，按需分配，提高利用率。这三个方向不冲突，生产环境一般会叠加使用。

3.2 量化推理：从FP16到INT8/INT4的取舍

量化是推理侧性价比最高的手段之一。核心思想是用更少的比特数表示权重，从而降低显存占用、减少带宽消耗，推理速度随之提升。

训练后量化（PTQ）是最省事的路线，用少量校准数据统计权重分布，然后转成INT8或INT4。实现快，但精度损失需要验证。量化感知训练（QAT）在训练阶段就模拟量化误差，精度更稳，代价是要重新训练或微调，耗时明显。

针对大模型，工程上还有一些更精细的量化方法：有的基于二阶信息逐层搜索量化参数，以最小化层输出误差；有的关注激活值的离群点，对少量显著通道做缩放保护；还有的通过数学变换把激活值中的尖峰“转移”到权重上，让模型更适合低精度计算。它们的共同点都是不搞全局一刀切，而是针对不同层、不同通道做差异化处理。

实操建议：先准备一组能代表线上数据分布的校准样本，不要随便拿几条测试文本凑数。做完量化后，要在验证集上对比量化前后的输出差异，尤其是生成类任务的“语义连贯性”。如果掉点严重，优先检查哪些层对量化最敏感，把这些层单独保留FP16，也就是做混合精度量化，往往比整体降比特更有效。

3.3 连续批处理与投机采样：吞吐翻倍的秘密

推理服务的吞吐瓶颈，很大程度上来自批处理方式的落后。传统批处理要等一个batch里所有请求都生成完才一起释放，但请求长度参差不齐，短的早就结束了，还要等长的跑完，GPU白白空等。连续批处理把调度粒度从“请求级别”降到“迭代级别”：每次前向计算后，检查哪些请求的生成已完成，立刻回收显存并插入新的请求。这样GPU始终在处理有效更新，吞吐能提升好几倍。

投机采样则针对“串行解码太慢”的问题。大模型生成需要一个个token，但GPU本来可以并行算多个位置，串行解码完全没吃到算力红利。投机采样的思路是：先用一个更快的小模型草稿多个token，再让大模型一次性验证这些token，如果和预期一致就直接接受。理想情况下，一次验证能接受三到五个token，解码延迟大幅下降。严格说这不是无损方案，验证失败时要回退，但工程收益通常非常可观。

这两个技巧并不互斥，现代推理服务框架一般都能同时启用，组合之后单卡吞吐和响应延迟都有明显改善。

3.4 工程侧优化：显存规划与运行时监控

推理侧的坑，很多不是出在模型本身，而是出在工程配置上。比如显存预分配不够，动态分配碎片化，某个长请求突然把显存打满，整个服务OOM。我上线前会做一轮显存规划：模型权重占多少，量化后KV Cache上限多少，预留多大buffer给临时张量，再按最大并发数反推需要多少显存。

运行时监控也不能少。我习惯每10秒记录一次显存占用、请求队列长度、TTFT和生成吞吐。TTFT是首字延迟，用户点完发送到看到第一个字的时间，决定了“响应感”；生成吞吐则决定整段回答的等待时间。两类指标要分开监控，不要混在一起看平均值，否则首字延迟的抖动很容易被吞没。

一旦出现显存接近上限，立刻触发限流或排队策略，宁愿让新请求等一等，也不能把正在服务的请求杀掉。生产环境的稳定性优先级永远高于极限吞吐。

4. 模型压缩与轻量化：蒸馏、剪枝和低秩分解

除了优化训练和推理过程，还可以直接对模型本身做“瘦身”。这部分属于模型压缩范畴，包括剪枝、蒸馏和低秩分解，目的都是让模型更小、更快，同时尽量保住效果。

这一节的技术比前面的量化更偏“结构性”，需要动手改变模型的权重或架构，因此风险也更高。每一步都需要配合评估和微调，不能只看参数量降下来就结束。

4.1 剪枝：结构化裁剪与稀疏化

剪枝的思路是去掉权重中“不那么重要”的部分。非结构化剪枝直接把一个个权重置零，得到稀疏矩阵，压缩率很高，但绝大多数现有硬件不支持稀疏矩阵加速，实际推理速度反而不一定变快。结构化剪枝则是直接移除完整的注意力头、前馈层甚至整层，压缩后模型结构更规整，部署时真正能省计算。

实操上，剪枝不是剪完就结束。剪掉的机构一旦移除，模型必然会掉点，需要后续微调恢复。我在模拟项目X里试过几种剪枝目标：剪掉部分注意力头相对温和，模型损失较小；整层删除风险最高，因为深层语义依赖跨层传递，删一层可能导致连贯性崩掉。所以建议从“冗余度最高”的位置下手——比如先统计每层的注意力头对最终输出的影响，影响小的优先剪。

剪枝更适合对已有模型做最后一轮压缩。如果是从零开始做轻量模型，蒸馏通常比剪枝更可控。

4.2 蒸馏：用大模型教小模型

蒸馏的核心是让小模型模仿大模型的“思考方式”。传统监督学习只学硬标签，蒸馏还要学大模型的输出分布，也就是所谓“软标签”。大模型的输出分布里其实藏着大量信息：哪些候选答案接近、哪些完全不可能，这些信息比单一正确标签丰富得多。

白盒蒸馏能拿到大模型的中间层输出和logits，可以用KL散度让师生分布对齐，效果上限更高。黑盒蒸馏则只通过API调用拿到大模型生成的文本，再用这些数据训练小模型，适合无法接触模型权重的情况。我在实际项目里两种都用过：有权限时用白盒蒸馏微调一个小模型做初筛，没有权限时用黑盒蒸馏生成一批领域问答数据，再用来训练专用模型。

蒸馏的效果和师生差距直接相关。老师太大、学生太小，蒸馏出的模型容易“学不动”；老师和学生结构差距太大，中间层对齐也很难有意义。通常学生模型能达到老师模型80%-95%的效果，但推理成本能降到三分之一以下，这个交换在很多业务场景里非常划算。

4.3 低秩分解与LoRA微调的关系

低秩分解的出发点是一个假设：权重矩阵的有效信息其实集中在一个较低维度的子空间里，所以可以用两个小矩阵近似一个大矩阵。大矩阵是 n×n，低秩近似变成 n×r 和 r×n，r远小于n时参数总量显著下降。

但在推理侧直接对预训练模型做低秩分解，效果并不稳定。一个原因是训练好的权重里，高秩分量虽然小，却可能承担关键的语义功能，强行截断会破坏表达。所以工程上更常见的是把低秩思想用在微调阶段，也就是LoRA。

LoRA在微调时冻结原始权重，只训练两个低秩增量矩阵。原始权重不参与梯度更新，显存和算力需求大幅降低。推理时，这两个低秩矩阵可以合并回原始权重里，完全不需要额外计算路径。更妙的是，LoRA可以和量化搭配使用：模型先量化成低精度，推理时再把LoRA增量以FP16合并回来，精度恢复和显存节省可以兼得。模拟项目X最终方案就是“INT4量化权重 + LoRA增量合并”，效果接近全精度微调，显存占用却低了一个量级。

5. 服务化部署与框架选型：从离线评估到在线服务

训练、推理、压缩都做完，最后一步才是把模型变成真正可用的在线服务。这一步最容易被轻视，因为离线评估再漂亮，部署时接不住并发一样白搭。框架选型直接决定你能吃满多少性能，也决定了后续运维是省心还是痛苦。

选型不能只盯着测评榜单上的跑分，要结合自己的业务场景。下面是我梳理的三个方向，各有取舍。

5.1 推理框架选型与性能对比

主流的部署方案大致分三类：第一类是通用深度学习框架加手动优化，灵活度最高，适合研究原型和自定义算子，但工程量大，并发调度、显存管理都得自己处理；第二类是专门的推理服务框架，通常内置连续批处理、分页缓存、量化算子，上手快，稳定性好，适合大多数在线服务场景；第三类是结合专用硬件加速库做极致优化，性能天花板最高，但对硬件环境有强依赖，可移植性差。

选型时我会额外看几个点：是否原生支持我要用的量化格式，KV Cache的调度方式是否高效，是否支持流式输出，以及社区维护是否活跃。一个长期没人维护的框架，即使当下性能好看，风险也很大。总体来说，如果不是有特殊需求，建议优先选成熟的专用推理服务框架，自己能省掉一半的运维工作量。

5.2 并发、吞吐量与延迟指标的工程含义

线下单次请求测出来的延迟，和线上并发环境下的表现是完全两回事。并发一高，设备争抢、排队等待都会让延迟急剧恶化。工程师需要同时盯住两类指标：延迟类指标和吞吐类指标。

延迟指标重点关注TTFT和TPOT。TTFT是首字延迟，用户发出请求后多久看到第一个字，直接影响交互体感；TPOT是每个输出token的平均生成时间，决定整段回答的“流畅感”。吞吐指标则包括单卡每秒生成token数、每秒处理请求数，体现系统整体的服务能力。

优化时要避免只追一个指标。盲目压榨单卡吞吐，可能导致请求排队严重，TTFT飙升；只追低延迟，又会浪费GPU算力，成本居高不下。我通常先用压测工具模拟线上请求分布，画出“吞吐-延迟曲线”，在曲线上找到拐点，把服务的最大并发数控制在拐点附近，兼顾体验和成本。

5.3 一个7B模型的部署实例：从离线评估到在线服务

模拟项目X最后选择了7B规模的模型，配合INT4量化和LoRA微调后的效果，单卡部署。部署时先做了一轮显存规划：量化权重大约占7-8GB，KV Cache按最大并发和最大序列长度预分配8GB，剩下给临时张量留余量。通过连续批处理把请求调度起来，实测并发32路时，单卡吞吐约为800-1000 tokens/s，TTFT基本稳定在0.3-0.8秒之间。

这个配置能撑住业务峰值，同时成本可控。相比没优化时动不动显存溢出、响应超时，整个系统稳定了很多。部署过程中我最大的体会是：上线前一定要做一次基于真实流量的压测，至少跑30分钟以上，观察显存增长曲线、GC频率和CPU/GPU利用率，而不是测几条短文本就宣布“可以上线”。

6. 常见问题与排障笔记（踩坑实录）

最后整理一下我在这个项目里遇到并解决的典型问题。这些问题在网上零零散散都能搜到，但往往只有结论没有排查过程。我把思路写清楚，方便你遇到类似情况时少走弯路。

6.1 量化掉点严重怎么办

量化后效果明显变差，不要第一时间怀疑量化方法本身。先检查三件事：校准数据是否覆盖线上真实分布；模型里是否有某些层对量化特别敏感；权重分布里是否大量存在离群值。

我遇到过一次校准数据用的是新闻文本，线上却全是技术文档，量化后生造出不少专业名词的错误变体。解决办法是换了一套线上日志数据重新做校准，掉点立刻回落。另外，混合精度量化是一个很实用的备用方案：把对量化敏感的头和前馈层保留高精度，其余压到INT8或INT4，精度和收益能平衡得更好。

6.2 长序列生成时显存快速上涨怎么办

长文本生成时显存持续上涨，大概率是KV Cache在累积。排查时先看当前请求允许的最大序列长度是多少，再看服务端有没有限流和排队策略。实际项目中，经常是某个用户输入了一段超长文档，模型拼命生成，KV Cache直接涨到失控。

工程上的对策有三个：限制max_tokens，从源头控制生成长度；采用流式输出，生成完一段就释放对应缓存；对于超长文本，先做分块摘要再拼接，而不是让模型一次性处理全文。还有一个容易被忽略的点：给KV Cache做预分配。动态分配显存的碎片化问题很严重，预分配一块连续显存池，能显著降低分配开销。

6.3 分布式训练时通信瓶颈卡死

多卡训练时GPU利用率很低，但“等待IO”占比极高，大概率是卡间通信成了瓶颈。尤其在使用张量并行的场景，每一步都涉及全量同步，通信对网络带宽和拓扑极其敏感。

解决方法按优先级排列：第一，开启通信与计算重叠，让GPU在等待通信的同时继续做计算；第二，增大梯度累积步数，减少同步频率；第三，考虑梯度压缩或更高效的分片通信策略。另外一定要确认卡间物理互联方式，如果是低带宽网络，不要强行上大模型分布式训练，先把数据并行规模缩小，或者换成模型规模更小的方案，更现实一些。

6.4 一些实用小技巧

• 模型加载时不要一次性把所有权重读进内存，用懒加载或分片加载，能大幅降低冷启动OOM概率。
• 断点续训时，把优化器状态和模型权重分开保存，既能减小存储体积，也能避免某一方损坏导致整个检查点不可用。
• 推理服务上线前，必须做预热，让相关算子和显存分配先运行一遍，否则第一个线上请求会异常慢。
• 做优化对比实验时，固定随机种子和输入数据，否则实验结果很难复现，也无法判断优化手段是否真的有效。

我个人在实际操作中的体会是：大模型优化没有银弹，所有方案都是权衡后的结果。最靠谱的做法不是把所有先进技术一把梭，而是先建好基线、选好监控、小步验证，每次只引入一个变量，这样出问题时能快速定位。如果你正在被显存溢出、响应延迟或并发上不去的难题折磨，建议从量化、KV Cache、连续批处理这三个改动小、收益大的方向入手，先把系统稳定住，再做更深入的结构性优化。