为什么您的 LLM 使用仪表板与提供商发票不匹配

如果您的 LLM 使用信息中心、提供商控制台、云结算导出和客户发票显示不同的数字，请不要一开始就假设某个系统有问题。首先询问哪个号码对于哪个目的具有权威性。

网关仪表板通常是一个操作视图：快速、请求级且对于提醒很有用。提供商发票是一个已结算的计费视图：较慢、聚合并根据提供商计费规则进行调整。云结算导出添加了另一层，特别是对于托管模型服务，其中发票数据可以按项目、SKU、区域、使用类型或发票月份分组，而不是按 API 请求分组。

实际问题不仅仅是“找到实数”。它的目的是对不匹配的情况进行分类，保留足够的证据来解释它，并确定数字何时足以用于仪表板、财务报告或客户账单。

使用两个分类帐，而不是一个数字

最常见的错误是试图使实时网关估算表现得像最终发票一样。这些是不同作业的不同记录。

运营使用分类账

操作分类帐由您的网关、SDK包装器、代理或应用程序检测在请求时填充。它应该针对速度和归因进行优化。它回答了以下问题：

• 哪个租户、团队、API密钥、项目或工作流程创建了此请求？
• 调用了哪个模型？
• 观察或估计了多少输入、输出、缓存或推理标记？
• 请求是否已重试、取消、流式传输、批量处理或失败？
• 应立即收取哪些内部预算或限额？

此分类帐对于法学硕士成本管理至关重要，但它并不总是准确的发票。在提供商返回最终使用情况之前，它可能会使用估计的令牌。它可能会应用陈旧的价格表。它可能会对提供商不计费的尝试请求进行计数，或者错过提供商计费的重试。

已结算成本分类账

在提供商对费用进行汇总和分类后，结算成本分类帐由提供商成本 API、提供商使用报告或云计费导出填充。它应该针对财务报告进行优化。它回答了以下问题：

• 提供商报告的当天费用是多少、模型、项目、关键、订单项或使用类型？
• 适用哪种币种和发票期限？
• 是否有后期更正、功劳或调整？
• 哪些费用可以放心地分配给租户？
• 哪些成本由于元数据缺失而无法归属？

建议：使用运营账本进行提醒、预算预留、调试和近乎实时的信息中心。使用已结算成本分类账进行财务结算、客户发票、利润分析和最终退款。将任何预结算数字标记为估计数字或临时数字。

调试前对不匹配进行分类

大多数法学硕士账单差异分为五类。首先对差距进行分类，可以防止团队在真正的问题是发票时间时追踪标记化详细信息，或者在真正的问题是缺少租户元数据时追踪云发票导出。

1.时间窗口漂移

当两个系统将相同的使用情况分组到不同的时间段时，就会发生这种情况。

常见原因包括 UTC 日期与本地日期、提供商结算日与信息中心日不匹配、批处理作业完成日期与提交日期不同、跨越日期边界的流请求以及云发票月份字段与使用时间戳不同。云结算导出还可能包括稍后发票期间的更正或后期货币化使用情况。

调试步骤：

1. 在比较之前将每个时间戳转换为 UTC。
2. 分别比较使用日期、请求开始时间、请求结束时间、提供商处理时间、批次完成时间和发票月份。
3. 首先协调关闭期间。避免根据仍在解决的提供商报告来诊断今天的信息中心。
4. 对于批量工作负载，请比较请求提交日期和批量完成日期。

建议：定义一个报告日历，将“使用日”、“结算日”和“发票月份”分开。不要将这些字段折叠到一个日期列中。

2.尺寸漂移

当信息中心和发票对不同的内容进行分组时，就会发生这种情况。

您的网关可能按租户、团队、API 密钥、环境或工作流程进行分组。提供商成本 API 可以按项目、用户、API 键、模型、订单项或来源进行分组，具体取决于提供商和端点。云账单导出可以按项目、SKU、服务、位置、使用类型、标签或发票月份进行分组。对于托管模型服务，发票导出中可能根本不存在每个请求的提示归因。

调试步骤：

1. 记下每个系统使用的确切分组维度。
2. 在比较总数之前，对模型 ID、区域、服务层级、令牌类型、订单项和 API 来源进行标准化。
3. 检查提供商项目、工作区、API 键和云项目标签是否完全映射到您的内部租户。
4. 明确识别未归属的支出，而不是将其强制放入租户存储桶中。

