MoE大模型推理显存不够？Slotstream与SSD专家流式加载实战解析

之前帮朋友调一个 MoE 大模型推理性能时，最头疼的不是算子本身，而是显存总是不够用。模型参数几百 B，单卡 80GB 显存根本塞不下，强行塞进去之后 KV Cache 又没地方放。后来接触到 SSD Expert Streaming 这类思路，才发现“把模型权重放到 SSD 上按需加载”并不是异想天开，MoE 模型本身的结构就非常适合这种玩法。Slotstream 正是这类方案里很有代表性的一个方向：通过显存 slot 缓存加 SSD 流式预取，尝试绕过 LLM 推理中的 Memory Wall。

这篇文章会拆解 Slotstream 这类方案的核心设计逻辑，包括它解决了什么问题、关键难点在哪里，并提供一个可以直接运行的 Python 模拟器，帮助理解 slot 缓存、预取策略和命中率之间的关系。不管你是做大模型推理优化，还是单纯对 MoE 模型感兴趣，都值得花几分钟看完。

1. 背景：LLM 推理的 Memory Wall

1.1 什么是 LLM 的 Memory Wall

Memory Wall 在 LLM 语境下通常指两层含义：显存容量墙和显存带宽墙。

先看容量墙。主流训练和推理卡的单卡显存普遍在 80GB 到 141GB 之间，而大模型参数动辄几十 B 甚至几百 B。一个 7B 模型用 FP16 存储，权重大约 14GB，单卡还能放下；但到了 70B、100B+ 的规模，单卡完全放不下。你可能说多卡并行可以解决，但多卡并行意味着通信开销、调度复杂度、硬件成本同步上升，并不是所有团队都能承担。

再看带宽墙。推理的 decode 阶段是典型的 memory-bound 场景，每生成一个 token 都要把相关参数从显存读一遍。即便模型权重勉强放进显存，显存带宽也决定了每秒钟能生成多少 token。H100 的 HBM 带宽大约 3TB/s 级别，但 model 参数越大，每个 token 需要的读取量越大，单位时间能生成的 token 数就越低。这就是 Memory Wall 的本质：容量限制能装什么模型，带宽限制能跑多快。

1.2 MoE 模型为什么适合 SSD 流式加载

MoE（Mixture of Experts，混合专家）模型和传统 Dense 模型最大的区别在于：它的总参数量非常大，但单次推理只激活一小部分参数。

一个典型的 MoE Transformer 层会把原来的 FFN（前馈网络）替换成 Router 加多个 Expert。Router 会根据当前 token 的特征，从 N 个专家中选出 top-k 个专家参与计算，再把结果加权合并。以 Mixtral 8x7B 为例，它有 8 个专家，每个 token 只走其中 2 个专家，实际参与计算的参数只有总参数的 1/4 左右。DeepSeek-V2、Qwen2-MoE 这类模型也都是类似的设计，专家数量更多，稀疏性更明显。

这带来一个关键机会：模型总参数可能放不进显存，但每个 token 真正需要的“活跃专家”一定能放进去。如果能把不活跃的专家放到 SSD 这样的低成本存储上，等路由结果出来后再按需加载，理论上就可以用很低的硬件成本跑超大 MoE 模型。这就是 SSD Expert Streaming 能成立的底层原因。

1.3 已有方案为什么不够

在 Slotstream 这类方案出现之前，业界已经有不少尝试突破 Memory Wall 的思路。

第一类是做模型并行，把模型切分到多张卡上。这个方法能扩大总显存，但通信瓶颈会随模型规模增长越来越明显，而且部署成本很高。

第二类是量化，把 FP16 权重压缩成 INT8 或 INT4。量化确实能直接减少显存占用，但压缩比例有限，低于 4bit 之后精度风险明显上升。

第三类是粗粒度 CPU Offload，把整层或整块权重放到 CPU 内存，用的时候再拷回显存。CPU 内存和 GPU 之间走 PCIe，延迟和带宽都远不如 HBM，如果加载粒度太大、缺乏预取，很容易出现 GPU 空等。

Slotstream 的不同之处在于，它按照 MoE 模型天然的“专家粒度”进行精细调度，配合显存 slot 缓存和异步流式预取，把 SSD 的高容量和低单次访问成本利用起来，听起来像是给 LLM 推理加了一层软件管理的 cache。

