如何跨多个 AI API 构建每个团队的 LLM 成本分类账

提供商信息中心可以告诉您组织的支出情况。他们很少回答财务和平台团队实际需要回答的问题：哪个团队、产品、环境、工作负载或客户群体导致了支出，以及该支出是否符合预期。

持久模式不是另一个仪表板。它是一个内部成本分类账：一个记录系统，结合了应用程序端请求元数据、范围内的 API 键、提供商使用数据和发票级计费总计。该账本为工程团队提供了近乎实时的运营可见性，同时为财务部门提供了可支持预算、分配和退款的协调视图。

本文为使用多个 AI API 的团队提出了一种实用架构，包括标记合约、请求流、表格、协调流程、控制和权衡。

问题：提供商计费准确但并不总是可分配

大多数 AI 提供商都会公开使用情况信息中心、使用情况 API、结算导出、项目、工作区、服务帐户或费用 API 的某种组合。这些工具很有用，但它们的操作细节并不相同。

事实

• 某些提供商成本端点专为财务报告而设计，可能会按发票行项目、项目或结算周期细分支出。
• 使用 API 通常会提供操作详细信息，但由于折扣、积分、延迟结算、承诺定价、批量费率、缓存定价或发票调整，使用记录和最终费用记录可能无法完美一致。
• 项目、工作区、服务帐户、API 密钥或 IAM 主体等本机管理边界可以帮助属性支出，但具体功能因提供商而异。
• 对于某些平台，每个请求的元数据显示在调用日志中，而不是成本分配报告中。团队必须汇总日志并应用定价来估算请求级成本。

建议

将提供商数据视为输入，而不是整个系统。构建一个可以回答运营和财务问题的内部分类账，然后每天根据提供商成本来源进行核对。

账本架构

成本分类账有五个主要组成部分：

1. 稳定的成本维度架构。
2. 限定范围的凭据和路由规则。
3. 请求级元数据捕获。
4. 提供商使用情况和成本摄取。
5. 每日调节和政策执行。

目标是生成两个相关视图：针对运营的按请求估算的分类账和针对财务的每日核对分类账。

这是更广泛的AI API成本控制中的常见构建块，因为它将工程遥测与财务责任联系起来，而不依赖于单个提供商的报告模型。

第 1 步：在构建信息中心之前定义成本维度

从财务、工程、产品和安全团队一致使用的维度开始。在选择图表或编写提取作业之前执行此操作。

实用的架构通常包括：

• team_id:所属工程或业务团队。
• product_id:使用API.
的产品、功能区域或内部平台
• 环境：生产、暂存、开发、沙箱、演示或测试。
• 工作负载：聊天、摘要、提取、分类、代码生成、评估、嵌入、重新排名或批处理。
• customer_segment：企业、中端市场、免费试用、内部、合作伙伴或其他批准的细分市场。
• budget_owner：负责支出的人员、团队或成本中心。
• provider：用于请求的 AI API 提供商。
• 型号：确切的型号或部署标识符。
• request_class:交互式、后台、批处理、重试、后备、评估或管理。

保持架构足够小，以便工程师能够实际填充它。添加治理以防止自由文本漂移。例如，team_id 应来自内部团队注册表，而不是来自任意请求标头。

实施详细信息

将维度表示为版本化合同。缺少所需生产标签的请求将无法在网关处关闭，或者被路由到每日审核的明确命名的隔离存储桶中。

{
  "schema_version": "2025-01",
  "team_id": "platform-ai",
  "product_id": "support-assistant",
  "environment": "production",
  "workload": "summarization",
  "customer_segment": "enterprise",
  "budget_owner": "cost-center-4812",
  "request_class": "interactive"
}

第 2 步：按团队和环境颁发作用域密钥

共享整体API密钥使成本分配变得脆弱。如果每项服务都使用相同的凭据，财务部门就无法自信地归因支出，平台团队也无法在不影响不相关系统的情况下禁用一项工作负载。

尽可能使用限定范围的凭据：

