Databricks 如何让 12000 名员工在模型发布首日用上新前沿模型

为员工提供前沿 AI 能力是 Databricks 的首要任务，因此，让员工在新模型发布时立即使用它们对我们来说非常重要。与此同时，让超过 10,000 人快速访问一个新模型并非易事，因为：

1. 被宣传为前沿的模型往往并非如此。例如，与 Opus 4.8 相比，Opus 5.0 更昂贵，且在我们的工程师中，其定量和定性质量评分都更低。迁移到一个前沿性倒退的模型可能会严重损害公司，而不是帮助公司。根据我们的经验，在将工作负载大规模迁移到新模型之前，评估模型需要非常谨慎。
2. 天真地使用新模型可能会导致成本爆炸。当我们将 GPT Astra 发布给一个没有相关成本缓解措施的对照组时，开发者的平均支出增加了 60%，相比获得 Astra 访问权限之前。对于拥有超过 10,000 名用户的企业来说，一夜之间成本增加 60% 是非常难以规划的。一旦我们更好地理解了 Astra 在哪些任务上特别出色，我们就能够引导使用，从而大幅降低总体成本。

本文讨论了我们在 Databricks 采用的一套技术，使大多数员工能够在“第 1 天”就访问新模型，同时让我们能够评估这些模型是否确实是优秀的长期主力。这些技术在很大程度上依赖于Unity Gateway来自适应地发布、评估和整合新模型。9 月 21 日那一周是对这些能力的一次关键考验，当时 Opus 5、GPT-6 Sol 和 GPT-Luna 相继发布。在这一周内，Databricks 为所有员工提供了第 1 天访问权限，到第 3 天，我们已经收集了足够的数据来确认这些模型处于效率前沿，从而将它们纳入我们更广泛的基础设施中。

模型发布生命周期

从高层来看，Databricks 的新模型发布遵循如下流程：

1. 立即以“实验性”方式向所有员工提供新模型。
2. 基于每用户预算限制新模型的使用。
3. 在收集足够数据后，决定是否将模型提升到生产环境（甚至将其设为默认）。

第 1 步：立即提供新模型

为了更轻松地管理闭源和开源模型提供商，我们在所有内部使用中利用我们自己的Databricks Unity Gateway。这是我们的 AI 治理、成本管理和可观测性的中心枢纽，因此从这里开始是很自然的。

Gateway 是我们让所有员工访问新发布模型的地方。不过，仅靠服务器端配置是不够的。我们的员工在笔记本电脑上使用 Claude Code、Codex 和Omnigent元框架，我们需要将新模型配置分发给他们。

这正是 Unity Gateway CLI （UG CLI）的用武之地。UG CLI 已经通过我们的移动设备管理部署在每个人的笔记本电脑上。每当有人启动 Claude Code、Codex 或 Omnigent 时，UG CLI 都会运行，检查是否有新的模型、工具和技能，并更新本地 harness 的配置。UG 还让我们能够集中指定默认模型与实验性模型、为 智能路由准备模型，并收集追踪数据以评估每次模型上线。

我们配置了 Unity Gateway，为 Opus 5.5 和 Sol 6 推送实验性配置。这些模型现在会带有此标签显示，这样员工可以选择它，但也明白这是一个新模型，可能并非同类最佳，也可能不会长期存在：

Claude Code / 模型输出明确将 Ous 5.5 标记为实验性

第 2 步：使用每用户预算来限制用量

我们之前曾 撰文介绍过如何为 AI 支出配置每用户预算。自那以后，我们扩展了整体预算架构，纳入了四个主要预算，每个都按每用户定义：

1. 每月上限：每个用户在所有模型上都有一个总体月度支出上限。
2. 每日失控限额：每个用户都有一个每日上限，可以直接在 Slack 中提高，以避免失控会话造成意外支出。
3. [新！] 质量前沿预算：我们将月度预算的一定比例分配给质量前沿的最顶级模型，例如 GPT Astra 和 Claude Fable。（由于 Anthropic 的数据保留政策，Fable 目前尚未在内部推出，但我们正在密切合作以实施其新政策。）这体现了这样的意图：这些模型不应作为日常主力使用，而应被选用于它们特别适合的专业任务，以证明其相比下一质量层级高出 2-3 倍的成本是合理的。
4. [新！] 实验性预算：月度预算的另一部分分配给新的、未经测试的模型的使用。在这里，我们旨在平衡采用速度与广泛暴露一个不在效率前沿上的模型所带来的下行风险。

