Kimi 为 K3.1 Pro 限流道歉：补偿 25% 月度额度，问题出在子 Agent

模型发布两天后，用户等来的不是新功能，而是一封道歉信。10 月 26 日凌晨，Kimi 就 K3.1 Pro 的限流和额度消耗问题公开致歉，并给所有订阅会员补上了一笔“额度”。这在国产大模型的服务史里并不常见：愿意把问题归因到自己身上，也愿意用可计量的方式补偿。

一分钟速览

• Kimi 就会员使用 K3.1 Pro 时出现的限流及不必要额度消耗致歉。
• 所有有效期内的订阅会员，按月度总额的 25% 补偿，相当于一周用量。
• 若当前用量不足月度总额的 25%，则直接重置为 0。
• 官方已调整配置，减少不必要的子 Agent 调用和输出长度。
• K3.1 Pro 于 10 月 24 日发布，是月之暗面迄今最强的 3 万亿级参数模型，支持 100 万上下文。

一封道歉信里的三个信息

第一，问题不是个别用户“用超了”，而是平台侧的限流与额度计算出了偏差。Kimi 的原话是“问题出在我们，我们也本应更早修复”。这句话把责任揽了过去，也说明故障持续了一段时间。

第二，补偿方案是“按月度总额的 25%”，而不是发一张固定面额的优惠券。对重度用户来说，这更接近真实损失；对轻度用户，官方也留了一个兜底：如果当前用量不足月度总额的 25%，直接把用量重置为 0。

第三，修复方向不是简单扩容，而是“减少不必要的子 Agent 调用和输出长度”。这句话技术含量很高，它承认了一个常见问题：智能体为了完成一个任务，会反复调用子 Agent、生成大量中间文本，最终让同样的额度完成更少的事。

为什么子 Agent 会“吃额度”

K3.1 Pro 主打编程智能体和长上下文。这类任务天然适合多 Agent 架构：一个主 Agent 负责规划，多个子 Agent 分别检索、写代码、跑测试、改错误。好处是并行、专业；坏处是每一次调用都要消耗 token，而且中间结果会被反复传递。

如果编排层没有做好裁剪，用户看到的是“我只问了一个问题”，账单上却是十几次模型调用。更糟的是，有些子 Agent 会在没有新信息的情况下重复输出，额度就这样被“礼貌地浪费”了。

Kimi 说正在减少不必要的子 Agent 调用和输出长度，本质上是在优化编排层，而不是单纯堆算力。对一家模型公司来说，这是更可持续的做法，也更考验工程能力。

3 万亿参数模型的甜蜜负担

K3.1 Pro 是月之暗面迄今能力最强的模型：3 万亿级参数，100 万上下文，编程智能体测评超过 GPT-6。参数越大、上下文越长，单次调用的成本越高，服务端的调度也越复杂。

发布初期的流量洪峰，几乎必然会撞上容量瓶颈。区别只在于，有的公司选择悄悄降级，有的公司选择限流，有的公司选择道歉并补偿。Kimi 选了第三种。

这不完全是道德选择，也是竞争策略。国产大模型的价格战已经打到“按厘计价”，用户迁移成本很低。一次糟糕的体验，可能就让用户换到另一家；一次及时的补偿，反而能换来谅解。

补偿背后的“额度经济学”

25% 的月度额度，听起来不多，但对高频用户来说，这是实打实的成本。更重要的是，它建立了一个可预期的规则：平台出错，按用量比例赔。

这比“送一张 20 元优惠券”更透明，也更容易被用户接受。它把“道歉”从情绪层面拉到了合同层面：你付了钱，我没交付好，我按比例退。

当然，补偿也有边界。它补的是额度，不是被耽误的时间，也不是因限流而错过的截止日期。对依赖模型完成生产任务的团队来说，稳定性仍然比补偿更重要。

趋势洞察

大模型竞争正在从“谁的跑分高”转向“谁的服务稳”。模型能力可以靠论文和榜单证明，服务能力只能靠一次次高峰期的表现积累。K3.1 Pro 的发布证明了前者，这次限流则暴露了后者。

接下来值得观察的是：Kimi 会不会公布更具体的容量指标，比如高峰时段的可用率、平均排队时间、子 Agent 调用的上限？如果这些数据能被持续披露，用户才能真正判断“什么时候该用它，什么时候该换一个”。

对行业来说，这也是一个提醒：智能体的成本不只是 token 单价，还包括编排效率。能把“同样的额度完成更多实际任务”做好的公司，才有资格谈性价比。

参考链接：月之暗面官网