35B MoE大模型本地部署全攻略：硬件选型、量化格式与踩坑总结

我断断续续折腾了大半年，从最开始只想在本地跑个不带云端 API 的小助手，到后来认真研究 MoE 架构、对比不同权重格式、反复刷显存占用曲线，最后终于把 35B 这个档位的 MoE 大模型在本地稳定跑通。中间踩过的坑，随便数数都有十个，而且几乎每个坑都让我浪费过至少一个周末。

如果你也想在本地部署 35B MoE 大模型，正在纠结显卡怎么选、权重格式选 GGUF 还是 GPTQ、或者已经在跑但总是爆显存、速度慢到怀疑人生，那这篇记录应该能帮你少走很多弯路。我会把硬件选型思路、权重格式对比、完整的实操路径、还有那些踩到麻木的坑全部摊开来讲，尽量说人话，不堆术语。

1. 为什么是 35B MoE：参数规模与任务适配

1.1 MoE 架构凭什么“省算力”

很多人第一次听到 MoE 这个名字，第一反应都是“这是什么新架构”。其实 MoE（Mixture of Experts，混合专家）概念很早就有了，只是这两年在大模型上大规模应用。它的核心逻辑可以理解成：一个团队里有十几个专家，每次来任务只需要叫其中两三个人干活，而不是让全队人一起上。

放到模型参数上看，35B MoE 虽然总参数量有 35B 左右，但真正参与计算的“活跃参数”可能只有 8B 到 12B。这个特性带来的好处很直接：模型的知识容量和表达上限接近 30B 级别的 Dense 模型，但推理时的计算量却只和 10B 左右的模型差不多。这就是 MoE 最吸引人的地方——用更少的算力，换来更高的参数上限。

这一点决定了它在本地部署的定位：相比 7B 或 8B 的小模型，35B MoE 有明显更强的复杂指令跟随能力和知识储备；相比同参数量的 Dense 模型，推理速度又快了不止一档。说它是“本地党的甜点档位”，一点也不夸张。

1.2 35B 这个档位在本地部署中的生态位

入门玩家通常会从 1.5B 到 8B 的小模型开始玩，优点是随便一张显卡甚至纯 CPU 都能跑，但用一阵子就会发现瓶颈：写长文容易跑题、逻辑推理容易断、代码生成经常出现低级错误。往上走，直接跳到 70B 的 Dense 模型，光模型权重在 Q4 量化下就要 40GB 左右，单卡 4090 都很吃力，更别说还得留出 KV cache 和运行内存。

35B MoE 正好卡在中间：量化后权重占用大概 20GB 到 26GB，一张 24GB 显存的显卡刚好能塞进去，还能留一点余量给上下文。性价比、可玩性和实用性的平衡点就在这里。

另外还要看到，MoE 模型的“智能分布”并不平均。因为每次只激活部分专家，它对不同类型的任务往往有偏科现象，比如代码能力强的模型长文本可能一般，数学好的模型闲聊可能差点意思。所以选型时不能光看总参数，要结合你日常的高频场景来定。我自己主要拿它做代码补全、文档摘要和结构化数据提取，35B MoE 在这个区间表现很稳，这也是我最终留下来的原因。

2. 硬件选型：算力、显存、内存与散热的平衡

2.1 显卡优先：显存容量是第一刚需

先把结论放在前面：跑 35B MoE，显存容量比算力更重要。模型能不能完整加载到显存里，直接决定你是 20 token/s 还是 0.5 token/s。我见过有人拿着 4090 想跑未量化的 35B，结果 24GB 显存根本装不下，只能含泪删权重；也见过有人用老旧 P40 24GB 配 Q4 量化，虽然没有 4090 快，但好歹整模型进显存，能正常对话。

以 Q4_K_M 量化为例，一个 35B MoE 的 GGUF 文件大约 21GB 到 23GB。考虑到 KV cache、激活值、CUDA context 等额外开销，想要跑得舒服，单卡显存 24GB 是起步。具体来说：

• RTX 3090 / 4090（24GB）是性价比极高的甜点选择，单卡就能扛起 Q4 量化模型，配合合理的上下文长度能稳定运行。
• RTX 4080 16GB 或 A4000 16GB 则需要在“更低位宽量化”和“缩上下文”之间做取舍，不是不能跑，而是很勉强。
• 如果想上更高精度的 Q5/Q6 量化，或者想要更长上下文，那 48GB（A6000、A5000、两张 3090）会更轻松。

