给云计算设一个上限，就能保证这个月不超预算吗？Databricks在10月29日介绍的新一组Serverless成本控制，把访问权限、用量归因和计算速率拆开处理。对企业AI团队而言，这种拆分很重要：能限制谁启动任务、能看见钱花在哪里，以及能否真正阻止继续花钱，并不是同一个功能。

快速看点：访问控制已正式可用；标签和速率控制仍有测试阶段边界；速率限制主要约束自动化任务的Spark执行器；共享交互预算尚非本次已交付承诺。不能把这些功能合称为覆盖全部Serverless与AI产品的账单硬封顶。

先管谁能启动，再谈成本归属

访问控制引入Serverless计算对象，分别承接交互式笔记本、Databricks Connect，以及作业和声明式管线等自动化任务。用户能否使用对象，由相应权限决定；拥有管理权限的人还能修改授权。它给平台团队一个集中入口，但并不同时授予数据表、模型或下游系统的访问权。

默认设置也需要读清。系统提供默认交互与默认自动化对象，All Users初始具有使用权限，默认对象不能随意重命名或删除。因此，启用功能不等于所有人立即被拦住；管理员仍要检查现有授权和任务依赖，再调整范围，避免配置好的作业因缺权而无法运行。

更重要的限制写在当前AWS文档里：这套控制不覆盖所有Serverless产品，例如Databricks SQL、模型服务、批量ai_query与向量检索等并不都走同一入口。文档还说明，服务异常时可能采取放行策略，未获授权的工作负载仍有启动可能。它不能被当成绝对不可穿透的支出防线。

速率上限，限制的是哪一部分计算

速率限制面向自动化工作负载的Spark执行器自动伸缩，而非整份账单。Driver、REPL、GPU以及部分物化视图和流表刷新等不在这个限制范围内。部署团队应先按任务类型画出覆盖清单，否则容易给一个对象设了数字，就误以为所有相关AI调用都被限住。

限制按工作负载计算，不是多人共享一个总池。两个作业使用同一个计算对象，可以分别取得完整的速率额度；同一作业内的任务才共享该作业的额度。它适合控制单项任务的资源消耗速度，却不能直接替代部门月度总预算。

额度以估算的DBU每小时表达，不是固定集群大小，也不是美元硬上限，实际消耗可能波动并超过估计。当前指南还要求相应运行时达到17.3.1或以上，管线使用预览通道，并通过自定义对象配置；默认对象不能直接套用这项限速。

开放阶段存在需要保留的差异：公告将速率控制称为Beta，而当前AWS操作指南仍标注Private Preview，要求联系账户团队并启用预览。企业应以自己工作区实际可用权限为准，不能把介绍文章中的测试版字样理解为所有客户已经可自行开启。

看得见支出，不代表已经拦住支出

用量归因可以结合执行身份、计算对象及自定义标签分析。不过，账单系统表可能把一次工作负载拆成多行，需要正确汇总；run_as记录的是执行用户或服务主体，不必然等于发起业务请求的人。若多个应用共用服务账户，仍需建立业务归属映射，不能只按一个用户名追责。

预算告警同样不是实时保险丝。一般预算通知可能延迟最多二十四小时，预算统计按标价计算，不包含谈判折扣和抵扣等完整账单因素。把告警金额直接当作财务实际付款，或期待告警一到所有任务立即停止，都超出了这些工具的承诺。

公告提及的交互式共享预算仍是后续能力；其他产品如Unity Gateway拥有自己的预算安排，也不能把其阻断行为移植成笔记本已经具备的功能。成本治理需要分别回答：哪里能拒绝启动，哪里只能降低速率，哪里只是记录与提醒。

企业可以先选一个非关键作业做验收：核对权限是否生效、并发作业如何分别计额、限速后的完成时间，以及用量记录和实际账单怎样对账。本站本轮仅核对公告和文档，没有访问客户工作区、修改权限、执行查询或跑成本实验，因此不报告节省比例或投资回报。

小编判断

Serverless减少了管理机器的负担，却没有取消成本治理。此次更新的价值，是把权限、归因和速率变成可分别配置的部件；它的局限，也正是这些部件还不是一个全局硬预算。企业上线前先写清适用范围、放行条件和告警延迟，比给一个醒目的额度数字更有用。