热门 AI 模型容量不足时：从 Kimi K3 看创始人的上线 SLO

月之暗面近日暂时停止接受 Kimi K3 的 C 端新订阅。官方解释是，K3 的需求远超预期，GPU 容量正在承受压力；已有会员权益不受影响，团队会在扩充供给的同时调整会员入口。这个变化距离 Kimi K3 上线 Kimi、Kimi Work、Kimi Code 与 API 只有几天。

这不代表 Kimi K3 是一个糟糕的模型，也不能证明它的 API 已经宕机。月之暗面的公开状态页目前仍显示 API 正常运行。真正得到证据支持的结论更窄，却对产品团队更有用：一个模型可以能力很强、已经开放使用，但仍然没有足够可预测的容量，去承接每一个想依赖它的产品。

对 AI app builder 用户、非技术创始人和小团队来说，这件事比榜单又升了一名更重要。用户不会直接感受到 benchmark 分数，他感受到的是结果能否在 8 秒内出现、加载动画会不会一直转、付费流程是否做到一半突然触发限制，以及系统切到备用模型后会不会在没有说明的情况下改变答案。

本文把 Kimi K3 的容量事件转成一套创始人可以亲自把关的上线测试。你会得到一份依赖服务 SLO、一个 72 小时小流量试运行（canary）、明确的重试预算、降级阶梯，以及“上线 / 暂缓 / 不上线”决策表。它适合正在考虑接入热门新模型，或准备迎接流量高峰的 AI 产品团队。它不会推测 Kimi 未公开的内部容量，也不能替代企业合同中的正式 SLA。

发生了什么，以及现有证据不能证明什么

月之暗面的官方订阅说明表示，Kimi K3 的需求远超预期，GPU 容量面临压力，因此暂时停止 C 端新订阅。与此同时，Kimi K3 官方发布文章确认模型已经进入 Kimi 的消费端产品与 API，完整权重和技术报告会在后续交付窗口公布。发布文章将 K3 描述为一个 2.8 万亿参数的混合专家模型，支持 100 万 token 上下文，并公布了模型、编程、知识工作与多模态评测结果。

这些材料能够确认三件事：模型已经发布，需求使官方采取了容量管理措施，还有一部分技术产物尚未交付。它们没有公开容量缺口有多大、需求高峰期间的 API 错误率、平均排队时间、暂停订阅会持续多久，也无法回答某一个付费 API 账号会不会被限流。网上流传的收入、估值或用户增幅，同样不能替代这些缺失的运行数据。

还有一条很容易被忽略的边界。月之暗面的公开状态页目前把 API 与模型服务标记为正常，并提供近期事故记录。“状态页全绿”和“暂停新增订阅”完全可以同时成立。状态页通常回答的是：“某个服务是否出现大范围故障？”产品团队真正需要回答的是：“我们的账号、模型、地区、token 形态与流量曲线，能不能达到我们向用户承诺的体验？”

所以，应当把这次暂停当作一个测试信号，而不是最终判决。负责任的结论既不是“Kimi 无法扩容”，也不是“问题已经解决”，而是：容量已经成为这次发布中可见的一部分，因此容量也必须进入采用证据。

创始人需要理解的五个词：可用性、容量、配额、延迟与 SLO

这些概念经常被压缩成一句“API 能用”，但它们对应的是不同的失败面。

可用性（availability），指在一个明确周期内，有多少有效请求拿到了有效响应。月度可用性数字可以很好看，产品却仍可能在发布后的一个小时流量高峰中失败。 容量（capacity），指服务在特定条件下能够处理多少有用工作。对 AI 模型来说，请求并不等价。一个 600 token 的分类任务，和一个使用 100 万 token 上下文的 Agent 会话，消耗的推理资源完全不同。Google SRE 关于过载处理的章节特别指出：如果单次请求的成本差异很大，只看每秒请求数往往无法准确描述容量。 配额（quota），指供应商允许你的账号消耗多少资源，可能按请求数、输入 token、输出 token、并发任务、消费金额，或几种指标组合计算。即使硬件仍有余量，配额也可能为了保护服务而限制你的账号。 延迟（latency），指一次请求要等多久。不要只看平均值，要看整个分布。p95（第 95 百分位）表示 95% 的请求都能在这个时间内完成。如果平均值是 6 秒、p95 却是 48 秒，就说明有相当一部分用户经历的是另一种产品。 SLO（Service Level Objective，服务水平目标），是团队为一项可观测的用户结果，在特定时间窗口内主动设定的目标。SLA 是供应商写进合同的承诺，通常附带补偿或处理办法；上线 SLO 则是团队内部的运行决策。只要你的产品承诺要求更高，内部目标就应该更严格，而且要提前写清未达标时怎么办。

