多模型混跑成本失控？统一网关路由与Token计费换算实战指南

1. 多模型并行调用的真实场景与核心痛点

1.1 为什么团队会同时跑三个大模型

先说结论：没有任何一个模型能在所有任务上同时赢下质量、速度和成本三条线。我们团队从去年下半年开始，把日常的推理任务拆成了三类，分别交给三个不同的模型处理，跑了大半年下来，账单和效果都稳定了，才敢把这套方案写出来。

具体分工是这样的：复杂推理、长文档分析、代码生成这类任务交给 claude-opus-5.5，它的上下文理解能力和指令遵循度在长链条任务里确实稳，代价是单价高、响应慢；高并发、低延迟的批量任务，比如内容分类、意图识别、简单摘要，走 gemini-3.8-flash，它的吞吐和响应速度是三个里最好的，单价也低；中文语义理解、结构化抽取、本地化场景用 qwen3.8-max-0902，中文语料上的表现比前两个更贴合，尤其是涉及中文歧义消解和行业术语的任务。

这套组合不是拍脑袋定的。我们做过一轮横向评测，拿同一批 2000 条真实业务数据分别打三个模型，按准确率、P95 延迟、单次调用成本三个维度打分，最后发现：如果全用 opus，成本是混合方案的 4.2 倍；如果全用 flash，复杂任务的准确率掉 18 个百分点；如果全用 qwen，英文技术文档的处理质量明显下滑。混合方案是在质量和成本之间找到的那个平衡点。

1.2 三个模型混跑带来的四个真实麻烦

模型混跑听起来只是多调几个 API，实际落地时会撞上四个坑，每一个都够你折腾半天。

第一个坑是 Token 计费口径不统一。三个厂商对 Token 的定义、切分方式、计费粒度都不一样。opus 按输入输出分别计价，输入还分缓存命中和未命中两档；flash 的计费粒度更细，按千 Token 计费但有个最小计费单位；qwen 的输入输出价格差异大，而且对中文的 Token 切分和英文完全不同。你如果直接拿调用次数做成本估算，误差能到 30% 以上。

第二个坑是成本归因困难。一个项目线可能同时调用了三个模型，月底账单出来是一坨总数，你根本不知道哪个项目、哪个功能、哪个用户群体吃掉了多少钱。没有按项目线拆账的能力，成本优化就是盲人摸象。

第三个坑是路由逻辑散落各处。如果每个业务代码里都硬编码"这个任务调 opus、那个任务调 flash"，改一次路由策略要改十几个文件，还容易漏。而且没有统一入口，限流、重试、降级、日志这些横切关注点要在每个调用点重复实现。

第四个坑是故障切换没有兜底。任何一个模型 API 抖动或限流，业务就直接报错。三个模型混跑本来是为了冗余，结果因为没有统一网关，冗余能力完全没发挥出来。

1.3 这篇指南能帮你解决什么

接下来我会按四个层次把这套方案讲透：第一层讲清楚三个模型的 Token 计费粒度到底怎么换算，给你一张能直接用的换算表；第二层讲按项目线拆账的成本归因怎么做，包括标签体系设计和账单聚合逻辑；第三层讲统一网关的路由配置，给你一份可复现的配置模板；第四层讲实操中踩过的坑和排查技巧。

适合谁看：正在做多模型混跑、被账单和路由搞得头大的后端或平台工程师；准备引入第二个模型、想提前把架构设计对的团队；以及任何需要给 AI 调用做成本核算的技术管理者。不需要你是三个模型的专家，但至少要调过其中一两个的 API，知道什么是 Token、什么是流式响应。

2. Token 计费粒度换算：三个模型的账要算明白

2.1 三个模型的计费口径差异拆解

要把三个模型的成本算清楚，第一步是搞明白它们各自的计费口径。我拿我们实际用的版本参数来说明，具体数字以你签约时的报价为准，但口径逻辑是通用的。

claude-opus-5.5的计费分四档：输入未命中缓存、输入命中缓存、输出、以及可选的批量折扣。输入命中缓存的价格通常是未命中的十分之一左右，这个差异非常大。它的 Token 切分用的是自己的分词器，对英文比较友好，一个英文单词平均 1.3 个 Token 左右，中文一个字大约 1.5 到 2 个 Token。

