Databricks 如何让 1.4 万名员工在模型发布首日用上新模型

让我们的员工能够使用前沿 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 的默认模型。不过，鉴于 GPT-6 Sol 相对于 5.6 Sol 的成本优势，我们会将 GPT-6 Sol 纳入我们智能路由器的工具集。 

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