2. Slotstream 核心设计思路

2.1 名字拆解

Slotstream 这个名字可以拆成三个部分：

• Slot：表示显存中划分出来的固定大小缓存槽，每个槽可以容纳一个专家或专家参数分片。
• Stream：表示持续不断的异步流式加载，提前把下一批可能用到的专家从 SSD 搬到显存。
• Breaking the Memory Wall：表示最终目标是突破显存容量和带宽的制约。

合起来看，Slotstream 解决的核心问题是：如何在 SSD 上存放大量专家参数，同时保证推理时加载延迟对计算过程基本不可见。

2.2 整体架构

从数据流视角来看，Slotstream 涉及 5 个核心组件：

code复制Token ──> Router ──> expert ids
                      │
                      v
             ┌── Slot Cache Manager ──┐
             │  显存固定大小的 slots   │
             └────────┬───────────────┘
                      │ hit / miss
                      v
             ┌── Expert Store（SSD）──┐
             │  专家参数池            │
             └────────────────────────┘
                      ▲
                      │ 异步预取
             ┌── Stream Engine ────────┐
             │  预测 + 预取 + 流水线   │
             └────────────────────────┘

• Expert Store：SSD 上的专家参数池，按 (layer_id, expert_id) 逻辑切分存储。
• Slot Cache Manager：管理显存中的一组 slot，负责查缓存、占用和淘汰。
• Router Predictor：根据当前的路由信息或历史统计，预测未来会被访问的专家。
• Stream Engine：负责从 SSD 异步加载专家参数，并尽可能与计算重叠。
• Compute Engine：GPU 上真正执行 MoE 计算的模块。

整体流程是：Router 先算出当前 token 需要哪些专家，Slot Cache Manager 检查这些专家是否已经在显存 slot 中；如果命中，直接参与计算；如果未命中，则向 Stream Engine 发出加载请求，从 SSD 读取专家参数并放入空闲 slot，然后继续计算。同时 Stream Engine 还会根据预测结果，提前加载下一批候选专家。

2.3 与普通缓存的异同

如果把 Slotstream 和 CPU 的 L1/L2 Cache 做对比，会发现核心思想非常相似：都是利用局部性原理，把未来大概率访问的数据放在更快的存储层。

区别在于三点：

• 管理粒度：CPU 缓存以 cache line 为单位，Slotstream 以“专家”为单位，粒度更大，每个数据块的大小从几十 MB 到数百 MB 不等。
• 预取依据：CPU 缓存主要靠硬件预取器识别线性模式，而 Slotstream 可以直接拿到 Router 产生的专家 id 或 logits，相当于有一个“软件预告”，这是很大的优势。
• 替换策略：CPU 缓存由硬件决定替换，Slotstream 可以针对 MoE 访问模式定制策略，比如按专家热度排序、按层分组淘汰。

栈式理解之后，逻辑就很清晰了：Slotstream 本质上是一个软件定义的、面向 MoE 推理的专用缓存系统。

3. 关键难点与解决逻辑

3.1 专家粒度大，加载一个专家太慢怎么办

MoE 模型里的一个专家可能就有几 GB 大小。比如 8x7B Mixtral，每个专家约 7B / 8 ≈ 900M 参数，FP16 下约 1.8GB。如果是更大的 MoE 模型，单个专家可能达到几十 GB。一次性把整个专家从 SSD 加载到显存，延迟可能长达几十毫秒甚至上百毫秒，这对推理延迟是完全不可接受的。

解决思路是分片流水线。把专家参数切成多个 chunk，Stream Engine 按 chunk 顺序加载，第一个 chunk 到达显存后就可以开始计算。这样加载延迟就和计算延迟重叠起来了。这个思路和 CPU 预取本质上一样，只不过数据块更大、流水线深度需要更精细地调节。

3.2 预取依赖未来的路由结果怎么办

预取的前提是知道“未来会用到哪些专家”。但 Router 产生的结果是逐步产生的，当前层算完了才知道当前层的路由结果，下一层的路由结果要等下一层输入算出来才知道。

