多个 AI 模型怎么一起对外服务：推理路由、灰度发布与显存规划

需求场景：为什么旧模型不能一删了之

新模型要上线，又不敢直接替换旧模型，担心效果回退引发客诉，怎么做到一部分流量先试新模型。这是很多平台团队在迭代大模型或视觉模型时真实遇到的困境。直接全量切换的风险很直接：新模型在某些长尾输入上可能输出变差，或者首字延迟突然升高，一旦全量上线，影响面就是全部用户；而旧模型又不能一直保留两套独立环境，那样显存与机器成本翻倍，且两套环境的配置与状态难以保持一致。更麻烦的是，当对外同时提供多个尺寸或版本的模型时，比如一个大语言模型同时有七百亿参数版本和七十亿参数版本，或一个视觉模型同时有检测版与分割版，调用方只关心接口稳定与响应正确，并不关心背后跑的是哪个版本。于是问题收敛成三件具体的事：如何在同一套资源上让多个模型版本共存、如何把不同请求送到最合适的版本、如何在出问题时把流量秒级切回旧版本。把这三点想清楚，路由与灰度就不是抽象概念，而是一组可以落地的工程决策。

三套部署方案各自怎么落地

把多模型对外服务这件事拆开看，工程上常见三种结构。它们不是互相替代的关系，而是按团队规模、模型数量与隔离要求逐步演进的台阶。

方案一：单实例单模型，版本各占一套环境

最朴素的做法是每个模型版本各自独占一组实例。推理引擎进程只加载一个模型权重，对外暴露一个固定服务地址，两套版本之间在进程或物理层面完全隔离。它的优势是简单、可预测、故障域小，任何一个版本出问题都不会波及另一个版本，调试和归因也最省心。代价同样明显：显存利用率偏低，尤其在请求量波动时，单个模型如果没有跑满，空闲显存无法被其他版本复用，资源浪费非常直观。灰度只能靠上游或前端把流量按比例打到两套独立地址，路由逻辑分散在多个调用方手里，难以统一管理；回滚时也要逐个调用方改配置，节奏不一致，容易漏改。当模型版本数量从两个涨到十个时，这种每版一套环境的模式会让机器数量和运维台账同步膨胀，最终难以为继。

方案二：单实例多模型，由推理引擎内部路由

第二种做法在同一推理实例里加载多个模型版本，由实例内置的路由层根据请求携带的模型标识或元数据决定调用哪个版本。典型的实现是推理服务支持模型仓库与版本号，同一个服务端口后面挂多个版本，请求里带上版本字段即可命中对应权重。显存上多个版本权重同时驻留显存，这就要求做显存隔离，避免某个版本在突发请求下把整张卡的显存吃满，连带把同卡的其他版本拖垮，出现互相影响的 OOM。这种结构的路由灵活度高于方案一，灰度可以在实例内部通过权重配置完成，但路由能力受限于单一推理框架，跨框架、跨机房的统一分流策略很难落地。另一个隐患是实例本身变成更大的故障域：它一旦宕机，挂在下面的所有版本一起不可用，而不是只影响一个版本。

方案三：网关统一路由，把分流从引擎里抽出来

第三种做法把路由从推理引擎里抽出来，放到独立的模型网关层。网关只负责请求鉴别、鉴权、模型版本选择、流量比例分配与回滚切换，后端则连接多组推理实例，这些实例可以运行不同框架、分布在不同机房。这里的关键收益是路由层与推理引擎解耦：推理引擎只管把模型跑起来，灰度比例、版本映射、A/B 分组全部写在网关配置里，因此可以独立灰度——修改路由规则不需要重新部署模型，也不需要重启推理实例。这正好回应开篇的困境：新模型先在网关里配置百分之五的流量，观察指标，再逐步放量；一旦指标异常，把比例改回零即可，整个过程不涉及模型重新加载。对于需要同时对外提供十几个模型版本的产品团队，网关层几乎是绕不开的一层。

三套方案关键参数差异对比

成本差异怎么算才贴近业务

