1. 大模型推理延迟全景：定义、关键指标与用户体验
大家好，我是你们的老朋友。今天咱们聊聊大模型推理延迟这个话题。说实话，这玩意儿是上线前必须啃下的硬骨头。我见过太多项目，模型精度刷得漂漂亮亮，一上线用户等得直骂娘——说白了，延迟没控住，一切归零。
咱们先搭个框架，把延迟这事儿看透。我习惯把大模型推理延迟拆成三个维度：定义、关键指标、对用户体验的影响。下面这张图能帮你快速建立全局认知。
1.1 什么是大模型推理延迟？
大模型推理延迟，说白了就是：从用户输入问题，到模型吐出完整回答，中间花了多少时间。你想想看，用户敲完回车，屏幕转圈圈，那几秒钟的等待，就是延迟在作祟。
我习惯把推理过程拆成三个阶段：
- 预填充阶段（Prefill）：模型把用户输入的 prompt 一次性处理，生成第一个 token 的中间状态。这个阶段计算密集，但只跑一次。
- 解码阶段（Decode）：逐 token 生成后续内容。每生成一个字，都要跑一遍完整的前向计算。这是延迟的大头。
- 后处理阶段：比如采样、去重、格式化输出。虽然占比小，但优化不好也会拖后腿。
1.2 三个关键指标：TTFT、TPOT、E2E Latency
做性能优化，不能凭感觉。你得有数据。我个人最看重的三个指标，分别是 TTFT、TPOT 和 E2E Latency。咱们一个一个说。
1.2.1 TTFT（Time to First Token）—— 首Token延迟
TTFT 指的是从用户提交请求，到模型输出第一个 token 的时间。这个指标直接决定了用户的「第一印象」。
举个例子：你打开一个聊天机器人，输入问题，等了 3 秒才看到第一个字开始往外蹦。这 3 秒就是 TTFT。如果超过 5 秒，用户大概率会关掉页面。
| 场景 | TTFT 目标 | 说明 |
|---|---|---|
| 实时对话 | ≤ 500ms | 用户期望秒回 |
| 文档分析 | ≤ 2s | 输入较长，可接受稍慢 |
| 批量处理 | ≤ 10s | 后台任务，容忍度高 |
1.2.2 TPOT（Time Per Output Token）—— 每Token延迟
TPOT 衡量的是模型每生成一个 token 所需的平均时间。它决定了回答的「流畅度」。
你想想看，如果 TPOT 是 100ms，那生成 100 个字的回答就需要 10 秒。用户看着文字一个字一个字往外蹦，那种感觉就像看幻灯片。如果 TPOT 降到 30ms，3 秒出 100 字，体验就丝滑多了。
TPOT 的优化，说白了就是跟解码阶段死磕。常见的优化手段包括：
- KV Cache 优化：避免重复计算历史 token 的 key/value。
- 量化推理：用 INT8 或 FP8 替代 FP16，减少计算量。
- 批处理（Batching）：把多个请求拼在一起处理，提高 GPU 利用率。
1.2.3 E2E Latency（端到端延迟）
E2E Latency 就是用户感知到的「总等待时间」——从点击发送，到看到完整回答。它等于 TTFT + TPOT × 输出长度 + 网络传输时间 + 后处理时间。
这个指标最贴近用户体验。我习惯用 P50、P95、P99 分位数来评估：
- P50：一半用户能享受到的延迟水平。通常作为优化目标。
- P95：95% 的用户体验。如果 P95 太高，说明有「长尾延迟」问题。
- P99：最差情况。P99 超过 10 秒，基本就属于事故了。
1.3 延迟对用户体验的影响
聊完指标，咱们说说「人」的感受。延迟对用户体验的影响，我总结为三个层次：
- 感知层（0-1s）：用户觉得「秒回」，体验极佳。TTFT 控制在这个范围内，用户会认为系统很智能。
- 容忍层（1-5s）：用户开始不耐烦，但还能等。如果 TPOT 流畅（文字连续输出），用户会认为「虽然慢了点，但还在工作」。
- 流失层（>5s）：用户直接关页面。我见过一个数据：延迟每增加 1 秒，用户流失率增加 7%。
这里有个容易被忽略的点：感知延迟 ≠ 实际延迟。你想想看，如果模型先快速吐出第一个 token（TTFT 低），然后文字流畅地逐字出现（TPOT 低），用户会觉得「好快」。反过来，如果 TTFT 很高，但后面输出很快，用户也会觉得「卡了一下」。所以，TTFT 是用户体验的「第一道防线」。
好了，这一章的内容就到这里。咱们把延迟的定义、三个核心指标（TTFT、TPOT、E2E）、以及它们对用户体验的影响都捋了一遍。下一章，我会带大家深入推理引擎的内部，看看延迟到底是怎么产生的——嗯，到时候咱们再细聊。
公众号:蓝海资料掘金营，微信deep3321