在模型发布的第一天，我们通过 Unity Gateway 向所有员工开放了 Opus 5.5 和 Sol 6，并将它们标记为实验性预算。随后我们用接下来的几天收集数据，以决定下一步怎么做——去掉实验性标签，还是将其从开发者看到的模型目录中移除。

预算设置概览，反映四个预算

第 3 步：推广或放弃该模型

为了确定模型是否处于效率前沿，我们依赖三个信号：

1. 基准数据：我们有一套私有基准，测试一系列任务，包括离线基准（如文档推理、工作区搜索和我们自己的 Genie 产品），以及在线基准（我们将两个模型并排运行，比较创建拉取请求的输出）。我们会继续扩展和调整这些基准；在理想情况下，我们的基准足以快速确定任何新模型发布的成本和质量。
    
2. 用户反馈的质量： 实验性模型发布提供了大量关于人们如何看待新模型的轶事性数据。我们发现，一群重度用户热衷于尝试新模型，并通过 Slack 和调查问卷比较他们的体验。
    
3. 通过 OpenTelemetry 追踪进行成本跟踪：Unity Gateway 将所有追踪记录集中记录在一个位置，并附带成本信息。我们可以按会话比较试点用户在上一代模型与最新模型上的花费。这不一定能告诉我们质量如何，但能很好地衡量成本。

对于 Opus 5.5 和 Sol 6，这三项指标都向我们展示了一致的情况。

基准测试，例如我们的 OfficeQA Pro V2，表明 Opus 5.5 显然处于成本/质量前沿，在两个维度上相较 Opus 5 都有巨大提升。GPT-6 Sol 在成本和质量两方面都介于 GPT-5.6 Sol 和 GPT-5.6 Terra 之间。

用户反馈 普遍认同，对于工程和调试任务（我们的早期采用者绝大多数是工程师），Opus 5.5 在质量上相较 Opus 5 和 Opus 4.8 有大幅提升，且其写作风格远更受青睐。而 GPT-6 Sol 相较 GPT-5.6 Sol 偶尔在质量上有所下降。

成本跟踪 使我们能够将早期采用者的使用情况与同一群体一周前的使用情况进行比较。保持同一队列至关重要，因为早期采用者往往是 AI 的重度用户，而非普通用户。

我们希望将成本归一化为 $/会话 基准，因为尝试新模型的用户有时会在实验过程中增加会话数量的使用。我们发现，使用基本的 $/会话 比较仍然具有误导性，因为会话的分布也在变化：早期采用者用新模型尝试的是更难的问题，而非他们的平均会话。

因此，我们根据会话是单轮还是多轮，以及是否进行了任何文件编辑，对会话进行了分层，然后相应地重新加权分布。下表显示了 Opus 5.5 对比 Opus 4.8 以及 GPT-6 Sol 对比 GPT-5.6 Sol 的结果。

考虑到价格下调了 50%，GPT 的数字并不太令人意外。但令我们高兴的是，鉴于我们此前使用 Opus 5 的经验，Opus 5.5 也为我们的实际工作负载带来了显著的价格降低。

我们的决定

我们能够在模型发布的第一天就为员工提供 Opus 5 以及 GPT-6 Sol 和 Luna 的实验性访问权限。在三天内，我们就收集到了足够的数据，确认这些模型处于效率前沿，并决定将它们从实验性预算中移出，作为普遍可用的模型纳入标准流通。

在接下来的一周里，我们将为 Opus 5.5 更进一步，使其成为 Claude Code 的 默认选择，因为其作为质量更高、成本低于前代产品的定位十分明确。

我们对 GPT-6 Sol 的经验表明，它不会取代 GPT-5.6 Sol 成为 Codex 的默认选择。不过，鉴于其相较于 5.6 Sol 的成本优势，我们会将 GPT-6 Sol 纳入智能路由器的工具集。 

总体而言，我们发现这套方法能有效快速评估模型的质量和成本，使我们能够迅速采用那些证明自身价值的最新模型。如今新模型几乎每天都在涌现，这种灵活性比以往任何时候都更为重要。