模型文件下载好了权重也量化完了第一版服务上线后首字延迟直接把我劝退了。这不是个例。身边做推理优化的朋友最近聊得最多的不是“谁又改了权重”而是“权重不动的情况下首字延迟到底还能压多少”。所以当我看到“0 行权重改动77% 首字延迟下降”这个说法时第一反应不是怀疑而是有点感慨这正是我这半年做推理服务优化时的真实体感。TTFT 这个指标长期被归咎于模型本身可实际上服务化推理的延迟大头根本不在权重计算上而在排队、调度、内存访问这些权重之外的环节。这篇文章我就把可复现的方法、参数和避坑经验一次说清楚适合想优化在线推理延迟但不想重新训练模型的工程师。1. 权重是天花板时延是路况先盘清楚 77% 从哪里来1.1 为什么 2026 年的提速都绕开权重先说一个很多算法同学容易忽略的事实权重决定的是模型能力的上限而不是服务的响应速度。同一个 7B 模型用不同的推理引擎、不同的 batch 策略、不同的缓存策略跑TTFT 可以差出好几倍。权重改不动不代表延迟改不动因为一次请求从进来到第一个 token 出来真正花在“计算权重矩阵”上的时间往往只是一部分。权重改动本身也贵。无论是微调还是继续预训练都要准备数据、卡资源、重新评估效果线上模型还不能随便换。相比之下推理引擎层面的改动属于纯工程问题风险低、可回滚、效果立竿见影。这就是 2026 年整个行业出现“推理提速大都发生在权重之外”这个趋势的根本原因当模型参数规模上去之后大家发现与其重新训练一个复杂的模型不如先把已经训练好的模型在服务端跑得更快。另一个原因是硬件特性。大模型推理在解码阶段是访存密集型计算单元很多时候在等显存数据而不是在算数。如果只盯权重不盯内存访问和 kernel 调度很多优化做了等于没做。1.2 拆开 TTFT才能理解 77% 是怎么省下来的TTFT 全称 Time To First Token也就是首字延迟指从请求发出到模型返回第一个 token 的时间。它是推理模型最主要的在线指标尤其对聊天、Agent、搜索摘要这类交互场景用户能不能感觉到“快”基本就看这个数字。一个请求的 TTFT 大致可以拆成这样TTFT 网络传输 排队等待 调度开销 Prefill 预填充计算 首个 token 采样权重影响的是“Prefill 预填充计算”这一环里的矩阵运算量但排队、调度、显存分配、缓存命中这些环节权重完全插不上手。实际线上环境中请求并发高的时候排队等待经常比 prefill 计算还长prompt 很长的时候prefill 的显存和算力占用又会把其他请求堵在后面。任何一个环节做优化TTFT 都能变短而且不需要碰权重文件一个字。我见过一个典型的长 prompt 场景系统提示词占 6000 token用户输入只有几十个 token。这种情况下每次请求都要重新计算同样的前 6000 个 tokenTTFT 里 prefill 部分几乎全是重复劳动。把这段公共前缀缓存起来反复请求相同前缀prefill 耗时能直接降到原来的三分之一以内。这就是“0 行权重改动”能拿下 77% 下降的第一个解释权重之外有大量结构化浪费存在。2. 权重之外的三大提速引擎调度、KV Cache 与投机解码2.1 调度与 PD 分离先让请求跑起来权重之外最容易被忽略又收益最大的一层是调度器。传统静态批处理会等一批请求凑满再统一执行单个请求的 TTFT 天然被 batch window 拉高。连续批处理continuous batching则改成了“来一个算一个算完一个立刻腾出来给下一个”配合分页注意力吞吐和延迟同时改善。更强的是 PD 分离也就是把 Prefill 和 Decode 拆到不同的执行单元。原因是 Prefill 阶段是典型的计算密集型要并行处理整段 promptDecode 阶段是访存密集型一次只推一个 token。两个阶段混在一起跑时一个长 prefill 任务会长时间霸占 GPU后面所有待 decode 的短请求都得排队TTFT 就这么被拉高了。拆开之后prefill 请求可以被调度到专门的 prefill 实例decode 流量在另一批实例上稳定推进互相不抢资源。对长 prompt 或高并发场景这个动作往往一次就能带来 20% 到 40% 的首字延迟下降。不要觉得 PD 分离只是分布式架构的“花活”。哪怕单机部署vLLM 也允许通过参数把 prefill 和 decode 的调度权重分开让 prefill 不要霸占整个 GPU 管线。工程上我可以给一个非常朴素的优先级先确认并发和 prompt 长度分布。如果 p50 prompt 超过 1000 token 且并发高于 16PD 分离的收益通常比换一个更小更快的小模型还明显。2.2 KV Cache 的四个关键操作KV Cache 是权重之外最值得做文章的“隐形权重”。它不改变模型参数但每存一个 token 的 Key 和 Value就在显存里占一块地方。它直接影响能同时跑多少请求决定排队长度进而决定 TTFT。先说 PagedAttention。它把 KV Cache 切成固定大小的块类似操作系统分页用得上的块才放到显存里杜绝了碎片化浪费。显存利用率的提升意味着 batch 可以开得更大同一时刻能服务的请求更多排队时间自然缩短。这块优化在 vLLM 里默认就是开启的但很多人不知道如果自己手写推理逻辑或用老框架缺少分页机制显存利用率可能低 30% 以上。其次是 Prefix Caching。这是对 TTFT 影响最直接的一个开关。当请求的 prompt 有相同前缀时系统可以复用之前算好的 KV Cache而不是重新 prefill。聊天场景里的 system prompt、Agent 场景里的工具定义和任务说明都是天然的高复用前缀。实测中如果 prompt 前缀稳定且缓存空间充足长文本场景的 TTFT 可以下降 40% 到 60%。前提是 prompt 要严格一致多一点空格、换一个换行符缓存就命不中。第三是 KV Cache 量化。把 KV 从 FP16 压到 FP8 甚至 INT8能以很小的精度损失换回约一半的显存占用。显存腾出来又可以扩大 batch间接降低排队。这里注意KV Cache 量化并不改动任何权重数值它只是对运行时缓存做压缩属于纯运行时优化。第四是 Chunked Prefill。它把一段长 prompt 的 prefill 拆成多个小块穿插到 decode 请求之间执行避免单个长 prefill 长时间独占 GPU。对整体的 TTFT 分布来说这个机制的价值不在“被拆的这个请求变快”而在“它后面的请求不用再傻等”。配参数的时候要留意 max-prefill-tokens一般建议压在 512 到 2048 之间设得太高就失去了切块的意义。2.3 投机解码与 CUDA Graphs把多余步骤砍掉投机解码这几年很热原理是拿一个小模型先去猜接下来的 k 个 token再用大模型一次性验证。猜中的部分可以并行算出就不用一个个串行 decode 了。它能显著提升解码阶段的 token 吞吐但对 TTFT 的影响要看实现方式。首字出来之前前面根本没有生成序列可猜所以纯投机解码并不会让第一个 token 更快。不过一些实现会通过投机减少 prefill 之后的首次采样负担整体上让 p99 延迟更稳。我倾向于把它当作吞吐优化器而不是 TTFT 的第一选择。CUDA Graphs 是另一个容易被忽略的加速器。它把一小段 kernel 的启动序列录制下来省掉 GPU 和 CPU 之间的频繁交互。解码阶段每次只生成一个 tokenkernel 很小启动开销占比很高CUDA Graphs 能让这类短 kernel 的执行效率明显提升。对短 prompt 的批量请求这个优化对 TTFT 的贡献不如对单 token 延迟明显但它会改善整体响应。还有算子融合、FlashAttention 这类底层优化。FlashAttention 通过分块计算和近似把 Attention 的显存访问量从 O(N^2) 降到 O(N)长 prompt 的 prefill 时间可以缩减一大截。这些都属于“权重之外的提速”因为计算图的语义没变权重数值一个都没动只是把执行方式改得更贴近硬件。3. 实操复现用 vLLM 和 llama.cpp 把首字延迟压下去3.1 vLLM 侧从默认参数到低延迟配置先给一套我在长 prompt 场景下实测过比较稳的 vLLM 启动命令。注意这不是唯一答案不同显卡、不同模型参数要做微调但方向是通用的。python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --served-model-name chat \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.92 \ --max-num-seqs 32 \ --enable-prefix-caching \ --enable-chunked-prefill \ --max-prefill-tokens 1024 \ --kv-cache-dtype fp8简单解释几个关键参数enable-prefix-caching 打开前缀缓存前提是你的 prompt 前缀一致enable-chunked-prefill 配合 max-prefill-tokens 1024把长 prefill 切成小份别让一个大请求堵住后面的短请求kv-cache-dtype fp8 把 KV Cache 压成 8 位显存省一半左右max-num-seqs 32 是并发数不是越大越好太大反而让显存碎片增加。这些参数叠加起来在 A100 或 H100 单卡上跑 7B/32B 模型都能看到 TTFT 明显变化。我做过一次最直观的对比同一个 7B 模型默认参数下长 prompt 的 TTFT 稳定在 1.8 秒左右打开 prefix caching、把 chunked prefill 的 max-prefill-tokens 压到 1024、KV 量化调成 fp8 之后p50 降到了 0.4 秒附近。这就是 77% 量级的下降整个过程我没有动过权重的任何一行也没重训。3.2 llama.cpp 侧offload 到内存算不算改权重最近在讨论“llama cpp offload 到内存是权重吗”的说实话这是个很容易含糊的问题。结论很明确不是。llama.cpp 的 offload 指的是运行时把权重或计算挂在不同的内存上比如把若干层放在 CPU 内存只有少数层放在显存也可以把状态和 KV Cache 放到内存里。这些操作改变的是权重的驻留位置和计算路径权重文件本身的字节没有任何变化参数的数值也没有被重新训练或微调。这属于“权重之外”的一种调度优化。它的价值在于当显存不够但又想跑更大的上下文时不至于直接 OOM把部分层丢到内存后模型能跑起来了TTFT 自然比完全起不来要低很多。但要注意内存带宽通常远低于显存offload 层数过多会让推理变慢TTFT 和 token 生成速度都受影响。所以实际项目中不要无脑 offload我的建议是先看显存占用只把确实放不下的层丢到内存同时用大页内存、numactl 绑定 NUMA 节点尽量把内存带宽吃满。可以这样启动llama-server -m ./model.gguf \ -ngl 24 \ --ctx-size 32768 \ --parallel 4 \ --no-mmap这里的 -ngl 24 表示把最后 24 层放在 GPU 上其余在 CPU 内存里具体数值要根据模型总层数、显存大小和上下文长度来调。--no-mmap 是我在 offload 场景里的偏好禁用内存映射后访问更规律配合 numactl 效果更好如果你的机器内存带宽非常吃紧mmap 有时候反而能缓解一部分负载这个要实测。3.3 压测与指标口径别再被 TTFT 平均值骗了参数调完怎么判断是不是真的变快只看“平均首字延迟”是个新手陷阱。并发上来之后平均值被绝大多数短请求拉低真正的长尾问题藏在 p95/p99 里。我压测时会在客户端记录请求的开始时间、第一个 token 到达时间以及完整响应时间然后分开统计。一个简单的思路是这样用 Python 的 aiohttp 或 httpx 发请求每个请求记录 sent_time 和 first_token_time日志落盘后再做分位数统计。并发建议从 1、8、16、32 一路往上加不要在单一并发下比较。同时要区分冷启动和热态服务刚起来权重还在从磁盘加载TTFT 会虚高连续打几分钟之后再统计才是真实的服务水平。指标本身也要看清。TTFT 是首字延迟TPOT/ITL 是每个 token 的平均间隔TBT 是 token 间延迟的波动用户感知的“打字速度”看 TPOT“反应快不快”看 TTFT。下面这个对照表是我团队内部一直沿用的指标衡量内容重点关注场景TTFT请求发出到首个 token 返回的时间交互类、Agent、搜索摘要TPOT平均每个 token 生成耗时长文本生成、翻译、代码补全TBT相邻 token 间隔的抖动流式输出体验Total Latency整体请求耗时离线批处理、短问答如果只优化 TTFT却不管 TBT用户会看到“第一个字很快后面一顿一顿”体验照样很糟。这也是“推理模型主要测试指标”里很少被讲透的点TTFT 只是第一道门门后还有一连串指标要盯。4. 权重下载只是起点同一个权重不同的延迟4.1 预训练权重热度很高但推理命中率是另一回事最近一段时间DINOv3、YOLOv8、SAM3 这几个词的预训练权重下载量都很高。大家的注意力集中在“从哪里下载、用什么格式、怎么加载”这当然没错但权重下载只是拿到了模型的建筑材料离“低延迟上线”还差一整个工程层。举一个很朴素的例子同样是 YOLOv8 的预训练权重一个直接跑 PyTorch 动态图一个转成 TensorRT 引擎同一块显卡上的单张图片推理延迟可以相差两三倍。模型权重来源相同只是执行方式不同为什么差这么多区别全在权重之外TensorRT 重排了计算图融合了算子调整了内存复用换用了更贴硬件的 kernel。这正好解释了标题里的现象0 行权重改动推理速度可以完全不一样。4.2 引擎升级与算子融合不改权重也能拿到的性能权重之外的性能来源很大一块来自“编译优化”。PyTorch 的 torch.compile、ONNX Runtime 的图优化、TensorRT-LLM 的 engine都是把同一个模型图翻译成执行效率更高的指令序列。普通的解释执行会频繁启动小 kernel内存来回搬运编译优化能把多个算子合成一个把内存分配提前规划好把循环结构改成更适合 GPU 并行的形态。FlashAttention 这种优化同样属于这个阵营。它和权重无关只是把 Attention 的计算方式改成分块策略避免了显存里的巨大中间矩阵。对一个 8K 上下文的模型长 prompt 的 prefill 时间因此缩短一半这也是 TTFT 下降最直接的贡献之一。当你面对一堆“预训练权重”的时候别默认 PyTorch 原版推理就是唯一方式。先花半天时间把权重导成 engine 或上 vLLM/TensorRT-LLM通常比微调权重获得更多收益。4.3 你的 77% 能不能复制能不能复制取决于瓶颈在哪。同样是 TTFT 高有的人是因为 prompt 太长导致 prefill 慢有的人是因为并发太高导致排队久还有的人是因为显存不够导致频繁换页。把三张方子混在一起喝不一定有效。我给一个判断流程。第一步看请求的 prompt 长度分布如果 p50 prompt 只有几十 tokenprefill 不是瓶颈优先优化并发和排队比如扩大 batch、开 PD 分离。第二步看并发和 GPU 利用率如果 GPU 没打满但请求排队说明调度层卡住了别去动权重。第三步看前缀复用观测 prefix cache 命中率如果命中率很低先统一 system prompt 和模板格式再决定要不要加大缓存空间。如果这三步都做了TTFT 还是高再考虑权重层面的操作比如量化、剪枝、蒸馏。顺序反过来往往会走到歧路权重换了效果降了延迟却没降下来。这是我对想复制“77%”的人最大的一个建议。5. 排障实录TTFT 迟迟降不下来问题出在权重之外5.1 症状-原因-操作对照表先放一张我常用的速查表每次线上 TTFT 告警我都是对着它排查第一轮。症状常见原因优先排查动作所有请求 TTFT 整体上升请求排队、batch 太小或太大看队列长度和 GPU 利用率调 max-num-seqs长 prompt 请求特别慢prefill 未切块或未缓存开启 chunked prefill 和 prefix caching短请求被偶尔的长请求拖住长 prefill 霸占 GPU压小 max-prefill-tokens考虑 PD 分离缓存命中率低重复 prompt 仍慢prompt 模板不一致统一 system prompt检查分隔符和换行offload 后 TTFT 不降反升内存带宽瓶颈、层放得太多减少 offload 层数绑定 NUMA用大页内存这张表的重点是先定位“权重之外”的环节。不要在跑诊断之前就去怀疑模型权重坏了权重坏了的典型表现是输出乱码、效果崩坏而不是慢。慢这个问题十有八九在运行时。5.2 现场排查顺序我自己的排查顺序很固定是按照成本从低到高排序的。第一步看请求日志里的 queue time。如果队列等待占了 TTFT 的大半说明不是计算慢是排队慢下一步调并发上限、调度策略和 PD 分离。第二步看 prefill 耗时。vLLM 的日志和监控里有 prefill performance 这类数据能看出单次 prefill 的时间如果很长看是不是没有前缀缓存或没切块。第三步看缓存命中率。命中率低别怀疑缓存代码坏了先把 prompt 模板整理。第四步如果前几步都正常再做 profiler。用 profiler 的时候重点看 Attention 算子和内存拷贝时间。如果内存拷贝占比很高说明权重或激活值在显存和内存之间挪得太频繁这时才需要回到 offload 或 KV Cache 量化上。不要一上来就抓最复杂的工具先把调度和缓存这两层看清大多数 TTFT 问题已经能水落石出。5.3 我踩过的三个坑第一个坑开了 prefix caching但缓存命中率不到 5%。原因是同一个功能在线上有多个模板有的请求 system prompt 末尾带换行有的不带有的带 BOS token有的没带。缓存是按 token 严格匹配的任何一个 token 不一样都命中不了。后来我把模板收敛成唯一版本再用专门的字段控制尾部空格命中率直接从个位数跳到 70% 以上。这个操作和权重完全无关但 TTFT 效果立竿见影。第二个坑chunked prefill 的 max-prefill-tokens 设得太大了。我把值定在 4096结果一个 6000 token 的 prompt 依然是一整块 prefill长请求照样卡住后面的短请求。后来改成 1024并把并发数适度调小整体的 p99 TTFT 才真正降下来。这个教训是参数开了不代表生效要看实际的切块行为和 GPU 时间片分布。第三个坑offload 到内存之后忘了做 NUMA 绑定和内存通道优化。在双路服务器上权重层如果散落在多个 NUMA 节点访问延迟差距很大TTFT 反而比纯 GPU 运行更高。我后来用 numactl --cpunodebind0 --membind0 把进程和内存绑到同一个节点并把 offload 层数降到刚好显存能容纳的范围TTFT 才恢复正常。这类问题在文档里很少写只有现场踩过才会知道内存拓扑对推理速度的影响有多大。我个人做了这些年推理优化最深的体感是权重是模型的灵魂但延迟是服务的身手。很多人拿到预训练权重之后第一反应是想“如果不改权重还能干点什么”结果答案远比想象多。优先级缓存、切块 prefill、KV 量化、PD 分离、CUDA Graphs……每一个都不碰权重却都能让首字延迟往下走。最后再分享一个小技巧压测时把 prompt 模板固定成线上同一份既能让缓存命中率真实反映线上情况也能避免被“假快”的测试结果误导。权重之外的水还深先把这些做好再考虑动权重不迟。