大模型服务配额设计：从调用次数到Token计量

一、为什么计量单位要从调用次数转向Token

早期的大模型应用多以“一次对话”作为计量单位。这种方式简单直观，但只适用于单轮问答。当系统开始承担代码编写、资料检索、文档分析和跨工具执行等任务时，单次请求的资源消耗差异会非常大。一次简单问答可能只消耗几十个Token，而一次多步骤任务可能包含多轮推理、多次工具调用和很长的上下文，消耗量可能达到数十倍。如果仍按调用次数计费，低消耗请求会被高估，高消耗请求会被低估，成本与收费无法对应。

Token是模型处理文本的基本单位，输入和输出都会计入。除Token数量外，影响单位资源成本的因素还包括模型规格、上下文长度、推理深度和响应速度模式。因此，成熟的计量体系通常以Token为基础，再叠加权重系数，形成统一的资源度量。

二、配额设计要回答的三个问题

设计配额系统前，需要先明确三个问题。

1. 计量什么。 常见的计量项包括输入Token、输出Token、推理Token、工具调用次数和任务执行时长。计量项越多，成本越贴近真实消耗，但统计和解释的复杂度也随之上升。
2. 按什么粒度限制。 配额可以按用户、按席位、按组织或按项目分配。粒度越细，越能防止单个用户或单个任务耗尽共享资源，但管理成本更高。
3. 额度如何恢复。 常见方案有固定窗口、滑动窗口和令牌桶。固定窗口实现简单，但在窗口边界处可能出现瞬时突发。令牌桶允许一定程度的突发请求，同时限制长期平均速率，更适合交互式场景。

下表对比了三种常见恢复机制。

机制	实现复杂度	边界突发	适用场景
固定窗口	低	明显	粗粒度的日、月配额
滑动窗口	中	较少	需要平滑限流的接口
令牌桶	中	可控	允许短时突发的交互任务

三、多时间窗口限流

单一周期的配额难以同时满足两类需求。短周期窗口（如五小时）用于约束瞬时峰值，防止用户在短时间内集中消耗资源。长周期窗口（如一周）用于约束总量，保证资源在更长时间内公平分配。两类窗口可以同时生效，一次请求只有在所有窗口都有剩余额度时才能执行。

判断逻辑可以概括为：可用额度等于所有窗口剩余额度的最小值。下面是一段示意代码，仅说明判断与记录的流程：

# 示意代码：多窗口配额检查
def check_quota(task_cost, windows):
    """检查任务是否可以执行，返回受限的窗口名称。"""
    for w in windows:
        if w["used"] + task_cost > w["limit"]:
            return False, w["name"]
    return True, None
def record_usage(task_cost, windows):
    """任务完成后，把实际消耗记入所有窗口。"""
    for w in windows:
        w["used"] += task_cost
windows = [
    {"name": "five_hour", "limit": 1000, "used": 620},
    {"name": "weekly",    "limit": 5000, "used": 4800},
]
ok, blocked_by = check_quota(300, windows)
print(ok, blocked_by)  # 输出 False weekly，周窗口已接近上限

该示例说明一个容易被忽视的现象：即使短周期窗口仍有余量，长周期窗口接近上限时请求依然会被拒绝。因此，产品文档需要明确告知用户每个窗口的含义，并在界面中分别展示剩余额度，避免用户对“为什么无法继续”产生困惑。

实际系统中还需注意并发问题。如果两个请求同时读取到相同的剩余额度，就可能出现超额扣减。解决办法通常是使用原子计数操作，或者在配额服务中按用户加锁。

四、预扣与结算

任务执行前，系统往往无法准确知道实际消耗量。输出长度取决于模型生成的内容，工具调用次数也依赖于任务过程。常见做法是采用“预扣加结算”的两阶段方式：

1. 预扣。 根据输入长度和预估输出上限，先冻结一部分额度。
2. 结算。 任务结束后，按实际消耗扣减，并释放预扣金额与实际消耗之间的差额。

这种方式的关键在于保证结算的幂等性。同一任务即使因网络重试被提交多次，也只能扣减一次。失败任务的处理同样需要明确规则：如果模型调用在输出阶段异常中断，是否计费、是否退还，应当在服务条款和接口文档中写清楚，并在日志中记录原因，便于事后审计。

五、按模型与速度档位加权计量

同样数量的Token，在不同模型上的计算成本可能差别很大。速度更快的服务模式通常需要占用更多计算资源，因此单位消耗也更高。把这些因素统一纳入计量，可以使用加权公式：

任务成本 = 输入Token × 输入权重(模型)
         + 输出Token × 输出权重(模型)
         + 推理Token × 推理权重(模型)
         + 工具调用次数 × 工具权重
         × 速度档位系数

下面的示意代码展示了权重表的组织方式。其中的数值仅用于说明结构，并非任何实际服务的费率。

# 示意代码：加权成本计算，数值仅为演示
MODEL_WEIGHTS = {
    "compact":  {"input": 1.0, "output": 4.0, "reasoning": 4.0},
    "standard": {"input": 2.0, "output": 8.0, "reasoning": 8.0},
}
SPEED_MULTIPLIER = {"normal": 1.0, "fast": 4.0}
TOOL_CALL_WEIGHT = 50
def task_cost(model, speed, input_t, output_t, reasoning_t, tool_calls):
    w = MODEL_WEIGHTS[model]
    base = (input_t * w["input"]
            + output_t * w["output"]
            + reasoning_t * w["reasoning"]
            + tool_calls * TOOL_CALL_WEIGHT)
    return base * SPEED_MULTIPLIER[speed]
print(task_cost("standard", "fast", 3000, 1200, 800, 3))

权重表应当集中管理并纳入版本控制。每次修改权重都需要记录生效时间，并保证历史账单可以按当时的规则重算。否则，用户对账时会出现无法解释的差异。

六、企业用户的预算与用量治理

对企业而言，配额不只是技术限制，也是预算工具。管理者通常需要回答三个问题：每个团队花了多少，哪类任务消耗最大，额度是否足够支撑下个周期的计划。为此，可以从以下几个方面建立治理机制。

• 用量可视化。 按项目、按任务类型和按模型统计Token消耗，形成趋势图。一个团队的消耗突然上升，往往意味着某个流程出现了循环调用或上下文膨胀。
• 阈值告警。 当某个窗口的使用率超过设定值时，向负责人发送通知。告警应留出足够的处理时间，避免额度耗尽后业务中断。
• 额度分配。 为关键项目预留独立额度，防止日常查询耗尽共享资源。
• 成本优化。 常见手段包括：缩减无关的上下文，减少重复提示词；对稳定的中间结果做缓存；把大任务拆分为可独立执行的小步骤；对简单任务选用规模较小的模型。

优化时需要注意质量与成本的平衡。过度压缩上下文可能导致输出质量下降，因此应当结合评测集对改动前后的结果进行对比，再决定是否推广。

七、实施检查清单

上线配额系统前，建议逐项确认以下内容。

• 计量口径在文档、接口和账单中保持一致，同一概念使用同一术语。
• 每个时间窗口的起止规则、重置时间和时区定义清晰。
• 并发扣减使用原子操作，并有对应的压力测试。
• 预扣、结算、退款各环节均有日志，且日志中不记录用户提示词或敏感数据，只保存必要的统计字段。
• 权重表有版本号，历史账单可以按当时规则复算。
• 用户端能够看到各窗口的剩余额度和预计恢复时间。

配额系统的价值在于让资源消耗可预测、可解释、可审计。只要计量口径和恢复规则清晰，用户就能据此安排工作，平台也能在资源增长与服务质量之间保持稳定的平衡。