建议：将租户归因视为一流的结算字段，而不是信息中心过滤器。为了实现可靠的LLM API成本归因，请在请求时捕获租户标识符，并保留稍后加入所需的提供商端标识符。

3.定价漂移

当运营估算使用的定价逻辑与提供商的结算账单不同时，就会发生这种情况。

常见原因包括缓存令牌定价、缓存写入与缓存命中费用、单独的输入和输出令牌率、迁移到更新定价模型的模型别名、服务层级、推理地理、批量折扣、文件搜索或网络搜索订单项、图像或音频单位以及货币换算。一旦提供商帐单包含多种令牌类型或订单项，将总令牌乘以一个混合价格的信息中心就会发生变化。

调试步骤：

1. 在比较总计之前将费用分解为订单项。
2. 在提供商报告的地方分离输入令牌、输出令牌、缓存写入、缓存命中、推理令牌和非令牌单元。
3. 对内部价格表进行版本控制并存储用于每个估算的价格版本。
4. 检查提供商报告的模型别名、模型快照或产品系列项目是否与您的网关不同。
5. 在应用您自己的货币换算之前，先比较提供商的结算货币。

事实：提供商报告界面可以公开分桶成本和分组维度，例如项目、用户、API 键、模型、订单项、工作区、令牌类型、地理位置、服务层级或货币，具体取决于提供商和环境。云导出可能会公开标签、资源字段、使用时间戳、发票月份、积分和更正。

4.请求生命周期漂移

当系统对于一项计费操作的计算方式存在分歧时，就会发生这种情况。

重试通常是罪魁祸首。如果应用程序在超时后重试，您的产品仪表板可能会将最终成功的答案视为一次用户操作，而提供商会对两到三个模型调用进行计费。当一个失败的主调用和一个成功的回退调用显示为一个应用程序结果时，回退路由可能会产生相同的问题。

流媒体增加了另一个漂移来源。用户可以在接收到部分输出后取消流。提供商可能会报告生成的令牌直至取消，而您的应用程序仅记录失败或放弃的请求。批处理作业创建不同的生命周期：提交、验证、处理、部分失败、结果检索和结算可能不共享相同的时间戳。

调试步骤：

1. 为用户操作分配稳定的内部请求 ID。
2. 为每个提供商调用、重试和回退分配单独的尝试 ID。
3. 存储提供商响应 ID 和请求 ID（如果可用）。
4. 记录流状态：已完成、客户端取消、服务器终止、超时或网络丢失。
5. 对于批处理作业，存储批处理作业 ID、输入文件 ID（如果适用）、提交时间、完成时间和每个项目的状态（如果有）。

建议：将提供商账单与提供商尝试进行比较，而不是与产品级用户操作进行比较。然后将尝试汇总到用户操作以进行产品分析。

5.提供商结算漂移

当您的信息中心显示数字后提供商方结算数据发生变化时，就会发生这种情况。

提供商成本 API 和云结算导出更接近结算事实，但它们可能会延迟、存储或稍后调整。信用、更正、迟到使用、发票月份更改和产品重新分类都可能改变最终数字。当财务人员将当月第一天的仪表板屏幕截图与稍后生成的发票导出进行比较时，这一点尤其重要。

调试步骤：

1. 跟踪获取每个提供商成本桶的时间。
2. 存储已结算成本导入的不可变快照。
3. 检测相同提供商、期间和分组维度的导入之间的变化。
4. 将后期调整保留为调整行，而不是默默地重写历史记录。
5. 定义关闭流程：例如，保留一个临时期间，直到提供商数据稳定且差异检查通过为止。

建议：客户发票应使用固定期限或带有明确的临时标签。仪表板可以容忍开放期间的微小变化；客户结算不应隐藏不确定性。

最低证据架构

调节过程的有效性取决于在不匹配出现之前保留的证据。至少，捕获元数据可让您在运营记录和提供商计费记录之间切换，而无需存储敏感的提示内容。

推荐的请求级字段：

