Kimi K2.8补齐1M上下文

Kimi Code 全量切换 K2.8 Preview，模型 ID 不变

月之暗面今天将 Kimi K2.8 Preview 全量上线 Kimi Code，原有用户不需要更改模型配置。此次升级沿用 kimi-for-coding 这一 Model ID，Kimi Code 客户端及已经接入该模型的第三方编程工具会直接获得新版本，官方给出的定位是“综合性能接近 K3，思考效率更高”。

Kimi K2.8 Preview 是月之暗面面向编程与智能体任务推出的预览模型，重点补齐了 100 万 token 上下文和可调思考强度。与一次需要用户主动切换 Model ID 的新品发布不同，这次更接近服务器端原地升级：开发者昨天使用的还是 K2.7 Code，今天在相同入口发起任务，底层模型已经变成 K2.8 Preview。

这次更新最重要的变化不是模型名称，而是月之暗面把此前偏向高档位会员的两项能力下放给了全部 Kimi Code 会员。所有会员档位现在都能通过 kimi-for-coding 使用最高 1M 上下文，同时可以在 low、high 和 max 三档之间调节 thinking effort，默认档位为 max。

一张表看懂 K2.8 Preview 改了什么

K2.8 Preview 的产品价值可以概括为“用原来的入口，获得更接近旗舰模型的能力”。根据月之暗面公布的信息及 Kimi Code 现有模型文档，升级前后的主要区别如下。

| 对比项 | K2.7 Code | K2.8 Preview | Kimi K3 | |---|---|---|---| | Kimi Code Model ID | kimi-for-coding | kimi-for-coding | k3 / k3-256k | | 模型定位 | 常规编程模型 | 接近 K3 的新一代编程模型 | 2.8 万亿参数旗舰模型 | | 最高上下文窗口 | 256K | 1M，全部会员开放 | 1M，高档位会员开放 | | 思考强度 | Thinking 开启，缺少统一分档 | low / high / max，默认 max | low / high / max | | 编码与 Agent 能力 | 适合代码补全和常规开发 | 全面提升，强化复杂编码与智能体任务 | 面向长程工程、科研编程等前沿任务 | | 是否需要改配置 | — | 不需要，自动升级 | 需要主动选择 K3 Model ID | | 无思考模式路由 | 原 K2.7 Code 路线 | 路由至 K2.8 Preview 无思考版 | 关闭 thinking 后同样路由至 K2.8 Preview |

这张表也暴露了 K2.8 Preview 的真实角色：它并不是用来取代 K3 的新旗舰，而是 Kimi Code 默认体验的“准旗舰底座”。月之暗面仍然保留了 K3 作为最高能力选项，但把日常编码最常用的长上下文、Agent 执行和思考强度控制交给 K2.8 Preview 承担。

1M 上下文从高档权益变成默认能力

100 万 token 上下文是指模型在一次会话中最多可以接收和处理约 1048576 个 token。它不是简单的“聊天记录更长”，而是决定编程模型能否同时看到大型代码仓库、依赖说明、终端日志、测试结果和历史修改记录的基础容量。

K2.8 Preview 将上下文窗口从 K2.7 Code 的 256K 提升到最高 1M，理论容量扩大了 4 倍。对于只让模型写一个函数的短任务，这项提升几乎没有感知；但在分析单体仓库、跨目录重构、排查长链路故障或者运行多轮 Agent 工作流时，256K 和 1M 的差别可能就是“中途压缩上下文”与“完整保留现场”的差别。

1M 上下文最适合处理需要全局理解的软件工程任务。一个典型场景是让 Kimi Code 阅读前端、后端、数据库迁移和测试目录，定位一个涉及权限校验的跨模块问题；另一个场景是连续执行搜索代码、修改文件、运行测试、读取报错和再次修复，模型需要记住几十轮工具调用中的状态变化。

长上下文并不等于模型会自动理解整个仓库。上下文窗口描述的是容量上限，而检索质量、注意力分配、提示词组织和中间信息压缩，仍然会影响最终结果；一次性塞入大量重复日志，还可能让真正关键的信息被淹没。

第三方工具也未必会自动用满 1M 上下文。Kimi Code 官方文档此前提醒，部分客户端会设置自己的上下文上限，使用 K3 时需要将相关字段配置为 1048576；K2.8 Preview 虽然不需要更换 Model ID，但如果客户端仍把窗口锁定在 256K，服务端支持 1M 也不会凭空突破本地配置。

因此，这次升级对官方客户端用户最省心，对第三方工具用户则仍需检查上下文设置。Model ID 不变解决的是兼容问题，不代表每一个客户端都会自动调整自身的 token 预算、压缩阈值和缓存策略。

