LLM API 按密钥支出限制解决了帐户级结算控制无法解决的问题：一个脚本、代理、客户、环境或泄露的凭据不应在任何人注意到之前消耗掉全部 API 预算。

大多数团队从单一提供商密钥和单一每月预算开始。这适用于早期实验，但一旦同一帐户支持生产流量、本地开发、编码工具、后台作业、客户租户、Telegram 机器人或经销商工作负载，它就会崩溃。问题不仅仅是账户总共花费了多少钱。实际问题是每个密钥是否有明确的所有者、明确的预算、可预测的故障模式以及足够的使用跟踪来解释发生的情况。

提供商控制各不相同。一些平台提供组织或项目支出限制。有些暴露了工作空间上限。有些提供的警报不会阻止交通。有些限制是速率限制而不是货币上限。持久的成本控制设计将提供商限制视为一层，然后在可以识别各个工作负载的网关或应用程序边界添加每键 AI API 预算。

每键支出限额是多少

每个按键的支出限额是附加到特定API按键或虚拟按键的预算。密钥可以代表人员、工作负载、客户、环境、自动化、机器人或下游服务。当该密钥的使用量达到配置的预算时，平台可以发出警告、限制、冻结、拒绝新请求、以不同方式路由或要求操作员提高限制。

这与提供商帐户限制不同。帐户或组织上限可以保护顶级计费关系，但它通常无法判断支出是否来自生产服务、测试脚本、泄露的密钥或单个客户。每键控制可减少爆炸半径。他们使预算边界与运营边界相匹配。

例如，个人开发者可能会为个人助理、编码代理、文档提取作业和公共演示应用使用单独的密钥。该帐户可能有每月上限，但每个密钥都应该有自己的预算和使用历史记录。公开演示需要一个小的硬上限。编码代理可能需要每日上限加上型号限制。文档作业可能需要较大的临时预算，但需要严格的并发控制。将所有这些视为一个共享密钥使得 AI API 配额管理主要是猜测。

支出限额、配额和费率限制不同

许多费用事故都是由词汇问题引发的。配额、速率限制和支出限制都可以阻止请求，但它们控制不同的风险。

支出限额

支出限额是一个货币阈值。它可以根据提供商报告的确切使用情况、网关估计成本、结算的代币使用情况、预付积分或本地价格目录来计算。支出限制可以是软性的，也可以是硬性的。软限制通知但允许继续使用。硬限制尝试在达到阈值后停止新的使用。

硬限制很有价值，但不应将其视为数学上瞬时的。并发请求、流式响应、异步作业、延迟的提供者报告和分布式执行可能会允许少量的溢出。好的系统会明确该行为并为此进行设计。

配额

配额是一种更广泛的津贴。它可能指请求、令牌、图像、模型、信用、并发、计费层或工作区容量。一些提供商使用配额语言来实现帐户级别的资格，而不是支出控制。配额在没有预算的情况下也很有用。

速率限制

速率限制控制一段时间内的流量：每分钟的请求数、每分钟的令牌数、并发请求数或类似的衡量标准。速率限制对于遏制重试循环和滥用至关重要，但它们并不等同于 LLM API 预算限制。十个便宜的请求和十个昂贵的高上下文请求可能具有截然不同的成本。

最强大的设计结合了所有三项：资金支出限制、分配配额以及速度的速率或并发限制。

为什么提供商原生限制还不够

提供商原生限制很重要。 OpenAI 支持项目和组织级支出控制、警报、项目范围的密钥、端点权限、模型配置和速率限制操作。 Anthropic 支持工作区范围内的密钥，其工作区支出和速率限制低于组织级别的限制。 Google Gemini 键与 Google 云项目关联以进行计费和配额，而速率限制取决于项目使用层，并且可能因帐户状态而异。 Cloudflare AI Gateway 可以按提供商、模型和元数据定义支出限制，并在配置的规则超出预算时阻止请求。

