8GB显存也能跑35B大模型？MoE量化部署全攻略

上个月我在二手群收了一张 8GB 显存的 RTX 4060本来只想跑 Stable Diffusion 出点素材图结果朋友甩过来一句“35B 的 MoE 模型你用 8GB 试试” 我当时第一反应是不信——35B 就算是 INT4 量化文件也得 20GB 上下8GB 显存连一半都塞不下凭什么跑但真把环境和模型装好之后我发现这个判断只对了一半显存是装不下但本地大模型不一定非要全部装进显存。这篇记录就是一张消费级显卡、一台普通电脑跑通 35B 模型的完整过程适合手里只有 8GB 甚至 6GB 显存、又想在本地部署 AI 大模型的人参考。里面没有云端租卡没有双路服务器只有我自己踩过的坑和最终的稳定配置。1. 先算笔账35B 模型到底要吃多少显存1.1 一个公式看懂显存和参数的关系很多人听到“35B”第一反应是“35B 参数 35GB 显存”这个直觉其实错得不算离谱但漏掉了精度。模型权重占用的空间跟存储精度直接相关。权重占用GB 参数量B× 每参数比特数 / 8FP16半精度16bit35B × 16 / 8 70GBINT88bit35B × 8 / 8 35GBQ4_K_M约 4.5~4.8bit35B × 4.5 / 8 ≈ 19.7GB也就是说同样一个 35B 模型FP16 要 70GBQ4 量化后只要 20GB 左右。这就是消费级显卡敢碰 35B 的第一块垫脚石量化把模型体积砍到了原来的四分之一不到。但问题来了8GB 显存依然装不下 20GB 的权重文件。所以这里必须把“显存”和“内存”拆开看。显存是 GPU 的专属工作间内存是 CPU 和系统共享的大仓库。跑本地大模型时模型文件并不要求全部躺在显存里只要显存 可用内存的总容量能容纳下模型文件系统就能勉强把模型跑起来显存管加速内存管存放。打个比方显存是工位内存是仓库35B 模型是一堆材料工位放不下没关系只要仓库够大工人用的时候再从仓库搬一部分过来就行速度慢一点但活儿能继续干。我实测下来8GB 显存 32GB 内存跑 35B 的 Q4 量化 MoE 模型完全可行。如果你只有 16GB 内存那就很悬因为系统本身还要占掉 4~5GB剩下 11GB 左右连模型文件都塞不下。所以这篇文章的第一个结论很直接8GB 显存跑 35B显存是必要条件内存才是决定性条件。1.2 为什么 MoE 是低显存跑大模型的突破口35B 模型还有个大分类Dense稠密和 MoE混合专家。同样是 35B 总参数量Dense 模型每一个 token 都要激活全部 35B 参数推理时算力需求极高MoE 模型虽然总参数也是 35B但内部被拆成了多个“专家网络”每次推理只激活其中一小部分专家。现在热词里总有人问“MoE 架构要全部参数进显存吗”我的实测答案是模型文件在加载时会完整占用内存或显存空间不可能只加载“激活参数”那一小部分但因为激活参数少推理时的计算量和 KV Cache 开销会比同体量的 Dense 模型低很多。换句话说MoE 解决的是“算不动”和“显存带宽不够”的问题而不是“装不下”的问题。你要装下模型依然得准备 20GB 左右的物理内存空间。这也是为什么社区里最近讨论的 35B MoE 模型比如 Minimax H3 这类会被认为比同尺寸 Dense 模型更适合低显存设备总文件大但每次推理只让 2~3B 参数真正干活8GB 显存只负责搬运一部分层剩下的层在内存里慢慢算最终效果是能跑只是没有云端 API 那么飞快。如果你拿一个非 MoE 的 32B 千问模型来试8GB 显存跑 Q3 量化都费劲这就不是简单的“显存容量”能解决的。1.3 量化等级别选错Q4 和 Q3 差多少GGUF 量化格式是当前本地部署的主流常见有 Q2、Q3、Q4、Q5、Q8 几个档位。以 35B 模型为例量化等级文件大小参考相对 FP16 质量适合场景Q8_0约 35GB很高显存充足、追求质量Q5_K_M约 23GB高12GB 显存 32GB 内存Q4_K_M约 19~21GB中高8GB 显存 32GB 内存甜点档Q3_K_M约 16~17GB中低8GB 显存 16GB 内存能用但不推荐IQ4_XS约 17~18GB中上极端吃空间时可用速度比 Q3 好我这次选的是 Q4_K_M。理由很简单这是一个质量和体积比较平衡的组合。Q3 确实更小但回答复杂问题时会明显出现句子不通、逻辑跳步的现象尤其是中文场景更明显。Q4_K_M 在代码解释、知识问答、角色扮演这些日常测试里体感质量接近原版模型而文件体积只比 Q3 大三四个 GB这点空间用 32GB 内存很容易覆盖。还有一个容易踩的坑量化等级不是越高越好。8GB 显存用户看到 Q8 以为“质量更高”下载下来才发现权重 35GB内存 16GB直接启动失败。本地部署的第一步永远是先确认“总量装得下”再考虑质量。2. 消费级本地部署的硬件与软件选型2.1 8GB 显存起步12GB 更舒服消费级显卡里8GB 显存是一个很微妙的分界线。NVIDIA 这边常见的有 RTX 3050、RTX 3060 8GB、RTX 4060、RTX 4060 Ti 8GB、RTX 5060 8GB 这类AMD 这边有 RX 6600、RX 7600 等。如果你想跑 35B 这类大模型我建议把目标定在 8GB 显存起步不要低于 6GB否则即使能启动速度也会低到让人失去耐心。我实测用的是 RTX 4060 8GB另一台备用机是 RTX 3060 12GB。两者在同一个 35B MoE 模型上的差距非常明显8GB 版本生成速度大约在 3~5 token/s12GB 版本能到 6~8 token/s。原因很简单12GB 显存能放下更多层CPU 和 GPU 之间搬运数据的频率更低。有人问“Minimax H3 用 RTX 3060 12G 能跑吗”我这边用 3060 12GB 跑同类 35B MoE 的结论是能跑而且体验比 8GB 好不少但前提仍然是系统内存要够。如果你现在还没有显卡只有一个大概预算我的建议顺序是显存容量优先于显卡型号。4060 8GB 和 3060 12GB 之间我会毫不犹豫选 3060 12GB跑大模型时多出的 4GB 显存比几代架构差异更值钱。当然如果你还要兼顾游戏那就按游戏性能需求来选毕竟本地大模型只是其中一个场景。2.2 Ollama 与 llama.cpp两条路线怎么选本地部署 AI 大模型的工具很多但绝大多数人最终会落到两个选择Ollama 和 llama.cpp。Ollama 本质上是 llama.cpp 的封装层自带模型管理、API 服务和一套简化命令llama.cpp 则是更底层的 C 推理框架需要自己下模型文件、自己敲命令。我的经验是第一次接触本地大模型直接上 Ollama遇到速度或显存分配问题再用 llama.cpp 做对照实验。Ollama 安装非常简单Windows 有安装包Linux 一条命令装完。装好后核心操作就两个# 如果模型在 Ollama 官方库直接拉取 ollama pull m35b # 如果是本地 GGUF 文件用 Modelfile 导入 ollama create m35b -f Modelfilellama.cpp 则适合手动指定 GPU 层数、逐层调试。比如我想知道“到底有多少层跑在 GPU 上更合理”用命令行就能反复试llama-cli -m m35b.Q4_K_M.gguf -ngl 20 --ctx-size 4096 -t 6这里的-ngl 20表示把前 20 层放到 GPU其余层留在 CPU。这个参数在 Ollama 里也能通过 Modelfile 写但 Ollama 默认会自动分配有时候你反而不知道它到底把哪些层放到了 GPU 上。两个工具配合使用才算真正掌握低显存跑大模型的调优手段。2.3 AMD 核显用户怎么手动分配显存不是所有人都有独显。最近热词里出现 Ryzen AI Max 395 这类高性能核显平台这类 CPU 的核显性能足以跑中小型本地模型但显存是从系统内存里“借”出来的默认分配往往很小。如果你用的是 AMD 核显平台进 BIOS 找“UMA Frame Buffer Size”或“IGPU VRAM”选项把它从默认的 512MB 或 1GB 手动调到 6GB 甚至 8GB。这个操作的实质是从系统内存里划出一块固定区域给核显当显存所以整机内存如果不到 32GB建议不要调太高否则模型没跑起来系统先内存告急。NVIDIA 独显用户不需要做这一步因为独显显存是独立物理硬件驱动会自动调度不存在“手动分配”这个概念。还有一个小提醒核显跑 35B MoE 不是不可能但带宽会被内存速度卡住。DDR5 双通道和 DDR4 单通道的差距非常明显8GB 核显显存 32GB 内存的方案速度大概率比 RTX 4060 低一倍以上。如果预算能加一点一张二手 3060 12GB 是更好的投资。3. 8GB 显存跑 35B 完整实测记录3.1 下载模型到导入 Ollama关键在 Modelfile这次实测用的模型是一个 35B 参数的 MoE 模型量化格式选 Q4_K_MGGUF 文件大小约 19.6GB。拿到模型文件后我没有直接ollama pull而是走了一遍本地导入流程因为这样可以精确控制参数也不依赖模型是否在官方库里。步骤很简单把下载好的m35b.Q4_K_M.gguf放到一个固定目录在同一个目录下新建一个文本文件命名为Modelfile写入基础配置执行ollama create m35b -f Modelfile执行ollama run m35b我的 Modelfile 是这样写的FROM ./m35b.Q4_K_M.gguf PARAMETER num_ctx 4096 PARAMETER temperature 0.6 PARAMETER top_p 0.9 SYSTEM 你是一个耐心、简洁的中文助手回答问题时先给结论再展开理由。有几个细节值得留意。FROM后面的路径是相对当前目录的如果你把 Modelfile 放在其他目录路径就要写对。num_ctx控制上下文长度8GB 显存场景下 4096 是一个比较稳的值不要一上来就填 8192。SYSTEM是系统提示词可以自由定制但不要指望靠它去绕什么安全限制后面我会详细说。导入完成后可以用ollama list确认模型存在。第一次运行前建议先看下磁盘剩余空间Ollama 的默认模型目录可能和 GGUF 所在目录不是一个盘需要额外拷贝一份索引和 blob 文件20GB 模型导入后C 盘或者模型目录所在盘至少要留 30GB 空间。3.2 上下文、并发、GPU 层数怎么设一次说清很多教程只告诉你“装 Ollama 就能跑”但跑起来之后发现速度飘忽不定其实问题多半出在上下文和并发设置上。Ollama 有几个环境变量非常重要# 服务监听地址让局域网内其他设备也能访问 export OLLAMA_HOST0.0.0.0:11434 # 并发请求数低显存场景强烈建议保持 1 export OLLAMA_NUM_PARALLEL1 # 同时加载的模型数只保留一个 export OLLAMA_MAX_LOADED_MODELS1 # 模型空闲多久后卸载5分钟比较合适 export OLLAMA_KEEP_ALIVE5mWindows 用户可以在系统环境变量里新建同名变量Linux 用户在启动ollama serve之前 export 即可。为什么并发必须设 1因为每多一个并发请求Ollama 就要为额外的 KV Cache 分配显存和内存。8GB 显存本来就很紧张并发 2 的情况下模型很可能被强制搬到更多层到 CPU速度从 3~5 token/s 直接掉到 1 token/s。GPU 层数方面Ollama 默认会自动把能塞的层都塞进显存这通常没问题。但如果你想手动控制可以在 Modelfile 里加一行PARAMETER num_gpu 20这里的20是层数不是百分比。谁也不知道你的模型一共多少层所以一个稳妥的调试方法是先从一半层数开始如果nvidia-smi显示显存还有富余就逐步往上加一旦出现显存溢出就回退几层。别指望一次调到位本地大模型的调优本来就是一门“试错学”。3.3 首次启动实测显存、内存、速度全记录我这次的实测环境如下硬件/软件配置CPUIntel i5-12400F6 核 12 线程内存32GB DDR4-3200显卡NVIDIA RTX 4060 8GB系统Windows 11工具Ollama llama.cpp 交叉验证模型35B MoE Q4_K_M约 19.6GB第一次执行ollama run m35b显存占用不是瞬间拉满的。模型加载过程大约持续 20~30 秒随后nvidia-smi显示显存占用约 7.3GB系统内存占用约 13GB。这个分布符合预期模型权重大约有一半被搬运到显存另一半留在内存页缓存里。注意内存占用 13GB 包括了模型权重、KV Cache 和 Ollama 运行时开销所以 16GB 内存根本扛不住32GB 才比较从容。生成速度方面简单问答场景大概 4~5 token/s回答“用一句话介绍自己”这种短任务首字响应约 2~3 秒。一旦让它写一段 500 字的分析后半程速度会下降到 3 token/s 左右但整体没有断流也没有出现显存溢出。这套体验用来做知识库问答、写草稿、代码注释整理完全够用但如果你平时已经被云端 API 的 30 token/s 惯坏了会觉得很着急。对比 RTX 3060 12GB 的同款模型速度能提升到 6~8 token/s主要原因是更多层可以留在 GPUCPU 和 GPU 之间交换数据的频率降低了。所以我的结论很直白8GB 跑 35B 是“能用”12GB 是“好用”24GB 才是“舒服”。3.4 接入本地知识库让模型真正具备私有知识跑通模型只是第一步真正让本地大模型变得实用的是接上本地知识库。我现在的用法是再搭配 AnythingLLM把 PDF、TXT、Markdown 文档全部丢进去让 35B 模型基于我自己的资料回答问题。这个过程不复杂核心配置就几步安装 AnythingLLM在模型设置里选 Ollama 作为 LLM Provider填入本地地址http://localhost:11434聊天模型选择刚才创建的m35b向量模型选nomic-embed-text没有就先ollama pull nomic-embed-text上传几份文档然后让系统自动分块、向量化问答时选择“检索后回答”实际体验下来35B MoE 模型的优势在知识库场景里特别明显它能根据检索结果组织更完整的回答而不是只吐出一句片面的结论。同时我要提醒一句“本地部署大模型怎么解除限制词”这类问题没必要去研究绕过安全对齐那些限制是模型训练时固化的不是一句提示词能解决的。你更应该做的是在系统提示词里明确回答边界比如加一句“不确定的信息直接说不知道”这比折腾绕过有效得多也不会给后续使用埋雷。4. 本地部署常见问题与排查技巧实录4.1 GPU 占用低、CPU 爆满是怎么回事很多人第一次启动后打开任务管理器发现 GPU 占用不到 20%CPU 却直接飙到 90% 以上第一反应是“是不是没用上显卡”。这个判断并不总是对的。35B 模型用 8GB 显存跑本来就意味着很大一部分层运行在 CPU 上CPU 占用高是正常现象。你需要确认的是“有没有一部分层在 GPU 上”而不是“GPU 必须 100%”。怎么确认Ollama 有一个很实用的命令ollama ps它会列出已加载模型以及当前模型主要在 GPU 还是 CPU 上运行。如果显示100% CPU说明 GPU 完全没有参与那就要查驱动、查 CUDA 环境、查是否被其他进程占用显存。如果显示PROCESSOR GPU/CPU混合那就没问题CPU 高是应该的。还有一种情况Ollama 没有识别到 NVIDIA 显卡尤其常见于 Windows 下装了老版本驱动或者用笔记本双显卡切换的用户。解决方法是更新到最新 NVIDIA 驱动然后重启 Ollama 服务。如果还是不行用 llama.cpp 直接指定-ngl参数手动测试能跑就说明是 Ollama 的环境识别问题。4.2 明明 8GB 显存却提示 OOM我在调试时遇到过非常诡异的现象nvidia-smi显示显存只用了 4GB但 Ollama 报错说显存不足。原因是 OOM 判断不是看你剩余显存有多少而是看“能否一次性容纳你指定的模型层数 KV Cache CUDA context”。Ollama 要为 CUDA 上下文预留固定空间还要给 KV Cache 留缓冲实际可用显存往往比剩余空间小很多。解决思路有三个。第一降低num_ctx比如从 8192 降到 4096KV Cache 占用会明显下降。第二关闭其他占用显存的应用浏览器硬件加速、录屏软件、游戏平台全部关掉。第三给 Ollama 设置显存预留比例留一些缓冲给系统export OLLAMA_GPU_OVERHEAD0.1我的实测经验是8GB 显存目标占用别超过 7.2GB给系统留 0.8GB 左右的余量。不要想着把显存填满一旦遇到突发显存分配很容易直接崩掉省下的那 0.8GB 显存带来的性能提升完全可以忽略。4.3 对话越聊越慢上下文塞满了本地大模型用久了你会发现一个规律新开一个会话前几句话速度正常连续聊了 20 轮之后速度越来越慢甚至每生成一个字都要卡一下。这不是模型出了问题而是上下文长度在增长KV Cache 也在膨胀。KV Cache 是模型计算过程中缓存的历史信息长度越长缓存越大。8GB 显存场景下如果上下文从 2048 涨到 8192KV Cache 可能多占 1~2GB显存放不下Ollama 只能把缓存挪到内存甚至频繁和显存交换速度自然断崖式下降。我的做法很简单把num_ctx固定在 4096长对话改写成一问一答不要在一个会话里无限累积。如果你确实需要分析超长文本优先考虑用知识库检索切片喂给模型而不是直接把整篇文档塞进上下文。另外对话结束后可以手动执行ollama stop m35b释放资源避免模型一直驻留内存。4.4 多人访问与 200 人规模的现实成本Ollama 本身就提供 HTTP API设置OLLAMA_HOST0.0.0.0:11434之后局域网内其他设备就能访问。很多人会想那我能不能用一台电脑服务整个办公室实测下来35B MoE 模型在 8GB 显存下单人使用是 3~5 token/s并发 2 人时每人速度会掉到 1~2 token/s并发 3 人以上基本处于不可用状态。原因是每增加一个并发请求KV Cache 和模型实例占用都会成倍增加而 8GB 显存的空间已经不允许更多实例驻留。有人问“搭建一个 200 人用的本地大模型需要多少钱”这个问题不能只看显卡价格。按每个并发会话至少占用 20GB 左右物理内存显存加内存来计算200 人同时使用需要 4TB 级别的推理内存还要考虑服务稳定性、负载均衡、模型多卡拆分这不是消费级硬件能解决的场景。更现实的路径是10 人以内的小团队用一台 32GB 显存加 64GB 内存的工作站配合 Ollama 并发 4 以内可以凑合着用200 人规模要么租专业 API要么搭分布式推理集群预算至少是几十万元起步。所以我的最终建议很简单8GB 显存跑 35B最合适的定位是“个人电脑智能化”——自己一个人用搭配本地知识库让电脑真正理解你的文档和工作流。不要指望它变成一台服务器去服务全公司那不是 8GB 显存该干的事。最后分享一个我自己的调试习惯每次换一个新模型先用默认配置跑通再一项一项加上下文长度、并发数、GPU 层数一次只改一个变量。这个习惯帮我避开了绝大多数“玄学问题”。如果你也是 8GB 显存用户准备开跑 35B记住先把内存加到 32GB这是成本最低、收益最明显的准备工作。