12G显存跑16B MoE模型：分层调度实战指南

说个真实的开场。我最初想在一台12G显存的笔记本上加载16B参数量级的MoE模型，结果还没开始推理就被OOM（显存溢出）直接劝退。那一刻我盯着错误日志，觉得自己在拿一杯水去装一浴缸的洗澡水。但回头仔细算了算账，发现我进入了一个误区——我一直在想怎么把模型完整“塞进”显存，却忽略了MoE模型的核心特点：它的参数虽然多，但每一次推理只激活其中一小部分。于是我把方案彻底换掉，从“硬塞”改成“分层调度”：GPU只放每一步计算都必须要用的共享层和热门专家，全部专家权重留在内存里，按路由结果动态换入显存。折腾了几天之后，模型在12G显存的笔记本上稳定跑起来了，生成速度虽然没法跟服务器比，但也到了勉强可用的水平。这篇分享就是想把整个思路和实操过程写清楚，适合手里只有一台游戏本、又想在本地折腾16B规模MoE模型的同学，其中涉及的计算方法和调参逻辑同样对更大规模的模型适用。

1. 先给显存算笔账：MoE-16B的真实体重到底是多少

1.1 纸面参数和实际显存占用不是同一个概念

很多同学一看“16B参数”，第一反应就是用参数乘以2个字节，算出FP16精度下约32GB的显存需求。12G显存的机器连零头都不够。但这里有个关键问题：MoE模型和传统的Dense模型不太一样，16B是“总参数”，不是“每次推理都会用到的参数”。

以典型的MoE结构为例，整个模型大致可以分为两类：

• 共享部分：包括embedding、attention层、共享专家、输出层，这一部分不管来什么token都得完整算一遍。
• 路由专家：一个MoE层里有几十个甚至上百个专家，但每个token只会被门控网络（Router）选择其中Top-2或者Top-4个专家来激活计算。

换句话说，名为16B的模型，实际每次前向推理参与计算的参数量可能只有3-4B。这就是MoE模型可以通过“分层调度”跑在小显存上的前提。如果是Dense模型，激活参数等于总参数，卸载到哪里都得全量读一遍，那才是真的物理上没法绕开。

1.2 为什么Dense卸载很惨，MoE却可以“钻空子”

我做这个方案之前，试过把一个普通7B Dense模型用CPU offload的方式跑在12G显存笔记本上，结果非常惨。Dense模型推理时每一层每一块权重都是必须的，所以CPU内存和GPU显存之间需要每个token都搬运全部权重，PCIe带宽和内存带宽瞬间打满，生成的每一token都要卡好几秒。

但MoE模型不一样。显存里只需要常驻两类东西：

• 共享部分：每token必算。
• 当前被路由选中的专家：每个token只读几百MB。

那么，把共享部分和一部分访问量最高的专家放在GPU显存里，把剩下的全部专家放在内存里，推理过程中根据路由结果，按需把专家从内存搬到显存，再用完搬回去，理论上是可行的。代价就是牺牲一点速度，换来回显存容量的效果。

这就是“分层调度”的核心思路，也是这个标题想表达的真正意思：不要硬塞，要学会把模型拆成“热数据”和“冷数据”。

2. 分层调度的整体设计：把模型拆成四个独立层次来管理

2.1 第一层：权重分层，GPU只留每步都用的部分

整个方案里最关键的一个决定是：什么权重必须放GPU，什么权重可以放内存。

我的默认规则很简单——“每token都参与计算”的模块全部放GPU，包括：

• token embedding和输出头，这部分参数量不大但每token必用。
• attention相关的Q、K、V和输出投影，这是密集计算部分。
• MoE层中的共享专家（shared expert），如果有的话。
• 所有路由专家的权重则统一放在内存，由调度模块动态管理。

以某个64个路由专家加2个共享专家、总参16B级别的MoE模型为例。4bit量化后，共享部分（约4B参数）大概占2GB显存，64个专家如果全部按4bit加载，总共约6GB。但FP16精度下每一个专家的体量大约是375MB，64个专家全放显存要24GB，显然不现实。但如果只放最热的8个专家在显存里，就是3GB，剩余56个专家放内存，显存占用立刻可控了。

2.2 第二层：专家缓存层，用LRU思想决定谁留在GPU

专家数量众多，但具体到一段真实文本，访问频率是极度不均匀的。有的专家高频率被召唤，有的则在很长一段上下文中都不会被路由选中一次。

所以我在调度模块里维护了一张专家访问记录表，采用类似LRU（最近最少使用）的策略：

• 初始化时所有专家都在内存，显存里不预置专家。
• 前几个token推理时，记录路由选中的专家ID和访问次数。
• 当某个专家的访问次数超过阈值，就在下一次该专家被选中之前，提前把它搬到显存。
• 当显存中的驻留专家数量超过上限，就把最久没被访问的专家换出到内存。

