MFS：模型家族共享KV缓存，token生成延迟降低56.1%-开发者社区

1. 当推理服务遇到"模型家族"：MFS 要解决的真实痛点

做过大模型推理服务的人大概都有过这种体验：线上同时挂着好几个不同尺寸的模型，7B 的负责高并发轻量请求，13B 的兜底中等复杂度任务，70B 的专门处理需要深度推理的硬骨头。听起来很合理，但真跑起来你会发现，显存被切得七零八落，每个模型都要单独占一份 KV 缓存空间，GPU 利用率上不去，token 生成延迟还忽高忽低。EuroSys 2026 上这篇关于 MFS 的工作，瞄准的就是这个场景——把原本各自为战的"模型家族"塞进一个大模型的服务框架里，让它们共享底层资源，最终把 token 生成延迟压低了 56.1%。

这个数字不是随便说说的营销话术。在推理服务里，延迟的构成非常复杂：有 prefill 阶段的算力瓶颈，有 decode 阶段的显存带宽瓶颈，还有调度层面的排队等待。MFS 能做到这个幅度，说明它不是单纯优化了某一个环节，而是在架构层面重新组织了模型家族之间的关系。关键词里出现的 LLM、token、KV 缓存，恰好对应了这条技术链路的三根支柱：模型怎么组织、token 怎么生成、缓存怎么复用。

先说清楚 MFS 到底是个什么东西。从标题的表述来看，它的核心思路是"把模型家族装进一个大模型"。这句话可以有两种理解：一种是把多个小模型的能力蒸馏或合并到一个大模型里，另一种是让多个模型共享同一套服务基础设施，对外表现为一个统一的大模型服务。结合 EuroSys 这类系统顶会的调性，以及"token 生成延迟降低"这个明确的系统指标，我更倾向于后者——MFS 是一个面向模型家族的服务系统，通过共享 KV 缓存、统一调度、参数复用等手段，让多个模型在同一个推理框架下协同工作。

为什么这件事值得单独发一篇顶会论文？因为模型家族的服务化不是简单的"多加载几个权重"就完事了。每个模型有自己的注意力头数、层数、隐藏维度，KV 缓存的形状完全不同。如果每个模型都独立管理缓存，显存碎片化会非常严重。更麻烦的是，当请求在模型之间切换时，缓存无法复用，prefill 阶段要重新计算，延迟自然就上去了。MFS 要解决的，正是这种"模型多了反而更慢"的悖论。

适合读这篇内容的人，我大致分三类：一是正在做推理服务架构的工程师，你们可能已经在用 vLLM、TensorRT-LLM 或者自研框架，想知道多模型场景下还能怎么优化；二是做模型部署和运维的同学，你们关心的是显存利用率和吞吐量；三是对 LLM 系统研究感兴趣的学生或研究者，想了解 EuroSys 这类会议关注的问题切口。不管你是哪一类，接下来的内容都会从原理到实操层面，把 MFS 这套思路拆开讲清楚。

2. 模型家族共享 KV 缓存：MFS 的核心机制拆解

2.1 为什么 KV 缓存是模型家族服务的命门

要理解 MFS 的价值，得先搞清楚 KV 缓存在推理服务里到底占多大分量。Transformer 做自回归生成时，每生成一个 token，都要拿当前 token 的 query 去和之前所有 token 的 key 做注意力计算。如果每次都重新算一遍历史 token 的 key 和 value，计算量会随着序列长度平方增长。KV 缓存的作用就是把这些中间结果存下来，避免重复计算。

问题在于，KV 缓存的显存占用非常可观。以一个 13B 模型为例，假设 40 层、隐藏维度 5120、32 个注意力头，每个 token 的 KV 缓存大约是 2 × 40 × 5120 × 2 字节（FP16），算下来每个 token 差不多 1.6MB。如果并发 32 个请求，每个请求平均 2048 个 token，光 KV 缓存就要吃掉 100GB 以上的显存。这还没算模型权重本身。所以在大模型服务里，KV 缓存管理直接决定了你能扛多少并发、能跑多长的上下文。