解决思路一般有两种。第一种是利用历史统计信息，比如维护一个专家热度表，把最近频繁被访问的专家提前预加载到显存。第二种是训练一个专门的路由预测网络，根据当前 token 的 embedding 特征预测下一层最可能访问的专家。实际工程中更常见的是一种混合策略：热度统计打底，加上当前 token 的路由 logits 做修正。

Slotstream 的核心价值之一，就是把这些预测逻辑纳入一个整体框架，而不是在系统外部零散地处理。

3.3 SSD 带宽不够怎么办

SSD 的顺序读带宽虽然能到几个 GB/s（PCIe Gen4 NVMe SSD 约 5-7GB/s，Gen5 更高），但和显存带宽相比仍然低了几个数量级。面对大模型推理的吞吐需求，SSD 带宽很可能成为新瓶颈。

应对办法主要有几条：一是尽量把专家参数按访问频率排列到 SSD 的相邻物理区域，把随机读变成顺序读，提升有效带宽；二是用多个 SSD 实例并发读取，摊薄单盘压力；三是控制预取总量，不要盲目把太多专家往显存搬，否则会挤占计算需要的显存空间。

3.4 模型更新后参数不一致怎么办

如果模型权重在线更新，或者同时服务多个版本的模型，SSD 上存放的专家参数和显存中的 slot 内容可能出现版本不一致。工程上一般会给每个专家的参数带版本号，slot 命中时不仅要检查专家 id，还要检查版本号是否匹配。版本不一致时把旧参数淘汰，重新从 SSD 加载新版本。

这个问题的另一个变体是：同一个专家出现在不同的训练 checkpoint 中，参数发生了变化，但 id 没有变化。如果缓存系统只按 id 判断命中，就会拿到旧参数，产生严重推理错误。

4. 环境准备与版本说明

这里先说明，本文的模拟环境不需要 GPU，也不需要安装 CUDA、PyTorch 等重型依赖，只需要 Python 3.8 以上环境，标准库中的 collections 就足够跑了。

如果你后续要把它接入真实推理框架，版本需要根据项目实际情况调整。本文示例以常见的 Python 环境为例，重点演示配置和设计思路，不依赖特定框架的 API。

模拟实验用到的核心概念有三个：SSD 专家存储、显存 slot 缓存、预取策略。下面逐个实现。

5. 完整实战案例：用 Python 模拟 Slotstream

5.1 模拟场景设计

为了直观地展示 slot 缓存和预取的作用，我设计了一个简化场景：

• 模型有 2 层，每层有 8 个专家，共 16 个逻辑专家。
• 每个 token 运行时会访问 2 个专家（对应 top-2 路由）。
• 显存中最多容纳 4 个、6 个或 8 个专家 slot。
• 路由模式设计成“周期性切换”：偶数 token 访问一组专家，奇数 token 访问另一组专家。

这个模式虽然简单，但能很好地模拟访问局部性变化，以及预取在应对“访问集合切换”时的收益。

5.2 定义 SSD 专家存储

先定义一个 ExpertStore，模拟 SSD 上的专家参数池。真实场景中这里对应磁盘上的模型权重文件，按专家切分配置；这里用字典模拟，读取即返回一个参数标记字符串。

python复制# 文件路径：slotstream_sim.py
class ExpertStore:
    """模拟 SSD 上的专家参数存储。"""

    def __init__(self, num_layers=2, num_experts=8):
        self.store = {
            (layer_id, expert_id): f"params(layer={layer_id}, expert={expert_id})"
            for layer_id in range(num_layers)
            for expert_id in range(num_experts)
        }

    def read(self, key):
        # 真实场景中这里是 SSD 异步读取，返回 Tensor
        return self.store[key]

ExpertStore 的核心是 read 方法。真实实现里，read 应该触发一次异步 I/O 操作，从磁盘加载专家权重并写入 pinned memory，再由 copy engine 拷贝到显存。这里为了逻辑清晰，直接用字典取值代替。

5.3 定义显存 Slot 缓存

接下来定义一个 SlotCache，它是整个方案的核心。功能包括：

• 判断某个专家是否已缓存。
• 命中时更新 LRU 顺序。
• 未命中时加载并淘汰最久未使用的 slot。

python复制# 文件路径：slotstream_sim.py
from collections import OrderedDict


