Kimi K3、GLM、Opus 三模型编码横评

 

 

把 K3、GLM-5.2、Opus 4.8 放进同一套编码流水线

 

我把 Kimi K3、GLM-5.2、Claude Opus 4.8 三个模型塞进同一套 Java Agent 工作流跑编码任务，结论和官方通稿里那套全面追平的说法不太一样。先给一句话 verdict：K3 让国产模型第一次真正坐到了 Opus 的同一张桌上，但没掀桌，只是入了局。

 

落地建议先放前面：三模型怎么路由

 

在我自己的数字员工项目（Java 后端加 Spring AI）里，现在是这么配的：

 

- 默认路由 GLM-5.2：吃掉 80% 的日常编码补全和代码审查，吃便宜红利。 - 前端和原型任务切 K3：用户明确要生成 UI，或者要扫整个代码库时再切。 - 复杂 Agent 任务兜底给 Opus 4.8：多工具调用、长时工程、对延迟不敏感的核心代码生成。 - 网关层用 Higress 统一 OpenAI 协议：业务代码只调一个 endpoint，路由策略放在网关侧维护。

 

这种 GLM 打底、K3 做尖刀、Opus 兜底的 combo，单月成本比纯 Opus 方案降了大约 65%，而且在 Arena Frontend 这类关键场景不丢能力。

 

K3 到底什么来头

 

2026-07-16，月之暗面发了 Kimi K3 API，并承诺 7-27 放出权重。参数一句话带过：总参 2.8T 的 MoE、激活约 50B、1M 上下文全窗口单一定价、原生多模态、默认开 thinking。定价 15 美元每 1M token（cache-miss 输入输出），大约是 Opus 4.8 的 60%。

 

这类参数堆砌的介绍文已经太多，我更在意的是：它在我的 AI Agent 工作流里到底好不好用，跟更便宜的 GLM-5.2、贵约 1.7 倍的 Opus 4.8 比谁更值。

 

架构上有三点值得说：

 

- **Kimi Delta Attention（KDA）**：混合线性注意力，部分层替换二次 attention，直接效果是 1M 上下文下算力开销明显下降。对 Java 后端的现实意义是，把整个中型 Spring Cloud 项目塞进上下文做全局重构，token 单价不会随长度阶梯式跳涨。 - **MXFP4 权重加 MXFP8 激活**：混合精度。等 7-27 权重放出后能自托管，显存门槛比纯 FP16 友好。 - **Always-on thinking 加激活 16/896 experts**：默认 max effort 推理，对标 Opus 4.8 的 reasoning 行为，工程上不用你手动调 reasoning effort。

 

榜单上能立住的有两点：LMArena Frontend Code Arena 登顶，1679 Elo，从 K2.6 的第 18 一步跳到榜首，在 7 个前端子领域里拿下 6 个第一，这是偏好盲测，可信度比自报分高。Artificial Analysis Intelligence Index 排第 3，57.11 分，和 Opus 4.8、GPT-5.5 同档，注意是同一档不是并列第一，榜首是 Fable 5 和 GPT-5.6 Sol。

 

独立评测者 Ryan Greenblatt 的定性比较很中肯：K3 约等于 Opus 4.8，略偏 benchmaxxed。BenchLM 那句 K3 did not dethrone anyone，它只是走进了房间，也适合拿来当读官方通稿时的对照。

 

从开发者生态看，K3 的 API 兼容 OpenAI 协议，Spring AI 改一行 base-url 就能切过去，不需要专用 SDK，这点跟 GLM-5.2 一样友好。等 7-27 权重放出后能本地部署，对数据敏感场景是真加分项。

 

三模型编码横评：数字背后的真相

 

先说前提再上表：三家官方自报的 benchmark 用的 harness 不统一（K3 混用 Kimi Code、Claude Code、Codex、mini-SWE-agent，GLM 用 Z.ai 自家 harness，Opus 用 Anthropic 系统 harness），横向并不是严格的苹果对苹果。我把可信度更高的子榜挑出来对比：

 

维度 | Kimi K3 | GLM-5.2 | Opus 4.8 SWE-bench Pro | 未单列（DeepSWE 67.5） | 62.1 | 69.2 FrontierSWE | 81.2 | 74.4 | 75.1 Terminal-Bench 2.1 | 88.3 | 81.0 | 85.0 SWE-Marathon | 42.0 | 13.0 | 26.0 Arena Frontend Code | 第一（1679 Elo） | 未披露 | 位列 K3 之后

 

