月初打开账单，我整个人是懵的。模拟项目X上个月的API开销是4660元，比上上月翻了将近一倍。这个项目本身是个小成本AI客服问答场景，日活也就几千，怎么都想不明白钱花在了哪里。排查了大半个月，我把问题锁定在一个当初根本没重视的架构决策上：所有请求都打到了同一个高价位模型接口，没有任何分流策略。后来我在中间加了一层智能LLM路由，把不同复杂度的请求拆开调度，月度成本降到了大约1400元，降幅接近70%。如果你也在做基于大模型API的应用，尤其是问答、客服、内容生成这类场景，这篇文章应该能在成本控制和技术选型上给你一些实际参考。
1. 账单涨到4660元：问题出在哪儿
1.1 从账单反推用量，第一步是别骂厂商
收到账单的第一反应当然是觉得“又被收贵了”。但骂完没用，得先搞清楚钱花在了哪里。我去后台导出了上个月的完整用量明细，按接口、按天、按token三个维度拆了一遍。
关键数据是这样的：
| 指标 | 数值 |
|---|---|
| 当月请求数 | 24800 次 |
| 旗舰模型占用 | 约 92% |
| 输入 tokens | 约 29.4M |
| 输出 tokens | 约 20.1M |
| 结算金额 | 4660 元 |
单看单次请求，平均每次输入约 1200 个 token、输出约 800 个 token，一次下来也没几毛钱。可当几万次请求全部堆在一个模型上的时候，量变就成了质变。那时候我做了四件事：导出账单、按接口聚合、按小时展开、随机抽日志样本。抽查样本时发现了真正的线索——超过九成请求都是“你们支持哪些支付方式”“退货多久能到账”这类固定问答，却全部通过高价位模型生成回答。
1.2 贵的不是调用次数，是“什么都用旗舰模型”
这里先说一个很多人忽略的事实：LLM API 计费不是按次数的，而是按 token 数量乘以单价。输入和输出单价不同，输出通常更贵。部分高价位模型还带有内部思考机制，会额外产生用户看不到的思考 token，这些 token 同样要计入账单，而且往往占据了不小的比例。
模拟项目X当初接入某头部大模型API厂商时，为了省事，我把所有功能都指向了旗舰模型。旗舰模型确实聪明，回答质量也稳定，但它根本不适用于“欢迎语”“FAQ 背诵”这类低难度任务。用我后来和同事聊天的话说：开着卡车去买菜，油费自然拦不住。
1.3 真正的根因：模型能力与任务难度错配
复盘下来，技术问题其实不复杂。账单这么高，不是因为用户量暴涨，也不是因为产品复杂，而是因为一个简单的架构决策失误：没有按任务难度划分调用通道。
模型选择在 LLM 应用里直接决定成本。旗舰模型的单价可能比轻量模型贵好几倍，但业务里如果有大量简单请求也跑在旗舰模型上，那就等于月月交“能力税”。这也是为什么很多人一看到大额账单就抱怨“API太贵”，但同样的流量换一套调度策略后，费用立刻就不一样了。
我的建议是：如果你的账单也开始长得离谱，先从后台导出原始用量，按接口名分组，看看哪个模型的调用量和 token 消耗最大。不要凭感觉猜，日志抽样会告诉你真实分布。这个排查链路，比去研究任何高级优化技巧都重要。
2. 智能LLM路由的核心逻辑：先给请求分个类
2.1 任务画像，是一切路由策略的前提
很多文章一上来就介绍各种路由算法，但实际落地首先要做的是任务画像。我把模拟项目X的请求日志随机抽了 1000 条，人工或半自动打标签，最终得到一个大致的分布：
| 任务类型 | 占比 | 典型例子 |
|---|---|---|
| 固定 FAQ / 打招呼 | 62% | “怎么退款”“你们地址在哪” |
| 短文本处理 | 12% | “把这句改成书面语” |
| 知识检索 + 轻量概括 | 15% | “章程里有没有提到请假规则” |
| 多轮复杂推理 | 11% | “帮我对比几份合同差异” |
这个比例不需要特别精确，但有了分布，你才知道该把哪部分流量从旗舰模型上挪走。如果不去做这一步，后面一切规则都像在赌运气。
2.2 分通道调度的匹配原则
拿到画像之后，我做了四层通道，按成本和能力从小到大排列：
- 固定 FAQ / 打招呼：直接走关键词匹配或向量检索，最好连模型都不调用，返回预设答案即可。这层响应最快，成本几乎为零。
- 短文本处理：交给轻量模型。润色、翻译、分类这类任务，轻量模型完全够用，输出质量用户感知不到区别。
- 知识检索 + 概括：用向量库检索相关片段，再配合轻量模型把检索结果整理成回答。关键成本在向量库，不在 LLM。
- 多轮复杂推理：保留旗舰模型。这类请求一旦答错，代价比省下来的几分钱高得多，必须留在能力最强的通道。
这个思路的每一步单看都不新奇，但组合起来就是“智能LLM路由”。路由的本质，是把请求按难度分级，然后让不同等级的模型承接对应任务。有人担心降级后回答质量变差，实际上大多数简单问题在轻量模型上的输出，和旗舰模型差别不大，用户根本察觉不出来。
2.3 路由判据怎么设计：规则优先，模型兜底
路由判据是我觉得最需要讲透的地方。我们用“规则优先、模型兜底”的混合方式，判断顺序从低成本到高成本：
- 先查缓存：同样的问题之前回答过，直接返回缓存结果。
- 关键词规则：命中 FAQ 白名单，走 FAQ 通道，连模型都不用调。
- 输入维度判断：是否带附件、上下文长度超过阈值、会话轮数超过 N 轮，走旗舰通道。
- 模型兜底：拿轻量模型做一次短文本分类，判断“这个问题是否需要深度推理”，如果分类置信度低，再升级到旗舰模型。
需要注意，不要在路由入口用旗舰模型去做判断。一次路由判断循环就会消耗不少 token，省下来的钱又还回去了。路由层必须优先用最便宜的判断方式，也就是缓存、关键词和启发式规则，模型分类只是最后一道兜底。
第一版规则建议“先粗后细”。不要一开始就设计特别复杂的打分公式，先用缓存和关键词跑几天，记录漏判的 case，再一点点把规则补进白名单和黑名单。
3. 动手搭路由层：一个轻量服务的实现细节
3.1 为什么自建路由层
当时我也调研过现成的 LLM 网关方案。它们能解决模型接入和负载分发，比如按照模型上限随机转发、失败重试、多 key 轮询，做得都很成熟。但我们真正的需求不是负载均衡，而是“按业务意图、成本预算、质量要求做调度”，这属于应用层策略，规则改动很频繁。
自建一个路由服务，代码量并不大，后面还能在路由层统一做缓存、日志和成本统计。如果只是让多个模型互为备份、随机分发，那直接用现成网关就够了；但像我们这样要把 FAQ 检索、轻量模型、旗舰模型串起来的场景，路由层确实值得自己做。
3.2 路由判型与调用链的伪代码
这是当时路由服务里最核心的一小段，我简化成了一个可以直接理解的版本：
# route_llm.py —— 一个极简的智能路由示例 import hashlib ROUTE_CACHE = {} FAQ_KEYWORDS = ["退款", "支付方式", "退货", "客服电话"] def make_key(message): return hashlib.md5(message.encode("utf-8")).hexdigest() def classify(message, turns, attachment_len): key = make_key(message) if key in ROUTE_CACHE: return "cache" if any(word in message for word in FAQ_KEYWORDS): return "faq" if attachment_len > 2000 or turns > 6: return "complex" return "simple" def route_request(message, turns=1, attachment_len=0): label = classify(message, turns, attachment_len) key = make_key(message) if label == "cache": return ROUTE_CACHE[key] if label == "faq": return call_llm("faq_template", message) if label == "complex": return call_llm("flagship", message) try: return call_llm("light", message) except Exception: return call_llm("flagship", message)这段代码只是骨架。真正落地时，classify函数里的关键词列表需要根据后台统计持续补充，call_llm函数再去分别对接不同模型的 API。另外注意faq_template这一路其实不一定需要真的调用 LLM，可以直接从预设模板里取答案，最省。
3.3 关键参数：超时、重试、缓存和并发
路由层本身也是一个服务，如果它崩了，整个业务都受影响。几个关键参数我建议直接抄作业：
- 超时：轻量模型设 3 秒左右，旗舰模型设 10 秒左右。太短容易误判失败，太长会拖垮路由 worker。
- 重试：失败重试 1 次，间隔 300ms 起，指数退避。不要无限重试，否则旗舰模型涨价式连环调用会直接击穿预算。
- 缓存 TTL：FAQ 类缓存 24 小时，热点活动文案 1 小时。太短命中率低，太长内容过期会导致答非所问。
- 并发控制：同一模型同时进行中的请求数加信号量限制，比如旗舰模型并发不超过 20。不然账号触发限流后，所有请求一起超时重试，成本会翻倍往上跳。
我踩过的最大一个坑是：路由层部署后第一个星期忘了做并发控制，一次营销活动流量进来，旗舰模型接口被限流，所有请求都在重试，那一小时的花费直接抵得上平时一天。
4. 省下70%：账单对比和核算口径
4.1 优化前后一个月的账单对比
路由策略稳定运行一个完整自然月后，拉出来的账单是这样的：
| 通道 | 请求占比 | 单月成本估算 |
|---|---|---|
| 缓存 / FAQ 模板 | 约 15% | 约 200 元 |
| 轻量模型 | 约 75% | 约 480 元 |
| 旗舰模型 | 约 10% | 约 620 元 |
| 路由层运行开销 | - | 约 100 元 |
| 合计 | 约 1400 元 |
原账单是 4660 元，新月度开销约 1400 元，差了 3262 元，降幅约 70%。这里要明确一点：这个数字对比是基于同一业务量、同一自然月的可比口径，中间没有砍功能，也没有牺牲复杂任务的模型能力。
4.2 这个70%怎么理解
（4660 - 1400）/ 4660 ≈ 70%。有些人可能会觉得，降了这么多是不是意味着回答质量变差了？其实不是。真正的变化是：75% 的简单请求不再走旗舰模型，改走轻量模型；15% 的请求直接命中缓存或 FAQ 模板，根本没有产生大模型调用成本；仍然只有 10% 左右的复杂请求保留在旗舰模型上。
省钱的核心不是“克扣模型能力”，而是“把不该用旗舰模型的请求剥离出去”。这一点在跟老板汇报的时候一定要讲清楚，不然很容易被误解为降低了产品质量。
4.3 算账时容易漏掉的三项成本
第一是缓存读取费用。API 厂商对缓存读取也会收少量费用，金额不大，但积少成多，要计入成本表。第二是升级重试成本。路由判错之后，轻量模型返回结果质量不合格，或者调用失败，升级到旗舰模型重新跑一遍，这就是额外支出。第三是路由层本身的基础设施成本，一台小服务器、向量库存储、日志系统的开销，虽然不大，但长时间累计也是一个数字。
做成本核算的时候，建议建一个简单的日报表：请求量、路由命中分布、缓存命中率、升级率、总费用。月末对账的时候，一眼就能看出钱花到哪里去了。没有这个日报，你很难知道下一次该优化哪一环。
5. 上线之后的坑：误判、延迟与长期维护
5.1 第一个坑：复杂任务被误判成简单任务
路由上线第一周就收到用户投诉，说“咨询借款利息怎么算，答案算错了一位小数”。查日志发现，这个问题被路由到了轻量模型通道，因为关键词“利息”不在 FAQ 黑名单里，会话轮数也不多，被判成了简单任务。
后面补了两个措施。第一是在路由判据里增加了“高风险业务词”名单，金融、医疗、合同、法律等词一旦出现，直接升级旗舰模型。第二是给轻量模型的输出加了一道校验钩子，检测到数值计算或列表明细时，如果置信度不够，自动升级重试。这两步之后，同类误判基本消失了。
5.2 第二个坑：延迟变高了还是变低了
加一层路由，我原本最担心的是 P95 延迟会变高。跑下来发现整体 P95 反而降了一些。原因是大多数简单请求走轻量模型和缓存后，响应时间比原来旗舰模型更快；只有复杂任务仍然维持原来的耗时。
不过监控不能只看平均值。要盯三个指标：路由命中率、缓存命中率、升级率。如果缓存命中率突然下降，说明用户输入写法和 FAQ 库的匹配度变差了，需要调整向量检索的阈值；如果升级率高于 10%，说明路由判据太激进，误判风险在累积。
5.3 第三个坑：路由规则不是一次性的
关键词列表、业务模型、模型价格都会变。现在我把“模型路由周报”固定成了每周五必须检查的巡检项：本周请求分布、成本分布、误判升级、用户负反馈。任务画像也需要每季度重新抽样更新，因为产品功能一多，简单任务和复杂任务的边界就会移动。
另外，各模型 API 的价格也会调整，路由规则里建议把“模型名称 → 调用地址 → 单价 → 并发限制”做成配置表，不要写死在代码里。价格一变，改配置和对应权重就行，不用重新发版。上线三个月后，我靠这个习惯躲过一次调价带来的成本波动。
最后说点个人体会。被账单吓到不可怕，可怕的是不知道钱被谁赚走了。第一次做 LLM API 成本优化的时候，我折腾了两周，最大的收获不是那 70% 的降幅，而是把以前完全黑盒的成本结构变成了白盒。如果只留一条建议，我会说：先给请求分类，再选模型。便宜模型不是洪水猛兽，旗舰模型也不是每件事都得上，把对的请求发给对的模型，比换一家 API 厂商或者硬砍用量要靠谱得多。
