How Databricks rolls out frontier models to 12,000 employees on Day 1

Databricks如何在第一天向12,000名员工推出前沿模型 | Databricks博客

跳至主要内容

Unity Gateway

2026年9月28日

Databricks如何在第一天向12,000名员工推出前沿模型

Databricks AI产品与工程团队著

为员工提供前沿AI能力是Databricks的首要任务，因此当新模型可用时，我们希望员工能够立即使用。同时，向超过12,000人快速开放新模型存在显著挑战：

• 被宣传为前沿的模型往往并非如此。例如，Opus 5.0相比Opus 4.8在成本和定量/定性质量评分上均表现更差。迁移到退化前沿的模型可能对企业造成实质性伤害。根据我们的经验，大规模迁移工作负载前需要格外谨慎评估模型。

• 盲目使用新模型可能导致成本激增。当我们向没有成本控制措施的对照组开放GPT Astra时，开发者平均支出比之前增加了60%。对于超过10,000人的用户群体，单日60%的成本增幅对企业来说是难以规划的。当我们更深入了解Astra在特定任务上的优势后，成功引导使用模式使总体成本显著降低。

本文将讨论我们采用的一系列技术，使Databricks大多数员工能在新模型发布"第一天"即获得访问权限，同时评估模型是否具备长期价值。这些技术高度依赖Unity Gateway实现模型的自适应发布、评估和集成。9月21日当周是关键测试期，Opus 5、GPT-6 Sol和GPT-Luna在短时间内相继发布。当周内Databricks向所有员工开放了Day 1访问权限，到第3天已收集足够数据确认这些模型处于效率前沿，随后将其整合到更广泛的基础设施中。

模型发布生命周期

从宏观层面看，Databricks的新模型发布流程如下：

• 立即以"实验性"方式向所有员工开放新模型

• 基于每个用户的预算限制新模型使用

• 在收集足够数据后，决定是否将模型推广至生产环境（甚至设为默认）

第一步：立即开放新模型

为简化对封闭和开放模型提供商的模型管理，我们使用自研的Databricks Unity Gateway处理所有内部使用。作为AI治理、成本管理和可观测性的核心枢纽，从这里开始是自然的选择。

Gateway是员工访问新模型的入口。但仅靠服务器端配置是不够的。我们的员工正在使用Claude Code、Codex和Omnigent元框架工具，需要将新模型配置分发到他们的笔记本电脑上。

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

我们已配置 Unity Gateway 向 Opus 5.5 和 Sol 6 推送实验性配置。这些模型现在会显示此标签，使员工能够选择它们，但也能理解这些是新模型，可能并非最佳选择，也可能不会长期保留：

Claude Code / 模型输出明确标注 Opus 5.5 为实验性模型

第 2 步：通过用户预算限制使用

我们之前曾撰文介绍如何为 AI 花费配置用户级预算。此后，我们扩展了整体预算架构，新增了四个基于用户维度的预算：

• 月度上限：每个用户在所有模型上的月度总支出设有上限。
• 每日失控限制：每个用户设有每日最大额度，若出现失控会话，用户可通过 Slack 直接提高限额以避免意外支出。
• [新增！] 质量前沿预算：我们将月度预算的一定比例分配给质量前沿的顶级模型（如 GPT Astra 和 Claude Fable）。由于 Anthropic 的数据保留政策，Fable 目前尚未内部上线，但我们正与对方密切合作以实施新政策。这体现了我们的意图：这些模型不应作为日常主力使用，而应专门用于其特别擅长的场景，以证明其相比下一质量层级的 2-3 倍成本增加是合理的。
• [新增！] 实验性预算：月度预算的另一部分用于新模型的试用。在此，我们试图在快速采用与广泛暴露未达效率前沿模型的潜在风险之间取得平衡。

在模型发布首日，我们通过 Unity Gateway 向所有员工开放了 Opus 5.5 和 Sol 6，并将其标记为实验性预算使用。随后的几天里，我们收集数据以决定下一步行动——是保留实验性标签，还是从开发人员可见的模型目录中移除该标签。

预算设置概览，体现四个预算层级

第 3 步：推广或下架模型

为了判断模型是否达到效率前沿，我们依赖三个信号：

• 基准数据：我们拥有一套私有基准测试，涵盖文档推理、工作区搜索、自有 Genie 产品等离线任务，以及并行运行两个模型进行拉取请求创建的在线基准测试。我们持续扩展和优化这些基准测试；在理想情况下，我们的基准测试足以快速评估任何新模型的成本和质量。
• 用户反馈质量：实验性模型发布为新模型提供了丰富的轶事数据，反映用户对其的感受。我们发现，一群高活跃用户特别热衷于尝试新模型，并通过 Slack 和调查反馈比较使用体验。

• 通过 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 的高阶用户，而非普通用户。

我们希望将成本标准化为每会话费用（$/session），因为尝试新模型的用户在实验过程中有时会增加会话次数。我们发现仅使用基础的 $/session 对比仍然具有误导性，因为会话分布也在变化：早期采用者使用新模型时尝试的难题比其平均会话更复杂。

因此，我们根据会话是单轮还是多轮、是否进行了文件编辑对会话进行分层，并据此重新调整分布权重。下表显示了 Opus 5.5 与 Opus 4.8、GPT-6 Sol 与 GPT-5.6 Sol 的对比结果。

成本对比

旧模型（平均 $/session）

新模型（平均 $/session）

差异

Opus 4.8 vs. Opus 5.5

$5.94/会话（Opus 4.8）

$4.23（Opus 5.5）

−29%

GPT-5.6 Sol vs. GPT-6 Sol

$4.52/会话（GPT-5.6 Sol）

$2.34/会话（GPT-6 Sol）

−48%

考虑到价格降低了 50%，GPT 的数据并不令人意外。但我们很高兴发现 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 纳入智能路由工具包中。

总体而言，我们发现这种评估方法能有效快速地判断模型质量和成本，使我们能够迅速采用那些证明自身价值的最新模型。这种灵活性在如今新模型几乎每天都会出现的情况下显得尤为重要。

订阅博客获取最新文章

订阅我们的博客，即可将最新文章发送到您的邮箱。

注册

查看所有博客

slice-start id="_gatsby-scripts-1"

slice-end id="_gatsby-scripts-1"