三套方案的成本不能只看服务器租金，因为显存是否被复用、实例是否被跑满，会极大改变单位请求的真实开销。一个常见的误区是用 GPU 卡时去衡量多模型服务的成本：卡时只反映机器被占用多久，却掩盖了同一张卡上大半个显存长期空闲的事实。更贴近业务的方式是按 token 或按请求维度拆解——把一次推理请求对应的显存占用时长、算力消耗与调用次数摊到单价上，才能得到每次调用的真实成本。模型尺寸差异越大，这种算法与卡时算法的差距越明显：一个大模型和一个小模型共用网关时，如果仍按卡时平摊，小模型调用方会被严重高估成本。在规划预算时，一万网络的一体化机柜与带宽交付能让按流量调度实例的方式更可控，具体机型、显存规格与带宽报价以官网实时或咨询确认为准。把成本模型从卡时切换到 token 或请求维度，也是后面做灰度收益评估的前提：只有先算清每个版本的边际成本，才能判断灰度放量到底有没有省到钱。

灰度发布怎么做才不打扰用户

灰度发布的本质是把风险控制在小范围内再逐步放大，落到多模型网关上，通常按这样的节奏推进：新模型先作为小流量版本接入网关，比例设为零或个位数百分比，让它承接极少数请求，验证基本可用性与延迟分布；随后在网关配置里写入流量比例，把特定用户群、特定地域或特定接口路径的流量按权重分给新版本，这一动作完全在路由配置里完成，不需要动模型权重；与此同时对照旧版本建立对比指标，包括首字延迟、输出长度分布、错误率与业务侧的质量评估，而不是只看服务是否存活；确认平稳后再按阶梯逐步放量，比如从百分之五到百分之二十再到百分之五十，每一档都留出足够观察窗口；指标稳定后切到全量，并把旧版本保留为可一键回退的备用版本，而不是立刻下线。整个过程的关键是把灰度动作收敛成几次配置变更，避免每次放量都重新构建和部署模型。

版本回滚机制：配置化才是正解

很多团队把回滚想成重新部署旧模型，这恰恰是故障发生时最慢的一条路。正确的思路是让模型版本与路由规则都可配置化，回滚只是把网关里的版本映射和流量比例改回旧值。把模型权重作为不可变版本存放在模型仓库里，每个版本有唯一标识；网关持有当前生效的版本映射表，回滚时只需把映射表切回上一个已知良好版本，流量在秒级内回到旧模型，推理实例无需重启、权重无需重新加载。这要求两件事提前到位：其一，模型仓库必须保留历史版本，而不是每次发布覆盖；其二，路由规则要纳入配置版本管理，每一次变更可追溯、可回退。这样即便新版本在灰度中途暴露出长尾问题，运营侧也能在不打扰用户的前提下把影响面瞬间收口。把回滚从一次部署动作降级为一次配置切换，是多模型服务能否做到高可用的分水岭。

灰度与 A/B 测试的边界在哪里

很多人把灰度和 A/B 测试混为一谈，两者目标不同，落地方式也不同。灰度更关心风险可控，核心问题是新版本有没有变坏，只要不回退就继续放量，对比通常只针对新旧两个版本，结论是非此即彼的发布决策。A/B 测试更关心择优，核心问题是哪个版本在业务指标上更好，往往同时跑多个候选版本，对比维度更宽，结论用于选优而非单纯避险。落到多模型网关，区别直接体现在路由配置上：灰度是一份版本映射加一个递增比例，目标是把坏版本挡在门外；A/B 是多份版本加按用户或请求特征的分组，目标是收集可比数据。同一个网关可以同时支撑两者，但不要把它们写进同一套规则里——灰度的止损逻辑是异常即回退，A/B 的止损逻辑是数据不显著就延长观察，混在一起会让自动化策略互相打架。把边界划清，路由配置才不会因为语义冲突而失灵，团队也才说得清某次放量到底是在避险还是在选优。

日常运维要点