• 内部标识符： internal_request_id、attempt_id、parent_request_id、tenant_id、team_id、project_id、环境、workflow_id.
• 访问标识符： gateway_api_key_id、provider_api_key_id（如果可用）、服务帐户、user_id（如果适用）。
• 提供商标识符：提供商、provider_project_id、provider_workspace_id、provider_response_id、provider_request_id、cloud_account_id、cloud_project_id.
• 模型和路由： requested_model、resolved_model、model_version、route_policy、fallback_from、fallback_to.
• 用法： input_tokens、output_tokens、cached_input_tokens、cache_write_tokens、reasoning_tokens、token_unit、non_token_quantity、quantity_unit.
• 估算价格： estimated_cost、货币、price_table_version、estimate_source、budget_reservation_id.
• 生命周期：状态、error_class、retry_number、stream_started、stream_completed、stream_termination_status、batch_job_id、batch_item_id.
• 时间： request_started_at、request_completed_at、provider_reported_at、batch_submitted_at、batch_completed_at、usage_date_utc.

不要仅仅为了核对帐单而存储原始提示或响应。请求元数据、令牌计数、提供者 ID 和标准化维度通常就足够了。如果调用日志可能包含敏感内容，请编辑或禁用提示和响应负载捕获，同时保留使用情况和身份字段。

以最低可靠共享粒度进行比较

请求级协调听起来很有吸引力，但并不总是可行。正确的比较粒度取决于提供程序公开的内容。

提供商费用 API

如果提供商成本端点公开每日存储桶和分组维度，例如项目、用户、API 键、模型、订单项、工作区或令牌类型，请从此处开始。使用相同维度将每日结算成本桶与网关的每日汇总进行比较。除非租户覆盖范围完整，否则请勿将租户级信息中心与提供商组织总数进行直接比较。

比较粒度示例：

• date_utc
• 提供商
• provider_project_id 或workspace_id
• api_key_id（如果有）
• 型号或resolved_model
• line_item 或 token_type
• 货币

云计费模型服务

对于云计费服务，发票导出可能不包含每个请求的标识符。在这种情况下，请以更粗粒度（例如日期、模型、区域和使用类型）将调用日志加入到成本和使用情况导出中。使用请求级日志进行租户分配，但使用云结算导出来获取发票总计。

比较粒度示例：

• usage_date_utc
• cloud_account_id或billing_account_id
• cloud_project_id
• 地区
• model_id
• usage_type 或 SKU
• invoice_month

事实：AWS Bedrock 文档介绍了如何使用成本和使用情况报告字段，例如使用类型数据中的模型、令牌类型、服务层和跨区域推理，同时使用模型调用日志来获取请求身份、令牌计数、模型 ID、区域和请求 ID。文档建议在模型、使用类型和日粒度上将调用日志与 CUR 结合起来，以获得发票准确的总计。

实用的调节工作流程

当财务部门报告发票不匹配时，请使用此工作流程。

第 1 步：冻结比较

选择一个提供商、一个结算周期、一种货币和一种比较粒度。同时导出仪表板编号、提供商成本报告和云计费导出。记录导出时间戳。许多团队浪费大量时间来比较移动目标。

第 2 步：分开估算金额和结算金额

将行拆分为estimated_cost 和settled_cost。估计成本来自您的网关价格表。结算成本来自提供商或云计费数据。切勿用一个覆盖另一个；存储两者并跟踪方差。

第 3 步：标准化维度

为提供商、模型、解析模型、订单项、令牌类型、服务层、区域、项目、工作区、API 键和租户创建映射表。包括“未知”或“未归属”的存储桶。强制分配比显式间隙更糟糕，因为它隐藏了操作修复。

第 4 步：自上而下核对总计

从提供商组织总额与提供商发票总额开始。然后按天比较。然后按型号和行项目进行比较。只有在这些通过之后，您才可以比较租户或API-密钥分配。此顺序可以告诉您问题是全局定价、时间窗口漂移还是归因。

第 5 步：按类别调查差异

使用这五个类别作为清单：

• 时间窗口漂移： UTC 不匹配、本地日期分组、批次完成日期、发票月份、延迟使用。
• 维度漂移：项目/工作空间不匹配、缺少 API 键、未映射模型、缺少租户标签。
• 定价漂移：缓存令牌、服务层级、区域、批量定价、非令牌订单项、过时的价格表。
• 请求生命周期偏差：重试、回退、流式传输取消、部分批次失败、超时。
• 提供商结算漂移：积分、更正、延迟存储桶、更改的成本导出。

第 6 步：应用方差阈值

