Kimi API 的限额怎么看？撞上了怎么处理

2026-07-27

数据截至 2026-07，价格与限额以各官网为准。

“Kimi API 又限额了”这句话，八成时候说的不是同一件事。上下文塞满了、请求被限流了、账户扣不动钱了，这三种情况的报错长得像、处理方式却完全不同。先分清是哪一类，再动手，比反复重试或者盲目换模型有用得多。

我见过不少人一遇到调用失败，第一反应是”是不是免费额度用完了”，然后跑去控制台充值，充完发现照样报错——因为真实原因是一次性把三十万 token 的文档全塞进了 messages，撞的是上下文窗口，跟余额一分钱关系都没有。也见过反过来的：把限流当成代码 bug，对着请求参数改了两小时，其实只要退避几秒重发就好了。所以这篇不按”报错码大全”来写，而是按你实际会遇到的三条边界来拆。

先把三种”限额”分开

一个调用要走通，至少要同时满足三个条件，任何一个不满足都会失败：

上下文窗口：单次请求里 system + 历史消息 + 本次输入 + 预留的输出，加起来不能超过模型的上下文长度。这是硬的、确定的、写在模型规格里的数字。
速率限制：单位时间内你能发多少请求、消耗多少 token。这个数字跟账户状态挂钩，不是全平台一个值，得在自己的控制台里看。
账户余额与计费项：能不能扣到钱，以及有没有你没算进去的按次计费项目。

三者的典型症状也不一样：撞上下文，错误信息里通常会直接点出 token 数超了，而且重试一百次也一样失败；撞限流，特征是”过一会儿再发就好了”，同样的请求体，间隔拉开就能过；撞余额，则是稳定失败且跟请求内容无关，随便发个”你好”也照样不通。

拿到报错先做这个三选一判断，能省掉大半排查时间。

上下文窗口：262,144 token 是什么概念

先说这条最容易搞清楚的。截至 2026-07，Kimi 大陆站当前在售的主力模型 kimi-k2.7-code、kimi-k2.7-code-highspeed、kimi-k2.6、kimi-k2.5，上下文长度都是 262,144 tokens。也就是说这一代模型在窗口大小上是拉齐的，选型时不需要为了”更长上下文”去换模型——差别在能力定位和价格上，不在窗口上。

另外还有经典的 moonshot-v1-8k / 32k / 128k 系列，这一系列各档位之间只有上下文长度不同，模型能力没有差异。这一点值得单独说，因为不少人误以为 128k 版本”更聪明”，于是无脑用最大档，结果只是让自己多付钱、还更容易踩到长上下文带来的响应变慢。真实的选法是：估算你的典型请求大概多长，选够用的那一档就行。（这一系列的具体价格本文不列，以 platform.kimi.com/docs/pricing/chat-v1 页面为准。）

要注意的是，上下文是输入和输出共用的。如果你打算让模型输出一份很长的报告，就得给输出留出足够空间，不能把窗口按满输入去塞。

撞了上下文墙怎么办

按代价从小到大排：

先量一量，别猜。在发请求之前把 messages 序列化出来估一下长度，超阈值就提前处理，而不是等 API 报错再回头补。中文场景下用字符数粗估会偏乐观，稳妥做法是留出足够余量（比如只用到窗口的七成），把剩下的当缓冲。
裁历史，而不是裁当前问题。多轮对话里最先该丢的是早期的闲聊轮次，最不该丢的是本轮用户的实际诉求和关键的 system 约束。常见做法是保留 system + 最近 N 轮 + 一段对更早历史的摘要。
长文档不要整篇塞。做文档问答就切片检索，只把相关片段送进去；做长文总结就分段总结再合并。硬塞满窗口既贵又不一定效果好。
确实需要一次性看完超长内容，那就得在架构上认账：拆任务、多次调用、中间结果落地，而不是指望换个模型窗口就变大——这一代模型的窗口值是一样的。

速率限制：本文不给数字，给方法

这里必须诚实说明一件事：Kimi 官方的速率限制具体数值，本文不列。这类数字跟账户等级、模型、地区站点都有关，而且官方历史上调整过多次，我不会凭记忆给你一个”看起来很专业”的 RPM/TPM 数字让你拿去做容量规划——那比不给更危险。你自己账户当前的限额，以你登录 platform.kimi.com（国际站为 platform.kimi.ai）控制台看到的页面和官方文档为准。

我能给的是不依赖具体数字也成立的方法：

第一，把限流当成必然会发生的事来设计，而不是异常。 只要你的应用有并发、有峰值，迟早会撞。区别只是撞了以后是自动恢复，还是给用户抛个红色报错。

第二，识别限流类错误。 这类错误在 HTTP 层通常表现为 429 这一类状态码，语义是”请求太频繁，稍后再试”。Kimi 具体返回的错误码字段、错误信息措辞、是否携带建议等待时间，以官方文档和你实际抓到的响应为准，别照抄别家平台的字段名去解析。稳妥的写法是：先看状态码分类（4xx 里的限流 vs 参数错误 vs 鉴权失败），再看具体 message 文本，两层判断。

第三，指数退避重试。 撞限流之后立刻原速重发，只会让情况更糟。基本骨架长这样：

import os, time, random
from openai import OpenAI

client = OpenAI(
    api_key=os.getenv("MOONSHOT_API_KEY"),
    base_url="https://api.moonshot.cn/v1",   # 国际站换成 https://api.moonshot.ai/v1
)

def chat_with_retry(messages, model="kimi-k2.6", max_retry=5):
    for attempt in range(max_retry):
        try:
            return client.chat.completions.create(model=model, messages=messages)
        except Exception as e:
            # 只对限流/临时性错误退避重试；参数错误、鉴权失败重试多少次都没用
            if not _is_retryable(e) or attempt == max_retry - 1:
                raise
            wait = (2 ** attempt) + random.random()   # 指数退避 + 抖动
            time.sleep(wait)

