1. 为什么我盯上了 8GB 显卡跑 35B 这个组合先把结论摆在前面8GB 显存跑 35B 级别的模型在 MoE混合专家架构出现之前基本属于天方夜谭。我手上这张卡是 RTX 40608GB 显存之前跑 7B 的稠密模型还算舒服一上 13B 就开始爆显存得靠 CPU 卸载硬扛速度掉到每秒两三个 token聊天体验直接崩盘。所以当我第一次听说有人用 8GB 卡跑 35B 模型的时候第一反应是这哥们儿是不是把参数记错了。后来把原理捋清楚才明白这里的关键变量是MoE 架构。传统稠密模型Dense推理时每一层所有参数都要参与计算35B 就是实打实的 35B 全部要过一遍。而 MoE 模型把前馈网络拆成很多个专家每次前向传播只激活其中一小部分比如 35B 总参数里每次只调用 3B 左右。这就带来一个非常有意思的结果显存占用和计算量可以解耦。计算量看的是激活参数显存占用看的是需要常驻的参数——而 MoE 的专家参数虽然总量大但可以按需加载或者放在内存里做流式调度。这篇文章就是把这套玩法从头到尾走一遍。我会讲清楚 MoE 到底省在哪、8GB 显存的实际边界在哪、用什么工具链能跑起来、参数怎么调、踩了哪些坑。适合手里只有消费级显卡、又想在本地折腾大模型的同学尤其是那些被显存不够劝退过的人。看完你至少能判断自己这张卡到底能不能跑、能跑多快、值不值得折腾。2. MoE 架构到底省在哪把显存和计算拆开看2.1 稠密模型和 MoE 的本质区别要理解为什么 8GB 能碰 35B得先把两种架构的账算清楚。稠密模型的结构很直白假设一个 35B 的稠密模型用 FP16 存储光权重就要 70GB 显存。就算量化到 4bit也要 17.5GB 左右8GB 卡连门都摸不到。推理时每一层、每一个参数都要参与矩阵乘法计算量和参数量是线性绑定的。MoE 的思路完全不同。它把 Transformer 里的前馈网络FFN替换成一组专家每个专家本身还是标准的前馈网络但数量很多。同时加一个路由器Router/Gate对每个 token 决定把它发给哪几个专家处理。典型的配置是总专家数 N每次激活 top-k 个比如 8 个专家激活 2 个或者 64 个专家激活 6 个。这里有个关键数字叫激活参数Active Parameters。一个标称 35B 的 MoE 模型可能总参数 35B但每次前向只激活 3B 左右。计算量按 3B 算显存里要放的却是全部 35B 的权重或者至少是当前层需要的专家权重。这就是省计算不省存储的由来。2.2 显存到底被什么吃掉了很多人以为显存只装模型权重其实推理时的显存开销分好几块我按实际占用从大到小排一下显存占用项说明8GB 卡上的典型占比模型权重量化后的参数4bit 最省最大头决定能不能跑KV Cache上下文越长占用越大长对话时能吃掉 1-2GB激活值/中间张量前向计算的临时缓冲几百 MB 到 1GB框架开销CUDA context、cuBLAS 等固定 300-500MB对 MoE 来说权重这块有个特殊之处不是所有专家都需要同时驻留显存。如果推理框架支持专家卸载expert offload可以把不常用的专家放在内存甚至硬盘上用到的时候再换进来。这就是 8GB 能跑 35B 的核心机制——用内存和 PCIe 带宽换显存。但这里有个代价必须说清楚专家换入换出走的是 PCIe速度远低于显存带宽。如果路由命中率低、频繁换专家速度会惨不忍睹。所以实际能不能跑得舒服取决于模型的路由特性、你的内存大小和 PCIe 版本。2.3 为什么是 35B 这个量级35B 这个数字不是随便挑的。市面上主流的开源 MoE 模型比如 Qwen 系列的 MoE 版本、Mixtral 8x7B总参数约 47B激活约 13B都在这个区间。35B 左右的总参数4bit 量化后大约 17-18GB超过 8GB 显存但配合内存卸载是可行的。如果总参数再大比如 70B 以上即使卸载内存和带宽压力也会让体验变得很差。所以 8GB 35B 这个组合本质是在**刚好超出显存、但还没超出内存和带宽承受范围**的甜蜜点上做文章。再往上就是硬扛再往下就没必要折腾 MoE 了直接跑 7B 稠密模型更省心。3. 工具链选型为什么我最后选了 Ollama 打底3.1 几种主流方案的对比本地跑大模型的工具链这两年冒出来一大堆我实际折腾过的有 Ollama、llama.cpp、LM Studio、vLLM 这几种。针对 8GB 跑 MoE 这个场景我把它们的表现列一下工具MoE 支持显存卸载上手难度适合场景Ollama好自动低快速验证、日常使用llama.cpp好手动精细中极限压榨、调参LM Studio一般自动低图形界面党vLLM好有限高服务端、多并发我最后选 Ollama 打底原因很实际它对 MoE 的专家卸载是自动处理的不用我手动指定哪层放显存哪层放内存。对于先跑起来看看效果这个阶段省心比极致性能更重要。等跑通了、知道瓶颈在哪再换 llama.cpp 做精细调优也不迟。3.2 安装和基础配置Ollama 的安装没什么好说的官网下载对应系统的安装包一路下一步。装完之后验证一下ollama --version然后拉模型。这里要注意MoE 模型在 Ollama 的模型库里通常有专门的 tag别拉错了。以 Qwen 的 MoE 版本为例ollama pull qwen2.5:35b-a3b这里的35b-a3b命名规则很关键35b 是总参数a3b 是激活参数 3B。看到这种命名就知道是 MoE 架构。如果拉成普通的35b那就是稠密模型8GB 卡直接没戏。拉完之后先别急着跑看一眼模型信息ollama show qwen2.5:35b-a3b重点看两行参数量确认是 MoE量化格式确认是 Q4 或更低。如果是 Q8 或者 FP168GB 卡基本跑不动得换量化版本。3.3 关键环境变量调优Ollama 默认的显存调度策略偏保守8GB 卡上需要手动调几个环境变量才能把 MoE 的优势发挥出来。我在 Linux 下的配置是这样的export OLLAMA_NUM_PARALLEL1 export OLLAMA_MAX_LOADED_MODELS1 export OLLAMA_GPU_OVERHEAD0 export OLLAMA_KV_CACHE_TYPEq8_0逐个解释一下为什么这么设OLLAMA_NUM_PARALLEL1单并发。8GB 显存本来就紧张多并发会让 KV Cache 翻倍直接爆。OLLAMA_MAX_LOADED_MODELS1只加载一个模型避免多个模型抢显存。OLLAMA_GPU_OVERHEAD0这个参数控制给 GPU 预留的额外显存设 0 是把显存榨干。OLLAMA_KV_CACHE_TYPEq8_0KV Cache 量化到 8bit长上下文时能省一半左右显存。注意OLLAMA_GPU_OVERHEAD设 0 有风险如果系统桌面也占显存可能导致 Ollama 启动失败。建议先设 512跑通后再逐步降到 0。4. 实操全过程从拉模型到跑出第一个 token4.1 启动和首次加载观察配置好环境变量后启动 Ollama 服务ollama serve然后在另一个终端跑模型ollama run qwen2.5:35b-a3b第一次加载会明显慢因为要把 17-18GB 的权重从硬盘读进来再决定哪些放显存、哪些放内存。这时候打开另一个终端监控显存和内存watch -n 1 nvidia-smi我实测下来加载完成后显存占用稳定在 7.2-7.6GB内存占用在 12-14GB 左右。这个分布说明 Ollama 把一部分专家层留在了内存里显存里放的是常驻的注意力层和部分高频专家。4.2 参数配置的取舍逻辑跑起来之后真正影响体验的是几个推理参数。我在 Ollama 的 Modelfile 里做了这些设置PARAMETER num_ctx 4096 PARAMETER num_predict 512 PARAMETER temperature 0.7 PARAMETER top_p 0.9 PARAMETER repeat_penalty 1.1num_ctx设 4096 是个权衡。设大了 KV Cache 吃显存设小了对话记不住上下文。4096 在 8GB 卡上是个比较稳的值再往上比如 8192KV Cache 会多占 1GB 左右容易触发显存不足。num_predict限制单次生成的最大 token 数防止模型话痨把显存拖爆。512 够日常问答用了。4.3 实测速度数据这是大家最关心的部分。我在 RTX 4060 8GB 32GB DDR4 内存 PCIe 4.0 的配置下跑了几组测试测试场景生成速度首 token 延迟短问答100 token18-22 tok/s0.8-1.2s中等长度300 token15-18 tok/s1.0-1.5s长上下文接近 40968-12 tok/s2.5-4s连续对话第 5 轮后6-10 tok/s3-5s这个速度什么概念18 tok/s 大概是人正常阅读速度的 2-3 倍聊天体验是流畅的。但长上下文掉到 8 tok/s 以下时就能感觉到明显的等待了。对比一下同样这张卡跑 7B 稠密模型Q4 量化速度能到 40-50 tok/s。所以 MoE 35B 的代价是速度砍半换来的是明显更强的模型能力。值不值看你的用途。4.4 内存和 PCIe 的影响这里必须强调一个容易被忽略的点内存大小和 PCIe 版本对 MoE 卸载的影响极大。我做过对比测试同一台机器把内存从 16GB 加到 32GB速度提升了约 30%。原因是 16GB 时系统频繁触发内存交换专家换入换出被拖慢。32GB 之后所有专家都能常驻内存换入换出只走 PCIe不碰硬盘。PCIe 版本的影响更直接。PCIe 4.0 x16 的带宽约 32GB/sPCIe 3.0 只有 16GB/s。如果你的主板是 PCIe 3.0专家换入换出的速度会减半长上下文场景下掉速更明显。这个在买卡之前就得考虑清楚。5. 踩过的坑和排查实录5.1 显存溢出OOM的几种典型情况跑 MoE 最容易遇到的就是 OOM但原因不止一种。我整理了一个排查表现象可能原因解决方法加载到一半就 OOM量化版本太高Q8/FP16换 Q4 或 Q4_K_M对话几轮后 OOMKV Cache 累积降低 num_ctx开 KV 量化启动就 OOM桌面占显存太多关桌面特效调 GPU_OVERHEAD偶发 OOM内存不足触发交换加内存关其他程序我遇到最坑的一次是模型能加载但一提问就 OOM。排查半天发现是num_ctx设成了 8192KV Cache 直接把最后一点显存吃光了。改成 4096 之后稳定运行。5.2 速度突然变慢的排查思路速度变慢通常有几个信号按排查顺序来先看显存nvidia-smi看显存是不是满了。满了说明在频繁换专家得降 num_ctx 或换更低的量化。再看内存free -h看内存剩余。如果 swap 在涨说明内存不够专家被换到硬盘了。最后看 CPUtop看 CPU 占用。如果 CPU 跑满说明大量计算被卸载到 CPU 了这时候速度慢是必然的。我实测发现当内存占用超过 80% 时速度会断崖式下跌。所以留足内存余量比什么都重要。5.3 几个反直觉的经验经验一不是所有 MoE 模型都适合 8GB 卡。关键看激活参数和专家数量的比例。激活参数越小、专家越分散卸载越灵活。有些 MoE 模型虽然总参数 35B但激活参数高达 8B那 8GB 卡跑起来就很吃力。经验二量化不是越低越好。Q2 量化虽然省显存但模型能力下降明显有时候还不如跑个 Q4 的 7B 稠密模型。我一般建议 Q4_K_M 起步这是质量和体积的平衡点。经验三首 token 延迟比生成速度更影响体验。生成速度 15 tok/s 其实够用但如果首 token 要等 5 秒聊天节奏就断了。降低首 token 延迟的办法是减少上下文长度和预加载常用专家。6. 这套方案适合谁不适合谁折腾完这一圈我对 8GB 跑 35B 的定位有了比较清晰的认识。适合的场景个人本地知识库问答、离线文档处理、对隐私敏感的文本分析、学习研究 MoE 架构。这些场景对速度要求不高但对模型能力和数据本地化有要求。不适合的场景多人并发服务、实时对话系统、需要长上下文超过 8K的任务。这些场景要么需要更大显存要么需要专门的推理服务器。如果你的目标是搭建一个 200 人用的本地大模型那 8GB 消费级卡肯定不够得考虑专业卡或者多卡方案成本是另一个量级。但如果只是个人用、想体验一下 35B 级别模型的能力8GB 卡配合 MoE 卸载是完全可行的。最后分享一个我常用的判断方法先跑起来用nvidia-smi和free -h观察 10 分钟如果显存稳定在 7.5GB 以内、内存有 30% 以上余量、速度稳定在 10 tok/s 以上那这套配置就是可用的。任何一项不达标就得回去调参数或者换方案。这个标准比任何理论计算都实在。