接入大模型之后，很多团队都会遇到同一个尴尬局面：产品上线时测算的单次调用成本是几分钱，月底账单却是预算的十倍。原因通常不复杂——用户量增长、提示词越写越长、误用和滥用、以及高价位模型被用在了本不需要它的任务上。解决这个问题的核心思路有两个：一是从调用入口做预算限制，把支出的上限锁死；二是在任务层面做模型降级，让简单请求自动走便宜模型。本文围绕这两条主线展开，给出可以直接落地的方案和代码。
一、为什么成本会失控：先搞清楚钱花在哪里
在动手治理之前，必须先建立成本归因能力。大多数API提供商的账单只告诉你总额，不会告诉你哪个功能、哪个用户花的钱最多。常见的失控原因包括：提示词模板中塞入了大量上下文（例如每次都带上完整对话历史）、系统提示过长、用GPT-4处理格式转换或分类这种简单任务、以及缺少并发和频率限制导致被刷接口。
一个实用的做法是在调用层做统一封装，把每次请求的模型名、输入token数、输出token数、用户ID、功能模块都记录下来。以OpenAI的定价为例，GPT-4的输入价格通常是GPT-3.5的十几倍以上，如果一个功能模块80%的请求只是做关键词提取，却全部走GPT-4，这就是最典型的浪费点。先有数据，再谈优化，否则所有降级决策都是盲猜。
二、预算限制：从入口处锁死支出上限
预算限制的第一层是账号级的硬性限额。以OpenAI为例，可以在后台设置每月消费上限，超过后API自动拒绝请求。这个开关看似简单，却是最后的保险丝——即使其他所有机制都失效，账单也不会无限膨胀。建议为生产环境和测试环境使用不同的API Key，并给测试环境设置极低的限额。
第二层是应用级的配额管理，也就是按用户或按功能分配预算。典型实现是为每个用户维护一个计数器，记录当日已消耗的token数或金额，超过阈值后降级到免费模式或直接拒绝。下面是一个基于Redis的简单示例：
import redis
import time
r = redis.Redis()
def check_and_consume_quota(user_id: str, cost: float, limit: float = 1.0) -> bool:
"""按自然日统计用户消费金额，超过限额则拒绝"""
key = f"quota:{user_id}:{time.strftime('%Y%m%d')}"
# 原子性累加，保证并发安全
new_val = r.incrbyfloat(key, cost)
if new_val == cost:
r.expire(key, 86400 * 2) # 首次使用时设置过期时间
return new_val <= limit
# 调用示例
if not check_and_consume_quota("user_123", 0.012):
raise Exception("今日额度已用完，请明天再试")
第三层是限流，用于防止突发流量和恶意刷接口。令牌桶算法是常见选择：以固定速率往桶里放令牌，每个请求消耗一个令牌，桶空则拒绝。相比简单的固定窗口计数，令牌桶允许短时突发又能平滑限速，适合LLM这种延迟敏感的服务。三层机制叠加，才能做到单用户可控、整体可控、账号绝对可控。
三、模型降级：让简单任务自动走便宜模型
模型降级的核心判断是：这个请求真的需要GPT-4级别的推理能力吗？经验上，以下几类任务用GPT-3.5甚至更小的模型就足够：文本分类、情感分析、格式转换、简单摘要、FAQ匹配、固定格式的信息抽取。而复杂推理、长链逻辑、代码生成调试、创意写作等任务才真正受益于旗舰模型。
降级策略可以分为静态路由和动态降级两种。静态路由是在代码层面按功能模块写死模型选择，实现最简单，适合功能边界清晰的产品。动态降级则更进一步：先让便宜模型回答，通过某种置信度信号判断结果是否可靠，不可靠时再用贵模型重试。置信度信号可以是自评估（让模型输出一个确定性打分）、关键词匹配（检测到“我不知道”“无法确定”等表述时升级）、或者用小模型先做难度分类，按难度路由。下面是一个分级路由的实现示例：
import openai
PRICING = {"gpt-4": 0.03, "gpt-3.5-turbo": 0.002} # 每千token大致价格，仅供示意
def route_by_difficulty(prompt: str) -> str:
"""用便宜模型判断任务难度，再决定使用哪个模型"""
classify = openai.chat.completions.create(
model="gpt-3.5-turbo",
messages=[
{"role": "system", "content": "判断以下任务是简单还是复杂。只回答simple或complex。"},
{"role": "user", "content": prompt}
],
max_tokens=5
)
label = classify.choices[0].message.content.strip().lower()
return "gpt-3.5-turbo" if "simple" in label else "gpt-4"
def call_with_fallback(prompt: str):
"""先走便宜模型，结果可疑时升级到GPT-4"""
model = route_by_difficulty(prompt)
resp = openai.chat.completions.create(
model=model,
messages=[{"role": "user", "content": prompt}]
)
answer = resp.choices[0].message.content
# 检测低置信信号，触发升级
weak_signals = ["无法确定", "我不能", "信息不足"]
if model != "gpt-4" and any(s in answer for s in weak_signals):
resp = openai.chat.completions.create(
model="gpt-4",
messages=[{"role": "user", "content": prompt}]
)
answer = resp.choices[0].message.content
return answer
还有一种更激进的降级手段是失败降级：当预算即将耗尽或高价位模型限流时，自动把所有请求切换到低价模型，牺牲部分质量换取服务可用。这种策略需要一个总开关配合，建议通过配置中心实现，可以随时回滚。同时务必监控降级前后的用户满意度指标（如任务完成率、投诉率），避免为了省钱把产品体验拉垮。
四、监控与告警：让成本变化可观测
成本治理不是一次性工程，而是持续运营。建议搭建三类指标：一是实时消耗速率，即每分钟花费的金额，突增往往意味着被刷或代码bug；二是分模块成本占比，观察降级策略是否真的生效；三是质量回归指标，确保省钱的改动没有伤害效果。当日消耗达到预算的70%和90%时分别触发告警，给运营留出反应时间。
落地上可以把每次API调用的token用量写入时序数据库，用Grafana画出日消耗曲线和模型分布饼图。当发现某个模块GPT-4占比异常升高时，第一反应应该是检查是否有新代码绕过了路由层直接调用贵模型——这在多人协作的项目里非常常见。规范的做法是：所有模型调用必须经过统一的网关函数，禁止业务代码直接实例化客户端，从架构上保证降级和预算策略不被绕过。
总结一下，预算限制负责守住底线，模型降级负责提升效率，监控告警负责及时发现问题。三者配合，才能在大规模调用场景下做到成本可控。实践中多数团队在引入静态路由加用户配额这两项基础措施后，就能砍掉一半以上的无效支出，投入产出比非常高。