这些控件有所帮助，但它们并不都提供相同的粒度。提供商项目对于一个应用程序来说可能是正确的边界，而对于另一个应用程序来说则过于宽泛。工作区可以分隔团队，但仍可以组合多种服务。标准提供商密钥可能无法识别下游客户或内部用户。警报可能会在损坏已经发生后发出通知。速率限制可能会减缓不良循环而不反映模型价格。

网关层通过发布与您实际操作方式相匹配的密钥来填补这一空白。它可以将预算、模型策略、速率限制、并发限制和使用情况分析附加到同一身份。它还可以标准化跨提供商的控制，因此您不需要每个上游API都支持完全相同的策略模型。

选择正确的归因边界

仅当键代表有意义的内容时，每键预算才有效。在设置 API 键支出限制之前，请确定每个键应代表什么。

有用的边界包括生产服务、开发环境、CI 作业、本地实验、客户租户、公共演示、Telegram 机器人、编码代理、批处理工作人员、经销商和支持工具。代表太多不相关参与者的密钥无法执行有用的预算。如果十个客户共享一个密钥，则密钥预算可能会保护您的帐户，但不会告诉您是哪个客户造成了支出。

有时，关键级别归因是不够的。当许多最终用户生成请求时，SaaS 产品可能会使用一个后端密钥。在这种情况下，请求应携带客户、用户、工作空间或工作负载元数据，以便网关可以生成每个用户或每个租户的成本分析。关键仍然是执行凭证，而元数据添加了第二个归因维度。

对于在 Model Gate 或类似平台上构建的产品，这也是 合作伙伴 API 自动化 的相关之处：密钥创建、组分配、限制更改、冻结、轮换和使用读取应该是配置的一部分，而不是手动控制台工作的一部分。

实用的预算层次结构

单一限制是远远不够的。良好的 AI API 使用上限是分层的，因此最严格的适用政策获胜。

在顶部，保留帐户范围的紧急上限。如果所有其他控制措施均失败，这可以保护整个计费关系。下面是单独的生产、开发、暂存和实验环境。发展不能导致生产挨饿。生产应有更高的限制，但应有更严格的警报和审查。

接下来，对相关键进行分组。组可以代表客户、团队、机器人系列、代理客户、经销商帐户或应用程序。当多个密钥需要共享配额时，团体预算非常有用，但分类账仍应保留单个密钥的归属。否则，组上限可能会隐藏哪个键创建了支出。

最后，设置每个键的预算。小的、有风险的、公共的、自主的或实验性的密钥应该有较低的硬上限。受信任的生产密钥可能有更高的预算，但它们仍然需要警报和升级规则。无限密钥应该很少见并定期审查。

每次请求之前和之后要跟踪的内容

支出执行取决于您捕获的数据。至少，每个请求都应与密钥 ID 或密钥前缀、组、客户或工作负载标识符（如果可用）、请求的模型别名、解析的提供程序和模型、请求类型、输入令牌、输出令牌、媒体或工具使用情况、估计成本、结算成本、状态和时间戳相关联。

数据的作用不仅仅是计费。它可以让您识别高级模型路由错误、重试风暴、超出预算的请求失败、最近没有所有者审查的密钥以及消耗率突然变化的工作负载。为了进行更广泛的分析，专用的 AI API 使用情况分析仪表板 应按关键、模型、提供商、组、客户和时间窗口显示支出。

不要仅依赖提供商信息中心来实现此目的。提供者数据可能会延迟、范围不同、在错误的边界聚合或丢失应用程序所需的下游元数据。提供商发票对于对账仍然至关重要，但它们不能替代您自己的使用情况分类帐。

飞行前检查、预订和结算

强大的支出控制系统在将请求分派到上游之前做出决定，然后在得知最终使用情况后更正会计。

预检检查会询问密钥是否处于活动状态、模型是否允许、请求是否符合速率和并发限制，以及估计费用是否符合剩余预算。对于廉价的同步文本调用，这个估计可能很简单。对于昂贵的请求，它应该考虑最大输入、最大输出、模型价格、重试、后备路由、媒体成本、工具调用和异步完成。

