Kimi K2.8 Preview全量上线：1M上下文、三档思考

Kimi K2.8 Preview已经全量上线Kimi Code。

现有kimi-for-coding模型ID保持不变，客户端和第三方工具不需要修改配置；官方给出的主要变化包括：最高1M上下文、low / high / max三档thinking effort，以及相较K2.7 Code更高的思考效率。

Kimi对它的定位是“综合性能接近K3”，但目前官方没有随这次全量上线公开K2.8 Preview的参数规模、激活参数、模型架构和逐项Benchmark。

01

K2.8全量上线

Kimi Code目前主要提供K3、K2.8 Preview和K2.7 Code HighSpeed。

其中K3的公开规格包括2.8万亿参数、KDA混合线性注意力、Attention Residuals以及最高1M上下文。

K2.8 Preview目前公开的信息要少得多。

因此不能因为K2.8和K3都支持1M上下文和三档思考，就把K3的2.8T参数和KDA架构直接套给K2.8。

对技术团队来说，这个区别很重要。没有激活参数、架构和Serving数据，就无法仅凭模型名称推导显存占用、Prefill成本或者Decode吞吐。

021M上下文下放

K2.8 Preview现在向所有Kimi Code会员档位开放最高1M上下文。

这比单纯把Context Window从256K改成1M更值得做生产测试，因为代码Agent的长上下文通常会同时带上代码、日志、工具返回、需求文档和历史修改记录。

1M可以减少Compaction、分块和重复注入，但它不会自动解决长上下文里的信息干扰。

代码仓库越大，模型面对的旧实现、重复接口、历史日志和无关文件也越多。实际效果可能出现两种情况：

一种是跨文件修改明显更稳，因为依赖关系可以一次放进上下文。

另一种是输入量变大以后，TTFT和成本增加，但最终任务成功率没有同比例提升。

所以测试1M不要只问“能不能装下整个Repo”，更应该固定同一组工程任务，分别测：

• 128K / 256K / 1M
• 首Token延迟
• 总任务耗时
• Tool Calls
• Retry次数
• Test Pass Rate
• Cost / Successful Task

如果1M只是让输入token明显增长，却没有减少工具调用、检索和返工，它未必是更便宜的配置。

03三档Thinking

K2.8 Preview支持low、high、max三档thinking effort，默认是max。

官方第三方工具映射也已经写得比较清楚：

这意味着同一个kimi-for-coding模型ID，可以在应用层直接做推理预算分级。

日常补全、格式修改、小范围Bug修复可以先测low；跨文件修改、复杂Debug可以使用high；长周期Agent和高难度工程任务再上max。

但实际成本不能只按档位判断。

例如max虽然单轮思考更多，但如果一次完成任务，可能比low失败后重新跑三轮更便宜。因此建议按任务记录：

Thinking Level → Tokens → Tool Calls → Latency → Retry → Success

最终比较的应该是Cost per Successful Task，而不是“low一定最省”。

04

模型ID不变

Kimi Code官方文档里有一个比较重要的路由规则：

当thinking关闭后，K3系列和K2.8 Preview的请求都会由K2.8 Preview无思考版本处理。

也就是说，产品界面里选择“K3”，不代表每一种调用模式最终都一定由K3完成。

如果团队在做K3和K2.8的A/B测试，必须同时记录：

• Model ID
• Thinking是否开启
• Effort档位
• Context Window

否则很容易出现“界面显示K3，但实际无thinking请求走的是K2.8”的情况，最终Benchmark没有可比性。

这一点对接入Claude Code、OpenCode、Codex等第三方工具时尤其重要，因为不同工具对effort名称的映射并不完全一样。

例如Claude Code中的medium会映射为Kimi的high，xhigh会映射为max。

生产测试时最好直接记录最终发送给Kimi Code API的参数，而不是只记客户端UI里选了什么。

05生产要回归

这次K2.8 Preview采用的是原地升级方式。

Model ID仍然是：

kimi-for-coding

客户端和第三方工具无需修改配置就会使用新模型。

对普通用户很方便，但对生产系统反而有一个问题：

代码没改，底层模型行为已经变了。

因此如果kimi-for-coding已经用于正式Agent、代码审查或者自动修复流程，建议重新跑一次固定Regression Set。

至少检查：

• Structured Output
• Function Calling
• Tool参数格式
• Patch Accepted Rate
• Test Pass Rate
• 长任务中断率
• Prompt兼容性
• 输出长度变化
• Thinking Token变化
• P50 / P95 Latency

尤其是依赖稳定Prompt行为的自动化流程，不能因为Model ID没变，就默认升级前后的行为完全一致。

06

K3差距还有多少

Kimi官方对K2.8 Preview的描述是“综合性能接近K3，思考效率更高”。

但此次全量上线没有同步公布一张完整的K2.8 Preview vs K3 Benchmark表。

目前也没有看到官方给出K2.8 Preview在SWE-bench、Terminal-Bench、LiveCodeBench或者长周期Agent任务上的逐项结果。

所以“接近K3”更适合作为官方产品定位，而不是一个已经可以量化的结论。

K2.8 Preview这次能够确认的升级主要集中在三项：

1M上下文、可调Thinking、思考效率提升。

它们都指向同一个使用场景：代码Agent持续执行更长时间的任务。

所以测试集也应该尽量避免只用单文件补全。

更适合加入：

• 跨模块Bug修复
• Repo级重构
• 长日志定位问题
• 连续运行测试并修复
• 多工具调用
• 大型代码库问答
• 需求文档到完整Feature实现

最终记录：

如果K2.8的提升成立，最应该体现出来的不是“它拥有1M窗口”，而是同一个复杂任务需要更少的返工、更少的工具调用，或者更低的推理预算就能完成。

目前可以确认的是，K2.8 Preview已经从预览阶段进入Kimi Code全量使用，kimi-for-coding直接升级，所有会员可以使用最高1M上下文，同时获得三档thinking effort。

参数规模、激活参数和底层架构目前没有公开，因此这部分最好等Moonshot后续技术报告。