首Token延迟(TTFT)：决定AI产品体验的关键性能指标

我们一直在测错延迟

在评估AI模型或应用的性能时，大多数人本能地关注同一个数字：一次响应从开始到结束花了多长时间。这是最直观的指标，却几乎与交互式使用体验无关。

一位Reddit开发者分享了他长期以来的误区，也道出了许多工程师的盲点：真正决定用户感受的，是首Token延迟（Time To First Token, TTFT）——即从你按下回车，到屏幕上出现第一个字符之间的那段间隔。

这个洞察看似简单，却直击AI产品体验设计的核心。一旦token开始流动，你的大脑就会认定「系统在工作」，并开始阅读输出内容。于是一个300毫秒内开始、20秒后才完成的响应，感觉上是「快」的；而一个3秒后才开始、12秒就完成的响应，反而感觉「慢」——尽管后者客观上更快。

你测量的是总时长，你感受的是开场时刻。 这两者之间的错位，正是无数AI产品体验不佳的隐藏根源。

reddit source

为什么TTFT才是那个「唯一重要」的数字

这个观点之所以值得深入，是因为它牵连出一系列容易被忽视的工程后果。

缓冲的代价被严重低估

路径中任何一处的缓冲（buffering）都比图表上看起来昂贵得多。任何在传递之前先收集完整响应的中间层，都会把一次「感觉很快」的交互变成「感觉很慢」的交互，而对总时长几乎毫无影响。

换句话说，如果你正在评估任何位于你与模型提供商之间的组件（如代理层、网关、路由服务），TTFT才是应该测试的关键属性——而它绝不会出现在任何测量完成时间的基准测试里。

服务降级的第一征兆

TTFT还是提供商性能劣化的早期预警信号。在状态页面变红之前，TTFT就已经开始漂移：排队增加、调度延迟拉长，但请求最终仍能正常完成，所以什么都不会被记录为「事故」。

如果你只盯着总时长和错误率，你会完全错过一个糟糕的时段——而用户的体验正在悄然恶化。这对运维监控体系提出了一个明确要求：把TTFT纳入核心可观测性指标。

TTFT（Time To First Token）在技术层面指的是：从客户端发出完整请求，到服务端返回流式响应的第一个token所经历的时间。它本质上由两部分构成：网络往返延迟（请求到达服务器的时间）和服务器端排队+预填充时间（模型处理输入prompt、完成KV Cache计算并生成第一个输出token的时间）。与之对应的另一个常用指标是TPOT（Time Per Output Token），即每生成一个后续token的平均耗时，它决定了流式输出的「字符滚动速度」。总响应时间（Total Latency）大致等于 TTFT + TPOT × 输出token数。在输出较长时，TPOT对总时长的贡献远大于TTFT，这正是为什么单看总时长会系统性地误导工程师——它把一个对用户感知几乎无关紧要的尾部成本，与真正决定「第一印象」的前置成本混在了一起。

推理模型如何打乱整个框架

说个细节，当下流行的推理模型（reasoning models）彻底改变了这套逻辑。

如果一个模型在输出前需要「思考」，那么按经典定义计算的TTFT可能长达数秒，即便一切正常运转。这时问题的关键就转移了：这段等待被用户读作「卡住了」还是「在工作」，几乎完全取决于界面是否在等待期间给用户展示了些什么。

同样的延迟，不同的体验，由UI决定。 这解释了为什么ChatGPT、Claude等产品会展示「思考中」的动画或流式输出推理过程——这不是装饰，而是对抗高TTFT感知的必要手段。

推理模型（如OpenAI o系列、DeepSeek-R1）的核心机制是在生成最终答案前，先产生一段内部「思维链」（Chain-of-Thought）。这段思维链有时长达数百乃至数千个token，全部在模型内部完成后才开始输出用户可见的答案。从TTFT的角度看，这意味着即便模型本身运行正常，用户也可能等待5-30秒才看到第一个有意义的输出。主流产品的应对策略分为两类：一是流式暴露思维链（如Claude的「Extended Thinking」模式），让用户实时看到模型的推理过程，从而把高TTFT转化为「正在认真思考」的感知；二是展示占位动画，用视觉反馈填充等待空白。这两种策略本质上都是通过UI层的信息设计，将客观的高延迟重新诠释为「高投入感」，是感知工程（perception engineering）在AI产品中的典型应用。

平均值在撒谎，p95才诚实

作者提出了一个尖锐的批评：平均值掩盖了你真正关心的东西。

TTFT的分布是高度倾斜的——一个漂亮的中位数配上一条丑陋的长尾，会让人觉得不可靠；而一个稍差的中位数配上收紧的尾部，反而让人觉得稳定。原因很简单：人们记住的是那些糟糕的交互。

因此：

p95是诚实的数字——它反映了那5%最差体验的真实状况
均值是讨好人的数字——这大概正是它被普遍发布的原因

对于任何认真对待用户体验的团队，这是一个应当写进性能报告规范的原则：报告分位数，而非平均值。

p95（第95百分位数）是统计学中的分位数指标，意指在所有测量样本中，有95%的请求延迟低于该值。换言之，p95反映的是「最差的那5%用户」所经历的延迟上界。在延迟分析中常用的分位数还包括p50（中位数）、p99和p99.9。TTFT的分布通常呈现右偏长尾特征：绝大多数请求集中在较低延迟区间，但极少数受排队、GC停顿、网络抖动等影响的请求会产生极高延迟，将均值大幅拉高。由于均值对离群值极度敏感，一次10秒的超时就能将一千次200ms请求的均值拉高到210ms，而p95则基本不受影响。Google的SRE实践和亚马逊的内部规范均明确要求使用高分位数（p99或p99.9）而非均值作为SLA定义依据，正是出于同样的考量。

一个尚未解决的难题

作者坦言自己运营着一个会增加「一跳」（hop）的中间层项目（routera.one），而「一跳」恰恰是那种如果构建得草率、就会悄悄毁掉TTFT的东西。因此他对这个指标格外敏感——路径中的任何东西都必须在这个指标上「证明自己配得上一席之地」。

他也诚实地划定了适用边界：对于批处理或后台任务，以上一切都不成立。当没有人盯着屏幕时，优化TTFT就是浪费精力，此时吞吐量和成本才是正确的指标。TTFT的统治地位，专属于交互式编码等「开场时刻主导一切」的场景。

最后，他抛出了一个开放性的产品难题：如何在不训练用户忽视你的前提下，向他们传达「提供商变慢了」这一信息？

每当p95上升就弹警告，一周内它就会变成没人看的「墙纸」
什么都不显示，用户又会把别人造成的糟糕下午算到你的产品头上

这是一个没有干净答案的问题，也是每个构建AI基础设施的团队都会遇到的真实困境。

写在最后

这篇讨论的价值在于，它把一个被工程师群体系统性忽视的指标推到了台前。在大模型能力日趋同质化的今天，交互延迟的「感知质量」正在成为产品差异化的关键战场。

记住这几条原则：测量TTFT而非总时长、用p95而非均值报告、把TTFT作为服务降级的早期哨兵、并用UI设计弥补推理模型的先天延迟。这些看似细微的取舍，最终决定了用户觉得你的产品是「快」还是「慢」。