1. 为什么我盯上了 8GB 显存跑 35B 这件事先说结论8GB 显存能跑 35B 参数的模型靠的不是魔法是 MoE 架构的稀疏激活特性加上内存与显存的合理分工。我手上这张 8GB 显存的消费级显卡放在两年前连 13B 的量化模型都跑得磕磕绊绊现在却能稳定对话一个 35B 的 MoE 模型这个反差本身就值得写一篇完整的实录。事情的起因很简单。我平时做本地大模型部署和本地知识库搭建手头主力机器就是一台普通消费级台式机显卡是 8GB 显存那一档。之前一直跑 7B、8B 级别的模型效果凑合但遇到需要多步推理、长上下文理解、代码生成这类任务时明显感觉脑子不够用。想上更大的模型第一反应是换卡可一张大显存显卡的价格够我再配一台整机了。于是我把目光转向了 MoE 架构——这个在服务器端已经验证过的思路能不能下放到消费级显卡上实测下来答案是能但有前提。这篇文章我会把整个过程的思路、参数计算、踩过的坑、以及最后稳定运行的配置全部摊开讲。适合两类人看一类是手里只有 8GB 显存显卡、想榨干硬件潜力的折腾党另一类是想搞清楚 MoE 到底怎么回事、为什么它能让小显存跑大模型的技术爱好者。不管你是刚接触本地部署大模型的新手还是已经玩过 ollama 本地部署大模型的老手这篇实录里的细节应该都能给你一些参考。需要提前说明的是我用的工具链是 ollama 本地部署大模型这套方案原因是它对消费级显卡友好、配置简单、社区模型库全。如果你习惯用别的推理框架核心原理是一样的只是操作命令不同。2. 先搞懂 MoE35B 的模型为什么不需要 35B 的显存2.1 稠密模型和 MoE 模型的本质区别要理解 8GB 跑 35B 这件事必须先搞清楚稠密模型和 MoE 模型的区别。传统的稠密模型比如一个 32B 的 Llama 系列模型你每问它一个问题它内部所有的 32B 参数都会参与计算。这意味着什么意味着这 32B 参数必须全部加载到显存里否则计算就没法进行。按 FP16 精度算32B 参数就是 64GB 显存就算量化到 4bit也要 16GB 左右。8GB 显存连门都摸不到。MoE 全称是 Mixture of Experts混合专家。它的结构不是一个大一统的网络而是把前馈网络层拆成了很多个专家子网络再加一个路由器Router来决定每个 token 该交给哪几个专家处理。关键在于每次推理只激活其中一小部分专家大部分专家处于休眠状态。举个例子一个 35B 的 MoE 模型可能总共有 35B 参数但每次前向传播只激活其中 3B 到 5B 的参数。这就好比一家有 35 个专家的咨询公司你问一个法律问题公司只派 3 个法律专家来回答剩下 32 个专家该干嘛干嘛不参与这次咨询。计算量按激活参数算但知识储备按全部参数算——这就是 MoE 的核心魅力。2.2 激活参数和总参数的关系这里有个很多人容易混淆的点MoE 模型的大小到底看哪个数字答案是两个都要看但用途不同。总参数决定模型的知识容量和文件体积。一个 35B 的 MoE 模型权重文件加起来就是 35B 参数那么大量化到 4bit 大约 18GB 到 20GB 的磁盘占用。激活参数决定推理时的计算量和显存占用峰值。如果每次只激活 3B 参数那计算时的显存需求就接近一个 3B 稠密模型。但这里有个陷阱激活参数少不代表显存占用就少。因为路由器需要知道所有专家的存在才能做选择理论上所有专家的权重都得能被访问到。这就引出了下一个关键问题——MoE 架构要全部参数进显存吗2.3 MoE 架构要全部参数进显存吗这是我在实测前最关心的问题也是热词里被问得最多的。答案分两种情况第一种如果推理框架把全部专家权重都加载到显存那 35B 模型 4bit 量化后也要接近 20GB 显存8GB 卡直接出局。这种方案叫全量驻留适合显存充足的服务器。第二种如果推理框架支持专家权重按需加载也就是把不常用的专家放在内存甚至磁盘上只把当前激活的专家和路由器加载到显存那显存占用就能大幅下降。这种方案叫分层加载或offload是消费级显卡跑大 MoE 的关键。我实测用的 ollama 方案底层依赖 llama.cpp 的推理能力它支持把部分层放到内存CPU 推理部分层放到显存GPU 推理。对于 MoE 模型它会把注意力层和路由器放在显存专家层根据显存余量动态分配。这就是 8GB 能跑起来的根本原因——不是所有参数同时进显存而是按需调度。注意分层加载的代价是速度。专家层如果频繁在内存和显存之间搬运推理速度会明显下降。所以这套方案适合对速度要求不极端、但对模型能力有要求的场景比如个人知识库问答、文档总结、代码辅助而不是高并发在线服务。3. 实测环境与模型选型8GB 显存到底能塞下什么3.1 硬件与软件环境清单先把我的实测环境交代清楚方便你对照自己的机器判断可行性。项目配置显卡8GB 显存消费级显卡内存32GB DDR4处理器6 核 12 线程硬盘NVMe SSD剩余空间 100GB操作系统Windows 11推理工具ollama 本地部署方案模型格式GGUF 量化格式内存这一项特别关键。8GB 显存跑 35B MoE内存至少要 32GB因为被 offload 到内存的专家权重需要地方放。如果内存只有 16GB模型加载阶段就可能因为内存不足而失败。硬盘也要留足空间35B 模型 4bit 量化后接近 20GB加上系统和其他文件100GB 剩余空间是比较稳妥的。3.2 模型选型为什么是 35B 这个量级市面上 MoE 架构的开源模型不少我选 35B 这个量级是有考虑的。太小的 MoE比如 8B 总参数激活参数太少能力提升不明显跑起来和稠密 7B 差不多没必要折腾。太大的 MoE比如 100B 以上即使分层加载内存和硬盘压力也太大消费级机器扛不住。35B 左右是一个甜点区总参数够大知识容量可观激活参数通常在 3B 上下计算压力可控4bit 量化后文件体积在 20GB 以内普通硬盘放得下。选型时我重点看三个指标总参数、激活参数、量化后的文件大小。总参数决定能力上限激活参数决定推理速度文件大小决定能不能装下。这三个数字在模型的说明页一般都会标注选之前一定要看清楚。3.3 量化等级的选择Q4 还是 Q5量化等级直接决定模型质量和资源占用。我实测对比了 Q4_K_M 和 Q5_K_M 两个等级。Q4_K_M 是 4bit 量化的中等档文件最小35B 模型大约 20GB推理速度最快但质量损失相对明显尤其在长文本理解和细节推理上。Q5_K_M 是 5bit 量化的中等档文件大约 24GB质量更接近原始模型但内存和显存压力更大速度慢一档。我的建议是8GB 显存优先选 Q4_K_M。原因是显存本来就紧张Q5 带来的质量提升在分层加载的速度损失面前不太划算。如果你内存有 64GB 以上可以试试 Q5体验会更好。至于 Q3 或更低的量化我不推荐35B 模型降到 3bit 后质量下降太明显还不如直接跑一个高质量的 14B 稠密模型。4. 完整实操从零把 35B MoE 跑起来4.1 安装与基础配置第一步是装 ollama。官网下载对应系统的安装包一路下一步就行。装完后打开终端输入ollama --version确认安装成功。Windows 用户注意ollama 默认会随系统启动占用一点后台资源如果不想让它常驻可以在服务里改成手动启动。第二步是配置显存和内存的使用策略。ollama 默认会尽量把层放到 GPU但 MoE 模型需要更精细的控制。我通过环境变量来调整# 设置 GPU 层数数值越大放显存的层越多 set OLLAMA_GPU_LAYERS20 # 设置并行请求数个人使用设为 1 即可 set OLLAMA_NUM_PARALLEL1 # 设置上下文长度太长会吃显存 set OLLAMA_CONTEXT_LENGTH4096OLLAMA_GPU_LAYERS这个参数是调优的核心。设得太高显存不够会报错或自动回退到 CPU设得太低GPU 利用率不足速度上不去。我的经验是从 20 开始试逐步往上加直到显存占用接近但不超过 8GB。4.2 拉取模型与首次加载配置好环境变量后拉取模型ollama pull 模型名称:35b-q4_K_M拉取过程取决于网速20GB 的文件大概要等一段时间。拉完后首次加载会做一次模型映射把权重分配到显存和内存这个过程可能持续几分钟期间硬盘和内存占用会飙升属于正常现象。首次加载时我建议开着任务管理器盯着看。重点看两个数字显存占用和内存占用。显存应该稳定在 7GB 到 7.8GB 之间留一点余量给系统内存占用会在 20GB 到 28GB 之间波动取决于当前激活的专家数量。如果内存直接爆了说明你的内存不够需要换更小的量化等级或者加内存。4.3 参数调优让 8GB 显存物尽其用模型跑起来只是第一步调优才是让体验从能跑到好用的关键。我实测下来有几个参数对性能影响最大。上下文长度。默认可能是 2048 或 4096这个值直接吃显存。上下文越长KV Cache 越大显存压力越大。8GB 显存下4096 是比较稳妥的值再往上就要牺牲 GPU 层数。如果你主要做短对话2048 也够用还能省出显存多放几层到 GPU。批处理大小。个人使用设为 1 就行设大了会成倍增加显存占用而且对单用户场景没有收益。线程数。CPU 推理部分用到的线程数设为物理核心数比较合适。我 6 核 12 线程设成 6 或 8 都试过差别不大设成 12 反而因为超线程调度有轻微下降。调优的过程就是不断试错。我的方法是固定其他参数只调一个观察速度和显存占用的变化找到平衡点。这个过程可能要花一两个小时但调好之后体验提升很明显。5. 实测数据与性能表现5.1 速度实测每秒能出多少字这是大家最关心的。我在调优后的配置下做了几组测试输入一段 200 字左右的中文问题让它生成 300 字左右的回答。场景生成速度首字延迟短对话上下文 2048约 8-12 字/秒1-2 秒中等上下文4096约 6-9 字/秒2-3 秒长文档总结接近 4096约 4-6 字/秒3-5 秒这个速度什么概念比纯 CPU 跑 7B 模型快比 GPU 全量跑 7B 模型慢。日常对话完全够用读起来不会觉得卡顿。但如果你要它一次性生成几千字的长文等待时间会比较明显。速度波动主要来自专家调度。当问题涉及的领域比较集中时激活的专家少速度快当问题跨多个领域时路由器要频繁切换专家速度会下降。这也是 MoE 模型的一个特点——速度不是恒定的跟问题内容有关。5.2 质量实测35B MoE 到底比 7B 强多少光有速度不够质量才是上大模型的理由。我拿同一组问题分别问了 7B 稠密模型和 35B MoE 模型对比结果。在事实性问答上35B MoE 的准确率明显更高尤其是涉及多步推理的问题7B 经常在第二步就偏了35B MoE 能一路推下去。在代码生成上35B MoE 写出的代码结构更合理边界处理更完善7B 的代码经常需要大改。在长文档理解上差距最大35B MoE 能抓住文档里的细节和逻辑关系7B 经常漏掉关键信息。但 35B MoE 也不是全面碾压。在一些简单的日常对话上两者差别不大甚至 7B 因为速度快体验反而更好。所以我的用法是简单任务用 7B复杂任务切 35B MoE按需选择。5.3 资源占用实测显存、内存、硬盘的真实数字跑起来之后我记录了稳定运行时的资源占用。显存占用稳定在 7.2GB 到 7.8GB留了约 0.2GB 到 0.8GB 余量。这个余量不能省因为系统和其他程序也要用显存占满了容易出问题。内存占用在 22GB 到 28GB 之间波动峰值出现在加载模型和处理长上下文时。硬盘占用就是模型文件本身约 20GB加上 ollama 的缓存总共 25GB 左右。这里有个经验内存占用是动态的不是固定的。因为专家权重是按需从内存加载到显存的不同问题激活的专家不同内存里的权重换入换出占用就会波动。所以内存要留足余量32GB 是底线64GB 会更从容。6. 踩过的坑与排查技巧实录6.1 加载失败显存和内存的双重陷阱我遇到的第一个坑是模型加载到一半失败报错信息很模糊只说资源不足。排查后发现是两个问题叠加一是OLLAMA_GPU_LAYERS设得太高显存不够二是内存被其他程序占了不少导致 offload 的权重放不下。解决方法分两步。先把OLLAMA_GPU_LAYERS降到 15 试试能加载起来再逐步往上加。然后关掉不必要的后台程序尤其是浏览器Chrome 开十几个标签页能吃掉好几个 G 的内存。如果还是不行就换更小的量化等级。提示加载失败后不要反复重试先看任务管理器的资源曲线确认是显存爆了还是内存爆了对症下药。6.2 速度突然变慢专家调度的锅用了一段时间后我发现速度会突然变慢从 10 字/秒掉到 3 字/秒。一开始以为是显卡降频查了温度正常。后来才想明白是问题内容变了激活的专家变多内存和显存之间的搬运变频繁速度自然下降。这个问题的解法不是调参数而是调整使用习惯。把复杂问题拆成几个简单问题分别问比一次性问一个大问题速度更快。另外保持对话上下文简洁及时清理不必要的历史记录也能减少专家调度的负担。6.3 常见问题速查表问题现象可能原因解决方法加载失败报资源不足显存或内存不够降低 GPU 层数关闭后台程序换小量化速度突然变慢专家调度频繁拆分问题清理上下文输出质量下降量化等级太低换 Q5 量化或减少上下文长度显存占用居高不下上下文太长降低上下文长度到 2048模型响应卡顿内存不足导致换页加内存或换更小模型首次加载特别慢正常现象耐心等待后续加载会快6.4 几个独家避坑心得第一不要在模型加载时做其他重活。加载阶段内存和硬盘压力最大这时候开个大软件或者拷贝大文件很容易导致加载失败。第二定期重启 ollama 服务。长时间运行后内存碎片和缓存积累会影响性能重启一下能恢复。我一般每天重启一次。第三模型文件放在 SSD 上。机械硬盘的读取速度会成为瓶颈尤其是首次加载和专家权重换入换出时SSD 和机械硬盘的差距非常明显。第四别迷信参数全进显存。有些教程教你强行把所有层塞进显存8GB 卡上这是不可能的强行设置只会导致失败或系统不稳定。分层加载才是消费级显卡的正道。7. 这套方案适合谁以及还能怎么扩展7.1 适用场景与人群这套 8GB 跑 35B MoE 的方案最适合的是个人用户和小团队内部使用。典型场景包括本地知识库搭建把公司文档、个人笔记喂进去做问答代码辅助让模型帮忙读代码、写注释、找 bug文档处理长文总结、翻译、改写。这些场景对速度要求不极端但对模型能力有要求正好匹配 MoE 分层加载的特点。不适合的场景也很明确高并发在线服务多人同时用会排队实时性要求极高的任务比如实时翻译、实时对话机器人对稳定性要求苛刻的生产环境消费级硬件的稳定性毕竟有限。7.2 后续扩展方向如果你跑通了这套方案想进一步提升有几个方向可以试。一是加内存。从 32GB 加到 64GB能显著减少专家权重换入换出的频率速度会有可感知的提升。这是性价比最高的升级。二是换更大显存的卡。如果预算允许换一张 12GB 或 16GB 显存的卡能把更多层放到 GPU速度提升明显。但要注意显存大了之后MoE 的优势就没那么突出了可以考虑直接跑稠密大模型。三是尝试不同的 MoE 模型。不同模型的专家数量、激活策略、路由算法都不一样实际体验差别很大。多试几个找到最适合你任务的那个。四是结合本地知识库。把模型和向量数据库结合做检索增强生成能让模型回答更准确、更贴合你的私有数据。这是本地部署大模型最有价值的扩展方向。7.3 关于成本的实话最后说点实在的。这套方案的成本主要是硬件8GB 显卡加 32GB 内存的机器如果新配大概几千块。如果手头已有类似配置那就是零成本。相比租用云端大模型服务本地部署的优势是数据不出本地、无使用限制、长期成本低。劣势是前期投入和折腾时间。我个人在实际操作中的体会是本地部署大模型这件事硬件只是门槛真正的价值在于你对模型的控制权和数据的私密性。8GB 跑 35B 这个方案本质上是用时间换空间、用调度换显存它不完美但足够实用。如果你愿意花一个周末折腾收获的是一个完全属于你自己的、能力不俗的 AI 助手。这个投入产出比我觉得值。