对于高成本或长时间运行的工作，请使用预留模式。发货前预留预计金额。当提供商返回最终使用量时，结算实际费用并释放或调整预订。这会降低许多并发请求都通过相同预算检查并共同超出限制的可能性。

结算需要针对流式传输、取消、提供商错误、超时、异步作业、批量请求和未知结果的明确规则。如果最终使用不可用，系统应该知道是否保留预订、确定估计、重试使用检索或因未来请求而失败。正确的策略取决于工作负载的成本和可靠性需求。

将预算与模型控件配对

模型访问是最简单的成本控制之一。开发密钥不应能够调用高级推理模型、高上下文模型、视频模型或托管工具，除非该访问是故意的。公开演示可能只需要低成本模型配置文件。批量提取作业可能需要特定模型，并且不能回退到更昂贵的模型。

模型允许列表、拒绝列表和路由配置文件可以在花钱之前防止出现意外情况。它们还使预算更容易推理，因为每个请求的最大可能成本更窄。当允许回退时，回退路径必须遵守原始密钥预算和权限。否则，一条失败的廉价路线可能会变成一条计划外的昂贵路线。

选择更便宜或更可预测的模型是更广泛的统一 AI API计费策略的一部分，但应在提出请求时强制执行，而不仅仅是在发票到达后进行审核。

软警报和硬执行

软提醒和硬上限有不同的用途。警报最适合人工管理的钥匙，因为可用性很重要并且操作员可以做出响应。常见阈值是预算的 50%、80%、90% 和 100%。自主代理、公共应用和面向客户的试验通常需要较低的门槛，因为它们可能会在没有人为意图的情况下快速消耗预算。

硬上限可以保护资金，但可能会中断工作流程。生产密钥达到硬限制可能会产生用户面临的错误。数据管道可能会中途停止。除非错误已清除，否则编码代理可以重试。硬执行应该返回可预测的错误，通常是 429 或与付款相关的失败，具体取决于 API 设计，并带有机器可读的原因代码、已知的重置时间和补救指南。

客户行为很重要。一般错误可能会触发积极的重试，从而使事件变得更糟。超出预算错误应该告诉表现良好的客户不要重试，直到预算发生变化或窗口重置。

重置窗口和生命周期支出

每项预算都需要一个窗口。每月预算与计费周期保持一致。每日预算可以减少短期损失。滚动窗口对于突发控制很有用。手动重置可以支持预付费客户套餐、试用或内部实验。

无论您选择哪种重置模式，请区分当前期间的使用情况和终生支出。重置密钥的每月使用情况不应删除审核事件、总历史支出、安全证据或会计记录。在发生妥协或客户纠纷后，这种区别至关重要。

还定义重置时会发生什么。预算是否会在 UTC 午夜、帐户本地时间、订阅周年纪念日或自定义合同日期重置？有效预订是否会结转？异步作业是否按开始时间或完成时间计费？这些细节在边界附近很重要。

小数货币处理问题

LLM 使用成本通常每个请求都很小，但总体来说却很大。浮点运算可能会产生接近预算阈值的舍入误差，尤其是在将代币计数乘以价格目录和使用乘数时。使用小数安全算术存储和比较货币值。

Model Gate 的合作伙伴 API 文档反映了这种模式，将财务和使用字段表示为 JSON 字符串，并指示集成商使用任意精度的十进制算术而不是浮点数。这是执行支出的正确姿势：有意解析十进制字符串，验证它们，并在确定密钥是否有剩余预算时避免二进制浮点比较。

如何Model Gate适合

Model Gate 与每项 LLM 预算相关，因为它位于应用程序和多个上游 AI 提供商之间。网关可以集中密钥管理、计费归属、使用情况分析以及围绕网关颁发的密钥和组的执行决策，而不是依赖每个提供商公开相同的预算控制。

