LLM Token 消耗与生产限流：从查看到落地的完整指南

LLM Token 消耗与生产限流：从查看到落地的完整指南

调用大模型 API 时，Token 就是钱。不管不问，成本可能失控；管得太死，又会影响用户体验。 本文整理了一套从单次 Token 查看到生产环境限流配置的完整方案，直接可用。

---

一、单次 Token 消耗怎么看？

方法 1：API 响应里直接拿（最准，生产必用）

主流厂商（OpenAI、阿里云、百度、火山引擎等）的 API 返回 JSON 中都带有 usage 字段：

{
  "usage": {
    "prompt_tokens": 120,
    "completion_tokens": 80,
    "total_tokens": 200
  }
}

注意 ：使用流式返回（stream=true）时，需要额外加上参数：

stream_options: {"include_usage": true}

这样最后一条 chunk 会携带 usage 信息，否则流式模式下是拿不到精确 Token 数的。

方法 2：本地提前估算（发请求前用）

用分词器提前估算文本长度：

import tiktoken

enc = tiktoken.get_encoding("cl100k_base")
tokens = enc.encode("你的输入文本")
print(len(tokens))  # 近似 token 数

一个实用的经验法则：

1 汉字 ≈ 1 token，1 英文单词 ≈ 1 token。

方法 3：平台控制台看明细

平台	查看路径
OpenAI	Usage 面板 → 每日明细
阿里云百炼	模型监控 → 调用统计 → 追踪单次调用
Azure OpenAI	门户 → AI Foundry → 用量明细
百度千帆	模型管理 → 监控看板

---

二、生产环境 Token 限制：没有国标，只有行业实践

核心原则只有一句话：

单请求不超模型上下文窗口 + 按场景设预算 + 限流防刷。

技术硬上限（不能超）

不同模型的上下文窗口决定了硬上限：

模型	上下文窗口
GPT-3.5	16K
GPT-4 / GPT-4o	128K
国产通用模型（Qwen、GLM、Baichuan 等）	8K ~ 32K

安全底线 ：单次 total_tokens ≤ 模型上下文窗口 × 80%，留出冗余空间，避免请求被截断。

行业常用软限制（按场景分级）

场景	单次最大 Token	说明
核心业务（支付/风控/客服）	4K ~ 8K	关键链路，允许长上下文
普通业务（文案/摘要/咨询）	2K ~ 4K	平衡成本与体验
轻量工具（翻译/短问答）	500 ~ 1K	高频高并发，严控成本
测试/开发环境	≤ 1K	防滥用、降本

生产必配的 4 个限流维度

1. 单次请求上限
   → 如 max_tokens=2000（输出）+ 输入截断 ≤ 4K

2. 每分钟 Token（TPM）
   → 核心服务 10万~50万，普通业务 2万~5万

3. 每日配额
   → 核心 100万/日，普通 20万/日

4. 用户/租户级隔离
   → 免费用户 ≤500/次，付费 ≤4K/次

---

三、推荐落地标准（直接可用）

如果你不想从零设计，可以直接套用下面这套配置：

单次请求

• 输入（prompt）≤ 3000 token
• 输出（max_tokens）≤ 1000 token
• 合计 ≤ 4000 token（通用场景）

并发/时间窗口

• TPM（每分钟 Token）≤ 10 万
• 单用户每日 ≤ 5 万 token

成本红线

• 单请求成本 ≤ 0.01 元（按主流模型价格估算）
• 日成本不超过业务营收的 1%~3%

---

四、Token 消耗的组成分析

了解 Token 花在哪里，才能精准优化。

总 Token = 输入 Token（Prompt）+ 输出 Token（Completion）

输入 Token 构成

• 系统指令（System Prompt）
• 用户问题
• 历史对话上下文
• 工具/函数定义
• RAG 检索结果

输出 Token 构成

• 模型生成的回答内容
• 结构化输出格式（JSON、Markdown）
• 多次调用时的中间推理结果

谁更贵？

