文章摘要
Kimi Code提供Kimi K3和Kimi K2.7 Code两种模型，共四个模型ID。其中k3-256k在256k上下文内效果与k3(1M)相同，但消耗配额更少，适合日常问答和代码补全。切换模型时需注意上下文长度限制。
文章总结
好的，这是根据您的要求，对原文进行中文重述和精简后的版本：
模型配置
本文介绍 Kimi Code 提供的模型，以及如何在各个客户端中切换使用。
模型概览
Kimi Code 目前提供 Kimi K3 和 Kimi K2.7 Code 两款模型，共四个模型ID，可在客户端或第三方工具中通过模型ID进行选择。
推荐模型：k3-256k。在256k上下文内，其效果与k3（1M）相同，但消耗的配额更少。适用于日常问答、代码补全、常规功能开发及单文件/小文件编辑，不支持视频输入。
切换提醒： * 从K3 (1M) 切换到 K3-256k：若当前会话上下文已超过256k，部分工具会自动压缩。建议手动压缩一次，确保上下文在256k内，以保留任务要点并享受更持久的配额。若历史记录包含视频文件，需先压缩再切换。 * 从K3-256k 切换到 K3 (1M)：若256k上下文接近上限，可直接切换到1M，避免压缩丢失信息。
模型规格表：
| 模型ID | k3 | k3-256k | kimi-for-coding | kimi-for-coding-highspeed |
| :--- | :--- | :--- | :--- | :--- |
| 模型版本 | Kimi K3 | Kimi K3 | Kimi K2.7 Code | K2.7 Code HighSpeed |
| 描述 | 旗舰编码模型，2.8T参数，1M上下文 | K3的256k版本，降低消耗 | 擅长代码补全和常规开发 | K2.7 Code的高速版，输出速度快约5-6倍 |
| 速度 | 常规 | 常规 | 常规 | 高速（6倍速，3倍配额） |
| 上下文窗口 | 最高1M（更高会员等级） | 仅256k | 256k | 256k |
| 推理能力 | 支持低/高/最大（默认高） | 支持低/高/最大（默认高） | 支持思考 | 支持思考 |
| 可用性 | Moderato及以上可用；Allegretto及以上可用1M上下文 | 所有Moderato及以上会员 | 所有会员 | Allegretto及以上计划 |
| 多模态输入 | 图片、视频 | 仅图片 | 图片、视频 | 图片、视频 |
常见问题：
- 为什么切换模型后用量增加？ 切换模型后，之前建立的上下文缓存失效，需要重新预填充。建议使用新模型时开启新会话。
- 为什么正确的模型ID仍返回401错误？ 通常是因为请求的功能超出您的套餐权限。例如：套餐低于Moderato无法调用
k3系列；Moderato套餐下k3仅支持256k上下文；部分套餐不包含高速模型。 - 为什么高速版感觉不明显？ 可能原因：模型ID输入错误（需为
kimi-for-coding-highspeed）；高速仅加速模型输出，工具调用和脚本执行等环节不受影响。 - 如何减少切换推理强度带来的开销？ 切换推理强度会使缓存失效。建议在会话内保持一致的推理强度，如需更改，最好开启新会话。
如何切换模型
使用须知：
* 切换模型ID时请开启新会话，以避免缓存失效导致额外消耗。
* 填写模型ID，而非模型版本名称（如Kimi K3）。
* 保持思考功能开启以使用K3或K2.7 Code，关闭则会回退到K2.6。
切换方式：
- 官方客户端：
- Kimi Code CLI：输入
/model命令切换。若最新模型未列出，先/logout再/login。 - VS Code扩展：在输入栏的下拉菜单中选择目标模型。若未列出，重启VS Code或重装扩展。
- Kimi Code CLI：输入
- 第三方工具：将工具的模型ID设置为目标模型。
- 在Kimi Code控制台创建API Key。
- 在工具中填写Base URL和对应的模型ID。Kimi Code API支持OpenAI和Anthropic两种协议。
- OpenAI兼容：
https://api.kimi.com/coding/v1 - Anthropic兼容：
https://api.kimi.com/coding/
- OpenAI兼容：
在第三方工具中使用K3的特别说明：
* 上下文窗口：部分工具默认上下文窗口小于1M，需手动设置为1048576以使用K3的全部上下文。
* 推理强度：K3支持low / high / max。工具发送的强度值映射关系如下：
* null / undefined → high
* ultra / max / xhigh → max
* high / medium → high（推荐）
* low / minimum / light → low
* none → 禁用思考
评论总结
根据评论内容，主要观点和论据总结如下：
1. 对模型发布的积极反馈（认可度较高） - 用户madihaa表示“That's actually nice! I usually try to stay below 200k context anyway.”（这实际上很好！我通常尽量保持在200k上下文以下。） - 用户ibuildproducts兴奋地评论“omg! new model!!”（哦天哪！新模型！！）
2. 对模型本质的疑问（认可度中等） - 用户hawtads质疑“This is just an API level change right? The model itself should be the same I think.”（这只是API层面的变化吧？我认为模型本身应该是一样的。） - 用户dgritsko询问“This isn't quantized, right? Just a smaller context?”（这不是量化版本吧？只是上下文更小？）
3. 对定价和可用性的关注（认可度中等） - 用户sergiotapia表示“I can't seem to find pricing for this model... Since the context size is just a quarter of the full size K3, is the price also much cheaper?”（我找不到这个模型的定价...既然上下文大小只有完整K3的四分之一，价格是否也更便宜？） - 用户wxw引用官方说明“k3-256k is now available. Within 256k context, it delivers the same results. k3 (1M) consumes about twice as much quota as k3-256k.”（k3-256k现已可用。在256k上下文中，它提供相同结果。k3（1M）消耗的配额大约是k3-256k的两倍。）
4. 对服务稳定性的担忧（认可度较低） - 用户illithid0指出“This was posted 38 minutes ago, and as of 20 minutes ago, several Anthropic services are now designated as having a 'major outage'.”（这发布于38分钟前，而截至20分钟前，多个Anthropic服务被标记为“重大故障”。） - 用户lukan抱怨“when I click pricing, I see 'Join a waitlist'. Wtf? Are they really that good... or do they just don't have the hardware being in china?”（当我点击定价时，看到“加入等待列表”。什么鬼？是他们真的那么好...还是只是在中国没有硬件？）
5. 对模型实用性的肯定（认可度中等） - 用户sergiotapia补充“I usually keep my context in chats below 256k anyways so this would be tremendous honestly.”（我通常将聊天上下文保持在256k以下，所以这实际上会很棒。）
平衡总结： 评论整体对k3-256k模型发布持积极态度，但存在对模型本质（是否仅为API变化）、定价透明度、服务稳定性的质疑。用户普遍认为256k上下文对日常使用足够，但希望价格相应降低。