因此，真正的产品依赖单元不是“Kimi K3”或任何一个模型名，而是：模型 + 账号等级 + 接口端点 + 请求形态 + 流量模式 + 失败策略。

为什么 benchmark 胜出回答不了容量问题

Benchmark 关心的是：在指定的 harness、数据集、预算与评分器下，模型能否得到正确或更受偏好的结果。容量测试关心的是：在你自己的账号限制和真实工作负载下，产品能否持续交付可接受的结果。两者都重要，但不能互相替代。

Kimi 的发布文章对部分评测边界说明得相当清楚：不同结果使用了不同 Agent harness，一部分分数由厂商自己运行，并使用最高推理强度。文章也列出了产品限制，例如对完整思考历史较敏感，以及在某些任务上可能过于主动。这些披露能帮助团队设计 eval，却仍然无法告诉你：发布当天 10:05，等待名单中的 2,000 名用户同时到来时，你的产品会发生什么。

创始人应该把问题拆成四层：

1. 能力：模型能否以要求的质量完成代表性任务？
2. 兼容性：模型放进你的提示词、工具、结构化输出与安全控制后，是否仍然正确工作？
3. 容量：服务能否承受预期的请求到达方式和 token 消耗？
4. 单位经济性：算上重试、备用路线和人工纠正以后，每一份真正被用户接受的结果要花多少钱？

高分可以成为启动测试的理由，却不能成为跳过另外三问的理由。同样，C 端暂停订阅也不会推翻模型的 benchmark 结果；它只是提出了一个 benchmark 从来没有负责回答的新问题。

在真实用户进入之前，先写一份依赖服务 SLO

不要从“速度要快、服务要稳”这种模糊要求开始。选定一条用户旅程，写成可观测的一页合同，小团队也能在一次会议里完成。

假设你的产品会把创始人的用户访谈笔记整理成有优先级的产品简报，一份初始 SLO 可以这样写：

表里的数字只是示例，不是所有产品都要照抄的标准。后台研究报告可以等几分钟，输入联想功能却不能。免费实验能够接受的可用性，也可能低于会阻断客户工作的付费流程。

这份合同还要指定负责人和数据来源。只写“看供应商后台”不够，因为供应商看不到用户是否在浏览器里放弃、响应是否缺字段，以及你的应用是否自动发起了第二次请求。自己的事件记录至少要串起：请求开始、供应商返回、校验结果、重试、备用路线、用户可见状态与最终验收。默认情况下不必保存敏感的 prompt 正文。

只看五类真正对应用户伤害的信号

监控大屏可以很漂亮，却仍然回答不了是否该继续上线。先跟踪五类互相独立的信号。

1. 有效完成率

只有通过 schema 与产品质量检查，才算真正完成。HTTP 200 但缺少关键字段，不算成功；结果虽然生成了，却在用户已经放弃流程以后才到达，也不算成功。

2. 尾部延迟

同时记录 p50、p95，以及超过界面等待上限的请求比例。按照模型、输入长度档、输出长度档和路由拆分。一个合并后的平均值，可能完全掩盖长上下文客户总是卡住的事实。

3. 限流与过载错误

把 429、超时、5xx 和供应商专用的过载错误分别记录。供应商文档能够说明为什么必须拆开。Anthropic 的限流文档分别计算每分钟请求、输入 token 和输出 token，返回 retry-after，并提醒流量突然增长可能触发“流量突增限制”。如果团队只记成“API 错误”，就丢掉了调整流量形态最需要的线索。

4. 重试放大倍数

统计每一次用户操作最终产生了多少次供应商调用。即使初始失败率只有 2%，只要多个应用层各自重试，实际负载就会快速放大。Google 的过载指南建议同时限制单次请求和单个客户端的重试预算，并提醒多个层级一起重试会成倍增加流量。用“用户操作”作为分母，才能让这种放大显形。

5. 每个有效结果的成本