模型家族的场景更麻烦。7B、13B、70B 三个模型的 KV 缓存形状完全不同，层数、头数、维度都不一样。传统做法是给每个模型预分配一块固定的缓存池，但实际流量是波动的，7B 的池子可能经常空着，70B 的池子却排队等缓存。MFS 的思路是打破这种静态划分，让模型家族共享一个统一的缓存空间，按需分配、动态回收。

2.2 统一缓存池的分配逻辑与碎片治理

MFS 实现共享缓存的关键，在于它设计了一套跨模型的缓存块管理机制。具体来说，它把 KV 缓存切分成固定大小的 block，每个 block 可以存储一定数量 token 的 KV 数据。不同模型的 block 大小可能不同，但 MFS 通过一个全局的 block 分配器来统一管理，避免了每个模型各自维护空闲链表带来的碎片问题。

这里有个细节值得注意：不同模型的 KV 缓存维度不同，意味着同样大小的 block 能存的 token 数量不一样。MFS 的做法是按"token 容量"来标准化 block，而不是按字节数。比如一个 block 定义为能存 16 个 token 的 KV 数据，那么 7B 模型的 block 字节数就是 16 × 2 × 32层 × 4096维 × 2字节，13B 模型则是 16 × 2 × 40层 × 5120维 × 2字节。分配器只关心"这个 block 属于哪个模型、存了多少 token"，不关心底层字节差异。

这种设计带来的好处是缓存复用变得可行。当同一个请求从 7B 模型切换到 13B 模型时（比如 7B 处理不了，升级到 13B），如果两个模型的 tokenizer 一致，那么已经生成的 token 的 KV 缓存理论上可以部分复用。MFS 通过记录每个 block 的 token 范围和模型归属，在切换时尽量保留可复用的部分，只重新计算不兼容的层。这比完全重新 prefill 要快得多。

注意：跨模型 KV 缓存复用有一个前提，就是不同模型的注意力机制要足够相似。如果一个是 MHA、一个是 GQA，头数对不上，复用就会受限。MFS 在论文里应该处理了这种异构情况，但实际部署时还是要根据模型家族的具体配置来评估复用收益。

2.3 调度器如何让 token 生成延迟降下来

延迟降低 56.1% 这个数字，主要来自调度层面的优化。传统多模型服务里，每个模型有自己的请求队列，调度器各自为政。一个请求如果需要在模型间流转，要经历"排队-执行-再排队-再执行"的过程，中间还有缓存换入换出的开销。MFS 把模型家族视为一个整体，用一个全局调度器来分配请求。

全局调度器的核心策略是"缓存感知调度"。当新请求进来时，调度器不只看哪个模型有空闲算力，还要看哪个模型的缓存里已经有这个请求相关的上下文。比如一个多轮对话请求，前几轮在 7B 上处理过，缓存里还留着历史 token 的 KV。如果这一轮继续用 7B，缓存直接命中，prefill 几乎为零；如果换到 13B，缓存不命中，就要重新算。调度器会优先选择缓存命中率高的模型，除非 7B 的负载已经饱和。

另一个优化点是"批量合并"。MFS 会把发往不同模型的请求在调度层面做 batch 合并，让 GPU 在一次 kernel 执行中处理更多 token。虽然不同模型的权重不同，但 MFS 可能通过模型并行或时间片轮转的方式，让多个模型的 decode 阶段交错执行，填满 GPU 的空闲周期。这种细粒度的调度，是延迟降低的主要来源。

3. 从请求到 token：MFS 服务流程的完整还原

3.1 请求接入与模型路由的决策依据

一个请求到达 MFS 后，第一站是接入层。接入层要做的事情包括：解析请求格式、提取关键信息（比如 prompt 长度、期望的 max tokens、是否有历史会话 ID）、然后决定路由到哪个模型。这个决策不是拍脑袋，而是基于几个维度的综合评分。

第一个维度是请求复杂度。MFS 可能内置了一个轻量级的复杂度评估器，根据 prompt 的长度、词汇多样性、是否包含推理链关键词等特征，给出一个粗略的难度分。简单请求走小模型，复杂请求走大模型。第二个维度是缓存亲和性。如果请求带有会话 ID，MFS 会查这个会话之前在哪个模型上处理过，优先路由到同一个模型，最大化缓存复用。第三个维度是当前负载。如果目标模型的队列已经很长，调度器会考虑降级到稍小但空闲的模型，用一点质量换延迟。