三档 thinking effort，让算力花在难题上

Thinking effort 是控制模型在回答前投入多少推理资源的参数。K2.8 Preview 与 K3 保持一致，支持 low、high、max 三档，其中默认值为 max，用户可以根据任务难度在响应速度、资源消耗和解题质量之间做取舍。

三档思考强度解决的是编程模型长期存在的“所有问题都用同一种力度”问题。让模型解释一段正则表达式，不需要像设计分布式事务方案一样反复推演；让模型给变量改名，也没有必要支付与跨模块重构相同的等待时间。

| 思考档位 | 更适合的任务 | 预期特点 | |---|---|---| | low | 代码解释、简单补全、格式调整、小范围改名 | 响应更快，适合高频轻任务 | | high | 常规功能开发、错误排查、单模块重构 | 在速度与推理深度之间平衡 | | max | 跨模块修改、架构设计、复杂 Agent 任务、疑难故障 | 推理投入最高，默认档位 |

可调思考强度对 Agent 场景比对普通问答更有价值。编程智能体往往要连续执行读取文件、规划修改、调用终端、运行测试和修复失败等步骤，如果每一步都使用最高推理强度，简单工具调用也会拖慢整体流程；如果始终使用最低强度，模型又可能在关键决策点选错文件或误判错误根因。

月之暗面此次特别强调 K2.8 Preview 的“思考效率”较 K2.7 Code 显著改善，但目前没有公布延迟、输出 token 数或单位任务消耗的量化结果。因此，“效率更高”暂时只能理解为官方产品结论，不能直接等同于响应时间缩短多少或成本降低多少。

默认使用 max 也说明月之暗面现阶段更重视任务成功率，而不是把速度放在第一位。对于交互式补全、简单查询等轻任务，开发者可以主动降至 low；对于需要模型独立工作十几分钟甚至更久的工程任务，保留 max 更稳妥。

关闭 thinking 后，K3 也会回到 K2.8

无思考模式统一路由至 K2.8 Preview，是这次更新中容易被忽视但十分关键的产品调整。官方明确表示，关闭 thinking 后，无论请求选择的是 K3 系列还是 K2.8 Preview，最终都会路由到 K2.8 Preview 的无思考版本。

这套路由意味着 K3 的差异化价值主要体现在开启推理之后。用户虽然在界面上选择了 K3，但一旦关闭 thinking，真正执行任务的并不是一个“K3 无思考版”，而是 K2.8 Preview；对于比较模型效果、记录实验结果或复现问题的开发者，这一点必须写入测试条件。

统一无思考底座有助于降低产品复杂度。月之暗面只需要维护一套面向低延迟请求的默认模型路线，K3 则集中处理需要更深推理的任务，这与云服务常见的“快速路径”和“深度路径”分层相似。

统一路由也会改变用户对模型名称的理解。今后在 Kimi Code 中，“选择 K3”并不必然代表每次请求都由 K3 完成，thinking 开关同样决定实际模型；仅比较界面所选名称，而不记录思考模式和 effort 档位，得到的对比结论可能失真。

“接近 K3”很诱人，但暂时缺少公开跑分

K2.8 Preview 综合性能接近 K3，是官方对这次更新最有冲击力的描述。K3 是月之暗面近期发布并开源的旗舰模型，参数规模达到 2.8 万亿，采用 KDA 混合线性注意力机制与 Attention Residuals，最高支持 100 万 token 上下文，并将长程编程、GPU 编译器、芯片设计和科研编程列为重点场景。

K2.8 Preview 与 K3 的具体差距目前仍无法精确量化。月之暗面尚未随此次全量上线公布 SWE-bench Verified、LiveCodeBench、Terminal-Bench 或内部 Agent 评测的逐项成绩，也没有披露 K2.8 Preview 的参数规模、激活参数量和推理速度。

缺少公开跑分使“接近 K3”更像产品定位，而不是可复验的技术结论。它可能意味着日常编程任务的体感接近，也可能意味着综合内部评测接近，但在长程任务、极复杂推理、视觉理解或高难度系统优化中，K3 仍可能保持明显优势。

历史数据只能提供背景，不能替代 K2.8 Preview 的成绩。月之暗面此前公开的 Kimi K2 是一个总参数 1 万亿、激活参数 320 亿的 MoE 模型，在 SWE-bench Verified 单次补丁设置下取得 65.8% pass@1，并在引入并行测试时计算后达到 71.6%；这些数字证明 K2 系列有较强的 Agent 编程基础，但不能直接推导 K2.8 Preview 或 K3 的当前表现。

