我在一线折腾AI模型推理也有几年了从最早用PyTorch直接写demo到后来负责把模型压到毫秒级响应这个过程中踩过的坑、翻过的车足够写一本小册子。今天想聊的是围绕“AI模型推理延迟优化的工程思路”展开的一些实操经验核心不是给你罗列一堆优化名词而是把延迟优化这件事真正拆开看透搞明白每一步该怎么选、为什么这么选、实际会碰到什么问题。先定义一下到底什么叫推理延迟。它不是单一数值从客户端角度看是发一个请求到收到完整响应的时间从工程层面拆它包含排队时间、网络传输、模型prefill计算、逐token生成、后处理序列化每一段都可能是瓶颈。我们平时说的“优化延迟”大多数场景其实是针对服务端模型计算部分但真正上线后你会发现模型推理只占整个链路的一部分网络开销、GPU利用率、调度策略往往更致命。这篇文章适合谁看一是刚接触推理加速、准备做模型部署的算法工程师二是负责推理服务架构、正在为接口延迟指标发愁的后端同学三是对大模型落地成本敏感、想把GPU用得更狠的团队负责人。你会看到一套从诊断、建模到优化、验证的完整方法里面的思路和工具我已经在多套系统里反复验证过拿过来就能直接用。1. 推理延迟的构成与诊断逻辑1.1 先把延迟拆开一次完整请求的时间都去哪了很多新手一上来就盯着模型本身调算子这是误区。我在一个文本生成服务里遇到过一个问题模型单次推理已经从50毫秒压到了35毫秒但接口P99延迟依然高达2秒。后来一查发现请求在网关排队等了1.6秒模型那几十毫秒根本无关痛痒。延迟优化的第一步永远是画像。一次请求的全链路大致包含这么几段网络传输客户端到网关、网关到推理节点的RTT队列等待请求进入服务后在队列里排队的时间受并发数和调度策略影响输入预处理tokenize、拼装prompt、padding模型计算prefill阶段处理输入序列加decode阶段逐个生成token输出后处理detokenize、过滤、采样结果整理响应回传模型计算内部又分为prefill和decode两个阶段。prefill是并行计算输入序列的attention计算量大但不涉及串行依赖decode是一个token一个token往外蹦每一步都依赖上一步的结果GPU利用率天然偏低。这两段的时间优化手段完全不同prefill看的是计算吞吐decode看的是访存效率。我建议每接到一个延迟优化需求先在服务端起一个profile中间件把上述每一段的时间打点记下来至少跑一周生产流量然后再动手调。很多人省了这一步结果优化方向全是靠猜。1.2 如何准确判断瓶颈在计算还是在调度判断瓶颈有一个很简单实用的方法看GPU利用率和服务吞吐的曲线关系。如果GPU利用率已经90%以上但延迟依然高那就是模型计算本身太慢该去优化算子和显存访问。如果GPU利用率只有40%延迟却很高说明任务没喂饱GPU瓶颈在调度、并发、批处理策略上。如果GPU利用率波动剧烈一会99%一会20%大概率是请求到达不均匀导致排队要考虑动态batch或扩容策略。专业工具层面我常用的组合是服务端整体打点记录从请求进入到响应完成的全程耗时在中间件里加时间戳GPU侧profile采集kernel执行时间、显存占用、SM利用率定位具体算子热点框架内置profilerPyTorch自带的profiler可以逐算子输出耗时TensorRT也有对应的工具用这些工具跑一轮之后延迟瓶颈的分布基本就清楚了。这里有个常见误区很多人喜欢把延迟平均值作为优化目标我建议一律改成P95/P99优化。平均延迟被少数慢请求拖低的可视性不够P99才是用户体验的真实感受优化时要盯着长尾样本一个一个追。1.3 延迟优化的核心指标首token延迟与token间延迟如果做的生成式模型还要区分两个关键指标首token时延TTFT从请求发出到收到第一个token的时间主要受prefill阶段影响每token时延TPOT相邻两个token的生成间隔主要受decode阶段影响这两个指标加起来基本决定了用户感知的“快慢”。交互式聊天场景TTFT要尽量压到1秒内TPOT要低于100毫秒用户才会有“流畅对话”的感觉。离线批量任务则相反更看重吞吐对TPOT的敏感度低。针对TTFT的优化主力是模型侧量化、算子融合、小batch下的计算缩减。针对TPOT则更多要靠KV Cache优化、连续批处理、speculative decoding这些调度和存储层面的手段。实际项目里两者往往是同一个优化动作交叉受益但你在设定目标时要分开盯防止优化完TTFT降了TPOT反而恶化。2. 模型层面的硬核优化手段2.1 量化INT8、FP8、INT4到底怎么选量化是推理加速里性价比最高的一招原理很简单模型权重和激活值从FP16/FP32降到更低精度计算变快、显存减半甚至更多延迟自然下降。选哪种精度不是越低越好而是看你模型敏感度和硬件支持。我做过的几个项目经验INT8对绝大多数模型损失极小几乎是无损替换。如果硬件支持INT8 Tensor Core推理速度能提升1.5到2倍。这是最稳妥的起点。FP8在H系列GPU上支持较好精度比INT8更好控尤其适合训练后推理一体化的场景。精度损失可忽略速度收益略逊于INT8。INT4显存缩减最猛能把几十B模型塞进一张卡但精度风险明显。需要在量化后做充分评测尤其对数学推理、多步推理类任务可能会掉点明显。按我的经验落地顺序建议是先做INT8跑通流程看延迟收益如果还嫌不够再对特定层做INT4混合量化。不要一上来就追求极致压缩否则返工成本很高。权重量化有两种主流方法一种是在训练后直接做PTQ后训练量化用一小批校准数据统计激活分布设好scale和zero point就行。这种方法部署最快大多数场景精度可控。另一种是QAT量化感知训练在训练时模拟量化误差让模型适配精度更好但需要准备训练流程和额外的训练时间一般只有在PTQ效果不达标时我才上。激活值量化比权重更麻烦因为激活分布是动态变化的尤其大模型套上attention之后数值范围可能漂移很大。所以主流框架里常用per-token和per-channel混合策略按行或按列独立设scale避免一个离群值毁掉整个张量的量化精度。这块没有统一参数需要在你模型上反复试验。2.2 结构化剪枝与稀疏化卡在“精度恢复”这一关剪枝是把模型里贡献小的权重或结构去掉减少计算量。但大模型时代纯靠剪枝做延迟优化我持保留态度因为剪完精度掉得厉害恢复成本又高。真正在工程里有价值的是半结构化稀疏和2:4稀疏模式。某些新卡对2:4稀疏有硬件加速可以做到接近2倍的计算密度提升。做法是把权重矩阵中每4个元素强制干掉2个配合重训练把精度拉回来。我实际试下来如果模型本身已经很大直接训练时剪枝比训练后剪枝效果好得多。训练后剪枝对数学推理这类强逻辑任务的破坏尤其明显除非你对精度损失有预算否则建议优先量化剪枝作为叠加手段而非首选。还有一种更温和的做法是通道裁剪把模型中冗余的attention头或FFN维度切掉。判断哪些头冗余可以看它们在验证集上的贡献度或者直接看attention输出的方差方差低说明这个头输出稳定不变剪掉影响有限。这种方式比粒度剪枝对精度影响小对延迟的帮助主要在显存带宽层面。做个简单的加法量化管权重剪枝管结构二者叠加理论上能把延迟压到FP16的1/4左右但精度验证要做得非常细致。2.3 蒸馏用“小模型”换延迟的最优解蒸馏的思路一句话讲完让一个大教师模型教会一个小学生模型学生学会后体积小、推理快。做延迟优化时蒸馏和量化剪枝不冲突它们是同一道菜的两味料。我自己在某个分类项目里把一个4亿参数的模型蒸馏到1亿参数精度只掉了不到1个百分点延迟从12毫秒降到3毫秒这个收益是纯工程优化很难达到的。蒸馏的常见形式有三种离线蒸馏先用大模型在大量样本上生成logits再用这些软标签训练小模型效果最稳但成本高在线蒸馏教师和学生同步训练学生实时从教师拿指导信号省去二次标注成本适合快速迭代自蒸馏用一个模型自身不同深度的输出来互教省去训练大教师模型的成本蒸馏的难点不在训练方法而在数据准备。蒸馏要的不是标注对错而是大模型的“知识分布”。同一个问题大模型给出的答案分布带有很多细微偏置信息学生要把这些信息学进去才能接近教师的能力。数据要覆盖多样场景、边角情况否则学生只会对见过的样本“死记硬背”。我把蒸馏排在最后说是因为它的周期最长通常要重新训练模型。如果你要改的是已经上线的旧模型且线上数据敏感那蒸馏的前置评估成本会比较高。但如果你做的是新模型部署从一开始就规划蒸馏路线效果和成本都最划算。3. 工程落地推理框架与调度优化实战3.1 主流推理引擎怎么选从简单到极限性能模型层的优化做完就要看工程侧了。现在的推理框架已经非常成熟自己手写CUDA算子来加速不是不行但性价比太低。我推荐的选型路径是这样性能要求不高、求快上线直接用原生PyTorch加半精度推理适合demo和内部工具生产环境、通用场景用开源推理框架体验过几款之后我推荐把vLLM或TensorRT-LLM作为优先尝试项它们在连续批处理和缓存利用上做得非常成熟极致性能、定制需求基于TensorRT手动搭推理图逐层优化算子适合对延迟敏感且模型结构稳定的场景各家的底层都默认打开了算子融合、显存复用、CUDA Graph等优化。以CUDA Graph为例传统PyTorch执行是逐kernel启动每个kernel都有启动开销GPU在kernel切换时会出现空闲。CUDA Graph把一个推理过程的所有kernel捕获成一个图一次启动、整体执行省掉了海量的启动开销。我实测过在短序列场景下这项技术能给单次推理带来30%以上的延迟下降。选型时有两个重要的参考维度你的模型是否被该框架官方支持并有针对性优化比如近几年大火的那些开源模型主流框架都做了专门适配性能差异不大你的请求模式是单条低频还是高并发流式这决定了连续批处理的收益是否明显3.2 批处理策略吞吐和延迟的跷跷板如果模型服务的是一次一条请求每请求独占GPU资源那GPU利用率和延迟表现都不好看。正确做法是引入批处理把多个请求拼在一起计算GPU的算力才能喂饱。但批处理不等于简单地把请求攒起来。传统静态batching要求同一批次的请求长度一致长度不一就得padding而padding很大的短序列会浪费大量计算长序列比例高时收益不升反降。业界主流的解法是连续批处理也就是待一个请求的生成步骤完成后立刻插入一个新请求继续跑不需要等整批结束。这个机制能让GPU一直有活干利用率能维持在85%以上。连续批处理对长序列尤其友好因为每个请求在不同生成阶段可以交错运行GPU资源的使用是动态分配的。这背后有两个关键技术点PagedAttention机制仿照操作系统的虚拟内存用分页方式管理KV Cache避免显存浪费从而提高可同时处理的请求数动态调度器每个迭代步都重新决定哪些请求进入计算谁生成完毕就腾出位置给新请求实际配置连续批处理时需要调的两个关键参数是最大批大小和最大等待时长。批大小不是越大越好要看你GPU显存和模型大小等待时长控制请求在队列里攒批的时间设太大会增加延迟设太小则批不齐。经验上先从等待20毫秒、批大小按显存余量推算起步再根据线上P99延迟微调。3.3 KV Cache优化与显存治理增加并发的前置条件解码阶段的推理需要把历史token的键值缓存起来这个缓存叫KV Cache。它的大小跟序列长度、层数、注意力头数线性相关跑长上下文时能把显存吃成无底洞。KV Cache优化直接影响并发度和延迟。最常见的四种手段用更小的数据类型保存键值比如把FP16降为FP8显存直接减半用PagedAttention式分页管理解决显存碎片和“预分配过大”问题加前缀缓存比如系统提示词或公共对话历史多个请求共用一份避免重复计算对不再需要的序列及时释放防止僵尸请求占用显存我做的一个模拟项目X里在没做任何模型层优化前仅把KV Cache从FP16切到FP8同时引入前缀缓存同样一批请求的并发数从32提到了80P99延迟反而降了40%。原因很简单之前显存不够导致频繁换入换出算力都在等待显存搬运现在显存宽裕了GPU能够连续计算。另外一个容易被忽略的点是请求长度。长上下文请求会占用大量KV Cache尤其在做共享缓存时一个长请求可能挤掉几十个短请求的资源。我建议在入口处根据请求长度做分级队列分配不同的显存配额避免长请求拖垮整体延迟。3.4 并发模式与多副本从单机到分布式的性能边界当单台GPU的算力和显存都压满后还要继续降延迟就只能靠横向扩展了。最常见的架构是推理服务前面架一层负载均衡后面挂多个推理副本每个副本处理一部分请求。这样可以把并发压力分散到多张卡上单卡负载降下来平均延迟自然跟着降。这里有一个关键决策你要的是单纯扩容还是做模型并行。如果模型能塞进单卡只是请求量大那多副本加负载均衡就够了部署简单容灾也好做如果模型太大塞不进单张卡就需要把模型切到多卡上并行比如张量并行或流水线并行模型并行的代价是通信开销。张量并行每层计算都需要多卡同步通信量巨大通常要求卡间用NVLink连接否则通信时间比计算时间还长。流水线并行则把模型按层切分到不同卡上卡之间只传激活值通信量小但存在流水线气泡利用率有天然上限。我的建议是不到万不得已不要上模型并行。优先走量化、蒸馏把模型压到单卡再用多副本扩展吞吐和延迟。多副本架构要留意的就是每个副本的实例数和请求队列避免负载均衡层成为新瓶颈。4. 推理延迟优化的完整流程参考4.1 从延迟指标到优化方案一张路线图把前面说过的内容收拢成一套可复制的落地流程大致是七个步骤建立全链路延迟画像确定瓶颈在模型计算、调度还是网络设定延迟目标分别定TTFT、TPOT、P99数值模型层优先做量化和算子融合验证精度与速度如果模型太大评估蒸馏或剪枝把模型瘦身到适合单卡运行引入成熟推理框架开启连续批处理和CUDA Graph等机制优化KV Cache与显存管理提升并发能力负载均衡与多副本扩展解决单节点瓶颈这个路线图的价值在于把优化动作按风险从低到高排了序。量化和框架配置属于低风险高收益上来就做蒸馏和剪枝属于高成本动作只在前面步骤做完还达不到目标时才考虑。4.2 一个实际案例2秒延迟降到300毫秒是怎么做到的模拟项目X是一个文本生成服务初始环境是PyTorch半精度直接部署在单卡上模型大约7B参数接口延迟P99稳定在2秒左右用户体验很一般。优化过程按路线图逐步展开第一步打点画像发现模型计算占1.2秒队列等待占0.6秒网络和后处理占0.2秒。第二步模型切到INT8量化精度评测掉点约0.3%可接受prefill部分延迟从700毫秒降到450毫秒decode部分从500毫秒降到350毫秒。第三步换用推理框架开启CUDA Graph和连续批处理decode延迟进一步降到200毫秒同时GPU利用率从35%跳到80%以上。第四步KV Cache切FP8并做前缀缓存同并发下显存占用降了一半队列积压明显改善排队时间从600毫秒降到100毫秒。第四步做完整体P99从2秒降到了700毫秒左右。第五步上多副本负载均衡把P99压到300毫秒。这个案例里每一步的动作都不复杂核心是靠画像把有限的优化资源投在了正确的位置。我见过很多项目就是不画像直接上量化结果量化完瓶颈还在调度上白白浪费了精度预算。4.3 验证与回归优化完要盯的指标不只是延迟延迟优化做完要做的验证不能只看“是不是快了”。我建议至少做这四组回归精度回归量化、剪枝、蒸馏后模型在评测集上的指标是否落在合同允许范围内稳定性回归长时间压测下P99是否漂移有没有周期性波动并发回归不同并发数下的延迟曲线确认吞吐提升没有以延迟恶化为代价长尾回归专门构造超长输入、超大输出等极端案例观察是否有延迟尖刺其中精度回归很多人会偷懒只跑一两个指标就上线。量化对某些隐形任务的影响普通指标看不出来要故意构造边界case试比如数学题、多步推理、指令遵循类任务。延迟优化的终点不是把测试集跑完而是线上持续可观测。我建议在服务里长期保留延迟画像打点按日/周聚合TTFT、TPOT、P99和GPU利用率设好告警任何一次模型更新或框架升级都先跑一遍回归再灰度放量。5. 高频问题与避坑心得5.1 为什么量化后速度不升反降比较常见的情况是模型小、序列短计算量本身不大量化省下的计算时间被反序列化和反量化开销抵消了。遇到这种情况建议先用量化后的推理基准对比FP16跑不同batch和序列长度组合看收益出现在哪个区间。只要在业务典型负载下没有收益就不要为量化而量化。还有一种情况是选错了量化精度。INT4虽然显存优势大但GPU原生支持的Tensor Core指令集如果对INT4不友好速度反而肩比INT8。配套的PTQ校准数据要贴近真实分布我第一次做量化时拿纯文本数据校准上线后遇到大量代码样本激活分布漂移严重导致生成质量明显下降。5.2 延迟抖动严重P99不稳定延迟平均值低但P99忽高忽低最常见的三个原因显存碎片化长期运行后KV Cache分配不连续导致访存局部性差。解法是定期清理或使用支持分页管理的框架抢占式调度某个大请求占住GPU算力其他小请求排队等待。解法是按请求大小分流到不同队列JIT编译抖动某些算子首次调用时触发动态编译占用几毫秒到几十毫秒。解法是提前warmup把Graph或编译好的kernel预加载我处理过的一个线上事故就是显存碎片导致的P99翻倍。重启进程后恢复正常但过几天又复发。后来改成启动时预分配大块缓存并把KV Cache统一走分页管理才根治。5.3 并发上去了延迟反而变差并发和延迟的关系不是单调的。不同batch大小下推理延迟呈U型曲线batch太小浪费算力batch太大时单个请求的平均延迟被拖高。要找到那个平衡点最靠谱的方式是压测。压测时要分两个维度记录一是固定输入长度下不同并发数的吞吐和P99延迟二是固定并发下不同输入长度组合的延迟分布。别在高并发下只看平均值那会掩盖个别超长请求的惨烈表现。上线前我还习惯做一次“削峰演练”模拟流量突刺场景观察自动扩容或队列溢出的表现。很多系统平时测试都是匀速流量遇到真实业务的脉冲流量就露馅。5.4 显存不够导致OOM怎么办OOM是推理服务最常见的稳定性问题。我的排查顺序是先看模型权重占了多大激活值预留了多少KV Cache又占了多少再查是不是有请求的序列特别长被某个极端case打爆最后看显存碎片率是不是长时间运行后碎片越来越多针对每一步都有对应的解法权重层可以切更低的量化激活值可以开显存复用或梯度检查点KV Cache可以走分页加长度限额碎片可以定时做显存整理或做进程重启策略。如果真的遇到单卡物理显存上限再考虑上多卡并行这是兜底方案不是首选。5.5 模型更新后延迟表现变了模型更新后延迟波动通常不是计算量变化而是权重分布变化导致量化scale不再匹配。这种情况下原量化配置会失效精度和延迟都会劣化。我会定一条规矩模型结构或权重有更新必须重跑量化校准和延迟回归。如果在框架层做了算子融合模型结构变了融合模式也要重新评估。之前某个项目替换了激活函数融合kernel没跟着换延迟从优化后的8毫秒反弹到20毫秒排查了大半天才定位到。6. 最后补一句个人经验AI推理延迟优化是一个系统性工程不是单一技术点能解决的。我经手的项目里凡是成功把延迟压下来的共同特点都是先画像、再分层、小步迭代、每步验证。凡是失败的几乎都是跳过画像直接上重手段或者只盯着某个技术点死磕忽略了链路里的其他瓶颈。做这一行经验固然重要但方法论和流程感才是保证每一版都能稳定收敛的关键。如果只让我留一个小技巧那就是所有优化动作上线前都做成开关A/B跑三天再决定去留。省下的不是延迟是无数个线上事故。 我在一线折腾AI模型推理也有几年了从最早用PyTorch直接写demo到后来负责把模型压到毫秒级响应这个过程中踩过的坑、翻过的车足够写一本小册子。今天想聊的是围绕“AI模型推理延迟优化的工程思路”展开的一些实操经验核心不是给你罗列一堆优化名词而是把延迟优化这件事真正拆开看透搞明白每一步该怎么选、为什么这么选、实际会碰到什么问题。先定义一下到底什么叫推理延迟。它不是单一数值从客户端角度看是发一个请求到收到完整响应的时间从工程层面拆它包含排队时间、网络传输、模型prefill计算、逐token生成、后处理序列化每一段都可能是瓶颈。我们平时说的“优化延迟”大多数场景其实是针对服务端模型计算部分但真正上线后你会发现模型推理只占整个链路的一部分网络开销、GPU利用率、调度策略往往更致命。这篇文章适合谁看一是刚接触推理加速、准备做模型部署的算法工程师二是负责推理服务架构、正在为接口延迟指标发愁的后端同学三是对大模型落地成本敏感、想把GPU用得更狠的团队负责人。你会看到一套从诊断、建模到优化、验证的完整方法里面的思路和工具我已经在多套系统里反复验证过拿过来就能直接用。1. 推理延迟的构成与诊断逻辑1.1 先把延迟拆开一次完整请求的时间都去哪了很多新手一上来就盯着模型本身调算子这是误区。我在一个文本生成服务里遇到过一个问题模型单次推理已经从50毫秒压到了35毫秒但接口P99延迟依然高达2秒。后来一查发现请求在网关排队等了1.6秒模型那几十毫秒根本无关痛痒。延迟优化的第一步永远是画像。一次请求的全链路大致包含这么几段网络传输客户端到网关、网关到推理节点的RTT队列等待请求进入服务后在队列里排队的时间受并发数和调度策略影响输入预处理tokenize、拼装prompt、padding模型计算prefill阶段处理输入序列加decode阶段逐个生成token输出后处理detokenize、过滤、采样结果整理响应回传模型计算内部又分为prefill和decode两个阶段。prefill是并行计算输入序列的attention计算量大但不涉及串行依赖decode是一个token一个token往外蹦每一步都依赖上一步的结果GPU利用率天然偏低。这两段的时间优化手段完全不同prefill看的是计算吞吐decode看的是访存效率。我建议每接到一个延迟优化需求先在服务端起一个profile中间件把上述每一段的时间打点记下来至少跑一周生产流量然后再动手调。很多人省了这一步结果优化方向全是靠猜。1.2 如何准确判断瓶颈在计算还是在调度判断瓶颈有一个很简单实用的方法看GPU利用率和服务吞吐的曲线关系。如果GPU利用率已经90%以上但延迟依然高那就是模型计算本身太慢该去优化算子和显存访问。如果GPU利用率只有40%延迟却很高说明任务没喂饱GPU瓶颈在调度、并发、批处理策略上。如果GPU利用率波动剧烈一会99%一会20%大概率是请求到达不均匀导致排队要考虑动态batch或扩容策略。专业工具层面我常用的组合是服务端整体打点记录从请求进入到响应完成的全程耗时在中间件里加时间戳GPU侧profile采集kernel执行时间、显存占用、SM利用率定位具体算子热点框架内置profilerPyTorch自带的profiler可以逐算子输出耗时TensorRT也有对应的工具用这些工具跑一轮之后延迟瓶颈的分布基本就清楚了。这里有个常见误区很多人喜欢把延迟平均值作为优化目标我建议一律改成P95/P99优化。平均延迟被少数慢请求拖低的可视性不够P99才是用户体验的真实感受优化时要盯着长尾样本一个一个追。1.3 延迟优化的核心指标首token延迟与token间延迟如果做的生成式模型还要区分两个关键指标首token时延TTFT从请求发出到收到第一个token的时间主要受prefill阶段影响每token时延TPOT相邻两个token的生成间隔主要受decode阶段影响这两个指标加起来基本决定了用户感知的“快慢”。交互式聊天场景TTFT要尽量压到1秒内TPOT要低于100毫秒用户才会有“流畅对话”的感觉。离线批量任务则相反更看重吞吐对TPOT的敏感度低。针对TTFT的优化主力是模型侧量化、算子融合、小batch下的计算缩减。针对TPOT则更多要靠KV Cache优化、连续批处理、speculative decoding这些调度和存储层面的手段。实际项目里两者往往是同一个优化动作交叉受益但你在设定目标时要分开盯防止优化完TTFT降了TPOT反而恶化。2. 模型层面的硬核优化手段2.1 量化INT8、FP8、INT4到底怎么选量化是推理加速里性价比最高的一招原理很简单模型权重和激活值从FP16/FP32降到更低精度计算变快、显存减半甚至更多延迟自然下降。选哪种精度不是越低越好而是看你模型敏感度和硬件支持。我做过的几个项目经验INT8对绝大多数模型损失极小几乎是无损替换。如果硬件支持INT8 Tensor Core推理速度能提升1.5到2倍。这是最稳妥的起点。FP8在H系列GPU上支持较好精度比INT8更好控尤其适合训练后推理一体化的场景。精度损失可忽略速度收益略逊于INT8。INT4显存缩减最猛能把几十B模型塞进一张卡但精度风险明显。需要在量化后做充分评测尤其对数学推理、多步推理类任务可能会掉点明显。按我的经验落地顺序建议是先做INT8跑通流程看延迟收益如果还嫌不够再对特定层做INT4混合量化。不要一上来就追求极致压缩否则返工成本很高。权重量化有两种主流方法一种是在训练后直接做PTQ后训练量化用一小批校准数据统计激活分布设好scale和zero point就行。这种方法部署最快大多数场景精度可控。另一种是QAT量化感知训练在训练时模拟量化误差让模型适配精度更好但需要准备训练流程和额外的训练时间一般只有在PTQ效果不达标时我才上。激活值量化比权重更麻烦因为激活分布是动态变化的尤其大模型套上attention之后数值范围可能漂移很大。所以主流框架里常用per-token和per-channel混合策略按行或按列独立设scale避免一个离群值毁掉整个张量的量化精度。这块没有统一参数需要在你模型上反复试验。2.2 结构化剪枝与稀疏化卡在“精度恢复”这一关剪枝是把模型里贡献小的权重或结构去掉减少计算量。但大模型时代纯靠剪枝做延迟优化我持保留态度因为剪完精度掉得厉害恢复成本又高。真正在工程里有价值的是半结构化稀疏和2:4稀疏模式。某些新卡对2:4稀疏有硬件加速可以做到接近2倍的计算密度提升。做法是把权重矩阵中每4个元素强制干掉2个配合重训练把精度拉回来。我实际试下来如果模型本身已经很大直接训练时剪枝比训练后剪枝效果好得多。训练后剪枝对数学推理这类强逻辑任务的破坏尤其明显除非你对精度损失有预算否则建议优先量化剪枝作为叠加手段而非首选。还有一种更温和的做法是通道裁剪把模型中冗余的attention头或FFN维度切掉。判断哪些头冗余可以看它们在验证集上的贡献度或者直接看attention输出的方差方差低说明这个头输出稳定不变剪掉影响有限。这种方式比粒度剪枝对精度影响小对延迟的帮助主要在显存带宽层面。做个简单的加法量化管权重剪枝管结构二者叠加理论上能把延迟压到FP16的1/4左右但精度验证要做得非常细致。2.3 蒸馏用“小模型”换延迟的最优解蒸馏的思路一句话讲完让一个大教师模型教会一个小学生模型学生学会后体积小、推理快。做延迟优化时蒸馏和量化剪枝不冲突它们是同一道菜的两味料。我自己在某个分类项目里把一个4亿参数的模型蒸馏到1亿参数精度只掉了不到1个百分点延迟从12毫秒降到3毫秒这个收益是纯工程优化很难达到的。蒸馏的常见形式有三种离线蒸馏先用大模型在大量样本上生成logits再用这些软标签训练小模型效果最稳但成本高在线蒸馏教师和学生同步训练学生实时从教师拿指导信号省去二次标注成本适合快速迭代自蒸馏用一个模型自身不同深度的输出来互教省去训练大教师模型的成本蒸馏的难点不在训练方法而在数据准备。蒸馏要的不是标注对错而是大模型的“知识分布”。同一个问题大模型给出的答案分布带有很多细微偏置信息学生要把这些信息学进去才能接近教师的能力。数据要覆盖多样场景、边角情况否则学生只会对见过的样本“死记硬背”。我把蒸馏排在最后说是因为它的周期最长通常要重新训练模型。如果你要改的是已经上线的旧模型且线上数据敏感那蒸馏的前置评估成本会比较高。但如果你做的是新模型部署从一开始就规划蒸馏路线效果和成本都最划算。3. 工程落地推理框架与调度优化实战3.1 主流推理引擎怎么选从简单到极限性能模型层的优化做完就要看工程侧了。现在的推理框架已经非常成熟自己手写CUDA算子来加速不是不行但性价比太低。我推荐的选型路径是这样性能要求不高、求快上线直接用原生PyTorch加半精度推理适合demo和内部工具生产环境、通用场景用开源推理框架体验过几款之后我推荐把vLLM或TensorRT-LLM作为优先尝试项它们在连续批处理和缓存利用上做得非常成熟极致性能、定制需求基于TensorRT手动搭推理图逐层优化算子适合对延迟敏感且模型结构稳定的场景各家的底层都默认打开了算子融合、显存复用、CUDA Graph等优化。以CUDA Graph为例传统PyTorch执行是逐kernel启动每个kernel都有启动开销GPU在kernel切换时会出现空闲。CUDA Graph把一个推理过程的所有kernel捕获成一个图一次启动、整体执行省掉了海量的启动开销。我实测过在短序列场景下这项技术能给单次推理带来30%以上的延迟下降。选型时有两个重要的参考维度你的模型是否被该框架官方支持并有针对性优化比如近几年大火的那些开源模型主流框架都做了专门适配性能差异不大你的请求模式是单条低频还是高并发流式这决定了连续批处理的收益是否明显3.2 批处理策略吞吐和延迟的跷跷板如果模型服务的是一次一条请求每请求独占GPU资源那GPU利用率和延迟表现都不好看。正确做法是引入批处理把多个请求拼在一起计算GPU的算力才能喂饱。但批处理不等于简单地把请求攒起来。传统静态batching要求同一批次的请求长度一致长度不一就得padding而padding很大的短序列会浪费大量计算长序列比例高时收益不升反降。业界主流的解法是连续批处理也就是待一个请求的生成步骤完成后立刻插入一个新请求继续跑不需要等整批结束。这个机制能让GPU一直有活干利用率能维持在85%以上。连续批处理对长序列尤其友好因为每个请求在不同生成阶段可以交错运行GPU资源的使用是动态分配的。这背后有两个关键技术点PagedAttention机制仿照操作系统的虚拟内存用分页方式管理KV Cache避免显存浪费从而提高可同时处理的请求数动态调度器每个迭代步都重新决定哪些请求进入计算谁生成完毕就腾出位置给新请求实际配置连续批处理时需要调的两个关键参数是最大批大小和最大等待时长。批大小不是越大越好要看你GPU显存和模型大小等待时长控制请求在队列里攒批的时间设太大会增加延迟设太小则批不齐。经验上先从等待20毫秒、批大小按显存余量推算起步再根据线上P99延迟微调。3.3 KV Cache优化与显存治理增加并发的前置条件解码阶段的推理需要把历史token的键值缓存起来这个缓存叫KV Cache。它的大小跟序列长度、层数、注意力头数线性相关跑长上下文时能把显存吃成无底洞。KV Cache优化直接影响并发度和延迟。最常见的四种手段用更小的数据类型保存键值比如把FP16降为FP8显存直接减半用PagedAttention式分页管理解决显存碎片和“预分配过大”问题加前缀缓存比如系统提示词或公共对话历史多个请求共用一份避免重复计算对不再需要的序列及时释放防止僵尸请求占用显存我做的一个模拟项目X里在没做任何模型层优化前仅把KV Cache从FP16切到FP8同时引入前缀缓存同样一批请求的并发数从32提到了80P99延迟反而降了40%。原因很简单之前显存不够导致频繁换入换出算力都在等待显存搬运现在显存宽裕了GPU能够连续计算。另外一个容易被忽略的点是请求长度。长上下文请求会占用大量KV Cache尤其在做共享缓存时一个长请求可能挤掉几十个短请求的资源。我建议在入口处根据请求长度做分级队列分配不同的显存配额避免长请求拖垮整体延迟。3.4 并发模式与多副本从单机到分布式的性能边界当单台GPU的算力和显存都压满后还要继续降延迟就只能靠横向扩展了。最常见的架构是推理服务前面架一层负载均衡后面挂多个推理副本每个副本处理一部分请求。这样可以把并发压力分散到多张卡上单卡负载降下来平均延迟自然跟着降。这里有一个关键决策你要的是单纯扩容还是做模型并行。如果模型能塞进单卡只是请求量大那多副本加负载均衡就够了部署简单容灾也好做如果模型太大塞不进单张卡就需要把模型切到多卡上并行比如张量并行或流水线并行模型并行的代价是通信开销。张量并行每层计算都需要多卡同步通信量巨大通常要求卡间用NVLink连接否则通信时间比计算时间还长。流水线并行则把模型按层切分到不同卡上卡之间只传激活值通信量小但存在流水线气泡利用率有天然上限。我的建议是不到万不得已不要上模型并行。优先走量化、蒸馏把模型压到单卡再用多副本扩展吞吐和延迟。多副本架构要留意的就是每个副本的实例数和请求队列避免负载均衡层成为新瓶颈。4. 推理延迟优化的完整流程参考4.1 从延迟指标到优化方案一张路线图把前面说过的内容收拢成一套可复制的落地流程大致是七个步骤建立全链路延迟画像确定瓶颈在模型计算、调度还是网络设定延迟目标分别定TTFT、TPOT、P99数值模型层优先做量化和算子融合验证精度与速度如果模型太大评估蒸馏或剪枝把模型瘦身到适合单卡运行引入成熟推理框架开启连续批处理和CUDA Graph等机制优化KV Cache与显存管理提升并发能力负载均衡与多副本扩展解决单节点瓶颈这个路线图的价值在于把优化动作按风险从低到高排了序。量化和框架配置属于低风险高收益上来就做蒸馏和剪枝属于高成本动作只在前面步骤做完还达不到目标时才考虑。4.2 一个实际案例2秒延迟降到300毫秒是怎么做到的模拟项目X是一个文本生成服务初始环境是PyTorch半精度直接部署在单卡上模型大约7B参数接口延迟P99稳定在2秒左右用户体验很一般。优化过程按路线图逐步展开第一步打点画像发现模型计算占1.2秒队列等待占0.6秒网络和后处理占0.2秒。第二步模型切到INT8量化精度评测掉点约0.3%可接受prefill部分延迟从700毫秒降到450毫秒decode部分从500毫秒降到350毫秒。第三步换用推理框架开启CUDA Graph和连续批处理decode延迟进一步降到200毫秒同时GPU利用率从35%跳到80%以上。第四步KV Cache切FP8并做前缀缓存同并发下显存占用降了一半队列积压明显改善排队时间从600毫秒降到100毫秒。第四步做完整体P99从2秒降到了700毫秒左右。第五步上多副本负载均衡把P99压到300毫秒。这个案例里每一步的动作都不复杂核心是靠画像把有限的优化资源投在了正确的位置。我见过很多项目就是不画像直接上量化结果量化完瓶颈还在调度上白白浪费了精度预算。4.3 验证与回归优化完要盯的指标不只是延迟延迟优化做完要做的验证不能只看“是不是快了”。我建议至少做这四组回归精度回归量化、剪枝、蒸馏后模型在评测集上的指标是否落在合同允许范围内稳定性回归长时间压测下P99是否漂移有没有周期性波动并发回归不同并发数下的延迟曲线确认吞吐提升没有以延迟恶化为代价长尾回归专门构造超长输入、超大输出等极端案例观察是否有延迟尖刺其中精度回归很多人会偷懒只跑一两个指标就上线。量化对某些隐形任务的影响普通指标看不出来要故意构造边界case试比如数学题、多步推理、指令遵循类任务。延迟优化的终点不是把测试集跑完而是线上持续可观测。我建议在服务里长期保留延迟画像打点按日/周聚合TTFT、TPOT、P99和GPU利用率设好告警任何一次模型更新或框架升级都先跑一遍回归再灰度放量。5. 高频问题与避坑心得5.1 为什么量化后速度不升反降比较常见的情况是模型小、序列短计算量本身不大量化省下的计算时间被反序列化和反量化开销抵消了。遇到这种情况建议先用量化后的推理基准对比FP16跑不同batch和序列长度组合看收益出现在哪个区间。只要在业务典型负载下没有收益就不要为量化而量化。还有一种情况是选错了量化精度。INT4虽然显存优势大但GPU原生支持的Tensor Core指令集如果对INT4不友好速度反而肩比INT8。配套的PTQ校准数据要贴近真实分布我第一次做量化时拿纯文本数据校准上线后遇到大量代码样本激活分布漂移严重导致生成质量明显下降。5.2 延迟抖动严重P99不稳定延迟平均值低但P99忽高忽低最常见的三个原因显存碎片化长期运行后KV Cache分配不连续导致访存局部性差。解法是定期清理或使用支持分页管理的框架抢占式调度某个大请求占住GPU算力其他小请求排队等待。解法是按请求大小分流到不同队列JIT编译抖动某些算子首次调用时触发动态编译占用几毫秒到几十毫秒。解法是提前warmup把Graph或编译好的kernel预加载我处理过的一个线上事故就是显存碎片导致的P99翻倍。重启进程后恢复正常但过几天又复发。后来改成启动时预分配大块缓存并把KV Cache统一走分页管理才根治。5.3 并发上去了延迟反而变差并发和延迟的关系不是单调的。不同batch大小下推理延迟呈U型曲线batch太小浪费算力batch太大时单个请求的平均延迟被拖高。要找到那个平衡点最靠谱的方式是压测。压测时要分两个维度记录一是固定输入长度下不同并发数的吞吐和P99延迟二是固定并发下不同输入长度组合的延迟分布。别在高并发下只看平均值那会掩盖个别超长请求的惨烈表现。上线前我还习惯做一次“削峰演练”模拟流量突刺场景观察自动扩容或队列溢出的表现。很多系统平时测试都是匀速流量遇到真实业务的脉冲流量就露馅。5.4 显存不够导致OOM怎么办OOM是推理服务最常见的稳定性问题。我的排查顺序是先看模型权重占了多大激活值预留了多少KV Cache又占了多少再查是不是有请求的序列特别长被某个极端case打爆最后看显存碎片率是不是长时间运行后碎片越来越多针对每一步都有对应的解法权重层可以切更低的量化激活值可以开显存复用或梯度检查点KV Cache可以走分页加长度限额碎片可以定时做显存整理或做进程重启策略。如果真的遇到单卡物理显存上限再考虑上多卡并行这是兜底方案不是首选。5.5 模型更新后延迟表现变了模型更新后延迟波动通常不是计算量变化而是权重分布变化导致量化scale不再匹配。这种情况下原量化配置会失效精度和延迟都会劣化。我会定一条规矩模型结构或权重有更新必须重跑量化校准和延迟回归。如果在框架层做了算子融合模型结构变了融合模式也要重新评估。之前某个项目替换了激活函数融合kernel没跟着换延迟从优化后的8毫秒反弹到20毫秒排查了大半天才定位到。6. 最后补一句个人经验AI推理延迟优化是一个系统性工程不是单一技术点能解决的。我经手的项目里凡是成功把延迟压下来的共同特点都是先画像、再分层、小步迭代、每步验证。凡是失败的几乎都是跳过画像直接上重手段或者只盯着某个技术点死磕忽略了链路里的其他瓶颈。做这一行经验固然重要但方法论和流程感才是保证每一版都能稳定收敛的关键。如果只让我留一个小技巧那就是所有优化动作上线前都做成开关A/B跑三天再决定去留。省下的不是延迟是无数个线上事故。