这样做的逻辑是：MoE模型的路由分布通常非常集中，一小部分专家会承担绝大多数计算任务。只要把这部分高频专家稳住，大多数token根本不需要实时从内存换入专家，速度表现会非常接近全量驻留显存的效果。

虽然我在这里不用外文缩写堆概念，但实操中这个缓存模块可以非常简单：一个字典记录“专家ID-最近访问时间”，一个队列记录“驻留专家顺序”，几十行代码就能写完。

2.3 第三层：传输与计算重叠层，不要让换入换出卡住推理流水线

很多人把专家换入换出做成同步操作：先搬权重，再算这部分。这样每一步都有巨大的等待时间。更好的做法是做一个生产者-消费者结构。

具体来说，在推理过程中，我开了两个并行的数据流：

• 主线程负责GPU上的当前层计算。
• 后台线程根据当前token的路由结果，提前把下一层甚至下两层会用到的专家从内存预取到显存。

这个思路和CPU的预取指令有点像，本质是用“空间换时间”的思路。只要后台搬运的速度比GPU计算的速度快，那么用户感知到的延迟就等于GPU计算时间，而不是“内存搬运时间+GPU计算时间”。

在代码里，我会用一个Python列表作为交换缓冲，后台线程把专家张量塞进列表，GPU线程从列表里取。实际操作中，预取深度设在2到4之间效果最好。太深会占用大量显存当缓冲区，太浅则起不到掩盖延迟的作用。

2.4 第四层：上下文分层，别让KV Cache偷偷吃掉显存

还有一个容易被忽略的显存黑洞是KV Cache。即使权重调度做得很好，如果上下文开太长，KV Cache同样能把12G显存吃光。

我算过一笔账：一个常见16B MoE模型如果配置为24层、隐藏层维度2048、32个注意力头，每个头维度128，在FP16精度下，长度为4096的上下文KV Cache大约是：

层数乘以注意力头数再乘以头维度，再乘以2（K和V），再乘以序列长度，再乘以2字节，结果在1GB级别。如果是8192长度，直接就翻倍到2GB以上。在显存本来就捉襟见肘的情况下，这绝对不是小数字。

所以我的第四个分层策略是限制KV Cache的上限，并且设定了一个上下文窗口阈值。超过阈值时，通过截断或者摘要压缩历史对话，而不是让它无限膨胀。这样做的本质是把“模型权重”和“运行时状态”分开管理，两者都不允许独占显存。

3. 实操实录：一台12G笔记本从OOM到跑起来的完整过程

3.1 环境准备与模型选型

整个方案的硬件要求其实不高。我用的是一台双通道DDR4内存、PCIe 3.0接口的笔记本，显卡显存正好12G。操作系统推荐Ubuntu或者Windows下的WSL2，原因是这两者能更方便地使用PyTorch的CUDA支持，同时内存和显存之间的张量传输会更可控。

依赖方面，我使用的主要工具包括：

• Python 3.10及以上版本。
• PyTorch，带CUDA支持。
• Transformers库，用于加载模型结构和权重。
• BitsAndBytes库，用于4bit量化，让专家权重在内存里的体量缩小一半以上。
• Accelerate库，用于处理设备分配。

模型选择方面，我选用的是一个总参数量约16B、在HuggingFace结构里带MoE层的开源模型。它包含64个路由专家和2个共享专家，每个token激活2个路由专家。不同模型的层结构、专家数量可能不同，但分层调度的思路完全通用。

3.2 方案A：自写PyTorch分层调度脚本

我最推荐的方法是写一个简化版的分层调度推理脚本，因为只有自己控制代码，才能针对具体模型做精细优化。下面是一个能跑通核心逻辑的示意代码，实际使用时要根据自己加载的模型结构调整内部属性和函数名。

