大模型首字慢和出字慢是两回事吗？

4 个讲解板块 · 关联 2 款站内工具 · 内容最后核对 2026-10-09

等第一个字是 prefill 的事，字往外蹦的速度是 decode 的事，两者调的参数完全不同。

直接答案

因为延迟本来就有两段，而且这两段卡在不同的硬件资源上。第一段叫 prefill，模型一次性读完整段提示词并建立缓存，这段是算力受限的，输入越长越慢，它决定你等多久看到第一个字。第二段叫 decode，模型一个字一个字往外吐，每吐一个字都要把全部权重和缓存重新读一遍内存，这段是显存带宽受限的，它决定字往外蹦的速度。

分清之后排查就简单了：如果用户抱怨「半天不出字」，那是 TTFT 问题，先看提示词是不是太长、是不是在排队等批次；如果抱怨「出字像挤牙膏」，那是 TPOT 问题，跟输出长度和显存带宽有关。这两种抱怨对应的优化手段几乎没有重叠，用同一套办法去治，多半是白费力气。

同一个模型、同一台机器，有人测出「快到飞起」，有人测出「慢得要死」，往往只是因为他们量的是不同的东西：一个报了出字速度，一个报了首个字的等待时间。这两个指标在流式输出里是分开计量的，平均值一混，问题就藏起来了。

把端到端延迟写成一行公式，问题立刻清晰：总时间约等于首字延迟加上每字耗时乘以输出字数。三个量各自对应不同的瓶颈，也各自对应不同的调参动作。

快速跳转三个指标各管一段为什么输入长只拖慢开头对着症状调参数一个容易忽略的参照系

1三个指标各管一段

流式输出把一次请求切成两段计时，所以至少要报两个数才说得清快慢。

指标	量的是什么	主要受谁影响
首字延迟（TTFT）	从发出请求到第一个字出现	提示词长度、排队等待、prefill 算力
单字耗时（TPOT）	第一个字之后每字之间的平均间隔	显存带宽、模型精度、并发批次
吞吐（tokens/s）	整台机器每秒产出的总字数	批次大小、并行度，与单请求感受无关

端到端总时长 ≈ 首字延迟 + 单字耗时 × 输出字数。输出 400 字、每字 30 毫秒、首字 400 毫秒，总时长就是约 12.7 秒。

2为什么输入长只拖慢开头

两段计算的性质不同，一个吃算力，一个吃带宽。

prefill 是算力受限: 整段提示词并行过一遍网络，算力单元跑满，所以耗时跟输入长度近似成正比：3200 字约 400 毫秒，16000 字就接近 2 秒。
decode 是带宽受限: 每生成一个字，都要把全部权重从显存里重新读一次，算的量却很小。所以加算力没用，得加显存带宽或者把权重压小。
排队会同时污染两个指标: 并发高的时候，请求要先等一个批次名额，这部分等待通常也算进首字延迟里，于是「空载很快、有负载就慢」成为典型症状。
连续批处理改变曲线: 按字粒度收放请求，能让吞吐上去了而单请求延迟不明显变差，这是它跟朴素批处理的最大区别。

3对着症状调参数

先判断是哪一段拖后腿，再决定动手改什么。

症状	大概率原因	先动什么
只有第一次请求慢，之后正常	模型权重冷加载	保持实例常驻，避免冷启动
输入长时首字慢，输出短时也一样	prefill 压力	压缩提示词、复用固定前缀、开前缀缓存
空载快、并发一上来就慢	排队等批次名额	加副本或做准入控制，别一味加大批次
首字正常但总时长很长	输出太长	收紧输出上限，让模型少写废话

用户感受上，「静默等第一个字」比「字慢慢往外蹦」更难受。所以同样的开销，优先花在首字延迟上，收益更大。

4一个容易忽略的参照系

人读字的速度比大多数人以为的慢得多，这决定了优化到什么程度就够了。

阅读速度是天花板: 成年人默读非虚构类材料约每分钟 238 词，折算约每秒 5 个词。所以每秒 20 个字的输出速度已经快过阅读，再往上压单字耗时，用户基本感知不到。
但等待的第一印象很重要: 换成朗读或播报场景，人耳需要更慢的节奏，反而不该追求极限速度。
批量任务看的是另一套账: 离线跑数据不看首字，只看整机吞吐；这时候把批次开大、牺牲单请求延迟是划算的。