多模型路由与灰度上线之后，运维重心会从单机健康转向全局水位与配置治理。显存水位是首要关口，同卡多模型尤其要盯住每张卡的实际占用峰值，给突发请求预留缓冲，否则一个版本的瞬时高峰会触发整卡 OOM，连累同卡其他版本。冷启动要提前预热，新版本首次加载权重和编译计算图都有耗时，建议在网关把流量调起来之前先做一次 warm-up，让首请求的延迟不被用户感知。版本清单要可审计，谁在什么时候上线了哪个版本、当前网关生效的是哪一份映射，都应该有记录可查。配置变更要走版本化流程，灰度比例、路由规则的每次修改都要有留痕，出了问题能立刻定位是哪一次变更引入。最后是效果监控要和业务对齐，延迟、错误率之外，还要把模型输出质量指标回流到灰度评估里，否则灰度只会验证服务活着，却验证不了模型变好还是变差。

显存规划：每张卡到底能放几个模型版本

规划显存要把占用拆成三块分别估算，而不是只盯模型文件大小。权重本身是其中占比最直观的一块，它和参数量、加载精度直接相关，以公开常见的规格做估算，一个七百亿参数模型用十六位浮点加载大约需要一百四十 GB 显存，单张八十 GB 的卡放不下，必须跨多张卡做张量并行；而一个七十亿参数模型同样精度下大约十四 GB，可以轻松放进二十四 GB 的卡并留出富余。另一块是键值缓存，它随上下文长度和并发数线性增长，长文本或高并发场景下单次请求的键值缓存可能比权重还吃显存，这也是同卡多模型必须给每个版本设占用上限的根本原因。还有一块是激活值与临时缓冲，在推理瞬间占用，峰值出现在批处理最大的时候。做规划时建议先按最大并发与最长上下文算出键值缓存峰值，再叠加权重，得到的总需求再去匹配显卡显存容量，例如八十 GB、一百四十一 GB 这类公开规格，并主动留出百分之十到二十的余量应对突发。把显存算清楚，路由与灰度的容量上限才有依据，否则放量到一半发现某张卡放不下新版本，灰度就会卡在半路，被迫临时扩容。

模型版本清单与发布纪律

多模型服务跑久了，真正消耗人力的不是推理本身，而是版本越来越多之后谁也说不清线上到底跑了哪些版本。建立一份始终准确的版本清单是首要一条纪律：每个模型版本都要有唯一标识、对应权重来源、上线时间与责任人，网关当前生效的映射要能在一处查到，而不是散落在多台机器的配置文件里。另一条纪律是不可变版本，权重入库后不覆盖、不就地修改，新版本走新标识，旧版本留在仓库里随时可切回，这直接支撑了前面说的配置化回滚。再一条纪律是变更留痕，灰度比例、路由规则、版本映射的每一次修改都要记录操作人与时间，出问题能立刻定位是哪一次变更引入。最后一条纪律是定期清理，长期零流量且不在回滚范围内的版本要从网关摘除，避免清单无限膨胀拖慢路由查找。这几条看上去琐碎，却是多模型服务从能用到好用的分水岭，版本数一旦超过十个，没有纪律的团队会频繁出现切错版本、回错版本的低级事故。

常见问题解答

问：多个模型共用同一张卡的显存，怎么隔离才不会互相影响？

同卡多模型最怕的就是一个版本把显存吃满，连带其他版本一起 OOM。隔离可以从三个层面下手。显存层面，给每个加载的模型版本设置占用上限，推理框架大多支持限制单模型可申请的显存比例，超过就排队或拒绝，而不是无限扩张。调度层面，网关在分配请求时要感知后端每张卡的实时水位，避免把突发流量集中打到已经吃紧的卡上。进程层面，关键版本可以放进独立的推理进程甚至独立的容器，用进程边界天然隔离显存与计算资源。三者结合，才能把同卡多模型的利用率优势保留下来，同时不让单点爆发拖垮整卡。需要提醒的是，隔离不是越细越好，隔离到进程级会损失一部分显存复用收益，要在利用率与稳定性之间按业务容忍度取平衡点。

问：路由到底按哪些维度把请求分给不同模型版本？

