Kimi K3-256k 发布：成本高效的高上下文编码

Kimi 推出了 K3-256k，这是其旗舰 K3 编码模型的专用版本，旨在降低对不需要完整 100 万令牌上下文窗口的开发者的配额消耗。对于 256k 限制内的任务，K3-256k 能够提供与完整 K3 模型相同的结果，同时消耗约一半的配额。

Kimi 编码模型对比

Kimi 目前提供两大模型系列——K3 和 K2.7 Code——通过四个不同的模型 ID 可供选择。K3 系列是旗舰产品，拥有 2.8 万亿参数。

模型 ID	模型版本	上下文窗口	关键特性	可用性
`k3`	Kimi K3	Up to 1M	Flagship capability; supports image and video input.	Moderato+ (1M for Allegretto+)
`k3-256k`	Kimi K3	256k	Same results as K3; reduced quota consumption; image input only.	Moderato+
`kimi-for-coding`	Kimi K2.7 Code	256k	Optimized for routine development and code completion.	All members
`kimi-for-coding-highspeed`	K2.7 Code HighSpeed	256k	5–6× faster output than standard K2.7; 3× quota usage.	Allegretto+

在 K3 的 256k 与 1M 版本之间切换，使开发者能够在成本和容量之间取得平衡。Kimi 支持“可突发上下文”工作流，用户可以根据会话的即时需求扩展上下文窗口。

在降低上下文窗口时，用户必须确保当前会话不超过 256k 令牌。如果超过，诸如 Kimi Code CLI 或 Claude Code 等工具将执行“compact”操作。Kimi 建议在切换前手动运行 compact 命令，以保留关键任务点并维护会话完整性。

用户可以直接从 256k 版本切换到 1M 版本，而不会影响缓存。这对于已接近 256k 限制并需要额外空间而不想通过压缩丢失信息的会话非常理想。

切换模型 ID 或更改 reasoning_effort 设置会使现有上下文缓存失效。这会迫使模型重新填充上下文，导致令牌消耗增加，并可能出现使用量的短暂峰值。为降低开销，Kimi 建议在切换模型时启动新会话，或在整个会话期间保持一致的推理力度。

Kimi Code API 支持 OpenAI 和 Anthropic 两种协议。要在第三方工具中使用 K3，开发者必须手动将上下文窗口设置为 1048576，以利用完整的 1M 容量，因为许多工具默认使用较小的窗口。

K3 支持三种推理力度级别。在通过第三方工具集成时，力度映射如下：

行业观察者和 Hacker News 的用户指出，K3-256k 的推出反映了基于上下文长度的分层定价趋势，这与 OpenAI 的实现类似。

“大量活跃的上下文会提升每个令牌的成本（每个输出令牌的 FLOPs 消耗和读取的字节数），因此将这部分成本转嫁给用户是合理的。”

一些用户强调了 256k 限制的实际用途，指出大多数编码任务很少超过此阈值，使得 1M 窗口成为一种“奢侈”但在日常开发中往往不必要的特性。另一些人则指出，以更低成本提供高性能模型对于与美国 AI 实验室竞争具有战略意义。