gemini-3.8-flash的计费粒度是三个里最细的，按千 Token 计价，但有个最小计费单位，比如单次调用不足 100 Token 也按 100 Token 算。它的分词器对多语言支持好，中文切分比 opus 更省 Token，同样一段中文，flash 的 Token 数通常比 opus 少 15% 到 25%。

qwen3.8-max-0902的输入输出价差最大，输出价格可能是输入的 3 到 4 倍。它的中文分词是三个里最优的，中文 Token 效率最高，但英文技术术语的切分比较碎，同样一段英文代码，qwen 的 Token 数可能比 opus 多 20%。

这里的关键认知是：你不能用"调用次数"或"字符数"来估算成本，必须用每个模型自己的 Token 计数。而且同一个 prompt，三个模型算出来的 Token 数是不一样的，差异能到 20% 以上。

2.2 统一 Token 换算表的建立方法

既然三个模型的 Token 口径不同，我们就需要一个统一的换算基准。我们的做法是：以"等效 opus Token"作为内部核算单位，把所有模型的消耗都折算到这个基准上，这样跨模型比较和汇总才有意义。

具体怎么建这张表？分三步。

第一步，采样真实业务数据。从每个项目线各抽 500 条真实请求，覆盖长短文本、中英文混合、代码、结构化数据等典型场景。不要用构造的测试数据，真实数据的 Token 分布和测试数据差很远。

第二步，分别用三个模型的分词器计数。三个厂商都提供了 Token 计数接口或本地分词库，把同一批数据分别过一遍，记录每个模型的实际 Token 数。这一步要记录输入 Token 和输出 Token 两个值，因为它们的价格不同。

第三步，计算折算系数。以 opus 的输入价格为基准 1.0，算出其他两个模型相对于 opus 的价格系数，再乘以各自的 Token 数比例，得到"等效 opus Token"的换算系数。

我们实测下来的一张换算表大致是这样的（系数为示意，实际以你的报价为准）：

这张表怎么用？假设某个项目线这个月调用了 flash 处理了 1000 万输入 Token 和 200 万输出 Token，那么等效 opus Token 就是：1000万 × 0.12 × 1.20 + 200万 × 0.15 × 1.05，算下来大约是 175 万等效 opus Token。这样你就能把三个模型的消耗加总，得到一个可比较的总量。

注意：换算系数不是一成不变的，厂商调价、模型版本更新、你的业务数据分布变化，都会影响系数。建议每季度重新采样校准一次，别用一张表跑一年。

2.3 缓存命中率对成本的杠杆效应

opus 的缓存命中价格是未命中的十分之一，这个杠杆太大了，必须单独讲。我们有个项目线，把系统提示词和固定的知识库内容做了缓存，缓存命中率做到 78%，光这一项就把这个项目线的 opus 成本压下来 60% 多。

缓存怎么用才有效？核心是把不变的内容放在前面，变化的内容放在后面。opus 的缓存是按前缀匹配的，如果你的 prompt 结构是"系统提示 + 知识库 + 用户问题"，那么系统提示和知识库这部分只要不变，就能命中缓存。但如果你把用户问题放在前面，或者每次都在系统提示里插入时间戳，缓存就永远命中不了。

我们踩过的一个坑：早期为了做 A/B 测试，在系统提示里加了个实验组标识，结果每个实验组的缓存是独立的，命中率直接腰斩。后来改成把实验标识放到用户消息里，缓存命中率才恢复。

flash 和 qwen 也有类似的缓存机制，但命中条件和折扣力度不同。flash 的缓存折扣相对小一些，qwen 的缓存主要针对长文档场景。三个模型的缓存策略要分别配置，不能一套逻辑套用。

2.4 输出 Token 的预估与控制技巧

输出 Token 是成本的大头，尤其是 qwen，输出价格是输入的 3 到 4 倍。控制输出 Token 有几个实操技巧。

第一，明确指定输出格式和长度。在 prompt 里写清楚"用不超过 100 字回答"或"只输出 JSON，不要解释"，能显著减少废话输出。我们实测，加了长度约束后，平均输出 Token 降了 35%。