• 每个团队和环境一个密钥或服务帐户。
• 生产和非生产工作负载的单独凭据。
• 用于高风险实验、评估和批处理作业的单独凭据。
• 提供商原生项目或工作区明确映射到内部所有权。

这并不意味着每个微服务都需要唯一的提供商帐户。太多的边界会产生运营开销。有用的单位是所有权、预算和运营响应不同的边界。

安全说明

API 密钥和安全令牌不应在网址中发送，因为网址通常会在日志、代理、分析工具和浏览器历史记录中捕获。将凭据放入标头或托管秘密存储中，通过自动化流程轮换它们，并记录事件响应的关键生命周期事件。

第 3 步：在网关或应用层捕获请求元数据

账本需要的不仅仅是代币数量。它需要足够的背景来解释支出发生的原因以及它是否有用。

对于每次 LLM 通话，捕获：

• 内部请求 ID 和分布式跟踪 ID。
• 返回时的提供商请求 ID。
• 提供商、模型、区域和端点。
• 团队、产品、环境、工作负载、客户群和预算负责人。
• 输入令牌、输出令牌、缓存令牌、推理令牌、嵌入单元、图像单元或其他可用的计费单元。
• 延迟、重试次数、回退路径、超时状态和错误代码。
• 缓存命中或未命中。
• 请求类别：生产、评估、重试、批量或实验。

中央网关使这一过程变得更加容易，因为每个提供商调用都会经过一个执行点。如果中央网关不可行，请使用共享客户端库并要求服务发出相同的事件格式。

默认情况下不要记录所有内容

提示和输出内容有助于调试和审核，但也会产生隐私、保留和访问控制义务。对于许多团队来说，默认值应该是元数据、令牌计数、模型标识符和跟踪 ID。仅在具有保留限制和访问控制的明确政策下存储提示和输出内容。

第 4 步：维护两个费用表

试图让一张桌子满足所有用途通常会造成混乱。使用不同的作业构建两个分类帐。

估计每个请求的分类帐

该表支持近乎实时的操作。它是精细的、快速的、近似的。

有用的列包括：

• request_id
• provider_request_id
• timestamp
• team_id
• product_id
• environment
• workload
• provider
• model
• billable_units
• rate_card_version
• estimated_cost_usd
• latency_ms
• status_code
• retry_count
• fallback_used
• cache_status

估算费用应根据最佳可用计费单位数据和版本化内部价目表来计算。在每行保留价目表版本，以便稍后解释历史估算。

发票对帐每日分类账

此表支持财务报告。它的粒度更小，速度更慢，并且更接近最终的结算现实。

有用的列包括：

• billing_date
• provider
• invoice_account
• project_or_workspace
• team_id
• product_id
• environment
• estimated_cost_usd
• provider_reported_cost_usd
• allocated_adjustment_usd
• reconciled_cost_usd
• variance_reason

调节表应保留差异而不是隐藏差异。如果提供商报告的成本因积分而较低，或因预置吞吐量而较高，请明确记录该差异。

第 5 步：每日核对，而不是在月底手动核对

每日对账可减少意外情况。该过程一开始可能很简单：

1. 连续提取请求级账本事件。
2. 按计划提取提供商使用情况和费用记录。
3. 按提供商、项目或工作区、模型、日期和已知分配维度对内部估算进行分组。
4. 将内部估算值与提供商报告的总费用进行比较。
5. 使用记录的政策分配差异。
6. 写出差异原因和调节状态。

常见差异类别包括协商折扣、提供商积分、延迟使用记录、缓存令牌定价、批量定价、预配置吞吐量、货币换算、最低费用和缺失元数据。

调节政策示例

如果提供商项目恰好对应一个团队和环境，请将提供商报告的完整每日费用分配给该团队，并将内部估算记录为支持详细信息。如果提供商项目包含多个团队，请根据内部估计成本按比例分配提供商报告的总额，然后在每个团队行中记录调整。

这项政策并不完美，但可以解释。可解释性比错误的精确性更重要。