把所有模型费用——包括失败请求、备用模型与校验调用——除以真正通过产品闸门的输出。Kimi 的发布文章公布了缓存命中输入、未命中输入和输出的 API 价格，会员页面则提供不同等级的访问方案。token 标价是有用的输入，但它不是这条工作流最终的单位经济性。

这五类信号可以同时避免两种常见误判：基础设施返回成功，就庆祝用户拿到了好结果；或者明明是排队与账号限制的问题，却归因于模型质量。

在服务承压之前，先给流量分级

容量紧张时，“所有请求照常服务”就不再是一项真实策略。发布之前必须决定哪些工作更关键。

可以先用四个简单等级：

这对应一个经得住长期验证的过载原则：先丢弃低关键度工作，再影响高关键度的用户任务。Google SRE 明确把请求关键度与延迟要求分开，并用关键度决定哪些请求应该先被拒绝。

这项策略也能防止客户互相伤害。在供应商前面设置单个用户和单个工作区的并发上限。OpenAI 的限流指南建议，为可编程调用或高用量功能设置单个用户的使用限制。一个用户同时发起 200 次生成，不应该耗尽所有人的容量。

不要让付费用户在不知情的情况下，和批量评测、内容生成、内部实验争抢同一份配额。这不是高效共享，而是一场没有披露规则的产品抽签。

设计有边界的重试，而不是重试风暴

面对短暂故障，重试很有用；面对持续过载，反复提交昂贵请求只会让情况更糟。

创始人不需要亲自挑选网络库，但应该批准以下规则：

• 只重试已经归类为“暂时性”的错误。身份认证失败、安全拒绝、无效输入，或没有改变请求就必然再次失败的业务校验，都不应该重试。
• 供应商返回 retry-after 时必须尊重这个时间。
• 使用指数退避与随机 jitter，避免所有客户端在同一时刻再次冲击服务。
• 同时设置最大尝试次数和端到端总时限。
• 只允许一个层级负责重试。如果 job worker 已经负责，API route 和浏览器就不能各自再加一层循环。
• 为每次用户操作分配幂等键（idempotency key），确保重复尝试不会创建两条记录、发送两封邮件或扣款两次。
• 如果剩余的用户等待时间已经不足以产生有用结果，就停止重试。

OpenAI 的官方指南建议使用带随机性的指数退避，并特别指出失败调用仍然会计入每分钟限制。Microsoft 则把用于暂时故障的重试模式，和达到失败阈值后暂时停止调用的断路器模式区分开来。AI 应用需要的正是这种分工：少量、有目的的重试，然后迅速进入已经设计好的降级状态。

“一直试到成功”为止，不是可靠性策略。它只是把供应商的压力转移成用户等待时间和你的账单。

设计一条保留任务含义的降级阶梯

不少团队只写一句 fallback_model = cheaper_model，就认为备用方案已经完成。模型并不是可以无差别互换的数据库。备用模型可能改变工具行为、安全拒绝、结构化输出稳定性、语言质量、上下文容量与回答风格。

应该设计一条逐级下降的阶梯，并用同一套产品评分标准验证每一层：

1. 同一个模型，缩小请求：去掉非必要上下文、缩小输出范围，或在不改变用户意图的前提下拆分任务。
2. 已验证的其他模型：只有备用模型通过固定测试样例、数据结构检查、安全规则与成本上限，才能接收真实流量。
3. 不依赖生成的降级模式：在合适场景中返回已保存草稿、确定性搜索、模板或之前计算的结果。
4. 排队后完成：明确告诉用户任务稍后结束，显示状态，并设置过期时间。
5. 诚实失败：保存用户输入，说明服务暂时不可用，提供重新尝试按钮，但不要谎称任务仍在后台运行。

凡是会明显影响信任的替换，都不能隐藏。如果能力更低的路线会改变用户应该如何理解结果，就要标注这是降级输出。也不要在没有核验同意、数据保留、地区与合同条款的情况下，把敏感数据静默发送给第二家供应商。

备用路线要保留的是任务含义，而不只是“还能生成一些文字”。一份没有来源链接的产品简报，可能还不如一份明确延迟交付的简报；一份客服草稿则可以走更简单的路线，只要发送前仍然有人复核。

公开发布之前，先跑一个 72 小时小流量试运行