对开发者而言，最靠谱的测试方法不是问模型“你是谁”，而是用自己的仓库做任务级评估。可以固定同一份代码快照和任务描述，分别测试 K2.8 Preview 的 low、high、max 以及 K3，记录首次修复成功率、测试通过率、总耗时、工具调用次数和上下文消耗。

这次升级真正改变的是会员分层

全部会员获得 1M 上下文，是 K2.8 Preview 比能力升级更值得关注的商业动作。此前 Kimi Code 文档显示，K3 需要 Moderato 及以上档位才能调用，1M 上下文则需要 Allegretto 及以上档位；K2.7 Code 虽然所有会员可用，但上下文只有 256K。

K2.8 Preview 把“所有会员可用”和“最高 1M 上下文”组合到同一模型上，降低了长仓库分析的使用门槛。用户不再需要仅仅为了扩大上下文窗口而切换到 K3 或提高会员档位，K3 必须依靠更强的复杂任务能力证明自身价值。

这也是月之暗面在 K3 发布后对产品矩阵的一次重新切层。K2.8 Preview 负责覆盖大多数日常开发和常规 Agent 工作流，K3 负责高难度、长程和前沿工程任务，高速模型则继续服务对输出速度更敏感的场景。

| 用户类型 | 建议选择 | 原因 | |---|---|---| | 高频问答与小修改 | K2.8 Preview + low | 降低不必要的推理等待 | | 常规功能开发 | K2.8 Preview + high | 兼顾速度和任务成功率 | | 大型仓库排障 | K2.8 Preview + max | 可利用 1M 上下文和最高思考强度 | | 长程自主工程任务 | K3 + high 或 max | 更适合复杂 Agent 与前沿编程任务 | | 无思考低延迟任务 | K2.8 Preview 无思考模式 | K3 关闭 thinking 后也会路由至该版本 |

无感升级是优点，也带来复现问题

Model ID 不变是这次更新最实用的设计。企业和个人不需要批量修改编辑器插件、CLI、自动化脚本或团队配置，也不会因为模型名称变化立即遇到兼容性故障。

无感升级同时削弱了结果的可复现性。如果团队只在日志中记录 kimi-for-coding，那么 9 月 11 日前后的两次请求虽然 Model ID 完全一致，背后实际运行的模型版本却可能不同，代码修改质量和工具调用行为也可能发生变化。

生产工作流需要额外记录日期、客户端版本、thinking 状态和 effort 档位。对于依赖稳定输出的自动代码审查、测试生成或批量迁移任务，建议先用固定任务集做回归测试，再决定是否让新模型直接进入关键流程。

切换思考强度还可能使提示词缓存失效。Kimi Code 此前已经在 CLI 中加入相关提示，建议切换模型或 effort 后新开会话，以避免旧缓存失效带来的额外 token 消耗；这项操作习惯在 K2.8 Preview 支持三档 effort 后会更加重要。

K2.8 Preview 更像 K3 的普及版

K2.8 Preview 不是一次靠新参数规模抢眼球的发布，而是一次直接改善现有用户体验的默认模型升级。它用不变的 kimi-for-coding 入口，把上下文从 256K 提高到 1M，并补上与 K3 一致的三档 thinking effort，实际影响范围比一个需要手动切换的新 Model ID 更大。

这次更新最值得肯定的是能力下放，而不是“接近 K3”这句宣传语。1M 上下文覆盖全部会员、旧配置无需迁移、简单任务和复杂任务可以采用不同思考强度，这三项变化都能直接减少开发者的配置成本和使用摩擦。

K2.8 Preview 当前最大的问号仍然是缺少量化数据。官方没有公布它相对 K2.7 Code 的延迟降幅、token 消耗变化和公开编程跑分，也没有解释“接近 K3”究竟对应哪些评测集；在这些数据补齐前，它更适合被称为“K3 的普及版体验”，而不是“K3 的平替”。

对于已经使用 Kimi Code 的开发者，这次升级没有迁移门槛，值得立即用真实仓库复测。对于正在比较不同编程模型的团队，则应把 1M 上下文、effort 档位和 thinking 路由规则纳入评测，否则很容易把上下文容量、推理预算与模型本身的能力混为一谈。

参考来源

• IT之家：月之暗面 Kimi K2.8 Preview 全量上线 Kimi Code：此次更新的上线时间、Model ID、1M 上下文及思考强度信息。
• GitHub：Moonshot AI / Kimi K2：Kimi K2 的模型架构、参数规模及 SWE-bench 等历史评测数据。
• Hugging Face：Kimi K2 Thinking：K2 Thinking 的长程推理、工具调用能力和公开基准测试说明。