尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
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 的麻烦。
RELATED

相关推荐

AI落地失败,最大的变量不是技术,而是组织

AI落地失败,最大的变量不是技术,而是组织

过去,一个岗位对应一个人。未来,一个岗位,对应的是“人 Data Agent”共同协作。最近两年,AI以前所未有的速度进入企业经营,企业投入持续加码,但真正见到实效的却凤毛麟角。问题究竟出在哪儿?近…

📅 2026/8/24 1:26:41
MiniMax市值缩水3000亿港元,从明星公司到普通上市企业,能否重回千亿市值?

MiniMax市值缩水3000亿港元,从明星公司到普通上市企业,能否重回千亿市值?

【MiniMax股价暴跌,市值缩水超3000亿港元】上市半年的MiniMax,股价经历了一轮过山车走势,从4000亿港元到不足1000亿港元。7月21日收盘,MiniMax股价报收222.4港元,总市值776.7亿港元。半年前的1月9日,公司在…

📅 2026/8/24 1:26:44
大模型测试:按产品形态区分完整测试方案

大模型测试:按产品形态区分完整测试方案

目录 一、大模型主流产品形态分类 1. 纯 API 服务型(后台能力底座,无前端界面) 2. 网页端对话应用(C 端通用聊天产品) 3. 客户端独立 App(手机 / PC 桌面端) 4. 嵌入式 / 插件集成型&#…

📅 2026/8/24 1:26:44
MORE NEWS

更多资讯

📰

MCP 协议实战(下):JSON-RPC 机制拆解与面试高频考点

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

Codex 100个真实案例 - 用AI做中文智能分词工具(自定义词典+可视化)

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

多模态AI搜索信源筛选:大模型采信证据链与内容适配路径

一、多模态AI搜索的四个常见问题多模态AI搜索正在改变用户获取信息的路径。当用户向豆包、文心一言、DeepSeek等平台提问时,答案并非凭空生成,而是基于一套隐性的信源筛选与证据权重机制。企业面临的第一道困惑是:为什么官网内容详实&#xf…

📰

GEO内容信任危机:AI搜索时代企业权威性如何构建

一、GEO优化的技术实践的四个常见问题当生成式引擎优化进入企业视野,一个被反复提及的困惑是:为什么精心准备的内容投喂给大模型后,AI在回答用户提问时依然绕开企业信息?行业调研中常遇到四类典型问题。其一,企业官网内…

📰

Atlas 300V 24G部署YOLO实战:从ONNX转换到多路视频推理

1. 先说清楚:Atlas 300V 24G到底是什么卡这段时间好几个做视觉检测的朋友来问我同一件事——“Atlas 300V 24G是不是运算加速卡?能不能直接拿来部署YOLO?”问的人多了,我意识到很多人其实对这个系列的认知是模糊的,甚至…

📰

PyTorch BCEWithLogitsLoss实战指南:从原理、参数到工业级避坑

1. 这不是“套公式”,而是理解二分类损失的底层心跳BCELoss——全称Binary Cross Entropy Loss,中文常译作“二元交叉熵损失”或“二分类交叉熵损失”。如果你刚接触PyTorch,大概率在写第一个分类模型时就撞见它:nn.BCELoss()或更…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