小流量试运行（canary）是在全部流量进入前，用少量真实流量验证产品行为。面对刚刚爆发需求的新模型，测试周期要足够长，至少覆盖不止一个流量时段。

第 0–6 小时：固定测试样例

准备 30–50 个经过同意或完全合成的案例，覆盖短输入、典型输入和接近上限的输入。整套测试至少重复三次。记录质量通过率、延迟分布、token 用量、错误和供应商调用次数，并确认测试使用的请求形态与生产环境一致。

第 6–24 小时：受控增加流量

只给 5% 的合格用户或一小批邀请用户开放。SLO 持续达标后再缓慢增加。流量突然升高本身就可能触发供应商的流量突增限制；Anthropic 的文档明确建议逐步提升流量。批处理工作不要走这条路由。

第 24–48 小时：故障与备用路线演练

在预发布环境中注入 429、超时、格式错误输出、流式输出变慢和供应商 5xx。确认界面会按照承诺停止、重试、降级或排队。验证重复请求不会重复执行工具动作，并完整走一遍断路器和恢复流程。

第 48–72 小时：模拟发布时的流量形状

使用安全的合成请求，重放接近发布第一个小时的到达曲线。不要对供应商制造滥用式流量，始终遵守公开限制与约定配额。重点测试自己的队列、并发上限、监控、告警与回滚控制。决策负责人要亲自观察用户界面，而不是只盯日志。

最后生成一页验收凭证：工作负载版本、模型 ID、账号等级、测试时段、案例构成、质量通过率、p50 / p95、错误明细、每次用户操作的调用次数、备用路线比例、每个有效结果的成本、尚未解决的未知项，以及最终决策。这份凭证就是可复用的交付物，可以把“看起来挺稳定”变成其他人能够复核的证据。

一个具体场景：等待名单里有 2,000 人

假设两个人组成的小团队做了一款 AI 用户研究助手。演示结束后，有 2,000 人加入等待名单。创始人准备周一上午 10 点一次性发送邮件，每位新用户可以上传五份访谈，交给 AI 综合分析。

最天真的估算是 2,000 位用户乘以一次生成。真正有用的预测还要考虑流量集中、重试、长输入与后台任务。如果 20% 的人会在前 15 分钟到达，其中一半立即上传，而每次分析至少要发一个长请求和一次校验调用，那么还没计算重试，供应商就会接到至少 400 次请求。如果 API route 和 job worker 都各自重试两次，一次用户可见的失败可能制造出数次供应商调用。

团队因此修改了发布方式：

• 邮件分四批，在六小时内逐步发送。
• 每个工作区只允许一个分析任务运行，另外两个进入队列。
• 第一份结果只使用有上限的上下文，可选的跨项目比较稍后运行。
• 为付费试点用户保留并发容量。
• 第一次暂时性错误后遵守 retry-after；第二次失败后进入队列，或切换到已验证的备用路线。
• 界面把“已排队”“处理中”“受限摘要”和“需要重试”显示成不同状态。
• 如果 p95 高于 90 秒，或有效完成率连续 10 分钟低于 95%，暂停接收新上传，让已有任务先排空。

这些动作不会让底层模型变得更聪明，但会让产品承诺变得更窄、更可观测、也更容易恢复。这才是创始人在发布时应该负责的部分。

常见失败模式与误读

“状态页是绿色，所以我们的路由一定正常。” 全局状态页可能无法反映你的账号等级、地区、模型、prompt 大小或突发流量。它是证据之一，不应该成为唯一监控。 “暂停订阅，说明 API 不可靠。” C 端注册入口和 API 容量可能由不同机制管理。必须测试自己真正要调用的接口与账号。 “重试越多，完成率越高。” 短暂故障时可能成立；服务持续过载时，重试会继续消耗配额、增加费用，并延迟一次本该诚实展示的失败。 “接入第二家供应商，就自动获得冗余。” 只有通过兼容性、隐私、质量、安全和成本检查，第二家供应商才是一条备用路线；否则只是一个新的失控依赖。 “排队能够解决容量问题。” 队列可以削平流量尖峰，却不会凭空增加吞吐。没有准入上限和过期时间，过载只会变成越来越长的积压。 “长上下文只是多了一个功能。” 长输入会同时改变延迟、限流消耗、缓存行为、成本与失败概率，必须按输入长度档分别测试。 “需求爆发证明模型全面领先。” 订阅增长可能来自质量、价格、新鲜感、分发能力或稀缺感，无法单独证明其中任何一项，更不能证明模型适合你的工作负载。