路由维度取决于你想用灰度解决什么问题。最常见的几个维度是用户维度，比如把内部员工或特定白名单用户先放进新版本，用来做真实但可控的试错；地域维度，按机房或区域切流，用来隔离不同市场的反馈；接口路径维度，把风险高的新功能接口先灰度，核心接口保持旧版本；以及请求特征维度，比如按输入长度或模态分流，长文本走更强的版本，短文本走轻量版本。网关的价值在于这些维度可以自由组合写进配置，而不是写死在代码里。需要避免的是维度叠加过多导致流量切分碎成无法观测的碎片，建议每次灰度只聚焦一到两个维度，放量过程中保持可解释，出了问题能立刻说清楚是哪一类请求被影响。

问：灰度比例按什么节奏往上加，有没有经验值？

灰度比例没有万能数值，但有一条通用原则：观察窗口要长于问题暴露周期。很多模型缺陷不是首请求就出现，而是特定长尾输入累积到一定量才显现，所以每一档放量都要留出足够的请求量去覆盖长尾，而不是只看几分钟的指标。常见节奏是从百分之五起步，指标平稳再跳到百分之二十、百分之五十，最后全量；风险高的模型可以把起步压到百分之一甚至更低。判断能不能加比例的不是时间到了，而是关键指标已经跨过观察阈值并持续平稳，包括延迟分位、错误率、以及业务侧的质量评估。一旦任一指标回退，就停在当档甚至回退，而不是机械地按时间表推进。把放量节奏和指标绑定，而非和时间绑定，是灰度不翻车的核心。

问：版本回滚到底要多久，用户会不会有感知？

如果回滚走的是配置化路线，也就是模型版本与路由规则都已配置化，那回滚本质只是网关改一次映射和比例，理论上在秒级内生效，用户侧的感知取决于网关配置下发与连接重连的耗时，通常远快于重新部署模型。真正拖慢回滚的是两种准备不足：一是历史版本被覆盖了，回滚时无版本可切，只能重新构建；二是路由规则没有版本化，回退时凭记忆手改，容易改错引入二次故障。把这两件事提前做成机制，回滚就能从应急动作变成常规操作。需要强调的是，即便配置秒级生效，已经打到新版本并正在进行中的长请求仍可能走完，所以回滚后建议再观察一小段时间确认新请求已全部回到旧版本，而不是只看配置状态变绿。

问：小模型能不能和大模型放在同一张卡上共存？

可以，而且这正是多模型路由想要拿到的显存收益之一，但前提是两者加载后的合计显存要留出余量。大模型权重本身占用显存的主要部分，小模型额外占用的相对有限，同卡共存能让大模型的空闲显存被小模型复用，提升整卡利用率。风险点在于推理时的瞬时显存峰值，尤其是大模型处理长上下文或长序列时，激活值与键值缓存会临时占掉一大块显存，如果此时小模型也在跑高并发，就可能撞上峰值导致 OOM。所以同卡共存时务必给每个版本设显存上限，并在网关侧错峰调度，避免两类模型同时冲峰值。如果小模型对延迟极其敏感、和大模型峰值容易叠加，那就宁可把它放进独立进程，牺牲一点复用收益换稳定性。

问：新模型冷启动延迟很高，怎么压下来？

冷启动延迟主要来自两块：权重从存储加载到显存，以及计算图或内核的首次编译。压法对应也分两步。加载侧，尽量把常用版本常驻显存，不常用的才按需加载，并用本地高速缓存减少重复读取；网关在真正放量前先发起一次预热请求，把权重加载和编译都提前跑完，用户首请求到来时走的是已经热好的实例。编译侧，推理框架大多支持提前编译或缓存编译结果，避免每次启动都重新生成内核；对量化模型尤其要注意量化内核的首次构建耗时。还有一个被忽视的点是连接预热，网关到推理实例的长连接如果也是冷启动，首请求的建连耗时会被算进延迟，建议在放量前把连接池先打满。把这几步做成上线流程的一部分，冷启动就不会在用户面前暴露。