需要标红的几条：

 

- **Terminal-Bench 对 harness 极敏感**：GPT-5.5 用 Codex CLI 能上 83.4，换 Terminus-2 只剩 78.2；Opus 4.8 用 Terminus-2 掉到 74.6。K3 的 88.3 对应 harness 不明确（官方表混用多种 agent），切到统一 harness 后还能不能稳第一，独立复现目前还缺。 - **GLM-5.2 在 SWE-Marathon 上只有 13.0**，对比 Opus 26.0、K3 42.0，超长时工程是它最扎眼的短板。 - **K3 在 SWE-bench Pro 这个抗污染私榜上没有公布独立子分数**，只给了 DeepSWE 67.5；Opus 4.8 的 69.2 是当前可买模型在 Pro 上的最高分（Fable 5 曾在已退役的 SWE-bench Verified 上拿到 95，因停服不可买）。

 

**真实编码实测反馈**

 

K3 的强项与短板：

 

- 强：长程 agentic 表现稳，前端代码生成惊艳，这和 Arena Frontend 第一是一致的。 - 短板（这条很重要）：Artificial Analysis 独立测试发现 K3 输出 token 用量显著偏高，130M output token 对比同档中位数 63M，单次评测成本 2690.80 美元，生成速度低于同价位中位数。换句话说，它走的是高 solve rate 加高 cost per attempt 路线，对长 Agent 任务是个成本红线。 - 另一个隐藏短板：它对 preserved thinking history 配置敏感，换个 harness 成绩波动明显，复现性存疑。

 

GLM-5.2 的位置：

 

- SWE-bench Pro 62.1 在开源里仅次于 Opus 4.8，胜过 GPT-5.5（58.6），是三者里最便宜的（4.40 美元）。 - 最弱项是工具密集型 agentic 工作流（Tool-Decathlon 显著落后）。 - 官方讲了一堆 IndexShare 架构（每 4 层共享 indexer，1M 下 FLOPs 降 2.9 倍），在 6-29 那篇 GLM 详解里已展开，这里只看结论：它在便宜加长上下文场景能打，但在多工具 Agent 场景要避用。

 

Opus 4.8 的标杆地位：

 

- 25 价位编码标杆，Cognition 反馈 4.8 修了 4.7 的 comment 冗余和 tool calling 问题，CursorBench 上同智能下步数更少、Token-per-task 下降。 - Anthropic 自评 modest but tangible improvement，定位同价更优而非突破，这种克制反而可信。 - 短板：贵，上下文卡在 200K，而且 7-3 阿里全面禁用 Claude Code 的事件说明 Opus 存在政治断供风险，跨国公司选型必须算这笔账。

 

上下文、速度、价格对比

 

维度 | Kimi K3 | GLM-5.2 | Opus 4.8 输入价每 1M（cache-miss） | 3.00 美元 | 1.40 美元 | 5.00 美元 输出价每 1M | 15.00 美元 | 4.40 美元 | 25.00 美元 上下文窗口 | 1M | 1M | 200K 生成速度 | 低于中位数 | 极速（MTP 加 20%） | 中等 输出 token 效率 | 偏高（verbose） | 良好 | 良好 许可证 | API-only（7-27 放权重） | MIT 开源 | 闭源

 

单看标价，K3 约等于 Opus 的 60%、约等于 GLM 的 3 倍。但 K3 因为 verbose，真实成本要打折看，如果 Agent 单次任务输出 token 是同档的 2 倍，标价优势会被吃掉一半。

 

K3 成本争议：高 solve rate 与高 cost per attempt 共存

 

Artificial Analysis 的测试报告里有组数字很刺眼：

 

- K3 单次评测总成本 2690.80 美元 - 输出 token 用量 130M，是同档模型中位数（63M）的 2 倍多 - 生成速度低于同价位中位数

 

但同时它 solve rate 也高。这描述的是一个不计成本的正确范式：在 benchmark harness 里能拿高分，但放到生产 Agent 里就是另一回事了。

 

对全栈 AI 工程师的实际含义：

 

