1. 多模型接入后的真实困境统一 API 为什么不够用很多团队在早期接入大模型时都会经历一个非常相似的阶段先接一家模型服务商跑通业务然后随着业务场景变多开始陆续接入第二家、第三家。为了不让业务代码里到处散落着不同厂商的 SDK 和鉴权逻辑大家很自然地会想到做一层统一 API 网关把所有模型调用收敛到一个入口。这个思路本身没错我自己也是这么干的。但真正上线跑一段时间之后问题就冒出来了统一 API 解决了“调用入口”的问题却没有解决“调用质量”的问题。业务方反馈说同一个接口有时候快有时候慢有时候答得好有时候答得离谱出了故障排查半天定位不到是哪一层的问题账单月底一看比预期高出一大截却说不清楚钱花在了哪个模型、哪个业务、哪个调用方身上。这些问题的根源在于统一 API 只做了协议适配和鉴权收敛它把不同厂商的差异抹平成了一个函数签名但模型服务本身的差异——延迟特征、上下文窗口、计费方式、限流策略、输出稳定性、故障模式——一个都没有被真正管理起来。换句话说统一 API 是一张“入口的门”但门后面的路怎么走、走哪条、堵了怎么办它一概不管。这篇文章想聊的就是这件事当企业接入多个模型之后为什么光有一个统一 API 远远不够以及在此之上还需要补哪些能力。我会从路由策略、模型服务层设计、可观测性建设、成本与配额治理几个角度展开把踩过的坑和验证过的方案都摊开讲。适合正在做多模型接入的架构师、后端工程师也适合负责 AI 平台建设的技术管理者参考。2. 统一 API 到底解决了什么又漏掉了什么2.1 统一 API 的价值边界在哪里先把话说清楚统一 API 不是没用它的价值非常明确。最直接的一点是鉴权收敛。如果业务代码直接持有各家厂商的 API Key那么密钥管理就是一场灾难轮换困难、泄露风险高、权限无法细分。统一 API 把密钥收拢到服务端业务方只拿一个内部凭证这是最基本也是最重要的收益。第二点是协议适配。不同厂商的接口格式、参数命名、返回结构都不一样有的用messages数组有的用prompt字符串有的流式返回格式是 SSE有的是自定义分块。统一 API 把这些差异封装掉业务方用同一套请求格式调用所有模型切换模型时业务代码几乎不用改。第三点是基础限流和配额。在网关层做一层调用频率限制防止某个业务方把额度打满影响其他人这也是统一 API 的常见职责。但问题在于很多团队做到这一步就停了以为“统一”就等于“治理”。实际上上面这三件事只覆盖了调用链最外层的一小部分。真正决定多模型系统好不好用的是入口之后的那一整套调度和观测能力。2.2 被忽略的四个核心缺口我把实际运行中暴露出来的缺口归纳成四类每一类都对应着统一 API 无法覆盖的领域。第一类是路由决策的缺失。统一 API 通常只提供一个“模型名”参数业务方指定用哪个模型网关就转发到哪个模型。但业务方凭什么知道该用哪个同一个问答场景简单问题用便宜的小模型就够了复杂推理才需要上大模型高峰期应该优先保延迟低峰期可以优先保质量。这些决策逻辑如果全压在业务方身上每个业务团队都要重复实现一遍而且很难随全局状态动态调整。第二类是模型服务层的缺失。统一 API 把模型当成一个黑盒的 HTTP 端点但模型服务本身是有状态的、会波动的。某个厂商突然限流、某个区域网络抖动、某个模型版本悄悄更新导致输出风格变化这些都需要在服务层做健康检查、熔断降级、重试策略。没有这一层一个厂商的抖动会直接穿透到业务。第三类是可观测性的缺失。统一 API 通常只记录“请求进来了、响应回去了”但中间发生了什么完全是个黑盒。延迟花在了排队还是推理Token 消耗是输入多还是输出多失败是因为限流、超时还是内容审核没有这些维度故障排查基本靠猜成本优化也无从下手。第四类是成本与配额治理的缺失。多模型意味着多套计费方式有的按 Token 计费有的按调用次数有的有免费额度有的没有。统一 API 如果不做成本归因月底账单就是一笔糊涂账更别提做预算控制和成本优化了。提示如果你的统一 API 目前只做了鉴权和协议适配那么它本质上只是一个“反向代理”距离真正的模型服务层还有相当距离。3. 路由策略从“业务方指定”到“系统智能决策”3.1 为什么路由不能交给业务方我见过不少团队的做法是在统一 API 的请求参数里加一个model字段业务方自己填。短期看没问题长期看会积累出一堆麻烦。首先是认知负担。业务开发同学要记住哪个模型擅长什么、哪个便宜、哪个快、哪个上下文长这本身就是一件反直觉的事。模型迭代速度这么快今天的最优选择下个月可能就变了让业务方跟着更新是不现实的。其次是全局视角缺失。业务方只能看到自己的请求看不到全局的负载情况。如果所有业务都往同一个模型打那个模型限流了大家都受影响。而实际上系统里可能有另一个模型此时负载很低完全可以分流过去。最后是策略无法统一演进。路由策略应该是一个可以集中调整、灰度发布、快速回滚的东西。散落在各个业务代码里改一次策略要协调多个团队根本快不起来。3.2 分层路由策略的设计思路我的做法是把路由拆成三层从粗到细逐层决策。第一层是静态路由按业务场景绑定模型池。比如客服问答场景绑定一组“高性价比”模型代码生成场景绑定一组“强推理”模型。这一层解决的是“这个业务大概该用什么档次模型”的问题相对稳定变更频率低。第二层是动态路由按请求特征在模型池内选择。这一层看的是单次请求的具体特征输入 Token 长度、是否包含复杂推理需求、是否需要长上下文、当前各模型池的健康状态和负载。比如输入很短且问题简单就选池子里最便宜的那个输入很长接近上下文上限就选支持长上下文的那个。第三层是兜底路由处理异常和降级。当首选模型不可用时按预设的降级链依次尝试备选模型。降级链的顺序要考虑模型能力的接近程度不能从最强模型直接降到一个完全不能用的模型那样用户体验会断崖式下跌。下面这张表是我在实际项目中用过的一个路由决策参考把请求特征和模型选择对应起来请求特征优先考虑备选策略说明输入短、问题简单小参数模型中等模型成本优先延迟也低输入长、需要长上下文长上下文模型分段处理注意上下文窗口上限需要复杂推理强推理模型强推理备选质量优先可接受高延迟高峰期高并发负载低的模型池排队限流保整体可用性低峰期非实时任务便宜模型批量处理成本优先延迟不敏感3.3 路由策略落地时的几个关键参数路由策略听起来简单落地时有一堆参数要调。我挑几个最关键的讲。健康检查阈值。每个模型端点都要有健康检查连续失败多少次标记为不健康、不健康状态持续多久后重新探测这两个参数直接决定了故障切换的灵敏度。设得太敏感会频繁误切换设得太迟钝故障影响面就大。我的经验是连续失败 3 次标记不健康30 秒后放一个探测请求试探。延迟阈值。动态路由需要知道每个模型当前的延迟水平。通常用滑动窗口统计最近 N 次请求的 P95 延迟超过阈值就降低该模型的优先级。窗口大小建议取 100 到 200 次请求太小波动大太大反应慢。权重分配。同一个模型池内的多个模型可以按权重分配流量。权重可以基于成本、延迟、质量综合计算。我一般给新接入的模型一个较小的初始权重观察一段时间稳定后再逐步提升。注意路由策略一定要有“可解释性”。每次路由决策最好能记录下为什么选了这个模型否则出了问题根本没法复盘。4. 模型服务层把模型当成有状态的服务来管4.1 模型服务层和统一 API 的本质区别统一 API 把模型当成一个无状态的 HTTP 端点请求进去、响应出来中间不管。模型服务层则把每个模型当成一个有状态、会波动、需要被持续管理的服务实例。这个区别体现在几个方面。统一 API 关心的是“请求能不能转发成功”模型服务层关心的是“这个模型当前的健康度、负载、延迟、成功率怎么样”。统一 API 是被动转发模型服务层是主动管理。举个具体的例子。某个模型厂商突然开始返回 429 限流错误统一 API 的做法是把错误原样透传给业务方业务方自己处理。模型服务层的做法是识别出这是限流触发熔断把流量切到备选模型同时后台持续探测原模型恢复情况恢复后逐步放量回来。业务方对此完全无感。4.2 熔断、降级、重试的正确姿势这三个词大家都会说但做对不容易。熔断的核心是状态机。关闭状态正常放行连续失败达到阈值进入打开状态直接拒绝打开状态持续一段时间后进入半开状态放少量请求试探试探成功则回到关闭失败则继续打开。这里的关键参数是失败阈值和打开持续时间前面提过不再重复。降级的核心是降级链的设计。降级不是随便找个模型顶上而是要保证降级后的输出质量在可接受范围内。我的做法是给每个模型标注能力标签降级时只在能力标签相近的模型之间切换。如果实在没有合适的备选宁可返回一个明确的“服务繁忙”提示也不要返回一个质量差到离谱的结果。重试的核心是区分可重试和不可重试的错误。超时、连接中断、5xx 这类错误可以重试参数错误、内容审核不通过、配额耗尽这类错误重试没有意义。而且重试要有退避策略不能立即重试否则会把已经过载的服务打得更惨。我一般用指数退避首次重试等 1 秒之后 2 秒、4 秒最多重试 3 次。# 重试策略的简化示意 RETRYABLE_ERRORS [timeout, connection_error, server_error] MAX_RETRIES 3 BASE_DELAY 1.0 def should_retry(error_type): return error_type in RETRYABLE_ERRORS def get_delay(attempt): return BASE_DELAY * (2 ** attempt)4.3 多模型场景下的连接池与并发管理多模型接入后连接管理会变得复杂。每个模型厂商的端点不同连接池要分开管理。如果所有模型共用一个连接池某个厂商的慢请求会把连接占满影响其他厂商的调用。我的做法是按模型厂商维度隔离连接池每个池子设置独立的超时和最大连接数。超时时间根据该厂商的历史延迟分布来定一般是 P99 延迟的 1.5 倍。最大连接数根据配额和并发需求来算避免把对方限流打满。另外要注意的是流式请求和非流式请求最好也分开管理。流式请求占用连接的时间长如果和非流式混在一起容易互相影响。5. 可观测性没有度量就没有优化5.1 多模型场景必须采集的指标维度可观测性这块我的观点是指标维度设计得好不好直接决定了你后面能不能做优化。维度太少出了问题定位不到维度太多存储和查询成本又扛不住。经过几轮调整我最终稳定下来的核心维度有这么几个模型厂商、模型名称、业务场景、调用方、请求类型流式/非流式、状态成功/失败/降级。这几个维度组合起来基本能覆盖绝大多数排查和优化需求。具体指标方面延迟要分 P50、P95、P99 三个分位光看平均值会被长尾掩盖。成功率要区分总成功率和各错误类型的占比限流失败和超时失败的处理方式完全不同。Token 消耗要分输入和输出因为很多厂商这两部分的计费单价不一样。指标类别具体指标采集粒度主要用途延迟P50/P95/P99按模型场景性能监控、路由决策成功率总成功率、错误分类按模型调用方故障排查、熔断触发Token输入/输出 Token 数按模型场景成本归因、配额管理流量QPS、并发数按模型调用方容量规划、限流调整质量重试率、降级率按模型场景质量评估、路由优化5.2 链路追踪在模型调用中的特殊处理常规的链路追踪在模型调用场景下有个特殊问题一次模型调用可能持续几秒甚至几十秒如果按常规方式埋点追踪数据会非常庞大。而且流式请求的“响应时间”到底怎么算也是个问题。我的处理方式是把一次模型调用拆成几个阶段分别埋点排队等待时间、连接建立时间、首 Token 时间、Token 生成时间、总时间。其中首 Token 时间对用户体验影响最大是重点监控对象。流式请求的总时间按最后一个 Token 到达时间算。另外模型调用的追踪数据里要带上路由决策信息也就是这次请求为什么选了这个模型。这样当用户反馈“这次回答特别慢”时你能快速定位到是路由选错了模型还是模型本身变慢了。5.3 从可观测数据到优化动作的闭环采集数据不是目的基于数据做优化才是。我一般会建立几个固定的分析视角。成本视角按业务场景和调用方看 Token 消耗和费用找出消耗大户评估是否有优化空间。很多时候会发现某个业务用大模型处理了大量简单请求换成小模型完全够用。性能视角按模型看延迟分布找出长尾严重的模型评估是否需要调整路由权重或增加备选。质量视角按模型看重试率和降级率重试率高说明模型不稳定降级率高说明主模型经常不可用都需要调整策略。异常视角按错误类型看趋势某类错误突然增多往往意味着上游有变化需要及时跟进。6. 成本与配额治理把账算清楚6.1 多模型计费的复杂性多模型接入后计费这件事会变得相当复杂。不同厂商的计费单位不同有的按 Token有的按调用次数有的按字符数。同一个厂商不同模型的单价也不同而且经常有阶梯定价和免费额度。更麻烦的是有些厂商的计费口径和实际返回的 Token 数对不上。比如你按返回的 usage 字段算出来是 1000 Token但账单上显示扣了 1200 Token多出来的可能是系统提示词或者格式开销。这种差异如果不处理成本核算就会有偏差。我的做法是建立一个统一的成本计算层把各厂商的计费规则抽象成配置每次调用后按配置计算成本同时记录厂商返回的 usage 数据定期对账发现偏差就调整计算规则。6.2 配额分配与超限处理配额治理的核心是“谁用得多、谁该被限制、限制到什么程度”。我的做法是分层配额调用方维度有总配额业务场景维度有子配额模型维度有独立配额。任何一层超限都会触发相应的处理。超限处理不能简单粗暴地直接拒绝那样用户体验太差。我一般分三档达到 80% 配额时告警提醒达到 100% 时降级到便宜模型达到 120% 时才开始拒绝。这样既给了缓冲又守住了成本底线。提示配额配置一定要支持动态调整而且调整要能快速生效。业务量波动是常态配额如果改起来很麻烦大家就会倾向于把配额设得很宽松配额就失去意义了。6.3 成本优化的几个实操方向成本优化这件事我总结下来有几个见效比较快的方向。第一是模型降配。把简单请求从大模型切到小模型这是最直接的成本节省。关键是判断哪些请求算“简单”可以用输入长度、问题类型、历史成功率等特征来综合判断。第二是缓存复用。相同或相似的请求结果可以缓存尤其是那些高频的、答案相对固定的查询。缓存命中率每提高 10%成本就能降不少。第三是提示词精简。系统提示词往往占了不少 Token精简提示词能在不影响效果的前提下降低成本。我见过一个案例把系统提示词从 500 Token 压到 200 Token效果几乎没变成本降了 15%。第四是批量处理。非实时任务可以攒一批一起处理有些厂商对批量调用有折扣。7. 常见问题与排查技巧实录7.1 多模型接入的典型故障速查现象可能原因排查方向处理建议某模型调用全部失败密钥失效或配额耗尽检查密钥状态和配额切换备选模型更新密钥延迟突然升高上游限流或网络抖动看 P95 延迟和错误率降低该模型权重分流输出质量下降模型版本更新对比历史输出固定模型版本或切换成本异常增长某业务调用量激增按调用方看 Token 消耗调整配额或优化提示词路由不生效策略配置未加载检查配置下发状态重新加载配置加日志7.2 几个容易踩的坑坑一把重试逻辑放在业务层。我见过有团队在业务代码里做重试结果不同业务的重试策略不一致有的重试 5 次把上游打挂了。重试应该统一在模型服务层做业务层只管调用。坑二健康检查太频繁。有的团队为了快速发现故障把健康检查间隔设得很短结果健康检查本身就成了负担还可能触发上游限流。健康检查间隔要合理一般 10 到 30 秒一次就够了。坑三忽略流式请求的特殊性。流式请求的超时判断和非流式完全不同。非流式看总时间流式要看首 Token 时间和 Token 间隔。如果按非流式的标准判断流式请求超时会误杀很多正常请求。坑四配额只做总量控制。只控制总量不控制增速会出现月初用光配额月底没得用的情况。配额要同时控制总量和速率。7.3 排查思路的通用框架遇到多模型相关的问题我一般按这个顺序排查先看是不是单个模型的问题如果是就查该模型的健康状态和上游状态如果不是单个模型的问题就看是不是路由层的问题检查路由策略和配置如果路由也没问题就看是不是调用方的问题检查请求参数和配额最后再看是不是全局性的问题比如网络或认证服务。这个顺序的逻辑是从局部到全局从具体到抽象能比较快地缩小问题范围。8. 写在最后的一些个人体会多模型接入这件事我最大的体会是统一 API 是起点不是终点。很多团队在统一 API 上投入了大量精力却忽略了它之上的路由、服务治理、可观测性和成本治理结果系统看起来能用但一遇到波动就手忙脚乱。另一个体会是这些能力不需要一次性全做完。我的建议是先做可观测性因为它是其他所有能力的基础。没有数据路由策略调不了成本优化无从下手故障排查全靠猜。可观测性做扎实了后面的路由和服务治理才有依据。最后分享一个小技巧路由策略和熔断策略的配置一定要支持热更新而且要有版本管理和回滚能力。我踩过一次坑改了一个路由权重导致某个模型流量暴涨被限流因为没有回滚机制只能手动改回来中间耽误了十几分钟。从那以后所有策略配置都走版本管理改错了能一键回滚。
