面试官问“你的大模型流式输出第一个字要等几秒”“4 年大模型应用经验精通流式输出与 SSE做过多轮对话产品的低延迟优化。”看到这份简历我问了个很具体的问题你线上那个产品用户点发送到看见第一个字平均等几秒由什么决定候选人愣了一下说这个……没专门测过应该挺快的吧加了流式嘛。加了流式不等于知道首字多快。首字延迟(TTFT, Time To First Token)是流式产品体验的命根子但真正打开 logs 算过自己 TTFT 的人不多能说清它由什么决定的更少。我面过不少做对话产品的候选人简历都写着低延迟优化可一问首字延迟到底由输入决定还是输出决定对半开都答不上。今天这场面试就把第一个字背后的事讲透。Round 1加了流式输出模型真的变快了吗面试官“你给产品接了流式输出用户反馈快多了。模型真的变快了吗”候选人“流式嘛边生成边返回不用等全部生成完肯定快了。”正解答了一半。模型生成同样长度内容的总时间几乎没变分块推送甚至让总时间略微增加。流式真正改变的是用户的感知等待。把一次生成拆成两段时间看用户从点发送到看见第一个字是首字延迟(TTFT)看见第一个字之后字与字之间往外蹦的间隔是字间延迟(ITL, Inter-Token Latency也叫 TPOT)。非流式下用户的等待锚点是端到端总时间(E2E)要等最后一个字生成完才一次性看到整段。流式把这个锚点从 E2E 挪到了 TTFT第一个字出来用户就觉得开始了剩下的字在阅读过程中陆续补齐。所以流式优化的从来不是吞吐是把用户盯着的那个数字从总时长换成了首字。这也意味着 TTFT 一旦很慢流式的体验红利当场归零用户照样对着空白转圈。这里还有个容易被忽略的点TTFT 和 ITL 对体验的作用并不一样。TTFT 决定用户愿不愿意等第一个字迟迟不来人就想划走ITL 决定读起来顺不顺字间隔只要快过人的阅读速度(中文大约每秒读 5 到 10 个字)用户就感觉不到卡顿再快他也读不过来。这两个数不是越小越好TTFT 要尽量压低ITL 压到比阅读速度略快就够了多出来的算力留给吞吐更划算。至于总时间为什么不降反略增非流式把整段算完一次性返回流式要把结果切成几十上百个 chunk逐个走一遍网络协议(通常是 SSE)推给前端这些分块和传输的小开销累加起来让端到端总时间比非流式还多那么一点。流式从头到尾算的是体验账不是性能账。这件事 30 秒能自验证。任何兼容 OpenAI 的接口开streamTrue记下第一个有内容的 chunk 到达的时间import timefrom openai import OpenAIclient OpenAI()t0 time.time()stream client.chat.completions.create(model“…”, messages[{“role”: “user”, “content”: “讲讲注意力机制”}],streamTrue,)for chunk in stream:if chunk.choices[0].delta.content:print(fTTFT {time.time() - t0:.3f} 秒) # 第一个字到达立刻停break跑几次取中位数这就是你产品里用户每次都要先吞下的那段等待。要点速记流式不改总时间(E2E)分块推送甚至略增改的是用户的感知等待两个核心指标TTFT(首字延迟prefill 主导) ITL(字间延迟decode 主导)流式把用户的等待锚点从 E2E 总时长挪到 TTFT第一个字越快体验越好自验证streamTrue记第一个有内容 chunk 的到达时间3 行代码Round 2首字延迟由什么决定输出设到 4000 token第一个字会更慢吗面试官“同一个模型什么情况下 TTFT 会变长我把 max_tokens 从 200 调到 4000第一个字会等更久吗”候选人“输出设长了模型要算的多第一个字应该也慢吧或者就是模型大、机器不够快。”正解这是最常见的误解。TTFT 几乎只由输入长度决定和你要生成多长输出基本无关。max_tokens 从 200 调到 4000第一个字到达的时间几乎不动。要理解为什么得把推理拆成两个阶段。第一阶段 prefill(预填充)模型在吐第一个字之前必须先把你的整个 prompt 读一遍一次前向并行地算出所有输入 token 的 Key/Value建好 KV cache。这一步是高度并行、吃算力的(compute bound)耗时随输入长度上涨。注意力的矩阵乘随序列长度近似二次方增长每个 token 都要和前面所有 token 算一遍相关性n 个 token 就是 n×n 量级的计算输入长度翻倍、这部分计算量翻四倍prompt 越长 prefill 越重。prefill 跑完第一个 token 才出生。第二阶段 decode(解码)从第二个字开始逐 token 自回归生成每个字都要把模型权重搬一遍(memory bound)这一步的快慢决定字间延迟 ITL和首字无关。把这两段对上指标就清楚了TTFT 反映的是 prefillITL 反映的是 decode。你设的 max_tokens 只影响 decode 要跑多少轮碰不到 prefill所以动不了首字。真正动首字的是输入prompt 模板、对话历史、塞进去的 RAG context。一个 32K token 的长 prompt光 prefill 在 H100 上跑一个 70B 模型就要 200-400 毫秒(业界工程测算2026)输入再长到 100K 量级prefill 直接吃掉好几秒。顺带说清 prefill 和 decode 撞的是两堵不同的墙。prefill 时整个 prompt 的所有 token 一次性并行进 GPU几千个 token 的矩阵乘同时开算算力被喂得满满当当瓶颈在算得过来算不过来。decode 时一次只生成一个 token却要把整个模型的权重从显存搬一遍才换来这一个字算力大量闲着瓶颈在显存带宽够不够快。同一个模型、同一张卡两个阶段卡在完全不同的资源上。这也是为什么有些团队开始把两阶段拆到不同硬件分开伺候(disaggregated serving)让 prefill 吃算力、decode 吃带宽各自吃饱。这条对 RAG 产品尤其致命。你为了答得准往 prompt 里塞十几段检索结果每多塞一段用户的首字就多等一截。更隐蔽的是RAG 的 TTFT 不只有 prefill用户请求进来后还要先把 query 转成 embedding、去向量库检索、可能再 rerank、最后拼装 context这一长串都发生在模型看到 prompt 之前。有一组 RAG 延迟拆解显示在大向量库加重排序的架构下检索加上拼进来的长 context能占到 TTFT 的 45%-47%(Redis 工程拆解2026)换个架构这个比例会变prefill 自己反而占大头的情况也很常见。但方向是确定的你以为慢在模型其实有一截慢在你自己喂进去的那堆 context 和取它的过程。这题也能自验证固定一句话的输出把 prompt 从 100 token 灌到 10000 tokenTTFT 会肉眼可见地涨反过来固定 prompt、把 max_tokens 从 200 拉到 4000TTFT 基本纹丝不动。一来一回两个对照胜过背十遍定义。要点速记TTFT 几乎只由输入长度(prefill)决定与 max_tokens / 输出长度无关prefill把整个 prompt 并行算 KVcompute bound随输入长度近似二次方变重 → 决定 TTFTdecode逐 token 搬权重memory bound → 决定 ITL不碰首字32K prompt 在 H100 上跑 70B 模型 prefill 约 200-400ms100K 级别吃几秒RAG 重灾区某些架构下检索 长 context 可占 TTFT 的 45%-47%(Redis 实测)慢在喂进去的 contextRound 3线上 p99 首字延迟飙到 8 秒怎么定位、怎么压下来面试官“你产品 p99 TTFT 8 秒用户投诉一点就卡。给我一套排查到优化的路径别只说换模型加机器。”候选人“那就换个推理快的模型或者多堆几张卡扛并发”正解换模型加机器是最贵也最不对症的一招。先把 TTFT 拆开看它到底耗在哪一个请求的首字延迟约等于网络 排队等待 prefill 计算。8 秒的锅是排队还是 prefill决定了完全不同的打法。先看是不是排队。高并发下最隐蔽的杀手是队头阻塞(head-of-line blocking)一个超长 prompt 进来,它的 prefill 占满 GPU 这一拍,排在后面的所有请求只能干等。结果就是 TTFT 呈双峰分布,p50 看着挺正常,p95/p99 比 p50 差 5-10 倍(vLLM/Spheron 工程数据,2026)。所以排查第一步是看 p95/p99 而不是平均值看到双峰基本就是排队问题。排队问题的解法是chunked prefill(分块预填充)把一个长 prompt 的 prefill 切成固定大小的块(vLLM 新版默认每批 2048 token旧版是 512)块与块之间插进其他请求的 decode 步让长 prefill 不再独占一整拍。这套思路源自 Sarathi-ServevLLM 新架构(V1)已经默认打开不用再手动加开关。这里有个最容易被讲错的点它真正改善的是尾部p95/p99 的 TTFT 会明显被压下来代价是 p50 可能略微变高因为原本一口气算完的 prefill 被切开、和别人的 decode 交错了。它治的是双峰里那条长尾而平均首字未必更快。靠--max-num-batched-tokens调每批 token 预算来平衡 TTFT 和 ITL盯着 TTFT p95 看效果。chunked prefill 也不是免费午餐要懂它的取舍。不切块时调度器一拍要么集中算某个请求的 prefill要么集中做 decode长 prefill 占住一整拍正在 decode 的请求就被晾着、ITL 变差。切块之后长 prefill 被拆开和 decode 交错进同一拍正在输出的请求不再被一个长 prefill 卡死尾部 TTFT 和 ITL 都稳住了代价是这个长 prompt 自己的 p50 首字慢一丁点。但它只解决算力层的阻塞解不了显存压力长请求的 KV cache 还是一块块往上堆显存一旦耗尽调度器照样退回阻塞老路TTFT 又抖起来。所以它是缓解不是根治真扛不住还得配合缩短输入和扩容。再看 prefill 本身能不能省。最有效的一招是prompt caching / 前缀缓存(prefix caching)把已经算过的 prompt 前缀的 KV cache 存下来下次来的请求只要前缀一样直接复用跳过这部分 prefill。命中缓存时 TTFT 降幅非常夸张。一个公开实测里给同一个约 10000 token 的 prompt 发第二次TTFT 从 4.3 秒掉到 0.6 秒(llm-d 官方 benchmark, Qwen3-32B, 2026)也有工程师分享过自己生产 agent 流量打开 vLLM 前缀缓存后某个租户 TTFT 从 480ms 降到 110ms。vLLM、SGLang(靠 RadixAttention)、TensorRT-LLM 都开箱支持自动前缀缓存。但前缀缓存有两个坑没踩过的人最容易栽第一缓存失效是二元的按前缀逐块匹配。position 0 改一个 token整条前缀的缓存全废没有模糊匹配。原理是缓存按 KV 块组织成一棵前缀树新请求从根节点逐块往下匹配前面任何一块变了后面整条路径都对不上只能重算。所以要把稳定的内容(system prompt、工具定义)放最前面当固定前缀把用户输入、时间戳这类每次都变的东西放最后。上面那个 agent 案例里另一个租户开了缓存 TTFT 纹丝不动差别就在他把变量塞在了 prompt 开头。第二缓存默认是单节点的。4 个节点 round-robin 负载均衡按概率同一个 prompt 有 3/4(75%)的请求会打到没预热这条前缀的节点。多副本部署要配合按前缀路由否则缓存命中率全被负载均衡稀释掉。把这套整理成一张排查表TTFT 耗在哪典型信号对症手段排队等待p95/p99 远高于 p50双峰分布chunked prefill、按 token 预算调度、扩容prefill 计算低并发下首字也慢prompt 很长prompt caching / 前缀缓存、缩短输入输入过长RAG / 长对话历史context 几 K 起减少检索条数、压缩 prompt、history 截断缓存不命中接了缓存但 TTFT 没降稳定内容前置、按前缀路由、监控命中率落地顺序先看 p95 分清排队还是 prefill再决定上 chunked prefill 还是前缀缓存最后才考虑缩输入和扩容。监控盯三个数TTFT p95、缓存命中率、每副本缓存利用率命中率一掉就是流量变了或 prompt 模板被改了。要点速记TTFT ≈ 网络 排队 prefill先拆清楚耗在哪再动手别一上来换模型排队信号p95/p99 远高于 p50(双峰)队头阻塞所致 → chunked prefill(默认切块专压 p95/p99 尾部p50 可能略升)prefill 省钱前缀缓存命中可让 TTFT 从 4.3s→0.6s(10K prompt)、480ms→110ms(生产 agent)缓存两大坑失效二元(position 0 改一字全废稳定内容前置)、默认单节点(多副本要按前缀路由)监控 TTFT 看 p95 不看 p50盯缓存命中率Round 4reasoning 模型先想后答用户看到的第一个字还算 TTFT 吗面试官“现在推理模型先输出一大段思考再回答。用户盯着屏幕他感知到的第一个字是思考还是答案你那个 TTFT 指标还准吗”候选人“还是 TTFT 啊第一个 token 出来就算。”正解这题问的是指标的语义候选人答的是指标的定义正好错过了重点。reasoning 模型把 TTFT 的意义悄悄改写了。传统 TTFT 量的是第一个 token 到达。但 reasoning 模型在给出答案前会先生成几百到几千个思考 token。如果你的产品不把思考过程展示出来用户要一直等到整段思考链 decode 完、答案的第一个字才冒出来。这时用户真正感知到的首字延迟等于 prefill 加上整段思考的 decode 时间可能是几秒到几十秒和传统意义上零点几秒的 TTFT 完全不是一个量级。所以 reasoning 时代要拆成两个指标看一个是 TTFT(第一个 token很可能是思考的开头)另一个是首个答案 token 延迟(用户真正等的那个数)。很多推理产品干脆把思考过程也流式展示出来本质就是用第一个指标去糊弄用户的耐心别让他对着空屏干等几十秒。这又绕回流式那点老把戏它没让模型变快只是给了用户一个已经开始了的信号。往深一层这件事暴露了自回归推理的根脖子思考越长用户等得越久因为思考 token 也得逐个串行吐。要么靠展示思考来掩盖延迟要么从范式上动刀比如让思考过程并行生成的扩散语言模型(dLLM)。但那是另一场面试的题了。落到监控上也要跟着改还盯着传统 TTFT你会以为推理产品首字零点几秒、体验很好实际用户在等几十秒的思考。reasoning 产品该把首个答案 token 延迟单独拉出来当一级指标传统 TTFT 退居二线。要点速记reasoning 模型改写了 TTFT 语义第一个 token 可能是思考开头不是答案用户真正感知的是首个答案 token 延迟 prefill 整段思考的 decode可达几秒到几十秒产品对策把思考过程也流式展示别让用户对着空屏干等监控要把首个答案 token 延迟当一级指标传统 TTFT 退居二线根因仍是自回归逐字串行想彻底解决得换并行范式(如 dLLM)面试官点评这位候选人有流式产品的实操经验方向感不差但对首字延迟的理解停在接了流式就快了这一层没穿透到 prefill/decode 的分工。这正是低延迟优化的分水岭知道 TTFT 由输入决定的人会去砍 context、上缓存不知道的人只会换模型加机器钱烧了首字还是慢。给几条可执行的建议先把自己产品的 TTFT p95 测出来(上面 3 行代码就够)再按 prompt 长度分桶看你会发现长 context 请求的首字是短请求的好几倍。接前缀缓存前先审一遍 prompt 模板稳定内容(system prompt、工具定义)是不是都在最前面变量是不是都在最后。模板不对缓存白接。上线一个 TTFT p95 缓存命中率的看板。这俩数一起看比任何单点优化都更早暴露问题。如果做的是推理模型产品单独埋一个首个答案 token 延迟的指标别用传统 TTFT 自我安慰那个数好看却不是用户真正在等的那段时间。回头看这四个问题其实是同一件事的四个切面流式产品的体验几乎全压在第一个字之前那段你看不见的时间上。这段时间里模型在读你的 prompt、在排队等 GPU、在缓存里翻有没有算过的前缀唯独没在生成你真正要的答案。它由输入长度决定、与输出长度无关能靠缓存和调度大幅压缩还会被 reasoning 的思考链整个改写。把这段时间拆开、量出来、压下去往往比换一个贵一倍的模型实在得多。接了一年流式很多人优化的从来不是模型快了多少而是用户从哪一刻开始看到字。流式把用户的注意力从总时长偷偷换成了首字这是个聪明的障眼法。可一旦第一个字本身要等一整段思考这个障眼法就穿帮了到那时候要么把思考摊开给用户看要么换一个不用逐字排队的生成范式。面试时能把流式讲顺的人不少但能说清第一个字之前到底发生了什么的人不多。后者优化延迟时手里有的是刀而不是只有钱包。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】