大模型API涨价，程序员如何控制调用成本

大模型API涨价后，程序员控制调用成本的核心思路是：把每一次调用都当成花钱，先缓存、再降级、后压缩、最后监控。
这篇文章面向正在使用大模型API做开发、但账单开始失控的程序员，按可落地的顺序给出配置和代码片段，读完你能立刻在项目里减少不必要的调用。

先看清钱花在哪：用量审计与基线记录

控制成本的第一步不是改代码，而是知道自己每天花了多少、花在哪个接口。
建议在网关或业务层加一层日志，记录每次调用的模型名、输入token、输出token、耗时和调用场景。

如果项目已经接入网关（如One API、LiteLLM等），通常在后台的日志页面就能看到按模型和按key的用量统计。
没有网关的话，在代码里加几行日志即可：

import time, logging
logging.basicConfig(filename='llm_usage.log', level=logging.INFO)

def call_llm(model, prompt, resp):
    logging.info({
        'ts': int(time.time()),
        'model': model,
        'prompt_tokens': resp.usage.prompt_tokens,
        'completion_tokens': resp.usage.completion_tokens,
        'scene': 'chat'
    })

先跑三天，拿到基线数据。
没有基线，后面所有优化都无法验证效果。

缓存命中：让重复问题只花一次钱

很多业务场景里，用户问的问题是高度重复的。
比如客服FAQ、文档问答、代码解释，同一句话可能被问几十次。
这类场景直接用缓存挡住，成本能降一大截。

最简单的做法是用问题文本的hash做key，把模型返回存进Redis：

import hashlib, json, redis
r = redis.Redis(host='127.0.0.1', port=6379, db=0)

def cached_ask(prompt):
    key = 'llm:' + hashlib.md5(prompt.encode()).hexdigest()
    hit = r.get(key)
    if hit:
        return json.loads(hit)
    answer = call_llm(prompt)
    r.setex(key, 86400, json.dumps(answer))
    return answer

缓存过期时间根据业务调整：FAQ类可以设24小时，时效性内容设1小时以内。缓存命中率超过30%时，成本下降会非常明显。

模型路由：简单问题别用最贵的模型

不是所有请求都需要顶级模型。
把请求按复杂度分流，简单分类、抽取、改写用便宜的小模型，复杂推理和长文生成才走大模型。

可以在网关层配置路由规则，也可以在业务代码里判断：

LIGHT_TASKS = {'classify', 'extract', 'rewrite'}

def route(task_type, prompt):
    if task_type in LIGHT_TASKS:
        return call_llm(model='gpt-4o-mini', prompt=prompt)
    return call_llm(model='gpt-4o', prompt=prompt)

判断条件可以更细：输入token少于200且任务类型是分类或抽取，就走小模型；
需要多步推理或输出超过500token，才走大模型。多数业务里，60%以上的请求其实用不上最强模型。

Token压缩：把输入和输出都瘦下来

Token是计费的基本单位，输入和输出都算钱。
压缩分两个方向：输入侧精简提示词和历史上下文，输出侧限制max_tokens并去掉冗余格式。

输入侧常见的浪费是把整篇文档塞进prompt。
可以先做检索，只把最相关的2-3段拼进去。
历史对话也不要全量带上，保留最近3轮加摘要即可：

def build_prompt(history, question, max_history=3):
    recent = history[-max_history:]
    return '\n'.join([f"{m['role']}: {m['content']}" for m in recent]) + f"\nuser: {question}"

输出侧设置合理的max_tokens，并在提示词里要求模型直接给结果、不要解释过程。输入压缩30%、输出限制在必要长度，整体成本通常能再降20%-40%。

监控告警：别等账单来了才发现

成本控制需要持续监控。
建议设置日用量阈值，超过就告警。
可以在网关后台配置额度限制，也可以用脚本定时查询用量接口。

以LiteLLM为例，在config.yaml中设置预算：

budget_duration: 24h
max_budget: 20

同时每天记录一次各模型的token消耗，观察趋势。
如果某天用量突然翻倍，优先检查是不是缓存失效或路由规则被改。

常见疑问

缓存会不会导致回答过时？
会。所以缓存key要包含业务版本号或日期，时效性内容设置短过期时间，并在返回时标注“来自缓存”。

小模型回答质量不够怎么办？
先用小模型跑一批测试集，对比大模型结果。如果准确率差距在可接受范围内（比如分类任务差5%以内），就放心用。差距大的任务保留大模型。

涨价后已经上线的功能要不要砍？
不建议直接砍功能。先做用量审计，找出调用量最大但价值最低的场景，优先优化那部分。多数项目优化后能回到涨价前的成本水平。

控制大模型API调用成本不是一次性工作，而是持续的过程。
从用量审计开始，依次落地缓存、路由、压缩和监控，每一步都有明确的验证方式：缓存看命中率，路由看模型分布，压缩看平均token数，监控看日账单趋势。
按这个顺序执行，你就能在涨价环境下把成本控制在可预期范围内。