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 元 harness，我们需要将新模型配置分发给他们。

这就是 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 标记为 Experimental

第 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 traces 进行成本追踪： Unity Gateway 将所有 traces 连同成本信息一起记录在一个集中的位置。我们可以比较试点用户在上一代模型和最新模型上的逐会话花费。这不一定能告诉我们质量如何，但能很好地衡量成本。

对于 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 的结果。

GPT 的数据并不太令人惊讶，因为价格降低了 50%。但我们很高兴 Opus 5.5 也代表了实际工作负载的显著价格降低，考虑到我们之前使用 Opus 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 纳入我们的智能路由器工具包中。

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