显存大小决定能不能跑，算力强弱决定跑得快不快。这两者不能搞反。

2.2 CPU 与内存：数据搬运的瓶颈

很多人配机器时把注意力全放在显卡上，结果忽略了内存和 CPU，这也是我第一个坑的来源。

先说内存。当显存不够、把部分层卸载到 CPU 内存时，内存带宽就成了最大的瓶颈。普通 DDR4 3200MHz 双通道的内存带宽大概 40GB/s 左右，DDR5 也只有 60GB/s 上下，和显卡动辄几百 GB/s 的显存带宽完全不是一个量级。也就是说，哪怕你的模型只卸载了几层到内存，速度也会被瞬间拉低。所以我强烈建议内存直接上到 64GB，如果预算有限至少也要 32GB 起步，选择双通道而非单根大容量，通道数比容量更影响实际效果。

再来看 CPU 本身。如果你只用 GPU 跑，CPU 的主要任务是数据搬运和 token 生成后的采样逻辑，普通中端 CPU 就能胜任。但如果你打算用 llama.cpp 这类框架做 CPU 推理（也就是完全不吃显卡），那 CPU 的多核性能和内存带宽就决定一切了。苹果 M 系列芯片因为统一内存带宽较高，在 Mac 上跑 MoE 反而有不小的优势，这个后面细说。

2.3 硬盘与供电散热：容易被忽略的“隐形下限”

模型文件动辄 20GB 以上，如果用机械硬盘加载，光是读取模型权重到内存这一步就可能花掉十几分钟，而且每次运行都要来一遍。NVMe 固态硬盘在这个流程里几乎是必需品，建议 1TB 起步，顺序读取速度至少 2000MB/s 以上。一个实操技巧是，把模型文件放在和系统盘不同的另一块 NVMe 上，可以减少磁盘 IO 争抢。

供电更是个隐形坑。RTX 3090 在瞬时负载下能飙到 450W 以上，普通 750W 电源很容易触发过载保护导致黑屏重启。我第一块 3090 就因为这个在跑大模型时频繁重启，排查了三天最后换了 1000W 金牌电源才算根治。散热同理，显卡满载时温度如果超过 85 度会触发降频，导致 token 生成速度断崖式下跌。机箱风道要保证显卡不进“闷罐”，有条件尽量选择公版或散热设计较强的非公版。

整体配置参考我放在表格里：

3. 权重格式：GGUF、GPTQ、AWQ 与原始 Safetensors 的取舍

3.1 四种主流格式的本质区别

模型权重格式这个东西，看起来只是后缀名不同，实际影响大到你无法想象。挑错了格式，轻则推理环境配不起来，重则连模型都加载不了。

先说说 GGUF。这是 llama.cpp 项目推动的格式，最大的特点是可以在 CPU 和 GPU 之间灵活分层加载，兼容性极强。Ollama 底层用的就是它。它的量化文件自带 KV cache 等配置信息，你用 Ollama 拉模型基本就是一套流程走完。对于本地环境杂、想换设备反复实验的人来说，GGUF 是最省心的。

接着是 GPTQ。这是纯 GPU 推理的量化格式，vLLM、AutoGPTQ 这类服务于高吞吐批量推理的框架对它的支持最好。GPTQ 的量化过程会做逐列校准，理论上在相同 bit 数下精度损失比 GGUF 的 naive quantization 要小一点，但如果你的显存不够装下整个模型，GPTQ 没办法帮你，因为它在设计上就不支持 CPU 卸载。

AWQ 可以理解成 GPTQ 的进阶版。它根据激活值分布来选择哪些权重需要保留高精度，量化过程更聪明，在低 bit 数下的表现通常更好一点。不过它的生态相对窄一些，支持 AWQ 的框架不如前两者多。

最后是未量化的 Safetensors 格式。这是模型原本的完整形态，精度最高，但动辄 60GB 以上的体积对显存极不友好。本地跑 35B 这个档位，除非你拥有 48GB 以上的显存，否则我基本不推荐直接用原始格式。

3.2 量化级别怎么选：Q4_K_M 还是 Q5_K_M

GGUF 格式按位宽和量化策略分成很多具体级别，最常见的几个是 Q3_K_M、Q4_K_M、Q5_K_M、Q6_K 和 Q8_0。跑 35B MoE 时，量化级别的选择本质上是在“显存占用、精度损失、生成质量”三者之间做平衡。

