8GB显存跑35B大模型实录：RTX 4060部署与调优

网上聊本地大模型显存总被当成一道硬门槛——跑 7B 要 8GB 显存跑 14B 要 16GB32B 以上基本被判定为没 40GB 显存就别碰。但我手里这台机器只有一张 RTX 4060 8GBCPU 是 i5-12490F内存 32GB明摆着不是为本地大模型准备的。偏偏我又不死心刷了一堆 35B 档位模型的量化包帖子之后特别想验证一件事消费级显卡到底能不能扛住 35B 这个量级。折腾了三个周末踩了无数坑最后确实跑起来了——而且不是只能蹦几个字的演示而是能正经对话、写代码、做文档分析的完整可用状态。这篇文章就把完整实录写出来含配置、参数、速度测试、踩坑全过程给手上只有 8GB 卡的兄弟一个真实参考。1. 这个选题的缘起8GB 显存玩家的35B 执念1.1 为什么非要跟 35B 过不去人手一张 8GB 消费级显卡是当下很多非硬件玩家的真实状态。4060、3060、4050 这代卡显存几乎都卡在 8GB跑 7B/8B 模型很轻松跑 14B 用 4bit 量化也能勉强接受但再往上就总有人说没戏。我一开始也认命老老实实用 7B 模型。可时间一长就发现问题7B 模型的逻辑推理和代码生成能力很难撑住真实需求。让它写个带状态管理的 Python 类经常答非所问让它分析一份合同条款又容易漏掉关键信息。真正能干事的大模型业内基本共识是从 30B 往上走而 35B 这一档恰好是专业能力明显提升 量化后体积还能控制在 20GB 左右的甜点区。问题就在这20GB 的模型8GB 显存放不下但也不是完全不能碰——只要显存放一部分、内存放一部分配合 CPU 一起算理论上就能跑。我想搞清楚的就是这个理论上到底能兑现多少。1.2 先说清楚8GB 能跑的是什么不能跑的是什么先把丑话说在前面避免抬杠。8GB 显存跑 35B不是指把完整 FP16 精度的 35B 模型塞进显存那在物理上就不可能。真实做法是两步叠加模型用 4bit 量化体积从 70GB 量级压到 20GB 量级显存只负责存放其中一部分层CPU 和系统内存承担剩余部分也就是说这是一套显存不够、内存来凑的混合推理方案。代价是推理速度远低于纯显存运行体验介于真能用和卡到崩溃之间。整篇文章要讲清楚的就是这个中间地带到底长什么样。网上热词里本地大模型怎么部署ai大模型本地部署频繁出现说明不少人和我一样既没有 A100 也没有 4090就是一台普通消费级电脑想在隐私可控的前提下用上大模型。这套方案不完美但确实是一个真实可复制的起点。2. 35B 模型的资源账单先把账算清楚再动手2.1 量化档位决定体积也决定你能跑什么35B 这一档社区里常见的代表有 Qwen2.5-32B、Yi-34B、CodeLlaMA-34B 等参数量在 32B 到 34B 之间统一叫 35B 档位比较方便。不同量化精度下模型文件体积差异巨大。我实测用的是 Qwen2.5-32B-Instruct 的 GGUF 量化版各档位体积大致如下量化档位32B 模型体积运行所需内存质量损失FP16约 64GB64GB无Q8_0约 34GB40GB极轻微Q5_K_M约 22GB32GB轻微Q4_K_M约 20GB24GB可接受Q3_K_M约 17GB24GB明显Q2_K约 13GB20GB严重注意 Q4_K_M 是我最终选的档位。很多人会想选更小的 Q3 甚至 Q2以为能省内存但实测下来质量损失非常明显尤其是中文长文本和代码逻辑推理上会有一种说了人话但句句不过脑的怪异感。Q4_K_M 是体积和质量的平衡点正好卡在 20GB 左右配合 32GB 系统内存能把模型整体装进去还有富余。2.2 显存和内存的分工逻辑不是平均分配模型权重只是一个部分真正运行的时候还有 KV Cache 和激活值。KV Cache 是给对话缓存历史状态用的上下文越长占用越大。所以20GB 模型 32GB 内存这个配置内存必须留出 3-5GB 给 KV Cache 和系统开销否则会直接 OOM。那 8GB 显存放多少层合适Qwen2.5-32B-Instruct 有 64 个 transformer 层Q4_K_M 化后整个模型约 20GB平均每层约 0.3GB。8GB 显存里Windows/Linux 桌面系统本身会占掉 0.5-1GB这取决于驱动和桌面环境真正能给模型的可用显存大约 7-7.5GB。再留 1GB 左右给 KV Cache实际能放约 6.5GB 的权重层换算下来就是 20 层左右也就是总层数的三分之一。这是我整轮实测的锚点64 层里只放 20 层上显存剩余 44 层在 CPU 上跑。当然不是死数字上下文调短一点、KV Cache 占用小一点就能多放两三层反过来把上下文拉长层数就得往下调。所有速度调优本质上就是在层数、上下文长度、可用内存三者之间找平衡。2.3 内存带宽才是真正的隐形瓶颈显存放不下不是最要命的最要命的是 CPU 推理部分的速度瓶颈。GPU 上算层数可以很快但 CPU 上跑 44 层每一层都要把几 GB 的权重从内存搬到 CPU 寄存器。DDR4-3200 双通道的实际带宽大约只有 35-40GB/s模型权重 44 层对应约 13.5GB每生成一个 token 都需要把这些卷积权重过一遍。算下来每秒能过 2-3 遍也就是理论上限 2-3 token/s。这个数字在动手之前就该有心理准备。35B 模型在 8GB 显存配置上生成速度就卡在个位数 token/s跟 ChatGPT 那种 30-50 token/s 完全不是一个世界。但这不代表不能用要看怎么用——这个后面实测环节再拆。部署选型Ollama 与 llama.cpp 的选择和关键参数3.1 为什么两个工具都要用本地部署大模型的工具很多但我这次建议两手抓先用 Ollama 快速验证模型能不能跑再用 llama.cpp 做精细控制。Ollama 胜在开箱即用一条命令下载模型、一条命令跑起来自动处理 GGUF 文件。但它的调度策略是自动把能放进显存的层都放进去如果显存不够会自己把剩余层放 CPU不给你太多手动干预空间。对第一次接触本地部署的人很友好但对想压榨性能的人来说不够灵活。llama.cpp 就是另一套思路所有参数都摆在明面上。-ngl指定多少层放 GPU-t指定 CPU 线程数-c指定上下文长度-m指定模型路径。配置多但能精确控制每一寸显存。我的最终策略是先跑 Ollama 看默认效果再切到 llama.cpp 手动调参找到 8GB 显存下的最优层数。3.2 硬件清单和基线环境先交代这次实测的整机配置给一个可对照的基线部件配置备注GPUNVIDIA RTX 4060 8GB现代桌面显卡最低显存档位CPUIntel i5-12490F6 核心 12 线程中端内存32GB DDR4-3200 双通道实测下来 16GB 会崩24GB 也紧系统盘NVMe SSD 512GB本地部署大模型必须用 SSD系统Ubuntu 22.04 LTS建议在 Linux 下跑Windows 下效率低一截工具链llama.cpp master Ollama 0.5两者都用这里特别强调 Linux。同样一套配置Ubuntu 下比 Windows 下推理速度快 10%-20%OOM 概率也低得多。原因很简单Windows 桌面环境占显存、频繁调度后台进程CUDA 上下文切换和显存碎片问题在 8GB 小显存上被放大。如果你没有 Linux 经验用 WSL2 也行跟我这套配置的差别不大。3.3 最终启动命令和参数解释llama.cpp 编译好后我的实际启动命令如下./llama-cli \ -m /models/qwen2.5-32b-instruct-q4_K_M.gguf \ -ngl 20 \ -t 6 \ -c 4096 \ --temp 0.7 \ --ctx-size 4096 \ -p 用中文写一段冒泡排序的 Python 代码并解释思路逐个说踩过的逻辑-ngl 20是最关键参数表示放 20 层到 GPU。我实测从 16 试到 2420 是最稳的档位。22 时速度反而下降了因为 KV Cache 和 CUDA context 挤在一起显存频繁换入换出。24 直接 OOM。-t 6设为物理核心数不是逻辑线程数。i5-12490F 是 6 核 12 线程一开始我设-t 12结果 CPU 调度开销大增速度掉到只有-t 6的八成。这是很多人忽略的点。-c 4096是上下文窗口。别学网上那些盲上 8192 的8GB 显存32GB 内存这套配置4K 上下文是速度和资源占用的临界点再往上 KV Cache 会侵占层数空间。--temp 0.7是采样温度做代码生成和文档分析一般 0.5-0.7 之间比较理性。Ollama 快速验证的命令更简单如果不想手动调参先用它确认模型能跑通再折腾细节ollama run qwen2.5:32b-instruct-q4_K_MOllama 会自动选择调度策略但我用下来它默认的层数分配比 llama.cpp 保守显存利用率略低速度慢一点好处是真的零配置。对完全新手这条命令就能看到效果。完整实测从加载到对话的每一步4.1 首次加载OOM 警告和 20 层的确定过程第一次启动我直接把-ngl设为 32纯粹想验证显存够不够。结果意料之中加载到一半就崩了报错信息里明确说 CUDA error: CUDA OOM。这不是玄学是数学32 层 × 0.3GB/层 9.6GB已经超出实际可用值再加上 KV Cache 和 CUDA context 之类固有开销8GB 物理显存根本装不下。我改成-ngl 22这次模型加载成功了但生成到第三个 token 时偶尔卡顿nvidia-smi显示显存占用打到 7.9GB几乎贴着天花板跑随时会在上下文轮转时暴毙。最后试到-ngl 20显存占用稳定在 6.9-7.2GB留了约 1GB 余量给历史上的 KV Cache 和系统噪音整个过程才稳下来。这里有个直观经验想让负载长期稳定运行显存占用就别超过总显存的 90%。8GB 卡就是 7.2GB 以内。别拿显存还有几百 MB 空着就觉得可以再多塞一层的心态去赌上下文一翻滚就会 OOM。4.2 不同 offload 层数的速度对比我把-ngl分别设为 0、10、16、20 跑同一段文本生成任务记录每秒 token 数和资源占用情况参数配置实际层数GPU/CPU平均生成速度显存占用内存占用首 token 延迟-ngl 00/640.8-1.2 t/s约 0.5GB约 20GB7-10 秒-ngl 1010/541.5-2.0 t/s约 3.8GB约 17GB5-6 秒-ngl 1616/482.2-2.8 t/s约 5.5GB约 15GB4-5 秒-ngl 2020/443.0-4.2 t/s约 7.0GB约 12GB3-4 秒结论很明显-ngl 20时速度是纯 CPU 模式的 3 倍以上显存占满但稳定。再往上不是 OOM 就是不稳定所以 20 层就是这颗 8GB 显存的物理天花板除非改用更小的量化档位。那 3-4 t/s 用起来是什么感觉打一段 100 个字的中长回复大概等 30-50 秒。说流畅肯定是骗人但结合首 token 延迟只有 3-4 秒的事实人机交互的等待感比想象中好很多。真正的问题是你一次让它写很长的代码它能不间断输出问题就是你能不能忍住盯着屏幕看 10 分钟。4.3 生成质量对比Q4 和 Q8 的差异出乎意料为了确认量化对质量影响我同时下载了 Q8_0 版本约 34GB在 32GB 内存下跑纯 CPU。结果同样一段中文代码生成任务Q4_K_M 和 Q8_0 的回复质量几乎没有肉眼可见差异。我把两个输出放在一起做了 AB 对比逻辑一致性两者都很完整没有明显的逻辑断裂代码正确性Q8 在边界判断上比 Q4 稍微严谨一点但 Q4 的错误也只是少一个空行级别中文表达Q4 偶尔出现一个比较生硬的措辞但整体依旧通顺数学计算Q4 多了一个约等于的偏差Q8 完全准确这个结果基本验证了业内说法4bit 量化对 30B 以上模型的损伤远小于对 7B 模型的损伤。大模型参数冗余度高量化掉 2Byte 里的 1.5Byte 后核心能力还在。所以不要觉得我用 Q4 是妥协在这档显存上Q4_K_M 就是最优选。六个坑与对应的解药5.1 系统内存不足导致的隐性 OOM第一个大坑是系统内存。很多人看模型文件 20GB就只配 24GB 内存以为绰绰有余。实际上运行时的 KV Cache、上下文缓冲、CUDA 与 CPU 间的数据拷贝缓冲都会吃内存实测下来内存占用在 12GB-16GB 之间浮动。如果内存卡得太死系统不是马上崩而是触发 swap 交换到硬盘。那体验就是生成速度断崖式下降从 3 t/s 掉到 0.3 t/s看起来像是推理卡住了。我当时用 16GB 内存测得就是这样差点以为是模型文件坏了。解药很简单32GB 内存起步低于这个数别碰 35B。这条也是我能给的最朴素硬件建议。5.2 上下文设置太长层数被 KV Cache 挤掉我一开始贪心把-c设为 8192结果显示 22 层都能加载但跑起来频繁 OOM。原因刚才说了上下文越长KV Cache 占的显存越多把本来该给模型的显存抢走了。8GB 显存跑 35B上下文建议控制在 2048-4096 之间。我实测 4096 是平衡点再往上危机四伏。实际需求里大部分提问和代码补全 4096 token 已经够用没必要硬撑 8K。5.3 CPU 线程数设错越设越慢llama.cpp 的-t参数很多人会直接按任务管理器里看到的 12 线程填 12。但实测-t 12反而比-t 6慢 20% 左右。原因在于 CPU 是 6 核心 12 线程超线程SMT在数学密集型的矩阵乘推导中占不到便宜反而因为两个线程争抢同一个核心的执行单元导致上下文切换开销暴增。正确测法是只设物理核心数也就是 6让 6 个核心满负荷跑剩余 6 个线程留给操作系统和其他进程。如果是 8 核 16 线程的 CPU同样道理填 8 不填 16。5.4 内存带宽和频率的隐性影响同样的 32GB 内存DDR4-2666 和 DDR4-3600 之间的差距会直接反映到 CPU 推理速度上最大能差 30%。我一开始用两条 2666 内存跑速度只有 2.5 t/s换成 3200 后升到 3.4 t/s换成 3600 后到 3.9 t/s。原因还是 CPU 推理部分要反复搬运权重内存带宽直接决定搬运速度。如果你手里的 CPU 和主板支持高频内存尽量插满双通道这是除了 GPU 之外性价比最高的升级。5.5 电源管理和散热导致的降频RTX 4060 单卡功耗不高但跑大模型是长期满载GPU 核心温度和 CPU 核心温度会在 10 分钟后逐步爬升。我跑了一小时长生成任务后发现速度从 3.8 t/s 掉到 2.8 t/s问题就出在温度墙导致降频。解决方式是明确的机箱风道至少保证前后贯通GPU 风扇手动调到 70%CPU 散热器别用原装换个单塔风冷足够。另外 Linux 下注意安装power-profiles-daemon并切到性能模式别让系统把 CPU 锁到节能档。5.6 一次诡异的 API 缓存导致启动失败还有一次我改完参数重启后进程一直起不来报错显示 Failed to load the model。排查后发现是 WASM 版本的 llama.cpp 缓存和铜制的 CUDA 后端缓存冲突删掉~/.cache/llama.cpp和临时目录后正常。这条比较小众但值得记一笔改模型文件路径或者换量化版本时如果出现莫名奇妙的加载失败先清缓存再查依赖库最后才怀疑模型损坏。实测感想这套配置真正适合谁6.1 三个月的实际使用场景复盘跑起来之后我不只是做技术验证后续三个多月里真的把这台机器当主力工具用了。用得最多的场景长文本摘要把一篇两万字的技术文档投进去100 字以内的摘要十几秒就出准确度比 7B 模型高一个大档代码审查丢一段 300 行的 Python 函数进去让它检查逻辑漏洞能准确指出循环边界和内存泄漏风险私有知识库问答配合本地向量库把公司内部规范文档喂进去用 35B 模型做最后的归纳生成效果接近商用 API这些场景的共同特点是不追求秒回能接受 30-60 秒的等待对隐私和成本敏感。反过来如果你需要 Chat-GPT 那种快速流畅的对话体验或者需要高频反复问答这套方案会让你急得砸键盘。6.2 给 8GB 显卡兄弟们的心态建议最后说点实在的8GB 显存跑 35B 这件事技术上成立体验上是有代价的。它不是8GB 也能全速跑 35B的神话而是8GB 可以在可接受的等待时间下用 35B 模型干活的现实路径。如果看完这篇你还是觉得 3-4 t/s 太慢接下来值得做的两件事分别是攒钱买 16GB 显存二手 3090 或 4060 Ti 16GB那套配置跑 35B 的速度能到 12-15 t/s体验完全不同或者干脆用量化到 Q4 的 14B 模型先顶着等有合适硬件再换。我个人现在的工作流是日常快速问答用 14B 模型长篇正经分析切到 35B。一顿操作之后最深的体会是本地大模型部署永远是一个资源与需求做权衡的游戏真正重要的是把每一档预算能跑的东西摸到极限然后按场景切换。8GB 这张卡摸到 35B 这一步已经值回票价了。