1. 为什么我偏要在8GB显卡上折腾35B大模型先交代一下背景。我手上这台机器是两年前配的显卡是一张8GB显存的消费级卡具体型号不重要反正就是那种当年买得起、现在跑3A大作已经有点喘的级别。内存32GBCPU是六核十二线程的中端货。这套配置放在今天的大模型圈子里属于“入门都算不上”的水平——网上随便一搜动辄就是24GB显存起步、双卡4090才敢说自己跑得动大模型。但我这个人有个毛病就是不服气。尤其是看到“35B参数”这个数字的时候第一反应不是“我跑不动”而是“凭什么跑不动”。这里要先说清楚一个概念不然很多新手会被参数规模吓到。35B指的是模型有350亿个参数如果按照传统的稠密模型来算光是权重加载到显存里FP16精度下大概需要70GB显存INT8量化也要35GB左右INT4量化差不多18GB到20GB。8GB显存连门都摸不到。但问题在于现在很多大模型采用的是MoE架构也就是混合专家架构。这个架构的核心思路是模型虽然总共有350亿参数但每次推理的时候并不是所有参数都参与计算而是只激活其中一部分专家。这就好比一家公司有35个部门但每次处理一个具体项目只需要调用其中3到5个部门就够了其他部门的人该喝茶喝茶、该摸鱼摸鱼不占用工位。所以8GB显存跑35B模型理论上是有可能的前提是这个模型是MoE架构而且量化做得足够激进再加上合理的CPU卸载策略。我这次实测的目标就是把这套“理论上可行”的方案跑成“实际上能用”的结果。这篇文章适合谁看如果你手上只有一张8GB或者12GB的消费级显卡想在自己电脑上跑一个能力还过得去的大模型又不想花大价钱升级硬件那这篇实录就是写给你的。我会把整个过程中的选型逻辑、参数配置、踩过的坑、最终效果全部摊开来讲。不藏私也不吹牛跑出来是什么样就是什么样。2. 方案选型为什么是MoE加量化加CPU卸载这套组合拳2.1 稠密模型和MoE模型的显存账本对比在决定动手之前我先把账算了一遍。这个习惯很重要很多人上来就下载模型结果发现加载都加载不了白白浪费时间和硬盘空间。假设我们要跑一个35B参数的模型分别看看稠密架构和MoE架构在显存占用上的区别。对于稠密模型推理时的显存占用大致包括三部分模型权重、KV Cache、以及推理框架本身的开销。模型权重是大头计算公式很简单参数量乘以每个参数的字节数。FP16是2字节INT8是1字节INT4是0.5字节。35B参数在INT4量化下权重大约需要17.5GB显存。这还没算KV Cache和框架开销实际占用只会更高。8GB显存连权重都放不下直接出局。MoE模型就不一样了。以我这次用的模型为例虽然总参数量是35B但每次推理只激活大约3B到5B的参数。这意味着如果推理框架能够做到只把激活的专家加载到显存里那么显存占用可以大幅降低。但这里有个关键问题MoE模型的专家权重是分散存储的推理框架需要能够动态地从内存中加载需要的专家到显存这就涉及到CPU卸载技术。我打个比方。稠密模型就像一本完整的字典你要查任何一个字都得把整本字典带在身上。MoE模型就像一套分册的百科全书你要查某个领域的知识只需要从书架上抽出对应的那一册。CPU卸载就是那个书架内存就是书架的容量显存就是你手边的小桌子只放当前要用的那几册。2.2 量化方案的选择Q4_K_M为什么是甜点量化是大模型本地部署绕不开的话题。简单说量化就是把模型权重从高精度浮点数转换成低精度整数牺牲一点点精度换取大幅度的显存节省和速度提升。常见的量化级别有Q2、Q3、Q4、Q5、Q6、Q8数字越大精度越高占用也越大。Q4_K_M是社区里公认的甜点级别K代表使用了K-quant量化方法M代表中等粒度。这个级别的量化模型能力损失通常在可接受范围内但显存占用只有FP16的四分之一左右。我实测对比过Q3_K_S和Q4_K_M。Q3确实更省显存但模型在逻辑推理和代码生成上的表现明显下降有时候会出现答非所问的情况。Q4_K_M则稳定得多虽然和FP16原版比还有差距但日常问答、文本总结、简单代码辅助这些场景完全够用。Q5_K_M我也试过显存占用比Q4高了大概20%但能力提升并不明显性价比不高。所以最终我锁定Q4_K_M量化。这个选择不是拍脑袋决定的是在Q3和Q5之间反复横跳之后得出的结论。如果你显存更紧张可以退到Q3_K_M但要做好模型偶尔“犯糊涂”的心理准备。2.3 推理框架的取舍Ollama还是llama.cpp推理框架这块市面上选择不少但真正适合低显存场景的主要就是Ollama和llama.cpp这两个。我两个都装了也都跑了一遍说说实际感受。Ollama的优势是开箱即用安装简单命令行操作友好模型管理方便。你只需要一条命令就能拉取模型并运行对新手极其友好。但它的默认配置偏向于有足够显存的场景在8GB显卡上需要手动调整参数而且日志输出不够详细排查问题的时候有点抓瞎。llama.cpp的优势是控制粒度细几乎每一个和显存、内存、线程相关的参数都可以手动调整。你可以精确控制多少层卸载到GPU、多少层留在CPU、KV Cache用什么精度、批处理大小设多少。对于我这种喜欢折腾的人来说llama.cpp的可玩性更高。缺点是编译和配置门槛稍高参数多到让人眼花缭乱新手容易劝退。我最终的选择是日常使用Ollama深度调优和排查问题用llama.cpp。两个框架共享同一套GGUF格式的模型文件切换成本很低。这个组合让我既能享受Ollama的便利又能在遇到性能瓶颈时用llama.cpp深挖。3. 实操过程从零把35B模型塞进8GB显存3.1 环境准备和依赖安装先说基础环境。我的系统是Linux具体发行版不重要内核版本5.15以上。Windows用户也能跑但CPU卸载的性能会打折扣后面会细说。第一步是安装显卡驱动和计算框架。这部分我不展开讲因为不同显卡的安装方式差异很大照着官方文档走就行。重点是要确认计算框架能正确识别到你的显卡。安装完成后跑一个简单的检测命令看看显卡是否可用、显存容量是否正确识别。第二步是安装Ollama。官方提供了一键安装脚本执行后会自动配置好服务。安装完成后用ollama --version确认版本。我用的版本是0.1.32不同版本对MoE模型的支持程度不一样建议用较新的版本。第三步是准备模型文件。我这次用的是社区里一个35B的MoE模型GGUF格式Q4_K_M量化。模型文件大概20GB左右下载需要一些时间。下载完成后放到Ollama的模型目录下或者直接用ollama create命令从Modelfile创建。这里有个细节要注意MoE模型的GGUF文件通常包含多个专家权重文件体积比同等参数量的稠密模型要大。下载的时候确保硬盘有足够空间我预留了50GB实际用下来刚好够。3.2 关键参数配置层数卸载和KV Cache这是整个实操过程中最核心的部分。8GB显存能跑35B模型全靠参数调得好。第一个关键参数是num_gpu_layers也就是卸载到GPU的层数。这个参数决定了模型有多少层放在显存里跑剩下的层留在内存里由CPU处理。设得太高显存溢出直接报错设得太低CPU负担过重推理速度慢如蜗牛。我的调试方法是从较小的值开始逐步增加观察显存占用和推理速度的变化。具体操作是先用nvidia-smi或者等效命令监控显存然后每次增加5层跑一个简单的推理测试记录显存峰值和生成速度。实测下来对于这个35B MoE模型在8GB显存上num_gpu_layers设在12到15之间比较合适。设到15的时候显存占用大约7.2GB留了800MB左右的余量给系统和其他进程。设到18的时候显存直接爆了Ollama报错退出。第二个关键参数是KV Cache的精度。KV Cache是推理过程中缓存键值对的内存区域默认是FP16精度。对于长上下文场景KV Cache会占用大量显存。我把它降到了Q8_0精度显存占用减少了大约一半对生成质量的影响微乎其微。第三个参数是批处理大小。这个参数影响的是并行处理的请求数量。对于单用户场景设小一点没关系我设的是512。如果你打算多人共用可以适当调大但要注意显存余量。配置写好后用ollama run启动模型。第一次加载会比较慢因为需要把模型权重从硬盘读到内存再把部分层加载到显存。加载完成后就可以开始对话了。3.3 实测数据和性能表现跑起来之后我做了几组测试记录了一些关键数据。第一组是纯对话场景。问了一个需要多步推理的问题模型生成速度大约在每秒4到6个token之间。这个速度是什么概念呢正常人阅读速度大概是每秒5到8个汉字所以模型生成的速度基本跟得上你的阅读速度不会让你等得心焦。但如果你习惯了一目十行那确实会觉得有点慢。第二组是长文本总结。输入了一篇大约3000字的文章让模型总结要点。因为上下文变长KV Cache占用增加生成速度降到了每秒3到4个token。但模型对文章的理解和总结质量还不错关键信息基本都抓到了。第三组是代码辅助。让模型写一个简单的Python函数处理字符串格式化。模型给出的代码可以直接运行逻辑正确只是变量命名风格有点啰嗦。考虑到这是一个量化后的35B MoE模型在8GB显卡上跑出来的结果我觉得已经超出预期了。显存占用方面稳定运行时显存占用在7GB到7.5GB之间波动没有出现溢出。内存占用大约12GB主要是存放未卸载到GPU的模型层和KV Cache。CPU占用率在60%到80%之间说明CPU确实在承担相当一部分计算任务。4. 踩坑实录那些让我抓狂的瞬间和解决方案4.1 模型加载失败显存溢出的三种典型情况第一种情况是num_gpu_layers设得过高。我一开始贪心直接设了20层结果模型加载到一半就报显存不足。解决方案很简单降低层数从12层开始试。第二种情况是KV Cache精度没调。默认FP16精度下即使层数设得不高长上下文场景也会导致显存溢出。把KV Cache降到Q8_0后问题解决。第三种情况比较隐蔽系统桌面环境占用了显存。Linux下某些桌面环境会占用几百MB显存Windows下浏览器和桌面合成器也会占用。解决方案是在跑模型之前关掉不必要的图形界面程序或者切换到纯命令行模式。我在Linux下直接切到了tty显存一下子多出来500MB刚好够把层数从12提到15。4.2 推理速度过慢CPU瓶颈的排查和优化有一段时间模型生成速度突然从每秒5个token掉到了每秒1个token慢到无法忍受。排查过程如下先用top命令看CPU占用发现有一个核心跑满了其他核心在围观。这说明推理框架没有充分利用多核CPU。检查参数发现线程数设的是默认值可能只用了单核。把线程数改成物理核心数减一速度恢复到了每秒4个token左右。然后检查内存频率。我的内存是DDR4 2666MHz带宽有限。MoE模型在CPU上推理时需要频繁从内存读取专家权重内存带宽成了瓶颈。如果内存频率更高比如DDR4 3200MHz或者DDR5速度还能再提升一些。这个属于硬件限制只能接受。最后检查了硬盘。模型文件放在机械硬盘上加载速度慢而且推理过程中如果发生内存交换机械硬盘的随机读写性能会成为灾难。把模型移到固态硬盘后加载时间从三分钟缩短到了四十秒推理过程中的卡顿也明显减少。4.3 输出质量下降量化损失和上下文管理的平衡量化到Q4_K_M之后模型在某些任务上的表现确实不如FP16原版。我遇到的主要问题有两个一是数学计算容易出错。简单的加减乘除没问题但涉及到多步计算或者小数运算模型偶尔会给出错误答案。解决方案是在提示词里明确要求模型“一步一步计算不要跳步”这样能显著提高准确率。二是长上下文后段遗忘。当对话轮次多了之后模型对早期对话内容的记忆会模糊。这是KV Cache精度降低和上下文窗口限制共同导致的。我的应对策略是定期总结对话要点把关键信息放在新一轮对话的开头相当于手动帮模型“划重点”。还有一个经验MoE模型对提示词的格式比较敏感。同样的意思用不同的表述方式问模型给出的答案质量可能差别很大。我一般会在提示词里加上“请详细回答”或者“请用简洁的语言回答”这样的指令引导模型输出符合预期的内容。5. 这套方案到底能干什么实际应用场景盘点5.1 个人知识库问答的搭建思路本地大模型最实用的场景之一就是搭配本地知识库做问答。我把自己积累的技术文档、笔记、常用代码片段整理成文本文件然后用一个简单的检索脚本根据用户问题从知识库里找出相关段落拼接到提示词里发给模型。这套方案的好处是数据完全本地不用担心隐私问题。而且因为模型就在本机跑响应速度虽然比不上在线服务但胜在稳定不会因为网络波动或者服务商限流而中断。具体实现上我用了一个轻量级的向量检索库把文档切片、向量化、建索引。查询的时候先检索出最相关的几个片段然后连同问题一起发给模型。模型基于这些片段生成回答相当于开卷考试。实测下来对于技术类问题的回答准确率比纯模型问答高不少。5.2 代码辅助和文本处理的日常使用写代码的时候我经常让模型帮我做这几件事解释一段看不懂的代码、生成简单的工具函数、把一种语言的代码翻译成另一种语言、写正则表达式。这些任务对模型能力要求不算太高35B MoE模型在Q4量化下完全能胜任。文本处理方面我主要用模型做会议纪要整理、邮件草稿撰写、长文摘要。这些任务的特点是输入长、输出短对生成速度要求不高但对理解能力有一定要求。实测下来模型在中文文本处理上的表现比英文稍弱但日常使用足够。有一点要提醒不要指望本地模型能替代在线服务。在复杂推理、创意写作、多轮深度对话这些场景上本地小模型和云端大模型差距还是很明显的。本地部署的价值在于隐私、可控、免费而不是性能碾压。5.3 多人共享的可行性分析有人问过这套配置能不能给一个团队用。我的答案是能但体验会打折扣。8GB显存跑35B MoE模型单用户对话时生成速度每秒4到6个token。如果同时来三四个请求推理框架需要排队处理每个人的等待时间会成倍增加。而且并发请求会导致KV Cache占用飙升显存很容易溢出。如果确实需要多人共享我的建议是限制并发数为2把批处理大小调大同时接受生成速度下降的现实。或者换一个更小的模型比如7B或者13B的稠密模型牺牲一些能力换取更好的并发性能。至于“搭建一个200人用的本地大模型需要多少钱”这个问题说实话8GB显卡的方案肯定不够用。200人规模至少需要专业级显卡或者多卡并行成本是另一个量级的事情。消费级显卡本地部署定位就是个人使用或者小团队尝鲜别对它有不切实际的期望。6. 几个容易被忽略的细节和我的个人建议6.1 散热和功耗长时间推理的硬件压力跑大模型推理时显卡和CPU都是满载状态发热量比玩游戏还大。我实测连续跑两个小时推理显卡温度稳定在75度左右CPU温度到了80度。如果你的散热条件一般建议限制一下推理时长或者调低风扇曲线让噪音和温度平衡。功耗方面整机功耗比待机时高了大概150瓦。电费倒是小事但如果你用的是小功率电源要注意别让电源长期满载运行对寿命有影响。6.2 模型文件管理硬盘空间和版本控制GGUF模型文件动辄十几GB下载几个不同量化的版本硬盘很快就满了。我的做法是只保留当前在用的版本其他版本用完就删。如果确实需要保留多个版本做对比建议单独挂一块硬盘专门放模型文件。版本控制方面建议在文件名里标注清楚模型名称、参数量、量化级别和下载日期。比如qwen-35b-moe-Q4_K_M-20240615.gguf。这样过一段时间回头看能快速知道每个文件是什么不用一个个打开确认。6.3 安全使用本地部署的边界和注意事项本地部署大模型数据不出本机这是最大的优势。但也要注意几点第一模型生成的内容不一定准确尤其是量化后的模型。重要决策不要依赖模型输出把它当成一个辅助工具就好。第二模型文件要从可信来源下载。来路不明的模型文件可能被篡改存在安全风险。第三如果多人共用一台机器跑模型要注意用户之间的数据隔离。Ollama默认没有多用户隔离机制不同用户的对话历史可能会混在一起。可以通过为每个用户分配不同的模型实例或者使用容器化方案来解决。第四定期更新推理框架和显卡驱动。新版本通常会修复bug、提升性能、增加对新模型的支持。但更新前记得备份配置有时候新版本会改变默认参数导致原来的配置失效。最后说一个我自己的体会8GB显存跑35B MoE模型这件事本身的意义不在于性能有多强而在于它证明了消费级硬件也有探索大模型的可能性。你可能不会用它来生产但通过这个过程你能真正理解MoE架构、量化技术、CPU卸载这些概念是怎么在实际中运作的。这种理解比看十篇科普文章都管用。