第二，用 stop 序列。如果输出有明确的结束标记，配置 stop 序列让模型提前停止，避免它继续生成无关内容。

第三，区分任务类型设置 max_tokens。分类任务给 50 就够，摘要给 300，代码生成给 2000，不要所有任务都用同一个大值。max_tokens 设太大，模型有时会"话痨"，输出一堆没用的内容。

第四，流式响应配合提前截断。对于流式输出，如果检测到已经拿到需要的信息，可以主动断开连接，省下后续的 Token。这个要小心用，别把有用内容截断了。

3. 按项目线拆账：成本归因的标签体系设计

3.1 成本归因的三个维度

成本归因不是简单记个总数，要能回答"钱花在哪了"。我们设计了三个归因维度，每个维度下再细分标签。

维度一：项目线。这是最粗的粒度，比如"搜索推荐""内容审核""智能客服"三条线。每条线独立核算，月底出账单时能直接看到哪条线超支。

维度二：功能模块。同一条项目线内部，不同功能的成本差异很大。比如智能客服里，"意图识别"走 flash 很便宜，"复杂问题推理"走 opus 很贵。按功能模块拆开，才能定位到具体的成本热点。

维度三：调用来源。区分是线上真实流量、离线批处理、还是开发测试。开发测试的调用如果不单独标记，很容易混进线上成本里，造成误判。我们有个月发现某项目线成本异常，查了半天发现是测试环境跑了个大规模评测，把线上账单污染了。

这三个维度组合起来，一个调用请求的标签就是"项目线-功能模块-调用来源"的三元组，比如"智能客服-复杂推理-线上"。

3.2 标签注入的实现方式

标签怎么注入到每次调用里？我们的做法是在统一网关层做，业务代码只需要在请求头里带上标签，网关负责解析、透传和记录。

具体实现上，网关接收请求时会读取三个自定义 header：X-Project-Line、X-Feature-Module、X-Call-Source。如果业务代码没带，网关会打上默认标签"unknown"，并在日志里告警，提醒开发补上。

这里有个设计取舍：标签是必填还是选填？我们一开始做成选填，结果大量调用没带标签，归因做不了。后来改成必填，网关对缺失标签的请求直接拒绝，强制业务方补齐。虽然上线初期有阵痛，但数据质量一下子就上来了。

标签的取值要有约束，不能随便填。我们维护了一个标签字典，每个维度下的合法取值是枚举的，网关会校验，非法值直接拒绝。这样避免了"智能客服""智能客服线""客服"这种同义不同写的混乱。

3.3 账单聚合与分摊逻辑

有了标签，账单聚合就简单了。每次调用结束后，网关记录一条明细：时间戳、标签三元组、模型名、输入 Token 数、输出 Token 数、缓存命中 Token 数、折算后的等效 opus Token 数、实际费用。

月底聚合时，按标签三元组 group by，把等效 Token 数和实际费用分别求和，就能得到每个组合的成本。再往上卷，按项目线汇总、按功能模块汇总，都是简单的聚合操作。

有个细节要注意：共享资源的成本怎么分摊。比如网关本身的计算资源、日志存储、监控告警，这些是三个项目线共用的。我们的做法是按各项目线的调用量比例分摊，调用量大的多摊一点。这个分摊比例每月重算一次。

还有个坑：跨月调用的归属。一个请求如果 23:59 发起，00:01 结束，算哪个月的？我们按请求发起时间归属，简单清晰，避免了对账时的扯皮。

3.4 成本异常告警的阈值设置

光有账单还不够，要能及时发现异常。我们设了三层告警。

第一层是日环比告警。某项目线当天成本比前一天涨了 50% 以上，触发告警。这个能抓到突发的大流量或死循环调用。

第二层是单次调用成本告警。单次调用的等效 Token 数超过阈值（比如 5 万），触发告警。这个能抓到异常长的 prompt 或失控的输出。

第三层是预算告警。每个项目线设月度预算，用到 80% 时预警，100% 时告警并可选自动降级到便宜模型。

阈值怎么定？别拍脑袋。先跑两周收集基线数据，算出各指标的 P50、P95、P99，告警阈值设在 P99 之上一点。这样既不会天天误报，又能抓到真正的异常。