不同的用例需要不同的容差。如果工程仪表板明确标记为待处理，则可以容忍开放期间的小差异。预算执行系统可能需要保守估计以防止超支。客户发票应使用已结算的费用或记录的分配政策。

建议：按用例而不是提供商定义阈值。例如：

• 操作仪表板：允许小的开放期间差异并显示待处理状态。
• 预算提醒：使用保守估算并稍后进行调节。
• 内部退款：需要结算的提供商存储桶以及归因覆盖范围检查。
• 客户发票：要求关闭期间、已结算成本导入、差异低于阈值，并且没有重大未归属支出。

实现模式：调节表

简单的架构通常就足够了。您需要单独的表来存储操作尝试、提供商成本范围、标准化汇总和差异结果。

operational_attempts
- attempt_id
- internal_request_id
- tenant_id
- provider
- provider_project_id
- provider_workspace_id
- provider_api_key_id
- model_requested
- model_resolved
- region
- input_tokens
- output_tokens
- cached_input_tokens
- cache_write_tokens
- status
- retry_number
- stream_termination_status
- batch_job_id
- estimated_cost
- currency
- price_table_version
- usage_date_utc

provider_cost_buckets
- provider
- bucket_date_utc
- provider_project_id
- provider_workspace_id
- provider_api_key_id
- model
- line_item
- token_type
- service_tier
- region
- quantity
- quantity_unit
- settled_cost
- currency
- invoice_month
- imported_at

reconciliation_results
- period_start
- period_end
- grain_key
- estimated_cost
- settled_cost
- absolute_variance
- percent_variance
- variance_class
- status
- notes
- checked_at

重要的设计选择是保留估算成本和结算成本。提供商数据到达后，您可以计算方差，而无需破坏当时解释提醒和预算决策的原始运营记录。

首次协调后的常见修复

第一次核对通常会揭示运营差距。修复方法很简单，但需要跨平台和财务的所有权。

• 缺少租户元数据： 在网关边界需要 tenant_id、team_id 或 customer_id。拒绝或隔离没有归属元数据的制作请求。
• 过时价格表：版本价格、跟踪生效日期并在提供商模型目录或定价页面发生更改时发出警报。
• 重试计数过多或计数不足：将产品请求 ID 与提供商尝试 ID 分开。
• 流式传输取消间隙：在提供程序返回时记录部分使用情况，甚至在客户端断开连接时也记录终止状态。
• 批次模糊性：存储作业 ID 并按完成日期和提交日期进行比较。
• 云发票不匹配：按日期、型号、区域和使用类型粒度将调用日志加入到结算导出中，而不是预期每个请求的发票行。
• 无法解释的延迟变动：快照提供程序成本导入并记录延迟贷项或更正的调整行。

事实、建议和预测

事实：提供商和云计费系统公开不同的计费维度和详细程度。一些提供商 API 公开每日成本桶和分组维度，例如项目、用户、API 键、模型、订单项、工作区、令牌类型、服务层、地理位置和货币，具体取决于端点和环境。云计费导出通常包括项目或资源标签、时间戳、发票月份、积分、更正、SKU、位置和使用类型。云计费模型服务可能需要调用日志来进行请求级归因。

建议：保留运营使用分类账和结算成本分类账。比较最低可靠的共享粒度。保留请求级证据而不存储敏感负载。在比较之前标准化尺寸。使用已结算的提供商或云账单数据作为发票。将未归属支出视为数据质量问题，而不是通过混合分配来隐藏。

预测：随着团队使用更多缓存提示、批处理作业、服务层、后备路由和云托管模型服务，LLM 结算对账将变得更加重要。提供商结算 API 可能会得到改进，但不会消除对内部租户元数据的需求，因为提供商无法推断您的客户、团队或工作流程层次结构。

结论

当 LLM 信息中心与提供商发票不匹配时，答案很少是一个错误。这通常是运营估算、提供商结算的成本、云计费维度和内部归因规则之间的不匹配。

持久的修复方法是对账手册：将运营账本和结算账本分开，将差异分类为时间窗口、维度、定价、生命周期或结算漂移，保留请求级证据，并仅在差异检查后从结算期间开具发票。这使工程团队能够快速控制，而无需要求财务人员将临时数字视为最终金额。

相关阅读

• 每个团队 LLM 成本分类账的每日对账