Model Gate 的合作伙伴 API 记录关键级别字段和操作，包括 spend_limit、使用情况、剩余支出限额、rpm_limit、concurrency_limit、冻结和解冻、密钥轮换和使用重置。它还记录了群组级别的支出限制、使用情况、总支出、费率和并发限制、使用价格基础和乘数、群组成员资格、群组使用情况和群组统计信息。

这些控件支持实用模式：为每个客户或工作负载创建单独的密钥、将密钥分组到经销商或应用程序下、冻结可疑密钥、轮换暴露的凭据、在允许操作之前读取剩余预算，以及在不更改生命周期支出或帐户余额的情况下重置期间使用情况。

重要的警告是，网关控制是本地执行和会计控制。它们并不意味着上游提供商对每个请求都有本地每键预算执行。良好的实施仍然可以与提供商计费保持一致，处理延迟结算，并记录使用情况或定价数据丢失时会发生什么情况。

常见的实施错误

最常见的错误是使用一个共享的 API 密钥来处理所有事情。这使得归因很弱，轮换存在风险，并且遏制几乎不可能。第二个是假设组织或项目上限与每个密钥的预算相同。它不是。它可以保护整个帐户，但不会隔离个别参与者。

另一个常见的失败是依赖警报而称其为上限。警报很有用，但除非存在并启用强制执行，否则支出将继续。同样，请求率限制不是美元预算。即使请求率较低，少量高上下文、高级模型、图像、音频、视频或托管工具请求也可能超出预期支出。

团队也会忘记并发性。如果在任何一个请求结算之前十个请求检查相同的剩余预算，则所有十个请求都可能通过，除非系统保留预算或使用原子计数器。这对于最终成本较晚才知道的流式处理和异步作业尤其重要。

其他错误包括使用浮动资金、允许回退路线绕过预算规则、以删除审核历史记录的方式重置使用情况、未能跟踪分类帐中的提供商和模型、创建许多没有所有者的小密钥，以及返回客户积极重试的模糊的超出预算错误。

每个关键 AI API 预算的决策清单

首先确定每个键代表什么。如果答案是“一切”，则将其分开。为生产、开发、CI、本地实验、公共演示、代理、机器人和主要客户创建单独的密钥。指定所有者和审核日期。

接下来，定义预算层次结构：帐户上限、环境上限、组上限、关键上限和每个请求限制。确定哪些限制是软警报，哪些限制是硬执行。对于自治或公共工作负载，首选较小的硬上限和更严格的速率限制。

然后定义请求分类帐。捕获关键、组、用户或客户元数据、模型别名、解析的提供商和模型、使用单位、估计成本、结算成本、状态和时间。使用小数安全会计。核对提供商发票，但不要依赖它们作为每个密钥真相的唯一来源。

之后，实施飞行前检查和结算。对于昂贵或并发的工作，请在派遣前预留预计支出。完工后结算实际成本。测试精确阈值请求、接近阈值的并发请求、流式传输、取消、提供商调用失败、重试、预算耗尽后异步完成以及价格目录更新。

最后，让操作变得明确。记录谁可以提高限制、谁可以冻结密钥、密钥何时轮换、使用重置如何工作以及增加预算之前需要哪些证据。支出控制系统的强大程度取决于其周围的操作习惯。

结论

LLM API 对于运行多个实验的任何人来说，关键支出限制都是一种实用的控制方法。他们将共享帐户预算转变为脚本、代理、客户、团队和环境的可执行边界。我们的目标不仅仅是降低支出；它是可预测的故障、明确的归因、更快的事件响应，并且当使用量增长时不会出现意外。

持久模式很简单：按实际所有权边界拆分密钥，分层帐户、组和密钥预算，将支出上限与费率和并发限制配对，刻意限制昂贵的模型，跟踪分类帐中的使用情况，使用小数安全资金处理，并与提供商结算进行协调。 Model Gate 等多模型网关可以集中跨提供商的控制，而提供商本机限制仍然是帐户、项目或工作区级别的重要支持。