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

我断断续续折腾了大半年从最开始只想在本地跑个不带云端 API 的小助手到后来认真研究 MoE 架构、对比不同权重格式、反复刷显存占用曲线最后终于把 35B 这个档位的 MoE 大模型在本地稳定跑通。中间踩过的坑随便数数都有十个而且几乎每个坑都让我浪费过至少一个周末。如果你也想在本地部署 35B MoE 大模型正在纠结显卡怎么选、权重格式选 GGUF 还是 GPTQ、或者已经在跑但总是爆显存、速度慢到怀疑人生那这篇记录应该能帮你少走很多弯路。我会把硬件选型思路、权重格式对比、完整的实操路径、还有那些踩到麻木的坑全部摊开来讲尽量说人话不堆术语。1. 为什么是 35B MoE参数规模与任务适配1.1 MoE 架构凭什么“省算力”很多人第一次听到 MoE 这个名字第一反应都是“这是什么新架构”。其实 MoEMixture 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 / 409024GB是性价比极高的甜点选择单卡就能扛起 Q4 量化模型配合合理的上下文长度能稳定运行。RTX 4080 16GB 或 A4000 16GB 则需要在“更低位宽量化”和“缩上下文”之间做取舍不是不能跑而是很勉强。如果想上更高精度的 Q5/Q6 量化或者想要更长上下文那 48GBA6000、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 生成速度断崖式下跌。机箱风道要保证显卡不进“闷罐”有条件尽量选择公版或散热设计较强的非公版。整体配置参考我放在表格里配置组合显卡/算力内存模型加载方式期望速度入门低配RTX 3060 12G CPU 卸载32G 双通道部分 GPU 部分 CPU1-3 token/s甜点推荐RTX 3090 / 4090 24G32G-64GQ4 量化全 GPU15-30 token/s高配完整A6000 48G / 双 309064GQ5/Q6 或长上下文30-50 token/sMac 方案M1 Max / M2 Ultra 64G64G 统一内存Metal 全加载8-15 token/s3. 权重格式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_MGGUF 格式按位宽和量化策略分成很多具体级别最常见的几个是 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 到 5GB24GB 显存会变得非常紧张上下文稍微拉长一点就爆。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 ToolkitPyTorch 自带的 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 tokenKV 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/OllamaGPTQ 用 AutoGPTQ/vLLMAWQ 用特定的推理库三者虽然最终都能加载模型但依赖的 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 到最新版。这也提醒我任何工具在第一怀疑区间都先查版本兼容性别急着重下模型。十大坑整理成速查表类别坑点最直接的解决方法硬件显存估算忽略 KV cache留 20% 余量调短上下文硬件能跑但速度极慢换更大显存或接受 CPU 卸载硬件内存单通道带宽不足换双通道内存硬件电源功率不够换 850W 以上金牌电源硬件散热差导致降频改善机箱风道权重GGUF/GPTQ 环境混用确认格式选择对应框架权重下载文件损坏下载后校验 SHA256权重上下文过长爆显存调低 num_ctx 或换优化框架权重输出重复乱码调低温度开启重复惩罚权重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 qwen35llama-cli -m /models/qwen35.q4_K_M.gguf -ngl 999 -c 8192 --temp 0.7 --repeat-penalty 1.1之后每次启动只要敲两个单词不用再翻聊天记录找命令。