4. 统一网关路由配置：一份可复现的方案

4.1 网关的核心职责与架构选型

统一网关要干四件事：路由（决定请求发给哪个模型）、鉴权（校验调用方身份）、限流（保护后端和自身）、可观测（记录明细、打标签、上报指标）。

架构选型上，我们用的是"轻量网关 + 配置中心"的组合。网关本身是个无状态服务，可以水平扩展；路由规则、限流阈值、标签字典这些配置放在配置中心，支持热更新，改规则不用重启网关。

为什么不用现成的 API 网关产品？我们评估过，通用网关对多模型路由的支持不够灵活，尤其是按 Token 数、按内容特征做路由这种需求，通用网关要么不支持，要么要写一堆插件。自己写一个轻量网关，核心逻辑两三千行代码，反而更可控。

网关的技术栈选择上，关键是并发处理能力和流式转发支持。因为大模型调用很多是流式的，网关要能透传 SSE 流，不能把流缓冲成完整响应再转发，那样延迟会爆炸。我们用的是支持异步 IO 的框架，单实例能扛住几千并发连接。

4.2 路由规则的配置模板

路由规则是网关的核心。我们的规则配置是一组有序的匹配条件，从上往下匹配，命中第一条就停止。配置格式大致如下：

routes: - name: "complex-reasoning-to-opus" match: project_line: ["intelligent-customer-service", "content-analysis"] feature_module: ["complex-reasoning", "long-doc-analysis"] input_token_range: [500, 100000] target: "claude-opus-5.5" fallback: ["qwen3.8-max-0902"] timeout_ms: 60000 - name: "high-throughput-to-flash" match: project_line: ["search-recommend", "content-moderation"] feature_module: ["classification", "intent-recognition"] target: "gemini-3.8-flash" fallback: ["qwen3.8-max-0902"] timeout_ms: 10000 - name: "chinese-nlp-to-qwen" match: project_line: ["*"] feature_module: ["chinese-extraction", "structured-output"] target: "qwen3.8-max-0902" fallback: ["gemini-3.8-flash"] timeout_ms: 30000 - name: "default-route" match: project_line: ["*"] target: "gemini-3.8-flash" fallback: ["qwen3.8-max-0902"] timeout_ms: 15000

这份配置有几个设计要点。第一，规则有序，具体的规则放前面，兜底的 default 放最后。第二，支持通配符，project_line: ["*"]表示匹配所有项目线。第三，每条规则都有 fallback，主模型失败时自动切到备用模型。第四，超时时间按模型特性设置，opus 慢，给 60 秒；flash 快，给 10 秒就够。

路由匹配的字段除了上面这些，还可以加内容特征匹配，比如检测到 prompt 里包含代码块就走 opus，包含中文占比超过 70% 就走 qwen。这个需要网关做轻量的内容分析，会增加一点延迟，但路由更精准。

4.3 限流与降级的联动策略

限流和降级要联动设计，不能各管各的。我们的策略是：先限流，限不住再降级，降级还不行才拒绝。

限流分两层。第一层是调用方限流，每个项目线有独立的 QPS 配额，防止某个项目线把网关打满。第二层是模型侧限流，每个模型有独立的并发上限，防止把某个模型的配额用超。两层限流都通过令牌桶实现，桶的大小和补充速率可配置。

降级策略是这样的：当某个模型的错误率超过阈值（比如 5%）或 P95 延迟超过阈值，网关自动把该模型的流量切到 fallback 模型。降级是自动的，但恢复要人工确认，避免模型刚恢复就被打满又挂掉。

降级时有个细节：不是所有请求都能降级。有些任务对模型有强依赖，比如需要 opus 的长上下文能力，降到 flash 会直接失败。我们在标签里加了个degradable字段，标记这个请求是否允许降级。不允许降级的请求，模型挂了就直接返回错误，让业务方自己处理。

4.4 可观测性埋点与日志规范

网关的日志要能支撑成本归因和问题排查，所以埋点要全。每次调用记录这些字段：

这些字段写入日志后，通过日志采集管道进到时序数据库，支撑实时监控和离线分析。日志保留策略上，明细日志保留 30 天，聚合后的成本数据保留 2 年，满足对账和审计需求。

