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比特量化则约1GBKV Cache随并发数和上下文长度增大记录模型在处理序列时已经计算过的键值对计算中间态推理过程中产生的激活值多数框架有优化但峰值仍然存在。我实际估算时会先算一个大概的底数再加一个40%到50%的安全余量。举个例子一个7B参数级别的模型半精度权重约14GB考虑KV Cache和运行时额外占用单张显存小于24GB的卡基本不推荐13B级别的模型半精度约26GB运行时大概率要30GB以上70B级别的模型半精度约140GB单卡基本跑不了需要多卡切分。下面这张表是我当时用来横向对比不同候选模型的简化预估表格式可以直接抄走模型规模半精度权重8比特量化后建议最低显存典型并发场景1.5B3GB1.5GB8GB意图识别、关键词抽取7B14GB7GB24GB客服多轮、信息抽取13B26GB13GB40GB中等推理、结构化输出70B140GB70GB80GB以上且需多卡长文档、复杂推理提示显存计算最忌讳精确到字节。线上运行时有推理框架本身的开销、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做分页式管理不按固定的最大长度预分配而是按实际生成过程按需分配大幅降低显存浪费。同样规模下这项优化能支持的并发数可以从几十提升到几百。它的成熟开源实现已经很多接入成本低也建议优先排上日程。这两个优化做完同样的硬件预算至少能多跑一到两个模型。到这一步整套多模型部署体系才真正闭环了模型选型有依据资源算得清架构拆得开稳定性扛得住优化有抓手。最后说一下我这两年最真切的体会部署多个大模型这件事最大的敌人从来不是算力不够而是没有体系地硬上。只要把每个模型为什么存在、每个请求为什么去这个模型、每个数字为什么是这个量级说清楚多模型部署非但不是负担反而会是平台最值得吹的稳定性工程。希望这篇实战篇能帮你少走几个弯路。