月初打开账单我整个人是懵的。模拟项目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, turns1, attachment_len0): 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 起指数退避。不要无限重试否则旗舰模型涨价式连环调用会直接击穿预算。缓存 TTLFAQ 类缓存 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 厂商或者硬砍用量要靠谱得多。