SWE-Bench 高就一定会写项目？一篇 GH200 实测给了三个反例

这两年选 Coding Model，SWE-Bench 几乎成了必看榜单。

这没问题。

问题出在很多人把：

SWE-Bench 高

直接推导成：

更适合我的真实项目

今年 4 月有一篇很有意思的实验论文，标题很直白：

React-ing to Grace Hopper 200: Five Open-Weights Coding Models, One React Native App, One GH200, One Weekend

作者 Alex Potanin 用一台 NVIDIA GH200 576GB 节点，把几种开放权重 Coding Model 放到同一个 React Native 项目任务上。

这篇论文不是大规模 benchmark，只有一个 Prompt、一个任务、一个周末。作者自己也在论文里把这些限制写得很清楚。

但正因为任务很具体，它暴露了几个“榜单上很难看到”的工程问题。

我觉得值得单独拆出来看。

先把实验条件说清楚

硬件：

NVIDIA GH200 576GB
96GB HBM3
480GB LPDDR5X unified memory
72 ARM cores

推理后端：

llama.cpp build b8797
Unsloth Dynamic 2.0 GGUF

客户端：

MacBook Pro M1 Max 64GB
aider 0.86.2
whole edit-format

统一任务只有一句：

create react-native app that allows user to create account and login
and then count kangaroos seen per day and make sure it runs on the web

然后检查：

• 能否开箱运行；
• 登录是否真的校验凭证；
• 用户数据是否隔离；
• 是否按天计数；
• 历史是否保存；
• Logout 是否工作；
• Web 端是否安全兼容。

测试的模型包括：

Kimi-K2.5 Q3
Kimi-K2.5 Q4
GLM-5.1
Qwen3-Coder-480B
DeepSeek-V3.2

第一个反例：榜单更高，不代表产品决策更好

论文里最有意思的结果是：Kimi-K2.5 的 3-bit 量化版本，反而做出了最完整、最符合需求的应用。

GLM-5.1 当时在 SWE-Bench Pro 上有非常高的成绩，但在这个任务里选择了 Firebase Authentication。

从“代码是否正规”的角度，它没错。

问题是实验要求的是：

生成后就能运行

Firebase 方案需要用户额外提供 firebaseConfig.js。

所以作者给它的评价很尖锐：

technically correct, operationally useless

这恰好是 Coding Agent 最容易踩的坑。

模型会写“看起来更专业”的架构：

云认证
微服务
复杂依赖
生产级抽象

但用户真正想要的是：

先跑起来

这不是代码能力问题，是需求判断问题。

第二个反例：Reasoning 泄漏，最后变成了文件路径 Bug

DeepSeek-V3.2 的案例更典型。

Aider whole-edit 格式要求模型输出：

文件名
```代码块```

但模型一次输出的第一行类似：

Let’s start with App.js:App.js

结果 Aider 把整行当成文件路径。

于是 App.js 没写到正确位置，项目直接无法 Bundle。

这个问题很值得工程团队记住，因为它不是“模型代码写错了”。

它是：

模型输出格式
×
Reasoning 边界
×
工具解析器

三者组合出来的 Integration Bug。

如果你的 Agent 会根据模型输出执行文件、Shell、SQL 或 API，永远不要把模型输出直接当成结构化指令。

至少做：

Schema
路径规范化
允许目录
Reasoning标记清理
非法字符
白名单

尤其是文件路径，模型前面多一个“Here is...”就可能把系统搞坏。

第三个反例：所有模型都踩了同一个 React Native Web 坑

这篇实验最让我意外的一点，是所有测试模型都使用了：

Alert.alert

在 React Native 原生环境里很正常。

但任务明确要求：

make sure it runs on the web

Alert.alert 在 react-native-web 中并不能按预期完成这些确认交互。

结果出现：

• 注册校验静默失败；
• 清除历史按钮没有实际动作；
• 保存行为被阻断。

代码能编译，项目甚至能启动，但功能不对。

这正好说明一件事：

“能编译”距离“真的能用”还很远。

如果你的 Coding Benchmark 只检查：

代码能否生成
Patch能否应用
测试是否通过一部分

就很难发现这类跨平台行为问题。

温度为 0 也不一定更稳定

作者还记录了一个部署细节。

Aider 默认偏向 temperature=0，但 Kimi-K2.5 官方建议：

temperature=1.0
top_p=0.95

实验里使用 temperature=0 时出现长时间无输出。作者一开始误以为是 GH200 统一内存压力，后来按模型官方采样参数覆盖后恢复正常。

论文报告的生成速度：

Kimi K2.5 Q4：7.9 tok/s
Kimi K2.5 Q3：17 tok/s

这件事非常实际：

Coding Tool 的默认参数，不一定适合所有 reasoning model。

如果你通过 Aider、OpenAI-compatible gateway 或自己的 Agent Harness 接不同模型，模型参数应该是 Profile，而不是全局一套配置。

例如：

models:
  kimi-k2.5:
    temperature: 1.0
    top_p: 0.95

  glm-5.1:
    temperature: 0.6
    top_p: 0.95

  qwen3-coder:
    temperature: 0.7
    top_p: 0.8
    top_k: 20

这篇论文的排名不能被过度解读

我要替作者再强调一次限制：

只有一个 Prompt
每模型只跑一次
没有多 Seed
没有迭代修复
只有 React Native 一个技术栈
使用 Aider whole-edit
量化方案也不完全相同

所以不能从这篇论文得出：

Kimi 永远比 GLM / Qwen / DeepSeek 更强

这不是论文结论。

它真正有价值的结论是：

标准 Coding Benchmark 的排名，不能替代你自己的 Artifact-Level Evaluation。

如果把这个实验方法搬到自己的公司

我会挑 10—20 个真实工程任务，而不是自己编算法题。

例如：

1. 修复一个真实线上 Bug
2. 增加一个 REST API
3. 修改数据库字段并兼容旧数据
4. 修复一个前端移动端布局
5. 增加权限校验
6. 升级一个依赖版本
7. 增加测试
8. 处理一个跨平台问题
9. 修复并发 Bug
10. 根据 Issue 完成小 Feature

每个任务检查：

能否直接运行
测试通过率
是否满足需求
是否产生无关改动
安全问题
人工Review分钟数
调用次数
成本

再让模型自己改第二轮、第三轮。

因为真实 Coding Agent 不是“一次生成”，而是：

读代码
→修改
→跑测试
→读错误
→再修改

我最想保留的一个指标：Artifact Success

很多 benchmark 最终是一个分数。

但实际团队更容易理解：

这个 PR，我敢不敢合？

所以可以定义：

Artifact Success =
项目能运行
AND 必需测试通过
AND 功能验收通过
AND 无关键安全问题
AND 无禁止改动

最后再看 Token 和成本。

模型排行榜仍然值得看。

只是别在买硬件、签年度 API 合同或重构开发流程之前，只看排行榜。

这篇 GH200 实验最有价值的提醒就是：模型真正失败的地方，常常不是“不会写代码”，而是在规格理解、集成边界和产品行为上。

而这些，恰恰只有把模型放进真实项目里才能看到。

更多企业级 AI 应用、Agent、RAG 与模型工程化内容，我会继续整理在 智元界：

https://www.zyentor.com/