显存只有8GB却在本地把35B级别的模型跑起来了——这句话放两年前谁听了都摇头。35B模型光是FP16权重的体积就超过70GB8GB显存连零头都装不下。但今天情况真的不一样了量化把模型从70GB压缩到20GB上下再配合CPU/GPU混合推理消费级显卡确实能把这台大发动机点着火只是转速没那么高而已。这篇文章是我从零开始用一张8GB显存的消费级显卡在本地部署35B档大模型的完整记录。包括先算清楚的显存账单、怎么选量化版本、用Ollama还是llama.cpp、实际起跑时offload了几层、测出来的真实速度与生成质量以及折腾过程中踩过的各种坑。适合手里正好有8GB显卡、想跑本地大模型但预算有限的开发者、AI爱好者和打算搭个人知识库的朋友。看完你会明白8GB跑35B不是玄学是有明确边界条件的工程方案。1. 先算清楚这笔账8GB显存为什么能跑35B1.1 35B模型的显存账单从FP16说到4bit量化先做一道算术题。35B指的是模型参数总量约350亿个也就是35 Billion。按最常见的FP16半精度浮点数存储每个参数占2字节FP1635B × 2 70GBINT835B × 1 35GBINT435B × 0.5 17.5GB也就是说哪怕压到4bit量化理论体积也要17.5GB比8GB显存多一倍。这也解释了为什么很多人第一反应是不可能。如果谁跟你说8GB显存能完整加载35B模型那要么是吹牛要么就是没搞懂量化。量化是什么你可以把它当成照片压缩。原始照片是RGBA格式一张几十MB人眼能看出所有色彩过渡压缩成JPEG后体积小了十倍肉眼看差别不大但在专业修图放大到100%时能看出瑕疵。模型量化也是这个逻辑把原本用16bit或32bit浮点数表达的权重近似成4bit整数。模型要的从来就不是权重绝对精确而是概率分布大致正确所以量化后的模型往往还能保持八成以上的能力。实测中35B模型的GGUF量化文件大小差不多是这样量化格式理论大小35B实际文件体积主观能力保留FP1670GB不适合日常部署100%Q8_035GB约35GB99%Q5_K_M21GB约22GB92%左右Q4_K_M17.5GB约20GB85%-90%Q3_K_M13GB约15GB75%左右Q2_K8.7GB约12GB容易发飘注意Q4_K_M实际20GB比理论值大一点因为GGUF文件里除了权重还包含token embedding、norm参数和少量元数据这些部分往往没有量化得那么狠。1.2 CPU/GPU混合推理8GB显存的逃生通道既然20GB塞不进8GB显存那就塞一部分。这是整件事能成立的第二个关键机制混合推理。Transformer模型的结构是堆叠的layers层与层之间有严格的先后顺序。llama.cpp这一系推理引擎包括Ollama底层也是它支持把这个模型从中间切开前N层放在GPU显存里计算剩下的层放系统内存由CPU负责计算。这个前N层就是大家常说的offload层数即-ngl参数。推理时数据流要依次穿过每一层。放GPU的层用CUDA核来算放CPU的层用CPU的多核来算中间通过PCIe总线把每层输出的中间结果激活值搬运过去。所以性能瓶颈通常有两个一是CPU本身的浮点计算能力二是PCIe和内存带宽。我做这道题之前心里预期就是慢跑但可用。事实也差不多8GB显存、32GB内存的情况下35B Q4_K_M跑起来生成速度大约在每秒5到8个token读起来和正常打字差不多远达不到秒回但也不是完全没法等。一句话总结第一个章节8GB跑35B的原理很简单——先量化压体积再混合推理把放不下的部分摊到CPU上最后用显存跑一部分、内存跑一部分。下面每一步选择都是在给这个分蛋糕方案找最优切法。2. 模型选型与量化等级别被35B的名字带偏2.1 35B档位的开源模型怎么挑标题写35B实际市面上这个档位通常叫32B或34B。常见选择有几个Qwen3-32B系列中文能力强上下文长社区生态活跃量化文件好找GLM-4-32B系列中文理解和生成都强很适合中文办公场景DeepSeek-R1-Distill-Qwen-32B推理和数学能力突出但因为是蒸馏版且带思维链生成速度天生偏慢我这次实测的主力选的是GLM-4-32B和Qwen3-32B各跑了一轮最终长期留在机器里的是GLM-4-32B的Q4_K_M版。原因很主观我平时中文写作和总结类任务多GLM系在这块的语感更稳。如果你主要做代码生成或数学推理Qwen3-32B或DeepSeek蒸馏版更合适如果只是聊天和写文案国产这几个闭源也够好完全不必上本地模型。选型还要看授权。Qwen系列用Apache 2.0商用基本没问题GLM-4也开放了权重但要注意具体模型卡上的授权说明。如果你是给公司搭内部工具务必先确认许可证别模型跑起来之后才发现商用有限制。2.2 GGUF量化文件命名解析K、M、S、L代表什么决定模型能不能在8GB卡上跑量化级别比模型本身参数更重要。你在Hugging Face或ModelScope下载时会看到一串名字Qwen3-32B-Q4_K_M.gguf。这里的Q4_K_M到底什么意思Q4平均每个权重用4bit存储精度档位K表示用的是llama.cpp的K-quants量化方法这是社区在大量实验后打磨出来的混合精度策略不是简单的每4bit一刀切而是根据权重重要程度动态分配bit数M表示这个量化文件在同类中的混合程度是中等。还有Ssmall、Llarge、XL等变体。M的意思是量化过程中保留了一部分权重用略高的精度兼顾体积与效果所以Q4_K_M是社区公认的性价比之选一句话理解Q4_K_M 4bit为主 K方法 中等混合度。这个档位通常被认为是追求体积和质量的平衡点。往下Q3_K_M体积更小、跑得更快一点但智商肉眼可见地下降往上Q5_K_M质量更好但体积大个两成8GB显存能放的层数就少了得不偿失。2.3 8GB显存到底能装下哪个档位这个问题的标准答案是能装下的不是整个模型而是显存预算内的那部分层数。我按20GB的Q4_K_M来算。GLM-4-32B实际有64层左右平均每层权重约0.3GB。8GB显存实际可用一般在7.5GB左右如果留出1GB给KV cache缓存历史对话的注意力值和运行开销那能分给权重的就是6.5GB大概能放22层左右。剩下42层扔给CPU跑。换句话说8GB显存跑35B Q4_K_M的标准配置约是-ngl 22到-ngl 25之间视KV cache大小浮动。如果换成Q3_K_M文件体积15GB单层0.24GB那同样的6.5GB预算能放27层左右GPU承担的比例更高速度也更快。代价就是生成质量打折。我的建议是第一次跑别贪直接用Q4_K_M -ngl 22 上下文2048起步先把流程跑通。跑通之后再去纠结要不要往Q3或更高层数上调整。3. 推理引擎对比Ollama的省心与llama.cpp的精确3.1 Ollama五分钟把35B拉起来的强力选手选推理引擎是部署路上第二重要的决定。最省心的选择是Ollama普通用户我强烈建议从这里开始。Ollama的优点是零折腾安装完两条命令就把模型拉下来跑起来ollama pull glm4:32b-q4_K_M ollama run glm4:32b它会自动检测显卡、自动分配offload层数、自动管理KV cache还会起一个本地服务默认监听11434端口对外提供OpenAI兼容的API。这对接Dify、FastGPT、ChatGPT-Next-Web这些开源前端特别方便后面会细说。如果你想微调参数可以写一个Modelfile定义温度、上下文长度、GPU层数等FROM glm4:32b-q4_K_M PARAMETER temperature 0.7 PARAMETER num_ctx 4096 PARAMETER num_gpu 22 PARAMETER num_thread 8然后构建并运行ollama create glm4-32b-local -f Modelfile ollama run glm4-32b-localOllama的默认参数对大多数人来说是能跑且基本合理但如果你想榨干每一MB显存它会显得不太灵活。这时候就该llama.cpp上场了。3.2 llama.cpp每一层显存都要抠的精细派Ollama底层其实就是llama.cpp但它把很多参数藏起来了。直接用llama.cpp你可以精确控制每一层的摆放位置。尤其像我这种显存只有8GB、离OOM就差500MB的情况精细控制是刚需。llama.cpp在Windows下的用法不复杂。从GitHub Releases下载带CUDA的预编译包解压后打开命令行llama-cli -m glm4-32b-Q4_K_M.gguf -ngl 22 --ctx 4096 -t 8 -p 你好请介绍一下你自己几个关键参数-ngl 22把前22层放到GPU其余跑CPU。这是8GB显存的核心旋钮--ctx 4096上下文长度直接决定KV cache占多少显存-t 8CPU线程数按物理核心减2设设太满会卡顿-p 问题启动时直接输入提示词llama.cpp还支持--flash-attn开启flash attention能显著降低长上下文下的显存占用--no-mmap关掉内存映射加载慢但稳定性好。这些参数组合起来几乎可以做到把8GB显存每一MB都派上用场。两个引擎怎么选我的结论很直接第一次玩、或者你只是想尽快用上模型用Ollama如果你想在8GB显存上追求极致速度、想看看到底能offload多少层、或者要做性能基准测试直接用llama.cpp。我这次实测最终用的是llama.cpp因为我要精确控制变量记录数据。但日常聊天我反而用Ollama因为它跑起来更省事上下文管理也更友好。4. 部署实录一台8GB消费级显卡的35B完整起跑过程4.1 硬件环境与软件版本我实测机器的具体配置CPUAMD Ryzen 7 5700X8核16线程内存32GB DDR4-3200显卡NVIDIA GeForce RTX 4060 8GB系统Windows 11 23H2 WSL2 Ubuntu软件CUDA 12.4驱动 551.xxllama.cpp bxxxx 版本补充一句8GB显存的N卡里GTX 1650、RTX 2060、RTX 3050、RTX 4060这类都能跑但效果差距很大。核心影响因素其实是CPU和内存内存不够会直接OOMCPU太弱会让生成速度掉到每秒两三个token那种体验基本没法用。建议内存至少32GBCPU至少8核否则35B的体验会很挣扎。4.2 关键参数调整-ngl、ctx、threads怎么配第一次启动前我并没有直接抄网上配置而是按显存预算逻辑推了一遍8GB显存实际可用7.5GB左右给KV cache预留1GB权重预算约6.5GBQ4_K_M单层权重约0.3GB6.5GB ÷ 0.3 ≈ 22层于是初值定为-ngl 22 --ctx 4096 -t 8。启动后发现显存占用大约7.1GB还有一点余量。试了加到-ngl 24稳定运行再往-ngl 25加的时候直接CUDA OOM。这个往上试探直到爆的过程非常值得做每一台机器的可用显存、CPU内存容量都不一样直接套数值不如自己探一遍。CPU线程-t 8是经验值。5700X是8核16线程Windows的WSL2环境里跨NUMA调度有损耗-t 8比-t 16反而快因为避免了超线程抢资源。你可以对比-t 6/8/10跑同一个问题测秒数选最快那个。4.3 第一次启动验证它真的跑起来了用llama.cpp启动时的日志很有信息量几行关键输出会告诉你一切llm_load_model: loading model llm_load_tensors: offloading 22 layers to GPU llm_load_tensors: CUDA buffer size 6853.17 MiB llm_load_tensors: offloaded 22/64 layers to GPU看到offloaded 22/64 layers这行就可以确认GPU分担了约三分之一的计算量。然后你会看到模型加载花了二三十秒因为还要把剩下的层加载到系统内存。接下来直接丢一个简单的中文指令过去llama-cli -m glm4-32b-Q4_K_M.gguf -ngl 22 --ctx 4096 -t 8 -p 用三句话解释什么是Transformer第一次跑最磨人的是首字延迟问题丢进去之后CPU要先用几十秒做prompt处理prefill然后才开始流式吐字。别以为是卡死了其实它在工作。等第一个字出来后后续输出就比较有节奏了每秒稳定吐出几个token。5. 实测数据速度、显存、生成质量全记录5.1 速度实测token/s的真实水平我把同一组测试问题跑了好几轮分别调整-ngl得到的生成速度数据大致如下配置生成速度首字延迟处理提示词备注-ngl 0全CPU约2.3 token/s约35s慢到怀疑人生-ngl 12约4.8 token/s约18s能接受但着急-ngl 22约7.1 token/s约12s日常使用推荐-ngl 24约7.6 token/s约10s极限状态偶尔OOMOllama默认约6.5 token/s约15s自动分配稍保守别小看-ngl 12到-ngl 22之间两倍多的差距。同样是回答300个token的问题前者要等一分钟多后者四十秒上下体感完全不同。而且prompt处理速度差距更大因为prefill阶段CPU与GPU的并行效率天差地别。所以8GB显存下offload层数就是速度的第一决定因素。5.2 显存占用实测窗口余量很小用nvidia-smi实时盯显存跑35B Q4_K_M时的占用分布大致是模型权重22层约6.8GBKV cache4096上下文约0.6GBCUDA context等杂项约0.3GB总计约7.7GB余量不足300MB这个余量维持不了太长时间。跑长对话时KV cache会缓慢增长某个时刻就可能顶到8GB极限直接报错。我建议把Windows的桌面GPU加速关掉一些或换一个低内存占用的桌面环境能多挤出200MB余量。还有个观察如果开着浏览器看视频再跑模型大概率OOM。8GB显存本来就是硬凑的运行期间别给显卡加戏。5.3 生成质量实测量化混合推理的代价有多大速度是硬指标质量是体验核心。我用三组对比任务测了量化损失中文文案改写、逻辑推理题、生成简短Python函数。选的是GLM-4-32B的Q4_K_M版对比参考基线和Q3_K_M。结果是预料之中的梯度分布中文文案改写Q4_K_M和原始版几乎分不出来流畅度和用词自然度都在线逻辑推理Q4_K_M偶有小错但大方向对Q3_K_M开始出现步骤跳变结论有时站不住代码生成Q4_K_M能生成可运行的小函数Q3_K_M偶尔会漏引号、少参数Q2_K我试跑了一次就直接放弃了。不是速度问题是效果问题——回答常常结构正常但内容发飘数字对不上逻辑混乱这种看起来在说人话实际上在胡扯的状态比明确回答不知道更危险。所以关于8GB跑35B到底行不行我的结论是行但最好是Q4_K_M别指望无损。它适合做草稿、做总结、搭私人知识库不适合用来出财务算数报告或者写生产代码。6. 踩坑实录与优化技巧从能跑到跑得舒服6.1 跑不起来先查这三个地方很多朋友卡在模型明明下载了一跑就崩。我按自己排查的顺序整理成一条链路大概率能救回来。第一个排查点是显存报错。日志里出现CUDA out of memory或者failed to allocate说明-ngl给太高了或者后台有其他程序占显存。先跑一下nvidia-smi看剩余显存然后-ngl减5重新来。第二个排查点是系统内存不足。35B Q4_K_M至少需要20GB系统内存来放权重层再加系统自身占用和浏览器32GB内存其实已经有点紧。报错通常是bad_alloc或直接进程被杀。这种情况要么加内存条要么删掉--no-mmap让文件走内存映射要么换体积更小的Q3_K_M。第三个排查点是CPU线程数设置过大导致整体卡顿。WSL2、虚拟机、老主板这些环境里-t 16反而比-t 8慢。把线程数调到物理核心数的一半到三分之二往往有惊喜。我见过最诡异的是一次第一次能跑、第二次必崩后来发现是Windows的显存压缩和桌面窗口管理器在抢显存重启桌面进程就好了。这种环境的坑只能见招拆招。6.2 输出慢到怀疑人生优化三板斧如果模型能跑但速度只有每秒两三个token按优先级从高到低做三件事。第一把offload层数提到极限。8GB显存下每多放一层GPU速度就快一截。方法是-ngl从20开始每次加2跑到OOM再减2找到这台机器的最优解。注意调整后要重测一次显存占用别让KV cache没地方住。第二砍上下文长度。同样的-ngl 22--ctx 2048比--ctx 8192这代模型的KV cache会显著影响显存和整体吞吐。如果你日常是问一句答一句2048完全够用。要长文总结再临时开长上下文别一开始就设8192。第三换带--flash-attn的新版本。llama.cpp对Flash Attention的支持每代都有提升8GB显存场景下能省出几百MB KV cache间接等于多放一层GPU权重。升级后跑一下相同问题速度快10%到20%是正常的。如果这三板斧都试完还是慢那就接受现实35B不是用来实时聊天的它是用来后台慢慢生成文档的。想要秒回请出门左转用8B或14B模型。6.3 从命令行到产品接入Dify从命令行玩具变成本地服务跑通35B之后你大概率不会只想在终端里敲字。把Ollama或llama.cpp的server模式跑起来本地模型就变成了一个标准化API服务可以接入Dify这类平台搭知识库问答、工作流自动化。用Ollama的时候最简单ollama serve默认监听0.0.0.0:11434完事。在Dify的设置-模型供应商-Ollama里填Base URLhttp://localhost:11434模型名glm4:32b-q4_K_MAPI Key随便填Ollama本地不校验接入之后你就可以做个人知识库了。把一批文档灌进Dify的知识库用本地35B做检索增强生成。实测下来35B的总结能力比14B明显更不容易丢细节长文档的忠实度好不少。但有个重要的心理预期并发不要指望。8GB显存 混合推理的35B同时能处理的任务最多一两个再多就直接排队。生产环境想扛并发老老实实上多卡或云端API本地8GB的定位是个人助手级服务。跑到这一步这个项目的完整链条就闭合了模型选型、量化下载、引擎配置、性能调优到服务接入全部落地。最后分享一个我这几天摸出来的小技巧用Ollama的Modelfile把num_gpu固定在最稳妥的层数同时把num_ctx设为2048日常使用速度能稳定在每秒7个token以上需要长文分析时再用llama.cpp单独开一个长上下文的会话。这种双引擎分场景的用法是我在8GB显存限制下找到的最舒服姿势。35B跑在消费级显卡上确实不算快但每次它在你电脑里吐出整段完整内容的时候这种我的硬件也能做到的满足感还是值得体验一次的。