Databricks CEO用自家3000名程序员真实任务重磅测试：GLM 5.2 表现夯爆了

Databricks的联合创始人兼CEO Ali Ghodsi最近整了一个大活。

公司有1.1万名员工，AI相关的开销越来越高，到底该用哪个模型搭配哪种执行框架，才能在省钱的同时保住效果？

自己动手做了一次大规模测试。这次测试基于Databricks真实的业务代码，覆盖3家主流云厂商，由3000多名工程师的实际工作产出支撑，涉及多种编程语言和任务类型。

测试结果显示，同一个模型换一套执行框架（也就是通常说的harness），成本能差出接近2倍。他们还发现GLM 5.2表现非常强悍，真实任务和opus 4.8一样好。基于这些结论，Databricks在模型和框架之上搭了一层调度系统Omnigent，可以按任务灵活切换不同的模型和框架组合。

具体的测试方法和结论，由Databricks的几位工程负责人Vinay Gaba、Ankit Mathur、Rishabh Singh、Patrick Wendell以及首席技术官Matei Zaharia联合撰文公开。

https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase

测试的核心结论

第一，在编码任务的帕累托前沿上，也就是在特定成本下表现最好的方案中，同时存在着OpenAI、Anthropic的模型以及开源模型。这意味着目前还没有哪一家供应商能够垄断全场景。

第二，开源模型展现出了极强的实力，尤其是GLM 5.2已经能够应对最高难度的编码任务。

第三，单价，也就是每Token的价格，不能直接代表最终的实际任务成本。大模型的推理效率可能更高，反而能节省整体费用。

第四，调用模型的框架，也就是Harness，对成本和质量有着决定性的影响。在许多情况下，像Pi这样简单的框架表现得更加客观高效。

模型分类呈现出能力梯队

在实际任务中，微小的分数差异并不关键，团队更关注模型和框架分类表现出的规律。测试结果显示，模型和框架可以清晰地划分为三个能力梯队。

处于顶端的高智能模型能够高效解决各类难题，但其成本非常高。而处于中低梯度的模型在处理常见任务时同样高效，且价格要便宜得多。

在日常工作中，工程师面对的任务复杂度各不相同。更新配置或修改一个开关并不需要最高级的智能。因此，Databricks决定将更多日常工作分流给Haiku和GPT 5.4 Mini级别的模型，避免盲目使用高价模型。

开源模型迎来突破

开源模型的发展引人瞩目。测试结果表明，GLM 5.2完全可以胜任日常开发。它成功跻身顶级能力梯队，在质量上与Opus 4.8基本持平，但单次任务成本为1.28美元，低于后者的1.94美元。

这一结果也印证了内部开发者的实际反馈。由于其在日常编码中的优秀表现，团队已经开始着手将这类开源模型部署为日常开发的主力工具。

Token价格不等于任务成本

开发者通常会通过对比Token单价来估算AI的费用，但测试表明，这种估算往往不够准确。不同模型的推理效率差异巨大，任务层面的基准测试因此显得尤为重要。

例如，Sonnet 5的Token单价比Opus 4.8便宜约1.7倍。但在实际任务中，Sonnet 5的单次任务成本为2.09美元，而Opus 4.8仅为1.94美元。同时，Sonnet 5的任务完成率还比Opus 4.8低了6个百分点。造成这种现象的原因在于，Sonnet 5为了完成任务需要进行更长时间的尝试，阅读了更多内容，从而多消耗了1.9倍的Token。

调用框架对效率影响巨大

即使调用完全相同的模型，如果使用不同的框架，如Claude Code或Codex对比Pi，其任务成本可能会产生两倍以上的差距，而最终的质量却保持一致。

这种差异主要源于不同框架每次向模型输入上下文的数量。测试发现，Pi每次交互发送的上下文减少了约三倍。它通过更紧凑的工作集管理上下文，从而用更少的轮次完成了任务。

这提示我们，单凭模型选择无法决定整体效率，框架同样扮演着关键角色。为了能灵活切换不同的模型和框架，Databricks投资了Omnigent以实现无缝的方案替换。

为什么要建立自己的基准测试

虽然有SWE-Bench等公开测试集，但它们无法解答企业内部的具体疑问。一方面，公开测试集的任务很容易泄露到大模型的训练数据中。另一方面，公开测试集无法代表包含Scala、Go、Rust、Java、Bazel等多种语言和工具链的复杂私有代码库。

因此，基于自身拉取请求（即PR）构建基准测试，能够提供更具说服力的优化决策。

基准测试是如何构建的

团队利用Unity AI Gateway收集了所有编码交互日志，以分析任务的复杂度。结果显示，低复杂度的任务占到四分之一，中等复杂度任务约占六成。

测试集的构建过程经过了多重筛选：

1. 1. 时效性：提取最近的提交记录以反映当下的框架和规范。
2. 2. 人工编写：过滤掉自动生成的更改和机器人提交。
3. 3. 高质量测试集：确保可以验证代码的正确性。
4. 4. 模块自治：确保改动范围可控。
5. 5. 任务分布代表性：覆盖全栈各类服务和配置。

确定PR后，团队通过以下方式构建具体任务：

第一，总结开发意图并转化为提示词。通过阅读PR理解其真实目的并描述目标，同时去掉关于具体解决方案和Bug成因的解释，避免降低任务难度。

第二，分离出测试文件。将测试文件单独存放，并确保其余文件能够正常编译，随后通过构建系统运行所有相关的测试。

在此过程中，虽然使用了脚本和AI辅助生成任务，但每个样本都经过了人工校准。有时还需要手动重写测试用例，以使其更具容错性和严谨性。

当AI代理声明任务完成时，系统会保存代码，合入保留的测试，并根据测试通过情况判定结果。评估不依赖LLM裁判，而是依靠客观的测试结果。

为了防止AI代理利用Git历史记录作弊，团队在测试期间对Git历史进行了隔离，使其无法通过Git回溯找到原本的正确解答。

下一步计划

利用好AI程序员，关键在于因地制宜。未来，Databricks计划引入Unity AI Gateway和Omnigent的智能路由功能，根据任务类型自动推荐最合适的模型，实现效率和成本的更优平衡。

文章来自于微信公众号 “AI寒武纪”，作者 “AI寒武纪”