1. 为什么一个团队会同时部署多个大模型：不是铺张，是场景逼的
我接手某个模型平台那会儿，线上跑了三个大模型。当时不止一个同学来问："就一个客服系统，为什么非要部署这么多大模型？"这个问题问得挺合理，我最初也有同样的困惑。但真正做完一轮性能分析和成本核算之后，结论完全反过来了——只部署一个模型的代价，比部署多个模型高得多，而且效果还差。这也是我想写这篇实战篇的原因：聊聊为什么会有"这么多大模型"，以及它们到底该怎么部署才不白费算力。
先说那个让我意识到问题的晚上。系统某个深夜突然被流量打爆，原因很简单：所有用户请求都涌进了同一个大模型实例。哪怕只是"查订单状态"这种几句话就能解决的请求，模型也会按标准流程走一遍完整的推理过程，上下文一并带入，输出串成一大段。结果就是GPU显存被占满，新请求排队，用户等了几十秒才收到一句"您好"。那一瞬间我意识到，把不同难度的任务全都塞进同一个模型，根本不是"省事"，是在拿算力和体验做赌注。
后来我们把请求按复杂度做了分层，平台上同时保留了一个小参数模型、一个中参数模型和一个大参数模型，分别处理不同场景。表面上看是三份部署成本，实际上整体吞吐提高了接近四倍，每万次请求的推理成本反而降了。要说清楚这件事，得先弄明白一个问题：为什么单一模型打不了全场。
1.1 单一模型打不了全场：能力、延迟和成本是三个互相打架的指标
很多人以为大模型是"越大越全能"，部署一个最强的就完了。但真实业务里，最强的模型往往不是最合适的模型。
能力、延迟、成本这三者在大模型这儿是互相打架的：参数量越大，能力越强，但延迟越高、单位token成本越贵；参数量小，速度快、便宜，但复杂任务上又容易答非所问。一个线上系统如果只部署一个大模型，就相当于你让一位教授去干所有接待员的活——他能干，但你付的钱和等待时间都不值。
我常举一个例子：某个7B参数级别的开源模型，在"意图识别"这类简单任务上，准确率已经能达到98%。而一个70B级别的模型在这个任务上可能也只高一个百分点不到，但单次请求延迟从0.8秒涨到4秒多，单卡跑不动还得扩成多卡。为这一个百分点多付几倍的延迟和成本，绝大多数业务都算不过这笔账。
还有个容易被忽略的因素是输出质量的可控性。不同模型对不同任务的输出风格、格式稳定性差异很大。有些小模型在短文本分类、信息抽取上表现得极其稳定，反而比大模型更听话；大模型虽然聪明，但生成时偶尔会"自由发挥"，对强格式要求的场景反而是隐患。所以单一模型的另一个问题在于：你没法在一个部署上同时获得"稳定执行简单任务"和"灵活应对复杂问题"这两头的能力。
1.2 多模型并存的真实驱动力：任务分层、上下文长度和私有化要求
我们梳理过线上必须部署多个模型的几个硬性原因，它们不是拍脑袋想出来的，每一项背后都有具体业务事件。
第一个是任务分层。客服场景里，约六成请求是查信息、查状态、走固定流程，这类任务完全可以用小模型快速搞定；约三成是中等复杂度的多轮对话，需要一定推理能力；剩下的不到一成是长文档解读、复杂逻辑推导，必须动用大模型。如果全部请求都打到大模型上，前面六成简单请求的延迟和成本就白花了。
第二个是上下文长度差异。有的业务需要读很长的文档或很长的对话历史，比如合同审查场景，上下文窗口至少要数万token；而像关键词抽取这种场景，给一千token都嫌多。为所有场景都部署一个超长上下文的大模型，代价极其夸张——KV Cache会随着上下文长度线性增长，GPU显存压力陡增。分开部署不同上下文规格的模型，是成本最直接的优化手段。
第三个是私有化部署要求。有些业务数据不能出内网，但也只需要中等能力的模型就能满足需求；有些部门则要求更高准确率，愿意为此单独部署大参数模型。这些需求互相独立，催生了物理隔离的部署单元。
所以"部署这么多大模型"不是运维在做艺术创作，而是让每一级算力都用在刀口上。搞清楚这个逻辑之后，下一个问题就来了：这些模型怎么选、每台机器上该放哪一个。
2. 部署之前先算清楚账：显存、吞吐和成本的三方权衡
很多人部署大模型是"先拉一个模型下来跑通再说"，这个思路也没错，但一旦模型多起来，就撑不住了。跑两个模型时可能靠运气，跑五六个模型时，如果每一份资源账都没算清楚，后面一定会频繁遇到OOM、排队和硬件闲置同时出现的诡异现象。
我在规划多模型部署时，第一步永远不是敲命令，而是拿一张表把显存、吞吐、成本算明白。这一节把我实际用的计算方式和思考逻辑完整列出来，可以照着套。
2.1 参数量与显存：一张表直接预估
大模型推理时的显存占用主要来自三块：
- 模型权重：以半精度（bf16/fp16）存储，每10亿个参数约占2GB显存；如果用8比特量化，则约1GB；
- KV Cache：随并发数和上下文长度增大，记录模型在处理序列时已经计算过的键值对；
- 计算中间态：推理过程中产生的激活值，多数框架有优化，但峰值仍然存在。
我实际估算时会先算一个大概的底数，再加一个40%到50%的安全余量。举个例子，一个7B参数级别的模型，半精度权重约14GB，考虑KV Cache和运行时额外占用，单张显存小于24GB的卡基本不推荐；13B级别的模型半精度约26GB，运行时大概率要30GB以上；70B级别的模型半精度约140GB，单卡基本跑不了，需要多卡切分。
下面这张表是我当时用来横向对比不同候选模型的简化预估表，格式可以直接抄走：
| 模型规模 | 半精度权重 | 8比特量化后 | 建议最低显存 | 典型并发场景 |
|---|---|---|---|---|
| 1.5B | 3GB | 1.5GB | 8GB | 意图识别、关键词抽取 |
| 7B | 14GB | 7GB | 24GB | 客服多轮、信息抽取 |
| 13B | 26GB | 13GB | 40GB | 中等推理、结构化输出 |
| 70B | 140GB | 70GB | 80GB以上且需多卡 | 长文档、复杂推理 |
提示：显存计算最忌讳"精确到字节"。线上运行时有推理框架本身的开销、CUDA上下文、显存碎片，多留20%到50%余量属于基本操作。我见过太多人算得刚好，一上线加个并发就OOM。
量化到底能不能无脑用？
不少文章一上来就推荐"无脑上8比特量化，显存砍一半"。这个说法在部署多模型时得谨慎一点——量化确实是稳妥的显存优化手段，但它有适用边界。
量化对显存的缓解很直接，7B模型8比特量化后，权重部分从14GB降到7GB，小显存卡也能跑。代价是模型精度会有轻微损失，在简单任务上几乎无感，但在数学、逻辑和复杂指令跟随上，一两分的差距就可能让输出质量明显下滑。
我自己的原则是：能用小模型解决问题的时候，优先减小模型规模，而不是在大模型上强行量化。因为量化省下来的显存，在同等模型规模下是"有限度"的；而从小模型换成大模型获得的，是能力本身的提升。这两个方向不能本末倒置。真正需要量化的场景，是把某个已在业务中验证过的模型塞进预算有限的硬件时，才去考虑7比特、8比特这类方案。
2.2 吞吐量比显存更关键：别只盯着"能不能放下"
显存决定一个模型"能不能跑"，吞吐决定它"跑得多快、扛得住多少并发"。多模型部署最常犯的错误就是只看显存，不看吞吐，最后结果是模型都塞进了机器，但每个实例一压测就超时。
推理吞吐的核心指标是token/s，更准确地说，要同时关注首token延迟（TTFT）和生成速度（TPOT）。TTFT就是用户发出请求到收到第一个token的时间，它直接决定"看起来卡不卡"；TPOT是后续每个token生成的耗时，它决定整段回答"读起来流不流畅"。
实际压测中，一个数学关系要心里有数：并发数翻倍，整体吞吐不一定翻倍；单个请求的生成速度一定会下降。因为同一块GPU上的多个请求会竞争计算资源。动态批处理可以显著提升吞吐，但它摊薄的是算力，不是延迟。把并发打满而单请求延迟爆表，这在业务上跟不可用没有区别。
我常用"高峰时段并发请求数的三分之二"作为吞吐目标。比如预估某个时段最大并发是300个请求，那我会让单实例的压测目标定在每秒处理200个请求以上，保留三分之一余量应对突发。这个比例不是绝对标准，但按这个思路设阈值，线上出问题的概率会小很多。
2.3 成本模拟：把每小时跑数算给财务看
部署多个模型时，财务或者上级一定会问一句："为什么要多花钱？"这时候别嘴硬，直接掏一张成本测算表最有力。
单卡的每小时成本可以简单按硬件采购成本除以三年折旧来估算，加上电费和机房损耗。假设一张卡的月成本约等于硬件价格的三十分之一，数据中心的卡大概按这个系数折算。得到单卡时价后，部署一个7B模型如果占用一张卡，跑满一个月，就是"单卡时价乘以24小时乘以30天"。同样的方式可以算出70B模型如果占用四张卡，成本就是7B模型的四倍起。
光给成本数字还不够，还要给出"多模型部署带来什么收益"。我当时的算法是：如果小模型能承接60%的请求量，那这60%请求的延迟和成本就按小模型算；真正的复杂请求才动用大模型。整体下来，平均单请求成本比"全用大模型"降了50%以上，同时平均延迟降了70%。把这两组数字放在同一张表里，决策的人自然就看懂了。
3. 多模型部署的落地架构：从单机跑模型到分配集群
账算完了，下一步是动真格的。如果说上一节解决的是"我要哪些模型"，这一节解决的就是"这些模型以什么形态在线上跑"。多模型部署最怕的就是各干各的、互不相通，一定要有一个清晰的控制面把调度做起来。
3.1 部署单元怎么拆：一个模型一个服务，资源边界划清楚
我强烈建议把每个模型都拆成独立的部署单元，不要图省事把两三个模型塞进同一个服务进程里。原因有三个：一是故障隔离，某个模型显存溢出或者假死，不会拖垮其他模型；二是升级独立，替换某个模型时不需要停掉整个服务；三是弹性伸缩灵活，给热门模型单独扩容，扩容哪个不影响哪个。
拆分之后，每一份部署单元都要有明确的资源配额。当时我们用的是一套容器化部署方案，每个模型实例都设定好CPU、内存和GPU显存上限。这个配额不是摆设，它保证一个实例不会因为流量飙升把宿主机的显存全部吃光，把邻居实例全部挤下线。
资源配额这里有个特别容易踩的坑：显存上限设得刚刚好比模型所需多一点，看似省资源，实际上会把厂上的并发调度空间堵死。推理时的显存占用不是恒定的，KV Cache会随着并发和上下文动态增长。我建议显存配额至少要留出模型峰值占用的1.3倍空间。也就是说，一个模型平时占用14GB，配额最好给18GB以上，给调度器留出呼吸的余地。
3.2 路由层为什么不能省：让每个请求找到对的模型
多模型部署后，最先遇到的问题就是"请求该发到哪个模型"。如果只靠写死在代码里的接口地址，运维层面会很痛苦。你需要一个专门的路由层，它扮演的是"分诊台"的角色。
路由层的工作方式并不复杂。最简单的方案是基于规则的：根据请求的关键词、会话类型、用户等级、上下文长度这些条件，把请求分发到不同的模型实例。比如检测到用户上传了一份长合同，就走长上下文模型；检测到用户只是在查物流信息，直接走小模型；普通多轮对话走中间模型。这套规则看起来简单，实际作用非常大。
再进阶一点的方案是动态路由，给每个请求打一个"复杂度分数"。这个分数可以由一个小模型来打，也可以由关键词命中的规则组合算出。复杂度分数超过阈值就转大模型，否则交给中小模型。这种方式比纯规则更稳健，因为能覆盖那些"看起来简单但实际上需要推理"的边界请求。
路由层还要负责一件事：画好兜底路径。如果大模型实例全部繁忙，路由应该允许小模型先顶上，用"降级响应"代替"超时失败"。我见过很多系统栽在这里——复杂任务因为大模型排队过长直接超时，用户体验比随便给个答案还差。做降级时，我在小模型的Prompt里加了一句"当前由精简版本作答，请给出更简洁的回复"，实测可接受度很高。
3.3 冷启动与热切换：多模型在线更新的两个细节
多模型部署和单模型相比，更新频率会高不少，毕竟每个模型都在独立迭代。处理不好冷启动和热切换，一次模型升级就可能把整晚的稳定性搭进去。
冷启动是指一个模型实例从启动到真正可以接流量的过程。大模型的冷启动跟普通Web服务完全不同，它要把几十GB的权重加载进显存，几分钟的加载时间很常见。如果不处理，路由把请求分发到一个还在加载的实例，就会立刻超时。
我的做法是给每个模型实例加上"就绪探针"：实例启动后先加载权重，再自发向探针接口汇报"我已准备好"，路由层看到就绪状态后才允许把流量放进来。这个机制虽然简单，但能把冷启动时间从"请求超时重试"变成"平滑等待就绪"。
热切换则是升级模型时的高级玩法。理想的流程是：先启动一批新版本实例，等它们全部就绪并完成健康检查，再把旧实例从路由列表摘除，等旧实例上的存量请求跑完再释放资源。这套流程看起来标准，实际操作中有个细节很关键——摘除旧实例时要等待存量请求处理完，而不是立即杀掉进程。我们最初就因为没做"排空等待"，升级时把正在生成一半的回答当场截断，前端用户直接看到半句话。后来统一加了优雅下线逻辑：路由层停止向旧实例分配新请求，旧实例把自己正在处理的请求跑完，再主动注销。
4. 从"能跑"到"抗造"：稳定性实测与踩坑复盘
多模型部署的安全感和单模型完全不同。单模型出问题，大家一眼就能发现；多模型出问题，经常是A模型把某台机器显存占满，B模型在另一台机器上疯狂排队，而路由层还在把请求均匀分配——结果是所有模型的平均延迟都在涨，但没有任何一个告警被触发。所以稳定性这块，我必须把所有踩过的坑拿出来复盘。
4.1 显存碎片化：第三个模型加载不进去的真相
我遇到的第一个奇怪现象是：机器明明还有位置，显存总量也够，但加载第三个模型时直接报显存不足。排查半天，发现是显存碎片化的问题。
大模型的权重加载和KV Cache分配都在显存上频繁进行，碎片化会让显存出现很多"零碎空洞"。新加载一个大模型时，需要一整块连续的显存空间，空洞虽多但拼不出一个完整的大块，就会分配失败。这跟内存碎片化是一个道理，只是大模型场景更突出。
应对手段有这么几个，我按推荐程度排序：
- 给不同的模型实例分配不同的显存对齐策略，尽量让大模型独占物理显存区间；
- 按"大模型先启动、小模型后启动"的顺序加载，或者反过来，固定一版加载顺序，避免频繁反复腾挪；
- 如果容器化平台支持，给GPU实例开启"预先分配"模式，在实例调度时提前锁显存；
- 实在不行，直接在低峰时段重启宿主机的推理实例，定时给显存"消碎片"。
这个问题的坑点在于它没有任何告警，显存总量看着正常，分配却失败。所以这类问题需要监控模型实例的启动失败日志，而不是只盯着显存使用率。
4.2 流式输出超时：多模型混跑时最容易暴露的隐患
大模型应用普遍采用流式输出，就是生成一段回答的同时，一边生成一边把内容推到前端。多模型部署之后，流式输出的问题容易被放大，因为不同模型的生成速度差异很大，小模型可能10秒就出完了，大模型可能要30秒甚至更久。
如果路由层或者网关设置的响应超时是统一的15秒，那么大模型只要超过15秒就会触发超时。客户端看到的就是"回答到一半连接断了"。这个问题的根源不是模型坏了，而是超时配置没有按模型实例差异化处理。
我的做法是：每一个模型实例都在注册信息里带上自己的"预期最大响应时间"，路由层按这个时间设置超时。例如小模型允许20秒，大模型允许60秒。同时网关增加"心跳机制"——流式输出过程中定时发送keepalive，避免中间链路因为空闲被断开。
还有一个流式输出的隐藏坑是最大输出长度。模型生成的回答如果超过某个上限，比如超过2048个token，有些框架会直接终止连接而不是优雅截断。我在路由层做了兜底：如果检测到接近上限，就在生成结果后面补上一个结束标记，保证前端不会黑屏。这个细节很小，但线上确实因为它的缺失出过事故。
4.3 压测与灰度：多模型上线前必须做的两道检查
多模型部署比单模型更怕"一起上线"。我们吃过一次亏：一次性把所有模型实例同时替换成新版本，结果某个模型新版本存在一个只在特定场景才触发的推理错误，导致整个平台的通过率断崖式下跌。从那以后我们定了一条规矩：任何模型新版本必须先灰度，且灰度时只允许一个模型在流量小的时段上线。
压测时也不能只对单模型压，更要对"多模型混合流量"做压测。方法不复杂：录制真实业务的请求日志，按线上比例做回放，观察路由层、每个模型实例、整体延迟的指标。这一步能暴露很多单模型压测发现不了的问题，比如A模型长请求阻塞了B模型的短请求、路由分发规则在某些流量比例下产生倾斜等等。
注意：多模型压测一定要盯"最差体验"而不是平均延迟。平均延迟很容易被那些短请求拉低，掩盖大模型长请求的严重退化。我习惯重点看P95和P99延迟，这两个数字才是用户体验的真实底裤。
5. 我的部署顺序建议与运维日常
写到这里，各位可能已经感受到——部署"这么多大模型"不是一次性工程，而是一套持续运营的方法论。最后一节分享几个我在这套体系里沉淀下来的日常操作习惯，它们不华丽，但非常管用。
5.1 分阶段上线路线图
如果你正在从单模型往多模型迁移，别试图一步到位。我建议按四步走：
- 第一阶段：POC。用真实业务数据同时跑两三个模型，离线比对任务完成质量，确认"确实需要多个模型，而不是一个模型加更好的Prompt";
- 第二阶段：单模型稳定运行。先把最核心的主模型部署稳，把推理框架、监控告警这些链路全部打通，建立基线指标；
- 第三阶段：接入第二个模型。选一个简单的、风险低的场景先切过去，验证路由、配额、降级逻辑；
- 第四阶段：逐步扩展到更多模型。每增加一个模型就是一次小规模灰度，积累一次稳定性经验。
这个节奏看起来慢，但它能让你在每一层都留下可用于回溯的稳定性数据。前期慢一点，后期爆发的时候就不会慌。
5.2 每天盯住的三个核心指标
多模型部署之后，与其看十几个告警面板，不如盯住三个指标：GPU平均利用率、平均排队时间、模型实例重启次数。
GPU平均利用率说明整体算力的使用情况，长时间低于20%说明部署的模型太多或者路由没有把流量灌进去；平均排队时间是用户体验的显性信号，持续超过两秒就该考虑扩容或分流；模型实例重启次数则是稳定性的晴雨表，只要某实例重启次数频繁异常，就该立刻去看日志，不要等到用户投诉。
这三个指标对应着"资源效率、用户体验、系统稳定性"三个视角，日常盯住它们，基本不会出大问题。
5.3 最值得投入的两个优化点
最后聊两个性价比极高的优化，它们不复杂，但收益明显。
第一个是动态批处理机制。让模型在并发请求到达时，把多条请求拼成一个批次一起推理，吞吐能提升两到三倍。这个方向几乎零风险，有推理框架内置支持，配置不复杂，优先做它。
第二个是显存调度优化，业界常用的做法是对KV Cache做分页式管理，不按固定的最大长度预分配，而是按实际生成过程按需分配，大幅降低显存浪费。同样规模下，这项优化能支持的并发数可以从几十提升到几百。它的成熟开源实现已经很多，接入成本低，也建议优先排上日程。
这两个优化做完，同样的硬件预算至少能多跑一到两个模型。到这一步，整套多模型部署体系才真正闭环了：模型选型有依据，资源算得清，架构拆得开，稳定性扛得住，优化有抓手。
最后说一下我这两年最真切的体会：部署多个大模型这件事，最大的敌人从来不是算力不够，而是"没有体系地硬上"。只要把每个模型为什么存在、每个请求为什么去这个模型、每个数字为什么是这个量级说清楚，多模型部署非但不是负担，反而会是平台最值得吹的稳定性工程。希望这篇实战篇能帮你少走几个弯路。