这三个维度的权重是可以配置的。在延迟敏感的场景下，缓存亲和性和负载权重大一些；在质量敏感的场景下，复杂度权重大一些。MFS 应该提供了相应的配置接口，让运维人员根据业务特点调参。

3.2 Prefill 阶段的缓存查找与增量计算

请求路由确定后，进入 prefill 阶段。这个阶段的目标是把 prompt 里所有 token 的 KV 缓存算出来，为后续的 decode 做准备。MFS 在这里做了一个关键优化：缓存查找。

具体流程是这样的：系统先根据会话 ID 或 prompt 前缀，在统一缓存池里查找是否已有匹配的 KV block。如果有，就把这些 block 标记为"已命中"，只对未命中的部分做增量计算。比如一个多轮对话，前 500 个 token 的缓存还在，新的一轮只增加了 100 个 token，那么 prefill 只需要算这 100 个 token 的 KV，前 500 个直接复用。

这个查找过程依赖一个高效的前缀匹配算法。MFS 可能用了类似 radix tree 的结构来索引缓存 block，按 token 序列的前缀来组织。查找的时间复杂度与 prompt 长度相关，但通常远小于重新计算 KV 的开销。对于长上下文场景，这个优化的收益非常明显。

实操心得：缓存命中的前提是 tokenizer 一致。如果模型家族里有的模型用了不同的 tokenizer，前缀匹配就会失效。部署时一定要确认所有模型的 tokenizer 版本一致，否则缓存复用率会大打折扣。

3.3 Decode 阶段的 token 生成与缓存追加

Prefill 完成后，进入 decode 阶段，也就是逐个生成 token 的过程。每生成一个 token，MFS 要做三件事：用当前 token 的 query 和缓存里的 key 做注意力计算，得到输出分布；从分布里采样出下一个 token；把新 token 的 KV 追加到缓存池里。

MFS 在 decode 阶段的优化主要体现在缓存追加的效率上。传统做法是每个请求维护一个连续的缓存区域，追加时直接往后写。但共享缓存池里，block 可能不连续，追加时要处理跨 block 的情况。MFS 通过预分配和批量追加来减少开销：当一个 block 快满时，提前分配下一个 block，避免在 decode 的关键路径上做内存分配。

另一个优化是"连续批处理"（continuous batching）。MFS 不会等一个请求完全生成完再处理下一个，而是把多个请求的 decode 步骤交错在一起。当一个请求在等待采样结果时，GPU 可以切换到另一个请求的注意力计算。这种交错执行能显著提高 GPU 利用率，尤其是在请求长度差异很大的场景下。

3.4 请求结束后的缓存回收与复用标记

请求生成完所有 token 后，MFS 不会立即释放它的 KV 缓存。相反，缓存会被标记为"可复用"，保留一段时间。如果同一个会话的下一个请求很快到来，就能直接命中。如果超过一定时间没有复用，缓存才会被回收，block 归还到空闲池。

这个"延迟回收"策略是 MFS 提升缓存命中率的关键。在多轮对话场景里，用户往往会在几秒到几分钟内继续提问，如果缓存立即释放，下一轮就要重新 prefill。保留缓存虽然占用显存，但换来的延迟降低是值得的。MFS 应该有一个基于 LRU 或 LFU 的回收策略，在显存压力和命中率之间做平衡。

4. 实测数据背后的工程细节：56.1% 延迟降低从哪来

4.1 基准测试的配置与对比维度

要理解 56.1% 这个数字，得先看测试是怎么做的。虽然论文正文没有给出完整配置，但根据 EuroSys 论文的常见做法，可以推断几个关键维度：模型家族可能包含 7B、13B、70B 三个尺寸，硬件可能是 A100 或 H100 集群，请求负载模拟了真实场景的混合流量——短请求、长请求、多轮对话按一定比例混合。

对比的基线应该是传统的独立部署方案：每个模型单独起一个服务实例，各自管理 KV 缓存，请求通过一个简单的负载均衡器分发。这种方案在工业界很常见，因为实现简单、隔离性好。MFS 要证明的就是，在模型家族场景下，共享架构比独立部署更优。