class SlotCache:
    """基于 LRU 的显存 Slot 缓存。"""

    def __init__(self, max_slots: int):
        self.max_slots = max_slots
        self.data = OrderedDict()

    def has(self, key) -> bool:
        """检查 key 是否命中，命中则更新 LRU 顺序。"""
        if key in self.data:
            self.data.move_to_end(key)
            return True
        return False

    def add(self, key, value):
        """新增或更新缓存，缓存满时淘汰最久未使用的条目。"""
        if key in self.data:
            self.data.move_to_end(key)
            return
        if len(self.data) >= self.max_slots:
            self.data.popitem(last=False)
        self.data[key] = value

    def size(self):
        return len(self.data)

几个实现细节值得注意：

• 用 OrderedDict 维护 LRU 顺序，move_to_end 可以在 O(1) 时间内把命中的 key 移到队尾。
• popitem(last=False) 弹出队首元素，也就是最久未使用的元素。
• add 方法里没有区分“新加载”和“替换”，即使重复添加同一个 key，也会维护 LRU 顺序。

在真实实现里，has 和 add 之间可能存在并发问题，比如一个专家正在加载过程中另一个请求再次查询，需要考虑“pending 状态”，避免重复加载。这里先不扩展，后面的常见问题和最佳实践部分会提到。

5.4 定义路由模式

模拟中让路由模式按 token id 周期性切换，看起来像两类 token 交替访问两组不同的专家。

python复制# 文件路径：slotstream_sim.py
def route_for_token(token_id: int, layer_count=2):
    """
    生成当前 token 的路由结果。
    偶数 token：访问 expert 1、2；
    奇数 token：访问 expert 3、4。
    """
    if token_id % 2 == 0:
        return [(layer, 1) for layer in range(layer_count)] + \
               [(layer, 2) for layer in range(layer_count)]
    else:
        return [(layer, 3) for layer in range(layer_count)] + \
               [(layer, 4) for layer in range(layer_count)]

每个 token 访问的 key 集合有 4 个元素：第 0 层的 expert 1、expert 2，第 1 层的 expert 1、expert 2。奇数 token 则换成 expert 3、expert 4。这个设计制造了明显的访问局部性切换，方便观察缓存命中率的变化。

5.5 定义预取策略

预取是本实验的核心对比项。我先实现两个版本：

• 无预取：只在访问时加载。
• Oracle 预取：提前知道下一个 token 会访问哪些专家，直接预加载。这个版本展示理想上界。

python复制# 文件路径：slotstream_sim.py
def run_simulation(num_tokens, max_slots, use_prefetch=False):
    store = ExpertStore()
    cache = SlotCache(max_slots)
    hits = 0
    total = 0

    for token_id in range(num_tokens):
        route = route_for_token(token_id)

        # 正常推理：查缓存，未命中则从 SSD 加载
        for key in route:
            total += 1
            if cache.has(key):
                hits += 1
            else:
                cache.add(key, store.read(key))

        # 预取策略：把下一个 token 会用到的专家提前加载
        if use_prefetch:
            next_route = route_for_token(token_id + 1)
            for key in next_route:
                if not cache.has(key):
                    cache.add(key, store.read(key))

    return hits / total

这里 Oracle 预取只是为了演示“预取机制本身”能带来多大收益。真实场景不可能知道下一个 token 的精确路由结果，需要通过 Router logits 或者历史统计来预测。但先看理想上界，能帮助我们理解 slot 数量和预取效果的关系。

5.6 运行模拟

写一个主入口，对比不同 slot 数量和预取策略下的命中率。

python复制# 文件路径：slotstream_sim.py
if __name__ == "__main__":
    for slots in [4, 6, 8]:
        for prefetch in [False, True]:
            hit_rate = run_simulation(
                num_tokens=200,
                max_slots=slots,
                use_prefetch=prefetch,
            )
            print(f"slots={slots}, prefetch={prefetch}, hit_rate={hit_rate:.2%}")

运行后观察结果，预期能看到几个明显趋势：

• slot 数量越大，无预取时的命中率越高。因为缓存能容纳更多专家。
• slot 数量等于 4 且没有预取时，命中率很低。因为每个 token 的 4 个 key 和上一个 token 完全不同，缓存永远在“颠簸”。
• 开启 Oracle 预取后，即使 slot 数量只有 4，命中率也有明显提升。因为预取提前把下一组专家搬进了显存，访问时直接命中。

