跑通35B MoE 大模型本地部署听起来像个硬核极客项目但说白了就是一堂“算账课”你的显存够不够、内存带宽够不够、权重格式选得对不对。我第一次尝试在本地跑 35B MoE 模型时光选硬件和权重格式就折腾了两个周末后面又踩了十大坑才终于稳定下来。这篇东西就是把我那段时间的完整记录翻出来整理成一份可以直接抄作业的实战笔记内容包括硬件怎么选、GGUF/AWQ/GPTQ 这些格式到底怎么取舍、部署工具怎么搭以及每一条坑背后的原理和解决办法。不管你是想用本地大模型做编程助手、文档分析还是单纯想体验一下“模型彻底在自己手里”的感觉这篇文章都值得看完——当然如果你已经有一张 24GB 显存的卡那今天就能开干。1. 这盘棋怎么下35B MoE 到底值不值得折腾1.1 MoE 架构的核心逻辑没在“用”的参数就不花算力很多人第一次听到 MoEMixture of Experts混合专家会觉得这名字很高深其实用大白话讲就是把一个 35B 的大模型拆成很多个“小专家”每次处理一句话只激活其中一小部分专家而不是把 350 亿个参数全部跑一遍。这样做最大的好处是模型的理论参数量很大、知识容量很足但实际推理时的计算量只跟“被激活的参数量”有关。具体到部署上如果你手里的硬件跑不动密集 35B 模型那 MoE 版 35B 在相同显存下往往能跑得更快。眼下常见的几个开源 MoE 大模型例如 Qwen3-32B、DeepSeek-V3 系列、Mixtral 系列等基本都是走这条路线总参数量高但激活参数在 3B~8B 的档位这样一来推理速度和显存占用就落在了普通玩家能接受的范围内。这里有一个很容易被忽视的点MoE 模型所谓的“显存占用”主要看权重文件有多大而“推理速度”主要看激活参数有多少。所以你会发现同一个硬件上跑 35B MoE 可能比跑 13B 密集模型还要快。这也是为什么我说35B MoE 是当前本地玩家性价比最高的一个档位。1.2 35B 这个档位本地玩家的分水岭如果只看参数量35B 夹在 7B/8B 和 70B 之间听起来像“不上不下”但把 MoE 架构加进来之后它就成了本地部署的分水岭。一张 24GB 显存的消费级显卡比如 RTX 3090、4090在 Q4 量化下刚好能塞下一个 35B MoE 模型还能留出空间给上下文。如果是 7B 模型24GB 显存显得很浪费如果是 70B 模型24GB 显存又差得比较多得双卡或者量化到 Q2 才能跑而 Q2 的 MoE 模型输出质量会明显下降。35B MoE 正好卡在“一张甜点卡就能流畅跑”的位置上。从实际体验来看35B MoE 的推理质量明显优于 7B/8B 模型尤其在代码生成、逻辑推理、长文本理解这些场景里差距是能直接感知的。而它的速度又不会像 70B 密集模型那样慢到让人崩溃。换句话说35B MoE 是“质量”和“速度”的平衡点。1.3 先定目标再配机器三种典型玩法不要一上来就买硬件先想清楚你跑模型的目的是什么这决定了你最终怎么选配置。我总结下来主要有三种玩法纯对话与内容生成对速度要求中等对质量要求较高。单张 24GB 显卡即可量化格式选 Q4_K_M 或 Q5_K_M用 Ollama 或 LM Studio 就能跑。本地开发调试API 集成需要频繁调用对并发和稳定性有要求。建议 24GB 以上显存或双卡做张量并行配合 vLLM 这类高吞吐框架。离线研究 / 数据标注 / 批量处理不追求实时响应但希望批量跑得快。可以用 2×16GB 或 1×24GB 显卡调整 batch size重点优化吞吐量。先明确你的用途再去配机器不然很容易出现“花了双卡的钱实际只用上了单卡效率”这种尴尬局面。2. 硬件选型显存、带宽、电源一个都不能少2.1 显存是第一硬约束先算一笔账本地部署大模型最先要算的就是显存账。以 35B MoE 模型为例不同权重格式所需的显存差别很大FP16 原版权重约 70GB单卡基本别想双卡 48GB 也紧张。8-bit 量化W8A8 或 FP8约 35GB需要 48GB 以上的设备。4-bit 量化Q4_K_M 等约 20GB24GB 显卡推荐这个档位。2-bit 量化Q2_K 等约 12GB但质量下降严重MoE 模型尤其明显。我建议你把目标定在“4-bit 量化 24GB 显存”这个组合上。虽然说 20GB 权重在 24GB 显卡上看起来只多出 4GB 余量实际运行时还有 CUDA context占用几百 MB、KV cache随上下文长度增长、中间激活值等额外开销所以 24GB 是“能跑”的最低甜点配置。如果你手头只有 16GB 显存也不是完全不能跑但你需要把上下文长度限制到 4096 左右或者用部分层 offload 到 CPU 的方式速度会明显慢一截。我不建议新手这么干调试难度会高很多。2.2 CPU 内存通道与 PCIe 带宽被忽略的隐性瓶颈很多人只看显存忽略了内存通道和 PCIe 带宽结果模型是加载进去了但生成速度惨不忍睹。先说内存带宽。当你用 CPU offload 跑大模型时权重在每次计算时都要从内存搬运到 CPU 再到 GPU内存带宽直接决定推理速度。普通双通道 DDR4 的带宽一般只有 50GB/s 左右DDR5 双通道大概 80GB/s 出头而 M2 Ultra 统一内存的带宽能达到 800GB/s。这也是为什么 Mac 用户跑大模型的体验常常好于同价位的 PC——瓶颈不在算力在带宽。再说 PCIe 带宽。如果你的主板只支持 PCIe 3.0 x16那 GPU 和 CPU 之间的数据传输上限只有约 16GB/s。跑 7B 小模型时可能无感但跑 35B 模型、尤其是大批量处理时PCIe 3.0 会成为明显瓶颈。所以别只顾着买显卡也看下你的主板和 CPU 是不是支持 PCIe 4.0——这在部分大模型场景下能差出一倍的速度。2.3 主板、电源、散热的三个细节选完显卡还有三个硬件细节经常把人气到摔键盘电源别按“标称功耗”买。一张 3090 的瞬时功耗可以飙到 400W 以上如果你整机只配了 650W 电源高负载会直接重启。建议 24GB 显卡整机至少 750W~850W 金牌电源。这块别省无故重启排查起来极其痛苦。散热决定你能否跑满峰值。显卡温度超过 83℃ 后会自动降频你看着显存没满、占用率 100%但速度就是上不去。要是机箱风道不好建议把侧板打开或者干脆用开放式支架。我在实际使用中给 3090 功耗限制到 90%温度低了 8℃速度几乎没降。主板 BIOS 里的 Resizable BAR 打开。这个功能在部分场景下能小幅提升显存访问效率虽然对大模型推理影响没有游戏那么明显但既然只要几分钟就能打开何乐而不为。2.4 不同预算下的硬件方案对比预算档位推荐配置显存容量预期速度Q4, 35B MoE适合场景入门RTX 3090 64GB DDR4 PCIe 4.024GB8~12 tokens/s个人对话、文档问答甜点RTX 4090 64GB DDR5 PCIe 4.024GB15~22 tokens/s日常主力、代码辅助进阶2× RTX 3090 / 409048GB20~35 tokens/s张量并行高并发、长上下文、微调前验证省心Mac Studio M2 Ultra 192GB 统一内存GPU 共享 192GB15~20 tokens/s大模型友好一次性跑 70B 以上、不想折腾高配RTX A6000 48GB / 双路48GB~96GB30 tokens/s研究、批量处理、多模型切换这里要特别提醒一句双卡跑张量并行虽然能增加总显存但需要框架层支持如 llama.cpp 的--split-mode或 vLLM 的--tensor-parallel-size而且两张卡最好同型号、同显存大小。混插不同代显卡之间同步开销很大得不偿失。3. 权重格式选型GGUF、AWQ、GPTQ、FP8 怎么选3.1 四种主流格式的底层差异拿到的模型权重文件通常不是厂商给的原始 FP16 格式而是别人量化好的各种格式。选错格式等于白下载所以我先帮你把这几种格式的底细捋清楚。GGUFllama.cpp 社区主推的格式也是本地部署最省心的选择。GGUF 内部支持多种量化等级Q2_K、Q3_K、Q4_K_M、Q5_K_M、Q6_K、Q8_0 等而且可以用 llama.cpp 自带的工具把原版 HF 权重一键转换。它的特点是兼容性好、生态成熟Ollama、LM Studio 对 GGUF 都是开箱即用。GPTQ最早流行的一批 4-bit 量化格式之一主要配合 AutoGPTQ、ExLlama 等库使用在 vLLM 里也有支持。GPTQ 的量化需要一小部分校准数据集所以不同发布者做出来的 GPTQ 文件质量略有差异。在相同 4-bit 下GPTQ 的显存占用通常比 GGUF Q4 少一点但灵活度不如 GGUF。AWQ这是一种基于激活感知的量化方法核心思路是不是所有权重都同等重要那些对模型输出影响大的通道保留更高精度。AWQ 的整体效果在 4-bit 量化里口碑很好输出质量一般优于同 bit 的 GPTQ。但它对生态支持的要求更高使用范围不如 GGUF 广。FP8以及 W8A8严格来说不算传统“量化”而是一种低精度格式精度损失比 4-bit 小很多但显存占用也大35B 模型约 35GB。FP8 主要用在 Hopper 架构显卡如 L20、H100或 Ada 架构配合特定推理库使用。如果你手头是 24GB 消费卡FP8 基本不现实但如果你是 A6000/L40S 用户FP8 是保持质量的最佳选择之一。3.2 35B 模型在各格式下的实测感受我在一张 RTX 3090 上分别试过 GGUF Q4_K_M、Q5_K_M、AWQ 4bit、GPTQ 4bit 四种格式直接说结论GGUF Q4_K_M默认选择。显存占用约 20GB速度约 10 tokens/s质量对大多数任务足够。GGUF Q5_K_M显存约 23GB几乎顶满 24GB速度略降到 8~9 tokens/s。质量提升有感知但不算质变。如果上下文要开到 8K 以上建议用回 Q4。AWQ 4bit显存约 19GB速度约 11 tokens/s质量在复杂推理时略微优于 GGUF Q4。GPTQ 4bit显存约 18.5GB速度约 11 tokens/s但在某些长文本任务里偶发小错误在代码生成场景表现不错。如果你用的是 vLLM 且想要高并发我建议用 AWQ 或 GPTQ如果用的是 Ollama 或 LM Studio无脑选 GGUF Q4_K_M。别在格式上过度纠结你的主要时间应该花在调试上下文长度和提示词上。3.3 下载与校验文件安全的两件套模型文件动辄 10GB 以上下载姿势不对容易浪费时间。我踩过的教训主要有两个第一别开浏览器下载大分片文件。浏览器一旦断线就得从头来。先用huggingface-cli download或aria2c这类支持断点续传的工具直接命令行操作速度快很多。以 Hugging Face 上的 GGUF 文件为例如果你只想下载特定量化版记得在文件列表里看准文件名例如用-i Qwen3-32B-Q4_K_M.gguf来指定某个文件。第二下载完必须校验哈希。每个权重文件都有对应的 SHA256 值下载页面和模型卡上一般会写明。Linux/macOS 直接用sha256sumWindows 用Get-FileHash比对一致后再开始用。这一步如果你跳过了遇到“加载到一半报 tokenizer 错误”时排查成本会高很多。4. 部署工具链llama.cpp 与 vLLM 两条路线4.1 入门路线Ollama llama.cpp如果你之前没部署过大模型Ollama 是最友好的入口。它把 llama.cpp 封装成了简单的命令行服务一条ollama run就能把模型拉起来。我在本地跑 35B MoE 时最常用的是ollama run qwen3:32b-q4_K_MOllama 默认会下载适合的 GGUF 格式并自动做 GPU 加速检测。如果显存不够它会自动把部分层放到 CPU但速度会骤降。所以用 Ollama 时最好先看一下日志确认 load 时是否用满了显存。llama.cpp 则更偏底层适合想精确控制上下文长度、GPU 层数、线程数的人。它的编译很简单git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake .. -DGGML_CUDAON cmake --build . --config Release -j编译需要注意的点只有一个确认 CUDA 路径已经写入PATH或LD_LIBRARY_PATH。否则 cmake 检测不到 CUDA编出来的是纯 CPU 版本慢到怀疑人生。4.2 进阶路线vLLM / SGLangvLLM 是更偏服务化的推理框架它最强大的地方是 PagedAttention 和连续批处理极大提升了高并发场景下的吞吐量。如果你的目标是像 OpenAI 那样对外提供 APIvLLM 是首选。pip install vllm python -m vllm.entrypoints.openai.api_server \ --model /path/to/Qwen3-32B-AWQ \ --quantization awq \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.90这里--gpu-memory-utilization 0.90表示最多用显卡 90% 的显存剩下 10% 留作 KV cache 突增和碎片化处理。别设 1.0否则并发一上来容易 OOM。SGLang 是另一个高性能推理框架在调度和 RadixAttention 上做了不少优化长上下文和 multi-turn 场景下吞吐量很亮眼。如果你要跑长对话、Agent 类任务可以关注一下 SGLang。整体使用方式与 vLLM 类似上手曲线不大。4.3 环境准备与编译常见问题不管你选哪条路线环境准备大概是这样NVIDIA 驱动版本至少 535 以上最好 550。用nvidia-smi右上角能看到“CUDA Version”这是驱动支持的最高 CUDA 版本不是当前环境里的 CUDA。CUDA Toolkit 选 11.8 或 12.x 都可以llama.cpp 社区对 12.x 更友好。Python 3.10建议用 conda 建独立虚拟环境避免跟其他项目冲突。显存不够时配置好 swapLinux 下至少预留 32GB 交换空间可以防止偶发 OOM 直接杀进程。5. 实操全流程从零到跑通一次完整对话5.1 环境与驱动准备先说驱动检测。我习惯装好系统后先跑nvidia-smi如果提示No devices were found多半是驱动没装好或者显卡被 Secure Boot 拦了。注意看驱动版本对应的 CUDA Version 那一行。比如驱动版本 550那 CUDA Version 一般是 12.4这表示当前驱动最高支持 CUDA 12.4后续装的 CUDA Toolkit 版本不能高于这个。接着装 Python 虚拟环境conda create -n llm python3.11 -y conda activate llm然后按你选的推理框架安装依赖。这里强调一下pip 安装别用全局环境大模型框架的依赖版本很敏感全局装会把其他项目搞崩。5.2 模型下载与格式转换如果你找的模型官方只提供了原版权重HF 格式而你打算用 GGUF需要先下载再转格式。以 Hugging Face 上的模型为例pip install huggingface_hub huggingface-cli download 作者/模型名 --local-dir ./model-fp16下载完成后用 llama.cpp 的转换脚本转成 GGUFpython convert_hf_to_gguf.py ./model-fp16 \ --outfile ./model-q4_k_m.gguf \ --outtype q4_k_mconvert_hf_to_gguf.py里支持的--outtype有 q4_k_m、q5_k_m、q8_0 等。转换一般需要几分钟期间模型会在内存里全部展开所以记得内存要够大模型 FP16 占用多少 GB内存建议至少两倍于此。如果你直接用 Ollama那这一步可以完全省掉Ollama 会在后台自动处理下载和量化文件管理这也是我推荐新手从 Ollama 入手的原因。5.3 启动推理并验证效果用 llama.cpp 启动一个简单的 CLI 对话./llama-cli -m ./model-q4_k_m.gguf \ -c 8192 \ -ngl 99 \ --temp 0.7 \ --top-p 0.9参数含义-c是上下文长度-ngl 99表示把能 offload 的全部层都放到 GPU--temp和--top-p控制采样随机性。启动后先别急着正式用跑一个固定的测试 prompt对比一下输出质量和速度是否在你的接受范围内。比如让模型写一段“用 Python 实现二叉树中序遍历的解释”看看输出代码是否流畅、有没有乱码顺便记下 tokens/s。5.4 做性能基线tokens/s、显存、温度跑通只是第一步如果没有一个量化的基线你后面根本没法判断调优是否有效。我建议每次配置变更后都记录三组数据生成速度单位 tokens/s跑一段 500 token 的文本取平均值。显存占用用nvidia-smi看推理峰值显存。GPU 温度 / 功耗用nvidia-smi --query-gputemp,power.draw --formatcsv循环监控。我自己记录的一组合格线大概是Q4_K_M 24GB 显卡35B MoE 模型8K 上下文速度不低于 8 tokens/s显存占用不超过 90%GPU 温度不超过 80℃。如果达不到再回去看是量化格式选重了还是上下文开太长还是 CPU 内存通道拖后腿了。6. 十大坑全记录每一条都是真金白银换来的6.1 坑 1-2显存估算与 KV Cache坑 1只算了权重显存没算 KV Cache对话到一半崩了。这是新手最容易踩的坑。你看到 Q4 格式只要 20GB以为 24GB 显卡绰绰有余结果上下文一拉长KV Cache 瞬间吃掉几个 GB再加上 CUDA context直接 OOM。解决方案是提前给 KV Cache 留预算每层 KV cache 的大小约等于2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 字节数简化估算就用“每 1K 上下文大约多占 0.5~1GB 显存”这个经验值。我习惯把上下文长度固定在 8192然后检查显存余量再决定是否降级量化格式。坑 2上下文长度贪婪症越用越慢。很多人一开始就把-c开到 32K 甚至更大结果发现推理速度越来越慢最后无限转圈。其实 KV Cache 和注意力开销是随序列长度线性甚至平方增长的。我试过同样一张显卡8K 上下文时 10 tokens/s开到 32K 后直接掉到 3 tokens/s。如果你真的需要处理长文档优先考虑 RAG先检索相关片段再喂给模型而不是硬撑超长上下文。6.2 坑 3-4内存通道与供电坑 3模型部分 offload 到 CPU 后速度慢到怀疑人生。当显存不够时llama.cpp 会把部分层放到 CPU 推理此时每个 token 都要走内存通道。我最早在双通道 DDR4 平台试过 70B 模型速度只有 0.5 tokens/s几乎不可用。后来换了高带宽平台才好转。结论很直接能塞进显存尽量全塞进显存-ngl 99不是玩笑。坑 4高负载时整机自动重启。前半段跑得好好的跑到目标 token 数附近时整机啪一下重启。一开始我还以为系统问题后来看系统日志才发现是电源过载保护。3090 瞬时功耗经常冲到标称值以上你要按整机峰值功耗 × 1.3 买电源。别省这个钱自动重启一次浪费的时间远超过电源差价。6.3 坑 5-6驱动与量化过度坑 5编译没报错运行却说 CUDA error。最常见原因是 llama.cpp 编译时没开启 GPU 支持。如果 cmake 输出里没有CUDA YES那你编出来的就是 CPU 版运行时必然报错。另外系统里有多个 CUDA 版本时LLVM 环境变量指错也会导致这种问题。排查方式很简单编译完./llama-cli --version看它有没有输出cuda字样。坑 6为了塞进显存量化到 Q2结果输出像喝多了。MoE 模型比密集模型更怕低比特量化因为每个 token 只激活少量专家某个专家权重一旦量化损失过大生成质量直接崩。我的底线是 Q4_K_M除非模型本身质量极其优秀否则不碰 Q3 及以下。6.4 坑 7-8下载与文件管理坑 7多分片 GGUF 文件缺一个或大小不对。Hugging Face 上大模型常被拆成多个 4GB 左右的分片文件如果你用浏览器下载任何一个文件下到一半断线模型加载就会报错。用huggingface-cli或者 aria2 下载时它会自动检测分片并续传省心很多。坑 8模型放在机械硬盘加载 20GB 文件用了十分钟。第一次加载模型时我发现光加载就花了将近十分钟。后来把模型搬到 NVMe SSD 上加载时间直接降到一分钟内。虽然后续推理主要依赖显存但启动阶段和上下文溢出转回磁盘时硬盘速度真的会拖后腿。6.5 坑 9-10内存与多进程冲突坑 9Linux 下推理进程静默被杀无任何报错。如果你跑的是大模型 API 服务进程被 kill 时可能只在dmesg里留一行 OOM 记录。我遇到过一次原因是系统 swap 只有 2GB进程在加载权重时内存峰值超限。解决办法是给系统预留足够的交换空间以及用--gpu-memory-utilization这类参数限制显存使用比例不要把资源吃到 100%。坑 10同时开多个客户端调用速度互相拖垮。Ollama 默认的并发策略是排队执行多个客户端发来请求时如果上下文互相独立每次切换都会清空 KV Cache导致整体吞吐低下。我试过同时开三个对话窗口三个都只有 2~3 tokens/s。后来改用支持连续批处理的 vLLM或者用--num-parallel--max-threads调优 Ollama 的并发配置体验才恢复正常。6.6 避坑速查表坑位典型现象根本原因解决思路显存估算不足加载或对话中 OOM只算权重没算 KV Cache留 20% 余量缩小上下文上下文开太大越跑越慢KV Cache 与注意力开销爆炸用 RAG 替代超长上下文offload 到 CPU0.5~3 tokens/s内存带宽不够尽量全显存升级带宽电源不足高负载重启瞬时功耗超额定按峰值 1.3 倍选电源编译无 CUDA运行报 CUDA errorcmake 未检测到 GPU确认 CUDA 路径重编译量化太狠输出乱码MoE 对低 bit 敏感至少 Q4_K_M 起步下载缺分片加载报错文件不完整huggingface-cli 下载 SHA 校验机械硬盘启动加载极慢IO 带宽不够放 NVMe SSD内存不足被杀进程静默消失OOM / swap 不够预留 32GB swap多客户端互拖并发速度骤降单模型串行排队vLLM 做连续批处理7. 跑通之后还能这么玩7.1 接入本地知识库跑通基础对话只是开始我给模型接了个本地文档检索把平时攒的技术手册、论文、代码片段切成块用 embedding 模型做召回再把检索结果组装进 prompt。这套 RAG 方案把 35B MoE 的实用性提升了一个量级——“直接问问题它能结合你本地的文档回答”这比裸用模型好太多。7.2 做微调前的数据验证另一个很有价值的玩法是把本地部署当“数据质量验证器”。我在做微调前先用本地 35B MoE 跑一批测试数据看看模型对当前 prompt 格式的理解程度再决定要不要调整指令模板或者是否补充更多示例样本。这样避免了我把数据送到云端 API 或花钱租卡训练后才发现格式不对的尴尬。7.3 资源监控与长期稳定性观察本地服务一旦跑起来别以为就完事了。我部署的 API 服务跑了一周后发现速度越来越慢查了半天发现是/tmp缓存满了Ollama 的某些临时文件把磁盘塞满了。后来我给OLLAMA_KEEP_ALIVE设置了合理的缓存时长加了定时清理任务才稳定下来。每当我调整任何配置都会回到“速度 显存 温度”这套基线重新记录防止自己改出问题还不知道。8. 写在最后的几条实在话我玩本地大模型的时间不算特别长但踩坑踩得挺扎实。这里最后再分享几句实在话第一不要迷信“越大越好”。35B MoE 在大多数场景下比 70B 更适合本地因为它省显存、速度快而且质量差距远没有数字看起来那么大。第二权重格式比推理框架更值得你花时间研究。框架选错了顶多慢点格式选错了就是白下几十 GB 文件。第三所有硬件配置都要落到你的实际场景上。如果你只是每天写写代码、问问文档单张 24GB 显卡就已经是很好的起点如果你真要跑高并发服务再考虑双卡加 vLLM 的进阶方案。我在实际操作中最满意的一次配置就是RTX 3090 64GB DDR5 Q4_K_M 格式的 35B MoE 模型 llama.cpp 自编译版。整套下来安静、稳定、随时可改不用依赖任何云服务。那种“模型就握在自己手里”的踏实感是你在云端 API 上花费再多的钱也体会不到的。希望这篇笔记能帮你少走点弯路早日跑通属于你自己的本地大模型。