Kimi 崩了吗?
Moonshot AI
没崩 —— Kimi 运行正常
我们的监测源未发现异常。如果你仍然无法使用,问题很可能出在你本地 —— 下方的排查建议列出了常见原因。
监测数据详情
- 官方状态页
- 未提供
- 最近 1 小时测试请求
- 未对该服务运行测试
- OpenRouter 调用流量
- 4 个模型中有 0 个出现异常,近 30 分钟请求成功率 100%
- 最近 1 小时访客报告
- 0
Moonshot AI 未提供公开的状态页。访问 Kimi ↗
最近 24 小时
24 小时前现在
最近 30 天
30 天前昨天
有数据的 5 天中,有 5 天无任何异常。
近期故障
过去 30 天内无故障记录。
关于此服务
我们测试 Moonshot AI 国际版开放平台。Kimi 聊天应用则是基于相同模型构建的独立前端。
其他模型 API 当前状态
Kimi:常见问题
是 Kimi API 挂了,还是我代码的问题?
请查看 HTTP 状态码。401 和 403 代表 API Key 或权限问题,400 和 422 代表请求参数格式错误,429 代表触发了速率限制或额度用尽。只有 500、502、503、504 以及请求超时,才意味着问题出在 Moonshot AI 服务端。如果本站显示该服务正常但你依然收到服务端报错,可以用 curl 发送一个最小化请求,以排查是否是本地客户端库或代理的问题。
我的应用该如何应对 Kimi 突发故障?
对 429 和 5xx 响应采用指数退避重试,并加入少许随机抖动,同时限制最大重试次数;设置合理的超时时间,防止卡住的流式请求堆积。对于直接面向用户的场景,建议配置其他厂商的备用模型,并在连续几次请求失败后自动无缝切换——上方列表展示了当前哪些服务处于健康状态。
为什么别人说一切正常,我的请求却一直失败?
限制通常按组织和模型分别设定,因此你的账号可能会被限流,而其他人却能正常使用。在用量高峰期,新发布的模型和超大模型也往往最先被限频。请检查账号的用量页面,尝试改用较小的模型,并确认调用了正确的 base URL 和区域。
响应速度很慢但最终能返回,这算服务中断吗?
重点看首字(first token)延迟,而非总耗时。在我们自己的测试请求中,当首 token 耗时超过 3 秒且达到当天中位数的 3 倍以上时,我们就会标记为响应缓慢。长提示词(prompt)和长文本输出本身就需要较长时间,这属于正常现象,不会被视作故障。
你们怎么知道 Kimi 是否宕机?
针对 Kimi,我们综合参考OpenRouter 上 Moonshot AI 相关模型的请求成功率和本页面收到的用户故障反馈。我们会以最新且最严重的状态信号为准,并自动忽略过期数据以保证准确性。页面会自动刷新;具体的判定阈值可在我们的“检测机制”页面查看。