我的实际测试结论是：Q4_K_M 是最优先考虑的档位。它在 24GB 显存的设备上能完整加载，还能留出大约 8k 到 16k 的上下文空间，生成质量在大多数任务上和原版模型的差距体感不明显。Q5_K_M 精度会更好，但文件体积多出 4GB 到 5GB，24GB 显存会变得非常紧张，上下文稍微拉长一点就爆。Q3_K_M 虽然体积小，但生成的逻辑错误率和重复率明显上升，不建议日常使用。

如果你是 Ollama 用户，可以通过ollama run <模型>:q4_K_M这样的标签直接选择对应量化版本；如果是手动下载 GGUF，文件名里的Q4_K_M通常就是量化级别标识。

3.3 我的选型结论与混搭经验

综合这几个月的折腾，我最终的权重格式选型逻辑是这样的：

• 追求简单稳定、可能在多台设备上换着跑，直接选 GGUF 的 Q4_K_M，配 Ollama 或 llama.cpp。
• 想用 vLLM 做一个正经的本地推理服务，接 API 给团队用，选 GPTQ 4bit 或 AWQ，配 AutoGPTQ/vLLM。
• 显存充足到能扛 48GB 以上，或者你做的工作对输出精度要求极高，比如代码生成和数学题求解，可以考虑未量化的 Safetensors，用 Transformers 跑 fp16。
• 在 Mac 上，GGUF 配 llama.cpp 的 Metal 加速是目前最成熟的路径，Ollama 在 Mac 上的表现其实也很好，统一内存的优势让它甚至能跑比 Windows 同等显存下更大的模型。

还有一个容易被忽略的点：GGUF 文件内部的 tokenizer 和特殊 token 配置是打包的，跨框架迁移时不容易出现 token 不匹配的问题。如果你在 GPTQ/AWQ 方案里换了推理框架，一定要确认 tokenizer 的版本和原模型一致，否则很容易出现生成的句子看起来正常但实际语义错乱的情况。

4. 从零跑到冒烟：本地部署完整实操路径

4.1 环境准备与推理框架选择

跑 35B MoE 的推理框架，我实际用下来主要就是三个：Ollama、llama.cpp 和 vLLM。三者的定位差别很明显：

Ollama 适合入门和日常使用，一条命令拉模型一条命令启动，省心、干净、好维护。它对 GGUF 的支持几乎是零配置的，还会自动管理模型版本和量化级别。缺点是高度封装，想调底层参数时不够灵活。

llama.cpp 适合需要抠性能的人。它编译起来不算难，支持 GPU 层数自定义、批次大小调节、并行序列设置，能让你直观感受到不同参数对速度的影响。对喜欢研究底层机制的人来说非常友好，但学习曲线也相对陡峭。

vLLM 是服务化部署的首选。它支持 PagedAttention 等优化，吞吐量比前两者高不少，适合做 API 服务。但如果只是自己本地交互式使用，它的启动开销和配置复杂度反而成了负担。

如果你之前没装过 CUDA 环境，先确认一下显卡驱动的 CUDA 版本，可以用nvidia-smi查看。不需要单独装全套 CUDA Toolkit，PyTorch 自带的 CUDA runtime 基本够用。Ollama 更是连这一步都省了，装好就能用。

4.2 权重下载、目录规划与校验

这一步是很多人翻车的高发区。我建议先用 Ollama 跑通流程，把模型拉下来再看情况换框架。

以 Ollama 为例，执行：

ollama pull <模型名>:q4_K_M

模型名要去对应模型的仓库页确认，比如 Qwen、DeepSeek、GLM 系列的 MoE 大模型在 Ollama 库里的命名和标签可能不太一样。拉取完成后可以用ollama list查看已安装的模型列表。

手动下载 GGUF 时要注意路径规划。我习惯在磁盘上建立一个专门的模型目录，例如D:\models\gguf或/data/models/gguf，然后按“厂商/模型/量化级别”建子目录。不要把模型文件直接丢到 C 盘系统目录，也不要用中文路径和空格路径，llama.cpp 这类工具对路径的解析有时候很挑剔。

下载之后最好做一次哈希校验。很多 GGUF 文件在 Hugging Face 页面上会提供 SHA256 值，可以用sha256sum或 PowerShell 的Get-FileHash验证，排除下载过程中文件损坏的情况。千万别跳过这一步，我踩过一次 5GB 文件下载到 99% 断线重连后文件损坏、但文件名和大小完全正常的坑，跑起来全是乱码。

4.3 首次加载与性能调优