提示：日志里不要记录完整的 prompt 和响应内容，只记 Token 数和元数据。完整内容涉及数据隐私，而且日志量会爆炸。需要排查具体内容时，用 trace_id 去业务侧的日志里查。

5. 实操踩坑与排查技巧实录

5.1 Token 计数不一致的排查

最常见的坑是网关记录的 Token 数和厂商账单对不上。我们遇到过好几次，差异从 5% 到 20% 不等。排查下来有几个原因。

原因一：分词器版本不一致。厂商的分词器会更新，你本地用的分词库版本和线上不一致，算出来的 Token 数就有偏差。解决办法是定期同步分词库版本，或者直接用厂商提供的在线计数接口。

原因二：特殊字符和格式的处理差异。比如换行符、制表符、特殊 Unicode 字符，不同分词器的处理方式不同。我们有个场景，prompt 里包含大量表格数据，用制表符分隔，结果本地计数和厂商计数差了 12%。后来改成用逗号分隔，差异就降到 2% 以内。

原因三：流式响应的 Token 统计时机。流式响应是边生成边返回的，如果你在流结束前就统计 Token，会少算。要等流完全结束，拿到最终的 usage 字段再统计。

排查方法：拿一批固定的测试数据，同时用本地计数和厂商接口计数，对比差异。差异超过 5% 的样本，逐条分析原因。

5.2 路由错配导致成本飙升的案例

我们踩过一个典型的坑：路由规则写错，把本该走 flash 的批量任务路由到了 opus。那个月这条项目线的成本涨了 8 倍，直到月底出账单才发现。

问题出在路由规则的匹配顺序上。我们新加了一条规则，匹配条件是feature_module: ["batch-*"]，本意是匹配所有 batch 开头的功能模块。但这条规则被放在了 flash 规则的前面，而 batch 任务里有一部分功能模块名恰好也匹配了这条规则，就被路由到了 opus。

修复方法有两个：一是调整规则顺序，把更具体的规则放前面；二是加实时成本监控，单次调用成本超过阈值就告警。我们现在两个都做了，规则顺序定期 review，成本告警实时盯着。

这个坑的教训是：路由规则改动必须走 review，不能随手改。而且改完要做回归测试，拿历史流量回放一遍，确认路由结果符合预期。

5.3 缓存命中率低的常见原因

缓存命中率低，成本就下不来。我们排查过几种典型情况。

情况一：prompt 里有动态内容。最常见的是时间戳、随机 ID、用户 ID 这些每次都变的内容。解决办法是把动态内容挪到 prompt 末尾，让前面的固定部分能命中缓存。

情况二：prompt 结构不稳定。比如系统提示词有时带标点有时不带，有时多一个空格，这些细微差异都会导致缓存不命中。解决办法是把系统提示词模板化，用固定的字符串常量，不要动态拼接。

情况三：缓存过期时间设置太短。厂商的缓存有 TTL，过期就失效。如果你的调用频率低，两次调用间隔超过了 TTL，缓存就命不中。解决办法是评估调用频率，调整缓存策略，或者把低频调用的内容合并处理。

排查缓存问题，最直接的方法是看厂商返回的 usage 字段里的缓存命中数。如果命中数长期为 0，那就是缓存根本没生效，要检查 prompt 结构。

5.4 多模型输出格式不一致的兼容处理

三个模型的输出格式有差异，尤其是 JSON 输出。opus 的 JSON 比较规范，flash 有时会加 markdown 代码块包裹，qwen 偶尔会在 JSON 前后加解释文字。

兼容处理有几个层次。第一层是 prompt 约束，明确要求"只输出 JSON，不要任何其他内容"。第二层是网关侧清洗，用正则把 markdown 代码块标记去掉，把 JSON 前后的非 JSON 内容截掉。第三层是业务侧容错，解析失败时走重试或降级。

我们现在的做法是三层都做。prompt 约束能解决 80% 的问题，网关清洗解决 15%，剩下 5% 靠业务侧容错。这样整体成功率能到 99.9% 以上。

