Cost, Billing, and Ops2026年7月10日Flatkey Team

按客户进行 AI 使用量计量：为嵌入式 AI 功能构建计费证据

一份实用的成本运营指南，教您如何将嵌入式 AI 使用量转化为客户级计费证据，涵盖从元数据到争议处理的全过程。

按客户进行 AI 使用量计量是为嵌入式 AI 功能实现公平计费的操作系统。如果您的产品内部运行着支持助手、文档分析器、图像生成器或工作流代理，模型账单并不会告诉您是哪个客户产生了哪笔支出，是哪个功能创造了需求，或者某个有争议的账单项目是否应该被记入贷方。

这种差距会迅速变得代价高昂。提供商的仪表板可以按项目、API 密钥、用户、模型、账单项目或日期显示使用情况。网关可以保留元数据、日志、令牌计数、状态和成本。计费系统可以接收带有客户 ID、数值、时间戳和幂等性密钥的使用事件。但在您的应用程序为每个 AI 请求标记正确的客户上下文，并在账单关闭前完成对账链条之前，这些信息都无法成为计费证据。

Flatkey 在此工作流中至关重要，因为其公共网站将 flatkey.ai 定位为适用于 GPT、Claude、Gemini、DeepSeek、图像、音频和视频模型的单一 API 密钥，并提供跨提供商的定价、使用分析、成本控制和统一账单。请将其视为统一的访问和审查界面，但不要将其视为您自己客户归因合同的替代品。在进行生产计费之前，请在您当前的 Flatkey 账户中核实确切的仪表板字段、请求日志、导出行为、模型目录、定价单位和保留设置。

按客户进行 AI 使用量计量：简而言之

对于每个嵌入式 AI 功能，按客户进行 AI 使用量计量应回答四个问题：

| 问题 | 证据字段 | 为何重要 | |---|---|---| | 哪个客户发起了请求？ | customer_meter_id 或哈希租户 ID | 支持计费、信用额度和客户级限制 | | 哪个功能产生了使用量？ | feature_id、路由、工作流或 SKU | 区分聊天、搜索、摘要、代理和后台作业 | | AI 调用消耗了什么？ | 模型、输入令牌、输出令牌、请求计数、缓存令牌、媒体单位 | 将使用量转换为提供商和账单单位 | | 财务部门能否为这笔费用辩护？ | 请求 ID、时间戳、计费周期、定价版本、计量事件 ID、对账状态 | 支持审计跟踪和争议审查 |

有用的模式不是“记录所有内容”。而是保护隐私的客户归因、持久化的请求证据，以及受控地汇总到计费计量事件中。这就是按客户进行 AI 使用量计量如何将嵌入式 AI 从一个毛利率上的意外转变为一条可审查的产品线。

为何团队级使用量还不够

团队级使用量跟踪有助于工程团队管理支出，但对于嵌入式 AI 计费来说，这种粒度太粗了。一个生产环境的 API 密钥可能会混合来自免费试用、付费客户、内部员工、演示账户、重试、后台索引和测试装置的流量。如果您只按团队或环境分组，那么关于账单的对话就会变成猜测。

在以下情况下，客户级归因变得至关重要：

您将 AI 信用额度捆绑到付费计划中。
您对高级 AI 使用量的超额部分收费。
销售团队承诺了客户特定的信用额度或上限。
采购部门询问 AI 使用量如何显示在账单上。
客户对某项收费提出异议，或声称未使用某项功能。
支持团队需要解释为何某个租户超出了配额。
财务团队需要按账户、细分市场或功能计算毛利率。

按客户进行 AI 使用量计量不需要向 AI 提供商发送个人数据。事实上，应该避免这样做。您用于计量的客户密钥通常应该是一个内部的、计费安全的标识符，例如 cust_meter_8f2a9c，而不是电子邮件地址、公司名称、提示或最终用户名。

首先构建客户计量合同

计量合同是指每个 AI 请求在到达网关或提供商之前必须携带的一小组字段。保持其稳定、简单且可审计。