第 6 步：将预算和控制附加到分类账维度

支出归因后，控件就变得更加有用。对于大多数团队来说，单一组织范围的限制过于生硬。

针对不同的工作负载使用不同的控件：

• 沙盒：每日或每周严格限制、自动关闭、批准门槛低。
• 开发：软警报加上适度的硬上限。
• 评估：批处理窗口、明确的预算所有者、到期日期。
• 生产：软警报、升级工作流程、紧急限制增加路径。
• 面向合作伙伴或客户的API用法：客户级分配、配额执行和滥用监控。

硬限制可以防止账单失控，但可能会中断生产工作流程。在生产中小心使用它们，并将它们与升级规则配对。对于非生产工作负载，硬限制通常更容易证明合理。

第 7 步：检测总支出之外的异常情况

每日总支出是一个滞后信号。更好的警报使用分类账的操作字段。

有用的异常检查包括：

• 按工作负载计算的每个成功请求的费用。
• 与历史基线相比的产出代币比率。
• 按提供商、模型和服务划分的重试率。
• 从更便宜的型号到更昂贵的型号的回退频率。
• 在当前小时内花费速度。
• 预期受益于缓存的工作负载的缓存命中率下降。
• 工作时间以外的非生产支出。
• 请求缺少必需的费用维度。

表示支出较高的提醒不如表示一项服务的生产汇总请求在部署后生成的输出令牌数量是正常输出令牌的三倍的提醒有用。

建议的实施顺序

不要尝试在一个版本中构建完整的架构。实用的顺序是：

1. 定义成本维度架构和所有权注册表。
2. 针对支出最高的工作负载按团队和环境拆分提供商凭据。
3. 添加网关或客户端库元数据捕获。
4. 创建估计的每个请求分类帐。
5. 为正在使用的提供商和模型添加版本化的价目表。
6. 将提供商成本数据提取到每日报告表中。
7. 实施每日调节和差异跟踪。
8. 添加预算政策、提醒和审批工作流程。
9. 每周检查缺失的元数据和未分配的支出。

第一个有用的里程碑并不是完美的退款。它能够在一个工作日内回答哪个团队和工作负载导致了材料支出变化。

明确决定的权衡

提供商信息中心与内部分类帐：提供商信息中心的采用速度更快，但它们很少与跨团队、产品、环境和客户的内部成本维度相匹配。

粒度与运营开销：更多的键、项目、工作区和标签可以改善归因，但也会增加治理工作。使用与实际所有权相匹配的边界。

估算费用与发票费用：请求级估算对于运营来说是及时且有用的，但它们不会自动反映积分、协商定价或结算调整。

中央网关与分布式检测：网关可以跨提供商提供一致的执行，但它成为关键的基础设施。共享客户端库在某些环境中更容易采用，但执行起来却比较困难。

可审核性与隐私权：内容日志记录有助于调查，但仅元数据日志记录通常是更安全的默认设置。

预测：成本账本将成为 AI 平台治理的一部分

可能的方向是提供商原生报告将会得到改善，但跨提供商分配仍然需要内部背景。提供商无法了解每个公司的团队结构、产品分类、客户细分、审批工作流程或退款政策。

随着人工智能的使用从试点项目扩展到生产工作流程，成本分类账将与访问控制、密钥轮换、审核日志记录、速率限制和使用分析一起成为正常平台治理的一部分。尽早定义成本分类的团队稍后可以更轻松地添加预算、客户级分配和自动化控制。

可行的结论

围绕责任而非图表构建分类账。从稳定的维度、范围凭证和请求元数据开始。维护工程运营的每个请求的快速估算以及财务的每日协调账簿。协调而不是强迫估算看起来准确，并保留差异，以便折扣、承诺、积分和结算延迟保持可见。

有用的第一个版本可能会很窄：一个提供商、前三个工作负载、按团队和环境划分的范围键、元数据捕获、估算成本以及与提供商报告的总数的每日比较。一旦生效，即可在各个提供商之间扩展相同的合同，并将预算政策附加到重要的维度。