第一次加载模型时不要直接上长上下文。先用默认参数启动，确认能正常对话，再慢慢拉长上下文。

Ollama 启动后可以通过环境变量调整上下文长度，比如/set parameter num_ctx 8192设置上下文窗口为 8k。llama.cpp 启动参数中对应的是-c 8192或--ctx-size 8192。上下文长度直接影响显存消耗，每增加 1k token，KV cache 的占用可能增加几百 MB 到 1GB 以上，具体取决于模型层数和注意力头数。

在性能调优方面，最值得关注的是 GPU 卸载层数。llama.cpp 中用-ngl参数控制把多少层交给 GPU 计算。如果显存足够，直接-ngl 999或者-ngl 100代表全部加载到 GPU；如果显存不够，可以先减半层数，观察生成速度再逐步调整。一个常见误区是“全部卸载就好”，实际上当 GPU 显存不够时，把一部分层留在 GPU 上让关键计算走显卡仍然能显著提升速度。

5. 十大坑全记录：从硬件到权重格式的踩坑速查

5.1 硬件相关的五个坑

坑一：显存估算严重失误，只看了权重文件大小，没算 KV cache 和激活值。我第一次看到 GGUF 文件是 21GB，心想 24GB 显卡肯定没问题，结果加载到一半直接 CUDA out of memory。后来才明白，模型权重只是基础，推理时每个 token 都会在显存里产生 KV cache，上下文越长占用越大，加上 CUDA context 和框架本身的碎片占用，实际显存需求至少比权重文件多 20%。解决办法是留足余量，或者在启动参数里把num_ctx调低。

坑二：以为“能跑起来”就是“跑得动”，结果速度 0.5 token/s。显卡 12GB 加内存 32GB，理论上模型能通过 CPU 卸载跑起来，但实际体验几乎没法用，生成一段话要等几分钟。这不是模型的问题，是内存带宽太低了。如果你只有 12GB 显存，建议考虑更小的 MoE 模型，或者接受这种程度的速度，别指望和满血显卡一个体验。

坑三：内存带宽被 DDR4 单通道卡死，跑 MoE 时 CPU 卸载部分成为最大瓶颈。我在一台老机器上插了一根 32GB 内存，续航结果比新机器的双通道 16GB 差了一倍还多。后来才发现单通道内存带宽直接减半。之后我换成了两根 16GB 组成双通道，速度大概提升了一倍不止。加内存时尽量按双通道来配。

坑四：电源功率不够，显卡高负载时直接黑屏重启。这是最让人崩溃的坑，因为它现象随机，排查还困难。最后是通过查看系统事件日志和替换电源才判断出来是供电问题。如果你用的是 3090 或 4090，建议电源至少 850W 以上，并且不要和其他高功耗设备共用一条 12V 线路。

坑五：机箱风道差，显卡 85 度持续降频。MoE 模型推理虽然相比训练负载小，但连续对话半小时后显卡温度很容易冲到 80 度以上。一旦触发降频，token 生成速度能掉一半。后来我调整了机箱风道，加了两个排气风扇，温度稳定在 70 度左右，速度也恢复了。如果你的机箱空间小，优先选公版或三风扇散热的显卡，不要只看外观。

5.2 软件与权重格式相关的五个坑

坑六：下载时不分 GGUF 和 GPTQ，拿到什么用什么，环境乱套。这是很多新手的通病。GGUF 用 llama.cpp/Ollama，GPTQ 用 AutoGPTQ/vLLM，AWQ 用特定的推理库，三者虽然最终都能加载模型，但依赖的 Python 包、量化算子和启动参数都不一样。正确做法是先在模型仓库页看清楚文件类型和推荐框架，再决定一条路走到底，别混着来。

坑七：下载中断导致模型文件损坏，跑起来全是乱码。

这个前面提过，文件名和大小正常不代表文件完整。解决方式是下载之后立刻做哈希校验，别嫌麻烦。另外，用 huggingface-cli 下载时如果中断，建议用它的断点续传功能，不要直接删了重下。

坑八：上下文拉长就爆显存，还没搞清 KV cache 的规律。默认 8k 上下文没问题，改成 32k 之后直接 OOM。这是因为 KV cache 的大小随上下文长度线性增长，对应 MoE 模型的多头注意力，每层都会产生多份 cache。如果你需要长上下文，可以用支持 GQA 的模型，或者调低num_ctx，或考虑使用 vLLM 的 PagedAttention 来优化显存分配。

