做推理服务这几年我改过的权重文件加起来不到二十个但改过的启动参数、调度配置和缓存策略保守估计上千次。这个比例不是我懒是现实逼出来的2026 年真正能把首字延迟压下去的杠杆绝大多数都不在权重里。首字延迟也就是大家常说的 TTFTTime To First Token从请求进网关到你屏幕上蹦出第一个字中间塞着排队、模板渲染、分词、prefill 计算、首步解码、采样、序列化、代理转发七八个环节而权重只跟其中一两个环节沾边。这篇东西就聊这件事为什么0 行权重改动能换来 77% 的首字延迟下降这些改动具体发生在哪一层以及我在实操里踩过的坑。不管你是刚接手推理服务的新人还是已经在调 vLLM、llama.cpp 这类后端的同学下面的内容都能直接拿去用。1. 先把账算清楚TTFT 里的时间到底花在哪很多人一提推理提速就条件反射地想到换更小的模型、做量化、剪枝这属于只盯着一棵树忘了整片林子。要让首字延迟下降第一步是把这条时间线切开看清楚每一段各占多少毫秒。我在自己的测试环境里单卡 80G 显存8B 级别稠密模型16K 上下文做过一次完整打点一个 2400 token 的请求基线端到端 TTFT 是 1830 毫秒而其中真正属于模型前向计算的部分不到 900 毫秒。剩下那一半全在权重之外。1.1 Prefill 和 Decode 是两条完全不同的曲线要理解 TTFT得先把 prefill 和 decode 分开。Prefill 是把整段 prompt 一次性喂进去计算注意力并填充 KV Cache这个过程是大矩阵乘密集型的瓶颈在算力属于把一整本书一口气读完并做笔记。Decode 是每次只吐一个 token每一步都要把全部权重和已经积累的 KV Cache 重新读一遍瓶颈在显存带宽属于逐个字抄写但每写一个字都要翻一次词典。这两件事的优化手段几乎不重叠。TTFT 只跟 prefill 和排队有关而 TPOT每个输出 token 的耗时也叫 ITL跟 decode 有关。你如果把权重从 FP16 压到 INT4decode 阶段的访存量降到四分之一TPOT 会明显好转但 TTFT 的收益往往只有百分之十几——因为 prefill 的耗时里有相当一部分来自注意力的平方复杂度这部分不会因为权重变小而缩短。我见过太多团队花了三个月做权重量化吞吐上去了首字延迟几乎没动然后被业务方追着问为什么变快了但感觉没变快。1.2 被忽略的排队时间和传输时间把 TTFT 的组成拆开最容易被低估的是两个东西排队和传输。先说排队。单请求打点的时候你看不到它但只要并发上来排队时间会迅速变成大头。我在并发 32 的压测里见过排队占到 TTFT 的 45%。原因很直白请求到达后先进调度队列调度器要等当前这一轮 batch 跑完才能把它塞进去如果前一批里有几个 8K 长 prompt 正在 prefill后面的短请求就得干等这就是典型的队头阻塞。这一段的耗时跟权重一点关系都没有纯粹是调度策略决定的。再说传输。这部分更隐蔽而且经常是客户端测出来比服务端慢 300 毫秒的元凶。默认配置下反向代理会把 SSE 流式响应攒在缓冲区里等攒够一定大小或者超时才往下发业务方看到的首字延迟里就凭空多了一段缓冲时间。还有 gzip对 SSE 这种长连接流式响应做压缩会把本来可以逐块发出的数据卡住。这三百毫秒你就算把模型换成世界最小的也优化不掉因为它压根不在 GPU 里发生。还有一段更少人注意的模板渲染和分词。Chat 模板通常是 Jinja 渲染的长 system prompt 加上多轮历史渲染一次几十毫秒很正常分词器如果是 Python 实现长 prompt 又要几十毫秒而且受 GIL 影响不容易并行。这两段加起来在长 prompt 场景下能吃掉你一百多毫秒。1.3 为什么动权重这条路越来越不划算我不是说权重侧没有优化空间而是说它的投入产出比在快速衰减原因有三个。第一是收益结构不对。权重侧的手段主要改善 decode 的访存瓶颈对 prefill 和排队几乎无能为力而 TTFT 恰恰主要由后两者决定。你做了一堆量化用户的感受是输出变快了但第一个字还是等那么久。第二是周期长、风险高。蒸馏和剪枝要重新训练周期按周甚至按月算量化要跑完整的质量评测还要过业务方的回归集。权重是资产一旦发布就被下游按哈希锁死你改一次整条链路都要重新验证一遍。第三是回滚成本。权重改坏了回滚意味着重新加载几十 G 的模型、重新预热、重新发版。而调度参数、缓存策略、内核后端这些运行时资产改完当天生效出问题一条命令回滚还能顺手做 A/B 对比。所以我的原则很简单能在运行时解决的绝不碰权重。这也正好解释了标题里那句话——77% 的收益来自一堆根本不改模型数值的开关。1.4 该盯哪些指标别只盯平均值聊优化之前先把度量这件事定下来。只有平均值等于自欺欺人。我一般看这么一组指标含义我的关注点TTFT p50一半请求的首字延迟反映常规体验TTFT p95 / p99长尾请求的首字延迟决定用户投诉量TPOT / ITL每输出 token 耗时和 TTFT 分开优化排队时长请求进队到开始 prefill判断调度是否合理KV Cache 使用率显存里 KV 占用比例接近 100% 就会开始抢占抢占次数preemption 计数大于 0 说明并发超了goodput满足 SLO 的吞吐比裸吞吐更有意义这里有个反常识的点裸吞吐和首字延迟经常是互相打架的。你把并发上限开大吞吐数据好看但排队变长p99 的 TTFT 直接爆掉。真正该盯的是 goodput——在TTFT 小于某个阈值这个约束下的有效吞吐。我吃过这个亏早期为了冲吞吐把并发上限调到 256结果线上 p99 首字延迟从 800 毫秒涨到 4 秒用户端表现就是发了消息半天不出字最后只能把并发降回来吞吐其实并没损失多少。2. 权重之外的五个抓手从调度到内存的完整拆解把账算清楚之后优化方向就清楚了凡是发生在请求到达到prefill 结束之间的环节都是我的目标。下面这五层是我实际调优时的检查顺序从便宜到贵排列越靠前的性价比越高。它们的共同点是一行权重都不用动。2.1 调度层连续批处理与 chunked prefill调度层是收益最大也最容易被忽视的一层。老式的静态批处理是攒一批请求跑完一起返回一个 batch 里最慢的那个决定所有人的等待时间。连续批处理iteration-level scheduling改成每生成一个 token 就重新组一次 batch新来的请求随时能插进去短请求不用等长请求跑完。这一改动对 TTFT 的影响是数量级的。在此之上还有 chunked prefill中文一般叫分块预填充。它的思路是把一个超长的 prefill 切成若干小块比如 8K 的 prompt 切成每块 512 token让这些小块和 decode 步骤交替执行。好处有两个一是长 prompt 不会长时间霸占 GPU后面的短请求能及时插队二是显存峰值更平滑。代价是长请求自己的首字延迟可能略微变长但整体 p95/p99 会明显下降。这笔买卖在真实流量里非常划算因为长 prompt 通常是少数短请求是多数。控制这个行为的核心参数是单轮 batch 里最多塞多少个 token。我的经验值是从 2048 起步如果你发现 decode 的 TPOT 被拖慢了说明块太大如果发现 prefill 效率低、GPU 利用率上不去说明块太小。这个参数没有普适最优解必须拿你自己的 prompt 长度分布去扫一遍。2.2 前缀缓存把重复的 prefill 直接抹掉如果说调度层是省时间前缀缓存就是直接把时间删掉。原理非常朴素如果两个请求的前面一段 token 完全一样那这段的 KV Cache 可以直接复用不用重算。真实业务里前缀重复率高得惊人。系统提示词、角色设定、few-shot 示例、工具定义、RAG 的固定指令模板这些东西在同一个产品里往往一模一样长度动辄一两千 token。我这次实测的场景里系统提示部分有 1200 多个 token开启前缀缓存后这部分直接从 prefill 里消失TTFT 掉了 430 毫秒。但这里有个巨坑我必须单独拎出来说前缀缓存要求前缀逐 token 完全一致一个空格、一个换行、一个模板渲染出来的多余 token 都会导致缓存失效。最常见的错误写法是把时间戳、请求 ID、会话 ID 塞在 system prompt 的开头比如当前时间是 2026-03-15 14:22:31请根据以下规则回答……。这一句直接让所有请求的前缀都不一样命中率归零缓存形同虚设而且你在监控面板上根本看不出异常——GPU 该忙还是忙只是白忙。正确的做法是把所有动态内容挪到 prompt 的末尾让前面那 1200 token 保持完全静态。如果确实需要时间信息就放在用户输入那一段里或者用工具调用的方式注入。2.3 KV Cache分页、量化与生命周期管理KV Cache 是推理服务里最值得花心思的一块显存。它有两重身份既是计算中间结果也是并发容量的天花板。先说分页。早期的实现给每个请求预留一段连续显存长度按最大可能长度算结果实际用了一半另一半浪费掉还产生大量碎片。分页方案把 KV Cache 切成固定大小的块用类似虚拟内存的方式按需分配浪费率能从百分之六七十降到个位数。这个改动的直接效果不是单请求变快而是同样显存能塞下更多并发排队时间下降TTFT 跟着下降——典型的绕道优化。再说量化。KV Cache 用 FP8 存储显存占用直接减半容量翻倍。这同样是绕道降延迟并发能力上去了队列短了首字自然快。不过 KV 量化对输出质量的影响比权重量化更敏感尤其是在长上下文场景下误差会在注意力里被放大。我的做法是先在业务回归集上跑一遍对比确认质量差异在可接受范围内再上线而且要开一个小流量灰度。最后是生命周期。这里有个容易被忽略的参数显存预留比例。设得太高容易 OOM设得太低会导致运行中的请求频繁被抢占KV 块被换出到 CPU 内存再换回来延迟直接起飞。我一般让 KV Cache 使用率稳定在 80% 到 90% 之间同时盯紧抢占计数只要不为零就说明并发上限该往下调了。2.4 计算图与内核CUDA Graph、后端选择与采样开销这一层是纯工程活收益稳定但需要耐心。CUDA Graph 的思路是把一连串 kernel launch 录制成一张图之后一次提交全部执行。decode 阶段每生成一个 token 要启动几十个 kernel启动开销累积起来相当可观用 CUDA Graph 之后这部分基本消失。它对 TTFT 也有贡献因为 prefill 末尾和第一步 decode 的 kernel 启动开销同样被省掉了。注意不同 batch size 需要不同的图所以框架一般会准备一组分段图这也是为什么你在压测时会看到某些批量下性能突然跳变。注意力后端的选择同样关键。同一张卡、同一个模型换一个注意力实现TTFT 差百分之十几很正常因为不同实现针对的序列长度、head 维度、数据类型各不相同。我一般的做法是把候选后端列出来用自己真实的 prompt 长度分布比如短、中、长三档各测一遍选 p95 最好的那个而不是看社区推荐的默认值。采样环节也值得看一眼。词表动辄十几万top-p 采样要做排序和累积求和几毫秒到几十毫秒都有可能。如果你的业务不需要极端多样的输出适当限制候选集、换更高效的采样实现能省掉一部分首字时间。这里顺便说个反直觉的结论投机解码对 TTFT 帮助很有限。它的核心价值在 decode 阶段用小模型先猜几个 token 再由大模型验证能提高 TPOT。但 prefill 阶段它帮不上忙而且草稿模型本身还有开销。我实测下来开投机解码后 TTFT 甚至略有上升但 TPOT 好了不少。所以如果你的 SLO 是首字延迟别把预算花在这里。2.5 内存分层与卸载offload 动的到底是什么这一节专门回应一个高频疑问把权重 offload 到内存算不算改权重答案很明确不算。权重的数值一个比特都没变变的是它存放在哪里、以及被读取的路径。量化和剪枝是改内容offload 和 mmap 是改位置这是两件性质完全不同的事优化手段和风险也完全不同。具体到场景offload 通常是显存不够、但还想跑起来的妥协方案。把一部分层放到主机内存计算时通过总线搬进显存搬运带宽是硬瓶颈。结果就是首字延迟显著变差——你可能获得了能跑的能力但代价是慢。所以在延迟敏感的场景里offload 是保底手段而不是加速手段。稍微例外的一种组合是权重常驻显存只把 KV Cache 的一小部分卸载到主机内存。这种情况下权重路径没变被牺牲的是长上下文下 KV 的读写速度TTFT 会有小幅增加但换来了更长的上下文支持。这种取舍是否值得取决于你的业务是短 prompt 高并发还是长文档低频次。3. 一次真实调优从 1830 毫秒压到 420 毫秒上面讲的是方法论这一节把过程完整还原一遍。数据来自我自己的测试环境你要照抄参数之前请记住所有绝对数字都跟硬件、模型、prompt 分布强相关只有优化顺序和排查思路是可以直接搬走的。3.1 基线怎么测才可信先把测量这件事做对否则后面所有对比都是幻觉。我给自己定了五条规矩。第一条客户端测不要在服务端内部打点。服务端日志里的 TTFT 往往不含网络和代理业务方感受到的是客户端那个数。第二条必须流式测只看第一个 chunk 到达的时刻不要等整个响应结束。第三条prompt 长度要固定成几档我用 512、2400、8000 三档每档跑 200 个请求输出都只取 1 个 token因为我们只关心首字。第四条冷启动和预热后分开记录第一请求永远特别慢别混进统计。第五条并发要固定我测 1、8、32 三个档位因为不同并发下瓶颈会换人。下面是我用的测量脚本很简单核心就一句记录第一个数据块到达的时间。import asyncio, time, statistics import httpx URL http://127.0.0.1:8000/v1/chat/completions PROMPT ... # 固定内容长度按档位准备 CONCURRENCY 32 ROUNDS 200 async def one_call(client): payload { model: local-model, messages: [{role: user, content: PROMPT}], max_tokens: 1, # 只要首字 stream: True, temperature: 0, } t0 time.perf_counter() async with client.stream(POST, URL, jsonpayload) as resp: async for line in resp.aiter_lines(): if line.startswith(data:) and DONE not in line: return (time.perf_counter() - t0) * 1000 return None async def main(): limits httpx.Limits(max_connectionsCONCURRENCY * 2) async with httpx.AsyncClient(timeout120, limitslimits) as client: # 预热别把冷启动算进去 for _ in range(10): await one_call(client) samples [] sem asyncio.Semaphore(CONCURRENCY) async def worker(): async with sem: v await one_call(client) if v: samples.append(v) tasks [asyncio.create_task(worker()) for _ in range(ROUNDS)] await asyncio.gather(*tasks) samples.sort() p lambda q: samples[min(int(len(samples) * q), len(samples) - 1)] print(fp50{p(0.50):.0f}ms p95{p(0.95):.0f}ms p99{p(0.99):.0f}ms) asyncio.run(main())基线数据并发 32、prompt 2400 token 时p50 是 1830 毫秒p95 是 2640 毫秒。GPU 利用率只有 62%这个数字本身就是线索——如果你的 GPU 没跑满但用户还在等那时间一定花在 GPU 之外。3.2 第一轮传输层和模板层第一轮我一共只动了配置文件没碰任何服务端逻辑收益 230 毫秒加 60 毫秒加 50 毫秒。先在反向代理上关掉响应缓冲。这一条我强烈建议所有做流式服务的同学检查因为默认值几乎一定是开而它对 SSE 的伤害巨大。location /v1/ { proxy_pass http://127.0.0.1:8000; proxy_http_version 1.1; proxy_set_header Connection ; proxy_buffering off; # 关键别攒缓冲区 proxy_cache off; gzip off; # 流式响应别压缩 chunked_transfer_encoding on; proxy_read_timeout 300s; }改完之后客户端 p50 直接掉了 120 毫秒。这 120 毫秒我原本以为是模型慢其实是网关在等缓冲区。然后是模板渲染。我把渲染逻辑从每个请求现场拼 Jinja改成静态部分预先渲染成字符串常量的哈希键命中就直接取。同时所有动态内容全部后移到消息末尾。改完省了 60 毫秒更重要的是这为后面的前缀缓存铺了路——如果模板每次都渲染出细微不同的字符串前缀缓存永远打不中。最后是分词。把 Python 分词器换成 Rust 实现的版本长 prompt 场景下省了 50 毫秒。这个改动在短 prompt 上几乎看不出差别所以如果你只有一个短 prompt 场景可以跳过。3.3 第二轮调度与缓存第二轮开始碰服务端参数这也是收益最大的一轮总共省了 740 毫秒。下面是我最终用的启动参数每一项后面都写了理由。vllm serve ./models/local-8b \ --served-model-name local-model \ --max-model-len 16384 \ --gpu-memory-utilization 0.88 \ --enable-prefix-caching \ --enable-chunked-prefill \ --max-num-batched-tokens 2048 \ --max-num-seqs 64 \ --disable-log-requests几个参数逐个说。显存利用率设 0.88 而不是 0.95是因为留一点余量给临时 buffer避免高峰期被抢占实战里稳定性比那 7% 的容量重要得多。分块预填充的块大小设 2048是我把 1024、2048、4096 各扫一遍之后的结果1024 时 prefill 效率太低4096 时 decode 被明显拖慢2048 是这一档的甜点。最大并发序列数设 64是配合p99 TTFT 小于 600 毫秒这个 SLO 调出来的不是越大越好。前缀缓存打开之后我做了一件事验证它真的生效了发两个完全一样的请求看第二次是不是明显更快。第一次 1830 毫秒第二次 1380 毫秒说明那 1200 token 的系统提示确实被复用了。如果你测出来两次一样快那一定是前缀没对齐回去检查动态内容有没有混在前面。3.4 第三轮KV Cache 与内核第三轮改的是数据精度和内核选择省了 440 毫秒。KV Cache 切到 FP8 之后容量翻倍同样显存能挂的并发从 24 涨到 47排队时长肉眼可见地缩短。注意力后端我从默认实现换成了一个针对长序列更友好的实现这一项单独贡献了大约 120 毫秒。顺手把 CUDA Graph 打开decode 阶段每步的启动开销被吃掉首步也随之受益这一项省了 180 毫秒左右。采样那边我把候选集做了限制省了几十毫秒。这里提醒一句KV 量化上线前一定要跑质量回归。我在一个文档问答场景里测过短问题几乎无差异但超过 8K 上下文之后答案里的数字引用偶发出错。这种问题在压测里根本看不出来只有业务评测集能抓到。3.5 收益对照表与归因说明把三轮的收益合起来就是下面这张表。p50 从 1830 毫秒降到 420 毫秒降幅 77%和标题里的数字对上了。阶段改动内容p50 变化是否改权重基线默认配置1830ms-第一轮关闭代理缓冲、直通 SSE-120ms否第一轮模板预渲染、动态内容后移-60ms否第一轮换 Rust 分词器-50ms否第二轮前缀缓存命中 1200 token-430ms否第二轮分块预填充与调度调参-310ms否第三轮KV Cache FP8-160ms否第三轮注意力后端替换-120ms否第三轮CUDA Graph 与采样优化-160ms否合计-1830ms 到 420ms全部为否必须说清楚一件事这些收益不是严格可加的。前缀缓存省下的 430 毫秒里有一部分和分块预填充重叠KV 量化的收益高度依赖并发水平如果你本来就是低并发场景它可能一点用都没有。这张表更大的价值在于给出优先级先把传输层和模板层这种零成本、马上见效的活干完再动调度最后才是精度和内核。4. 权重那一侧下载、校验、格式与 offload 的边界说完权重之外还是得把权重之内的事情聊清楚因为最容易混淆的恰恰是这条边界。很多团队在排查延迟问题时把属于运行时的问题误判成权重问题白白折腾了好几周。4.1 预训练权重下载与完整性校验先说下载。做视觉任务的同学经常需要拿预训练权重做微调起点检测、分割、自监督骨干各有各的权重文件命名和许可各不相同下载来源也五花八门。我的习惯是只在官方仓库或官方发布的镜像渠道获取下载后立刻做哈希校验并且把哈希值和来源链接一起写进项目文档。为什么这么较真因为权重文件往往是几十 G 的分片下载中断、断点续传、缓存目录软链接这几件事组合起来很容易出现文件大小看起来对、加载时缺了几个张量的情况。更麻烦的是有些框架加载时会静默忽略缺失的键你训练半天发现某一层是随机初始化的而日志里只有一行不显眼的警告。我的校验流程大概是三步。第一步核对分片数量与索引文件是否一致分片索引里列了多少个文件磁盘上就该有多少个。第二步全量哈希校验。第三步用严格模式加载一遍确认没有缺失或多余的键。# 1. 分片数量是否与索引一致 python - PY import json, os idx json.load(open(model.safetensors.index.json)) files sorted(set(idx[weight_map].values())) missing [f for f in files if not os.path.exists(f)] print(分片数:, len(files), 缺失:, missing) PY # 2. 哈希校验前提是你有一份可靠的清单 sha256sum -c weights.sha256 # 3. 严格加载有任何键不匹配立刻报错 python - PY from safetensors import safe_open import glob for f in sorted(glob.glob(*.safetensors)): with safe_open(f, frameworkpt) as st: print(f, len(st.keys())) PY这一步花你十分钟能省掉后面几天甚至几周的排查。我见过最惨的一次是某团队用了一份不完整的骨干权重做微调训练损失曲线看起来还行但下游评测一直上不去最后发现问题出在下载环节前后浪费了两周。4.2 量化改了数值offload 只改了位置这是全篇我最想讲清楚的一个区分。同样是让模型跑得动下面两类手段的性质完全不同。手段动的是什么是否改变权重数值对 TTFT 的典型影响权重量化数值精度是主要改善 TPOTTTFT 有限知识蒸馏模型结构和数值是明显但要重训结构化剪枝参数量是明显但要重训和评测权重 offload存放位置否通常变差权重 mmap读取路径否冷启动变差热态持平显存布局调整内存排布否间接靠并发容量内核替换计算实现否明显尤其是长序列这张表基本能解释为什么标题说提速发生在权重之外。真正改数值的手段一定伴随着训练、评测、发版、回滚这一整套重流程而不改数值的手段只需要改配置和代码当天验证当天上线。还有一个细节值得说量化并不总是让 TTFT 变快。INT4 权重在某些后端需要反量化反量化本身是额外计算如果这个开销大于访存节省的部分prefill 反而更慢。所以量化对 TTFT 的影响方向不确定必须实测。这也是为什么我把量化排在优化顺序的最后面。4.3 llama.cpp 里那些和权重有关的开关用 llama.cpp 的同学经常会被一堆参数绕晕我把自己常用的几个列一下并且标注它到底动了什么。llama-server -m ./models/model-Q4_K_M.gguf \ -ngl 99 \ --no-mmap \ --mlock \ -c 8192 \ -b 2048 \ -ub 512 \ --flash-attn \ --host 127.0.0.1 --port 8080-ngl决定多少层放到显存里这个参数改的是权重放哪不改数值。放得越多矩阵乘跑在更快的显存上首字越快但显存不够就只能往下调代价是变慢。--no-mmap和--mlock是一对组合拳。默认情况下权重用内存映射的方式加载好处是启动快、内存占用按需增长坏处是第一次访问某个页会触发缺页中断从磁盘读进来冷启动的第一个请求可能慢好几秒。关掉 mmap 并锁住内存可以把权重一次性读进物理内存常驻代价是启动变慢、内存占用顶格。做延迟敏感服务我通常选择后者并且在服务启动后主动发几个预热请求把页面踩热。-b和-ub这两个参数特别值得关注因为很多人压根没用过。前者是逻辑批大小后者是物理微批大小后者直接决定 prompt 处理阶段一次算多少 token。把微批调大prompt 处理速度会明显提升首字延迟跟着改善调太大则显存峰值上去可能 OOM。我在 8K 上下文下从默认值调到 512长 prompt 的处理速度提升了三成左右。这两个参数同样不改权重纯粹是计算调度。--flash-attn这类开关是换内核实现也不改权重。注意不同版本里这个参数的名字和取值形式会变用之前先看一眼帮助输出别照着旧博客抄。5. 常见问题与排查技巧实录优化做多了会发现绝大部分玄学延迟都能归纳到少数几个原因上。我把自己的排查速查表和踩过的坑整理如下。5.1 常见问题速查表现象最可能的原因处理方向TTFT 高但 GPU 利用率低排队或传输层耗时查代理缓冲、查调度队列深度首字很慢但日志显示 prefill 很快客户端到服务端的传输被缓冲关 gzip、关 proxy_buffering冷启动第一个请求特别慢权重缺页、内核自动调优预热请求、关 mmap、锁内存并发一上来 p99 就爆抢占、KV 不足、无准入控制降并发上限、扩 KV、加优先级两次相同请求速度差异大前缀缓存没命中检查动态内容是否混在前缀里p50 正常但 p99 极差长 prompt 队头阻塞开分块预填充、分离长短队列长上下文下答案质量波动KV 量化误差关 KV 量化或降量化等级这张表我贴在工位上每次接到延迟相关的反馈先按顺序过一遍能解决八成问题。5.2 三个我踩过的坑第一个坑把时间戳放进了 system prompt 开头。这个错误的破坏力我到现在还印象深刻。当时我信心满满地开了前缀缓存指标面板上缓存命中率是 0我却花了半天排查配置项最后发现是模板里一句当前时间{{ now }}把所有请求的前缀都变成了独一无二的字符串。改法很简单把那句话挪到用户消息里命中率立刻上到 92%TTFT 掉了四百多毫秒。从此我养成了一个习惯任何写进 system prompt 的内容都要问一句它对所有请求都一样吗。第二个坑以为换了量化模型就能解决首字延迟。有一段时间我执着于把模型从 FP16 换到 INT8折腾了两周TPOT 好了百分之三十TTFT 只好了百分之八。业务方的反馈是打字快了但还是等半天才出第一个字。那次之后我才彻底想明白TTFT 的主要矛盾在排队和 prefill跟权重精度关系不大。省下的这两周如果拿去调调度参数收益会大得多。第三个坑显存利用率设得太激进。我一度把显存利用率开到 0.96想把并发容量榨到极限压测数据确实好看。结果线上流量一有波峰就开始抢占KV 块被换出又换回p99 首字延迟从 900 毫秒飙到 5 秒。后来降到 0.88 并加了并发准入稳定性立刻回来了而平均吞吐只降了不到百分之五。这个教训告诉我容量参数的甜点区往往不在最大值而在略低于最大值的地方。5.3 一条可以照抄的排查顺序最后把我常用的排查顺序写出来遇到首字延迟变高的反馈我会按这个顺序往下走通常前三步就能定位。第一步客户端和服务端分别打点。如果客户端比服务端慢 300 毫秒以上问题在传输层直接去查反向代理配置和压缩设置。第二步在服务端内部把时间线切开分成排队、prefill、首步 decode、序列化四段看哪一段异常。这一步需要框架暴露细粒度指标如果没有就临时加日志。第三步看 KV Cache 使用率和抢占计数这两个数字能立刻告诉你并发是不是超了。第四步同一请求连发两次比较耗时差异判断前缀缓存是否生效。第五步用一个长度固定的极简 prompt 做对照实验如果极简 prompt 很快、真实 prompt 很慢问题就在 prompt 结构和模板上而不是计算。按这个顺序走基本不会跑偏到去改权重这条远路上。我在实际项目里的体会是推理优化这件事越靠近用户的那一层越容易被忽略但收益往往越大。反向代理的一个配置项值 120 毫秒模板里一句话的位置值 430 毫秒而花两周做的权重精度转换可能只有几十毫秒。下次再遇到首字延迟的指标报警先把 GPU 放一边从请求进入网关的那一刻开始往后捋你会发现问题大多不在显存里而在那些你从来没打开看过的配置文件里。