上个月我把一块计算卡的负载从 30% 提到了 75% 以上做的事情只有一个把原来“一卡一模型”的部署改成了一卡多实例。在跑大模型推理的朋友应该都有同感单实例部署逻辑最简单但所有资源都绑在一套生命周期里。模型 A 偶尔把显存吃满模型 B 就得一起遭殃你想给某个模型单独升级整套链条都要重启每次发版上线都像拆弹一样谨慎。换成 MindIE 多实例部署之后这些纠缠一下就被切开了。不过网上关于 MindIE 多实例的资料很多都停在“支持这个功能”的层面真正把 config.json 怎么组织、资源怎么分、哪些参数不能乱动的实战经验分享太少了。这篇文章不写概念直接按我实际配置一个单卡多模型实例的流程来讲适合正在用、或者正准备用 MindIE 做推理服务集群、又苦于卡资源不够分的同学参考。1. 为什么单卡多实例能救回一半利用率1.1 单实例模式里资源到底浪费在哪先说一个不一定精确、但很能说明问题的观察在我经手的几个模型部署项目里大模型推理服务在单实例状态下的算力利用率往往长期在 20%-40% 之间浮动。这不是说模型推理不重要而是推理场景本身有很强的“时间不均匀性”。一个典型的在线服务模型请求密集期集中在白天几个小时夜间或者业务低谷期几乎空转。但模型加载到显存里的权重不会释放KV cache 预留的空间也一直在那里。也就是说就算一个请求都没有那张卡也已经“被占用”了。单实例部署下卡空着是常态再叠加不同业务场景对模型的需求又得再加卡成本就是这么滚上去的。另一个浪费点在于请求类型的差异。聊天类模型有固定的系统提示词要处理很长的 prefill 阶段分类模型输入短、输出短但并发高向量化模型恰恰相反一条请求的算力开销小吞吐要求高。如果你强行让一个模型实例承接所有类型的请求配置只能按最重的场景来轻场景请求多的时候照样会拖慢重场景。1.2 多实例到底解决了什么多实例不会帮你把一张卡的物理算力变大它做的是两件事把资源切成更小的管理单元再把模型生命周期从资源占用中解耦出来。具体到部署收益我体感最深的四点故障域隔离一个实例崩了、OOM 了、卡死了不至于把所有推理服务全部拖下线。在单实例时代一次显存溢出就能让线上所有模型一起难堪。按模型独立调优A 模型吃显存、B 模型吃算力它们可以各自用自己的一套并发数、Batch 大小、KV cache 策略互不干扰。灰度升级容易新版本模型先开一个新实例流量切一部分过去验证稳定后再摘掉旧实例。这在单实例时代根本无法想象。填满资源空洞把不同的请求曲线叠在同一张卡上峰值互相错开之后整卡利用率自然就上去了。当然多实例不是没有代价。它的代价体现在配置复杂度上——而这恰好是 config.json 存在的意义把隔离、配额、端口这类事情在启动前一次性定清楚。如果靠手工去调整每个进程的环境变量多实例方案大概率会把维护者逼疯。2. 先搞清楚实例、模型、服务三者怎么对应2.1 三个概念的关系在动手写 config.json 之前我觉得有必要把几个词先对齐因为很多配置错误本质上都是概念混淆导致的。模型指权重、Tokenizer、配置文件的静态组合。它躺在磁盘上不占显存。实例一个正在运行中的模型副本。它有自己独立的显存占用、KV cache、并发队列和生命周期。服务对外暴露的 HTTP/gRPC 接口。实例通过服务对外接受请求一个实例可以对应一个服务端口。在 MindIE 里你配置的核心对象其实是“实例”模型路径、端口、资源限额都是挂在实例下面的。也就是说你可以让同一个模型路径的两个实例分别加载也可以让同一个实例内部按模型名称路由多个模型——但后一种方式隔离性弱我一般不太推荐用作多模型生产方案。2.2 实例隔离与硬件加速器分区的关系这里要跟“硬件 MIG 分区”做个区分。很多人一听到多实例第一反应是“是不是要把卡物理切成好几块”其实不完全是。物理分区比如 GPU 的 MIG 模式是把计算单元、显存、带宽都从硬件层面隔开隔离性最强但分区数量受限而且对模型尺寸有要求——一个模型如果稍微超出一个分区的显存就装不下了。MindIE 这套配置体系更多是基于软件层面的资源声明确保隔离每个实例在显存池里划走一块在算力调度上拿到自己的配额在端口上有独立的监听地址。物理资源依旧是共享的但逻辑上每个实例以为自己在独占一块区域。实际部署时物理分区和软件多实例可以结合使用。比如一张大卡先用硬件分区劈成两个 MIG 设备再在每个虚拟设备上通过 config.json 各跑多个推理实例。这样既拿到硬件级故障隔离又不受分区数量限制。3. 动手前先算一笔资源账3.1 三本账显存、算力、端口我见过不少同事一上来就直接改 config.json结果启动失败的次数能绕机房一圈。配置本身不难难的是没有提前算好资源账。多实例最核心的三本账是显存账一个模型实例在运行时要占用的显存主要由四部分组成模型权重大小半精度下 7B 大约 14GB13B 大约 26GBKV cache 预设跟 max_seq_len、并发数和层数强相关激活值attention 计算过程中的中间结果推理框架自身的运行时开销CUDA context、内存池碎片等算力账模型推理请求的 prefill 阶段需要大量矩阵乘decode 阶段则更偏访存瓶颈。不同模型对算力的需求差异极大这笔账决定了你在 config.json 里给各实例分配的算力配额比例。端口账每个实例至少需要一个服务端口另外可能还涉及指标监控端口和调试端口。多实例一旦上了量端口冲突会成为最常见的启动失败原因。3.2 一张表把账算清我这次配置的目标是在一张 80GB 显存的卡上部署三个模型实例一个 7B 聊天模型、一个 6B 向量化模型、一个轻量的关键词分类模型。动手前先列了这么一张表实例模型文件大小期望峰值并发预估显存占用算力配额服务端口chat-7b约14GB32约35GB50%8001embed-6b约12GB64约25GB30%8002clf-tiny约2GB128约10GB20%8003系统预留--约10GB--这张表的预估逻辑是聊天模型长文本多KV cache 占比高给足显存向量化模型并发高但单请求短算力需求更集中在传输带宽分类模型轻量用它填剩余的资源缝隙。比例不是拍脑袋定的是照着业务请求曲线估算出来的。后面调优时也是拿这张表跟实际监控对照着改。4. 用 config.json 从单实例改造成三个实例4.1 单实例配置长什么样如果你已经有一套能正常跑的单实例配置改造思路就比较顺了。下面是一段简化后的单实例 config.json 结构我拿它做底子{ device_id: 0, model_path: /models/chat-7b, serving_port: 8001, max_batch_size: 32, max_seq_len: 4096, kv_cache_size: 8192 }这段配置表达的意思是物理设备 0 上加载一个模型用 8001 端口对外服务。单实例阶段很多字段是缺省状态——因为在只有一个实例的时候资源怎么分都是它的不需要写。一旦要扩展成多实例这些缺省值就会变成隐性地雷。4.2 改成多实例的关键字段多实例的 config.json 在结构上最大的变化是把原来“直接在根上声明模型”的方式改成了“先用一个公共段落声明全局资源再在实例列表里逐个声明归属关系”。下面是我这次实际使用的简化配置框架{ global: { device_id: 0, gpu_memory_pool: 81920, log_level: info }, instances: [ { name: chat-7b, model_path: /models/chat-7b, serving_port: 8001, max_batch_size: 32, max_seq_len: 4096, kv_cache_size: 8192, compute_quota: 5 }, { name: embed-6b, model_path: /models/embed-6b, serving_port: 8002, max_batch_size: 64, max_seq_len: 2048, kv_cache_size: 4096, compute_quota: 3 }, { name: clf-tiny, model_path: /models/clf-tiny, serving_port: 8003, max_batch_size: 128, max_seq_len: 512, kv_cache_size: 1024, compute_quota: 2 } ] }这里几个值得展开说的点compute_quota是各实例的算力配额。我按 5:3:2 分配的含义是调度器在争夺计算资源时按这个权重执行。它不严格等于“独立占有 50% 算力”更像是一种优先级加权——权重高的实例在抢资源时更容易赢权重低的在空闲时也能借到算力。gpu_memory_pool是全局显存池上限。注意我是一个池子统一管理的思路并没有分别给每个实例写死“必须占 35GB”这种硬限制。这样做的优点是显存利用率高某个实例低谷时空出来的显存可以被其他实例借去撑一波突发流量。缺点是隔离性弱如果一个实例把池子吃满其他实例照样会 OOM。如果你更看重硬隔离可以在实例级加显存上限字段把池子切成“硬分区模式”。两种模式各有利弊我建议在线业务用硬分区离线任务用共享池具体看你们对故障容忍度的要求。4.3 启动服务和验证配置写好后启动方式跟单实例基本一致只是 MindIE 在读取 config.json 后会自动按实例列表逐个拉起服务。启动命令大概是这样的形式mindie-service --config /etc/mindie/config.json启动后我从日志里最关心的是两类日志一类是每个实例是否成功加载模型权重另一类是实例服务端口是否进入 listening 状态。看到三行类似“server started on port 8001/8002/8003”的关键词就说明配置级别没有大问题。接下来做的是最基础的请求验证用一个简单脚本把三个端口都打一遍curl http://127.0.0.1:8001/generate \ -H Content-Type: application/json \ -d {prompt: 你好介绍一下你自己} curl http://127.0.0.1:8002/embed \ -H Content-Type: application/json \ -d {text: hello world} curl http://127.0.0.1:8003/classify \ -H Content-Type: application/json \ -d {text: 这个商品质量很好}如果三个端口都能在合理延迟内返回结果那基本架构就跑通了。但这里我要提醒一句能返回结果跟性能达不达标完全是两码事别急着收工。接下来要做的是并发压测用压测工具把请求打上去观察延迟和吞吐是否跟预想的一致。5. 多实例调优的平衡点算力配额与显存隔离5.1 算力配额调优的实测过程我第一次跑压测时三个实例的 compute_quota 是 5:3:2结果发现 embed-6b 明明配额只有 3吞吐却比聊天模型高一截。原因不复杂embedding 场景单请求计算量小只要显存够、带宽充足吞吐自然会高。而聊天模型虽然权重占用量大但算力需求是突发的、有强依赖的——它一旦进入 decode 阶段必须持续占用计算资源。这个观察给到我的启发是算力配额不应该按模型大小来定而应该按这个模型业务请求对延迟的敏感度来定。比如聊天模型如果你要求首 token 延迟低于 300ms那它在高峰期的算力配额就不能低。衡量维度是请求数的 QPS 曲线不是模型参数量。另外一个容易被忽略的细节是算力配额对“长尾请求”影响很大。我在压测里发现当 embed-6b 的并发打到 60 以上时比较小的 clf-tiny 实例的 p95 延迟会突然飙高。这是因为调度器在权重大的情况下会优先把资源给到高权重实例导致低权重实例的长尾请求饿死。解决办法不是单纯调高 clf-tiny 的配额而是给它单独限流——在实例上配置最大并发数从源头控制请求涌入量。5.2 显存预留与 KV cache 的权衡多实例配置最容易“看起来没问题跑起来炸”的就是显存预留。KV cache 的分配逻辑值得单独拿出来说。KV cache 的大小跟 max_seq_len 和 max_batch_size 强相关。以聊天模型为例max_seq_len 是 4096、max_batch_size 是 32粗略估算下来KV cache 大概要预留 6-8GB。如果你把这个值配小了会出现两个现象一是长文本请求成功率下降二是当多个长请求同时到达时即使并发数没到上限服务也会报显存不足。这里有个常见的反直觉配置实例级 KV cache 大小设得过大反而会拖垮整体吞吐。因为显存池是共享的一个实例把 KV cache 空间划走太多其他实例能用的池子就变小了。我实际调下来最后把 chat-7b 的 KV cache 从 8GB 降到了 6GB虽然单实例极限并发小幅下降但整体三个实例的吞吐反而提升了 15% 左右。多实例场景下局部最优不一定是全局最优要有“让一点”的心态。6. 排错实录五个最常见的翻车现场6.1 端口被占却查不出来多实例配置里最常见的问题就是端口冲突。我遇到过一次启动报错日志只提示“failed to bind address”但第一次排查时netstat -tlnp查了半天也没看到对应端口被占用。后来才发现问题出在调试端口而不是服务端口——两个实例虽然服务端口不同但调试端口都配成了缺省值 8080导致第二个实例启动时抢占失败。解决方法是给每个实例显式配置独立的调试端口和监控端口不要偷懒用缺省值。教训其实很朴素多实例配置里凡是带“端口”字样的字段全部要单独指定。6.2 显存看起来够模型却加载失败一次部署 clf-tiny 时模型文件只有 2GB全局显存池还有 10GB 空闲但加载就是失败。排查到最后发现是显存池碎片导致的——前面的实例加载后留下了大量大小不等的内存块新实例需要的连续内存块恰好不够。这类问题在单实例时代几乎不会遇到但多实例共享显存池之后就变得很常见。解法一是采用硬分区模式给每个实例提前划定独立显存区域避免碎片问题解法二是在全局池配置里开启内存碎片整理策略但碎片整理本身也有开销需要权衡。我不建议靠重启硬扛尽早切换到硬分区模式更省心。6.3 服务起来了延迟却高得离谱这个坑藏在实例的并发参数里。我一开始给三个实例都配了很大的 max_batch_size以为并发越大越好。结果聊天模型的 p99 延迟从 500ms 直接飙升到 3 秒以上。原因在于多实例共享算力当一个实例的 batch 过大时它把计算资源集中用于处理这一大批请求其他实例的请求就被挤到一边。而由于算力配额权重不同低权重实例的请求会被“插队延迟”表现就是整体延迟不均匀。后来我把分类模型的最大 batch 从 128 降到 64聊天模型保持 32 不动整体延迟曲线马上平滑了不少。6.4 KV cache 分配导致批量变慢有段时间我发现 embed-6b 的平均延迟一直稳定但一旦聊天模型有长对话请求进来它的响应就会抖动一下。最后定位到 KV cache 上聊天模型的长请求会临时占用大量 KV cache如果池子里空间不足它会向共享池借而共享池的一部分被 embed-6b 的缓存占着于是调度器就开始做 cache eviction产生额外开销。这个问题的本质是你把两个模型的请求峰值叠加到了同一块显存池上。解决方案有两个方向一是错峰——比如把向量化模型的离线批量任务挪到夜晚避开聊天模型的高峰二是隔离——显存池改硬分区给每个实例划死配额。按我们的实际业务选了一顺手提升明显。6.5 中断后残留实例占着资源多实例模式下进程崩溃并不少见但要命的是MindIE 主进程退出时某些子实例进程可能没有跟着清理干净。我遇到过一次进程已经停了但端口还在监听、显存还被占着的情况导致重启时配置校验不通过。处理这类问题的步骤我固定成了三条# 1. 查端口占用 lsof -i:8001 # 2. 查显存占用 npu-smi info # 或对应硬件的等效命令 # 3. 确认没有残留后强制清理再重启这步操作我建议直接写进团队的部署脚本里每次重启前自动执行检查能省掉很多“启动失败又找不到原因”的时间。7. 部署完成后的日常维护建议7.1 定期看监控而不是出问题再看多实例部署上线后我最强烈的感受是必须把每个实例的独立监控指标拉出来。之前单实例只需要看整卡利用率、显存占用现在要看每个实例的 QPS、平均延迟、p95 延迟、显存使用率、算力配额使用率。我习惯在每个实例的端口附近单独暴露 metrics 端点然后接入 Prometheus 一类的监控系统。发现某个实例长期跑不满配额就把这部分配额分给更紧张的实例发现某个实例配额长期打满就得考虑到底是并发太高还是模型本身方式不对。7.2 每次改配置记录“改动前后对比”config.json 的改动比代码改动更容易被忽略因为它看起来只是几个数字。但有时我只是把某个实例的 compute_quota 从 3 改成 4就会连带影响另一个实例的 p95 延迟。所以我现在养成了给配置文件做版本管理的习惯每次改动顺手在 commit message 里写上期望目的和实际观察结果。7.3 把配置模板化和校验变成一个标准动作随着实例数量增加靠手写 config.json 迟早会出错。我后来把配置模板抽了出来实例的“name、model_path、serving_port、显存上限、算力配额”全部参数化部署时通过模板渲染生成实际配置。另外每次改动配置后先做配置校验MindIE 相关工具大多支持 dry-run 模式再重启服务。说句实在话单卡多实例这套玩法配置本身并不神秘难点始终在于对资源的敏感度和对业务场景的理解。多实例不是万能银弹如果你的单实例负载本来就已经 100%那多实例只会放大竞争但在大部分实例利用率低迷的部署现场这一套操作下来往往就是最省成本、见效最快的一步棋。上面这些坑是我实际踩过换回来的经验希望能帮你在配置 config.json 时少走几段弯路。