| 字段 | 示例 | 规则 | |---|---|---| | customer_meter_id | cust_8f2a9c | 内部客户或租户 ID，尽可能使用假名 | | billing_account_id | acct_2041 | 拥有账单的账户，不一定是最终用户 | | feature_id | support_summary | 产品功能或可计费的 SKU | | environment | prod | 将生产流量与预发布和测试流量分开 | | request_id | req_01HX... | 用于重放和支持的唯一应用请求 ID | | idempotency_key | meter_01HX... | 唯一的计量事件密钥，以便重试不会重复计费 | | model_requested | gpt-4o-mini 或网关别名 | 应用请求的内容 | | model_served | 路由后实际运行的模型 | 实际运行的内容（如果可用） | | unit_basis | tokens、requests、seconds、images | 将汇总到计费中的单位 | | pricing_version | ai-plan-2026-07 | 用于面向客户计算的版本 | | privacy_mode | metadata_only | 是否保留提示/输出的有效载荷 |

这份合同应由产品和财务团队共同创建。工程团队负责捕获质量；财务团队负责计费解释；支持团队负责向客户解释。

在 AI 调用离开您的应用前标记元数据

添加客户上下文最安全的地方是在已经知道已认证租户和功能的服务边界。不要让前端客户端发送客户 ID 作为可信的计费证据。后端应从会话、租户、权限或许可或作业所有者中派生出客户计量 ID。

type AiMeteringContext = {
  customerMeterId: string;
  billingAccountId: string;
  featureId: "support_summary" | "contract_review" | "agent_run";
  environment: "prod" | "staging" | "dev";
  requestId: string;
  pricingVersion: string;
};

function buildAiMetadata(ctx: AiMeteringContext) {
  return {
    customer_meter_id: ctx.customerMeterId,
    billing_account_id: ctx.billingAccountId,
    feature_id: ctx.featureId,
    environment: ctx.environment,
    app_request_id: ctx.requestId,
    pricing_version: ctx.pricingVersion,
  };
}

确切的传输方式取决于您的网关和 SDK。例如，Cloudflare AI Gateway 记录了用于请求标记的自定义元数据，并指出元数据值会出现在日志中以便搜索和筛选。其日志记录文档还描述了在使用 cf-aig-collect-log-payload: false 时仅记录元数据，保留令牌数、模型、提供商、状态码、成本和持续时间，同时跳过原始提示和响应负载。Vercel AI Gateway 记录了用于报告的 user 和 tag 字段，以及诸如 ai-reporting-user 和 ai-reporting-tags 之类的标头，用于标记使用情况而无需重写每个调用站点。

这些示例是提供商和网关的模式，而不是 Flatkey 的功能声明。如果您使用 Flatkey，请在依赖某个字段进行计费之前，在您的账户中验证当前支持的元数据路径和日志。

保留提供商使用量和成本维度

您的内部客户分类账不应过早地扁平化提供商的详细信息。提供商的使用量 API 通常会暴露一些维度，这些维度有助于稍后解释成本变化。

OpenAI 的组织使用量端点支持按 project、user、API key、model、batch 和 service tier 等字段对完成情况使用量进行分组，并返回 input tokens、output tokens、cached tokens、audio tokens、request count、model、project ID、user ID 和 API key ID 等使用量字段。OpenAI 的组织成本端点支持按 project、line item 和 API key 对成本进行分组，并返回 amount、currency、line item、project ID、API key ID 和 quantity 字段。

这并不意味着您的客户分类账应使用 OpenAI 用户 ID 作为客户 ID。这意味着您的按客户 AI 使用量计量层应保留足够的请求级上下文以进行连接：

将应用客户 ID 连接到网关请求 ID。
将网关请求 ID 连接到提供商请求或生成 ID。
将提供商使用单位连接到面向客户的计费单位。
将提供商成本项目连接到客户使用量存储桶。
将重试/回退事件连接到最终的计费决策。

如果提供商报告稍后显示按模型或 API 密钥划分的成本激增，您需要将其追溯到客户、功能和发票周期，而无需暴露提示内容。

使用客户使用量分类账

客户使用量分类账是原始 AI 日志和客户发票之间可供审查的表格。它应该是仅追加或版本化的，因为发票争议通常会询问截止时已知的情况，而不是回填后当前仪表板显示的内容。

