8GB显存也能跑35B大模型？量化+MoE+显存外扩原理与实测

先泼一盆冷水8GB 显存跑 35B 大模型这听起来像是个不可能完成的任务甚至会被很多人直接打成“标题党”。35B 参数光 FP16 权重就要占 70GB 显存8GB 连零头都不够。但我确实在消费级显卡上把它跑起来了而且不是只能出几个字的那种“跑”是能正常对话、能写代码、能分析文档的完整可用状态。这篇记录我会把整个过程的原理、工具选择、参数配置、实测数据和踩坑经过全部摊开包括每一步为什么这么做、中间出了哪些问题、最后怎么解决的。先说结论这条路走通靠的不是魔法而是三件事——量化压缩、稀疏激活、显存外扩。这三板斧叠起来物理容量不够的问题就被绕过去了同时把显卡的现有算力榨到极限。这篇文章适合手里只有 8GB 显存、又想在本地玩转大模型的折腾型用户也适合被各种“本地部署”教程搞得一头雾水、想搞清楚底层逻辑的初学者。我会尽量把每个决策背后的原因讲清楚而不是丢给你一堆复制粘贴的命令。1. 为什么 8GB 能跑 35B三个绕不开的核心原理1.1 量化是怎么把模型“压缩”进显存的大模型的参数本质上是一堆浮点数。原本用 16 位浮点FP16存储35B 个参数就是 35B × 2 字节 ≈ 70GB。8GB 显存连零头都装不下。但量化做的事情很简单粗暴把这些浮点数的精度降下来。用 4 位整数INT4表示权重体积直接缩小到原来的四分之一左右35B 模型压缩完大约 20GB 上下。不过这里有个非常容易踩的误解很多人以为量化之后模型能力会断崖式下跌。实际上现代量化方法比如 GPTQ、GGUF 的 Q4_K_M 级别在大多数任务上损失非常小日常对话、代码生成、文本总结基本无感。我自己实测下来4bit 量化的 Qwen2.5-32B 和原版 FP16 在判断题、改写、代码解释类任务上几乎没有差别只有极个别需要精确推理的场景会露馅。20GB 依然塞不进 8GB所以量化只是第一步。但它解决了最关键的问题——让模型能够跑起来而不是卡死在“显存不足”的报错上。1.2 稀疏激活与 MoE关键参数只有一小撮在干活第二个支柱是 MoE混合专家结构。像 Qwen3-30B-A3B 这类 MoE 模型总参数 30B但每个 token 进来只激活其中的 3B 参数。好比一家公司有 30 个部门但每个任务只叫 3 个部门干活其他部门待命。这样算力需求就比同规模稠密模型小一个数量级推理速度完全不可同日而语。实际表现上我 8GB 显存跑 Qwen3-30B 的 token 生成速度是 50-60 token/s而跑同等参数量级的稠密模型只有 5-8 token/s。这个差距就是 MoE 的稀疏激活带来的。很多人一听“30B”就被吓住了其实智谱、Qwen 这些团队早就把 MoE 结构下放到消费级能做动的规模了。1.3 显存外扩让 CPU 内存當“备用仓库”最后一块拼图是 CPU 卸载offload。既然 8GB 放不下 20GB 的量化权重那就把塞不下的部分放到内存里显卡算一层、CPU 算一层两层协同工作。Ollama 和 llama.cpp 这类工具自带这个能力会自动把显存放不下的层丢给 CPU 推理。这里有个天然的权衡CPU 推理速度远低于 GPU。如果完全不做部分卸载8GB 连精简到极致的 35B 都放不下。所以实际策略是把能塞进显存的全塞进去剩下的才抛给内存。显存越大、能装进 GPU 的层越多速度就越快。这也是为什么我建议 8GB 用户尽量选量化等级更高、体积更小的版本而不是无脑上最高精度。注意CPU 卸载不是万能的。如果 CPU 太弱比如 4 核老古董或者内存带宽太低整体速度可能还不如一个跑在 8GB 显存上的 7B 模型。这个权衡一定要提前想清楚别把硬件瓶颈找错了方向。2. 环境准备与工具选型动手前把坑填平2.1 为什么首选 Ollama 而不是直接上 llama.cpp本地部署大模型的工具五花八门Transformers、llama.cpp、Ollama、LM Studio 各有各的拥趸。我最终选了 Ollama核心原因是它在显存管理和模型调度上做了大量自动化处理——这对于只有 8GB 显存、每个字节都要精打细算的场景来说太关键了。llama.cpp 需要手动指定 GPU 层数、并行度、上下文长度参数调不好就是各种 OOMOllama 基本可以做到开箱即用默认配置已经能自动决定哪些层放显存、哪些丢内存。但 Ollama 不是没有缺点。它的参数传递相对保守很多高级选项要通过环境变量才能启用。比如要开启 Flash Attention得手动设OLLAMA_FLASH_ATTENTION1要调整并行加载模型的数量得设OLLAMA_NUM_PARALLEL。这些配置知道的人少但不配置的话8GB 显卡跑 35B 基本会卡在默认的 CPU 推理上。2.2 Windows 11 下的环境配置全过程我在 Windows 11 上实测配置确实比 Linux 简单不少。Ollama 官方提供了 Windows 安装包装完直接就能用。需要注意几个细节显卡驱动必须更新到最新版本。老驱动对 CUDA 12.x 的支持可能不完整会导致模型加载后 GPU 利用率始终为 0。内存建议 32GB 起步。8GB 显存跑 35B大约需要 12-16GB 的内存来装卸载出去的层外加系统本身占用16GB 内存会比较紧张32GB 才够从容。Ollama 默认模型存储路径在 C 盘35B 模型动辄 20GBC 盘不够用的话要提前改环境变量OLLAMA_MODELS指到大容量分区。开启系统休眠会导致推理中断在电源设置里把“睡眠”改成“从不”是基本操作。2.3 模型选型的取舍参数质量与技术路径权衡市面上 35B 级别的模型不算少但能在 8GB 显存上真正丝滑运行的不多。我建议优先考虑Qwen3-30B-A3B其次是Qwen2.5-32B的 Q4_K_M 量化版以及采用类似 MoE 结构的其他 30B 档模型。Qwen3-30B-A3B 的优势是激活参数只有 3B推理速度极快配合 Q4_K_M 量化后模型文件只有 20GB 上下卸载到内存的部分不算多8GB 显存能稳稳压住。Qwen2.5-32B 是稠密模型虽然同样能卸到内存跑但速度瓶颈就明显多了。至于为什么不是 35B 标准模型——5B 的差距本身没什么意义关键是模型架构和量化版本是否适配你手里的显存。个人建议选模型之前先用ollama run跑一下小模型比如 7B确定 GPU 利用率正常、速度符合预期再上大模型。不然你很难分辨是模型问题还是环境问题。3. 显存、算力与推理速度的三角平衡3.1 用计算弄清楚一张 8GB 显卡到底能做什么8GB 显存的物理上限不可绕过。我们用粗粒度估算Q4 量化后大约每 1B 参数占 0.6-0.7GB35B 需要约 20GB。就算把量化等级压到 Q2也要 12GB 左右。想全部塞进显存数学上不可能。所以思路必须转变成“能塞多少塞多少塞不下的交给别的部分”。显存分配还有一个必须留的余量KV Cache。上下文越长KV Cache 占的显存越多。默认 2048 token 上下文大概要 1-2GB8GB 显存上这已经是很大比例了。我在实际测试中发现把上下文长度调到 8192 时显存占用直接从 6.2GB 飙到 7.6GB其他层全被挤到 CPU 上推理速度肉眼可见地掉下来。这也是为什么我看网上好多人说“我 8GB 跑 32B 很流畅”结果一问上下文长度是 512基本等于玩玩具。3.2 量化等级的选择Q4 与 Q8 的实战差距GGUF 量化等级从 Q2 到 Q8 都有体积、精度、速度三者在打架。实测对比Q4_K_M质量可接受体积约 20GB8GB 显存基本能跑出 50 token/sMoE或 5-7 token/s稠密。Q6_K体积约 26GB精度更高但显存压力明显加大CPU 卸载量变多速度下降 30%-50%。Q8_0体积约 33GB质量接近原版但在 8GB 显存上基本没法看加载时间极长推理速度掉到 2-3 token/s。这个结论很清楚8GB 显存玩 35B老老实实选 Q4_K_M 就好。别为了一点精度去赌 Q6 或 Q8最后多半会陷入“精度确实好一点但慢到不想用”的尴尬局面。3.3 Flash Attention 和缓存优化看似不起眼实则是救命稻草Ollama 在 Windows 11 上默认可能没有启用 Flash Attention这会导致 KV Cache 占用比激活后高出一截。在 8GB 显存上这几十 MB、几百 MB 的差别就可能决定某个层能不能留在 GPU 上。实操做法在系统环境变量里新建OLLAMA_FLASH_ATTENTION1然后重启 Ollama 服务。改完之后观察nvidia-smi的显存占用你会看到启动后显存占用反而下降、GPU 利用率明显上升的结果。这个操作相当重要经常能带来 15%-20% 的速度提升而且完全免费。另外把OLLAMA_KV_CACHE_TYPEq8_0也设上KV Cache 用 8bit 而非默认的 16bit进一步压缩显存占用。这两招组合使用2GB 上下文级别的 KV Cache 可以压缩到 1GB 左右给模型权重留出更多 GPU 空间。4. 完整实测过程从安装到流畅对话的保姆级记录4.1 安装清单与版本信息我的实测环境如下供参考显卡NVIDIA GeForce RTX 4060 8GBLaptop 版驱动版本551.86Studio 驱动操作系统Windows 11 23H2CPUIntel Core i7-13700H内存32GB DDR5 4800MHzOllama 版本0.5.x运行ollama --version查看安装过程很简单去 Ollama 官网下载 Windows 安装包一路默认即可。重点在于配置环境变量# 设置模型存储路径避免C盘爆炸 setx OLLAMA_MODELS D:\ollama_models # 开启 Flash Attention setx OLLAMA_FLASH_ATTENTION 1 # KV Cache 用8bit量化省显存 setx OLLAMA_KV_CACHE_TYPE q8_0提示setx设置的环境变量只对新启动的进程生效。一定要重启 Ollama 服务或者干脆重启电脑否则配置不会加载。4.2 拉取模型并启动 35B 实测我用到的命令和输出长这样ollama pull qwen3:30b-a3b ollama run qwen3:30b-a3b第一次 pull 耗时取决于网速——20GB 的模型哪怕是千兆带宽也要半小时以上。建议放在晚上拉顺手把网络断点续传做好。模型拉取完成、运行起来之后真正的测试才开始。我用三个维度记录实测数据加载速度首 token 延迟、生成速度token/s、显存占用情况。加载耗时从执行ollama run到模型进入待输入状态大约 3-5 秒因为模型常驻在内存部分是显存加载。首 token 延迟输入一段 50 字左右的问题约 0.8 秒出第一个字。生成速度稳定在 50-60 token/s属于“聊天无压力阅读滚动跟得上”的水平。对比 Qwen2.5-32B Q4_K_M 的表现同样长度输入生成速度掉到 6-8 token/s明显感知到“一个字一个字往外蹦”。这说明 MoE 架构在 CPU 卸载场景下优势非常明显——激活参数少CPU 负担轻。4.3 显存占用实测记录用数据说话用任务管理器或nvidia-smi -l 1实时监控显存占用记录如下Qwen3-30B-A3B上下文 4096模型阶段显存占用GBCPU 内存占用GB备注空闲无模型0.54.5系统基础占用加载后待机6.813.2显存接近满载对话中短上下文7.013.5KV Cache 占用增加长上下文8K7.715.8接近显存极限结论很清晰8GB 显存被榨到 96% 左右再往上就爆了。所以长文档总结、大代码库分析这类任务不适合把上下文狠拉长显存会先崩掉。5. 常见问题与排查技巧实录5.1 模型加载后 GPU 利用率始终是 0%这是我被问得最多的一个问题。通常原因是 Ollama 没能调用 CUDA。排查两步走第一步确认驱动支持。运行nvidia-smi看右上角 CUDA Version 是不是 12.x。如果是 11.x 或者更老直接更新驱动。第二步检查 Ollama 日志。Windows 下日志文件在%LOCALAPPDATA%\Ollama\server.log打开后搜CUDA或GPU关键词看有没有报错。常见的坑笔记本双显卡核显独显用户Ollama 默认可能走核显。在 Windows 的“图形设置”里把 Ollama 的可执行文件设为“高性能 NVIDIA 处理器”就能解决。这个问题折腾了我一下午最后发现是系统默认调度把负载丢给了核显。5.2 加载到一半就 OOM模型直接消失显存溢出是 8GB 用户的家常便饭。这里分享一个经验法则上下文长度设为 2048 或 4096而不是默认拉到 8192。KV Cache 是显存杀手对 8GB 来说每多出 1K 上下文就意味着要多付出约 200-400MB 显存。如果已经 OOM正确操作是先把上下文调小然后设置OLLAMA_NUM_PARALLEL1禁止并行推理避免多个请求同时挤显存。同时把OLLAMA_MAX_LOADED_MODELS1也设上防止之前加载过的小模型残留在显存里。5.3 回复质量很差感觉在胡言乱语这一般跟量化等级和参数设置有关而不是模型本身出了问题。Q2_K 这种激进量化在 35B 上已经明显影响语义理解能力了至少要上 Q4_K_M。另外检查一下有没有在命令行里乱加温度参数。Ollama 默认温度是 0.7但对中文创作类任务我实测下来0.5 更稳逻辑更紧凑追求发散创意可以调到 0.8。综合来说一个稳定且质量不错的启动配置长这样ollama run qwen3:30b-a3b --num-ctx 4096 --temp 0.5 --top-p 0.95.4 长对话后变慢上下文膨胀带来的连锁反应刚开始对话很快聊了几百轮之后越来越慢逐渐逼近 3-4 token/s。原因很简单上下文越长KV Cache 越大显存溢出越多卸载到 CPU 的层就越多。对 8GB 显存来说这个衰减几乎是不可避免的。最实用的解决办法是及时开新会话。需要跨会话保留记忆的可以把之前对话的关键结论手动粘到新会话开头相当于给模型喂一段“摘要”。实测这种方法在牺牲少量上下文连续性的情况下能保住推理速度不崩。5.5 为什么别人能流畅跑 70B我只能 Q4这件事值得单独说。很多人发帖说自己 8GB 显存流畅跑 70B速度还很快让人怀疑人生。打开帖子细看不是用了极端的 2bit 量化就是把上下文砍到 512 token。这种“流畅”其实是定向过拟合出来的对短问答来说确实流畅但你让他写一份 2000 字的周报他就露馅了不是撒谎就是复读。与其追求“能跑多少 B”不如关注“能在多大上下文里保持什么质量”。8GB 显存下35B 短上下文对话是甜点位。超过这个范围不如乖乖用一个 7B-8B 的小模型加外挂知识库体验反而更好。6. 8GB 本地大模型的潜能边界与扩展玩法6.1 本地大模型不只是聊天玩具很多人以为本地部署大模型就是图一个“不用联网”实际玩下来你会发现远不止于此。我在 8GB 显存环境下做了三个方向的扩展体验都相当能打本地知识库问答把文档切块后灌进向量库比如 Chroma配合本地大模型做 RAG。35B MoE 的推理质量配合检索能力足以应付常见的问题解答和文档分析场景。代码解释与补全把一段复杂代码丢给它让它逐行解释、指出潜在问题。8GB 跑 Qwen3-30B 在代码理解上的表现比 7B 模型高出一个档次。离线写作助手把产品文案、周报、邮件模板这类重复性写作丢给本地模型。不用联网、数据不出本地对某些敏感场景而言本身就是刚需。扩展玩法中需要注意的RAG 场景下要控制检索文档的分块大小超出上下文长度时不是让模型硬撑而是先做摘要再继续。这也回到了前面说的“上下文是 8GB 显存最稀缺的资源”。6.2 下一步硬件升级的方向判断如果你觉得 8GB 实在不够用、想升级我建议按这个优先级思考先升级内存到 32GB 以上。因为卸载到 CPU 的层需要内存支撑内存不够模型根本加载不了。再把显卡换到 16GB 显存。16GB 配合 Q4 量化能全程 GPU 推理跑 32B 稠密模型体验质变。最后再考虑 CPU 升级。如果你用的是 MoE 模型CPU 瓶颈影响很大但稠密模型下GPU 还是主导。这条路线背后逻辑很简单先解决“能不能跑”再解决“跑得快不快”最后解决“跑得好不好”。8GB 是入门线16GB 才是甜点这一点希望你能明确预期。6.3 数据安全与隐私价值再强调一次本地部署最大的隐形福利是数据不出设备。我用本地模型处理过几份需要保密的测试数据整个过程完全离线心里踏实。相比之下在线 API 虽然方便但数据经过第三方服务器敏感场景基本不适合。当然也不是说本地就一定绝对安全。模型文件本身、日志文件都要注意管理不要随意共享。另外Ollama 默认在 11434 端口提供 API如果所在网络环境比较复杂建议改成仅本机访问。7. 写给后来者三个核心实操建议7.1 不要被参数规模带偏“35B”数字很唬人但真正决定体验的是激活参数量、量化等级和设备基础这三者的联合关系。看到 35B 先别急着下载先确认自己的显存能放什么等级的量化、CPU 能兜住多少卸载量。你用 8GB 跑 35B 不是为了跟人比参数是为了在有限的硬件里拿到最好的综合体验。7.2 养成环境变量管理的习惯Ollama 的许多关键调优都藏在环境变量里。建议在自己常用位置建一个配置文件Windows 下可以直接在系统设置里改把OLLAMA_FLASH_ATTENTION、OLLAMA_KV_CACHE_TYPE、OLLAMA_MODELS一次性设置好。以后不管拉什么模型都能自动享受这些优化不用每次重来。我自己因为早期没意识到这个问题反复测试花了不少时间提醒你好好避坑。7.3 测试标准要统一对比不同模型、不同量化等级时务必用同一套测试数据集同一批问题、同样的上下文长度、同样的生成参数。不然你测出来的“A 比 B 快”很可能只是上下文长度不同或者温度不一致带来的假象。我每次测速都用一样的 5 个中文问题然后取平均 token/s这样数据跨模型才有参考意义。8. 一个补充8GB 跑 35B 到底值不值聊了这么多最后把这个最实际的问题摆到台面。8GB 显存跑 35B 到底值不值我的看法是作为实验和探索绝对值。它把一个“不可能”变成“可能”让你真正理解显存、量化、推理架构这些概念是怎么在压力下互相制衡的。但如果你只是想要一个日常随手可用的 AI 助手8GB 跑 7B-8B 的模型会从容得多没必要为了追求大参数而牺牲速度和稳定性。这里分享一个我自己的典型使用配置日常轻量对话用 7B 模型响应迅速、显存无压力需要深度分析、长文本理解时切到 Qwen3-30B用慢一点的代价换高质量回答。两个模型在 Ollama 里可以共存ollama run命令切换就行非常方便。这种“小而快”与“大而准”的组合才是 8GB 显存环境下真正体面且稳定的工作流。最后再分享一个小技巧如果你跑 35B 模型时发现生成速度比预期慢很多先别急着换硬件检查一下模型是否真的运行在 GPU 上。在对话界面输入/set info查看模型运行参数确认gpu字段显示为真。很多时候速度慢只是因为某些配置没生效模型全部在 CPU 上硬扛。把这篇文章里提到的几个环境变量设好、测试一次你会发现差距比想象大得多。