8GB 显存跑 35B 级别大模型这句话隔三差五就会在本地模型群里出现。第一次听到我也觉得不靠谱毕竟 35B 模型光原始权重就接近 70GB一张消费级 8GB 显卡连零头都装不下。但真把环境搭起来之后我发现这事情并非天方夜谭——靠着 GGUF 量化加 CPUGPU 混合推理确实能让模型跑起来。这篇实测记录就是我基于 RTX 4060 8GB 把 Qwen2.5-32B-Instruct参数规模 32B 上下属于 35B 这一档在本地完整拉起、调参、压测的完整过程。文章会讲清楚量化怎么选、显存和内存怎么分工、关键参数怎么调、实测速度到底是多少以及这套配置适合干什么、不适合干什么。如果你手头只有一张 8GB 的消费级显卡又想本地跑大模型这篇东西应该能帮你省下不少试错时间。1. 8GB显存跑35B为什么不是天方夜谭1.1 显存装不下就分层装混合推理的基本盘要理解8GB 跑 35B这件事先得明白一个现实我们跑的不是那个 70GB 的原始模型而是量化后的 GGUF。以 Qwen2.5-32B-Instruct 为例量化为 Q2_K 后大约 11~12GB这个体积依然超过 8GB 显存所以还要再拆一手。模型在推理时是按层进行的Transformer 结构是一层接一层地算前一层的输出是后一层的输入。既然按层推进那就可以把前 N 层放进 GPU剩下的层放在内存里由 CPU 计算。llama.cpp 里这个N就是num_gpuOllama 里同样的参数也叫num_gpu。这样做出来的效果是 GPU 算完前 N 层把中间结果通过 PCIe 总线传给 CPUCPU 用内存里的权重接续算后面的层。每生成一个 token 就要完成一次GPU 算几层、CPU 算几层的接力所以总线带宽和 CPU 算力会直接决定最终速度。我习惯用仓库中转来类比显存是市区里的临时仓库内存是远郊大库房每次取一批货在仓库加工再送去远郊继续加工加工完一个零件就得这么来回一次。PCIe 总线和中转站CPU的能力决定了整个流水线的节拍仓库本身反而没那么重要了。以这个 12GB 的 Q2_K 模型为例假设模型有 64 层我让 GPU 承接前 22 层那显存里只需要放 22/64 的权重约 4GB剩下约 3~4GB 留给 KV cache 和其他中间缓存恰好能把 8GB 用完而不爆。剩下的 42 层权重常驻内存由 CPU 负责计算。这是整套方案能成立的底盘逻辑。1.2 量化选型Q2_K、Q3_K_S 与 IQ3_XS 怎么选量化等级是绕不开的一道选择题。GGUF 格式下常见选择有 Q2_K、Q3_K_S、Q3_K_M、IQ3_XS、Q4_K_M 等。对 35B 这一档Q4_K_M 体积在 20GB 左右8GB 卡别想直接装Q3_K_S 和 IQ3_XS 在 13~14GBQ2_K 在 12GB 左右。体积越小每个比特携带的信息越少越容易在长逻辑链里丢细节。量化格式近似体积能否在8GB显存下混合推理质量预期我的推荐度Q2_K约11.8GB可以明显降智仅跑通验证用Q3_K_S约14.5GB可以一般勉强可用IQ3_XS约13.2GB可以较稳推荐Q4_K_M约20GB无法高效运行好8GB下不建议注意表格里的可以不是指全部放入显存而是指能在 8GB 显存下通过部分分层 offload 的方式运行。如果你有 24GB 显卡直接上 Q4_K_M 会更省心。选择量化还要考虑任务类型代码和逻辑推理对量化损失很敏感闲聊、文案生成则宽容很多。我在实测中能明显感觉到 Q2_K 回答笨一些IQ3_XS 稳定不少所以如果不是纯验证环境我更推荐 IQ3_XS。2. 部署实操Ollama 和 llama.cpp 的两条路2.1 先把硬件底子摸清楚尤其是内存显卡其实是最不用担心的部分4060、3060、4060 Ti 这些 8GB 卡都能跑。真正决定能不能顺畅跑的是内存、CPU 和硬盘。先说内存模型权重里至少 8~10GB 常驻内存KV cache 和加载时的瞬时开销还要再吃几个 GB所以 16GB 内存基本是底线中的底线实测会触发大量 swap速度直接掉到 0.5 token/s 以下。想要正常使用32GB 起步有条件直接上 64GBDDR5 双通道最佳。CPU 方面因为模型超过一半的层在 CPU 侧计算所以它的压力甚至比显卡还大。i5/i7 级别的桌面处理器可以接受笔记本低功耗 U 会非常吃力。硬盘最好是 NVMe因为启动时要一次性把 12GB 左右模型文件读到内存SATA 固态和机械硬盘会让加载时间翻几倍。还有一个容易被忽略的点内存必须双通道。我单独做过一次对照单通道 DDR5 下速度只有双通道的 60% 左右原因就是 CPU 计算每层权重都要从内存连续读数据单通道带宽直接减半。这个坑后面展开说。2.2 Ollama 五步跑通 35B 档模型Ollama 是目前最省事的入口适合第一次尝试的人。步骤我一步步讲。第一步安装 OllamaWindows、macOS、Linux 都有安装包装完命令行直接可用。ollama pull qwen2.5:32b-instruct-q2_K第二步拉取量化模型。这里提醒一句先确认你的 Ollama 版本对应的模型仓库里有没有这个 tag太老的版本可能没有 32B 的量化名可以用ollama show查看本地已有的模型。第三步写一个 Modelfile。为什么非要写因为默认参数下 Ollama 会尝试把尽可能多的层塞进 GPU这在 8GB 卡上很容易 OOM必须手动限制层数。FROM qwen2.5:32b-instruct-q2_K PARAMETER num_gpu 22 PARAMETER num_ctx 4096 PARAMETER temperature 0.7第四步创建并运行ollama create qwen32b-local -f Modelfile ollama run qwen32b-local第五步根据显存表现回过来调num_gpu。如果你看到显存占用接近 7.8GB 以上就降到 20如果还有余量可以加到 24。8GB 卡上 22是我比较推荐的起点。运行期间可以用ollama ps看实际显存占用别只看任务管理器的粗略数字。2.3 llama.cpp 硬核调参方案喜欢完全掌控的话直接用 llama.cpp 的llama-cli。在 release 页面下载预编译包或者自己从源码编译。拿到 .gguf 文件后推理命令大致是这样的llama-cli -m qwen2.5-32b-instruct-q2_K.gguf -ngl 22 -c 4096 -t 8 --temp 0.7这里的-ngl就是刚才反复提到的 GPU 层数-t是 CPU 线程数-c是上下文长度--temp是采样温度。相比 Ollamallama.cpp 的命令行参数透明得多很适合写脚本做批量测试。比如我想对比不同量化模型的表现就写一个循环脚本逐个换-m参数跑相同的 prompt记录耗时和输出非常方便。llama.cpp 还支持一些高级选项比如--no-mmap、--mlock但在个人消费级场景下这些对速度影响不大不需要过度纠结。如果你只是自己玩玩Ollama 足够如果你要做实验、跑 benchmarkllama.cpp 更顺手。3. 实测实录默认配置到逐项调优3.1 默认配置首跑速度惨不忍睹记录一下首跑情况。机器配置RTX 4060 8GB、i7-12700K、DDR5 64GB 双通道、NVMe。使用 Ollama 默认配置直接运行 Q2_K 模型。命令敲下去之后模型加载大约花了一分钟这个时间主要是把 11.8GB 权重从 NVMe 读到内存再把其中一部分传到显存。第一次请求我让它写一段 200 字的活动开场白。从输入回车到开始输出大概等了 11 秒这属于 prompt 处理阶段。prefill 的时候 CPU 和 GPU 都在满载工作速度还能有 12 token/s 左右。真正让人崩溃的是生成阶段大约 1.3 token/s每分钟只能蹦出 80 个 token。一段 200 字的回答我等了将近三分钟。过程中打开任务管理器看显存占用 7.8GB贴着上限跑CPU 占用 60% 上下内存占用 21GB。这个结果显然不能作为日常配置。问题出在两处一是默认层数分配太激进看起来多用 GPU实际留给 KV cache 的余量太小系统频繁处于 OOM 边缘二是 CPU 线程没有专门设置Windows 上的默认调度并不理想。于是我开始逐项调参。3.2 核心参数逐项调优层数、上下文、线程第一刀先动num_gpu。我把层数从默认值往下拉分别测了 20、22、24、28 四档20 层显存占用约 5.6GBdecode 速度 2.3 token/s。22 层显存占用约 6.2GBdecode 速度 2.4 token/s。24 层显存占用约 6.9GBdecode 速度 2.6 token/s。28 层显存占用 7.9GB长上下文时偶尔崩溃decode 速度 2.7 token/s。结论是 22~24 层是甜点区。20 层最稳24 层略快但显存余量已经很少。如果后面还要挂 RAG 或者其他程序占显存我会直接回落 20 层。别为了那 0.2 token/s 去赌稳定性实测下来 OOM 崩溃一次的成本远高于那点速度提升。第二刀是num_ctx。4096 和 2048 对比显存差 0.8GB 左右升到 8192显存占用直接超过 7GB。上下文越长KV cache 越大这是线性增长的成本。对单轮问答和短文档总结4096 够用长会话不建议在 8GB 卡上开大上下文因为 KV cache 会挤占模型层数的显存空间反而逼着你降低层数。第三刀是线程数。llama.cpp 的-t对应 Ollama 里的num_threads。我这颗 i7-12700K 是 8 个大核加 4 个小核共 12 核 20 线程实测 8 线程下 2.4 token/s16 线程反而掉到 2.2说明线程数不是越多越好。线程太多会引入调度开销。可以设置为物理核心数的一半到三分之二再以自己的机器实测为准。笔记本用户记得插电运行关闭节能模式后再测。3.3 三档量化横向对比实测在层数固定在 22、上下文固定在 4096 的前提下我对比了 Q2_K、Q3_K_S、IQ3_XS 三种量化。测试任务选了三个一段代码 bug 修复、一篇 500 字新闻摘要、一个小学数学应用题评分只分能看和胡扯两档。量化格式近似体积decode速度显存占用代码修复中文摘要应用题Q2_K11.8GB2.5 token/s5.9GB偶尔能对漏细节经常错Q3_K_S14.5GB2.3 token/s6.7GB一半一半勉强能看时对时错IQ3_XS13.2GB2.4 token/s6.3GB基本能对稳定大体正确结论很清晰速度层面三者没有本质差异最多差 0.2 token/s质量层面 IQ3_XS 明显领先 Q2_K。如果你不是只为了让模型跑起来这个仪式感正式使用请选 IQ3_XS。Q2_K 更适合验证环境和跑通流程。4. 真实场景评判能干哪些活不能碰哪些活4.1 适合的任务轻量代码、文档摘要、知识库问答2.4 token/s 意味着每分钟约 150 个 token输出一段 800 字内容大约需要 10 分钟。这种速度下聊天式交互完全是煎熬但提交任务过一会儿来看结果的模式完全可行。我实际用得比较舒服的场景有三个。第一是代码小任务比如给我一段报错信息让它解释原因并给出修复代码一百多行的单文件场景下表现不错。第二是文档摘要把一份会议纪要丢进去让它分条输出待办事项35B 这一档的语义理解明显比 7B 强。第三是配合本地知识库做 RAG 问答先用 bge-m3 这类 Embedding 模型把文档向量化检索再把检索片段送给 35B 做最终回答整体效果比我之前用 7B 或 14B 底座时好一个档次尤其在涉及多步骤推理的答案里。4.2 不建议的任务多轮对话、长文本、实时交互反过来有些场景建议直接放弃。首先是多轮聊天上下文一长KV cache 膨胀速度越聊越慢最后甚至卡死。其次是长文档全文分析如果你直接丢几万字的文档进去prefill 阶段要等几分钟生成阶段又要几十分钟根本扛不住。正确做法是先切块检索只送和问题相关的片段给模型这和 RAG 是同一个思路。实时交互也基本没戏。语音识别、流式输出、边等边思考这类需求2.4 token/s 的吐出速度只会让人暴躁。这类场景更适合调用云端 API或者本地换一张更大显存的卡。我经常对来问的人说一句话8GB 跑 35B不是让你去替代日常聊天助手而是让你在隐私保护的前提下拥有一台能干活但慢半拍的离线工作站。4.3 本地部署的成本账与适用边界再算一笔成本账。如果你只是偶尔用云 API 按量付费显然更省钱省心。但如果你每天都有一堆私有数据要处理比如企业内部文档、客服记录、个人笔记token 费用积累起来很可观数据隐私和合规也是问题。这时候本地部署的价值就不只是跑通模型了。另外如果公司或团队想要的是一个200 人可用的本地大模型服务我个人建议千万别靠单机 8GB 方案硬撑。并发场景需要至少一张 24GB 或 48GB 的专业卡配合 vLLM、SGLang 这类服务框架还要考虑权限管理、负载均衡和显存分配。8GB 跑 35B 更接近一个人在家做的技术试验它验证的是算法与工程层面的可行性而不是生产级方案。5. 避坑实录我踩过的坑和最终参数5.1 启动 OOM 与显存占用失控最常见的坑就是启动直接报显存不足。原因基本是num_gpu设置过高或者 Ollama 自动检测时把 KV cache 的空间算漏了。排查顺序先看日志里实际加载了多少层到 GPU再把num_gpu降到 20同时把num_ctx降到 4096。如果仍然 OOM检查系统里是不是有别的程序占用了显存比如浏览器硬解视频、游戏挂机程序甚至桌面窗口管理器在某些情况下都会吃掉一部分显存。不要在 OOM 时直接继续拉高层数那样只会让系统进入不稳定状态。我遇到过最极端的情况是显存爆掉后花屏只能重启电脑。对 8GB 卡来说把显存用到 95% 以上本身就是危险信号留出 10% 的余量才是长期稳定运行的前提。5.2 生成速度异常慢内存通道是关键我踩过最典型的一个坑机器只有一根 DDR5 内存跑起来只有 1.1 token/s 左右。插上第二根组成双通道后速度立刻回到 2.3 token/s 以上。单双通道的差距巨大因为这套方案本质上是 CPU 在内存里搬权重数据内存带宽直接决定 CPU 侧的计算吞吐。其次检查 CPU 频率和功耗墙。笔记本在电池模式下性能会大幅缩水一定要插电跑台式机注意散热CPU 长期 90 度以上会降频速度反而更差。可以用任务管理器确认有没有其他程序占满 CPU尤其是 Windows 的索引服务、杀毒软件的实时扫描都会在模型加载和推理过程中抢资源。如果你发现速度忽快忽慢先排除这些后台因素再考虑调参。5.3 多轮对话卡死与上下文管理多轮对话中速度会越来越慢最后甚至直接卡死原因是上下文不断增长KV cache 膨胀后在显存里挤占权重空间最终触发 OOM 或内存交换。解决办法有三个限制num_ctx不要开太大4096 是 8GB 卡的合理档位定期重启会话或者用摘要压缩功能把历史对话折叠如果频繁出现干脆换一个小一点的模型。我在本地跑过一段长工作时连续使用超过半小时后速度会从 2.4 掉到 1.8 token/s最后不得不重启。后来我把任务拆成多次短会话每次只输入当前相关的内容速度和稳定性都好了很多。这也是 8GB 显存方案不得不接受的工程妥协——小步快跑比硬扛长上下文靠谱。5.4 常见问题速查表症状可能原因处理方式启动直接 OOMnum_gpu 过高 / ctx 过大 / 显存被其他程序占用降到 20 层、ctx4096关闭其他 GPU 程序生成速度低于 1.5 token/s内存单通道 / CPU 降频 / 线程数不适组双通道内存、插电运行、调整线程数回答质量离谱Q2_K 量化损失 / 温度过高换 IQ3_XS温度设 0.6~0.7加载特别慢SATA 硬盘 / 内存不足换 NVMe、增加内存、重启释放缓存多轮对话后越来越慢KV cache 膨胀减小 ctx、定期新开会话最后再分享一个实用技巧如果你主要用中文可以在 system prompt 里加一句请用中文回答答案要简洁这会减少输出 token 数量变相把速度劣势扳回一点。如果只是追求能跑8GB 跑 35B 并不是什么玄学它就是一次显存不足时的工程妥协理解了层分配和量化这两个核心你也能在 8GB 卡上把同级模型稳稳拉起来。