不用改一行配置，模型自动升级

升级最省心的一点是 Model ID 保持不变，仍为 kimi-for-coding。这意味着命令行工具、VS Code 扩展以及已经接入 Kimi Code 的第三方应用都不需要修改任何配置——Base URL、API Key、调用方式全部沿用原样，用户什么都不用做，手里的工具就自己变强了。

需要注意的是，官方提示不要把模型显示名”K2.8 Preview”直接填进 Model ID。自行创建 API Key 时，OpenAI 兼容接口的 Base URL 为 https://api.kimi.com/coding/v1，Anthropic 兼容接口为 https://api.kimi.com/coding/。

在客户端里切换模型也有明确路径：Kimi Code 命令行输入 /model 后从列表中选择 kimi-for-coding，若列表未刷新，可先执行 /logout 再 /login；VS Code 版则在输入框的模型下拉菜单中选择。

三档思考强度，与 K3 完全对齐

K2.8 Preview 支持 thinking effort 档位调节，提供 low、high、max 三档，默认使用 max，档位设计与 K3 的思考等级保持一致。简单补全可以降低档位换取速度，复杂重构、跨文件排查则保留默认设置。

另一条容易被忽略的规则是：关闭 thinking 之后，K3 系列与 K2.8 Preview 的请求都会路由到 K2.8 Preview 的无思考版本。也就是说，追求响应速度时可以把简单任务和深度任务拆开处理，两者互不干扰。

百万上下文向所有会员开放

上下文窗口是本次升级的另一个重点。K2.8 Preview 提供最高 1,048,576 token（约 100 万）的上下文窗口，且全部会员档位均可使用，不再受会员等级限制。图片和视频输入同样在支持范围内，调试录屏、界面截图和代码文件可以放在同一条任务里分析。

作为对比，Kimi Code 目前的模型矩阵是：K3（k3，2.8 万亿参数规模，1M 上下文，Moderato 及以上会员可调）、K3-256k（k3-256k，262,144 上下文，仅支持图片输入）、K2.8 Preview（kimi-for-coding，1M 上下文，所有会员可用）、K2.7 Code HighSpeed（kimi，262,144 上下文，面向更看重输出速度的编码任务）。

官方给出的定位也很清晰：日常代码补全、功能开发和常规仓库任务优先使用 K2.8 Preview；需要更强的长程推理和复杂工程能力时再切换到 K3。

百万上下文怎么用才不浪费

上下文变长不等于可以无脑堆料。官方给出的建议是，把任务目标、完成标准和不能改动的目录写在开头，再让模型自行搜索相关文件，比把整个仓库和全部历史对话反复贴进去更省。

具体到不同场景：处理大仓库时，先让模型列出与目标功能有关的入口、调用链和测试文件，确认范围后再开始修改；处理长文档时，先要求模型定位章节、表格和结论，再对命中的部分做摘要、改写或交叉检查；处理多轮任务时，每完成一个阶段就保留决策、改动文件和待办事项的短摘要，后续对话引用这份摘要，减少无关历史占用上下文。

还有一个实操提醒：切换模型或思考档位后，旧会话的上下文缓存可能无法命中，刚切换时消耗会偏高。长任务建议新开会话，再把任务目标、目录结构和关键约束写清楚。

从性价比角度看，K2.8 Preview 保留了原来的接入方式，又把更长上下文和可调思考带进日常工作流，对大多数开发任务来说，它已经是 Kimi Code 里更顺手的默认选项。

开放权重模型一多，围观者就习惯把它们摆成一场赛马：谁排名靠前谁就该用，落后的那个自动被归为“慢”或者“不能用”。How-To Geek 编辑 Jorge A. Aguilar 在 8 月 9 日发表的一篇文章里指出，这套逻辑一旦落到真实使用场景中就会立刻散架——因为有些模型压根不是为同一份工作而生的。

谷歌 DeepMind 的 Gemma 4 和阿里巴巴的通义千问 3.6，恰好是最典型的一对例子。

一个装进设备，一个住在云上

Gemma 4 的设计目标是在尽可能多的终端上高效运行：手机、笔记本、台式机。它的 12B 变体可以直接吃进原始音频和图像数据，不需要额外挂载独立的编码器模型。

千问 3.6 则是奔着云端基础设施和长链条分析任务去的。它采用混合注意力结构，能在不撑爆内存的前提下吞下巨量文本。用一句话概括这组差异：前者想当一个快速、私密、跑在本机上的助手；后者想当一个坐在云端、有耐心跟难题死磕的工程师。

两个模型的档位划分也印证了各自的取向。Gemma 4 于 4 月 2 日发布，提供从端侧优化的 E2B、E4B，到 12B、26B 混合专家、31B 稠密模型在内的多个尺寸。千问 3.6 的开放权重版本走的是另一条路线：35B-A3B 混合专家模型每个词元只激活约 30 亿参数，另有一款 27B 稠密模型，原生上下文达到 262144 个词元。两个家族目前都采用 Apache 2.0 许可，这一项上并不构成差异。

上下文窗口决定了能干什么活

真正把两者拉开距离的，是上下文容量和推理方式。

云端的千问 3.6 Plus 拥有 100 万词元的上下文窗口，并且搭配一个常驻运行的推理模式——模型会先把问题想一遍再作答。在部分会话中它还会启用思考保留模式，记住此前几轮的推演过程，从上一次的结论继续往下走，而不是每次都从零开始、重复踩同一个坑。

这个能力在特定场景里价值极高。调试一个庞大的代码库时，100 万词元的窗口可以一次性装下整个仓库、接口文档和错误日志，让模型在几百个文件之间追踪同一个缺陷而不丢线索。

Gemma 4 的上下文上限则视变体而定，落在 128K 到 256K 之间，装不下那么多东西。在较长的会话里，它还容易丢失被指定的角色设定，陷入需要整段重启才能跳出的重复循环。

成本与隐私的账要分开算

许可与账单的差异同样值得留意。千问 3.6 的部分本地变体以免费开放许可发布，企业可以自行部署而无需申请授权；但更高端的云端版本跑在付费租用的算力上，用得越狠账单越长。

Gemma 4 走的是相反的路径：拿到一份副本部署在自己的硬件上，一次配置完成后没有持续开销，输入的任何内容都不必离开本机——对隐私敏感的场景，这一点的分量远大于跑分。想先试一试的用户可以在 AI Studio 上体验 Gemma 4，本地部署则通常经由 Ollama 完成。Gemma 早期版本曾附带较多使用限制，如今这一层顾虑已经解除，小团队和独立开发者不必再为许可条款专门请教律师。

别再评“史上最强”了

Aguilar 在文章结尾给出了一个明确判断：把 Gemma 4 和千问 3.6 当成争夺同一顶王冠的对手，本身就理解错了题目。依据排行榜名次或品牌认知度二选一，大概率会选错——因为它们要解决的根本是两类问题。同样的道理也适用于 ChatGPT、DeepSeek 背后的模型。

会不会有一天出现一个足够大的模型，把端侧任务和深度仓库分析统统吃下？他认为这个设想并不离谱，但短期内看不到。一个能在 100 万词元的代码里做推理的模型，放到本地跑必然带来明显延迟；能撑起这种上下文窗口的云端模型，背后需要真金白银的服务器集群，还要面对网络延迟、隐私顾虑和运维成本——对普通用户来说很难承受。

所以结论不是“哪个更好”，而是“哪个不适合当前这项任务”。把它们当成两把用途不同的工具对待，两者都会变得更好用。

来源：How-To Geek