清洗逻辑要小心，别把合法的 JSON 内容误删了。比如 JSON 字符串里如果包含 ``` 这样的字符，简单的正则替换会出错。要用 JSON 解析器做校验，解析成功才认为清洗正确。

5.5 常见问题速查表

这张表是我们大半年踩坑的浓缩，建议打印出来贴在工位上，遇到问题先查表，能省不少时间。

6. 成本优化的进阶思路

6.1 按任务难度动态选模型

固定路由是基础，进阶玩法是按任务难度动态选模型。同一个功能模块，简单任务走 flash，复杂任务走 opus，这样能在保证质量的前提下进一步压成本。

怎么判断任务难度？我们用了几个信号：输入长度（超过 2000 Token 的走 opus）、是否包含代码块（包含的走 opus）、历史成功率（某类任务在 flash 上成功率低于 90% 的走 opus）、用户等级（高价值用户走 opus）。

这套动态路由上线后，整体成本又降了 22%，而质量指标基本没变。关键是难度判断的规则要持续调优，我们每周 review 一次路由效果，根据实际数据调整阈值。

6.2 批量任务的错峰调度

批量任务对延迟不敏感，可以错峰调度，利用厂商的闲时折扣。我们观察到，某些模型在特定时段有价格优惠，把批量任务挪到这些时段跑，能省 30% 到 50%。

错峰调度的实现是在网关加一个调度层，批量任务不立即执行，而是进队列，等到优惠时段再出队执行。队列要有优先级，紧急任务插队，普通任务排队。

这个方案的前提是你的批量任务能接受延迟。如果业务要求实时出结果，那就用不了。我们只对离线评测、数据标注这类任务做了错峰，线上实时任务还是即时执行。

6.3 输出压缩与后处理

输出 Token 是成本大头，压缩输出能直接省钱。除了前面说的长度约束和 stop 序列，还有几个技巧。

用缩写和符号代替长文本。比如让模型输出"是/否"而不是"是的，这个问题的答案是肯定的"。在 prompt 里定义好缩写规则，模型会遵循。

结构化输出代替自然语言。需要多个字段时，让模型输出 JSON 或 CSV，比让它写一段话再解析要省 Token。

后处理补全。有些固定内容不用模型生成，让模型输出占位符，后处理时替换。比如模板化的开头结尾，模型只输出中间的变化部分。

这些技巧组合起来，我们的平均输出 Token 降了 40% 多，而且输出质量没受影响，因为省掉的都是冗余内容。

6.4 定期成本复盘的方法论

成本优化不是一次性的，要定期复盘。我们的复盘节奏是周看趋势、月做归因、季调策略。

周看趋势：每周一看上周的成本曲线，看有没有异常波动，有的话当天排查。

月做归因：每月初出上月账单，按项目线、功能模块、调用来源三个维度拆解，找出成本热点和优化空间。

季调策略：每季度重新评估路由规则、换算系数、限流阈值，根据业务变化调整。同时重新采样校准 Token 换算表。

复盘要有产出，每次复盘至少定一两个优化动作，下个周期验证效果。没有产出的复盘就是走过场，浪费时间。

7. 一些实操中的个人体会

这套方案跑了大半年，最大的体会是：多模型混跑的成本控制，核心不在模型本身，而在网关和归因体系。模型选型只决定了单价，网关的路由策略和归因的精细度才决定了你实际花多少钱。

另一个体会是：别追求一步到位。我们一开始想做个完美的动态路由，结果规则太复杂，维护成本高，还容易出错。后来退回到"固定路由 + 少量动态规则"，反而更稳。先把基础的路由、限流、归因做扎实，再逐步加动态能力。

还有个细节值得说：标签体系一定要在项目初期就定好。我们有个项目线是中途接入的，标签体系没对齐，导致前两个月的成本数据没法归因，只能估算。后来统一了标签字典，数据才干净。所以如果你正准备做多模型混跑，第一件事就是把标签体系设计好，别等出了问题再补。

最后分享一个小技巧：给每个模型设一个"成本预算"，超了就自动降级。这个比事后看账单有用得多，能在成本失控前就刹住车。预算怎么定？按项目线的历史成本和业务预期来，留 20% 的缓冲。超预算降级会有质量损失，但总比账单爆炸好，而且降级本身也是个信号，提醒你该优化了。