1. 8GB 显存跑 35B 模型这事到底靠不靠谱先把结论摆在前面能跑但跑的不是你想象中那种“全量塞进显存”的跑法。如果你手里是一张 8GB 显存的消费级显卡比如 RTX 3060 Ti、RTX 4060、RTX 2070 这个档次看到“35B 参数”第一反应大概是“别逗了光权重就得几十个 G”。这个直觉没错——如果是一个稠密Dense的 35B 模型FP16 精度下光权重就要 70GB 左右INT4 量化也得接近 18GB8GB 显存连门都摸不到。但关键词里有个东西改变了整个游戏规则MoE 架构。MoE 全称 Mixture of Experts混合专家。它的核心特点是模型总参数量很大但每次前向推理只激活其中一小部分专家。也就是说35B 是“总盘子”但单次计算真正参与的可能只有 3B 到 6B 的活跃参数。这就给 8GB 显存留出了操作空间——前提是你得把“显存里放什么”和“内存里放什么”分清楚。这篇实录要解决的问题很具体在 8GB 显存的消费级显卡上把一个大参数量 MoE 模型跑起来并且跑得能用。适合谁看适合那些手里只有一张中端显卡、不想额外花钱升级硬件、但又想在本机折腾大模型的人。我会把整个过程的思路、踩过的坑、参数怎么调、速度到底多少全部摊开讲。不是那种“三步搞定”的爽文而是真实环境下反复试出来的记录。先明确一个前提本文讨论的是本地推理不涉及训练和微调。训练 35B 模型不是 8GB 显卡该想的事推理才是消费级显卡的主战场。另外我用的推理框架是Ollama原因是它对量化模型的支持比较成熟命令行交互简单适合快速验证。如果你习惯用 llama.cpp 或者 text-generation-webui思路是相通的只是操作界面不同。提示MoE 模型“总参数 35B”和“激活参数 3B”是两个完全不同的概念。前者决定模型文件多大、加载时占多少内存后者决定推理时算力消耗和显存占用。搞混这两个数字后面的所有判断都会错。2. MoE 架构到底怎么省显存把“专家”拆开看2.1 稠密模型和 MoE 模型的显存账本差异要理解为什么 8GB 能跑 35B得先算清楚显存到底被什么吃掉了。一个模型在推理时显存占用主要分三块权重占用、KV Cache 占用、计算中间激活占用。其中权重是大头KV Cache 随上下文长度增长中间激活相对小但也不能忽略。稠密模型的权重占用是“全量”的。一个 35B 稠密模型INT4 量化后大约 17.5GB按每参数 0.5 字节粗算INT3 大概 13GBINT2 大概 8.75GB。你看就算压到 INT28GB 也刚刚卡在边缘而且 INT2 量化后模型质量下降非常明显基本没法正常对话。MoE 模型不一样。以典型的 MoE 结构为例模型由共享层Attention、Embedding、LayerNorm 等和专家层FFN 部分被拆成多个专家组成。每次推理时Router路由网络会为每个 token 选择 Top-K 个专家参与计算。假设总共有 8 个专家每次只激活 2 个那么单次计算实际用到的专家权重只有 2/8。但这里有个关键点很多人会误解MoE 并不等于显存占用直接除以专家数。因为所有专家的权重都得加载到内存里备用Router 随时可能选中任何一个。所以 MoE 省的是计算量和计算时的显存带宽压力不是模型文件大小。模型文件该多大还是多大。那 8GB 显存怎么装下 35B 的 MoE答案是装不下全部但可以装下活跃部分。具体做法是让 Ollama 或 llama.cpp 把模型权重放在系统内存里推理时只把当前需要的专家层和共享层加载到显存。这就是所谓的CPUGPU 混合推理。GPU 负责算力密集的矩阵运算CPU 负责权重调度和部分计算。2.2 量化等级的选择Q4_K_M 是甜点但不是唯一解量化是让大模型跑进消费级硬件的关键手段。Ollama 支持多种量化格式常见的有 Q2_K、Q3_K_S、Q3_K_M、Q4_0、Q4_K_S、Q4_K_M、Q5_K_M、Q6_K、Q8_0 等。数字越小压缩越狠显存占用越低但模型“变笨”的风险越大。对于 8GB 显存跑 35B MoE我的实测结论是Q4_K_M 是最佳平衡点。Q4_K_M 大约每参数 0.5 字节35B 总参数对应模型文件约 17-18GB。这个大小放在系统内存里完全没问题现在主流机器 32GB 内存起步推理时 GPU 只需要加载当前活跃的专家和共享层显存占用能控制在 6-7GB。如果你显存更紧张比如只有 6GB可以退到 Q3_K_M模型文件约 13-14GB显存占用能压到 5GB 左右。但 Q3 量化后模型在复杂推理任务上的表现会明显下滑尤其是代码生成和数学计算。Q2_K 我不推荐除非你只是想让模型“能说话”不追求质量。量化等级35B MoE 模型文件大小8GB 显存占用实测质量评价Q2_K约 9-10GB4-5GB能跑但回答质量差不推荐Q3_K_M约 13-14GB5-6GB可用复杂任务吃力Q4_K_M约 17-18GB6-7GB推荐平衡最好Q5_K_M约 21-22GB7-8GB勉强容易爆显存Q8_0约 33-35GB不可能8GB 显存无解注意上表中的显存占用是“稳定推理时”的峰值不包括加载模型瞬间的波动。实际使用中如果你的上下文长度超过 4096 tokenKV Cache 会额外吃掉 1-2GB 显存需要预留余量。2.3 为什么不是所有 MoE 模型都能这么跑MoE 模型能不能在 8GB 显存上跑还取决于一个关键参数专家激活比例。有些 MoE 模型总参数 35B但每次激活 8 个专家中的 6 个活跃参数接近 26B那 8GB 显存根本扛不住。而有些模型激活比例低比如 8 选 2活跃参数只有 8-9B这才有操作空间。另外共享层的参数量也很关键。如果 Attention 层和 Embedding 层特别大即使专家层激活少共享层也得全量加载到显存。所以选模型的时候不能只看“总参数 35B”和“MoE”这两个标签得看具体的激活配置。我实测用的模型是一个 35B 总参数、激活约 3B 的 MoE 模型具体名称不展开避免导向性问题。这个激活比例下8GB 显存跑起来比较从容。如果你选的 MoE 模型激活参数超过 10B8GB 就会非常吃力甚至频繁触发内存交换速度掉到不可用。3. Ollama 部署实操从拉取到跑通的完整链路3.1 环境准备驱动、Ollama 版本和内存检查在开始之前先把基础环境确认一遍。这一步看起来简单但很多“跑不起来”的问题都出在这里。显卡驱动确保你的 NVIDIA 驱动版本足够新。Ollama 依赖 CUDA驱动太旧会导致 GPU 无法被识别。我用的驱动版本是 545 以上CUDA 版本 12.x。你可以用nvidia-smi命令查看当前驱动和 CUDA 版本。如果显示“command not found”说明驱动没装好先去官网下载对应显卡的驱动。Ollama 版本Ollama 更新很频繁不同版本对 MoE 模型的支持程度不一样。建议用最新稳定版。安装方式很简单官网下载对应系统的安装包一路下一步就行。安装完成后终端输入ollama --version确认。系统内存这是最容易被忽略的一点。8GB 显存跑 35B MoE模型权重主要放在系统内存里所以内存至少 32GB推荐 64GB。如果内存只有 16GB模型加载到一半就会因为内存不足而失败或者系统疯狂使用交换分区速度惨不忍睹。你可以用free -hLinux或任务管理器Windows查看内存容量和可用量。磁盘空间模型文件 17-18GB加上 Ollama 的缓存和系统临时文件建议预留 40GB 以上磁盘空间。SSD 是必须的机械硬盘加载模型会慢到让你怀疑人生。3.2 拉取模型和首次加载耐心比技巧重要环境确认无误后就可以拉取模型了。Ollama 的命令很直接ollama pull 模型名称拉取过程取决于你的网络速度17-18GB 的文件百兆宽带大概需要 20-30 分钟。拉取完成后用ollama list确认模型已经在本地。首次加载模型是最考验耐心的一步。当你执行ollama run 模型名称时Ollama 会先把模型权重从磁盘加载到系统内存然后再把当前需要的部分传输到显存。这个过程在 8GB 显存 32GB 内存的配置下大概需要 1-3 分钟。你会看到终端卡住不动别慌这是在加载不是死机。加载完成后你会看到对话提示符。这时候先别急着问复杂问题用一句简单的“你好”测试一下响应。如果模型能正常回复说明基本链路通了。提示首次加载后模型会常驻内存。如果你后续不再使用可以用ollama stop 模型名称释放内存和显存。但下次再跑又得重新加载所以如果频繁使用建议保持常驻。3.3 关键参数调优num_gpu、num_ctx 和 num_threadOllama 默认参数不一定适合 8GB 显存跑 35B MoE 的场景需要手动调整几个关键参数。这些参数可以通过 Modelfile 设置也可以在运行时通过 API 传入。num_gpu这个参数控制有多少层模型跑在 GPU 上。默认情况下Ollama 会尽量把能塞进显存的层都塞进去。但对于 MoE 模型我建议手动限制比如设置为 20-25 层具体取决于模型总层数。设太高会爆显存设太低会浪费 GPU 算力。你可以从 20 开始试观察nvidia-smi的显存占用逐步往上加直到显存占用接近 7GB 但不超过。num_ctx上下文长度。默认可能是 2048 或 4096。上下文越长KV Cache 越大显存占用越高。8GB 显存下我建议设 2048 或 3072。如果你需要处理长文档可以设 4096但要接受显存占用增加 1-2GB可能需要降低 num_gpu 来腾空间。num_threadCPU 线程数。MoE 模型有一部分计算在 CPU 上完成线程数设置合理能提升速度。一般设为物理核心数比如 8 核 CPU 设 816 核设 16。设太高会导致线程竞争反而变慢。一个典型的 Modelfile 配置大概长这样FROM 模型名称 PARAMETER num_gpu 22 PARAMETER num_ctx 3072 PARAMETER num_thread 12 PARAMETER temperature 0.7创建好 Modelfile 后用ollama create 自定义名称 -f Modelfile生成自定义模型然后ollama run 自定义名称运行。3.4 实测速度token/s 到底多少算能用速度是大家最关心的指标。我在 8GB 显存RTX 4060 32GB 内存 12 核 CPU 的配置下实测结果如下场景生成速度评价短对话100 token 回复8-12 token/s流畅接近打字速度中等长度300-500 token6-9 token/s可用等待感不明显长文生成1000 token4-6 token/s偏慢但能接受复杂推理代码、数学3-5 token/s慢适合不赶时间的任务这个速度是什么概念正常人阅读中文的速度大约是 5-8 字/秒对应 token 大概 4-6 token/s。所以 6-9 token/s 的生成速度基本能做到“边生成边读”不需要等太久。低于 3 token/s 就会明显感到卡顿适合后台跑任务不适合交互式对话。影响速度的最大因素是活跃参数比例和CPU-GPU 数据传输带宽。活跃参数越少GPU 计算越快内存带宽越大权重传输越快。DDR5 内存比 DDR4 有明显优势双通道比单通道快很多。如果你速度明显低于我的实测值先检查内存是不是单通道再检查 num_gpu 和 num_thread 设置。4. 踩坑实录那些让我折腾到半夜的问题4.1 显存溢出从“CUDA out of memory”到稳定运行第一次跑的时候我直接ollama run默认参数结果模型加载到一半就报CUDA out of memory。当时第一反应是“8GB 果然不够”差点放弃。后来查了日志才发现Ollama 默认把太多层塞进了 GPU导致显存溢出。解决过程分三步。第一步用nvidia-smi -l 1实时监控显存占用观察加载过程中显存什么时候爆掉。第二步手动设置num_gpu为较低值比如 15确认能稳定运行。第三步逐步增加num_gpu每次加 2跑一个测试对话观察显存峰值。最终稳定在 22 层显存占用 6.8GB留了 1GB 余量给 KV Cache 和系统波动。这个过程中有个反直觉的点num_gpu 不是越高越好。设太高会爆显存设太低会浪费 GPU 算力速度下降。最佳值需要实测不同模型、不同量化等级、不同上下文长度最佳 num_gpu 都不一样。注意如果你用的是 WindowsOllama 的显存管理不如 Linux 精细更容易出现溢出。建议 Windows 用户把 num_gpu 设得保守一点比如比 Linux 下低 2-3 层。4.2 加载卡死内存不足的隐蔽表现有一次我换了一个更大的 MoE 模型总参数差不多但共享层更大。加载时终端卡住超过 10 分钟没有任何输出。我以为是磁盘慢换了 SSD 还是卡。最后用htop一看内存占用飙到 95%系统在疯狂使用交换分区。原因很清楚模型文件 18GB加上 Ollama 自身的缓存和系统占用32GB 内存刚好卡在边缘。加载过程中需要额外的内存做权重转换和缓冲导致内存不足。解决办法有两个一是关闭其他占内存的程序二是增加系统内存。我后来加到 64GB加载时间从“卡死”变成 2 分钟左右。这个坑的隐蔽性在于它不报错就是卡住。很多人会以为是模型问题或者磁盘问题其实是内存不够。如果你遇到加载卡死先看内存占用再看磁盘 I/O。4.3 速度骤降上下文长度和 KV Cache 的隐形消耗跑通之后我试着让模型处理一篇长文档结果速度从 8 token/s 掉到 2 token/s而且越到后面越慢。一开始以为是模型变“累”了后来才想明白是 KV Cache 在作怪。KV Cache 是注意力机制为了避免重复计算而缓存的历史键值对。上下文越长KV Cache 越大显存占用越高。当显存不够时Ollama 会把部分 KV Cache 放到内存里导致每次生成新 token 都要在内存和显存之间传输数据速度自然暴跌。解决办法是控制上下文长度。如果任务不需要长上下文把num_ctx设小一点比如 2048。如果确实需要长上下文那就接受速度下降或者升级显存。没有两全其美的办法这是硬件物理限制。4.4 模型“变笨”量化过度的代价为了追求更低的显存占用我试过 Q2_K 量化。显存占用确实降到了 4.5GB但模型回答质量惨不忍睹。简单的事实性问题还能应付稍微复杂一点的逻辑推理就开始胡言乱语代码生成基本不可用。这让我意识到一个道理量化的本质是用精度换空间但精度损失是非线性的。从 FP16 到 Q8质量损失很小从 Q8 到 Q4质量损失可感知但可接受从 Q4 到 Q2质量损失急剧放大模型基本“废了”。所以 8GB 显存跑 35B MoEQ4_K_M 是底线再往下压就得不偿失。如果你发现模型回答质量明显下降先检查量化等级再检查是不是上下文太长导致模型“遗忘”了前面的内容。这两个原因占了“模型变笨”问题的八成以上。5. 这套方案适合谁不适合谁5.1 适合的场景个人学习、原型验证、离线任务8GB 显存跑 35B MoE最适合的场景是个人学习和技术验证。你想了解 MoE 架构的实际表现想测试某个模型的能力边界或者想在本机搭一个离线可用的对话助手这套方案完全够用。速度虽然不如云端 API但胜在数据不出本机隐私性好而且没有调用次数限制。另一个适合的场景是离线批处理任务。比如你有一批文本需要做摘要、分类或翻译不需要实时交互可以晚上挂着跑第二天看结果。这种场景下速度慢一点无所谓关键是能跑通、不花钱。5.2 不适合的场景高并发、实时交互、生产环境如果你需要同时服务多个用户或者要求毫秒级响应8GB 显存跑 35B MoE 完全不合适。单用户交互都已经在 6-9 token/s 徘徊多用户并发会直接让显存和内存双双爆掉。生产环境建议至少 24GB 显存起步或者直接用云端 API。另外如果你对模型质量要求极高比如做专业代码生成或法律文书撰写Q4 量化的 35B MoE 可能达不到你的要求。量化后的模型在细节准确性和逻辑严密性上和全精度模型有可感知的差距。这种场景下要么升级硬件跑更高精度要么接受云端服务的成本。5.3 硬件升级的性价比分析如果你现在用的是 8GB 显卡想升级到能更从容跑 35B MoE 的配置怎么选最划算我列了一个简单的对比升级方案显存可跑量化等级预估速度性价比评价保持 8GB8GBQ4_K_M6-9 token/s零成本能用升级 12GB12GBQ5_K_M10-14 token/s中等提升明显升级 16GB16GBQ6_K14-18 token/s较高接近流畅升级 24GB24GBQ8_020 token/s高但成本也高从 8GB 到 12GB 的升级速度提升大约 50%显存余量更充足不容易爆。从 8GB 直接到 24GB体验会有质变但显卡价格也翻了几倍。我的建议是如果你只是偶尔用用8GB 凑合够了如果你每天都用而且对速度有要求至少升到 12GB 或 16GB。提示升级显卡之前先确认电源功率和机箱空间。中高端显卡对电源要求不低别买了显卡发现电源带不动。6. 几个容易被忽略的细节和我的个人体会第一个细节是模型文件的存放位置。Ollama 默认把模型放在系统盘如果你系统盘是容量较小的 SSD很快就会被撑满。可以通过设置环境变量OLLAMA_MODELS把模型目录改到大容量硬盘。这个操作在模型多了之后特别重要不然系统盘红了会影响整个系统运行。第二个细节是散热。8GB 显卡跑大模型时GPU 占用率会长时间维持在较高水平发热比打游戏还猛。如果你的机箱风道不好显卡温度很容易冲到 80 度以上然后触发降频速度进一步下降。我后来加了一个机箱风扇温度降了 8-10 度速度稳定了不少。第三个细节是不要同时跑多个模型。Ollama 默认会保持模型常驻内存如果你先后跑了两个不同的模型两个都会占着内存不放。32GB 内存跑两个 35B MoE 模型直接爆内存。记得用ollama stop及时释放不用的模型。我个人在实际操作中的体会是8GB 显存跑 35B MoE技术上是可行的但需要你接受“它不是即问即答”的现实。它更像是一个慢速但可靠的本地助手适合不赶时间的场景。如果你追求的是流畅的对话体验要么降低模型规模比如跑 7B 或 13B 稠密模型要么升级硬件。没有捷径硬件限制就是硬件限制软件优化只能缓解不能突破。最后分享一个小技巧如果你发现模型在某个任务上表现不好先别急着换模型试试调整 temperature 参数。MoE 模型对 temperature 比较敏感默认的 0.8 有时候会让它“太发散”。把 temperature 降到 0.3-0.5回答会更聚焦、更准确。这个调整成本为零但效果往往立竿见影。