问：多模型服务的成本到底怎么算才不糊涂？

算清成本要把视角从机器租金切到每次调用。先把每张卡上的显存与算力按模型版本拆开，记录每个版本在统计周期内承接的请求数和消耗的 token 数，再用总租金除以这些业务量，得到每次请求或每千 token 的真实单价。这样做的好处是，大模型和小模型共用网关时，成本能按实际消耗分摊，而不是被卡时平摊误导。另一个容易漏的成本是闲置显存：如果一张卡长期只跑满一半显存，那一半就是隐性浪费，应该通过同卡多模型或按流量调度实例来填。在选型阶段，一万网络在华南、华东、华北及中国香港、海外多地整合了自营服务器与带宽资源，做多模型部署时可以根据用户地域把推理实例就近摆放，既压低跨区延迟，也让按地域灰度的成本结构更清晰，具体机型与带宽以实时报价为准。把成本摊到 token 和请求上，灰度放量到底是省钱还是烧钱一眼可见。

问：灰度期间怎么监控新模型效果，光看服务存活够不够？

只盯服务存活远远不够，因为服务活着不代表模型变好。灰度监控至少要覆盖三层。最外层是服务指标，首字延迟、吞吐、错误率、显存水位，这些回答的是能不能用。往里一层是输出一致性，把同一批黄金用例同时发给新旧版本，对比输出差异，捕捉新版本在长尾输入上的回退。最内核是业务质量，用自动评分或抽样人工评估衡量回答准确率、幻觉率、相关性，这部分才是灰度是否放量的决策依据。三层数据要汇到同一个看板，并且和网关的流量比例联动：放量到某一档时，对应档的对比指标要自动高亮异常，运营一眼能看出新版本是在变好还是变坏。建议给灰度设明确的止损线，比如质量指标回退超过阈值就自动暂停放量，而不是等人工发现问题才手忙脚乱地回退。监控到位，灰度才是可控实验，否则只是把风险悄悄放大，名义上做了灰度，实际上把全量用户都当成了试错样本。

结论

把多个 AI 模型一起对外服务，真正难的不是让模型跑起来，而是让它们在同一套资源上共存、在可控范围内迭代、在出问题时秒级收口。三种结构各有位置：单实例单模型适合版本少、隔离要求高的早期阶段；单实例多模型路由靠显存复用提升利用率，但要把隔离与故障域管住；网关统一路由把分流从引擎里解耦出来，靠配置化的版本映射与流量比例实现独立灰度和秒级回滚，是模型版本数量变多后的必经之路。落到工程上，把成本模型从卡时切换到 token 与请求维度，把回滚从重新部署降级为配置切换，把监控从服务存活扩展到输出质量，这三件事做好了，多模型路由与灰度发布就不再是一团乱麻，而是一组可以复制、可以审计、可以放心的标准动作。需要补一句现实预期：这套体系前期要投入网关与配置治理的搭建成本，小团队版本只有一两个时未必划算，等到模型数量、调用方数量都上来之后，路由与灰度带来的稳定性收益和显存复用收益才会明显超过搭建成本，所以它是随规模生效的架构，而不是一上来就非选不可的方案。

来源：NVIDIA Triton Inference Server 官方文档，主题：多模型版本管理与模型仓库机制，参考其公开技术文档与版本路由说明。

来源：vLLM 官方文档，主题：连续批处理、模型并行加载与多模型服务接口，参考其开源项目文档中关于模型加载与请求路由的公开说明。

来源：NVIDIA 数据中心 GPU 显存规格公开资料，主题：H100 八十 GB HBM3、A100 四十 GB 与八十 GB、H200 一百四十一 GB、L4 二十四 GB 等显存容量与适用场景，参考 NVIDIA 官网产品规格页。

来源：LiteLLM 开源项目文档，主题：统一模型路由转发服务与多供应商模型路由、负载均衡与回退配置，参考其公开文档中关于路由与回退的配置说明。

来源：SGLang 开源项目文档，主题：RadixAttention 与多模型推理服务部署，参考其公开技术文档中关于服务部署与路由的说明。