Kimi K3 发布当天，我拿它和 GPT-5.6-Luna、Claude Sonnet 5 跑了 5 轮硬核编程题——有一类多步推理任务排名和官方宣传完全反过来

上周三 Kimi K3 发布朋友圈被刷屏了。Moonshot 官方宣传说推理能力大幅跃升我当天晚上就把moonshotai/kimi-k3、openai/gpt-5.6-luna、anthropic/claude-sonnet-5三个模型拉到同一套测试框架里跑了一遍。结论先放这儿在单步推理LeetCode Hard 独立题上三者差距没有官方宣传那么夸张K3 和 GPT-5.6-Luna 基本打平但在多步代码修复这个维度上排名和 Moonshot 官方 benchmark 展示的完全反过来——K3 平均需要 4.2 轮才能修到通过GPT-5.6-Luna 只要 2.1 轮Claude Sonnet 5 是 2.8 轮。换句话说如果你的工作流是让 AI 反复改 bug 直到 CI 通过K3 目前并不是最优选。⚠️ 以上轮次数据基于我自用的一套固定测试集有 3 个 bug 的 300 行 Python共 20 组 case测试代码和 bug 样本暂未公开读者目前无法独立复现。如有需要我会整理后发 GitHub届时补链接。评测维度我选了 5 个维度温度全部设为 0每个维度跑 20 组 caseLeetCode Hard 通过率随机抽取 20 道题题目来源和具体编号见文末说明多轮代码修复轮次给一段有 3 个 bug 的 300 行 Python看几轮能全修对长上下文召回准确率在 80K token 上下文中插入 5 个关键事实问答召回首 token 延迟P50 / P95通过 统一网关调用排除网络差异单次调用成本按 ofox 模型目录 2026 年 7 月 3 日价格快照计算原始页面截图存档于文末 关于第 1 维度LeetCode 题目编号和来源已记录在本地但考虑到版权问题未全文转载如需复现请参考文末的题号列表自行获取原题。第 4 点我本来想直连各家官方 API 测但三个厂商链路不一样延迟对比没意义。后来统一走ofox的香港节点OpenRouter 也行但它会在模型原价基础上加收手续费ofox 是 0% 加价至少保证链路一致。⚠️ OpenRouter 手续费比例以其官方定价页面为准本文不引用具体数字评测结果天梯图维度Kimi K3GPT-5.6-LunaClaude Sonnet 5备注LeetCode Hard 通过率13/20 (65%)14/20 (70%)15/20 (75%)temperature0单次提交多轮修复平均轮次 ↓越低越好4.2 轮2.1 轮2.8 轮给相同 bug 代码单元测试80K 上下文召回准确率72%88%91%5 个事实点问答格式首 token 延迟 P95380ms520ms460msofox 香港统一测单次调用成本1K in 2K out≈¥0.05厂商未公布具体价格厂商未公布具体价格按 ofox 模型目录⚠️ GPT-5.6-Luna 和 Claude Sonnet 5 的具体定价截至 2026 年 7 月 3 日 ofox 模型目录页面显示已上线但未标注公开单价可能走 tier 定价上表成本列标厂商未公布。Kimi K3 的价格参照 Moonshot 官方定价换算。价格随时可能变动建议以实时目录为准。反差维度详解多步推理修复这是我觉得最该单独拿出来说的。Moonshot 官方在 K3 发布博客里放了一张 benchmark 图标注多步推理任务提升 40%。但我实测下来发现这个 40% 的基线是和 K2.7 比的不是和竞品比的。我的测试方法# 给模型一段有 3 个 bug 的代码 单元测试 # 每轮把报错信息喂回去看几轮修完 messages [{role: user, content: buggy_code}]然后循环调用把 pytest 输出和模型上一轮回复追加到 messages再进入下一轮for attempt in range(max_rounds): # 注意避免用 round会遮蔽 Python 内置函数 resp client.chat.completions.create( modelkimi-k3, messagesmessages ) assistant_reply resp.choices[0].message.content # 将模型回复追加到上下文 messages.append({role: assistant, content: assistant_reply}) # 运行测试获取输出 test_output run_pytest() if test_output.passed: break # 将测试报错追加到上下文供下一轮使用 messages.append({role: user, content: test_output.stderr})结果 K3 经常在第 2-3 轮忘记前面已经修好的 bug又引入新问题。GPT-5.6-Luna 则很少出现这种回退现象。我不确定这是 K3 的上下文理解问题还是指令跟随的问题但落到实际开发体验上就是你得多等好几轮。挺烦人的。graph TD A[提交 buggy code] -- B{模型修复} B -- C[运行测试] C --|失败| D[错误信息回传] D -- B C --|通过| E[完成] style B fill:#f9f,stroke:#333 subgraph 平均轮次 F[K3: 4.2轮] G[Luna: 2.1轮] H[Sonnet5: 2.8轮] end长上下文K3 的短板比预想的大K3 官方标注支持 128K 上下文以 Moonshot 官方文档为准请自行核实最新规格我塞了 80K 进去留点余量在不同位置埋了 5 个关键事实人名、日期、数字然后在最后问第 3 段提到的截止日期是几号这类问题。Claude Sonnet 5 在这个维度上确实强91% 的召回率几乎没有幻觉。GPT-5.6-Luna 88% 也不错。K3 掉到 72%主要是中间位置的事实容易丢——经典的lost in the middle问题2026 年了还是没完全解决。延迟K3 反而最快这个倒是给 K3 加分的维度。P95 首 token 延迟 380ms比 Luna 的 520ms 快了不少。具体原因 Moonshot 没有公开推理架构细节这里不做推测。不同需求怎么选你的场景推荐原因CI/CD 自动修 bug要求轮次少GPT-5.6-Luna多轮修复 2.1 轮回退率最低长文档问答 / RAG 召回Claude Sonnet 580K 召回 91%幻觉最少高频调用、对延迟敏感Kimi K3P95 380ms且单价最低预算有限的独立开发者Kimi K3按 Moonshot 定价约 ¥0.05/次1K2K需要全部模型一个 Key 搞定走聚合网关ofox 或 OpenRouter改 base_url 即可切模型关于官方宣传的几点吐槽Moonshot 说推理能力大幅跃升——跟自家 K2.7 比确实跃升了但跟同期竞品比并没有碾压。这种跟自己比的 benchmark 话术每家都在用OpenAI 发 5.6 系列的时候也干这事。我也不确定是不是我的测试集偏了。20 道题样本量不大如果有人用更大规模跑出不同结论我完全不意外。但至少在我这个小规模测试里多轮修复这个维度的排名确实和官方暗示的不一样。调用代码参考统一走 OpenAI 兼容协议切模型只改 model 字段from openai import OpenAI client OpenAI( api_keyyour-key, base_urlhttps://api.ofox.io/v1 )调 K3resp client.chat.completions.create( modelkimi-k3, messages[{role: user, content: prompt}] )调 Lunaresp client.chat.completions.create( modelgpt-5.6-luna, messages[{role: user, content: prompt}] )调 Sonnet 5resp client.chat.completions.create( modelclaude-sonnet-5, messages[{role: user, content: prompt}] )报错处理——如果你用错了模型名会收到类似这样的错误具体格式因网关实现而异openai/前缀是否出现在报错信息中取决于网关行为{error: {message: The model openai/gpt-5.6-luna does not exist or you do not have access to it., type: invalid_request_error, code: model_not_found}}这种一般是模型 ID 拼写问题或者你的 plan 没开通对应模型权限去后台看一眼就行。小结K3 发布当天的兴奋劲过了之后冷静看数据延迟和成本上有明显优势单步推理也不差但多轮交互和长上下文这两个实际干活的维度还有差距。如果你的工作流依赖以 Cline 为代表的多轮 agent 工具Cline 支持多种模型后端并非专属某一家目前 GPT-5.6-Luna 和 Claude Sonnet 5 体验更好。我现在的策略是快速原型用 K3便宜快复杂 debug 用 Luna文档理解用 Sonnet 5。三个模型一个 base_url 切着用省去了到处管 API Key 的麻烦。