坑九：输出重复、乱码，结果怪到模型头上，其实是采样参数没调对。很多人拿到模型就开跑，温度默认 1.0，结果模型输出经常陷入无限重复的循环。如果把温度降到 0.6 到 0.7 之间，再把重复惩罚值开到 1.1 左右，大部分重复问题都能缓解。量化级别太低的模型也比较容易出现这种现象，但不是模型本身的错。

坑十：Ollama 版本太老，不支持新模型的量化格式。旧版本 Ollama 对某些新出的模型系列不识别或报格式错误，一开始我还以为是权重文件有问题，费了好大劲重新下载，最后才发现就是版本不对。解决方法很简单：升级 Ollama 到最新版。这也提醒我，任何工具在第一怀疑区间都先查版本兼容性，别急着重下模型。

十大坑整理成速查表：

6. 性能基线参考与日常使用建议

6.1 不同硬件下的吞吐量参考

给你一个我实测下来的大致基线，方便你判断自己的配置大概在什么水平。不同模型的层数、注意力头数、激活参数不同会有点出入，但量级大致可信：

• RTX 4090 24G + Q4_K_M 全 GPU：约 25 到 40 token/s。这个速度基本能流畅阅读和对话。
• RTX 3090 24G + Q4_K_M 全 GPU：约 15 到 22 token/s。偶尔能感受到延迟，但可以接受。
• RTX 3060 12G + CPU 卸载：约 1 到 3 token/s。可读，但基本不适合交互式对话。
• Mac M1 Max 64G + Q4_K_M：约 10 到 18 token/s。日常够用，而且功耗低、噪音小。
• A6000 48G + Q5_K_M：约 30 到 40 token/s。体验已经非常接近本地原生应用。

这个表想说明一个事情：不要盲目追求参数最高的模型，而是要找到“能完整放进显存的前提下，你最能接受的速度对应的量化级别”。如果 4090 都只能跑到 10 token/s，那体验一定很差，即使精度再高也没用。

6.2 显存不足时的降级策略

如果你现在只有 16GB 显存或者更少，也不是完全没救。我的建议按优先级排序：

一是先降上下文长度，比如从 16k 降到 8k，这是最不损害模型能力的做法。二是换更低位宽的量化，比如从 Q5_K_M 降到 Q4_K_M，体感精度损失不大。三是在 llama.cpp 中手动指定更少的 GPU 层数，让模型一部分跑 GPU 一部分跑 CPU，找那个速度可接受的最优平衡点。四是用带 MoE 稀疏性的模型，它活跃参数少，显存和计算压力天然比同级 Dense 模型小。

如果上面这些方法都试了还是不行，我建议老老实实换一个更小的模型档位，比如 14B 或 16B 的 MoE/Qwen 系列。硬扛大模型，体验只会越来越差，并不是效率最高的路径。

6.3 我给新手的“少走弯路”操作建议

最后给新手一套我推荐的上手路径，算是我踩坑无数后总结出来的最优路线：

第一步，装最新版 Ollama。第二步，拉一个 35B MoE 模型的 Q4_K_M 版本，跑通对话。第三步，用/set parameter num_ctx 8192限定上下文，避免一上来就爆显存。第四步，只在这个阶段确认“能稳定对话、速度可以接受”。第五步，如果满意，继续保持 Ollama 作为日常使用；如果想进一步调优，再切换到 llama.cpp，手动调-ngl、-c和采样参数。最后，千万别在第一步就同时装 Ollama、llama.cpp、vLLM 和一堆 Python 依赖，那样出了问题根本不知道怪谁。

这个路径的好处在于，每个阶段都能验证自己硬件是否达到预期，不会出现“跑不起来也不知道是硬件还是软件”的尴尬情况。我当初要是按这个顺序来，至少能省下两个周末的踩坑时间。

根据我个人的实操感受，35B MoE 是本地部署大模型里“性价比”和“可玩性”结合得最好的一档，尤其在 24GB 显存环境下，能跑通它意味着你已经跨过了本地模型部署最大的那道坎。后面再往大模型或更复杂部署走，很多经验都是通用的。最后再分享一个我觉得特别实用的小技巧：把常用启动参数写成脚本或别名，比如在.bashrc里加一条alias qwen35="llama-cli -m /models/qwen35.q4_K_M.gguf -ngl 999 -c 8192 --temp 0.7 --repeat-penalty 1.1"，之后每次启动只要敲两个单词，不用再翻聊天记录找命令。