做推理服务的人这两年应该都有个很深的体感模型权重几乎不动了但线上速度一直在变快。2026年的推理提速越来越像一门系统工程真正的大头全部发生在权重之外。你翻遍社区里那些性能报告会发现“0行权重改动”这个提法越来越多再配上一组组首字延迟、吞吐量的对比数据很多人都看懵了——不碰模型速度是怎么提上去的这篇文章就从“0行权重改动77%首字延迟下降”这句话展开。我会先讲清楚权重为什么成了不动的资产再拆解首字延迟Time To First TokenTTFT到底卡在哪个环节然后把权重之外的提速手段逐个讲透最后用一次完整的优化复盘把过程走一遍。适合正在做推理服务优化、模型部署、线上性能调优的工程师也适合刚接触大模型推理、想知道为什么大家都在说“权重之外”的读者。1. 权重为什么成了“不动的资产”1.1 一次权重改动的真实成本很多人第一次听到“0行权重改动”时第一反应是怀疑提速不都是改模型、改权重换来的吗只能说你还没算过改一次权重的总账。先说算力。一次全量微调或者继续预训练哪怕是LoRA这类参数高效微调真正验证下来也要烧掉几十到几百张卡时。如果是几十B参数以上的模型动一次权重就意味着完整的实验循环数据准备、训练、对齐、评测、安全过滤、灰度。这一圈下来时间成本按周算人力成本按组算GPU成本按万算。跟纯工程优化动辄一两天上线相比权重改动是重武器不是日常工具。再说风险。权重一变模型行为就变了。评测集上可能涨几个点但线上真实分布一旦有偏移生成质量、格式稳定性、指令遵循能力都可能波动。更头疼的是这种行为变化很难被自动化监控覆盖。相比之下改调度策略、改缓存逻辑、改批处理大小最多影响性能指标不会改变模型“说话的方式”。还有部署层面的版本管理。生产环境里模型权重是强一致性的交付物换了权重就要重新做量化校准、重新压测、重新过合规审核。在很多团队里“换权重”意味着一次发布事件而“调推理参数”只是运维操作。所以从成本、风险、流程三个角度看权重都成了最不该频繁动的东西。1.2 权重冻结带来的工程红利权重不动反而带来了一波标准化红利。现在社区里到处能看到“dinov3权重”“sam3权重下载”“yolov8预训练权重下载”这类需求模型权重已经被当成一种标准化资产在分发。拿到一份权重只要推理环境匹配就能用统一的引擎跑起来这种“下载即用”的模式天然推动大家把优化工作移到权重之外的推理栈上。这就像同样一台发动机装在不同调校水平的车上百公里加速完全不一样。发动机本身没变但进气道、变速箱逻辑、轮胎、油品、电控程序变了成绩就会有巨大差异。推理服务也类似模型权重是发动机推理引擎、调度器、缓存、显存管理就是那套传动和电控系统。权重冻结还让性能对比变得公平。大家用同一份权重最后比的就是推理平台和工程水平。你会看到越来越多的性能榜单明确标注“权重未做任何改动”这反而让推理优化这件事更有说服力——同样的模型我比你快这就是系统能力的差距。1.3 推理模型的核心测试指标都在考察系统聊到这儿就需要点一下“推理模型主要测试指标”。现在大家最常看的三个数是首字延迟TTFT、吐字间隔Time Per Output TokenTPOT、端到端总延迟。这三个指标几乎不关心权重本身它们考察的是系统能不能快速响应、稳定输出。TTFT尤其能反映系统的“启动能力”。它衡量从用户发出请求到收到第一个token的时间这里面包括排队、模型前向计算、调度、网络传输等一堆环节。你会发现同样是那套权重不同系统测出来的TTFT可以差好几倍。这正好解释了开头那个问题推理提速为什么都发生在权重之外。2. 首字延迟到底卡在哪2.1 TTFT的四段旅程要优化TTFT先得把它拆开看。我习惯把首字延迟分成四段排队时间请求到达后在调度器里等待资源分配的时间。预处理时间把prompt做tokenize、padding、组装batch的处理时间。Prefill计算时间模型对整段prompt做并行计算生成第一个token所需的前向传播时间。第一token传输时间计算完成后把token送回客户端的时间。用公式表示就是TTFT T_queue T_preprocess T_prefill T_transfer。这四个环节里最容易失控的是排队和prefill计算。很多人的TTFT高不是模型跑得慢而是请求在队列里等太久了或者prompt太长导致prefill时间爆炸。这个拆分告诉我们一个核心逻辑优化TTFT时不一定要动模型只要把四段里的任何一段压下去首字延迟就能降。权重的角色只出现在prefill计算这一段而且这一段还能通过KV cache、算子融合、精度优化来压缩。权重之外的空间远比想象中大。2.2 Prefill阶段的算力与带宽压力很多人误以为prefill阶段只是“算一次前向”应该很快。但大模型的首字延迟恰恰最容易被prefill拖垮原因有两个计算量大和访存量高。先看计算量。对于一个序列长度为n的promptTransformer的自注意力计算量跟n²成正比。prompt越长prefill的浮点运算量涨得越快。你发一段5000字的上下文进去仅prefill的计算量就比输出阶段单个token的计算量大几个数量级。再看访存量。prefill阶段每个token都要读取模型权重和计算注意力权重几百GB都是常事。如果推理引擎没有做算子融合中间结果频繁写回显存再读出来显存带宽就成了瓶颈。很多实测里prefill慢根本不是卡在算力上而是卡在HBM带宽上。理解了这两点你就明白为什么FlashAttention这类技术能带来显著提升它不改变权重只是把注意力的计算顺序和访存路径重排了把数据搬运省掉一大半。权重还是那组权重但计算效率完全不一样。2.3 为什么在线服务都把TTFT当第一指标用户点开一个AI应用最直观的感受是“它多久开始回我”。哪怕后端吐字速度很快只要第一个字迟迟不出来用户就会觉得卡。这就是TTFT成为第一指标的体验基础。从产品角度讲TTFT还直接关系到流式输出的体验设计。如果TTFT超过两三秒用户很可能已经刷新页面或者放弃请求了。很多团队把TTFT的P95作为SLO一旦超标就告警。这说明什么说明首字延迟不只是技术指标它已经是产品和运维共同盯着的重要服务承诺。所以在性能优化里TTFT永远享有最高优先级。优化手段能不能上线先看它会不会让TTFT变差。也正因如此下面要讲的这些权重之外的优化方案全都把“降TTFT”作为核心目标。3. 权重之外2026年真正主流的提速手段3.1 KV Cache与前缀缓存让模型“少算”权重之外的提速方案里KV cache缓存是我第一个要说的因为它效果最直接。KV cache是什么模型在生成过程中会把每个历史token的Key和Value缓存下来避免每生成一个新token就重新计算全部历史。这是最基础的KV cache。再往上走是前缀缓存也就是把prompt中公共前缀的KV cache复用给不同请求。比如一个知识库问答系统所有请求都带着一长串系统提示词和固定文档这些内容的KV cache完全可以共享。第一个请求算完之后后续请求直接命中缓存prefill计算量一下子砍掉大半TTFT自然跟着掉。我见过一个实际案例系统提示词加固定参考资料有两千多token优化前每次请求都要从头计算TTFT在1.5秒左右。开了前缀缓存之后命中请求的prefill阶段几乎只剩用户问题那几十个token的计算量TTFT直接压到400毫秒以内。权重一个字节都没动效果比换模型还明显。做前缀缓存要注意两个细节。一是注意缓存键的设计prompt的token ID序列必须完全一致才能命中任何微小差异都会导致缓存失效所以需要对prompt做规范化处理。二是注意KV cache的显存占用缓存不是免费的它占的是显存空间缓存太多了反而挤占batch空间吞吐可能下降。合理做法是给缓存设容量上限并用LRU之类的淘汰策略管理。3.2 PD分离让Prefill和Decode各干各的2026年做推理优化的团队几乎都在聊PD分离也就是把prefill阶段和decode阶段拆到不同的计算资源上。为什么这样做能提速因为两个阶段对资源的需求完全不同。Prefill阶段特征是计算密集、batch可以很大、显存带宽压力大适合用高算力的GPU批量处理。Decode阶段每个请求只生成一个token计算量很小但对延迟很敏感如果大量请求挤在一起GPU利用率上不去还容易出现“一个慢请求拖累所有人”的情况。混合跑的时候一侧突发的大量prefill请求会把decode的GPU资源抢走导致在线服务TTFT和TPOT同时恶化。PD分离之后两套资源各干各的prefill节点就算被大prompt打满也不会抢decode节点的算力。很多实测中仅仅做了PD分离P95 TTFT就能下降20%到40%同时吐字间隔也更稳定。这还是没动权重的情况下达成的。需要提醒的是PD分离会引入节点间通信开销。prefill算完的KV cache要传给decode节点这里涉及传输时间和显存拷贝。如果集群网络不好分离带来的收益可能被通信开销吃掉。另外PD分离也要求推理框架支持比如vLLM、SGLang这些现代推理引擎都提供了相关配置但你要自己调试并发比例和节点分配。3.3 投机采样小模型写草稿大模型当裁判投机采样是个有点反直觉的方案让一个小模型先快速生成一串草稿token再让大模型在单次前向计算里验证这些token是否可接受。草稿通过验证的部分就直接当作输出结果不通过的从第一个错误token开始重新生成。这套机制里的权重一个都没改大模型的输出完整性和质量完全没变。但效果是因为大模型一次验证了多个token相当于把多次串行计算变成了一次并行计算TTFT和整体吐字速度都受益。在长prompt场景下TTFT主要被prefill阶段主导投机采样对TTFT的直接改善有限但它能让decode阶段提前开始、整体输出更快。而在短prompt、多轮对话场景草稿模型可以跟大模型同时读同样的KV cache首字延迟照样能降。选择草稿模型时最关键的是接受率。如果草稿模型写的东西总被大模型拒绝那白算一遍反而增加延迟。实践中我会先拿一批真实线上prompt做接受率验证接受率低于0.6就不太划算。另外草稿模型一般比大模型小一两个数量级而且最好用同一个训练家族的模型分布越接近接受率越高。3.4 算子融合与计算图重排把内存搬运省下来在推理引擎里模型的计算图通常被拆成很多细粒度的算子逐个在GPU上执行。每个算子执行完都要把中间结果写进显存下一个算子再读出来。这个读-算-写循环里真正的数学运算只占一小部分时间大量时间都耗在数据搬运上。算子融合的思路就是把这些细小的算子合并成一个大算子让中间结果留在寄存器或者共享内存里不落回显存。最典型的例子是FlashAttention它把attention的计算融合成一整个kernel避免了QK^T结果写回显存再读出来做softmax的过程。模型权重的数值没变但内存带宽压力骤降prefill阶段的速度自然就上去了。除了算子融合还有计算图重排。比如把两个可以并行的分支同时调度把相同shape的张量合并处理把没必要保存的中间结果及时释放。这些都是推理引擎层面做的优化跟权重一点关系都没有。所以你会看到同一个模型在vLLM、TensorRT-LLM、SGLang这些引擎上的性能差异可以达到一倍以上这个差距基本全是算子优化和调度策略贡献的。3.5 连续批处理与动态调度把排队时间压掉TTFT公式里的排队时间最容易被忽略也最好优化。传统做法是把请求攒一批再统一跑攒批时间就成了延迟。连续批处理Continuous Batching改成了边来边跑一个请求生成的token一旦结束立刻把它的显存空间让给下一条等待的请求。这带来的效果非常直接排队时间从“等整批凑满”变成“等当前step算完”TTFT的排队部分被压缩到毫秒级。再加上优先级调度把在线交互请求排在批处理任务前面首字延迟曲线会变得非常漂亮。调度策略也很有讲究。比如设置最大并发数和队列长度阈值超过阈值就拒绝新请求而不是无限排队再比如给不同业务设置优先级重要请求可以插队。这些都是推理服务里的“软优化”不碰权重但对用户体验的影响立竿见影。我见过一个团队只调了调度策略把排队上限从无限制改成动态阈值P95 TTFT就降了300毫秒。3.6 精度压缩与推理引擎优化权重“包装”变了内容没变看到“精度压缩”有人会问这不还是改了权重吗这里需要区分一个概念量化改变的是权重的存储格式和计算精度不是权重本身承载的知识。你可以把它理解成把同样一本书从精装版换成口袋本内容不变但携带轻了、翻页快了。在实际操作中FP16转FP8或者INT8权重文件大小缩小一半以上显存占用下降prefill阶段能塞进更大的batch吞吐提升同时访存量减少TTFT也受益。推理引擎里对量化权重做反量化的过程已经被优化到几乎不增加额外开销可以说就是纯工程红利。不过量化也不是白拿的收益。对特别小的模型精度损失可能比较敏感对某些需要精确数值的算子FP8可能不够稳。我的建议是先用校准集做一次量化再拿线上典型prompt做对比评测确认生成质量没有明显劣化再上线。多数场景下高质量校准数据能把精度损失控制到几乎不可感知。4. 一次实战复盘0行权重改动首字延迟下降77%4.1 基线测量先搞清楚现状再动手去年我在做一个知识库问答服务的推理优化模型是一套7B级别的权重部署环境是4卡A100推理引擎用的vLLM。一开始明显感觉首字延迟偏高但谁也没法凭感觉判断问题出在哪所以第一件事就是做基线测量。我们用压测工具模拟了线上请求分布平均prompt长度约1800 token请求并发在20左右同时统计了TTFT的均值、P50、P95。基线数据很直观平均TTFT是1.80秒P95更是到了2.35秒。这个数字对知识库场景来说已经很影响体验了用户问完问题经常盯着屏幕转圈。进一步拆解后发现问题集中在两块一是所有请求都带着同样的系统提示词和固定知识库摘要但每次都在重复计算它们的KV cache二是prefill和decode混在同一批GPU上偶发的大prompt请求会抢占在线请求的算力导致尾延迟飙升。这两块都跟权重无关全是工程层面的问题。4.2 优化清单与优先级排序基线数据拿到后我们按“投入产出比”排了优化顺序核心思想是先用改动最小的方案拿到最大收益再逐步叠加第一优先级开前缀缓存把公共prompt的KV cache做复用。第二优先级开启PD分离prefill和decode资源隔离保护在线请求。第三优先级调整调度策略设置动态队列上限给交互请求更高优先级。第四优先级把推理引擎升级到支持算子融合和PagedAttention的版本。第五优先级给模型做FP8量化降低显存占用和访存压力。整个过程中模型权重的参数量和数值都没有人为修改量化也只是改变了存储和计算精度。我们内部记了一笔账所有优化都发生在引擎配置、运行时策略和推理框架层面真正做到了“0行权重改动”。4.3 实测数据从1.80秒到0.41秒优化逐项上线后我们用同样的压测配置复测了一遍。效果非常明显指标优化前优化后变化幅度平均TTFT1.80秒0.41秒下降77.2%P95 TTFT2.35秒0.72秒下降69.4%平均吐字间隔76ms58ms下降23.7%吞吐量38 req/s61 req/s提升60.5%显存占用接近上限余量约18%压力明显缓解平均TTFT的计算过程不复杂(1.80 - 0.41) / 1.80 0.772也就是77.2%。这个数字最终成了我们对外汇报的核心成果。更让我欣慰的是P95也降下来了说明优化不是只把平均值拉低而是把尾延迟控制住了这对于在线服务的稳定性更重要。从1.80秒到0.41秒最重要的贡献来自前缀缓存它直接吃掉了最大的那部分重复计算。PD分离则负责把偶发的高延迟尖刺削平让P95大幅回落。FP8量化在提升batch吞吐方面贡献明显但单独拎出来对TTFT的直接影响不如前两者。这也再次印证了一个规律先解决系统的结构性问题再考虑权重的压缩包装。4.4 踩过的坑优化不是按开关那么简单整个优化过程不是一路顺风踩过的坑也值得记录。第一个坑是前缀缓存命中率上不去。起初以为缓存键只跟prompt文本有关结果发现线上请求的系统提示词里带了时间戳和随机token导致每个请求的token序列都不一样缓存形同虚设。后来把动态内容从公共前缀里拿出来命中率才从不到20%涨到85%以上。第二个坑是PD分离刚上线时某个节点的显存直接爆了。原因在于prefill节点算完的KV cache需要保存在显存里等待传输而decode节点要等收到完整KV cache才能开始生成两端节奏没对齐缓存积压。最后通过限制prefill节点最大并发和调整传输缓冲才稳定住。第三个坑是量化之后的首次响应慢。FP8权重在GPU上需要预热在服务刚启动的第一分钟内TTFT反而比FP16还差。后来我们加了启动预热请求让CUDA kernel和权重都提前加载完毕再对外放流量。这些经验不写在任何官方文档里只能靠现场踩出来。5. 排查经验与优化节奏5.1 典型症状速查表优化做完之后维护阶段经常遇到各种性能问题。我整理了一份速查表遇到问题可以先对号入座症状可能原因排查方向TTFT高但GPU利用率低排队时间过长查看调度队列长度和批处理策略TTFT高且prefill耗时长prompt过长或未命中缓存检查前缀缓存命中率和prompt长度分布P95忽高忽低Prefill和decode互相抢资源考虑PD分离或调整并发比例偶尔超时但平均值正常长尾请求被大请求挤压检查是否有超长prompt或超大batch缓存开启后吞吐下降KV cache占用过多显存调低缓存容量上限改LRU淘汰量化后质量波动校准数据覆盖不足换更贴近线上分布的校准集再补一个经验看指标不要只看平均值。平均TTFT好看P95可能已经高到不可接受。我在压测时习惯把P50、P95、P99一起拉出来看如果P99和P50差距过大说明系统里存在明显的长尾效应这种问题通常比单纯的平均值超标更难排查。5.2 三个“看起来有用其实没用”的操作优化做多了你会发现有些操作乍一看很有道理实测下来全是白费功夫。第一个是贪多量化。动不动就把FP8降到INT4权重是变小了但部分算子在低精度下性能反而更差而且生成质量开始出现肉眼可见的退化。量化不是越低越好要结合模型规模和业务容忍度选择。7B模型我建议先在FP8或者INT8上面试INT4只适合对质量不敏感的模型。第二个是盲目加大投机采样的草稿模型。以为草稿模型越大接受率越高结果草稿模型本身跑得太慢投机完全失去意义。草稿模型的关键不是单看接受率而是“单token生成时间乘接受率”的乘积这个综合指标才是决定收益的关键。第三个是只优化调度不优化缓存。有些团队花了很大精力调整批处理和优先级TTFT只降了一点点。后来一看prompt里一大半内容是重复的开个前缀缓存直接省掉80%的prefill计算。调度解决的是排队问题缓存解决的是计算问题两者是乘法关系不是替代关系。5.3 迭代节奏建议先测量再优化再验证最后说说优化节奏。我特别强调一点不要凭感觉优化。每做一次改动都要有基线数据、对比数据和量化结果作为支撑。我们团队内部定的流程是收集现状指标定位瓶颈排优先级逐项上线每次变动后重新压测然后记录收益和副作用。这样做的好处是哪怕某个优化手段没有生效你也能清楚知道它没生效而不是把所有改动揉在一起之后根本无法归因。另外上线顺序也有讲究先把零风险的启动比如调度策略调整、缓存开启再把有环境依赖的跟上比如PD分离最后才做有质量风险的比如量化。优先级排序我一般看两个维度改动风险和收益确定性。零风险高收益的事永远先做高风险低收益的事永远不做。这套逻辑放到推理优化里基本不会跑偏。结尾做了这些年推理优化我个人最大的体会是模型权重就像一座矿能被直接挖走的价值越来越少了真正剩下的富矿全在权重之外的系统层。资源调度、缓存复用、计算图优化、精度压缩这些不写进模型却决定模型跑得快不快的东西才是2026年推理提速的主要战场。如果只让我保留一个优化项我一定会保留前缀缓存。不是因为它是唯一有效的方案而是因为它最容易被人忽略却又能在不冒任何质量风险的情况下带来最大的首字延迟收益。下次你再看到“0行权重改动77%首字延迟下降”这种标题可以第一反应不再是怀疑而是好奇他们到底在权重之外做了什么。