两个细节别省：一是加随机抖动，否则多个 worker 会在同一时刻齐刷刷重发，形成新的尖峰；二是区分可重试与不可重试，鉴权失败、模型名写错、参数非法这些重试再多次也不会变好，只会白白拖慢失败反馈。

第四，从源头削峰。 应用侧加一个请求队列或令牌桶，把并发控制在自己设定的上限内，比事后重试优雅得多。批量任务尤其如此——一次性甩出几百个请求，然后靠重试兜底，是最容易把自己打到限流的写法。

余额之外，还有两笔容易漏算的钱

余额不足这类问题本身好判断，但有两个计费点常常被漏进预算里，导致”钱怎么掉得比我算的快”。

一是联网搜索工具的按次计费。 大陆站文档明确写了，联网搜索的工具调用会额外收取 ¥0.03/次，并且计费条件很具体：仅当 finish_reason 为 tool_calls 且确实调用了 web_search 时才收；如果这一轮最终以 stop 结束，就不收这笔。这个规则的实际含义是——你的 agent 循环写得越啰嗦、来回触发搜索越多次，这笔钱涨得越快，而它是按次而不是按 token 计的，token 用量报表里看不出来。做联网类应用的话，建议单独埋点统计搜索调用次数。

二是缓存命中与否的价差。 Kimi 采用自动上下文缓存机制，命中缓存时输入价格明显低于未命中价。以 kimi-k2.6 为例，缓存命中的输入价是 ¥1.10/百万 token，未命中是 ¥6.50/百万 token，输出是 ¥27.00/百万 token；kimi-k2.5 对应是 ¥0.70 / ¥4.00 / ¥21.00。同一个模型，输入这一项的命中价和未命中价能差好几倍，所以做成本估算时必须说清楚你算的是哪个口径，跟别家平台横向比价时更要注意，不然很容易得出一个偏离现实的结论。

需要提醒的是：缓存机制在官方文档里是作为价格机制描述的，它是否同时影响速率限制的计算口径，我手上没有可靠依据，不做推断，以官方最新说明为准。别把别家平台的”缓存读取不计入限速”这类规则想当然套到 Kimi 上。

批量调用另有优惠，具体折扣比例以官网 /docs/pricing/batch 页面为准。

模型下线：一种没人提醒你的”额度归零”

这一条严格说不算限额，但撞上的杀伤力和额度耗尽一样：你的调用会全面失败，且改重试次数没有任何用。

截至 2026-07，Kimi 官方已经把 kimi-k2、kimi-k2-0711-preview、kimi-k2-0905-preview、kimi-k2-turbo-preview、kimi-k2-thinking、kimi-k2-thinking-turbo 这一批模型在 2026-05-25 下线，官方建议迁移到 kimi-k2.6。如果你手上还有半年前照着老教程写的代码，模型名很可能就在这个清单里。

防这件事有两个动作：一是把模型名做成配置项，不要硬编码散落在十几个文件里，换名字的时候只改一处；二是可以用官方接口动态查一下当前可用模型，GET https://api.moonshot.cn/v1/models 返回的字段里带有 context_length、supports_image_in、supports_video_in、supports_reasoning 等信息，比看缓存在你记忆里的清单靠谱。

别把两套账户体系搞混

还有一类”限额问题”其实是站点搞错了。Kimi 有两套账户体系：大陆站（人民币计价）和国际站（美元计价），分别对应不同的域名和 base_url：

大陆站控制台 platform.kimi.com，调用地址 https://api.moonshot.cn/v1
国际站控制台 platform.kimi.ai，调用地址 https://api.moonshot.ai/v1

注意官方域名已经迁移过：原来的 platform.moonshot.cn 和 platform.moonshot.ai 现在分别 301 永久重定向到上面两个新域名。你搜到的老教程里域名多半还是旧的，能跳转过去，但心里要有数。至于两套体系的 key 是否互通，我没有可靠依据，建议以你实际注册地的账户为准，不要拿一套 key 去撞另一套端点然后怀疑是”限额”。

API Key 的创建路径在大陆站控制台左栏「API Key 管理」→「新建」，直达地址是 https://platform.kimi.com/console/api-keys，密钥只显示一次，当场复制保存。国际站控制台结构应当一致，以实际页面为准。

一份撞限额时的自查顺序

按这个顺序过一遍，大部分情况五分钟内能定位：

换个最简单的请求（就发”你好”）试一次。通过说明不是余额和鉴权问题，问题出在你原来那个请求本身；不通过就往账户和网络方向查。
看错误信息里有没有提到 token 数量。提到了就是上下文问题，去裁历史或切片。
等三十秒再发同一个请求。能过就是限流，去加退避和限流控制。
确认模型名还在当前在售清单里，尤其是老代码。
确认 base_url 和你的 key 属于同一个站点体系。
以上都对再看控制台的用量与账单页面，以及官方文档当前页面的说明。

小结

Kimi 的”限额”是三件事：上下文窗口是写死的规格，当前这一代主力模型都是 262,144 tokens，撞了只能改数据组织方式；速率限制跟账户状态相关，具体数值以你自己控制台和官方文档为准，工程上靠退避重试加源头限流来消化；余额之外还要把联网搜索按次计费和缓存命中与否的价差算进预算。模型下线这种”隐形断供”同样会让调用全线失败，把模型名做成配置项能省掉一次深夜救火。所有具体价格与限额数字变动都比较频繁，本文只作为排查思路参考，落到生产环境前请以官网当前页面为准。