Kimi K3 的上下文窗口

填满它要花多少钱

这张表有两个要点。第一，一次满窗口调用的成本约等于 1,000 轮短对话——窗口改变的不只是花费多少，而是成本的计量单位。第二，「缓存后重跑」这一列，是长上下文反复干活还负担得起的唯一原因：账单上最大的一项直接砍到 1/10。也正因为这一列，提示词怎么排序在 50 万 token 规模下比在任何地方都重要。

最后一行是外推值，我们也如实标了出来。两次长请求之间，token 量约 5 倍，实际耗时也约 5 倍，大致呈线性——但两个点画不出一条曲线，满窗口我们没有实测过。~110s 只当量级参考，别当精确数字。

上限不是长度控制器

上下文窗口和 max_completion_tokens 总被混为一谈，而在 K3 上，这个混淆是要花真金白银的。

• 1,048,576 的上下文窗口是 K3 能读进多少——也就是你的提示词。
• max_completion_tokens（默认值 131,072）是它能写出多少——包括推理内容。

第二点就是陷阱。推理消耗的是输出预算，所以想靠压低 max_completion_tokens 拿到「短一点的回答」，实际压掉的是 K3 被允许思考的长度。低于约 2,048，我们实测它什么都不返回，照常全额扣费。想要短回答，写进提示词里去要。看六组实测 →

还有一点值得知道：max_completion_tokens: 2000000——接近窗口的两倍——返回的是 HTTP 200，不是报错。API 不会告诉你这个数字纯属离谱。更多静默失败 →

窗口什么时候值得用

同一份大上下文被反复使用时，它就值。一个代码库、一份合同、一套文档，你要围着它问二十个问题：第一次调用付 $1.49，之后十九次每次只要 $0.15，因为前缀一直是热的。窗口就是为这种形态而生的，而且这种活换别的路子确实难做。

一次性检索不值。如果只是为了回答一个问题把 50 万 token 塞进去跑一遍，那就是花 $1.49 和 52 秒，去做一件「先检索、再发一条 5,000 token 提示词」就能搞定的事——后者成本不到一美分，几秒就返回。百万 token 窗口不是 RAG 的替代品——它是另一种工具，硬拿它当 RAG 用，是这里最烧钱的错误用法。

延迟才是最容易被低估的约束。成本可以靠缓存优化，实际耗时不行：在我们所有测试里，缓存都没有让热调用变快。一次 52 秒的调用就是 52 秒，无论你付的是不是全价。如果有人在屏幕前等，这个数字直接决定你的架构。

实用建议

• 长上下文一定开流式输出。不开流式，就是整整一分钟的沉默，看不到任何「还在跑」的信号。
• 客户端超时按分钟设。SDK 的默认超时会掐死一次完全正常的 52 秒调用。
• 生产环境盯住 prompt_tokens。在 $3.00 / 百万 token 的价位上，提示词膨胀是最容易失控的账单项。一次不小心的满窗口调用就是 $3.15。
• 从第一天就按缓存需求排提示词。稳定内容放最前，每轮变化的放最后。在这个规模下，这个折扣决定方案可行还是不可行。

上下文窗口 FAQ

Kimi K3 的上下文窗口有多大？

1,048,576 token——即 2²⁰——引自官方定价页，读取于 2026-07-16。

用满 Kimi K3 的上下文窗口要花多少钱？

按 $3.00 / 百万 token 的缓存未命中价，单次调用输入约 $3.15；前缀已经预热则约 $0.31。我们实测一次 497,718 token 的调用花了 $1.49、耗时 52 秒；满窗口的数字是在此基础上的算术与外推。

max_completion_tokens 和上下文窗口是一回事吗？

不是。上下文窗口是 K3 能读进多少；max_completion_tokens 是它能写出多少（包括推理内容），默认值 131,072。把它设低并不会让回答变短——只会截断思考：低于约 2,048 时，我们实测拿到的是照常全额扣费的空响应。