如何跨多个 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 的产品、功能区域或内部平台。
• 环境：生产、暂存、开发、沙盒、演示或测试。
• 工作负载：聊天、摘要、提取、分类、代码生成、评估、嵌入、重新排名或批处理。
• 客户细分：企业、中端市场、免费试用、内部、合作伙伴或其他批准的细分。
• budget_owner：负责支出的个人、团队或成本中心。
• 提供商：用于请求的 AI API 提供商。
• 型号：确切的型号或部署标识符。
• request_class：交互式、后台、批处理、重试、回退、评估或管理。

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

实现细节

将维度表示为版本化合同。缺少所需生产标签的请求应在网关处失败关闭，或路由到明确命名的隔离存储桶中，并每天进行审核。

<前><代码>{ “schema_version”：“2025-01”， "team_id": "平台-ai", "product_id": "支持助理", “环境”：“生产”， "工作量": "总结", "customer_segment": "企业", "budget_owner": "成本中心-4812","request_class": "交互式" }

第 2 步：按团队和环境发布范围密钥

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

尽可能使用范围凭据：

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

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

安全说明

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

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

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

对于每个 LLM 调用，捕获：

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

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

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

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

第 4 步：维护两个成本表

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

估计每个请求的分类帐

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

有用的列包括：

• request_id
• provider_request_id
• 时间戳
• team_id
• 产品 ID
• 环境
• 工作负载
• 提供商
• 型号
• bilable_units
• rate_card_version
• 估计成本_美元
• latency_ms
• status_code
• 重试次数
• fallback_used
• 缓存状态

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

发票核对每日分类帐

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

有用的列包括：

• 账单日期
• 提供商
• 发票帐户
• 项目或工作空间
• team_id
• 产品 ID
• 环境
• 估计成本_美元
• 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. 每周检查缺失的元数据和未分配的支出。

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

明确决定的权衡

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

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

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

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

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

预测：成本账本将成为人工智能平台治理的一部分

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

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

可行的结论

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

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