| 列 | 示例 | 目的 | |---|---|---| | occurred_at | 2026-07-10T11:03:22Z | 源请求时间 | | billing_period | 2026-07 | 发票分组 | | customer_meter_id | cust_8f2a9c | 客户归属 | | feature_id | support_summary | 功能归属 | | environment | prod | 排除非计费流量 | | app_request_id | req_01HX... | 支持追踪 | | gateway_request_id | gw_91b... | 网关追踪 | | provider_request_id | gen_72c... | 提供商追踪（如果可用） | | model_served | model-alias | 实际使用的模型 | | input_tokens | 841 | 使用单位 | | output_tokens | 226 | 使用单位 | | requests | 1 | 使用单位 | | raw_provider_cost | 0.0042 | 内部成本基础 | | billable_units | 1,067 tokens | 面向客户的单位 | | pricing_version | ai-plan-2026-07 | 定价解释 | | meter_event_id | meter_01HX... | 计费系统交接 | | reconciliation_state | matched | 证据质量 |

该分类账是按客户进行 AI 使用量计量的价值资产。原始日志对财务部门来说过于详细。发票对工程部门来说又太晚。分类账是共享的证据层。

将分类账行转换为计费计量事件

如果您使用 Stripe 或其他基于使用量的计费系统，请不要盲目地发送每个原始 AI 请求。首先要确定哪些算作可计费使用量。

Stripe 的计量事件 API 需要一个 event_name 和一个 payload。payload 必须包含与计量的客户映射和值设置相匹配的字段；文档中显示了使用 payload[value] 和 payload[stripe_customer_id] 的示例。Stripe 还支持用于唯一性的 identifier 和以 Unix 秒为单位的 timestamp，其时间戳边界由 API 定义。

这可以清晰地映射到分类账：

{
  "event_name": "embedded_ai_tokens",
  "identifier": "meter_01HX7VJ8AQB8",
  "timestamp": 1783681402,
  "payload": {
    "stripe_customer_id": "cus_123",
    "value": 1067,
    "feature_id": "support_summary",
    "pricing_version": "ai-plan-2026-07"
  }
}

计费事件应该是幂等的。如果您的工作进程在超时后重试，同一个 AI 请求不应创建两个计费事件。将计量事件 ID 保留在客户分类账中，并存储计费 API 响应，即使响应是“已处理”。

决定哪些内容不计费

按客户进行 AI 使用量计量，既涉及收费，也涉及排除。您的分类账应在流量进入计费系统前对其进行分类：

| 流量类型 | 默认计费决策 | 要保留的证据 | |---|---|---| | 生产环境客户操作 | 可计费，如果套餐允许计量 AI | 客户 ID、功能、请求 ID、使用单位 | | 代表客户的内部支持操作 | 通常不计费或单独分类 | 员工 ID、工单 ID、客户 ID、原因 | | 提供商出错后重试 | 仅对成功的逻辑请求计费 | 原始请求 ID、重试次数、最终状态 | | 从一个模型回退到另一个模型 | 根据策略计费，而不是盲目地对两者都计费 | 请求的模型、服务的模型、路由决策 | | 预发布/开发/测试流量 | 不计费 | 环境、所有者、测试标记 | | 滥用或自动循环 | 通常记入信用额度或设置上限 | 速率限制事件、检测原因、客户通知 | | 数据回填或迁移 | 通常不计费 | 作业 ID、操作员、批准 |

在客户询问之前，请在内部发布这些规则。一份成文的政策可以防止支持、财务和工程部门为每项争议制定临时例外。

尽可能将提示内容排除在计费证据之外

计费证据很少需要原始提示或补全内容。大多数争议可以通过时间戳、功能、客户、模型、令牌数、请求状态和面向客户的事件标签来处理。

一项保护隐私的按客户 AI 使用量计量政策应区分：

计量元数据：客户计量 ID、功能、环境、请求 ID、模型、令牌、成本、时间戳。
操作负载：提示、检索到的文档、生成的文本、附件、工具输入。
支持注释：工单 ID、审核员 ID、信用额度原因、面向客户的解释。

