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。

长上下文

非流式，输出极短，所以这基本等于「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 每次调用都要花好几秒推理，这才是时间线的大头。缓存优化的是账单，不是延迟。

该怎么做

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

这些数字不代表什么

它们不是基准测试。单一客户端、单一网络路径、单独一天、每档样本量一到五次。数字里叠着我们到月之暗面（Moonshot AI）服务器的线路状况，以及发布当天月之暗面扛着的负载——一款全新旗舰模型上线那天，想必不会清闲。

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

请把它们当量级看，而不是对模型的精确测定：首 token 是秒级不是毫秒级；100k 上下文是几十秒不是几秒；500k 是一分钟上下不是十秒。这就是它的轮廓，拿来做设计决策已经够用。等发布期的负载回落，我们会重测并更新日期戳。