输出 Token 通常是输入的 2~3 倍价格。 这是因为生成过程需要逐 Token 推理计算，而输入可以并行处理。

所以在做成本优化时，优先压缩输出 Token，其次是输入上下文裁剪。

---

五、为什么要限流？

限流不是给自己找麻烦，而是保护系统稳定性和控制成本的必要手段。

1. 成本控制

Token 就是真金白银。不加限制的请求可能导致：

• 长文本攻击：恶意用户发送超长 prompt
• Agent 无限循环：模型不停调工具、不停产出 Token
• 日结账单飞涨

2. 稳定性保障

• 长请求占用计算资源，拖慢整体并发
• 单租户打满配额，影响其他用户

3. 安全防护

• 防恶意刷接口
• 防 Prompt 注入后的长文本泄露
• 防无限递归调用

---

六、生产级限流配置示例（Python）

import time
from collections import defaultdict
from dataclasses import dataclass
from typing import Optional


@dataclass
class TokenLimitConfig:
    """单租户 Token 限流配置"""
    max_prompt_tokens: int = 3000       # 单次输入上限
    max_output_tokens: int = 1000       # 单次输出上限
    max_total_tokens: int = 4000        # 单次合计上限
    tpm_limit: int = 100_000            # 每分钟 Token 上限
    daily_limit: int = 50_000           # 每日 Token 上限


class TokenBucket:
    """简单的 Token 桶限流器"""

    def __init__(self, config: TokenLimitConfig):
        self.config = config
        self.daily_usage = defaultdict(int)  # user_id → 当日 Token 数
        self.minute_log = []                 # [(timestamp, tokens)]

    def check_request(self, user_id: str, prompt_tokens: int, 
                      max_output: Optional[int] = None) -> bool:
        # 1. 检查单次请求上限
        if prompt_tokens > self.config.max_prompt_tokens:
            return False
        output_limit = max_output or self.config.max_output_tokens
        if prompt_tokens + output_limit > self.config.max_total_tokens:
            return False

        # 2. 检查每日配额
        if self.daily_usage[user_id] >= self.config.daily_limit:
            return False

        return True

    def record_usage(self, user_id: str, total_tokens: int):
        """请求完成后记录用量"""
        now = time.time()
        self.daily_usage[user_id] += total_tokens
        self.minute_log.append((now, total_tokens))
        # 清理一分钟前的记录
        self.minute_log = [(t, n) for t, n in self.minute_log
                          if now - t < 60]

    def current_tpm(self) -> int:
        return sum(n for _, n in self.minute_log)


# ========== 使用示例 ==========
config = TokenLimitConfig()
bucket = TokenBucket(config)

def call_llm(user_id: str, prompt: str, model: str = "gpt-4"):
    prompt_tokens = estimate_tokens(prompt)

    if not bucket.check_request(user_id, prompt_tokens):
        return {"error": "超出 Token 配额"}

    # 调用 API（略）
    response = openai.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        max_tokens=1000
    )

    usage = response.usage
    bucket.record_usage(user_id, usage.total_tokens)

    return response

---

七、常见优化策略

1. 上下文裁剪

• 历史对话用滑动窗口，只保留最近 N 轮
• RAG 检索结果按相关性截断 Top-K
• 系统 Prompt 精简到必要内容

2. 缓存复用

• 相同查询走缓存，不重复调用
• 系统 Prompt + 工具定义缓存为恒定输入

3. 模型分级降级

• 简单任务用小模型（如 GPT-4o-mini、Qwen-Turbo）
• 超出配额时自动降级到更便宜的模型
• 非核心业务使用批量异步处理

4. 输出压缩

• 结构化输出代替自然语言回复
• 控制 max_tokens 不要留太多余量
• Agent 推理过程中间结果不返回给用户端

---

八、总结

Token 消耗管理说难不难，但需要在一开始就设计好：

1. 可见：每次调用记录 usage，做日志埋点
2. 可控：单次上限 + TPM + 日配额三层限流
3. 可优：缓存、裁剪、降级，持续压降成本