Kimi K3 上下文长度是 100 万 token，开放平台文档给出的精确值是 1,048,576 tokens，约为 K2.6、K2.7 Code 的四倍。计费上它不按上下文长度分段加价，输入分缓存命中与未命中两档、输出一档，都是统一单价。本文把官方数值、汉字换算、超限报错和拉满上下文的操作路径整理齐全，核查时间 2026 年 9 月 17 日。 Kimi K3上下文长度是多少
官方两处口径一致。Kimi 技术博客的表述是「原生支持视觉理解，并拥有 100 万 token 上下文窗口」；开放平台模型列表与定价表里写得更精确，kimi-k3 的上下文窗口为 1,048,576 tokens，并在同页注明「此处 1M = 1,000,000」。也就是说对外口语化的「100 万 token」对应的是 1024×1024 这个数，比字面的 1M 还多出 4.8 万。 同门产品之间的跨度很明显：
表内价格出自开放平台定价页，单位为每百万 tokens，与上下文窗口是两列独立信息。第三方模型的公开清单可作为交叉验证：在免鉴权的聚合平台模型列表里，kimi-k3 的 context_length 同样记为 1048576，与官方数值吻合。
还有一处错值流传很广。仍有资料把 K3 的上下文写成 256K，那是 kimi-k2.7-code 与 kimi-k2.6 的规格，两代产品被混在了一起。要判断也不麻烦，看文档里上下文窗口那一列，K3 对应的行不是 262,144。
100万token大约是多少字
官方定价页给了中文的换算口径：对于一段通常的中文文本，1 个 Token 大约相当于 1.5-2 个汉字，汉字之间差异不小，像「夔」这类生僻字会被拆成若干个 token，而「中国」这种高频短语可能只占 1 个 token。
按这个区间推算，1,048,576 tokens 大致对应 157 万到 210 万汉字。这是拿官方换算口径做的算术，官方没有直接公布对应的汉字数，实际能塞进多少还取决于你喂的是中文、英文还是代码。
输出这一侧另有独立上限。开放平台文档写明 max_completion_tokens 默认 131,072，最大可设置为 1048576。它和输入 token 数是相加后共同受窗口约束的，官方错误码说明里就有一条报错专门对应两者之和超出模型规格。
不用估。Kimi 提供了计算 Token 的接口，把即将发出的 messages 原样提交一次就能拿到实际 token 数，比按字数乘系数可靠得多。tokenizers/estimate-token-count 的请求体结构与 chat completions 基本一致，纯文本和带图的消息都能估。
这个上下文规格在真实任务里的样子，官方博客给过几个参照：一次连续 48 小时的自主 Agent 运行，完成了 4 mm² 芯片的设计、优化与验证；一份覆盖某行业 42 年历史的研究报告，过程中完成了 2800 多次网页搜索与抓取、1100 多次终端数据拉取，处理 87 份季报和 99 份原始 PDF，合计超过 11000 页资料；还有一次对 391 个引力波事件的分析，用 20 多个并发 subagents 完成。
怎么把上下文用满100万token
上下文窗口给的是上限，实际能不能用上，取决于你怎么组织请求。Kimi API 是无状态的，模型自己不留记忆，多轮对话的历史要由调用方每次带全。
- 把 messages 带完整。历史里用户的问题和模型的回复都要放，只传问题会让模型失去前文依据。
- 截断要有保底。messages 会随轮次不断变长，官方建议用策略把长度控制在合理范围内，示例做法是每次只保留最新的 20 条消息，并且截断后务必让 system 消息仍然留在列表里。
- 固定的大段内容放最前面。知识文档、system prompt、工具定义这类不变的内容放在 messages 数组前部，用户问题和模型回复追加在后，自动缓存才好命中。
- 跨过缓存门槛。官方说明写得很明确：当前一个请求的 prompt tokens 大于 256 时，新的请求才能命中前缀缓存；小于 256 的请求不会被缓存，而是直接丢弃。
- 输出侧按需放大。需要长输出时显式调大 max_completion_tokens，否则默认 131,072 会比输入先到顶。
- 超出窗口前先分层。内容极长而查询方向不固定时，检索增强比硬塞更划算。官方对比过两种路线：上下文缓存在特定场景下最高可降本 90%，长文本场景首 token 延迟平均可降到 5 秒以内，但只对重复引用的固定内容有效；检索增强则与业务特性无关，代价是需要额外做嵌入与调优。
上下文长度和计费的关系
计费这件事最容易被误判。K3 的计费不按上下文长度分段，官方常见问题页的原话是：上下文长度为 1M tokens，计费不按上下文长度分段，所有用量均按量付费，输入区分缓存命中与未命中，与输出分别按统一单价计费。一次塞进去 90 万 token 和塞 9 万 token，单价是同一个。
调用 K3 还有一道前置门槛：需在开放平台完成充值（最低充值金额 10 元）后解锁，新用户注册认证赠送的 15 元代金券不可用于 K3。
与 token 长度直接挂钩的另一组限制是速率，它按累计充值金额分级，单位分别是每分钟与每天的 token 数：
Tier0 的 TPD 是 150 万 tokens，一次接近满窗的请求就足够吃掉这个大半天额度。想把长上下文跑起来，账号等级往往比模型本身更早成为瓶颈。
上下文超限与常见报错
官方错误码页把与长度相关的几类报错列得很清楚，按提示对号入座即可：
| | |
|---|
| invalid_request_error：Input token length too long | 输入 tokens 超过模型最大上下文限制，缩短输入或换用更大上下文的模型 |
| invalid_request_error：prompt tokens + max_tokens 超过模型规格 | 减小 max_completion_tokens，或换用更大上下文的模型 |
| exceeded_current_quota_error：账户 token 额度不足 | |
| rate_limit_reached_error：触发组织级 TPM 限制 | |
| rate_limit_reached_error：触发组织级 TPD 限制 | |
收到 429 时先看 error.type 再决定动作：节点过载的退避重试即可，组织限速要么降并发要么升级等级，余额不足只能充值。限速响应头会带上 X-RateLimit-Limit、X-RateLimit-Remaining 与 X-RateLimit-Reset，可以据此做退避。
用长上下文要注意的限制
- 思考链关不掉。K3 始终开启思考模式，官方常见问题里明确目前无法关闭。嫌思考太长只能把 reasoning_effort 设为 low（三档为 low / high / max，默认 max），不能关。思考内容同样计入输出计费。
- 历史消息要原样回传。多轮对话与工具调用时，必须把 API 返回的完整 assistant message 加入下一次请求，不能只保留 content。官方在局限性里专门提醒：如果 agent 框架没有按要求回传全部历史思考内容，或者从别的模型会话中途切到 K3，可能引发上下文干扰，导致生成质量不稳定。
- 视觉输入不支持公网图片链接。图片要用 base64 或文件标识的形式传，content 必须是对象数组，不能是序列化后的字符串。
- 采样参数固定不可改。temperature 固定 1.0，top_p 固定 0.95，n 固定 1，presence_penalty 与 frequency_penalty 固定 0，显式传入其他值会报错。
- 缓存只认稳定的前缀。知识内容、system prompt 和工具定义频繁变动，命中率会直接掉下来。
- 联网搜索工具正在更新，官方建议近期不要用于生产流程。
- 旧模型已经下线。kimi-k2.5 与 moonshot-v1 系列（含 -auto 与 -vision-preview 版本）于 2026 年 8 月 31 日下线，kimi-k2 系列已于 2026 年 5 月 25 日下线，需要迁移到 K3 等在用模型。
- 风控限速触发后无法解除。充值与限速页写明，系统检测到账户异常行为时会触发风控限速策略，该限制一旦触发即无法解除。
Kimi K3上下文长度常见问题
Q：Kimi K3 的上下文长度精确是多少？ A：开放平台定价与模型列表给的是 1,048,576 tokens，官方对外表述为 100 万 token。
Q：上下文变长之后单价会涨吗？ A：不会。官方明确计费不按上下文长度分段，输入分缓存命中与未命中两档，输出一档，都是统一单价。
Q：100 万 token 大概能装多少中文字？ A：按官方 1 token 约等于 1.5-2 个汉字的换算口径推算，约 157 万到 210 万汉字，属于估算而非官方数值。
Q：最大输出能有多长？ A：max_completion_tokens 默认 131,072，最大可设置为 1048576。注意它和输入 token 数是相加后共同受窗口约束的。
Q：怎么提前知道这次请求会消耗多少 token？ A：用官方的计算 Token 接口，把要发的 messages 提交一次即可拿到实际用量，比按字数估算准。
Q：为什么我的请求命中不了缓存？ A：先看 prompt tokens 是不是大于 256。小于这个数时请求既不会被缓存，也不会被保留，而是直接丢弃。
Q：上下文超限会报什么错？ A：返回 400 invalid_request_error，提示 Input token length too long；如果是输入与 max_tokens 之和超限，报错信息会换成两者相加超过模型规格。
Q：用满上下文要多高的账号等级？ A：速率按累计充值分级，Tier0 的 TPD 只有 150 万 tokens，一次接近满窗的请求就会大量占用额度，长上下文场景通常需要更高等级。
Q：网页版和手机 App 的上下文长度也是 100 万吗？ A：官方在技术博客和开放平台文档中给出的数值是一致的 100 万 token，未针对 C 端单独公示另一套数值。以模型为主体的口径就是这个数。
把 Kimi K3上下文长度 记成一件事就够了：窗口 1,048,576 tokens，计费不按长度分段，真正卡住你跑满窗口的通常是账号等级和输出侧那个默认值。价格与限速会随官方调整，跑长任务前到开放平台的定价与限速页确认当期标准即可。
AI 速览