import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_id = "your-16b-moe-model" tokenizer = AutoTokenizer.from_pretrained(model_id) model = AutoModelForCausalLM.from_pretrained( model_id, load_in_4bit=True, device_map="auto", torch_dtype=torch.float16, ) # 将所有路由专家的权重转移到CPU for layer in model.model.layers: if hasattr(layer, "mlp") and hasattr(layer.mlp, "experts"): for expert in layer.mlp.experts: expert.to("cpu") # 将共享部分固定在GPU for layer in model.model.layers: if hasattr(layer, "mlp") and hasattr(layer.mlp, "shared_expert"): layer.mlp.shared_expert.to("cuda") # 显存驻留专家数上限 MAX_RETAINED_EXPERTS = 8 expert_access_record = {} retained_experts = [] expert_execution_buffer = [] def recall_expert(expert_id, layer_idx): """把指定专家搬到显存，并更新驻留队列""" if expert_id in retained_experts: return if len(retained_experts) >= MAX_RETAINED_EXPERTS: evict_id = retained_experts.pop(0) model.model.layers[layer_idx].mlp.experts[evict_id].to("cpu") expert = model.model.layers[layer_idx].mlp.experts[expert_id] expert.to("cuda") retained_experts.append(expert_id) expert_execution_buffer.append((layer_idx, expert_id)) def process_tokens(input_text, max_new_tokens=64): inputs = tokenizer(input_text, return_tensors="pt").to("cuda") for _ in range(max_new_tokens): with torch.no_grad(): outputs = model(**inputs) next_token_id = torch.argmax(outputs.logits[0, -1, :]).unsqueeze(0) inputs = { "input_ids": torch.cat([inputs["input_ids"], next_token_id.unsqueeze(0)], dim=-1), "attention_mask": torch.ones((1, inputs["input_ids"].shape[-1] + 1), dtype=torch.long, device="cuda"), } # 路由选择会发生在前向传播内部，这里只通过记录完成调度演示 # 实际项目里，需要hook MoE层的router输出才能拿到专家ID return tokenizer.decode(inputs["input_ids"][0], skip_special_tokens=True)

这段代码是示意性质的，因为不同模型暴露的路由信息接口不一样，但核心流程是明确的：

• 固定共享层到GPU。
• 专家冷启动全部在CPU。
• 推理时通过hook或者修改模型内部forward函数，把路由选中的专家ID暴露出来。
• 根据专家访问记录，动态把专家从CPU复制到GPU。

想要拿到每个token被路由到了哪些专家，最稳妥的做法是重写MoE层的前向传播函数，把专家索引以返回值或全局变量的方式记录下来。这个过程大概需要花半小时阅读模型代码，但一旦打通，后面会很顺手。

3.3 方案B：不想写代码就用Ollama的num_gpu_layers

如果不想动代码，Ollama配合GGUF格式模型文件也提供了一种雏形的分层能力。GGUF格式本身支持把不同层拆开，Ollama在加载时会根据num_gpu_layers参数的设定，把一部分层放进显存，其余留在内存。

对于16B MoE模型，一个常见的做法是设定OLLAMA_NUM_GPU_LAYERS为模型总层数的一半左右，比如模型有24层，就设置12层放GPU，剩余12层放CPU。这样做简单有效，但缺点也很明显：它的调度粒度是“层”，不是“专家”，无法做到“只留下热专家”这样精细的调度。实测下来，如果模型对带宽敏感，Ollama方案的速度会比自写调度慢很多，因为CPU侧需要计算那一整层的全部参数，而不是只算冷专家。

我的建议是：想快速验证模型效果，先用Ollama跑通再说；想认真压榨性显存的潜力，再来自写调度。

3.4 核心参数怎么定：以专家体量反推驻留数量

调度方案里最重要的一组参数是“显存驻留多少个专家”和“专家权重用多少bit量化”。我按一个专家约0.18B参数来算：

• FP16精度：单个专家约0.36GB，12G显存去除共享部分和KV Cache后，如果还剩6GB，最多驻留16个专家。
• 4bit量化：单个专家约0.09GB，同样6GB空间可以驻留60多个专家，甚至可能全部专家都放下。

所以，如果只想让模型能跑，4bit量化加上调度，很多时候甚至不需要换入换出。这是一个很容易被忽略的结论：MoE模型被量化之后，12G显存的实际容纳能力比想象中大得多。我实际使用时会把4bit量化和显存驻留8个专家作为默认配置，因为即使有换入换出，搬运一个90MB的专家在PCIe 3.0上也就20毫秒左右，几乎感知不到。

4. 实测数据与调参心得：不是每个12G都能跑出一样的速度

4.1 不同配置下的显存占用与生成速度对照

为了直观展示效果，我把不同配置下的实测结果整理成了表格。测试环境为12G显存、双通道DDR4-2666内存、PCIe 3.0 x16接口，模型为某16B级别MoE模型，上下文长度固定1024，输出长度64，FP16和4bit两种精度各跑一轮：

需要注意的是，这组数字在不同品牌和型号的显卡、内存组合下会有一定波动，但趋势是一致的：只要常用专家能留在显存里，速度就不会太离谱。我实测中，如果某个场景下热专家集中，8个专家驻留已经能覆盖90%以上的路由选择，速度基本稳定在每秒10到15个token，属于勉强可以聊天的水平。

4.2 三个真正的物理瓶颈

很多人在本地部署MoE模型，一觉得卡就怀疑显存不够，其实显存只是冰山一角。真正决定速度上限的是以下三个物理因素：

第一个是内存带宽。CPU从内存里读专家权重，速度取决于内存条规格。DDR4-2666双通道的理论带宽约42GB/s，实际可用大约20到30GB/s。如果模型的内存侧专家权重很大，读取就要排队。

