Databricks如何在模型发布第一天就让 14000 名员工用上新模型
Databricks公开其内部模型发布流程：新模型当天对全员开放但标记为实验性，用按用户预算限制用量，三天内根据内部基准、用户反馈和成本追踪决定是否转正。
AI解读：Databricks的做法是把“试用新模型”当成一项有预算、有标记、有退出机制的内部流程，而不是发一封全员邮件让大家自己折腾。新模型发布当天就推给所有员工，但走的是实验性预算和实验性标签，用量受个人月度上限和单日熔断额度约束。
它解决的是两个具体问题：一是被宣传为前沿的模型未必真的更好，文中举例Opus 5.0比Opus 4.8更贵、在工程师的质量评分上排名更低；二是让一万多人随意用新模型可能让成本失控，GPT Astra在无成本缓解措施的对照组里让开发者平均多花 60%。
对 14000 人规模的公司来说，这套流程的价值在于三天内就能拿到结论。2025 年 9 月 21 日那一周Opus 5、GPT-6 Sol和GPT-Luna密集发布，Databricks全员当天可用，第三天就确认这些模型处在效率前沿，把它们从实验预算转入常规可用。
具体判断依据有三类：内部私有基准（包括OfficeQA Pro V2和并用两个模型对比PR创建的在线基准）、用户在Slack和问卷里的反馈，以及Unity Gateway通过OpenTelemetry记录的按会话成本。成本比较前先按单轮/多轮、是否改文件分层再加权，避免把‘新模型试更难的任务’误读成涨价。
结果是：Claude Code将把Opus 5.5设为默认模型，因为它在质量和成本上都优于前代；GPT-6 Sol不会取代GPT-5.6 Sol成为Codex默认，但会进入智能路由工具箱，因为它更便宜。对普通用户来说，这更像是一份大公司管AI账单的样本，不需要立刻行动。
Databricks在官方博客中说明，它如何在模型发布的当天就让超过 14000 名员工用上新模型，并在三天内决定这些模型是否值得长期留在生产环境中。
博客称，让一万多人快速访问新模型并不简单，原因有两个。第一，被宣传为前沿的模型未必真的在前沿：文中举例说Opus 5.0比Opus 4.8更贵，同时在工程师的定量和定性质量评分上排名更低，迁移到这种‘退步’的模型可能实质伤害公司。第二，朴素地使用新模型会让成本爆炸：在无成本缓解措施的对照组中放开GPT Astra后，开发者的平均花费比之前高出 60%，对一万多人的用户群来说，一夜之间成本上涨 60% 很难做规划。
Databricks称自己依赖Unity Gateway来适配性地发布、评估和纳入新模型。2025 年 9 月 21 日那一周是这套能力的压力测试：Opus 5、GPT-6 Sol和GPT-Luna密集发布，Databricks给全员提供了第一天访问权限，到第三天就收集到足够数据确认这些模型处在效率前沿，随后将其纳入更广泛的基础设施。
发布流程：先全员实验，再限预算，最后决定转正或下架
Databricks把新模型发布分成三步：立即以‘实验性’名义向所有员工开放；用按用户预算约束新模型的使用；收集到足够数据后，决定是否把模型提升为生产模型甚至设为默认。
第一步依赖Databricks自己的Unity Gateway。博客称这是内部AI治理、成本管理和可观测性的中枢，新模型在这里对全员启用。仅有服务端配置还不够，员工在笔记本上使用Claude Code、Codex和Omnigent元框架，因此需要通过已经由移动设备管理部署在所有人笔记本上的Unity Gateway CLI（UG CLI）下发配置。每次有人启动Claude Code、Codex或Omnigent，UG CLI会检查新模型、工具和技能，并更新本地框架配置。UG还可以集中指定默认模型与实验模型、为智能路由准备模型，以及收集用于评估每次模型发布的追踪数据。
Databricks将Unity Gateway配置为推送Opus 5.5和Sol 6的实验性配置。这两个模型会带着实验标签出现，员工可以选用，同时也明白这是新模型，未必是最好的，也未必会长期保留。
四类按用户预算，实验模型不占日常额度
Databricks扩充了总体预算架构，包含四个按用户定义的预算。月度上限是每个用户在所有模型上的月度总花费上限；单日熔断额度是每个用户的每日上限，可以直接在Slack中提高，以避免失控会话带来的意外支出。
新增的‘质量前沿预算’把月度预算的一部分分配给位于质量前沿的最贵模型，例如GPT Astra和Claude Fable。博客说明，Fable目前没有在内部推出，原因与Anthropic的数据保留政策有关，双方正在合作落实新政策。这类预算反映的意图是：这些模型不应作为日常主力，而是用于它们真正擅长的专门任务，以证明比下一档质量层贵 2 到 3 倍是合理的。
新增的‘实验预算’把另一部分月度预算用于新的、未经测试的模型，目标是在采纳速度与广泛暴露一个不在效率前沿的模型的下行风险之间取得平衡。模型发布第一天，Opus 5.5和Sol 6通过Unity Gateway对所有员工开放，并被标记为使用实验预算；接下来几天收集数据，再决定是去掉实验标签，还是从开发者看到的模型目录中移除。
三天内的判断依据：私有基准、用户反馈和按会话成本
Databricks依靠三类信号判断模型是否处在效率前沿。基准数据方面，它有一组私有基准测试一系列任务，包括文档推理、工作区搜索和自家Genie产品等离线基准，以及并排运行两个模型比较拉取请求创建输出的在线基准。用户反馈方面，实验性发布提供了大量关于人们如何看待新模型的轶事数据，一群高级用户热衷于试用新模型并在Slack和问卷中比较体验。成本追踪方面，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偶尔是质量降级。
成本追踪让Databricks能把早期采用者的使用情况与同一群体一周前的使用情况做比较。博客强调保持同一批人至关重要，因为早期采用者更可能是AI重度用户而非普通用户。为了让成本可比，Databricks想把成本归一到每会话美元，但发现直接比较每会话仍然有误导性，因为会话分布也在变化：早期采用者用新模型尝试了更难的问题。因此它按会话是单轮还是多轮、是否发生文件编辑进行分层，再按此重新加权分布。结果表明，Opus 4.8到Opus 5.5的每会话平均成本从 5.94 美元降到 4.23 美元，下降 29%；GPT-5.6 Sol到GPT-6 Sol从 4.52 美元降到 2.34 美元，下降 48%。博客称GPT数字不意外，因为价格下调了 50%，但Opus 5.5也为真实工作负载带来了显著降价，这令人满意。
决定：Opus 5.5做Claude Code默认，GPT-6 Sol进智能路由
Databricks的结论是，它能在模型发布第一天给员工Opus 5、GPT-6 Sol和Luna的实验性访问权限，并在三天内收集到足够数据确认这些模型处在效率前沿，决定把它们移出实验预算，作为一般可用模型进入标准流通。
接下来一周，Databricks将对Opus 5.5更进一步，把它设为Claude Code的默认模型，因为它在质量和成本上都明显优于前代。对GPT-6 Sol的经验表明，它不会取代GPT-5.6 Sol成为Codex的默认模型；但鉴于它相对 5.6 Sol有成本优势，会把它纳入智能路由工具箱。博客称，总体而言这套打法能有效快速评估模型的质量和成本，让他们迅速采纳被证明有价值的最新模型，而新模型几乎每天都在出现，这种灵活性比以往更重要。