Kimi K3 延迟

首 token 延迟

五次流式运行，极简提示词（"Count to three"），输出上限 128 token：

TTFT 中位数是 2.82s。但看中间那列：五次里有三次从头到尾没吐出一个正文 token。这不是延迟问题——这是推理预算陷阱的现场抓拍。128 token 的上限被思考全部吃光，流结束时只输出了推理内容。如果你正在把 K3 流式返回给用户，静默失败长的就是这个样子。

首个 token 和首个正文 token 之间的间隔，才是决定体感速度的那部分：第 1 轮里，推理在 2.74s 就开始了，但回答直到 4.62s 才出现。如果你把 reasoning_content 渲染出来，用户在约 2.8s 就能看到动静；不渲染，他们就得对着转圈动画干等约 4.6s。

2026-07-18 复测：真实提示词是另一个量级

两天后我们跑了更大的一轮：每个端点十次流式运行，每次用不同的真实提示词（一个"用两句话解释"类任务——K3 真正会思考的那种），无缓存命中，同时覆盖 EvoLink 的两个端点：

这轮在 2026-07-16 数据之上补充了三点：

• 提示词复杂度能把 TTFT 拉开 3–4 倍。同一天、同一客户端，极简提示词的首 token 仍是约 3.35s;一旦要求真正思考，首 token 中位就落到 11.3s。按你真实要发的提示词做预算，别按跑分用的那种。
• 波动极大。单次运行的首个正文 token 在 2.9s 到 40s 之间。p95 约 36s 意味着每二十次调用就有一次让用户等半分钟才见到第一个字——除非你流式展示推理或做进度反馈。
• 主端点名副其实。direct.evolink.ai 每项中位数都优于备用端点 api.evolink.ai，分布中段约快 4s。生产用 direct，把 api 留作文档写明的备用。

TTFT 剧烈波动的同时吞吐却很稳:正文一旦开始，两个端点、两天实测都是每秒 15–18 token。等待集中在最前面,流本身没问题。想比较网关？同一协议也用同题配对方式跨两个窗口打过 OpenRouter——排不出稳定赢家。EvoLink 自己的中位数也从第一个窗口的 21.4s 漂到一小时后的 31.1s——时段漂移和两家网关之间的差距是同一个量级。

长上下文

非流式，输出极短，所以这基本等于「K3 读完你的提示词、想完这件事，要多久」：

总耗时随提示词变长

单次调用耗时（秒），输出极短 · 实测于 2026-07-16

50 万 token，一次请求就是 52 秒加 $1.49——这还是在 K3 动笔之前。百万 token 窗口是真的，但它既不快也不免费——token 量约 5 倍，总耗时也约 5 倍，照这个走势，逼近 1M 上限时大概率要接近两分钟。这一档我们没测；没测就只能算推算，不算实测。

快不快靠设计，不靠缓存

一个合理的期待：把前缀预热好，省掉那部分计算，把延迟赚回来。我们测了，不成立。相同前缀下对比冷、热调用，总耗时并没有稳定变快——3.56s→3.80s，3.02s→4.29s，3.99s→3.54s，4.38s→4.27s，5.22s→3.78s。轮次间的波动完全盖过了缓存的影响。

原因是结构性的：不管提示词有没有命中缓存，K3 每次调用都要花好几秒推理，这才是时间线的大头。缓存优化的是账单，不是延迟。

2026-07-18 在 1.2k 到 70k token 四档前缀上复证:每次热调用都命中缓存(账单可查),TTFT 依旧没有一致改善——一档变快,三档没有。

该怎么做

• 永远开流式。长上下文不开流式，等于让用户干等一分钟。stream: true，再加 stream_options: {"include_usage": true}。
• 客户端超时设到分钟级。SDK 的默认超时会把正常的长上下文调用直接掐死。我们实测过一次成功的请求跑了 52s。
• 想清楚推理间隙怎么处理。极简提示词下首个推理 token 约 3s，真实提示词中位 11s，首个正文 token 还要再等数秒到数十秒。要么把思考过程展示出来，要么让进度 UI 做好 p95 等上几十秒的准备。
• 别把 K3 放进有人在干等、时间预算又紧的同步请求链路。它要思考，这正是它的卖点。
• 精简你的上下文。延迟随提示词长度增长，而且和成本不一样，没有缓存折扣帮你兜底。

这些数字不代表什么

它们不是基准测试。单一客户端、单一网络路径、两天、每档样本量一到十次。数字里叠着我们到月之暗面（Moonshot AI）服务器的线路状况，以及月之暗面当时扛着的负载——2026-07-16 以及两天后,一款全新旗舰模型想必都不清闲。

主导这里每一个数字的，都是以秒计的 K3 思考时间。网络链路——包括经过一层透传网关的那一跳——相比之下只是毫秒级，所以我们把这些数字当作 K3 本身的耗时，而不是某个接入点的。我们在哪跑的。

请把它们当量级看，而不是对模型的精确测定：极简提示词的首 token 是秒级不是毫秒级,真实提示词是几十秒级；100k 上下文是几十秒不是几秒；500k 是一分钟上下不是十秒。这就是它的轮廓，拿来做设计决策已经够用。我们已经重测过一轮——上面的 07-18 数据——并会持续重测、更新日期戳。

Kimi K3 延迟 FAQ

Kimi K3 API 有多快？

取决于提示词。极简提示词实测首 token 中位约 3 秒（2026-07-16 为 2.8s，07-18 复测 3.35s）。真实提示词下，2026-07-18 实测首个推理 token 中位 11.3s、首个正文 token 中位 21.4s（n=10，p95 35.7s），正文开始后吞吐中位 18.4 token/秒。第一个 token 永远是推理而不是回答。这些是单客户端实测，不是基准测试。

Kimi K3 处理长上下文要多久？

我们实测 98,625 token 的提示词耗时 10.5 秒，497,718 token 耗时 52.0 秒，两次输出都极短。增长看起来大致线性，所以完整的 1,048,576 token 窗口很可能接近两分钟，但这一点我们没有实测。

提示词缓存能让 Kimi K3 变快吗？

不能。相同前缀下对比冷、热调用，总耗时并没有稳定改善，有些热调用反而更慢。不管有没有命中缓存，K3 每次调用都会推理，这才是耗时的大头。缓存优化的是账单，不是延迟。