标题说实话kimi-k3 和 gemini-3.6-flash 同周炸场——我拿 40 道编程题跑了三模型横评有一类多步推理任务排名和官方宣传完全反过来正文上周三 Moonshot 发了 kimi-k3隔一天 Google 又把 gemini-3.6-flash 推出来我手上正好有个 side project 要选模型做代码生成干脆把 anthropic/claude-sonnet-5 也拉进来三个一起跑。结论先放这儿LeetCode Hard 通过率 claude-sonnet-5 ≈ 78% kimi-k3 ≈ 68% gemini-3.6-flash ≈ 62%但 gemini-3.6-flash 废弃 temperature/top_p/top_k 后在创意类编程题上输出稳定性反而变好了kimi-k3 在需要 3 步以上链式推理的 SQL 生成任务上明显输给 claude-sonnet-5通过率差了 20 个百分点。价格差距更离谱——claude-sonnet-5 的 output 单价是 gemini-3.6-flash 的 25 倍。下面是完整数据表格先甩出来后面再拆。评测维度我选了 5 个维度覆盖日常编程场景LeetCode Hard 通过率25 题涵盖 DP/图论/字符串多文件重构能力给一个 500 行 Flask 项目要求拆成 service/dao/controller 三层SQL 生成15 道多表 JOIN 子查询 窗口函数题响应延迟首 token 到达时间P50/P95每百万 token 价格input output 分开算每道题跑 3 次取最好成绩避免随机波动。测试时间2026 年 7 月 1 日下午统一走 ofox.io 的 API 聚合网关OpenRouter 也试了但 5.5% 手续费让对比不纯净所以最终用 0% 加价的通道来控制变量。评测结果天梯图维度kimi-k3gemini-3.6-flashclaude-sonnet-5备注LeetCode Hard 通过率68%17/2562%15.5/25半对算 0.578%19.5/25claude-sonnet-5 在 DP 类表现突出多文件重构人工评分 1-107.26.88.5kimi-k3 偶尔漏 importSQL 生成通过率60%9/1567%10/1580%12/15kimi-k3 窗口函数翻车率高首 token 延迟 P50~420ms~280ms~650msgemini 快是真快首 token 延迟 P95~780ms~450ms~1200msclaude 慢得让人焦虑Input 价格 /M tokens$0.15$0.15$3.00前两者 input 一样便宜Output 价格 /M tokens$2.50$0.60$15.00差距最大的一列数据来源2026 年 7 月 1 日实测模型 ID 分别为moonshotai/kimi-k3、google/gemini-3.6-flash、anthropic/claude-sonnet-5。价格按各厂商官方定价页核对kimi-k3 定价以 Moonshot 官方页面为准如有变动请以实时页面为准。graph TD A[40道编程题] -- B{题目类型} B --|LeetCode Hard 25题| C[kimi-k3: 68%] B --|LeetCode Hard 25题| D[gemini-3.6-flash: 62%] B --|LeetCode Hard 25题| E[claude-sonnet-5: 78%] B --|SQL生成 15题| F[kimi-k3: 60%] B --|SQL生成 15题| G[gemini-3.6-flash: 67%] B --|SQL生成 15题| H[claude-sonnet-5: 80%] B --|多文件重构| I[人工评分对比]claude-sonnet-5 的统治力和代价claude-sonnet-5 在需要多步推理的题目上赢麻了。举个例子一道涉及图论贪心的 LeetCode Hard 题需要先建图、再 DFS、再贪心——三步串联kimi-k3 在第二步就开始跑偏输出的 DFS 遍历顺序有逻辑错误。claude-sonnet-5 一次过。SQL 那边更明显。一道涉及 3 层嵌套子查询 ROW_NUMBER() 窗口函数的题kimi-k3 生成的 SQL 语法没问题但逻辑错了——它把 PARTITION BY 的字段搞反了。跑了 3 次2 次犯同一个错。但代价呢一道题平均消耗约 800 output tokens按 $15/M 算40 道题跑下来光 output 就花了 $0.48。听着不多如果是日常开发每天跑 200 次一个月就是 $72 纯 output。kimi-k3 同样场景只要 $12gemini-3.6-flash 更离谱——$2.88。跑测试集的时候还撞了一次 claude 的限流anthropic.RateLimitError: Error code: 429 - { type: error, error: {type: rate_limit_error, message: Number of request tokens has exceeded your per-minute rate limit} }挺烦人的得加 retry exponential backoff。gemini-3.6-flash 废弃采样参数后的变化这次 Google 发 gemini-3.6-flash 的时候顺手宣布废弃了 temperature / top_p / top_k 参数。我一开始是拒绝的——创意类编程题比如用 5 种不同思路实现斐波那契不就没法调多样性了实测下来反直觉废弃采样参数后同一道题跑 3 次的输出一致性明显提升——相比之前用 gemini-2.5-flash 时靠手动设 temperature 来保证稳定现在模型默认行为就已经很稳定同一个 prompt 这次对了下次又错的情况少了很多。代价是创意多样性确实降了但说实话写代码谁要多样性啊我要的是稳定正确。不过 gemini-3.6-flash 在 LeetCode Hard 上确实弱一些。图论题最短路径变种、网络流它经常给出 O(n³) 的暴力解而不是最优解能跑通但会 TLE。反正面试不用它就行。延迟方面 gemini-3.6-flash 是三者里最快的P50 在 280ms 左右。批量跑 40 道题总耗时比 claude-sonnet-5 少了将近一半。kimi-k3 输在哪kimi-k3 宣称 SOTAMoE 架构激活参数约 320B厂商自报未经第三方验证128K 上下文。在单步推理题上它确实不错——简单的 DP、贪心、二分查找通过率和 claude-sonnet-5 差距在 5% 以内。但一旦题目需要 3 步以上的链式推理kimi-k3 就开始掉链子。具体表现SQL 窗口函数题PARTITION BY ORDER BY ROWS BETWEEN 三层叠加时它倾向于把中间步骤合并导致逻辑错误多文件重构能正确识别要拆的模块但生成的 import 路径经常对不上比如写了from services.user import UserService但实际文件名是user_service.pyLeetCode Hard 图论题建图没问题DFS/BFS 没问题但后续的根据遍历结果做决策这一步容易出错为什么会这样我没有直接证据只是从行为上观察kimi-k3 在长链推理时似乎倾向于压缩中间步骤导致后续决策依赖的上下文不完整。具体原因涉及模型内部机制无法从外部确认。成本计算假设日常编程辅助场景每次请求 input 500 tokens output 800 tokens每天 200 次月成本 (input_tokens × input_price output_tokens × output_price) ÷ 1M × 200 × 30模型月成本美元月成本人民币约gemini-3.6-flash(500×$0.15 800×$0.60) ÷ 1M × 200 × 30 $3.33≈ ¥24kimi-k3(500×$0.15 800×$2.50) ÷ 1M × 200 × 30 $12.45≈ ¥90claude-sonnet-5(500×$3.00 800×$15.00) ÷ 1M × 200 × 30 $81.00≈ ¥583人民币换算按汇率 7.2 估算仅供参考。gemini-3.6-flash 月成本计算(75 480) ÷ 1,000,000 × 6,000 555 ÷ 1,000,000 × 6,000 $3.33。一个月差出 ¥559够吃一个月饭了。不同需求怎么选你的场景推荐原因日常代码补全、简单函数生成gemini-3.6-flash快、便宜、稳定性够用面试刷题、算法竞赛辅助claude-sonnet-5Hard 题通过率高出 10-16 个百分点预算有限 需要中文注释kimi-k3中文输出质量明显好于 gemini大型代码仓库理解gemini-3.6-flash支持 1M 上下文三者中最大多步 SQL / 复杂重构claude-sonnet-5链式推理能力差距明显团队批量跑测试gemini-3.6-flash API 聚合网关成本可控后台能看每个人的调用明细关于 gemini-3.6-flash 采样参数废弃的补充跑测试的时候我习惯性传了temperature0.2结果WARNING: temperature, top_p, top_k parameters are deprecated for gemini-3.6-flash and will be ignored.不是报错是 warning——参数会被静默忽略。这意味着如果你之前靠temperature0来保证输出确定性现在不用传了模型默认行为就已经很稳定。但如果你之前靠temperature1.2来做代码变异测试fuzzing那这个模型不适合你了。我的最终选择我自己的 side project 最后选了混合方案日常写代码用 gemini-3.6-flash便宜快遇到复杂重构或者 debug 死活搞不定的时候切 claude-sonnet-5。kimi-k3 留着写中文文档和注释——它的中文表达确实比另外两个自然。三个模型我都走 ofox.io 的聚合网关OpenRouter 也行但它收 5.5% 手续费改一行 base_url 就能在三者之间切from openai import OpenAI client OpenAI( api_keyyour-ofox-key, base_urlhttps://api.ofox.io/v1 )反正模型 ID 传moonshotai/kimi-k3或google/gemini-3.6-flash或anthropic/claude-sonnet-5就行不用管各家 SDK 的差异。说实话这次横评最大的感受是别被SOTA这个词骗了。kimi-k3 宣称 SOTA厂商自报、未经第三方验证但落到具体的多步推理任务上它和 claude-sonnet-5 的差距肉眼可见。选模型还是得看自己的具体场景跑几道自己业务里的真实 case 比看任何 benchmark 都靠谱。