做 LLM 服务的人一定都有这种经历产品首页要同时部署一个轻量对话模型、一个总结摘要模型、一个工具调用的规划模型再算上灰度中的微调版本前前后后差不多十来个模型。常规做法是每个模型独立起一个带显存的服务实例可 GPU 显存就那么多A100 80G 看着不小模型一多照样捉襟见肘。更让人头疼的是同一批 GPU 上每个实例利用率都稀碎有些模型就早晚高峰忙一会儿其余时间都在白白占着显存。我们这次被 EuroSys 2026 接收的工作 MFS想解决的正是在“模型家族”场景下多模型服务的高成本和长延迟问题。所谓“模型家族”一般有两种一是像 Qwen、Llama 这种从小到大多个尺寸组成的姊妹系列二是用一个基座模型微调出来的多个行业版本。传统多模型服务的做法是每个成员独立部署显存自然翻倍或者用多 LoRA 挂在同一个基座上虽省显存但实时性、首 token 延迟、并发能力都很难兼顾。MFS 的思路是把一个家族内的所有模型看成一个大模型的子集将它们统一装进一个共享的“大模型执行空间”只保留各自真正特殊的那部分参数。实测下来相比独立多实例服务token 生成延迟平均降低 56.1%显存峰值下降超过一半。这篇文章里我会把我们设计 MFS 时遇到的问题、背后的取舍、核心实现逻辑和实验效果拆开讲清楚。如果你正在做 LLM 服务化、推理加速或者只是在多个模型之间反复切换部署这篇整理应该能给你一些值得参考的切入点。1. 先聊清楚多模型服务到底痛在哪1.1 模型家族带来的“资源碎块化”先说一个最直接的痛点显存碎片化。假设一个家族里有 0.5B、1.5B、4B、7B 四个成员如果各自独立部署到一张 80G 的卡上不算 KV cache 就得占掉小 30GB。为了不让请求互相争抢通常还得做资源隔离也就是每个模型单独占一块 GPU。你看着每张卡上显存都有余量但哪张卡上的模型都没法在其空闲时去承接另一个模型的突发流量因为显存已经提前切好了。这种情况我会称为“资源碎块化”——真正的计算能力很大程度在闲置但形式上每块都被占用。这种做法在模型少、负载稳的时候还能接受一旦走到“模型家族”式产品线几乎必然触发问题。比如一个智能问答产品先要一个 Embedding 模型做召回再要一个 reranker 重排接着是生成模型可能还要一个分类模型去判断用户意图。每个模型单独占用资源整个调用链长度被放大任何一个环节在排队都会拖累端到端延迟。1.2 高延迟不只是显存不够模型切换更致命比显存更隐蔽的是延迟问题。很多人以为把多个模型装进一张卡、轮流加载就能省显存可实际测下来延迟反而更差。为什么因为模型切换本质上是一次“冷启动”。从一个 7B 模型切到另一个 4B 模型即使权重都缓存在内存里把权重从主存搬运到显存再完成初始化也要好几秒。在这一过程中等待的所有请求全部被阻塞。另一个容易被忽略的问题来自调度层。独立部署时每个服务实例只会看到自己的请求队列如果某个模型的请求量一阵一阵地涌进来调度器没法把其他模型的空闲算力借过来造成明显的排队等待。这属于“等待延迟”比计算延迟更容易被用户感知尤其在流式输出场景下。1.3 为什么不能简单地把小模型“合”成一个大模型有人会问既然模型家族同源为什么不直接蒸馏成一个统一模型或者只保留最大那个模型这有两个问题。第一模型家族的每个成员都有各自擅长的任务比如一个 0.5B 模型专门做意图识别很轻量响应极快一个 7B 模型做长文本生成。强行合并成一个的话要么小模型被大模型“淹没”要么为了兼顾所有任务让整体模型变得臃肿推理延迟反而上升。第二从服务角度讲用户调用接口是明确到具体模型 ID 的合并后你还是要交付多个入口内部的实现复杂度并没有消失。所以真正值得做的不是消灭模型的多样性而是在保留每个成员功能的前提下让它们的底层资源能够复用。这也是 MFS 的出发点。2. MFS 的设计思路把家族当作一个大模型的子集2.1 核心转变从“独立模型”到“共享底座 子模型掩码”MFS 最核心的思想是把一个模型家族内的所有成员统一建模成“共享大模型”的子集。这个共享大模型里装着家族共有的底层权重比如 embedding、大部分 transformer 层和 attention 投影矩阵。每个具体成员则通过一组轻量的掩码和适配器来定义。推理时系统根据当前请求指定的成员 ID在共享大模型上挑选对应的权重路径来执行。用一句不太准确但容易理解的话说传统方案是每个模型一个“独立的人”MFS 更像是让一群人共用一副强健的身体骨架只是在必要时换上各自专属的“手”和“记忆”。骨架是所有人的专用参数是各自唯一的。这里有个关键点共享部分不是随便设定的而是通过对家族内模型的参数相似性做分析后选出来的。我们实际做法是先取家族内多个检查点逐层计算每个 transformer 层的输出相似度以及权重矩阵的重叠度相似度高的层直接共享相似度低的层保留在每个成员自己的适配模块中。这部分分析是静态离线完成的不会在线推理时带来额外计算。2.2 层内共享和层间装配不是简单拼接看到“共享底座”四个字有人可能以为就是把多个模型的 checkpoints 拿来平均一下或者放在同一个文件里按层拼接。这肯定不行。模型家族成员虽然同源但层与层之间的权重并非一一对齐尤其在不同尺寸成员之间hidden size 都不一样。直接拼接会导致矩阵形状不匹配。我们的做法在结构上近似稀疏 MoE但不是 MoE 那种“激活一部分专家”的语义。具体来说共享大模型定义了一张“参数大矩阵”家族中每个成员都有一张从大矩阵到自身计算图的索引表。比如 7B 模型的第 5 层 weight 会落在共享矩阵的某一段1.5B 模型对应 size 更小的段落在另一位置。每个成员的计算图是一个 mask 过的子网络前向时通过索引和 mask 把需要的权重取出来不参与计算的部分保持冻结。这样做的好处是不同尺寸模型之间的显存不再完全不可复用——只要它们的部分层规模相同权重就能在物理上共享即使层数不同也可以按块的边界做对齐。2.3 成员专用参数LoRA 之外的“自成一派”在保留成员独特性上我们最初尝试过典型的 LoRA把每个成员当成一组低秩矩阵挂在共享层上。实验发现 LoRA 适合小规模微调但对差异较大的模型比如通用模型和专项模型表达能力不够生成质量会掉点。所以最后 MFS 采用的是“双轨制”一层轻量的适配器类似 LoRA负责大多数成员另加“成员独立层”负责差异特别明显的模块比如专用 token embedding 和输出分类头。这里想表达一个经验不要迷信某种单一技术。共享参数的比例不是越高越好得看家族成员之间的相似度。相似度高的共享 90% 以上没有问题相似度低还硬共享质量损失会非常大。我们在论文里给了一个参考区间同族同构同尺寸不同 checkpoint共享 95%~98%同系不同尺寸共享 60%~85%跨任务微调版本共享 70%~90%。这个比例会直接影响最终延迟和显存收益。2.4 为什么没有直接选 MoE 方案熟悉 LLM 架构的朋友可能会问这个“共享大模型 掩码 索引”听着和 MoE 挺像为什么不直接用一个 MoE 模型包打天下原因是 MoE 在训练阶段就得确定路由结构和专家数量模型家族是服务阶段出现的需求不可能要求每个业务方先重新训练一个 MoE。另外MoE 的专家通常是大规模并行分布在全部层里而模型家族的成员往往是几个独立的、权重大小不一致的模型直接把它们 weight 塞进 MoE 的 expert 槽位并不合适。MFS 本质上是一个 serving 层面的统一调度和权重组织方案它不对模型训练过程做任何假设也不需要额外的 MoE 训练这是两者最大的差别。3. 延迟为什么能降三层优化缺一不可3.1 显存下降带来的 batch 提升其实是延迟收益的大头我们在论文中报告 token 生成延迟降低 56.1%很多读者第一反应是“单 token 计算变快了”。实际上单 token 的浮点计算量减少有限因为每个请求还是要走一遍完整的 transformer 层。延迟下降的大头来自“更高效的批处理”。当多个模型共享同一份底层权重单次请求占用的显存显著下降。同样的 GPU 上MFS 能同时容纳更大的动态 batch。batch 越大GPU 的矩阵乘法越接近饱和单 token 的有效计算延迟自然越低。道理和你在等待火车时一个道理如果一节车厢只坐一个人虽然彼此不相打扰但每个人都要独立占用整列火车的运力效率极低大家共享车厢之后每人的“行李负担”小了列车也能装更多人整体通过效率反而更高。我们在实测中观察到很多请求是被“排队”耽误了而不是被“计算”耽误了。MFS 通过提升吞吐把排队长度压下来直接拉低了端到端延迟和尾部延迟。3.2 模型切换从秒级降到毫秒级独立部署模型实例时你想从一个模型切到另一个必须经历权重卸载和新权重的加载。这在 MFS 中被重构为“权重重映射”共享部分始终在显存中驻留切换时只需要切换成员专属的 adapter 和掩码索引。adapter 通常只有几十 MB从内存搬到显存只需要几十毫秒相比原先几秒的加载时间降低了两个数量级。这个变化对微服务链路上的每一个跳转都很重要。传统方案里一个请求先后经过摘要模型、生成模型两段模型调用之间的切换成本会被用户切实感知到。MFS 让所有成员在同一个执行空间里共存模型切换这个动作对调度器来说只是一次轻量更新不用把整个计算管线停掉。3.3 全局调度把同一家族的请求聚到一起MFS 的另一个优势是调度器能看到完整的模型家族请求分布而不是像独立多实例那样只能看到各自分片的流量。调度器在动态 batch 时会尽量把消息分类到同一“权重路径”的请求凑在一起减少 batch 内的参数切换频率。举个例子如果一批请求里 70% 都指向 7B 模型、20% 指向 1.5B 模型、10% 指向 0.5B 模型调度器不会按先来先服务顺序把这三种请求零零散散穿插起来而是按“同权重路径优先”原则聚簇把 7B 请求打包成一个大 batch 执行然后切到另一个路径处理剩下的小 batch。因为路径切换成本足够低这种策略的总切换次数是可控的但计算效率提升非常明显。延迟收益还有一个来自 prefill/decode 分离的结构化调度。MFS 内部把预填充prefill和增量生成decode两个阶段放到不同优先级别的队列中避免 prefill 请求占满整个 batch 后把所有 decode 请求都卡住。这类做法在其他 serving 框架里也有但和统一权重空间结合后效果被放大了。这里可以补充一个计算视角56.1% 听起来很具体但它不是一个固定值。我们实验使用的是短文本测试集平均输出 token 长度在 128~256 之间调度空白较少如果换成极端短请求收益可能会降到 30% 左右如果输出很长收益可能更高。延迟指标在系统类论文里受场景影响很大你在参考时需要关注实验设置落到自己的负载上再判断。4. 核心实现从请求进入到 token 出来4.1 系统架构简化版MFS 在实现上分为三块模型仓库、统一执行引擎、请求调度器。模型仓库离线存放家族中每个成员的权重和对应的索引/掩码信息。统一执行引擎负责加载共享大模型并在运行时根据请求指定的 member_id 构建计算图。请求调度器维护全局请求队列决定某个成员路径下应该合并哪些请求以及 prefill/decode 如何在 GPU 上分配。这三块在逻辑上是解耦的所以在实际部署时可以根据显存大小灵活拆开模型仓库可以放在本地 NVMe统一执行引擎占住共享显存调度器跑在 CPU 侧只发指令。整个系统仍然对外提供 OpenAI 兼容的接口业务端基本无感知。4.2 一个家族的权重如何被“装进去”离线阶段我们要把一个家族的所有模型统一“装进”一个大模型空间流程如下对齐 vocabulary。家族内模型可能各自有 tokenizer 差异首先统一 tokenizer并对不重合的 token 建立映射表差异过大的 token 放在每个成员的专属 embedding 段。逐层做权重对齐。同尺寸且同结构的模型直接对齐层号不同尺寸的模型按“最相近的前若干层”对齐。不同 hidden size 的矩阵不能直接求和需要在共享矩阵中预留不同大小的分段。生成掩码索引。每个成员记录自己用到的层、矩阵行/列范围、adapter 路径。这些索引不会在前向时动态计算而是预生成好并缓存。额外对共享权重做一次轻量蒸馏校准。所有成员在共享参数上做 5~10 步低学习率回滚消除硬共享带来的轻微精度下降。这个步骤很关键不做的话部分成员在困惑度上会有可见回弹。这里有一点要特别提醒如果家族内两个模型在 embedding 规模、层数、head 数量上分歧很大强行共享会让索引复杂到不如不共享。MFS 最适用的对象还是“同源模型家族”跨家族的大型模型合并不是当前版本的目标。4.3 推理时的前向计算大致长什么样前向时每个请求会携带 member_id执行引擎根据它找到对应的掩码和 adapter。示意流程用伪代码描述的话如下# member_spec 包含掩码、适配器路径和成员配置 mask, adapter member_spec[member_id] x embed_shared(x) embed_special[member_id](x) for i, layer in enumerate(layers): if mask[i]: x layer.shared(x) if adapter.has_layer(i): x adapter[i](x) x self.norm(x) logits lm_head_shared(x) lm_head_special[member_id].T这只是抽象写法实际工程中不会逐层 if/else 判断而是把同一个权重路径的请求收敛到一个执行流里mask 在 batch 级别统一处理。对于没有启用 adapter 的层前向计算和普通 LLM 没有区别对于启用 adapter 的层也只是多一次低秩矩阵相乘计算开销很小。4.4 调度与并发控制的细节调度器维护一个按成员路径分桶的请求池。当 GPU 显存和算力有空闲时调度器从某个桶里抽出尽可能多的请求形成一个 batch。这里有两个控制参数很有用一个是“批量嵌入大小”控制一个 batch 最多混合几种成员路径另一个是“路径切换预算”控制单位时间内允许的路径切换次数。我们遇到过一种现象为了让延迟“看起来很漂亮”强制把所有请求塞进同一个 batch结果不同路径之间互相干扰实际吞吐反而下降。所以 MFS 的调度不是简单地把请求拼大算数而是要在 batch 大小和路径纯度之间做权衡。这个权衡参数想要调好需要在线上负载上做小规模实验。KV cache 的管理也需要特别设计。MFS 允许多个成员共享同一个 KV cache 池但不同成员对 KV 长度的预期可能不同比如一个分类模型只需要很短上下文而一个长文本模型会占很多 KV 空间。如果直接混用短上下文模型的 KV 会先占满显存长上下文请求反而拿不到空间。我们的方案是让 KV pool 按成员设置上限同时在调度层预测下一个时间段内各成员的请求比例做预清理。5. 实验设计与效果复盘5.1 测试场景与基线选择我们用了一个包含 6 个模型的家族0.5B、1.5B、4B、7B 四个尺寸各一个加上一个 7B 的指令微调版本以及一个 1.5B 的工具调用版本。测试负载分为三类闲聊对话、文档总结、工具调用。这三类请求的输入长度差异很大正好能考察系统在 prefill/decode 混合场景下的稳定性。基线我们选了三个一是每个模型独立一个 vLLM 实例二是一个 vLLM 实例挂 6 个 LoRA三是另一个多模型服务基准 MuxServe。评价指标主要看 TTFT、TPOT、端到端平均延迟、p99 尾延迟、吞吐和显存峰值。之所以不只看端到端延迟是因为在某些场景下某个模型特别快、另一个特别慢平均后的数字会掩盖真实问题。系统类实验如果只报平均值基本不具备参考意义。5.2 实测效果延迟和显存的对比直接说结果。在混合请求负载下相比独立多实例方案MFS 的平均 token 生成延迟降低了 56.1%p99 尾延迟降低了约 41%。TTFT 平均降低 22%TPOT 平均降低 60% 以上。端到端吞吐提升了约 1.9 倍。显存峰值方面因为共享底座常驻6 个模型整体占用的显存大约是独立部署的 44%也就是省了一半还多。和单实例多 LoRA 方案相比MFS 的显存优势略小低约 18%但在请求并发上来之后MFS 的 tp99 延迟反而明显更好因为 LoRA 方案在切换 adapter 时对 batch 的打断更频繁而 MFS 的 mask 和 adapter 切换开销更轻。这里也坦白一下效果背后的限制。当家族只有一个大模型且负载极低时MFS 相对独立部署没有延迟优势因为共享模型即使没有请求也在 GPU 上占着显存空闲时的功耗和显存都不会自动释放。所以在模型数量小于等于两个、几乎无并发波动的场景MFS 不是最优选择。5.3 延迟收益是怎么拆出来的我们对着指标做了实验归因。约 30% 的收益来自显存下降带来的更大 batch 和更高利用率约 15% 来自模型切换耗时从秒级降到几十毫秒级剩下的约 10% 来自调度器对 prefill/decode 的分离以及同路径请求聚合。你可能会好奇为什么不是三部分相加因为它们之间存在耦合batch 更大后调度器的路径切换频率也会增加抵消了一部分收益。这组归因数据给我们的一个重要启发是做 serving 优化时不要一上来就盯着算子融合或 CUDA kernel 优化先看看显存和调度。很多人的延迟大头并不是 GPU 算不动而是资源被管理得太烂。5.4 牺牲了哪些东西MFS 也不是白拿收益。首先是多模型权重统一后的量化难度更高。共享层上不同成员对数值范围的敏感度不同一个成员能接受 int8 量化另一个可能会掉点需要分成多个 scale。其次想动态往家族里加新成员需要做一次权重对齐流程不能像独立实例那样直接挂载一个 checkpoint。最后排查问题变难了——以前每个模型的日志独立现在所有成员都跑在一个执行引擎里一个 GPU 故障可能影响整个家族的服务。6. 实际落地时你会踩到的坑6.1 先把“共享”和“独立”的边界划分清楚不要觉得“既然有共享底座每个成员就越像越好”。我们最开始做过一个疯狂实验把一个 7B 通用模型和一个经过大量工具数据微调的 1.5B 模型强行共享了 95% 的参数结果工具模型的意图识别准确率掉了很多。原因很直接工具调用任务的底层表征和通用对话模型有偏差过多共享导致专用信息被稀释。所以实际划分共享层和独立层时一定要用离线评测集做“消融”先全共享然后逐步把部分层改为独立层测量每个成员在目标任务上的指标。彻底跑完一遍大概需要一两天但比上线后发现质量回退再回滚成本要低得多。6.2 调度器本身可能成为新的瓶颈MFS 把原本分散在多个模型实例的请求统一收拢到一个调度器里请求量大之后调度器 CPU 侧的计算可能成为瓶颈。我们在压测时遇到过 CPU 占用飙到 90% 以上的情况不是 GPU 不够而是调度器在频繁计算 batch 组合和路径切换策略。给后来者的建议是调度决策不要全用 Python 写动态策略尽量把高频路径编译成静态图或 C 实现的规则模板同时给调度器单独设一个 CPU 核不要让 GPU 的启动线程和调度线程抢资源。6.3 量化时容易出意外对共享大模型做量化需要特别小心每个成员的敏感层。我们经历过一个 case某个 1.5B 成员在共享层量化后困惑度只涨了 0.3但另一个 7B 成员在同样的量化 scale 下输出明显变差。最后是给不同成员的 adapter 单独设 scale共享层则选择所有成员误差最小的折中 scale才算解决问题。如果追求低显存部署建议先用 int8 做共享层adapter 保持 bf16不要一上来就 int4因为多成员共享权重后单个成员的异常 outlier 会被放大int4 很容易翻车。你真想用 int4至少要跑全量评测集而不仅是看几个样例输出。6.4 监控指标要升级独立多实例时监控一个请求属于哪个模型直接在服务日志里就能看到。MFS 模式下一个服务进程处理全体成员请求如果监控还停留在“单个进程的 GPU 利用率”层面根本看不出某个成员的实际服务状态。我们在生产环境加了自定义指标按 member_id 拆分的请求量、每个成员路径上的平均 token 延迟、路径切换次数。尤其是“路径切换次数”它和 tail 延迟强相关值得重点关注。7. 常见问题与排查方向问题可能原因排查/解决办法某个成员的生成质量下降明显共享层比例过高或 adapter 表达不足降低该成员的共享层数量增大独立 adapter 容量重新离线校准显存占用符合预期但吞吐上不去调度器 batch 纯度太低路径频繁切换调大路径切换预算提高同成员请求聚合权重TTFT 很高但 TPOT 正常prefill 被 decode 请求挤占打开 prefill/decode 分离队列为 prefill 设独立优先级加入新成员后现有成员延迟波动新成员路径权重与现有路径冲突检查索引映射是否重叠必要时重新做离线权重对齐量化后整个模型家族输出都不稳定量化 scale 选择了不当的折中方案分成员计算敏感度共享层采用分块量化策略服务空载时 GPU 功耗降不下来共享大模型常驻显存增加空闲卸载机制或控制单个节点的共享模型数量以上是我们在开发和调优 MFS 过程中真正踩过、也真正花时间解决过的问题希望对你能有参考价值。最后再说一个我个人的体会。做这类系统工作最大的收获不是延迟降了几个百分点而是理解了“服务化系统”的优化边界通常在资源管理而非单点计算。很多人一想到降延迟就去改 kernel但实际把调度、显存、批处理理顺后往往能获得更可观的收益。MFS 本质上只是把“模型家族多实例服务”这个场景里的资源问题重新做了一次设计效果超出我们最初的预期。如果你要在自己的环境中尝试类似的思路我的建议是不要一上来就试图把所有模型都融合成一个超级共享模型先拿两个结构相近的模型做个最小原型测量显存和延迟收益确认可行后再扩大到整个家族。这个增量式路径风险最低也最容易让团队看到实际效果。后续如果你们有把模型家族和动态扩容结合起来的需求或者想让共享底座支持在线增量学习MFS 这套基础架构还有不少可以继续演化的空间。