这些边界很重要，因为创始人可能向两个方向过度反应：仅凭一次消费端事件就放弃有价值的供应商，或者因为热门程度看起来像可靠性证明，就把生产流量直接交出去。

用“上线、暂缓、不上线”做决定，而不是凭感觉

小流量试运行结束后，对照预先写好的条件决策。

同一个团队可以针对不同工作流得出不同结论。Kimi K3 可能适合可选的后台编程辅助，却暂时不适合你账号上的同步付费交付。另一款模型可能能稳定完成短文本提取，但长上下文路线不达标。“我们到底用哪个模型？”这个问题太宽泛，应该具体决定：什么模型在什么失败策略下负责什么工作。

什么时候应该用这套框架，什么时候它仍然不够

以下情况适合使用这套上线 SLO：增加新的模型供应商；准备 Product Hunt 或等待名单发布；把 AI 步骤放进付费工作流；提高并发量；或者依赖刚刚出现异常高需求的热门模型。

如果只是一个不会伤害用户的私有原型，而且创始人可以手动重试，这套流程的重要性会降低。即便如此，记录延迟与尝试次数仍然有价值，至少不会把一次成功演示误认为生产就绪。

对医疗、法律、金融、招聘等高影响决策，这套框架远远不够。这些产品还需要领域验证、合规审查、人工监督、安全控制与事故处理。它也不能替代对自家数据库、队列、身份认证、存储与工具集成的压力测试。模型供应商可以完全健康，而你的应用仍然在其他位置失败。

如果工作流能够发送消息、花钱、公开发布、修改权限或删除数据，容量处理还必须保留人工批准边界和幂等性。首选模型暂时不可用时，备用路线绝不能因此自动获得更大的操作权限。

下一次热门模型发布时，创始人应该检查什么

在把真实用户交给一个刚刚爆发需求的新模型之前，确认：

• [ ] 已经写明用户旅程、模型 ID、接口端点、账号等级和请求长度档。
• [ ] 已经区分官方事实、厂商主张、自己的观察、推断与未知项。
• [ ] 固定测试样例同时评估有效质量与延迟。
• [ ] 正在记录 p50、p95、429、超时、5xx、无效输出，以及每次用户操作产生的调用次数。
• [ ] 重试策略包含 jitter、最大尝试次数、唯一负责层级与总时限。
• [ ] 每个会产生副作用的操作都有幂等键。
• [ ] 用户、工作区和批处理并发上限能够保护付费即时任务。
• [ ] 备用路线已经通过质量、隐私、安全、schema 和成本检查。
• [ ] 界面会区分等待、排队、降级、失败与完成。
• [ ] 成本按“每个通过验收的结果”计算，而不只是按 token 计算。
• [ ] 72 小时小流量试运行已覆盖正常、接近上限、故障与发布形态流量。
• [ ] 负责人无需重新部署就能暂停新任务或回滚。
• [ ] 停止条件在发布之前已经写好，并在发布期间持续可见。

Kimi K3 暂停新订阅之所以值得关注，是因为它把一个通常看不见的依赖暴露了出来。更普遍的产品教训是：前沿模型的访问能力是一份容量合同，而不是模型选择器里的一个下拉选项。小团队无法控制供应商有多少 GPU，却可以控制自己承诺什么、接收多少流量、制造多少重试、验证哪条备用路线，以及上线前必须拿到什么证据。

参考资料

1. 月之暗面，Kimi K3 订阅与容量官方说明，2026 年 7 月。
2. 月之暗面，Kimi K3: Open Frontier Intelligence，2026 年 7 月。
3. 月之暗面，Kimi 会员与价格，访问于 2026 年 7 月 20 日。
4. 月之暗面，服务状态与事故记录，访问于 2026 年 7 月 20 日。
5. Google，Site Reliability Engineering: Handling Overload。
6. OpenAI，API 限流与错误缓解指南。
7. Anthropic，Claude Platform 限流文档。
8. Microsoft Azure Architecture Center，Retry pattern。
9. Microsoft Azure Architecture Center，Circuit Breaker pattern。
10. Amazon Web Services，Using load shedding to avoid overload。