每次在技术群里看到怎么让模型推理更快这个问题十有八九的回答会指向三件事量化、剪枝、蒸馏。这三板斧确实有效但它们都落在同一个维度上——改权重。可最近这一年我复现了几轮推理优化项目结论有点反直觉0行权重改动首字延迟硬是降了77%。首字延迟也就是TTFTTime To First Token它正在取代简单的每秒生成多少token这类老指标成为推理性能优化里最值得盯的标尺。这个现象背后的逻辑其实很清晰大模型推理的开销早就不是权重计算一项了显存布局、调度策略、缓存管理、算子实现这些权重之外的环节每一处都可能在悄悄吃掉你的延迟。2026年推理提速的主战场已经从模型层移到了执行层。这篇文章我会把这块掰开揉碎讲清楚。先说说首字延迟为什么这么重要再拆一下权重之外到底有哪些提速空间然后专门聊一个最近特别热门的话题——llama.cpp把权重offload到内存到底算不算动权重最后把我复现77%下降的完整过程和数据贴出来再把过程中踩过的坑一并交代。这篇文章适合正在做推理服务部署、或者手上有模型但不知道怎么继续压延迟的团队参考。1. 首字延迟的生死线为什么大家突然都盯上TTFT1.1 按下回车到第一个字蹦出来中间发生了什么TTFT的定义并不复杂从用户把prompt发送到服务端到模型返回第一个token可以粗略理解为第一个字或第一个词所经历的时间。但它背后对应的工作量比大多数人想象的要重得多。一次请求进来服务端要做的事情包括输入文本的token化、prompt的逐层前向计算也就是prefill阶段这个阶段要把用户输入的所有token并行算一遍、算完的同时把中间生成的KV Cache键值缓存写入显存然后才是decode阶段生成第一个token。也就是说TTFT的绝大部分时间其实花在读完并理解你的输入上面而不是开始说话上面。输入越长、模型越大prefill阶段的计算量和显存占用就越高TTFT自然水涨船高。这里有个很多人容易忽略的细节prefill阶段是典型的计算密集型compute-bound而decode阶段是典型的访存密集型memory-bound。两者对硬件资源的诉求完全不同这也是后面为什么要做调度拆分的前提。你如果不把这两个阶段分开看就很容易出现调了半天参TTFT纹丝不动的情况。1.2 输入变长时TTFT的恶化是线性的吗不是线性是接近线性的增长而且在大模型场景下Attention部分的计算量随序列长度增长得尤其明显。我这边压测过一组数据一个中等规模的7B开源模型在同样一张A100 80GB上输入512 token时TTFT大概0.6秒输入2048 token时涨到1.9秒输入8192 token时就到了6秒以上。换成更大的模型这个恶化幅度还会放大。这就带来一个很现实的问题如果你的业务场景是短query比如搜索引擎式问答TTFT可能还能接受但如果是长文档问答、多轮对话带历史上下文、代码补全带整个仓库代码输入轻松上万tokenTTFT立刻变成体验瓶颈。还有一个容易踩的坑很多人只看生成速度TPS或TPOT觉得生成一顿猛如虎就够了。但实际交互中用户体验最敏感的是它什么时候开始有反应。3秒的TTFT会让用户觉得卡5秒以上就会觉得服务挂了。所以2026年各家推理框架vLLM、TensorRT-LLM、SGLang这些版本更新的重点几乎都在针对prefill和首token输出做文章这一点本身就说明问题了。另外提醒一句压测的时候别把TTFT和网络往返时间RTT混在一起算。我之前遇到过团队把客户端到服务器的网络延迟也算进TTFT里结果排障排了半天以为是推理框架慢最后发现是负载均衡器的超时配置有问题。测TTFT的脚本要端到端计时没问题但分析归因时一定要把网络、排队、显存搬运这些环节拆开。2. 权重之外2026年推理加速的四个主战场既然权重没动那加速从哪里来我把它拆成四个层面这四个层面就是我后面做优化实验时的主攻方向。2.1 KV Cache的显存管理从整块预留到页式分配先说一下KV Cache是什么。模型在生成每个token时都要反复引用之前所有token的注意力信息为了不每次都重复计算框架会把每层的Key和Value缓存起来这就是KV Cache。它的大小随输入长度和并发请求数线性增长在大上下文场景下它占的显存比模型权重本身还大。传统做法比如Transformers库的默认实现是给每个请求预分配一块完整的KV空间不管实际用不用得完。这会导致大量显存碎片和浪费并发一高就OOM或者被迫把batch压小吞吐和延迟一起变差。vLLM的PagedAttention这类方案本质上是把显存管理做成按页分配类似于操作系统的虚拟内存机制。请求来的时候只分配实际需要的页用完了释放利用率能从四成提到九成以上。这个改动对TTFT的影响主要有两个方向一是显存不再是瓶颈可以开更大的batch吸收并发二是prefill阶段不会因为临时找不到连续显存而触发等待。另外还有一个KV Cache量化的问题。注意这个量化的对象是KV Cache而不是模型权重它属于缓存层优化权重文件一个字节都没变。把KV Cache从FP16压缩到INT8显存占用直接减半又能多塞不少请求。业界对KV Cache量化的讨论这两年明显升温原因就是它跟权重量化走的是两条完全不同的路。想估算KV Cache占多少显存的话可以套这个公式2 × 层数 × 注意力头数 × 头维度 × 序列长度 × batch大小 × 精度字节数。拿7B模型举例假设层数32、头数32、头维度128序列长度2048batch 8FP16精度粗算下来大概是8×2048×32×128×2字节再乘个层数和batch系数实际要几个GB。所以KV Cache在显存里是实实在在的大户省它一省效果立竿见影。2.2 投机解码让一个小模型先跑大模型只当裁判投机解码Speculative Decoding的思路很有意思先用一个很小的草稿模型快速生成好几个候选token再让大模型一次性验证这些token是否合理。如果草稿模型猜对了大模型一次前向就确认了多个token的产出decode阶段的瓶颈就被绕开了。这个方法对TTFT本身帮助不大因为它主要优化的是生成后续token的速率而不是第一个token的等待时间。但它对整个请求的总时延包括排队、prefill、decode全部环节有明显改善。我在实践中的体会是投机解码更像是一个吞吐放大镜如果后端已经有了一定并发它能让你用同样的显存服务更多请求。但它不是解决TTFT燃眉之急的手段很多团队把宝全押在投机解码上结果发现首字延迟还是高方向就搞偏了。选草稿模型的时候有个经验草稿模型最好和主模型用的是同一个tokenizer词表也得对齐否则候选token的映射会多一层转换收益被吃掉一大块。另外草稿模型的接受率不是越高越好要结合生成长度一起看项目里可以先跑一小批数据统计平均接受长度再决定草稿模型的规模和采样温度。2.3 Prefill和Decode解耦把一口气干完改成流水线分工前面说过prefill是计算密集型decode是访存密集型。如果两者混在一个服务进程里抢资源计算密集的任务会阻塞访存密集的任务典型表现就是某个请求正在做大段输入的prefill时其他在生成中的请求全都跟着变慢。prefill/decode解耦的核心思路是把这两个阶段拆成独立的执行单元甚至放到不同的GPU实例上。prefill节点只负责快速读完输入、生成好KV Cache然后把KV交给decode节点继续decode节点只负责不断产出token。这样每个节点都能用自己的资源做最擅长的事。在单机单卡的场景下解耦主要体现在时间片调度上比如给prefill预留高优先级、控制单次prefill的batch大小避免单个大请求独占GPU太久。SGLang的RadixAttention、TensorRT-LLM的disaggregated serving方向其实都是在做这件事。实测下来prefill/decode解耦对长输入的TTFT改善非常明显因为它直接压缩了大请求排队抢资源的时间。我后面复盘里TTFT下降最猛的一轮就是靠的这个方向。2.4 引擎和算子同样的权重换一个跑法差距就很大最后一个层面往往最容易被忽视同一个模型权重在不同的推理引擎里跑延时差一倍都很正常。原因在于底层算子实现和调度策略的差异。举个例子Transformer里的Attention计算朴素实现是把Q、K、V三个矩阵分别算好再组合而FlashAttention类算子通过IO重排把多次访问显存变成更少次数的高效读写单这一步就能带来可观的prefill加速。CUDA Graph的作用则是把一串GPU kernel启动的开销提前录制好运行时不再需要CPU反复下发指令对短请求的延迟抖动抑制特别明显。这些优化有一个共同特点权重文件从头到尾没变模型结构没变但同一张显卡上的执行效率完全是两码事。我见过一个团队把Transformers默认后端换成vLLM后什么都没调TTFT先降了30%当时群里所有人都愣住了。为什么很多人守着旧引擎不换无非是怕踩坑、怕兼容性出问题。但到了2026年主流推理框架的成熟度已经很高OpenAI兼容接口、动态批处理、量化格式支持都基本齐了。与其守着旧管线抠权重不如花一个迭代周期把引擎层的版本和配置更新一遍这个投入产出比通常比继续压权重高得多。3. llama.cpp把权重offload到内存到底算不算动权重3.1 offload的本质是搬家不是改内容最近llama.cpp offload到内存这个话题在社区里讨论得很凶有不少人疑惑把权重从显存搬到内存这算不算权重改动我的判断很明确不算。offload改变的是权重数据存放在哪一层存储介质权重文件本身一个字节都没有变。它更像搬家老房子里的家具一样不少只是换了个地方摆放。为什么要这么干因为不是所有人的显卡都有80GB显存。对一个13B甚至70B的模型显存放不下全部权重时传统做法是硬塞结果频繁触发CPU-GPU之间的搬运整机卡成PPT。而llama.cpp这类框架的做法是让权重常驻系统内存RAMGPU只保留正在计算的那部分层算完了再换。这利用了现代CPU的高内存带宽和llama.cpp高效的CPU算子让显存不够的机器也能跑起来。我在本地一台只有24GB显存的机器上跑过13B模型不开offload基本是死路一条开了offload之后虽然整体速度比不上全显存但至少能稳定对话。对于很多个人开发者和原型验证阶段来说这个跑起来比跑得飞快重要得多。3.2 offload和TTFT之间隔着一堵内存带宽的墙很多人以为offload到内存会让速度慢到不可用但实测不是这么回事。关键在于decode阶段瓶颈是访存带宽而DDR5多通道内存的实际带宽已经能到200GB/s以上配合小模型足够喂饱CPU算力。但对TTFT来说offload的影响就要小心了。prefill阶段需要快速旁路大量权重和中间结果如果权重在内存里、需要反复搬运TTFT会明显恶化。我自己的经验是小模型7B级别以下offload到内存跑TTFT损失在可接受范围内而大模型30B以上offload后prefill阶段会成为灾难首字延迟可能从1秒多飙到十几秒。不同存储介质的带宽差距是理解offload瓶颈的关键存储介质典型带宽对prefill的适配度对decode的适配度显存HBM1.5~3TB/s优秀优秀系统内存DDR550~200GB/s偏弱基本够用系统内存DDR420~50GB/s弱瓶颈明显NVMe SSD3~7GB/s不可用不可用所以offload更适合本地跑个小模型图个方便的场景它解决的核心问题是能不能跑而不是怎么跑得更快。真要压TTFT优先考虑的还得是显存够不够、KV Cache管理好不好、prefill调度顺不顺跟权重内容没关系。3.3 视觉模型的权重下载潮背后藏着同一个道理热搜里DINOv3权重下载YOLOv8预训练权重下载SAM3权重下载这些词条都很热但真正做过部署的人会有体会拿回权重只是第一步部署端的优化空间一点不比模型本身小。拿YOLOv8来说同样的onnx导出权重用不同的TensorRT版本做算子融合、动态shape、半精度推理端到端延迟能差出一倍而NMS阈值、预处理方式letterbox判断、归一化反而经常成为瓶颈。SAM这类分割模型也一样图像预处理的耗时在整条链路里占比极高你再怎么优化权重预处理不重写端到端延迟也压不下去。所以说无论是LLM还是视觉模型权重之外的优化正在成为普遍共识。这也是我把这个标题拿出来写的原因2026年的推理提速关键词已经不是更强的模型而是更聪明的运行方式。4. 0行权重改动77%首字延迟下降我的完整复盘4.1 基线与压测方法为了避免体感优化我把这次实验做成了可复现的对比测试。先说环境两张A100 80GBNVLink连接模型用的是一款7B级别的开源对话模型FP16权重原封不动。推理框架从原始的HuggingFace Transformers生成式接口起步这是很多人开箱即用的默认状态基线就定在这。压测方法是自己写的一个几分钟的脚本构造一组不同长度的输入512、1024、2048、4096 token并发数设为8循环发送请求记录每个请求从发出到收到第一个token的时间间隔取P50作为TTFT参考值同时记录P95。基线数据如下输入2048 token时TTFT中位数2.8秒P95到了4.1秒。这个数据其实已经能感受到卡了。接下来四轮优化权重一次没动。4.2 四轮优化的实测效果第一轮把后端从Transformers切换到vLLM启用PagedAttention。这一步什么都没调TTFT从2.8秒降到1.9秒降幅约32%。原因很直接显存利用率上去了预分配浪费少了prefill阶段不再因为显存碎片被迫等待。顺便说一下为什么Transformers默认管线慢它对每个请求都是来一个处理一个动态图和静态优化的比例失衡GPU算力利用率经常只有两到三成。换成vLLM这类框架之后算子被预先优化、显存分配被重写等于给同样的权重换了一双合脚的跑鞋。第二轮打开连续批处理continuous batching和前缀缓存prefix caching。连续批处理让新请求不用等当前batch跑完就能插入前缀缓存则让重复的system prompt和公共上下文复用KV。这一轮TTFT降到1.2秒降幅约37%。特别是前缀缓存在多轮对话场景下效果比我想的还要猛。第三轮开启CUDA Graph同时把Attention实现换成FlashAttention类算子。TTFT从1.2秒降到0.9秒降幅约25%。这一轮的收益主要来自kernel启动开销减少和显存访问效率提升很直观地体现了同一个权重、不同引擎、不同算子的差距。第四轮做KV Cache INT8量化并调优显存分配策略。TTFT从0.9秒降到0.65秒降幅约28%。这轮有个细节KV Cache量化初期效果反复横跳后来排查发现是量化粒度太粗导致部分请求精度损失、触发重复采样把粒度调到按层量化后稳定下来。四轮合计从2.8秒到0.65秒TTFT下降了76.8%约等于77%。整个过程中模型权重文件一直是原始FP16一行没改。我把这四轮数据整理成了一张表方便对照轮次优化动作TTFTP50单轮降幅累计降幅基线Transformers默认2.80s——第一轮切换vLLMPagedAttention1.90s32%32%第二轮连续批处理前缀缓存1.20s37%57%第三轮CUDA GraphFlashAttention0.90s25%68%第四轮KV Cache INT8量化0.65s28%77%4.3 为什么零权重改动还能有这么大收益一个很多人没意识到的点权重层面的优化量化、剪枝、蒸馏在2024到2025年已经被大量工程化落地了各开源模型的部署默认配置几乎都吃到了这波红利。但执行层框架、调度、缓存、算子的优化普及度还远远不够大量生产环境还在用最原始的Transformers管线跑性能账面上的浪费可能高达百分之六七十。换个说法模型权重决定的是推理速度的理论上限执行层决定的是你实际能拿到这个上限的多少。很多团队卡在权重不能再压缩了的死胡同里其实是把这两个概念混为一谈了。做一次执行层的体检和升级往往比继续压权重性价比高得多。5. 权重外优化的坑与边界什么情况下你拿不到这77%5.1 超长上下文的prefill墙如果你把压测场景换成128K上下文前面那套优化组合的效果会大打折扣。原因在于当输入token数达到数万甚至十几万时prefill阶段的Attention计算复杂度会爆炸式上升KV Cache的管理再高效也架不住计算量本身的量级上去了TTFT照样一路走高。这个场景下的解法是另一套思路稀疏注意力、滑窗注意力、IO优化算子、或者干脆把大上下文拆成检索分块处理。如果你遇到的是这类业务直接套用上面的四轮优化会失望需要单独设计方案。怎么判断自己要不要走长上下文优化这条线就看一个数据业务里超过10%的请求输入token数大于8192如果是那你的TTFT优化重点就该放在Attention实现和上下文压缩上而不是一味堆KV缓存和调度。5.2 高并发时TTFT和吞吐是跷跷板为了把TTFT压到极致如果无脑给每个请求分配最高优先级并发一上来整卡算力会被快速抢占吞吐量直线崩塌最后所有请求一起变慢P95 TTFT反而恶化。实战中一定要做容量规划和排队策略max_num_seqs限制单批最大请求数、空闲等待时间idle timeout设置、长请求和短请求的分队列处理这些参数比模型层的东西更影响服务稳定性。我的建议是把TTFT和吞吐两个指标同时打点采样观察它们的联动关系而不是只盯着一个数。举一个我踩过的例子某次为了把P50 TTFT从0.8秒压到0.6秒我把batch上限调小了一半结果P95直接飙到3秒多因为短请求倒是快了长请求全在排队。后来改成短请求走低延迟队列、长请求走吞吐队列的双队列方案P50和P95才同时稳定下来。5.3 显存省了不等于延迟降了优化KV Cache、开启量化之后你会发现显存占用确实降下来了但某些请求的TTFT反而变差。这个现象我遇到过好几次原因基本都是量化带来的精度损失让模型生成了低置信度token进而触发重新采样或重复推理。所以每次做完省显存类型的优化一定要用真实业务prompt集做回归测试不能只看显存数字好看。我一般会同时记录三个指标显存占用、TTFT分布、生成质量用采样概率或人工抽查三者对齐才能确认优化真的成功了。另外还要提醒一句不要为了压TTFT而把并发粒度调得太极端。极端小的batch确实让单个请求跑得快但系统整体吞吐低排队反而拖累所有请求。这个平衡点没有一个通用公式要在你自己的负载特征下反复压测。最后分享一个我这两年的习惯每个推理服务上线前我都会写一份固定参数的压测脚本存在仓库里prompt长度、并发数、采样参数全部固定每次改动任何配置都跑一遍把TTFT和吞吐的P50/P95记录成一份趋势表。别小看这个动作很多优化完反而变慢的问题都是靠着这种对比才能第一时间抓出来。权重之外的优化空间还很大前提是你得有一把稳定的尺子去量它。