第二个是PCIe带宽。专家权重从内存搬运到显存，走的是PCIe总线。PCIe 3.0 x16实际有效带宽大约10到14GB/s，PCIe 4.0大约20到25GB/s。一个90MB的4bit专家从内存传到显存，在PCIe 3.0上大约需要8到10毫秒。这个延迟就是每次专家换入换出的基础成本。

第三个是路由稀疏度。MoE模型每个token激活的专家数量（Top-k）直接影响调度压力。Top-2的模型相比Top-4的模型，需要搬运的专家数量少一半，调度压力也小很多。所以在选模型的时候，不要只盯着总参数量，也要看看它的激活参数量和Top-k设置。

4.3 我的默认参数与调整顺序

经过反复测试，我给自己定了一套默认参数，稳定使用到现在：

• 精度固定为4bit量化，这个精度对16B模型的输出质量影响非常小，但能把单专家体量压缩到100MB以内。
• MAX_RETAINED_EXPERTS设为8，这是大多数场景下性价比最高的一档。显存占用低，调度压力小。
• prefetch_depth设为2，也就是提前预取接下来两层可能用到的专家。超过3之后收益不明显，反而增加后台线程的调度开销。
• KV Cache的上限设为7680个token，超出后自动截断到最近的5120个。保证KV Cache占用在2GB以内。

如果发现速度低于预期，我调整参数时的顺序是固定的：

• 先看是不是路由命中的专家在显存中命中率太低，如果是，把MAX_RETAINED_EXPERTS升到12或16。
• 再检查内存带宽是不是瓶颈，如果是，尝试用4bit量化进一步压缩专家体量。
• 最后检查PCIe传输是不是瓶颈，如果是，看能不能减少预取深度，减少无效搬运。

这个顺序背后的逻辑是：尽量让“多数计算留在显存”，其次才是“搬运更少的数据”。

5. 常见问题与排查技巧实录

5.1 故障现象速查表

我在本地部署这个方案的过程中踩了不少坑，也帮朋友排查过几台不同配置的笔记本，最常见的几个问题整理成了下表：

5.2 一个典型的排查案例：为什么我的速度比预期慢了三倍

有一次我在一台只有单通道DDR4内存的笔记本上测试，同样的模型、同样的参数，速度突然从原来的每token 120ms掉到了每token 400ms以上。刚开始我还以为是显存不够，后来检查了交换日志才发现，问题出在内存带宽上。

单通道DDR4-2666的理论带宽只有双通道的一半，实测从内存读取专家权重的速度下降了接近50%。再加上没有开启pin memory，CPU到GPU的传输还出现了额外延迟，最终速度就彻底被拖垮了。后来我把交换库改成固定分配内存，并使用torch.cuda的异步拷贝，同时在系统里打开了显存分配器的扩大池选项，速度才恢复到正常水平。

类似的坑还包括：在WSL2中默认的共享内存大小设置可能导致预取线程阻塞，需要在.wslconfig里手动加大内存分配；以及某些老款笔记本的PCIe通道实际只运行在x8甚至x4模式下，这类机器跑分层调度会非常吃力，建议直接用Ollama方案减少折腾成本。

5.3 独立于显存之外的两条实用经验

最后说两个很容易被忽略的细节，是我跑了很久之后才养成的习惯。

第一个是关于模型选择的经验。同样是16B总参数，不同模型的专家数量、每专家参数量、激活专家数差异很大。有些模型看着总参数不大，但因为每个专家都很大，换入换出的成本就高。相反，如果专家切得细碎，调度反而灵活。所以选模型时候最好先看一下它的结构参数，优先挑专家数量多、单个专家体量小的模型，这和“显存总量”是两码事。

第二个是建议在调度脚本之外单独写一个路由统计脚本。每次跑完任务后，把命中的专家ID和次数打印出来，几次之后就能大概摸清模型的专家热度分布。这样的数据积累能帮助手工固定一批“冷启动常驻专家”，在模型加载时直接预置到显存里，进一步减少第一次运行时冷专家频繁换入带来的卡顿。

写在最后

虽然整篇聊了这么多技术细节，但我还是要再强调开头那句话：在12G显存笔记本上跑MoE-16B模型，真正重要的不是让整个模型进显存，而是搞清楚哪些参数必须热，哪些参数可以冷，然后把调度做好。我现在的习惯是固定跑一套4bit量化加8个驻留专家的配置，先跑通功能，再在路由统计数据的帮助下逐步优化。这项工作的成本主要在前期的代码理解和路由接入上，但一旦打通，后面换模型或者调整上下文长度都只是改参数的事。

如果你也有一台显存不大、内存不小的笔记本，非常建议试一下分层调度。不一定非得追求每秒几十个token，本地能跑通、能稳定生成，本身就已经打开了不小的可能性空间。