注意，这个模拟结果只用来理解设计逻辑，不表示真实推理性能。真实场景中专家加载时间、SSD 带宽、计算重叠等因素会直接影响实际收益。

5.7 用频率统计替代 Oracle 预取

Oracle 预取在现实中不现实，我把它换成基于历史访问频率的预测器，更贴近真实工程。

python复制# 文件路径：slotstream_sim.py
from collections import Counter


class FrequencyPredictor:
    """基于历史访问频率的专家预测器。"""

    def __init__(self, top_k=4):
        self.counter = Counter()
        self.top_k = top_k

    def observe(self, keys):
        self.counter.update(keys)
        # 防止 Counter 无限增长
        if len(self.counter) > 10000:
            self.counter = Counter(dict(self.counter.most_common(1000)))

    def predict(self):
        return [key for key, _ in self.counter.most_common(self.top_k)]

修改 run_simulation，增加一个 prefetch_mode 参数：

python复制# 文件路径：slotstream_sim.py
def run_simulation(num_tokens, max_slots, prefetch_mode="none"):
    store = ExpertStore()
    cache = SlotCache(max_slots)
    predictor = FrequencyPredictor(top_k=max_slots)
    hits = 0
    total = 0

    for token_id in range(num_tokens):
        route = route_for_token(token_id)

        for key in route:
            total += 1
            if cache.has(key):
                hits += 1
            else:
                cache.add(key, store.read(key))
            predictor.observe([key])

        if prefetch_mode == "oracle":
            next_route = route_for_token(token_id + 1)
            for key in next_route:
                if not cache.has(key):
                    cache.add(key, store.read(key))
        elif prefetch_mode == "frequency":
            for key in predictor.predict():
                if not cache.has(key):
                    cache.add(key, store.read(key))

    return hits / total

频率预测在这个“严格交替访问”的场景下效果不如 Oracle，因为它只能统计历史热度，无法识别“下一次会切换专家集合”的模式。但这恰好说明了一个工程重点：预取器的质量直接决定 SSD streaming 方案能不能落地。如果预测不准，预取进来的专家用不上，反而浪费显存和 SSD 带宽。

6. 真实推理框架中的集成方向

6.1 自定义 MoE 层加载逻辑

在真实 PyTorch 项目中，最直接的接入方式是自定义 MoE Expert 模块。核心逻辑是：检查显存缓存中有没有这个专家的权重，没有就触发异步加载。

下面给一个示意片段，需要根据实际框架版本调整：

python复制# 文件路径：ssd_expert_layer.py（示意代码）
import torch
import torch.nn.functional as F


class SSDExpertLinear(torch.nn.Module):
    """
    从 SSD 加载权重的专家线性层。
    这里只展示核心逻辑，真实实现需要配合 pinned memory、
    异步 I/O 和显存拷贝。
    """

    def __init__(self, expert_key, store, cache):
        super().__init__()
        self.expert_key = expert_key
        self.store = store
        self.cache = cache

    def forward(self, x):
        if not self.cache.has(self.expert_key):
            # 异步加载：从 SSD 读取，写入显存 slot
            weight = self.store.read(self.expert_key)
            self.cache.add(self.expert_key, weight)
        else:
            weight = self.cache.get_data(self.expert_key)

        return F.linear(x, weight)

这段代码的要点是：

• store.read 在真实实现中应该返回一个 torch.Tensor，而不是模拟用的字符串。
• cache.has 只能反映缓存状态，真实场景中还要考虑 loading 状态。
• 更合理的做法是使用 CUDA Stream 做异步拷贝，让加载和计算重叠。

6.2 与 vLLM / SGLang 等框架的接入点

如果要在 vLLM 或 SGLang 这类推理框架上做 SSD Expert Streaming，通常需要改两个位置。

第一个位置是模型加载部分。默认情况下这些框架会一次性把所有权重 load 到 GPU，要做 SSD offload，需要在模型加载阶段把专家参数单独识别出来，写到 SSD 或映射文件中，而不是直接进显存。

第二个位置是调度和算子执行部分。MoE 算子在执行前需要拿到“当前 token 需要哪些专家”的信息，这就需要在 scheduler 或 model executor 里增加一层查询，把缺失的专家加载请求提前发出去。