测试指标除了 token 生成延迟，应该还包括吞吐量、缓存命中率、显存利用率等。56.1% 的延迟降低是综合结果，可能在不同负载下有所波动。比如在缓存命中率高的多轮对话场景，延迟降低可能超过 60%；在全是新请求的场景，降低幅度可能小一些。

4.2 延迟降低的归因分析

把 56.1% 拆开看，大概来自三个部分。第一部分是缓存复用带来的 prefill 减少。在多轮对话里，如果缓存命中率达到 70%，prefill 的计算量就能减少 70%，这部分对延迟的贡献可能占一半左右。第二部分是调度优化带来的排队减少。全局调度器让请求在模型间更均匀地分布，减少了单个模型的队列积压，这部分贡献可能占三成。第三部分是显存利用率提升带来的并发增加。共享缓存池减少了碎片，同样显存能跑更多并发请求，摊薄了每个请求的等待时间。

这三部分不是简单相加，而是相互增强的。缓存复用减少了计算量，让调度器有更多空间做批量合并；批量合并又提高了 GPU 利用率，反过来让缓存管理更高效。MFS 的设计精髓就在于把这些优化点串成了一个正反馈循环。

4.3 和 vLLM PagedAttention 的异同

熟悉推理服务的人可能会问：MFS 和 vLLM 的 PagedAttention 有什么区别？两者都用了分页的 KV 缓存管理，但目标不同。PagedAttention 解决的是单个模型内缓存碎片和共享的问题，让不同请求的 KV 缓存可以灵活共享物理块。MFS 解决的是多个模型之间缓存共享的问题，跨模型、跨请求地复用缓存。

可以这样理解：PagedAttention 是模型内部的缓存虚拟化，MFS 是模型家族层面的缓存虚拟化。MFS 可能借鉴了 PagedAttention 的 block 管理思路，但增加了模型维度的索引和调度。在实际部署中，两者可以结合使用——每个模型内部用 PagedAttention 管理缓存，模型之间用 MFS 做统一调度和跨模型复用。

5. 落地 MFS 思路时容易踩的坑

5.1 模型异构性带来的缓存不兼容

第一个坑是模型架构差异。如果模型家族里的模型来自不同厂商，注意力机制、位置编码、归一化方式都可能不同，KV 缓存根本无法复用。比如一个用 RoPE，一个用 ALiBi，缓存里的 key 表示的含义就不一样，强行复用会导致输出质量下降。MFS 在论文里应该假设了模型家族是同构或近似同构的，但实际部署时，这个假设不一定成立。

解决办法是在模型选型阶段就考虑兼容性。尽量选择同一系列、同一架构的模型，比如 Llama 家族的 7B、13B、70B，它们的注意力机制和位置编码是一致的，缓存复用可行性高。如果必须混用不同架构，就要在 MFS 里配置缓存隔离策略，让不兼容的模型各自管理缓存，只共享调度层。

5.2 缓存命中率低于预期时的调参方向

第二个坑是缓存命中率上不去。理论上多轮对话应该命中率很高，但实际可能因为几个原因掉下来：会话 ID 生成不稳定，每次请求都当成新会话；缓存回收太激进，用户还没追问缓存就被清了；tokenizer 不一致导致前缀匹配失败。

调参方向有几个：延长缓存保留时间，从默认的几十秒调到几分钟；增大缓存池容量，给复用留更多空间；检查会话 ID 的生成逻辑，确保同一用户的连续请求能关联上。如果这些都没问题，就要看请求模式了——如果业务本身就是大量独立的单轮请求，缓存命中率天然就低，这时候 MFS 的收益主要来自调度优化而非缓存复用。

5.3 显存压力与缓存容量的平衡

第三个坑是显存不够用。共享缓存池虽然提高了利用率，但总容量还是受限于 GPU 显存。如果模型家族里有 70B 这样的大模型，权重本身就占了大头，留给 KV 缓存的空间很有限。这时候如果缓存池设得太大，会导致 OOM；设得太小，命中率又上不去。

平衡的方法是做分级缓存。把最常复用的缓存放在 GPU 显存里，次常用的放在主机内存里，再次的放在 SSD 上。MFS 可能没有实现完整的分级缓存，但实际部署时可以结合操作系统的页缓存机制，让不常用的 KV block 被换出到内存，需要时再换入。代价是换入换出的延迟，但对于命中率不高的长尾请求，这个代价比重新计算要小。