第一类数据的存储时间应长于第二类。对第二类数据的限制应更严格。Cloudflare 的仅元数据日志记录模式在这里很有用，因为它展示了一种常见的操作分离：保留使用指标和请求元数据，而不存储该请求的请求和响应正文。如果您的网关或供应商提供类似的控制，请在发送受监管的客户流量之前进行测试。

在发票关闭前进行对账

对账作业是按客户 AI 使用量计量成为计费证据的地方。在发票最终确定之前运行它，而不是在第一次投诉之后。

使用此每日或每小时工作流：

提取计费周期的原始应用 AI 事件。
提取同一周期的网关日志或导出数据。
按模型、API 密钥、项目或订单项提取提供商的使用和成本摘要。
提取计费计量事件确认。
根据请求 ID、时间戳、客户计量 ID 和模型别名进行连接。
将每个分类账行标记为 matched、missing_gateway_log、missing_provider_usage、meter_not_sent、meter_duplicate、nonbillable 或 needs_review。
对于未解决的高价值行，阻止发票最终确定。
为支持和财务部门导出客户级摘要。

最重要的报告不是总支出，而是异常队列。少量不匹配的行可能会造成最大的客户信任问题。

构建争议资料包

当客户问：“为什么我被收取了 AI 使用费？”时，支持人员不应该打开五个仪表板即兴发挥。准备一个争议资料包格式：

| 部分 | 包含 | 避免 | |---|---|---| | 摘要 | 计费周期、功能、使用单位、客户套餐、总费用 | 除非明确需要，否则不要包含提示或补全文本 | | 证据 | 请求 ID、时间戳、模型类别、令牌/请求计数、计量事件 ID | 内部提供商机密或原始 API 密钥 | | 政策 | 计费规则、重试/回退政策、包含的信用额度政策 | 未经批准的一次性解释 | | 决定 | 接受、记入信用额度、更正或上报 | 在供应商之间推卸责任 | | 后续跟进 | 限制更改、错误修复、客户通知 | 未记录的手动编辑 |

这对于嵌入式 AI 功能尤其重要，因为点击该功能的用户可能不是审核发票的购买者。资料包必须用产品语言解释费用，而不仅仅是 API 语言。

实施清单

在推出面向客户的 AI 计费之前，请使用此清单：

每个 AI 请求都会收到一个后端派生的 customer_meter_id。
非生产流量在到达网关之前被标记。
应用程序为每个逻辑 AI 操作创建一个稳定的 app_request_id。
重试共享一个父请求 ID，并且默认情况下不会重复计数。
回退事件记录请求的模型、服务的模型和计费策略。
网关或提供商日志可以连接回应用请求。
提供商的使用和成本导出数据在有用的分组级别上得以保留。
客户使用分类账存储可计费和不可计费的行。
计费计量事件使用幂等标识符。
财务部门可以审查客户、功能、模型和周期的汇总数据。
支持团队有争议资料包模板。
提示和补全内容的保留与计量元数据分开，并被最小化。
客户可以看到足够的使用详情来理解他们的账单。

Flatkey 的适用之处

当运营问题是模型访问和发票激增时，Flatkey 就派上用场了。目前公开的 Flatkey 网站强调一个密钥即可访问 GPT、Claude、Gemini、DeepSeek、图像、音频和视频模型，一个 OpenAI 兼容的网关，使用分析和成本控制，请求日志，以及跨供应商的一张发票。对于希望减少供应商账户并拥有更清晰审查界面的团队来说，这是一个实用的基础。

对于按客户进行 AI 使用量计量，可将 Flatkey 用作统一路由，在此审查、定价和管理您的生产 AI 流量。将客户级别的计费证据保存在您自己的应用分类账中，除非您当前的 Flatkey 账户明确支持您所需的确切字段、导出、保留和计费工作流。然后在发出发票前，将 Flatkey 使用记录与供应商摘要和您的计费计量器进行核对。

如果您正在设计商业模型，请将本指南与按团队进行 AI API 成本归因、每次 AI API 请求的成本以及AI API 发票核对结合使用。当您需要当前的模型定价和计划详情时，请使用 Flatkey 定价页面。