1. 从一张失控的账单说起多模型接入到底难在哪去年下半年我帮一家做智能客服的团队做技术复盘他们当时的状态很有代表性产品里同时接了四家不同厂商的大模型分别负责意图识别、知识问答、话术润色和情绪判断。听起来分工明确但财务拉出季度账单的时候所有人都愣住了——预算超了将近三倍而且没人说得清钱到底花在哪个环节。这不是个例。只要团队开始从单模型打天下转向多模型协作几乎都会撞上同一堵墙接入方式五花八门、计费口径各不相同、调用量像脱缰的野马。有人用官方 SDK有人直接裸写 HTTP 请求有人把密钥硬编码在配置文件里有的模型按输入输出分别计价有的按词元总量打包还有的按时长或图片张数算。等到月底对账财务拿着一堆格式不同的账单来找你你只能凭感觉说大概是问答那块用得多。所以这篇内容我想聊的不是要不要用多模型而是当多模型成为既定事实之后怎么用一个统一调度平台把接入、路由、预算这三件事一次性管住。核心关键词就几个多模型、统一调度平台、API、词元、预算。适合正在做 AI 应用落地的后端工程师、技术负责人以及被账单追着跑的团队管理者。哪怕你现在只接了一个模型只要业务在长这套思路迟早用得上。我下面讲的不是某个具体产品的说明书而是把这类平台该有的能力拆开讲清楚每一层为什么这么设计、实际落地时会踩什么坑。你可以把它当成一份选型与自建的对照清单。2. 统一调度平台到底统一了什么很多人对统一调度的理解停留在把多个 API 地址写在一个配置里这其实只做到了最表层。真正的统一调度平台要同时解决四个层面的问题协议统一、路由统一、计量统一、治理统一。少任何一层账单该失控还是失控。2.1 协议统一把 N 套接口收敛成 1 套不同厂商的 API 差异有多大接过的人都懂。请求体字段名不一样返回结构不一样流式输出的分片格式不一样错误码体系更是各说各话。你写一套业务代码为了适配四家模型可能要维护四套请求封装和四套解析逻辑。统一调度平台的第一件事就是在中间加一层协议适配层。对外只暴露一套标准接口现在业界比较通用的是兼容 OpenAI 风格的/v1/chat/completions这类结构对内把各家模型的请求参数、返回格式、流式协议做双向转换。举个具体的转换例子。假设标准接口里用max_tokens表示最大输出长度但某家厂商的字段叫max_output_tokens另一家叫max_new_tokens适配层就要做映射# 适配层伪代码把标准请求翻译成各家厂商的请求 FIELD_MAP { vendor_a: {max_tokens: max_output_tokens}, vendor_b: {max_tokens: max_new_tokens}, vendor_c: {max_tokens: max_tokens}, # 字段一致无需转换 } def adapt_request(vendor, standard_payload): mapping FIELD_MAP.get(vendor, {}) adapted {} for k, v in standard_payload.items(): adapted[mapping.get(k, k)] v return adapted这层看着简单但价值巨大业务代码只写一次换模型只改配置不改代码。我见过太多团队因为没做这层每次上新模型都要改一遍业务逻辑改完还要回归测试人力成本比模型调用费还高。提示协议适配层一定要做字段白名单而不是字段透传。透传会把业务侧不认识的参数原样发给厂商轻则报参数错误重则触发计费异常。白名单能保证只有明确支持的字段才被转发。2.2 路由统一让请求找到对的模型协议统一解决的是怎么调路由统一解决的是调哪个。这是多模型平台最有价值、也最容易被做歪的部分。最朴素的路由是写死映射意图识别走 A 模型问答走 B 模型。但业务一复杂就不够用了。真正实用的路由策略通常包含这几类路由策略适用场景关键考量按任务类型静态路由任务边界清晰、模型能力差异明确配置简单但不够灵活按成本优先级路由预算敏感、对质量要求分层需要维护模型单价表按负载均衡路由单模型有并发上限需要健康检查与熔断按降级链路由主模型不可用时自动切换要保证降级后输出格式一致按内容复杂度路由简单问题走小模型复杂问题走大模型需要复杂度判定逻辑我特别想强调降级链路由。多模型平台的一个隐藏价值就是容灾当主模型返回 5xx 或者超时平台可以自动把请求转到备用模型业务侧完全无感。但这里有个坑——不同模型的输出风格和格式可能不一致如果业务侧对输出做了严格解析降级后可能直接解析失败。所以降级链里的模型最好在输出格式上做过对齐或者平台层做一次格式归一化。2.3 计量统一把词元变成可对账的数字这是整篇文章的核心也是预算能不能管住的关键。词元token是模型计费的基本单位但不同厂商对词元的切分方式、计价方式都不一样。统一调度平台必须在每次调用后把用量数据标准化地记录下来。一次完整的调用至少要记录这些字段请求 ID、时间戳、调用方标识命中的模型与厂商输入词元数、输出词元数、总词元数本次调用的估算费用是否命中缓存、是否走了降级有了这些结构化数据你才能回答钱花在哪这个问题。我建议计量数据单独落一张表不要和业务日志混在一起因为它的查询模式完全不同——业务日志按请求查计量数据按时间、按调用方、按模型聚合查。-- 计量表的核心结构示意 CREATE TABLE token_usage ( id BIGINT PRIMARY KEY, request_id VARCHAR(64), caller_id VARCHAR(64), -- 哪个业务方调的 vendor VARCHAR(32), -- 厂商 model VARCHAR(64), -- 具体模型 input_tokens INT, output_tokens INT, total_tokens INT, cost_estimate DECIMAL(12,6), -- 估算费用 is_fallback TINYINT, -- 是否降级 created_at DATETIME );2.4 治理统一限流、配额、审计一个都不能少治理层是很多自建平台会忽略的部分。它包含限流防止某个业务方把额度打满、配额每个业务方每月能用多少词元、审计谁在什么时候调了什么。这三件事如果不在平台层做就得在每个业务方各做一遍重复且容易漏。限流和配额的区别要分清限流管的是瞬时并发比如每秒最多 50 次请求配额管的是周期总量比如每月最多 1000 万词元。前者防打爆后者防超支。两个都要有缺一个都会出问题。3. 词元计费的那些隐藏算法预算管不住很多时候不是平台没做计量而是计量口径和厂商账单对不上。这一节专门讲词元计费里那些容易被忽略的细节这些是我在实际对账中一点点抠出来的。3.1 输入和输出为什么要分开算几乎所有厂商都对输入词元和输出词元采用不同的单价而且输出通常比输入贵好几倍。原因在于推理过程输入是读输出是逐字生成后者的计算量随长度线性增长成本自然更高。这意味着一个反直觉的结论同样是一万词元的消耗全是输入和全是输出费用可能差三到五倍。所以做预算时不能只看总词元数必须拆开看输入输出比例。一个典型的问答场景如果知识库塞得很长输入大、回答很短输出小单位成本其实比短输入长输出的创作类场景低。平台在做费用估算时公式应该是费用 输入词元数 × 输入单价 输出词元数 × 输出单价而不是简单地用总词元数乘以一个平均单价。后者在输入输出比例波动大的场景下误差能到百分之几十。3.2 词元数到底怎么数才准这里有个大坑你不能用厂商返回的用量数据来做实时预算控制因为那是调用完成后才知道的。要做实时拦截必须在请求发出前就估算出词元数。估算方法通常是把输入文本按模型对应的分词规则切分统计词元数输出词元数则用max_tokens参数作为上限来预估。注意是上限预估因为实际输出可能远小于上限。这就带来一个矛盾按上限预估会高估成本按实际值又来不及拦截。我的做法是双轨制实时拦截用上限预估宁可拦错不可放过事后对账用厂商返回的真实值。两者之间的差额单独记录用来校准预估模型的准确度。跑一段时间后你会发现某个业务场景的预估/实际比值稳定在某个区间就可以用这个系数去修正预估让拦截更精准。# 预估与实际的校准逻辑示意 def estimate_cost(input_text, max_tokens, model): input_tokens count_tokens(input_text, model) # 用历史系数修正输出预估 ratio get_output_ratio(model, caller_id) # 历史实际/上限 est_output int(max_tokens * ratio) return input_tokens * PRICE[model][input] est_output * PRICE[model][output]3.3 缓存命中能省下的钱比你想的多多模型场景下很多请求其实是重复的——同样的系统提示词、同样的知识库片段、同样的常见问题。如果平台层做了提示词缓存把重复的输入前缀缓存起来命中后不计费或大幅折扣成本能降一大截。但缓存有个前提输入前缀必须完全一致。系统提示词里哪怕多一个空格、换一个标点缓存就失效了。所以平台要提供提示词模板能力把系统提示词固化下来业务侧只填变量部分这样缓存命中率才高。我实测过一个客服场景把系统提示词和知识库头部固定成模板后缓存命中率能到六成以上那部分输入词元的费用直接省掉。这个收益在长系统提示词的场景下尤其明显。3.4 多模态模型的计费口径完全不同现在多模态模型越来越多图片、音频、视频都能作为输入。但多模态的计费口径和纯文本完全不是一回事有的按图片张数算有的按图片分辨率折算成词元有的按音频时长算。平台在做多模态计量时必须为每种模态单独建计价规则。比如图片输入常见做法是按分辨率分档低分辨率图折算成固定词元数高分辨率图按实际切分后的词元数算。如果不做这层区分多模态场景的预算会彻底失控——一张高清图折算下来可能顶几千个文本词元。注意多模态请求在预估阶段很难精确算词元因为图片的实际切分依赖模型内部逻辑。稳妥做法是对多模态请求单独设一个更宽松的配额池避免它挤占文本业务的预算。4. 预算管控从事后惊讶到事前拦截前面讲的计量是看清楚钱花在哪这一节讲的是怎么让钱不超支。两者的关系是没有准确计量预算管控就是拍脑袋只有计量没有管控就永远在事后追悔。4.1 预算要分几层来设我见过最常见的错误是只设一个总预算。总预算超了才发现但已经晚了而且不知道是谁超的。合理的预算体系应该是分层的租户级预算整个平台每月的总盘子防止整体超支业务方级预算每个接入的业务线各自的额度谁用超谁负责模型级预算给贵模型单独设上限防止被滥用场景级预算关键场景如对外付费功能单独管控这四层是与的关系任何一层触顶都要触发拦截或告警。比如总预算还剩很多但某个业务方已经用完了自己的额度那这个业务方的请求就该被拦而不是让它继续消耗总盘子。4.2 拦截策略硬拦、软拦、告警怎么选预算触顶后的处理方式直接决定了用户体验和业务连续性。我一般建议分三档档位触发条件处理方式适用场景告警用量达 80%通知负责人不拦截所有场景默认开启软拦用量达 100%降级到便宜模型或返回缓存对可用性要求高的场景硬拦用量达 120%直接拒绝请求成本红线场景软拦是个很实用的中间态。比如某业务方额度用完了平台不直接拒绝而是把它的请求从贵模型降级到便宜模型保证功能可用但成本可控。等负责人充值或调整额度后再恢复。这样既守住了预算又不至于让业务直接挂掉。4.3 实时拦截的技术实现要点实时拦截的难点在于低延迟。每次请求都要查一次预算余额如果这个查询走数据库高并发下会成为瓶颈。我的做法是把预算余额放在内存缓存里比如 Redis每次调用做原子扣减扣减成功才放行。# 基于缓存的原子扣减示意 def check_and_deduct(caller_id, estimated_tokens): key fbudget:{caller_id}:{current_month()} # 原子操作先查余额够则扣减不够则返回失败 remaining redis.decrby(key, estimated_tokens) if remaining 0: redis.incrby(key, estimated_tokens) # 回滚 return False return True这里有个细节扣减用的是预估词元实际消耗可能更少。所以事后要用真实值做一次多退少补的对账把预扣和实扣的差额补回去。否则长期跑下来预扣会越来越保守业务方明明没超支却被拦住。4.4 预算和路由的联动预算管控做得好不好很大程度上看它和路由的联动。举个场景某业务方本月预算快用完了平台可以自动把它的路由策略从优先高质量模型切换成优先低成本模型让它用更少的钱撑到月底。这种动态调整比一刀切拦截优雅得多。实现上路由层每次决策前先查一下该业务方的预算水位水位高就走高质量链路水位低就走低成本链路。这个逻辑对业务侧完全透明业务方甚至感知不到自己的请求被降级了。5. 自建还是用现成平台一份务实的对照聊到这里很多人会问这套东西是自己搭还是用现成的我的答案是看团队规模和业务阶段没有标准答案但有几个判断维度可以帮你决策。5.1 自建平台的真实成本自建听起来自由但成本容易被低估。一个能用的多模型调度平台至少包含协议适配层、路由引擎、计量模块、预算模块、管理后台、监控告警。这些加起来一个熟练后端全职投入保守估计也要两三个月才能到能用的程度到好用还要再迭代。而且自建有个隐性成本厂商接口一变你得跟着改。模型厂商的 API 迭代很快字段增删、计费调整、新模型上线每一次都意味着适配层要动。这个维护成本是持续的不是一次性的。5.2 现成平台要重点看什么如果选现成平台别只看支持多少家模型这种宣传数字。真正要考察的是这几项计量精度能不能拆到输入输出分别计量能不能和厂商账单对上预算能力支不支持分层预算、实时拦截、软硬拦分级路由灵活性能不能自定义路由策略降级链怎么配数据归属计量数据能不能导出能不能自己二次分析协议兼容对外接口是不是标准风格迁移成本高不高其中计量精度是我最看重的。一个平台如果计量和厂商账单对不上那预算管控就是空中楼阁。选型时一定要拿真实调用跑一轮对账看误差在不在可接受范围。5.3 混合方案核心自建边缘用现成对多数中型团队我推荐混合方案计量和预算这两块核心能力自建因为涉及钱必须自己掌控协议适配和路由用现成组件这部分标准化程度高没必要重复造轮子。这样既保证了成本数据的自主可控又省去了大量适配工作。而且计量模块自建后你可以按自己的业务口径去定义什么算一次有效调用哪些场景不计入预算灵活性比全用现成平台高得多。6. 上线后最容易翻车的几个地方平台搭好只是开始真正的问题都在上线后暴露。这一节我列几个实际踩过的坑都是那种文档里不会写、但一定会遇到的类型。6.1 流式请求的计量时机流式输出streaming场景下词元是边生成边返回的。如果你等整个流结束才计量那中途断开的请求就没被记录长期下来会漏掉一部分用量。正确做法是在流结束时以最终统计为准同时对异常中断的流做兜底记录。更麻烦的是有些厂商的流式接口不返回用量统计你得自己数。这时候平台要能根据返回的文本反推词元数虽然不精确但比不记录强。6.2 重试导致的重复计费网络抖动时平台可能会自动重试。但重试意味着同一个请求可能被计费两次——第一次其实已经到达厂商并产生了消耗只是响应没回来。如果不做去重账单会虚高。解决办法是给每个逻辑请求分配一个唯一 ID重试时带上同一个 ID厂商侧如果支持幂等就能去重。如果厂商不支持平台侧要在计量时识别出这是重试只记一次或标记出来人工核对。6.3 超长上下文的词元爆炸现在很多模型支持超长上下文动辄几十万词元。这带来一个新问题一次请求就可能吃掉大量预算。如果业务侧不小心把整个文档塞进去单次调用成本可能顶平时几百次。平台必须对单次请求的词元数设上限超过就拒绝或要求拆分。这个上限要按业务场景分别设不能一刀切。比如摘要场景可以放宽实时对话场景要收紧。6.4 密钥轮换与权限隔离多模型平台往往集中管理所有厂商的密钥。一旦密钥泄露损失是所有接入业务的总和。所以密钥管理要做到加密存储、按业务方隔离、支持轮换、操作留痕。别把所有密钥放在一个明文配置文件里那是给自己埋雷。我建议每个业务方用独立的平台侧密钥平台再用自己的厂商密钥去调用。这样业务方拿不到厂商密钥泄露了也只影响自己那一份额度。7. 我个人的几点实操体会做这类平台这两年有几个体会是踩了坑才明白的。第一计量先行管控后置。别一上来就搞复杂的预算拦截先把计量做准。计量不准拦截就是瞎拦反而影响业务。我一般建议先跑一个月纯计量把数据摸清楚再上管控。第二预算要留缓冲。别把额度卡得死死的留 10% 到 20% 的缓冲空间。因为预估总有误差卡太死会导致正常业务被误拦体验很差。第三降级链要定期演练。很多团队配了降级链就再也不管了真到主模型挂了才发现降级模型早就下线了。建议每月做一次故障演练手动触发降级验证整条链路是否通畅。第四把成本数据开放给业务方。让每个业务方能看到自己用了多少、花了多少比平台单方面管控有效得多。人一旦看到自己的账单自然会优化调用方式。这比任何技术手段都管用。最后分享一个小技巧给每个业务方做一个成本看板实时显示本月用量、剩余额度、预估月底花费。这个看板不用多复杂一张折线图加几个数字就够。但它的心理约束作用非常强很多不必要的调用会因为看着数字涨而被主动砍掉。技术管不住的东西有时候靠透明就能管住。