8GB显存跑35B大模型：量化拆分与推理调优实战指南

开头那段话我憋了挺久。8GB显存跑35B模型乍一听就是个标题党35B权重就算压到4bit也得20GB左右一张8GB显卡连零头都不够。但我实际跑起来之后发现这里的关键不是“显卡能不能装下”而是“推理时能不能让显卡和内存协作把模型拆开算”。我用的配置很普通一张RTX 3070 8GB、64GB内存系统是Windows 11加WSL2模型选的是Qwen2.5-32B-Instruct的GGUF Q4_K_M量化版。折腾了几个星期模型跑起来了速度也确实能用只是完全不是“秒回”的体验。这篇文章把我踩过的坑、调过的参数、实测过的速度全记下来给想低成本玩本地大模型的人一个参考。先说结论能跑能干活但你必须接受1秒出1~2个token的速度以及一系列围绕显存和内存的取舍。1. 为什么8GB显存跑35B这事值得折腾1.1 显存账本35B到底要吃多少内存先把账算清楚。一个35B参数的模型如果以FP16精度存储每个参数占2字节权重文件大约70GB。INT8量化能压到35GB左右4bit量化比如GGUF的Q4_K_M能压到20GB上下。看起来跟8GB显存是天壤之别但绝大多数人忽略了一个事实本地推理不是非得把整个模型塞进显存不可。显卡负责的只是部分计算模型可以按层拆开一部分层放在GPU上另一部分层放在CPU内存里算完GPU上的层再把中间结果传给CPU继续算剩下的层。这就是为什么“8GB显存跑35B”在技术上可行。我用生活里的例子解释一下。显存是桌面内存是储物间模型是一套需要按顺序翻阅的百科全书。桌面太小放不下整套书但你不需要同时打开所有书只需要把当前要读的那几本放桌上读完一批再从储物间换下一批。推理过程是串行的模型一层一层算所以同一时刻只需要驻留“正在算的这几层”而不是全部70GB。8GB显存只要能装下一部分层剩下的交给内存整台电脑就还能把活干完。当然代价是速度。显卡算完一部分后要把中间结果通过PCIe总线传给CPU这部分数据交换非常频繁再加上CPU本身算大模型就慢最终生成的token速度会低到让人怀疑人生。后面我会给实测数据这里先不卖惨。1.2 三条路线量化、按层拆分、控制上下文我实测过程中试过三条路线各有各的适用场景Ollama默认加载最简单装好之后一条ollama run命令就能跑。它会自动判断显存余量把能放的层放到GPU上剩下的留在CPU。适合只想快速验证“能不能跑”的人。llama.cpp手动指定GPU层数用-ngl参数控制到底放多少层到GPU精度最高适合需要反复微调显存占用的人。我最后长期用的是这条路。Ollama自定义Modelfile在Ollama里通过num_gpu参数实现类似-ngl的控制兼顾了Ollama的便利和llama.cpp的灵活性。三条路线的底层原理都一样量化缩小模型体积按层拆分降低峰值显存控制上下文长度来压住KV Cache。后面每一章都会围绕这三个点展开。1.3 适合谁、不适合谁说点实在话这套方案适合下面几类人有隐私需求不想把对话内容传到云端的人需要批量处理长文本比如翻译文档、做摘要、跑本地知识库对响应速度不敏感的人单纯想研究大模型部署原理把它当实验平台的人想在Dify这类工具里接一个免费、私有、不限量的本地模型做企业内部知识库原型的人。不适合的人是那些追求ChatGPT式交互体验的你问一句话等一两分钟才看到第一个字开始蹦再等几分钟才能收到完整回答普通用户大概率受不了。还有如果你需要高并发比如让几十个人同时用消费级单卡加CPU的方案会直接卡死。真到那个规模要么用云端API要么上多卡服务器这不是本文的讨论范围。2. 实操前的准备硬件、软件与模型选型2.1 我的实测环境先交代一下跑这套东西的环境方便你对照部件配置备注CPUAMD Ryzen 7 5700X8核16线程内存带宽很重要尽量别用太老的CPU显卡NVIDIA RTX 3070 8GB8GB显存是这次折腾的核心限制内存64GB DDR4-3200双通道建议至少32GB目标模型Q4_K_M约20GB内存太小跑不动硬盘NVMe SSD 1TB模型加载要从硬盘读SSD能减少加载时间系统Windows 11 22H2 WSL2 Ubuntu 22.04llama.cpp跑在WSL2里Ollama用Windows原生版CUDA12.1确保显卡驱动能识别CUDA这里最容易被忽略的是内存。很多人看到“8GB显存跑35B”就以为8GB是全部需求实际上40GB内存才是这套方案的真正门槛。20GB模型权重、Windows系统占用、浏览器、再加上推理过程中的中间激活值32GB内存都很紧张。我把内存从16GB加到64GB之后Ollama才不再随机崩溃这是我这套方案里最值的一笔投资。2.2 模型选型别下safetensors要下GGUF35B这个称呼在开源社区没那么严格我实测用的是Qwen2.5-32B-Instruct的GGUF量化版。为什么选GGUF而不是HuggingFace默认的safetensors因为Ollama和llama.cpp都原生支持GGUF格式整个文件就是为分块加载设计的支持把部分层留在磁盘、部分加载进内存、部分发到GPU。safetensors是训练和微调用的格式推理时加载起来非常笨重不适合这种低显存场景。各量化等级的体积和体验差异我的体感如下量化等级体积约实际体验Q2_K13GB左右速度快一些但中文效果明显下降经常语序混乱Q3_K16GB左右能跑但明显感觉模型“有点傻”Q4_K_M20GB左右我长期使用的版本中文能力、逻辑能力都可接受Q5_K_M24GB左右质量更好但8GB显存下内存压力太大加载都费劲Q6_K/Q826GB以上不建议这个场景尝试你会被卡到怀疑人生Q4_K_M是我综合体积、速度和效果后的甜点区。量化带来的损失是真实存在的但Qwen2.5-32B这种大模型本身冗余很高压缩到4bit后日常写作、翻译、代码补全依然够用。优先级排序先保证模型能跑起来再考虑质量。2.3 安装Ollama和llama.cpp如果你只是想快速跑起来先装Ollama。去官网下载Windows版本装好之后打开终端拉模型ollama pull qwen2.5:32b ollama run qwen2.5:32b第一次会下载模型文件之后每次加载会有一段时间的等待。Ollama启动时会自动分配GPU层数但默认策略在8GB显存下不一定最优所以后面我会教你创建自定义Modelfile。如果你想像我一样精细控制需要在WSL2里编译llama.cpp。步骤很简单git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDAON cmake --build build --config Release -j编译好之后用它加载GGUF模型./build/bin/llama-cli -m /mnt/d/models/qwen2.5-32b-q4_k_m.gguf -ngl 20 -c 8192 --temp 0.7-ngl是number of GPU layers意思是把多少层放在GPU上。这个是整个调参过程中最重要的参数后面我会单独讲怎么确定它的值。3. 跑起来的三条路线与实测参数3.1 第一次用Ollama跑先看默认策略翻不翻车我第一次跑的时候直接ollama run qwen2.5:32b等模型加载完输入“你好介绍一下你自己”屏幕卡了大约四十秒才开始吐字。当时心里还是挺激动的毕竟8GB显存真的把32B模型拉起来了。但接着就发现问题我用nvidia-smi看显存占用发现GPU显存几乎被占满而任务管理器的内存也在疯狂上涨。ollama ps显示模型加载在GPU和CPU各占了一部分但具体分了哪些层看不到。如果只是简单聊几句默认策略能跑。但一旦对话变长、上下文累积显存里的KV Cache会一路增长很快就能把剩余显存挤爆。我的经验是用默认策略跑10轮左右的对话后报错概率急剧上升有时候是CUDA out of memory有时候是内存爆掉导致Windows卡死。所以想要稳定跑必须自己做显存规划。解决办法是创建自定义ModelfileFROM qwen2.5:32b PARAMETER num_gpu 20 PARAMETER num_ctx 8192 PARAMETER temperature 0.7保存为Modelfile然后执行ollama create qwen32b-8g -f ./Modelfile ollama run qwen32b-8g这样创建的新模型ID叫qwen32b-8g它会严格按照20层GPU来加载。这个数字怎么看出来的往下看。3.2 llama.cpp如何确定GPU层数以及实测速度表用llama.cpp跑的时候启动日志会打印每一层放在哪个设备上。关键信息类似llm_load_tensors: offloading 20 repeating layers to GPU llm_load_tensors: offloaded 20/65 layers to GPUQwen2.5-32B总层数大约64层加embedding等。offloaded 20/65 layers表示有20层在GPU、45层在CPU。怎么确定20这个数方法很简单先设置一个较小的-ngl值比如10跑起来后看nvidia-smi里这个进程的显存占用记下来再停掉把-ngl加到15再看显存增量。增量大约就是每多放一层的显存开销。我的环境里每层大约0.3GB算上CUDA基础占用和KV Cache20层对应6.5GB左右给GPU留了1.5GB余量比较稳。我记录了一组实测速度生成任务都设置同样的-c 8192配置显存占用实际速度tokens/s说明-ngl 0约0.5GB0.42纯CPU推理慢到怀疑人生-ngl 10约3.5GB0.87GPU开始帮忙但帮助有限-ngl 20约6.8GB1.32我长期使用的配置-ngl 25约7.6GB1.15显存接近极限性能反而下降-ngl 28报错-CUDA out of memory直接崩溃从表格能看出两个关键点增加GPU层数并不总是提速因为当显存快满时KV Cache和中间激活值会被挤到内存里反而增加交换开销。另外推理速度不是由GPU层单独决定的CPU负责的那几十层才是最大瓶颈。整条流水线的速度就取决于最慢的一环跟生产线一个道理你没设备扩展那个慢环节光给前面的环节加人就白搭。这里有个细节为什么-ngl 25时显存占用只比-ngl 20多了0.8GB速度却下降了因为上下文长度的KV Cache原本由GPU做但显存紧张后部分KV被放到了内存每一轮生成都要在GPU和CPU之间搬运KV数据。搬运比计算还慢所以提速变减速。3.3 上下文长度与KV Cache别把显存掏空很多人跑大模型喜欢把上下文设置得很大比如32K。但在8GB显存的约束下这等于自杀。KV Cache的大小跟上下文长度线性相关Qwen2.5-32B在8K上下文下大约需要2~3GB空间这还是在开启flash attention之后的数字。Ollama里可以通过Modelfile设置PARAMETER flash_attn on PARAMETER num_ctx 8192llama.cpp里对应./build/bin/llama-cli -m /mnt/d/models/qwen2.5-32b-q4_k_m.gguf -ngl 20 -c 8192 --flash-attn --temp 0.7--flash-attn能显著减少KV Cache的显存占用效果非常明显。实测开启后同样的8K上下文显存占用能省下800MB到1GB这笔账必须算。如果你需要处理长文档我的建议是不要把长文档一次性塞进去。先让模型做分段摘要再把摘要拼起来这样能把上下文控制在4K以内既保证速度又避免OOM。后面我会详细说这个工作流。3.4 不同任务的实测体验光看速度数字不够直观我挑三个真实任务说说体验。第一个是代码生成。让它写一个Python脚本大概200行模型输出大约900个token1.32 tokens/s的速度意味着大约11分钟。这个速度说实话有点折磨人但写出来的代码基本能用简单的算法和API调用都正确。我觉得适合“你正在写代码突然需要一个不常用函数的实现”这种场景丢给模型慢慢生成自己先去干别的。第二个是翻译。把一篇5000字的英文技术文档翻译成中文这个场景最推荐。翻译任务对交互速度要求低你只需要等它把整段翻译完。我实测的速度虽然慢但翻译质量相当不错术语处理比很多在线翻译工具都专业。这算是本地大模型最适合的落地方案之一。第三个是长文写作。让它写一篇3000字的行业分析大约4500个token算下来要跑接近一个小时。这就不适合实时等待了我是写进脚本里让它后台跑跑完再去看。如果你只是想快速生成一篇短文还是用云端API更实际。但如果你在意数据隐私或者就是不想为API付费那等一小时也不算完全不能接受。4. 让它干活服务化接入与日常使用4.1 把模型变成API服务给Dify和知识库用跑通Chat界面只是第一步。真正让它有价值的做法是把Ollama变成后台API服务这样Dify、WebUI、甚至自己的Python脚本都能调它。Ollama装好后默认会监听11434端口。你可以启动服务ollama serve然后验证接口是否可用curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen32b-8g, messages: [{role: user, content: 你好}], stream: false }注意返回里的model字段必须跟ollama list里的模型ID完全一致我自己就曾因为在Dify里填了qwen2.5:32b而不是自定义的qwen32b-8g导致连接一直报错。4.2 Dify接入本地大模型的完整配置Dify接入Ollama的步骤不复杂但有几个坑必须提前知道。在Dify后台进入“设置 → 模型供应商”选择Ollama填写模型名称和Base URL。这里的Base URL有个经典的坑Dify如果是用Docker启动的它访问不了宿主机的localhost。你在Dify容器里填http://localhost:11434它指向的是容器自己而不是你装Ollama的Windows宿主机。正确写法要区分场景Dify以Docker方式运行在Windows填http://host.docker.internal:11434Dify以Docker方式运行在Linux填http://172.17.0.1:11434Dify直接跑在裸机填http://localhost:11434填完后点测试如果能通就把模型ID填成qwen32b-8g。之后你在Dify的应用编排里LLM节点就能选到这个本地模型。配合Dify的知识库你就拥有了一套完全私有化的RAG问答系统企业里做内部文档问答、客服助手数据都留在本地这一点对很多公司来说比模型精度还重要。不过要注意Dify默认的请求超时可能比较短。本地模型生成一个回答需要几十秒到几分钟如果超时设置太小Dify会直接报“请求超时”错误。我建议把请求超时调到120秒以上或者尽量让模型用短回答模式。在Dify的LLM节点里可以设置temperature低一点比如0.2并让System Prompt强调“回答尽量简洁”这样能显著减少等待时间。4.3 让本地35B干活的几个调参心得跑了大半个月我总结出几条非常实用的心得提问越短出结果越快。本地大模型的prefill阶段读入你的prompt也很慢你把背景信息写一大堆光是“阅读理解”就要卡半分钟。尽量用简洁的prompt。一次只问一件事。如果一个问题里带了三四个子问题模型输出会很长速度会拖到无法接受。拆成多个请求分段获取结果体感反而好。设定输出长度。Ollama的Modelfile里可以加PARAMETER num_predict 512llama.cpp里对应-n 512限制最大输出长度防止模型失控一直写下去。温度别调太高。Q4量化后模型本身有一定随机性温度太高容易跑偏和重复。一般对话用0.7任务型场景用0.2。对话别太长。每多一轮对话KV Cache就变大速度也会下降。遇到长任务我会直接开新会话只把必要的背景塞进去而不是在一个会话里连续聊几十轮。这些心得的核心都是同一个原则本地跑大模型你要把token视为稀缺资源尽量用最少的输入输出把活干完。云端API可能不在乎你多传几千个token本地8GB显卡很在乎。5. 常见问题与排查实录5.1 CUDA out of memory显存爆了的自救清单这是我最开始遇到最多的错误。典型场景是加载模型后没跑几句直接报CUDA out of memory。排查步骤按顺序来先看ollama ps确认当前加载的模型数量。Ollama会保留最近用过的模型在显存里如果之前加载了另一个模型会占掉不少显存。看nvidia-smi确认有没有其他程序占用显存。浏览器开几十个标签页、3D渲染软件、甚至某些桌面特效都可能吃显存。降低num_gpu从20降到15给KV Cache留出空间。真到万不得已把量化等级从Q4_K_M降到Q3_K。这会牺牲质量但至少能跑。我遇到过最隐蔽的坑是Windows的桌面窗口管理器会占用几百MB显存WSL2里跑的CUDA进程有时会把这部分也算进去。所以给GPU留1.5GB余量不是保守而是必须。5.2 内存和虚拟内存为什么建议至少64GB我一开始用32GB内存跑系统经常变得特别卡鼠标都移不动。原因是20GB模型权重占掉大部分内存Windows、浏览器、后台进程再占10GB内存马上见底。系统就开始疯狂用虚拟内存把数据往硬盘上倒腾这比CPU慢速推理还致命。排查方法很简单任务管理器里看“内存使用率”如果长期在95%以上就说明内存不够。解决办法两选一加物理内存或者把虚拟内存页面文件扩大到32GB以上。我后来加了内存条世界清净了。还要提醒一个细节如果开了虚拟内存Windows会把不常用的模型层交换到页面文件里你可能发现第一次加载模型特别慢但生成时偶尔也会卡住好几秒。页面文件能防止崩溃但不能防止慢。所以预算允许的话物理内存尽量给到64GB。5.3 速度慢得离谱到底有没有用到GPU很多人跑完第一反应是“这也太慢了”然后怀疑模型根本没用到显卡。其实80%的情况下你的GPU确实在干活只是CPU层拖了后腿。但为了排查可以用这几个方法确认ollama ps会输出PROCESSOR列显示模型是100% CPU还是包含了GPU。nvidia-smi看GPU利用率。如果能跑到40%~60%说明GPU在计算如果一直是0%说明没分配GPU层。看llama.cpp的启动日志里面有offloaded 20/65 layers to GPU之类的信息。如果确认GPU层数为0通常是两个原因一是Ollama版本太老没识别到CUDA二是WSL2里没安装正确的CUDA驱动。重新装驱动、升级Ollama就能解决。比较反直觉的一点是即使GPU利用率达到100%整体速度也可能只有1 tokens/s。因为CPU层是瓶颈GPU算完一批数据后要等CPU算完才能继续。这就像一条流水线一个环节慢其他环节再快也没用。想提速的唯一办法是让GPU多包揽一些层但显存用完后就到头了。这时候如果CPU内存带宽更高、CPU核心更强速度会有一点点提升但不会有质变。5.4 常见问题速查表现象原因处理方式输入prompt后很久才出第一个字模型在做prefill加上CPU计算慢缩短prompt换更强CPU开启flash attention生成到一半报CUDA out of memoryKV Cache随对话增长占满显存清空会话降低num_ctx增大num_ctx的余量模型加载后再次打开还要重新加载keep_alive时间太短Ollama设置OLLAMA_KEEP_ALIVE10m或更长Dify测试连接失败容器访问宿主机地址不对按Dify运行方式正确填写Host地址API请求总是超时本地模型响应太慢调大客户端超时到120秒以上并限制输出长度对话内容重复、混乱量化后模型质量下降调高temperature换Q5_K_M清上下文重开5.5 关于“企业搭建本地大模型”的运维成本网上经常看到“花二三十万买硬件搭本地大模型”的讨论。我的看法是预算高的方案运维量同样不小多卡服务器的驱动、CUDA版本、容器编排、监控告警每一项都够运维忙一阵。但我这套消费级方案几乎是零运维开机后启动Ollama模型文件躺在硬盘里平时就是占点内存和硬盘空间不用管它。真要说运维也就是定期看一眼模型版本、清理一下没用的模型文件。这也是消费级方案的一个隐藏优势够简单坏了也没那么心疼。6. 实操留一句自己的体会折腾这段时间我最大的体会是跑不跑得动跟显存有关跑得舒不舒服跟内存和预期有关。8GB显存跑35B技术上早就可行难的是接受1秒1个多token的现实。可一旦把它定位成后台任务、离线批处理、私有知识库的底座这种速度反而没那么重要。如果你是刚入门我建议先不用看那么多理论直接把Ollama装好下个Q4_K_M的GGUF模型创建一份带num_gpu 20的Modelfile跑两句体会一下。然后你就会明白为什么我会说“显存不够不是死路但内存一定要管够”。