MoE 这个词这两年被提得越来越频繁尤其是 DeepSeek 系列把总参数 671B、每个 token 只激活 37B这个数字摆到台面上之后很多人才第一次意识到原来大模型推理不一定每次都要把所有参数跑一遍。我自己是从 Mixtral 8x7B 那会儿开始折腾 MoE 本地部署的中间踩过的坑大概能写满一个笔记本——辛辛苦苦下完几百 G 的权重发现显存根本装不下、跑起来速度慢到像在拨号上网、量化完模型开始胡言乱语、调了半天参数才发现瓶颈压根不在显卡上。这篇文章就把 MoE 架构的原理、显存账本怎么算、本地部署怎么落地、出问题怎么排查从头到尾捋一遍。不管你是只有一张 24G 显卡的个人玩家还是手头有几台机器想搭内部推理服务的小团队MoE 都值得认真研究一下。它的核心价值就一句话用更少的激活参数换更大的知识容量让大模型这三个字从用不起变成能用得起。下面我会按原理、成本、实操、排查、心得五个部分展开代码和命令都是可以直接抄走跑的。1. MoE 架构到底解决了什么问题1.1 稠密模型绕不开的算力墙先说清楚稠密Dense模型的困境。一个标准的 Transformer 解码器层里注意力机制占的参数其实不多真正吃参数的是前馈网络那一块在主流模型里 FFN 通常占总参数量的三分之二左右。稠密模型的规则很简单也很粗暴不管你这个 token 是你好还是量子场论的重整化,它都得从第一层走到最后一层每一层的每一个权重都要参与计算。这就带来一个很别扭的结论——模型参数量一旦上去推理成本就线性上涨。你想让模型知道更多东西就得加参数加了参数每个 token 的计算量和显存占用就同步膨胀。一个 70B 的稠密模型FP16 下光权重就要 140G 显存两个 token 之间没有任何跳着走的可能。对于个人和小团队来说这条路基本走到 30B 左右就到头了再往上是机房和预算的较量不是技术问题。更关键的是这种全参数激活在直觉上就不合理。一个 token 是中文语法问题另一个 token 是代码补全第三个 token 是数学推导它们真的需要调用完全相同的参数子集吗显然不需要。MoE 就是从这个直觉出发的。1.2 稀疏激活把 FFN 拆成一堆专科医生MoE 全称 Mixture of Experts直译是专家混合。它的做法说起来不复杂把 Transformer 层里的那一个大 FFN替换成 N 个并行的小 FFN每个小 FFN 叫一个专家。然后加一个叫路由器Router也叫门控网络 Gate的小模块它的任务是看一眼当前这个 token 的隐藏状态判断它该交给哪几个专家处理。具体计算是这样的路由器是一个形状为[hidden_dim, num_experts]的线性层输入 token 的向量 x得到每个专家的打分做 softmax 之后取分数最高的 top-k 个专家把 token 分别送进这几个专家算一遍最后按门控分数加权求和得到输出。其他没被选中的专家这一步压根不参与计算。这里有个数字要分清楚总参数和激活参数。总参数是所有专家加起来的参数量决定模型能装多少知识激活参数是单次前向实际参与计算的参数量决定推理的算力和显存带宽开销。Mixtral 8x7B 总参数 46.7B每个 token 只激活约 12.9BQwen3-30B-A3B 总参数 30.5B激活只有 3.3BDeepSeek-V3 更极端总参数 671B激活 37B激活比例只有 5.5% 左右。用生活化的类比稠密模型像是一家只有一位全能医生坐诊的诊所不管你是骨折还是感冒都得挂他的号MoE 像是一家分科室的医院门口有个分诊台路由器看一眼你的症状就把你分到骨科或者内科其他科室的医生该喝茶喝茶。医院规模可以很大但每次真正干活的人就那么几个。1.3 DeepSeek 在路由设计上做的两个关键改动原始的 MoE 设计比如早期 Switch Transformer 那种有一个很明显的问题专家数量少、粒度粗通常是 8 个或 16 个专家每个专家的中间维度跟稠密模型一样大。这样的结果是路由器的选择空间很小一个 token 选哪个专家都差不多专业化程度有限。DeepSeek 系列在这一点上改了两处我觉得是整个架构里最值得琢磨的部分。第一处是细粒度专家。DeepSeek-V3 每个 MoE 层有 256 个路由专家每个专家的中间维度只有 2048相比稠密模型动辄上万维的 FFN单个专家小得多。专家数量多、粒度细的好处是组合空间爆炸式增长——256 选 8 的组合数是个天文数字路由器可以给不同 token 分配高度差异化的参数子集。代价是路由器的训练难度上升需要配合负载均衡策略。第二处是共享专家。DeepSeek-V3 每个 MoE 层除了 256 个路由专家还额外设了 1 个共享专家这个专家对所有 token 都激活不参与路由选择。这个设计的用意是有些通用知识比如基本的语言规律、常见的语法结构是所有 token 都需要的让它们反复被不同的路由专家重复学习是浪费把这些通用能力集中放在共享专家里路由专家就能更专注地学各自的专精领域。实测上这个改动对模型效果的提升在论文里有明确消融数据支撑。1.4 为什么 MoE 不是免费的午餐说了这么多好处必须泼点冷水。MoE 的代价主要有三块如果只盯着激活参数小这一条实际部署时会被打脸。一是显存仍然要按总参数算。虽然推理时只激活一部分专家但所有专家的权重都得加载到显存或内存里待命因为下一个 token 可能就路由到别的专家去了。所以 671B 的 DeepSeek-V3就算激活只有 37BQ4 量化后也得占约 370G 的存储空间单卡是不可能装下的。这一点是很多人第一次部署 MoE 时最大的认知偏差。二是训练不稳定。路由器的选择是离散的梯度没法直接回传需要用 top-k 的连续近似或者强化学习那一套。更麻烦的是路由塌缩——如果不加约束路由器会倾向于只选少数几个专家其他专家拿不到梯度就废了。DeepSeek-V3 用的是无辅助损失的负载均衡策略靠给每个专家维护一个动态偏置项来调节而不是简单地往损失函数里塞均衡惩罚项这样不会因为强行均衡而伤害模型效果。三是通信开销大。MoE 在多卡部署时天然适合专家并行——不同专家放在不同卡上但这就意味着每次路由都要做 all-to-all 通信把 token 发到对应卡上再收回来。在跨机部署的场景里这个通信量可能直接把推理速度拖垮。这也是为什么 MoE 在单机多卡上表现好跨节点就明显吃力。2. 显存、算力与量化MoE 的成本账怎么算2.1 总参数与实际占用之间的换算公式要把 MoE 跑起来第一步是算清楚到底需要多少显存和内存。这个账目分成四块模型权重、KV Cache、激活值缓冲、框架开销。其中权重是大头。权重的换算很直接权重大小(GB) ≈ 参数量(B) × 每参数字节数。不同量化精度对应的字节数大致如下表。量化格式每参数字节671B 模型占用30B 模型占用备注FP16/BF162.0约 1342 GB约 61 GB原始精度几乎没人这么部署Q8_0 / FP8约 1.06约 711 GB约 32 GB质量损失极小显存翻倍Q6_K约 0.83约 557 GB约 25 GB性价比不错的折中点Q5_K_M约 0.70约 470 GB约 21 GB质量与体积平衡较好Q4_K_M约 0.55约 370 GB约 17 GB最常用的部署档位Q3_K_M约 0.43约 289 GB约 13 GB质量开始肉眼可见下降Q2_K约 0.30约 201 GB约 9 GB不推荐MoE 上尤其糟糕这张表的数字是估算值实际会因为层数、嵌入表大小、专家维度而有出入但量级是对的。可以看到即便用 Q4_K_M671B 的 DeepSeek-V3 也要 370G 左右的存储空间这意味着你至少需要 512G 内存的机器配合 SSD 分层加载或者三到四张 96G 的卡才能把它稳稳装下。2.2 KV Cache另一个容易被低估的显存黑洞权重算完了KV Cache 的账也不能漏。它的大小跟上下文长度成正比公式是KV Cache 字节数 2 × 层数 × KV 头数 × 头维度 × 序列长度 × 批大小 × 数据类型字节数拿 Qwen3-30B-A3B 举例它有 48 层GQA 用的是 4 个 KV 头头维度 128。在 32K 上下文、单条序列、FP16 精度下2 × 48 × 4 × 128 × 32768 × 2 ≈ 3.2 GB。如果切到 INT8 精度的 KV Cache就是 1.6 GB。看起来不多但如果你开了 8 路并发这个数字就要乘以 8直接变成 25.6 GB——够呛。这里要特别提一下 DeepSeek 的 MLA多头潜在注意力。它的思路是把 KV 压缩到一个低维的潜在向量再缓存KV Cache 的压缩率能做到几十倍这也是 DeepSeek 系列在长上下文下显存占用依然可控的重要原因。不过 MLA 在 llama.cpp 这类推理框架里的实现相对复杂不同版本的兼容性差异比较大部署时要注意版本匹配。注意MoE 模型的 KV Cache 计算方式和稠密模型完全一致跟专家数量无关。但 MoE 的 KV Cache 通常更贵因为上下文一长专家路由的调度开销会被放大实践中建议搭配 KV Cache 量化使用。2.3 量化对 MoE 的伤害比稠密模型更大这是我踩过的一个大坑。刚上手的时候我习惯性地对 MoE 模型也用 Q2_K 或者 Q3_K_M 去压体积结果发现模型质量崩得比同等条件下的稠密模型厉害得多。原因不复杂。稠密模型里所有参数被所有 token 共享量化误差会被平均掉一部分MoE 里每个专家只处理一小部分 token专家内部的量化误差没有机会被其他 token 摊平。尤其是那些冷门专家本身拿到的 token 就少再叠加上量化噪声输出质量直接就废了。所以对 MoE 模型我的经验是量化不要低于 Q4_K_M条件允许的话尽量上 Q5_K_M 或 Q6_K。省下来的那点体积换来的是能用和不能用的差别。另一个细节是专家层和注意力层的量化敏感度不一样。注意力层和嵌入层对精度更敏感专家 FFN 相对耐受。llama.cpp 支持混合量化可以手动把attn_*、token_embd、output这些张量保留在更高精度只把专家层压到 Q4。官方的 Q4_K_M 其实已经做了类似的混合处理但如果要自己转量化可以用--tensor-type参数精细控制。2.4 专家并行与通信开销的真实体感如果你有多张卡MoE 的部署方式比稠密模型多一层选择可以按层切pipeline parallel可以按张量切tensor parallel也可以按专家切expert parallel。专家并行的逻辑最贴合 MoE 的结构——每个专家完整地放在一张卡上token 路由到哪个专家就去哪张卡取结果。听上去很美但通信是实打实的开销。每一层 MoE 都要做一次 all-to-all把 token 分发出去再聚合回来。以 DeepSeek-V3 的 61 层计算每层一次 all-to-all一次前向就是 61 轮通信。在 NVLink 互联的单机 8 卡上这个开销还能接受一旦跨到 PCIe 甚至以太网延迟会立刻成为瓶颈。我的实测感受是单机内专家并行收益明显跨机专家并行在中小规模下基本是负收益除非你有 400G 以上的高速互联。vLLM 里开启专家并行的参数是--enable-expert-parallel通常和张量并行一起用。它的实现会把专家权重按卡数均分路由时通过 all-to-all 交换。参数量越大、专家越多这个模式的优势越明显模型本身不大时反而增加了调度复杂度。3. 本地部署实操从选型到跑通第一个 MoE3.1 硬件门槛自查先看你适合哪个档位动手之前先做一道判断题避免下载完几百 G 权重才发现跑不动。我按实际体验把 MoE 部署分成了四个档位。档位硬件配置可跑模型典型速度入门16G 内存 无独显纯 CPUDeepSeek-V2-Lite Q4、OLMoE-1B-7B2-5 tok/s主流单张 24G 显卡 64G 内存Qwen3-30B-A3B Q4、Mixtral 8x7B Q430-60 tok/s进阶双卡 48G 显存 128G 内存Qwen3-235B-A22B Q4、phi-3.5-MoE15-35 tok/s硬核512G 内存 多张 48G/96G 卡DeepSeek-V3 Q4、DeepSeek-V2 Q45-20 tok/s这里有个很反直觉的点纯 CPU 大内存的方案在 MoE 上比在稠密模型上更有价值。因为 MoE 激活参数小CPU 的算力虽然弱但真正需要算的参数量少瓶颈主要在内存带宽上。一台 128G 内存的机器跑 DeepSeek-V2-Lite速度可以到 8-10 tok/s完全可用同样配置跑一个 70B 的稠密模型可能只有 1-2 tok/s那个体验就没法用了。我自己主力是一张 24G 卡配 96G 内存跑 Qwen3-30B-A3B 的 Q4_K_M把 4 位量化的专家层大部分放到 GPU 上KV Cache 在显存里余下部分走内存日常对话稳定在 40 tok/s 左右代码补全场景略低。这个配置的总成本控制在万元以内是我认为目前个人玩大模型性价比最高的档位。3.2 推理框架选型五款主流工具的适用边界选对框架能省掉一半的折腾时间。下面这张表是我把几个常用框架都实际部署过之后的对比。框架上手难度MoE 支持度适合场景主要短板llama.cpp中很好支持专家层 CPU 卸载单机、混合 CPU/GPU、GGUF 生态高并发能力弱Ollama低好底层就是 llama.cpp个人快速试用、桌面端参数控制粒度粗LM Studio极低好图形化分配 GPU 层图形界面党、非技术用户批量部署不便vLLM中高很好支持专家并行服务端、高并发、多卡显存要求高SGLang中高好RadixAttention 有优势高并发、前缀复用多的场景生态相对新如果你只是想在自己电脑上跑起来看看效果直接从 LM Studio 或者 Ollama 起步别一上来就折腾 vLLM。如果你要做的是团队内部 API 服务多人同时用那 vLLM 或者 SGLang 是正解llama.cpp 的 server 模式在并发上确实吃力。我个人的组合是日常试验用 llama.cpp 直接跑 GGUF要开服务就用 vLLM两者都留着。GGUF 格式的文件在 Ollama 和 LM Studio 里也能直接导入不用重复下载。3.3 用 llama.cpp 跑通第一个 MoE 模型下面是最小可跑的完整流程以 Qwen3-30B-A3B 为例Linux 和 Windows 的命令基本一致路径换成自己的就行。第一步是搞到模型文件。优先在 ModelScope 上找 GGUF 量化版国内下载速度比 HuggingFace 稳很多。搜索模型名加 GGUF选 Q4_K_M 或者 Q5_K_M 的版本注意要下齐所有分片文件名里带00001-of-00004这种。第二步是编译或者获取 llama.cpp。Windows 用户建议直接下 releases 里的预编译包选带 CUDA 的版本Linux 用户自己编译一遍更稳git clone https://github.com/ggml-org/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDAON -DCMAKE_BUILD_TYPERelease cmake --build build --config Release -j $(nproc)第三步是跑起来。关键在于-ngl和专家卸载的配合./build/bin/llama-cli \ -m ./models/Qwen3-30B-A3B-Q4_K_M.gguf \ -ngl 99 \ --n-cpu-moe 0 \ -c 32768 \ -ctk q8_0 -ctv q8_0 \ --flash-attn on \ -p 用一句话解释 MoE 的路由机制参数逐个解释一下。-ngl 99表示把 99 层都尝试卸载到 GPU实际能卸多少由显存决定。--n-cpu-moe 0表示不把任何专家层放到 CPU如果你的显存装不下全部专家这个值就往上调比如设成 20 表示前 20 层的专家放 CPU。-c 32768是上下文长度按需调整开太大显存会爆。-ctk q8_0 -ctv q8_0是把 KV Cache 量化到 8 位这个几乎无损但能省一半 KV 显存强烈建议开。--flash-attn on开 Flash Attention长上下文下提速明显。跑 DeepSeek-V3 这种巨物的时候命令长这样./build/bin/llama-server \ -m ./models/DeepSeek-V3-Q4_K_M-00001-of-00004.gguf \ -ngl 99 \ --n-cpu-moe 45 \ -c 8192 \ -ctk q8_0 -ctv q8_0 \ --host 0.0.0.0 --port 8080--n-cpu-moe 45的意思是让前 45 层的专家跑在 CPU 上后面的专家留给 GPU。这个数值需要反复试调大一点显存压力小但速度慢调小一点速度快但可能 OOM。我一般从层数的一半开始试往上往下微调。第四步是验证。服务起来之后用 curl 打一下curl http://localhost:8080/v1/chat/completions \ -H Content-Type: application/json \ -d { model: local, messages: [{role: user, content: 你好}], max_tokens: 128 }返回正常 JSON 就说明通了。日志里会打印每层的卸载情况和实际速度注意看offloaded X/Y layers to GPU那行数字对不上说明显存不够得调--n-cpu-moe。3.4 vLLM 部署 MoE 的关键配置要做多人共用的服务vLLM 是更合适的选择。它对 MoE 的支持比较完整专家并行、张量并行、FP8 量化都能配。一个典型的双卡部署长这样vllm serve Qwen/Qwen3-30B-A3B-Instruct-2507 \ --tensor-parallel-size 2 \ --enable-expert-parallel \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --kv-cache-dtype fp8 \ --max-num-seqs 16 \ --port 8000几个参数值得说道。--tensor-parallel-size 2是张量并行度等于卡数。--enable-expert-parallel打开专家并行让专家权重分布在两张卡上这个在专家数多的时候能明显降低单卡显存。--gpu-memory-utilization 0.92控制 vLLM 预分配的显存比例设太高容易在长上下文时崩设太低浪费。--kv-cache-dtype fp8是 KV Cache 量化。注意--enable-expert-parallel和--tensor-parallel-size一起用时专家的分布策略会变实际显存占用可能和预期不符。第一次部署建议先用nvidia-smi盯着显存逐步加大--max-model-len找到稳定点。vLLM 的短板是冷启动慢加载一个 30B 的 MoE 可能要几分钟因为它要把权重分片到各张卡上。如果你只是偶尔用一下llama.cpp 反而更省事。另外 vLLM 的版本迭代很快MoE 相关的参数和行为在不同版本间有差异部署前一定要看对应版本的文档别拿老教程硬套。3.5 推理参数调优把速度从能用提到好用框架跑通只是第一步参数调优才是把体验从能跑提到好用的关键。我按收益从高到低排一下。KV Cache 量化是收益最高的一刀。开q8_0几乎无损显存占用直接减半长上下文场景下收益尤其明显。如果显存实在紧张可以试q4_0但质量会有点损失MoE 模型上要谨慎。Flash Attention必开。它对长序列的收益随着上下文长度增长而放大32K 上下文下能提速 30% 以上显存也会降。llama.cpp 里加--flash-attn onvLLM 里默认就是开的。批大小和并发数要反复找平衡点。并发调大能提高吞吐但 KV Cache 是线性增长的很容易把显存吃满。我的经验是在 llama.cpp 里先设--parallel 1确认单路稳定之后再往上加每次加 2观察显存和延迟变化。vLLM 里对应的是--max-num-seqs。上下文长度别贪心。很多人一上来就设 128K结果显存直接爆。实际使用中 32K 能覆盖绝大多数场景需要更长的再往上调。llama.cpp 的-c参数设的是最大长度但实际分配是按需的不过 KV Cache 的容量在启动时就定死了。MoE 专属参数就是专家层的 CPU/GPU 分配前面说的--n-cpu-moe。这个参数对速度的影响是线性的专家层每多放一层到 CPU速度就掉一点。所以调优顺序应该是先把 KV Cache 和 Flash Attention 这些通用优化做完最后再动专家分配。我在 24G 卡上跑 Qwen3-30B-A3B 的一组实测数据供参考Q4_K_M 量化32K 上下文KV Cache q8_0不卸载专家层时 42 tok/s卸载 10 层专家到 CPU 时降到 31 tok/s卸载 30 层时掉到 14 tok/s。这个曲线挺陡的说明能塞进显存就尽量塞。4. 常见问题与排查实录4.1 显存不够从报错到解决的完整路径MoE 部署最常见的报错就是显存不足但报错信息五花八门有的是 CUDA out of memory有的是加载到一半卡死有的是启动成功但一推理就崩。排查思路我整理成一条固定的路径。第一步看是加载阶段还是推理阶段报错。加载阶段爆显存说明权重本身太大只能靠量化或者加大 CPU 卸载。推理阶段爆显存多半是 KV Cache 或者激活值导致的往上下文长度和并发数上找原因。第二步确认量化精度是否合适。同样一个 30B 的 MoEQ4_K_M 和 Q8_0 的差距可能就是一倍显存。如果 Q4 都装不下那这个模型就不适合你的硬件换个小一号的模型比硬压量化更划算。第三步调--n-cpu-moe。这个参数是 MoE 部署的救命稻草它允许你把一部分专家层放在内存里用 CPU 算。虽然速度会掉但至少能跑起来。原则是显存优先装注意力和嵌入层专家层往 CPU 上让。第四步开 KV Cache 量化。-ctk q8_0 -ctv q8_0这两句能省下相当可观的显存而且质量损失几乎感知不到。这是我每次部署的必开项。第五步降上下文和并发。这两项是显存的弹性部分需要多少给多少不要一上来就给顶格配置。4.2 速度慢定位瓶颈在哪个环节速度慢比显存不够更难排查因为瓶颈可能在显卡、CPU、内存、磁盘任何一个环节。我的定位方法是分段看指标。先看 GPU 利用率。用nvidia-smi -l 1或者nvitop盯着如果利用率常年低于 50%说明 GPU 在等数据瓶颈在别处。这时候看内存带宽——用htop或者任务管理器如果内存带宽跑满了说明专家层的 CPU 计算成了瓶颈解决方案是尽量减少--n-cpu-moe。再看模型加载方式。如果模型放在机械硬盘上首次加载会极慢而且如果内存不够触发了 mmap 换页推理过程会反复读盘速度惨不忍睹。MoE 模型一定要放在 NVMe SSD 上这个是我用血的教训换来的经验。我之前把 200G 的权重放在机械盘上推理速度只有 2 tok/s换了 NVMe 之后直接上到 15 tok/s。最后看参数配置。上下文设得太大、KV Cache 没量化、Flash Attention 没开这几个都会拖慢速度。对比测试的时候一次只改一个变量别一次改一堆不然不知道哪个起了作用。4.3 输出质量异常量化、路由与上下文MoE 模型的输出质量异常有自己的特点和稠密模型不太一样我遇到过三种典型情况。一是量化过度导致的专家失能。表现是模型大部分时候正常但一碰到某些特定类型的问题就开始答非所问或者反复重复同一句话。原因往往是某些冷门专家被压得太狠权重失真。解决方案是把量化精度提上去Q3 换 Q4Q4 换 Q5。二是负载不均衡导致的输出单调。如果你自己训练或者微调过 MoE可能会遇到路由器塌缩所有 token 都路由到少数几个专家输出变得非常模板化。这个在推理阶段的预训练模型上很少见但如果用了非官方的量化或者剪枝版本有可能出现。解决方式是用官方发布的权重。三是上下文超出导致的截断。MoE 模型在长上下文下的表现和稠密模型有差异如果上下文设置超过模型训练长度输出质量会急剧下降。这时候要检查模型的max_position_embeddings别盲目开大。4.4 常见问题速查表把上面这些整理成一张表出问题时可以先对照着看。现象最可能原因优先尝试的解决方案加载时 CUDA OOM权重超过显存容量提高量化档位或加大--n-cpu-moe推理时 CUDA OOMKV Cache 或激活值过大降低上下文、开 KV 量化、减少并发速度低于 5 tok/s专家层大量在 CPU 或模型在机械盘减少--n-cpu-moe、权重移到 NVMe输出重复、胡言乱语量化精度太低Q3 升 Q4、Q4 升 Q5优先保专家层精度启动成功但无响应上下文设置超限或服务端口冲突检查-c参数和端口占用多卡速度不升反降通信开销超过并行收益关闭专家并行改用张量并行长上下文质量断崖超出训练长度降低上下文到模型支持范围内提示MoE 模型的排查日志比稠密模型更有信息量。llama.cpp 启动时会打印每个专家的路由统计部分版本需要开 verbose观察一下是不是有专家几乎不被激活这能帮你判断量化是否伤害了路由。5. 几个我踩过坑之后总结的实战心得5.1 关于模型选择的取舍逻辑市面上的开源 MoE 模型不少选哪个其实有一套逻辑。我一般按激活参数匹配硬件、总参数匹配知识需求这两条来定。激活参数决定速度总参数决定模型懂多少。如果你主要跑对话和日常问答Qwen3-30B-A3B 这个档位3.3B 激活、30.5B 总参数是甜点区24G 卡轻松跑。如果你的场景需要更强的推理和知识广度比如复杂的代码生成或者长文档分析那就要往 A22B 或者更大的模型上走硬件门槛同步上升。DeepSeek-V3 这种 671B 的模型说实话个人玩家不建议硬上。就算量化到 Q4 也要 370G 存储要凑齐这套硬件不便宜而且速度很难做得舒服。它的价值更多在于服务端部署和 API 调用。个人场景下我推荐把 DeepSeek-V3 当云端 API 用本地跑 Qwen3-30B-A3B 做日常任务这个组合最经济。5.2 长上下文场景的额外注意点如果你的使用场景涉及长文档有几个坑要提前避开。MoE 本身对长上下文的支持取决于注意力的实现而不是专家数量。DeepSeek 的 MLA 让它在长上下文下显存高效但不是所有 MoE 模型都用 MLA很多还是标准的 GQA长上下文下 KV Cache 该占多少还是占多少。另外MoE 在长上下文下还有一个隐性的性能问题token 数量一多路由器的调用次数就多累积的调度开销变大。实测下来同样是 32K 上下文MoE 的 prefill 阶段耗时会比同激活参数量的稠密模型高一些decode 阶段则差不多。所以在做长文档处理时要预留更多的 prefill 时间预算。5.3 后续还能往哪扩展跑通基础部署之后有几个方向可以继续挖。一个是微调MoE 模型的微调比稠密模型省资源因为 LoRA 通常只挂在注意力层上专家层冻结训练成本低很多。llama-factory 这类工具对 MoE 的 LoRA 支持已经比较成熟。另一个是多模型混部用 llama.cpp 的 router 模式同时挂几个不同规模的 MoE 模型按任务复杂度动态选择这个思路我在做内部工具时用过效果不错。还有一个是推理监控自己写个脚本定时采集 tok/s、显存占用、路由分布长期跑下来能帮你摸清模型的实际负载特征。我个人在实际操作中的体会是MoE 本地部署这件事门槛不在技术在于对硬件边界的准确判断。搞清楚显存账本、认清量化对专家的伤害、会用 CPU 卸载做兜底这三条做到了剩下的就是试错和调参。别指望一次配好多跑几组对比数据慢慢就能摸出自己那套硬件的最佳配置。