首 Token 延迟和吐字速度分别由什么决定？怎么优化

先这样答

两个指标要分开看。首 token 延迟（TTFT）是从用户发出请求到看到第一个字的时间，消耗在三处：排队等待、对整个提示词做一遍预填充、网络往返。提示词越长预填充越久，这一步是计算密集型，瓶颈在算力。吐字速度是第一个字出现之后每秒能吐多少 token，解码阶段每生成一个 token 都要把模型权重完整读一遍，瓶颈在显存带宽。一个是算力问题，一个是搬运问题，优化手段不同。

按瓶颈对号入座。降首 token：用前缀缓存跳过公共开头的预填充、压缩提示词长度、用分块预填充避免一条长请求堵住整个服务、调度上让短请求优先。提吐字：加大批处理摊薄每次读权重的成本、量化减少要搬的字节数、投机解码让一次前向出多个 token。两边共同的硬基础是更快的卡和更大的带宽。

RAG（检索增强生成）场景的首 token 问题最典型：检索回来的文档把提示词撑得很长，预填充时间跟着涨。对策是控制检索条数、对文档做压缩摘要、稳定说明部分走前缀缓存，把有效提示词长度压下来。总结一句：先分清指标归属，TTFT 看预填充和排队，吐字看带宽和批调度，再按瓶颈选手段。

面试官会怎么追问

• 「为什么提示词翻倍，首 token 延迟不止翻倍？」 预填充的计算量随序列长度平方增长，每个位置都要和它前面所有位置做注意力。提示词越长，超线性越明显，这是长上下文服务必须做预填充优化的原因。
• 「批处理为什么影响吐字速度？」 批越大，一次权重读取同时服务的请求越多，带宽摊得越薄，总吞吐越高；但单个请求分到的算力变少，每步变慢。在线对话会把批控制在保吐字速度的范围，离线任务才放开冲吞吐。
• 「预填充和解码能分开部署吗？」 能，叫预填充与解码分离：预填充吃算力、解码吃带宽，瓶颈不同就放到不同的机器组上各配各的硬件，组间传递 KV Cache。大流量服务里已经是常见架构。

回答的坑

• 拿吞吐当吐字速度。吞吐是全系统每秒完成的 token 总量，吐字速度是单个用户感受的节奏，提批提吞吐常常会压低吐字速度，两个数要分开报。
• 一遇延迟就加卡。排队和长提示词造成的首 token 延迟，靠前缀缓存和提示词瘦身就能砍掉一大截，先看瓶颈再花钱。