这个过程的改造量不小，但基本思路是清晰的：把专家参数从“模型权重”的概念中剥离出来，当成“可流式加载的缓存块”来管理。

6.3 异步 I/O 层面的建议

真实系统中，从 SSD 读取专家权重到显存这个过程，推荐用异步 I/O 接口实现。Linux 下常见的选择是 io_uring 或 libaio，加载到 pinned memory 之后，用 CUDA copy engine 从 pinned memory 拷贝到显存，避免占用计算 stream。

这里要注意的是，SSD 读取和显存拷贝是两个不同的阶段，应该分别做流水线处理。理想状态下，第 N 层在计算时，第 N+1 层需要的专家同时在 SSD 读取和显存拷贝中，这样加载延迟就被计算时间完全隐藏了。

7. 常见问题与排查思路

这里面最容易被忽视的是“加载并发控制”。多个请求同时触发同一个专家的加载时，如果没有去重机制，会有大量重复读盘。建议在缓存层增加 per-key 的 loading 状态，只有一个请求真正触发加载，其他请求等待加载完成后再共用同一个结果。

8. 最佳实践与工程建议

如果你打算在自己的推理服务里尝试 SSD Expert Streaming，下面几条建议可以参考。

第一，先做 profiling。不要凭直觉判断“显存不够所以上 SSD”，建议先把模型推理过程中的显存占用、带宽利用率和各阶段耗时数据拿出来看。如果瓶颈真的在显存容量，再做 SSD 方案才有意义。

第二，量化优先。在把专家放到 SSD 之前，先对专家参数做 INT8 或 INT4 量化。量化能直接减小每个专家的体积，降低 SSD 读取量，也就等效于提高了有效加载带宽。SSD 方案和量化不是互斥关系，而是互补关系。

第三，专家热度表是性价比很高的配置。从训练数据或历史推理日志中统计每个专家的访问频率，生成离线热度表，启动时把高热专家常驻显存，低热专家留在 SSD。这种静态优化几乎零成本，但能明显提升命中率。

第四，监控指标要完整。建议至少监控这几项：缓存命中率、SSD 读取带宽、专家平均加载延迟、计算与加载的重叠率、显存占用比例。命中率只能说明缓存做得好不好，真正决定推理速度的是加载延迟是否被计算过程隐藏。

第五，谨慎处理模型热更新。在线更新模型权重时，必须确保缓存中的专家版本号同步失效，否则会出现“混合新旧参数”的推理错误。更稳妥的做法是在更新期间清空专家缓存，或者按版本号隔离缓存空间。

第六，安全与权限问题。如果 SSD 上存储的是模型权重文件，注意文件权限、校验和备份。生产环境变更模型文件之前，先备份原文件，并在测试环境验证加载流程，避免因为文件损坏导致线上推理异常。

9. 总结与学习路线

Slotstream 这类 SSD Expert Streaming 方案，本质上是在 MoE 模型的“远存储”和“近存储”之间建立一套软件管理的缓存体系。它利用 MoE 模型天然稀疏激活的特点，把显存容量墙的压力转嫁到 SSD 容量上，再用预取、slot 缓存和异步流水线把 SSD 的高延迟隐藏起来。

读完这篇文章，你应该掌握了三类关键内容：Memory Wall 的本质、Slotstream 的组件架构和工作流程、以及如何用 Python 模拟器验证缓存和预取逻辑的效果。

接下来如果还想深入，建议按这个顺序学习：

• 阅读一个开源 MoE 推理框架（如 vLLM 的 MoE kernel 实现），理解真实专家计算怎么调度。
• 研究 MoE 路由预测的论文和方案，思考如何用历史统计或轻量网络提高预取准确率。
• 动手把你手头的小型 MoE 模型改造一遍，先实现专家参数按层切分，再尝试把低热专家放到本地磁盘，配合量化测量推理吞吐变化。

最后提醒一句：模拟器里看到的命中率提升只是第一步，真实的收益要看加载延迟和计算重叠率。如果你也在做 MoE 推理优化，建议先从 profiling 开始，把显存和带宽数据摸清楚，再决定要不要引入 SSD 这条路线。希望这篇内容对你有帮助，收藏备用可以让后面实际动手时更快找到思路。