大模型应用的账单往往是上线后才暴露出真实压力：同一个产品功能，测试阶段每天几十次调用几乎无感，一旦面向真实用户，调用量上升后，成本可能以数倍甚至数十倍的速度增长。仔细拆解账单会发现，并不是模型突然变贵了，而是所有请求都被无差别地发送给了能力最强、单价最高的模型，同时大量重复或高度相似的问题还在被反复计算。要解决成本超支，核心思路不是简单换成更便宜的模型，而是让每一类请求都匹配到最合适的处理方式，并让已经计算过的结果尽可能复用。
一、先定位成本超支的两个关键来源
大模型API通常按照输入和输出的token数量计费，不同级别模型之间的单价差异可能达到数倍到数十倍。如果产品里所有请求都统一调用最贵的模型，就会出现大量低复杂度任务占用高价资源的情况。例如一个只需要做简单分类、抽取关键词或者生成固定格式回复的请求，根本不需要最高级别的推理能力，但一旦走了高端模型，就会产生不必要的支出。
另一个成本来源是重复计算。用户问的问题经常高度相似，尤其是客服、知识库问答、文档总结等场景中，很多问题的语义几乎相同，只是措辞略有变化。如果没有缓存机制，系统每收到一次请求都会重新调用模型生成一次答案，这意味着同一类问题的成本会随着用户量线性增长，而不是被有效摊薄。
针对这两个来源，优化方向也很明确：一是建立动态模型切换机制，让请求根据任务难度、上下文长度和风险等级自动路由到不同模型；二是建立缓存层，对完全一致的请求做精确匹配，对语义相近的请求做模糊匹配，命中后直接返回历史结果。两者结合后，可以同时降低单位调用成本和重复调用次数。
二、动态模型切换：按任务难度匹配模型
动态模型切换的本质是在请求进入模型之前先做一次轻量判断，根据任务特征选择一个性价比合适的模型。最简单的做法是基于规则的路由，例如先检查输入文本的长度、是否包含复杂推理关键词、是否需要生成代码、是否涉及多步逻辑推导等。如果问题简单，就路由到轻量模型；如果问题确实复杂，再使用高端模型。
下面是一个基础的路由函数示例，它接收用户输入，根据文本长度和关键词判断该使用轻量模型还是高端模型。实际项目中可以根据业务数据调整判断条件，也可以接入一个训练好的小分类器来提高判断准确率。
def route_model(question):
complex_keywords = ["分析", "推理", "生成代码", "总结长文", "多步计算", "规划"]
is_complex = len(question) > 300 or any(keyword in question for keyword in complex_keywords)
if is_complex:
return "gpt-4o"
return "gpt-4o-mini"
规则路由的优点是实现简单、成本极低，不需要额外训练模型。它的局限性也很明显：规则太硬，容易误判。比如一个很短的问题也可能需要深度推理，一个很长的文本可能只是简单排版。因此，在产品数据积累到一定规模后，可以把规则替换为专门的轻量分类模型，用历史请求和人工标注训练一个二分类器，输出该走轻量模型还是高端模型。这样做虽然增加了一点前置计算，但相对于高端模型的价格，通常可以忽略不计。
动态切换还需要考虑质量风险。如果用户对回答质量敏感，可以设置一个置信机制：当路由判断不确定时，默认走更稳妥的高端模型；当请求来自低风险场景，比如内部测试或匿名用户，可以更激进地使用轻量模型。通过灰度发布和A/B测试，可以找到成本与质量之间的平衡点。
三、缓存策略：让重复问题不再重复计费
缓存策略的第一层是精确缓存。它把请求原文或者经过标准化处理后的文本作为键，把模型返回的答案作为值存储起来。下次收到完全相同的请求时，直接返回缓存结果，不需要再调用模型。这种缓存适合输入高度固定的场景，比如固定话术的FAQ、固定格式的模板生成、周期性的批量任务等。实现上可以使用内存字典、Redis或者本地键值存储。
精确缓存无法处理换一种问法的情况。例如用户问“怎么退款”和“我要退货怎么操作”，语义几乎一样，但文本不同。这时需要语义缓存。语义缓存会先把问题转换成向量，计算新问题与历史问题之间的相似度，如果相似度超过阈值，就返回最相近问题的缓存答案。这样可以把大模型的计算结果沉淀下来，覆盖更多表达变体。
def get_semantic_cache(question, threshold=0.92):
emb = embed(question)
best_score = 0
best_answer = None
for item in cache_store:
score = cosine_similarity(emb, item["embedding"])
if score > best_score:
best_score = score
best_answer = item["answer"]
if best_score >= threshold:
return best_answer
return None
语义缓存并不是银弹。阈值设置得太高，命中率会很低；阈值设置得太低，可能返回语义偏差较大的答案，影响用户体验。因此需要根据业务容忍度选择阈值，并且对缓存设置合理的过期时间。对于时效性很强的信息，比如价格、库存、新闻事件，不应该使用语义缓存；对于知识相对稳定的内容，比如产品说明、操作指南、法律法规解释，语义缓存的价值最大。
四、组合策略落地与成本监控
动态模型切换和缓存策略通常组合使用。一个请求到达后，先查询语义缓存，如果命中则直接返回；如果没有命中，再进入模型路由，根据任务复杂度选择轻量或高端模型；模型生成答案后，把问题和答案写入缓存，供后续请求复用。这样既能减少高端模型的调用比例，又能降低重复请求的总量。
def ask(question):
cached = get_semantic_cache(question)
if cached:
return cached
model = route_model(question)
answer = call_llm(model, question)
cache_question_answer(question, answer)
return answer
落地之后还需要持续监控几个关键指标。缓存命中率反映有多少请求被缓存直接拦截，命中率越高，重复成本越低。模型调用占比可以展示轻量模型和高端模型各自处理了多少请求，帮助判断路由规则是否合理。单次请求成本是把所有模型调用费用分摊到每个请求上，用来观察整体成本趋势。延迟指标同样重要，因为缓存命中会显著降低响应时间，而语义缓存计算向量也有少量开销。
下面的表格给出了一个可参考的监控维度：
| 指标 | 健康范围 | 异常信号 |
|---|---|---|
| 精确缓存命中率 | 15%以上 | 持续低于5%，需检查输入标准化 |
| 语义缓存命中率 | 20%至40% | 过高需排查阈值是否太松 |
| 高端模型调用占比 | 低于30% | 持续超过50%，路由规则需调整 |
| 单次平均成本 | 逐步下降 | 不降反升，需分析调用结构 |
策略上线初期不要一次性把阈值调到很激进的位置。可以先从保守的语义相似度阈值开始，观察用户反馈和成本变化，再逐步放宽。每一次调整都要记录对应的影响，避免为了节省成本而牺牲核心体验。动态模型切换和缓存策略的最终目标不是让所有请求都走最便宜的路径，而是让每一分钱都花在真正需要模型能力的地方。