批量解析文档的费用上来了，打开模型网关明细，却找不到那批请求。这不一定是采集漏了。Databricks的11月发布说明写明，自11月1日起，文档解析、字段抽取和分类等专用AI函数，在批处理和实时执行路径上的开支纳入Unity Gateway预算。与此同时，使用追踪文档明确，这类调用不写入网关请求明细表。看预算和查账，需要用两套数据。

快速看点：这是预算覆盖扩展，不是AI函数首次上线；批量和实时路径都在发布说明内；有预算记录不等于网关请求明细有逐条记录。

从模型端点，扩到在数据处理中调用的函数

企业不一定直接请求一个聊天模型。数据团队也会在查询或管道里调用专用函数，例如用文档解析把文件转为结构化内容，再从文本抽字段或给条目分类。对提交任务的人来说，这些步骤看起来是SQL的一部分；从成本角度看，除了提交查询所用的计算，部分函数的模型推理还可能在独立的托管基础设施运行并另行计费。

此次变更覆盖的是专用函数的预算计入范围，发布说明列出文档解析、抽取和分类作为例子，并同时点到批量和实时路径。它不是通用批量推理函数早先计入预算的同义改写，也没有宣布整个数据管道的存储、查询计算和第三方处理费用都并进网关预算。排查前最好先分清查询运行在哪、哪一部分属于函数本身。

同一段任务可以包含文件读取、解析、抽取和写入结果四步。若只看总执行时长，很难知道是哪一步增加了模型用量。试点可以先选一种文档、控制页数和样本量，记录每次触发的函数及是否重跑，再与用量记录核对。这样才能区分输入体积变化、任务重复提交和单位调用成本变化。

预算有数，网关明细为何仍然没有这一行

通常，团队能在网关的系统用量表里追查模型请求和请求标签。但官方使用追踪指南单独排除了这类专用函数：它们会计入Unity Gateway预算，却不写到网关请求明细。不能仅凭表中没有请求，就认定函数未执行或未计费；把这张表当作全部AI成本台账，也会漏掉这一路用量。

对账时可以把问题拆开：预算页用于看当前估算和阈值，计费用量查系统账单记录，工作流记录用于核对任务、执行身份和输入范围。三者的刷新节奏和统计单位不必相同。针对一次文档处理，记录查询或作业的执行时段，并核对对应费用和任务结果，比要求每个函数都有一条网关请求记录更符合现有边界。

标签也有两种用途。预算指南说明，预算对端点或Unity Catalog标签进行范围匹配，请求标签不参与该匹配；另一方面，请求标签可用于网关表里已经记录的请求分析。对这次新增的函数路径，不能假设只加一个请求标签就能把整批任务分到指定预算，或反过来用标签补出缺失的明细。

阈值可以管后续流量，但不等于最终账单上限

预算文档按SKU标价计算估算额，不纳入议价折扣或账单抵扣。已配置的阻止动作也依据近实时估算，可能在实际用量达到阈值前拦截，也可能允许短暂超出；已在运行的请求不会因为触到阈值被中断。预置吞吐量请求不在Unity Gateway预算覆盖范围内，外部模型则另有是否纳入的配置。

应用团队可以先用一个脱敏的小批次建立基线：分别记录数据处理成功数、模型步骤的实际用量和异常重跑。再观察预算告警、系统账单与作业日志何时出现对应变化。在共享工作区中，还应验证实际执行身份与预算归属，并限制单次批量输入；不要依赖账单告警去阻止一条已经发出去的大任务。

发布说明提示功能分阶段推出，租户生效时间可能晚于初始日期。本文没有创建预算、调用函数或验证特定租户的扣费与拦截，因此不把文档列出的覆盖范围说成每个账号现在都已启用，也不承诺达到某个金额就能即时停下任意数据任务。

小编判断

这次变化真正提醒团队的是：一个成本入口，不等于一份包办所有用途的日志。把预算覆盖、请求可见和账单对账分成三项验收。先证明典型批次能在账上解释，再设计阈值告警和人工处置；日后费用波动时，团队才知道该找模型网关、数据管道，还是实际计费明细。