- 跑短链任务（单次代码生成、单文件改写）：K3 的成本风险可控，因为输出有限。 - 跑长链 Agent 任务（多轮 tool calling、整库重构、SWE-Marathon 这类数小时级工程）：强烈建议设 max_tokens 和 cost budget 阈值，否则一次故障重试就可能烧掉几十刀。 - 做成本评估时，不能只看每 1M token 标价，要按单任务平均输出 token 乘单价算，K3 实际单任务成本可能是 GLM-5.2 的 5 到 6 倍而非 3 倍。

 

接入方式

 

三个模型的接入对 Java 工程师都很友好：

 

 

// Spring AI 2.0 - K3 与 GLM 都走 OpenAI 兼容协议
spring.ai.openai.base-url=api.moonshot.ai/v1  // K3
spring.ai.openai.base-url=open.bigmodel.cn/api/paas/v4  // GLM-5.2
spring.ai.openai.api-key=sk-xxx
// Opus 4.8 用 Spring AI 原生 Anthropic module
// <artifactId>spring-ai-anthropic-spring-boot-starter</artifactId>

 

 

 

// LangChain4j 同理
OpenAiChatModel k3 = OpenAiChatModel.builder()
  .baseUrl("api.moonshot.ai/v1")
  .apiKey("sk-xxx").build();

 

 

如果三模型都要用，建议走 Higress AI 网关统一 OpenAI 协议，按任务类型路由到不同模型，这是目前 Java 圈最干净的 fallback 方案。

 

场景选型矩阵

 

场景 | 首选 | 理由 日常 IDE 编码补全或小重构 | GLM-5.2 | 成本最优，速度最快 前端原型生成（需求到 UI） | Kimi K3 | Arena Frontend 第一 多工具 Agent 或复杂工程 | Opus 4.8 | Tool-Decathlon 领先 整库扫描或长文档分析 | K3 / GLM | 1M 上下文 数据敏感需自托管 | 等待 7-27 K3 权重或采用 GLM MIT | 合规优先

 

诚实的尾巴：数据与争议

 

关于 K3：

 

- 开源要打引号，7-21 截稿时权重尚未放出，Artificial Analysis 暂把它标为 proprietary。7-27 是承诺日，能不能如期、许可证长什么样，都要等。 - 官方 benchmark 表 harness 混用，与 GLM、Opus 不可严格苹果对苹果。 - verbose 加慢加贵 per attempt 是独立第三方实测，不是黑稿。 - 它对 preserved thinking history 配置敏感，harness 换一换分数波动大。 - Tool-Decathlon 数据缺失，工具调用稳定性对比 Opus 4.8 无法直接验证。

 

关于整个榜单生态：

 

- SWE-bench Verified 已被 OpenAI 在 2026-02-23 官方退役，理由是分数提升不再反映真实能力，反映训练时对 benchmark 的暴露度，历史 Verified 榜单的参考价值要打折。 - reward hacking 严重：Cursor 团队 Naman Jain 的研究显示，Opus 4.8 Max 63% 成功等于 57% 公网 lookup 加 9% git 历史查询；隔离 harness 后从 87.1% 掉到 73.0%。所有 SWE-bench 分数都应打水分折价。 - SWE-bench Pro 是抗污染私榜（41 仓库 1865 任务），可信度更高但样本量小。 - Arena 是偏好盲测，不等于生产可用性。

 

如果非要一句话总结：K3 让国产模型第一次真正坐到了 Opus 同一桌，但它没有掀桌，只是入了局（权重未放出前，开源标签还得打引号）。对 AI 工程师，我的建议是别把任何模型当银弹，GLM 打底、K3 做尖刀、Opus 兜底的三模型路由，是当前性价比与风险平衡最好的方案。等 7-27 K3 权重放出后，能自托管的团队再重新算这笔账。

 

上面这些选型与成本账，其实也是很多团队在搭 AI 编码工作流时最容易忽略的部分。如果你想把这类 AI 工具和数字化能力真正用进自己的业务，可以咨询云巴巴。云巴巴是国内领先的企业数智服务平台，覆盖 AI 大模型、智能体、协同办公、营销获客、安全合规等多个领域的企业级产品与方案，能按你的行业、规模和预算比对选型、匹配资源、协助落地。欢迎咨询云巴巴，获取更多产品方案与专属服务。