8G显存实战：量化与CPU混合推理跑35B大模型

1. 为什么8G显存跑35B模型这件事值得认真聊

先把结论摆在前面：8G显存跑35B大模型，不是玄学，也不是把模型阉割到没法用，而是一套已经被大量实践验证过的组合拳——量化压缩 + CPU/GPU混合推理。核心逻辑就一句话：把模型的权重从16位浮点压到4位甚至更低，让原本需要几十G显存才能装下的参数，塞进8G显存里；再把一部分计算任务分给CPU和内存去扛，GPU只负责它最擅长的那部分。

我自己手头的主力机器就是一张8G显存的卡，之前一直觉得跑个7B、8B的模型就到头了，13B量化一下勉强能跑，30B以上的想都不敢想。后来接触到GGUF格式和llama.cpp这套工具链，才发现思路完全被打开了。现在35B级别的MoE模型，在这台机器上跑出可用的速度，已经是日常操作。

这篇文章适合谁看？三类人：一是手上有8G显存显卡（比如RTX 3060、4060、2070这些），想跑大模型但不想换硬件的人；二是对量化、GGUF、CPU混合推理这些概念听过但没实操过的人；三是已经能跑小模型，想进一步挑战更大参数规模的人。我会把整个思路、参数选择、实操步骤、踩过的坑全部摊开讲，你照着做基本能复现。

需要提前说明的是，35B这个量级的模型，尤其是MoE架构的，在8G显存上跑起来的速度不会是“飞起”那种体验，但做到流畅对话、代码补全、文档问答是完全没问题的。关键在于你怎么分配GPU和CPU的负载，以及选对量化等级。

2. 量化与混合推理的底层逻辑拆解

2.1 量化到底在做什么：从16位到4位的压缩账

量化的本质，是用更少的比特数去表示原本的权重数值。一个模型原始的权重通常是FP16（16位浮点），每个参数占2字节。35B参数就是350亿个参数，乘2字节，光权重就要70GB。这还没算KV Cache和中间激活值，8G显存连零头都不够。

量化的做法是把这些权重映射到更低的位宽。常见的有Q8（8位）、Q5、Q4、Q3、Q2。以Q4为例，每个参数大约占4.5位（因为还有缩放因子等开销），350亿参数乘4.5位除以8，大约是19.7GB。还是超过8G，但已经进入“可以想办法”的范围了。

这里有个关键点很多人会忽略：量化不是简单地把数字截断，而是通过分组缩放来尽量保留精度。GGUF格式里常见的Q4_K_M、Q5_K_M这些，K代表K-quant，用了分块量化的策略，把权重分成小块，每块单独算缩放因子。这样比全局统一缩放精度损失小得多。M代表medium，是质量和大小的折中档。

我实测下来，Q4_K_M在35B MoE模型上的表现，和原始FP16的差距在日常对话里几乎感知不到，代码生成会有一点点退化但完全可用。Q3_K_M就开始明显掉质量了，Q2基本只能做很粗的任务。所以我的建议是：能上Q4就别降到Q3，除非你的内存实在不够。

2.2 为什么MoE架构是8G显存的救星

35B模型能跑起来，很大程度要感谢MoE（混合专家）架构。传统稠密模型比如Llama 35B，每次推理所有350亿参数都要参与计算。MoE不一样，它把模型拆成很多个“专家”，每次推理只激活其中一小部分。

拿Qwen3系列的35B MoE来说，总参数35B，但每次激活的可能只有3B左右。这意味着什么？意味着虽然模型文件有20GB，但实际参与计算的计算量只相当于一个3B稠密模型。计算量小，推理速度就快；而知识容量又来自那35B的总参数，所以模型“懂得多”。

但这里有个陷阱：MoE的显存占用并不会因为只激活3B就降到3B的水平。因为所有专家的权重都得加载到内存里，随时准备被调用。所以显存/内存占用还是按总参数量算的。这就是为什么必须配合量化和CPU混合推理——权重放不下GPU，就放到内存里，CPU负责调度和部分计算。

2.3 CPU混合推理的分工逻辑：谁干什么活

混合推理的核心思想是：GPU算得快但显存小，CPU算得慢但内存大。那就让GPU负责它装得下的那部分层，剩下的层交给CPU。llama.cpp里通过-ngl（number of GPU layers）参数来控制有多少层放到GPU上。

具体怎么分？假设模型有40层，8G显存扣掉系统占用和KV Cache，大概能放20层左右。那-ngl 20就是把前20层放GPU，后20层放CPU。GPU部分跑得飞快，CPU部分慢一些，但整体是并行的，最终速度取决于最慢的那一环。

这里有个经验公式：每层占用的显存 ≈ 模型文件大小 / 总层数。比如20GB的模型40层，每层约500MB。8G显存留2G给系统和KV Cache，能放12层左右。但实际还要看KV Cache的大小，上下文越长，KV Cache越大，能放的层就越少。

我一般会先设一个保守值，比如-ngl 15，跑起来看显存占用，再逐步往上加，直到显存快满但不出错为止。这个过程需要试几次，但一旦找到最佳值，以后就固定用。

3. 实操环境搭建与模型选择

3.1 工具链选型：为什么是llama.cpp + GGUF

跑量化模型，工具链的选择很关键。目前主流的有几种：llama.cpp、Ollama、LM Studio、text-generation-webui。我最终选的是llama.cpp直接跑，原因有几个。

第一，llama.cpp对GGUF格式的支持最原生，参数控制最细，-ngl、-c、-t这些参数可以精确调节。Ollama虽然方便，但封装太厚，很多底层参数改不了，混合推理的层数分配不够灵活。第二，llama.cpp的CPU推理优化做得最好，用了AVX2、AVX512指令集加速，在纯CPU部分也能跑出可接受的速度。第三，它轻量，没有Python依赖地狱，编译完就是一个二进制文件，扔哪都能跑。

GGUF格式本身也是为这个场景设计的。它把模型权重、tokenizer、配置全部打包在一个文件里，支持各种量化等级，而且内存映射（mmap）加载，启动速度快，不会一次性把整个模型读进内存。

安装llama.cpp的步骤不复杂，但有几个编译选项要注意：

git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDA=ON -DGGML_CUDA_F16=ON cmake --build build --config Release -j$(nproc)

GGML_CUDA=ON是开启CUDA支持，如果你用的是N卡必须开。GGML_CUDA_F16=ON是让部分计算用FP16，速度更快。编译完之后，build/bin/目录下会有llama-cli、llama-server等可执行文件。

注意：编译时如果报错找不到CUDA，检查CUDA Toolkit是否安装，以及nvcc是否在PATH里。另外，CUDA版本和显卡驱动版本要匹配，太老的驱动可能不支持新版的CUDA。

3.2 模型下载：去哪找靠谱的GGUF文件

GGUF模型文件主要从Hugging Face上下载。搜索的时候直接搜模型名加GGUF，比如“Qwen3-35B GGUF”。一般会有多个上传者提供不同量化等级的版本，选下载量高、评论多的那个。

文件命名通常包含量化等级，比如Qwen3-35B-Q4_K_M.gguf。Q4_K_M是中等质量的4位量化，文件大小约20GB。如果内存只有16GB，可以考虑Q3_K_M，约15GB。内存32GB的话，Q5_K_M也可以试试，约24GB，质量更好。

下载方式用huggingface-cli或者直接wget都行。大文件建议用支持断点续传的工具，不然下到一半断了很痛苦。

huggingface-cli download username/repo-name Qwen3-35B-Q4_K_M.gguf --local-dir ./models

提示：下载前先看清楚文件大小和你的内存是否匹配。模型加载后占用的内存大约是文件大小的1.1到1.2倍，因为还有KV Cache和运行时开销。16GB内存跑20GB的模型会很吃力，建议至少32GB内存。

3.3 硬件配置的底线要求

8G显存是标题里的核心条件，但光有显存不够，内存和CPU也很关键。我整理了一个最低配置和推荐配置的对照：

内存是最容易被低估的。很多人以为8G显存就能跑，结果模型加载到一半就OOM了。20GB的模型文件，加载后占用内存可能到22-24GB，16GB内存根本不够。所以如果你的内存只有16GB，要么选更小的量化等级（Q3），要么选参数更小的模型。

CPU的核心数影响CPU部分的推理速度。llama.cpp支持多线程，-t参数控制线程数，一般设成物理核心数。比如8核16线程的CPU，设-t 8比较合适，设16反而可能因为超线程调度开销导致速度下降。

4. 混合推理参数调优与实测

4.1 关键参数逐个拆解：-ngl、-c、-t怎么设

llama.cpp的参数很多，但跑混合推理核心就几个。我把它们的作用和设置逻辑列出来：

-ngl（GPU层数）：这是最重要的参数。设多少层到GPU上，直接决定速度和显存占用。设得太少，GPU闲着，速度慢；设得太多，显存爆了，直接报错。我的做法是从小到大试，先设10，跑起来看nvidia-smi的显存占用，然后每次加2，直到显存占用到7.5G左右就停。

-c（上下文长度）：默认是512，但实际用起来至少设4096。上下文越长，KV Cache越大，显存占用越高。如果设了-ngl之后显存快满了，可以适当降低-c，比如从8192降到4096，能省出不少显存。

-t（CPU线程数）：设成物理核心数。比如6核12线程的CPU，设-t 6。设太多会导致线程切换开销，反而变慢。

-b（批处理大小）：默认512，一般不用改。如果内存紧张可以降到256。

一个典型的启动命令长这样：

./build/bin/llama-cli \ -m ./models/Qwen3-35B-Q4_K_M.gguf \ -ngl 18 \ -c 4096 \ -t 8 \ -n 512 \ --temp 0.7 \ -p "你的提示词"

-n 512是最多生成512个token，--temp 0.7是温度参数，控制随机性。

4.2 显存与层数的计算过程：一次真实的调参记录

我拿手头的RTX 3060 8G实测了一次。模型是Qwen3-35B-Q4_K_M，文件大小20.3GB，总层数41层。

第一步，先不设-ngl，纯CPU跑，记录基线速度。结果是大约2.1 token/秒，能用但偏慢。

第二步，设-ngl 10，跑起来看显存。nvidia-smi显示显存占用4.2GB，速度提升到4.5 token/秒。

第三步，设-ngl 15，显存占用5.8GB，速度6.8 token/秒。

第四步，设-ngl 18，显存占用6.9GB，速度8.2 token/秒。

第五步，设-ngl 20，显存占用7.6GB，速度8.9 token/秒，但偶尔报显存不足的警告。

最终我固定在-ngl 18，留一点显存余量给系统波动。速度8.2 token/秒，对于35B模型来说，这个速度已经相当可用了。作为对比，纯CPU只有2.1，提升接近4倍。

这里有个细节：每增加一层到GPU，速度提升不是线性的。从10层到15层，每层提升约0.46 token/秒；从15层到18层，每层提升约0.47；但从18到20，每层只提升0.35，而且开始不稳定。这是因为GPU层数多了之后，CPU部分的瓶颈更突出，整体速度受限于最慢的环节。

4.3 不同量化等级的实测对比

为了搞清楚量化等级对速度和质量的影响，我分别跑了Q3_K_M、Q4_K_M、Q5_K_M三个版本，记录如下：

Q3的速度最快，因为文件小，能放更多层到GPU，CPU负担轻。但质量确实有下降，我让它写一段稍微复杂的代码，Q3版本会出现变量名不一致的问题，Q4和Q5就没这个问题。

Q5质量最好，但24GB的文件在32GB内存的机器上跑，系统已经很吃紧了，而且能放的GPU层数少，速度掉到6.4。除非你对质量有极高要求，否则Q4_K_M是最平衡的选择。

我的建议：先用Q4_K_M跑起来，如果速度不满意再降Q3，如果质量不满意再升Q5。不要一上来就追求最高质量，速度太慢会影响使用体验。

5. 常见问题排查与避坑经验

5.1 启动就报错：显存不足和内存不足的区分

跑混合推理最常遇到的就是资源不足的报错。但显存不足和内存不足的报错信息不一样，排查思路也不同。

显存不足的典型报错是CUDA out of memory或者failed to allocate buffer。这时候要降低-ngl，或者降低-c。有时候降低-c比降低-ngl更有效，因为KV Cache占的显存可能比几层权重还多。

内存不足的报错是failed to mmap或者直接被系统kill掉。这时候只能换更小的量化等级，或者加内存。没有别的办法，因为模型权重必须全部加载到内存里。

还有一种情况是加载到一半卡住不动，这通常是内存刚好卡在临界点，系统在疯狂交换。这时候看free -h，如果swap占用很高，就是内存不够了。

5.2 速度突然变慢：线程数和批处理的坑

有时候模型能跑起来，但速度比预期慢很多。我遇到过几次，排查下来主要是两个原因。

一是-t设得太大。我一开始想当然设了16线程（CPU是8核16线程），结果速度反而比设8慢。原因是超线程的两个逻辑核心共享物理核心的执行单元，推理这种计算密集型任务，超线程带来的并行收益很小，反而增加了调度开销。后来改成-t 8，速度提升了约15%。

二是-b批处理大小和内存带宽不匹配。批处理太大，内存带宽成为瓶颈，数据搬运的时间超过了计算时间。我试过把-b从512降到256，速度反而略有提升。这个需要根据具体硬件试，没有统一答案。

5.3 输出质量差：量化损失和温度参数的平衡

量化之后模型输出质量下降，有时候不是量化的锅，而是温度参数没调好。量化本身会引入噪声，如果温度设得太高（比如1.0以上），噪声被放大，输出就会变得混乱。

我的经验是：量化模型用比原始模型更低的温度。原始FP16模型用0.7，量化模型就用0.5到0.6。这样既保持了一定的多样性，又不会因为量化噪声导致输出失控。

另外，--top-p和--top-k也要相应调整。我一般用--top-p 0.9 --top-k 40，这是一个比较保守的组合，适合量化模型。

如果调整参数后质量还是不行，那就是量化等级太低了，只能换更高的量化等级。Q3换Q4，Q4换Q5，每升一级质量都有可感知的提升。

5.4 常见问题速查表

6. 进阶技巧：让8G显存跑得更稳更快

6.1 KV Cache量化：省显存的隐藏技巧

KV Cache是推理过程中缓存的历史键值对，上下文越长，KV Cache越大。对于8G显存来说，KV Cache可能占到1-2GB，这部分如果能量化，就能省出显存放更多层到GPU。

llama.cpp支持KV Cache量化，通过--cache-type-k和--cache-type-v参数控制。默认是FP16，可以改成Q8或Q4。

--cache-type-k q8_0 --cache-type-v q8_0

这样KV Cache的显存占用直接减半，代价是极小的精度损失。我实测下来，Q8的KV Cache对输出质量几乎没有影响，但能多放2-3层到GPU，速度提升约10%。Q4的KV Cache省得更多，但质量开始有可感知的下降，不太推荐。

6.2 用llama-server搭建本地API服务

llama-cli适合交互式对话，但如果你想把它集成到其他应用里，比如自己写个前端或者接入自动化流程，用llama-server更方便。它启动一个HTTP服务，兼容OpenAI的API格式。

./build/bin/llama-server \ -m ./models/Qwen3-35B-Q4_K_M.gguf \ -ngl 18 \ -c 4096 \ -t 8 \ --host 0.0.0.0 \ --port 8080

启动后，就可以用任何支持OpenAI API的客户端来调用，比如Python的openai库：

from openai import OpenAI client = OpenAI(base_url="http://localhost:8080/v1", api_key="not-needed") response = client.chat.completions.create( model="local", messages=[{"role": "user", "content": "你好"}] ) print(response.choices[0].message.content)

这样就能把本地大模型接入到各种工具链里，比如Continue、Cursor这些代码编辑器插件，或者自己写的自动化脚本。

6.3 模型文件的管理和切换

跑多个模型的时候，文件管理是个问题。每个GGUF文件都十几二十GB，硬盘很快就满了。我的做法是只保留最常用的两个量化等级，比如Q4_K_M和Q3_K_M，其他需要的时候再下载。

另外，llama.cpp支持从标准输入读取提示词，方便脚本化调用：

echo "写一个Python快速排序" | ./build/bin/llama-cli -m model.gguf -ngl 18 -c 2048 -t 8 -n 256

这样就能把模型调用嵌入到shell脚本里，做批量处理。

6.4 长期运行的稳定性注意事项

如果你打算让模型长时间运行，比如作为常驻服务，有几个点要注意。

第一，显存泄漏。llama.cpp本身做得不错，但长时间运行后显存占用可能会缓慢增长。建议定期重启服务，比如每天一次。

第二，温度控制。GPU长时间满载温度会升高，如果散热不好会降频，速度下降。确保机箱风道通畅，或者用nvidia-smi -pl限制功耗，牺牲一点速度换稳定性。

第三，日志监控。llama-server会输出请求日志和错误信息，建议重定向到文件，方便排查问题。

./build/bin/llama-server ... >> server.log 2>&1 &

这样即使终端关了，服务也在后台跑，日志也保留了。

7. 实际使用场景与效果评估

7.1 日常对话和文档问答的表现

我平时用这套配置做三件事：技术问题咨询、文档摘要、代码片段生成。35B MoE模型在这三个场景下的表现，比我之前用的7B模型有明显提升。

技术问题咨询方面，35B模型能理解更复杂的上下文，回答更有深度。比如我问它“llama.cpp的KV Cache量化原理是什么”，7B模型只能泛泛而谈，35B能讲到分组量化和缩放因子的层面。

文档摘要方面，我把一篇5000字的技术文章扔给它，让它总结要点。35B模型能抓住核心论点，而且不会遗漏重要细节。7B模型经常漏掉关键信息，或者把次要内容当成重点。

代码生成方面，简单的函数和脚本没问题，复杂的算法实现偶尔会有bug，但整体可用。速度8 token/秒，生成一个50行的函数大概需要30秒，可以接受。

7.2 和纯GPU方案的对比：值不值得折腾

有人可能会问：既然8G显存跑得这么勉强，为什么不直接买张24G的卡？这个问题很现实。24G的RTX 4090或者3090，确实能全量加载35B Q4模型，速度能到30 token/秒以上，体验完全不一样。

但成本差距也很大。一张4090的价格，够买一台整机了。对于预算有限、又想跑大模型的人来说，8G显存+混合推理是唯一的选择。而且这套方案的可扩展性好，以后换了更大的显存，直接把-ngl调大就行，模型和工具链都不用换。

从性价比角度算：8G显存卡假设2000元，32G内存500元，加起来2500元。24G卡至少8000元起。花三分之一的钱，得到约三分之一的速度，这个账还是划算的。

7.3 什么情况下这套方案不够用

混合推理不是万能的。如果你需要高并发、低延迟的服务，比如同时处理几十个请求，这套方案撑不住。CPU部分的推理速度是硬瓶颈，并发一高就排队。

另外，如果你需要极长的上下文，比如处理整本书或者大型代码库，KV Cache会吃掉大量显存，能放的GPU层数急剧减少，速度会掉到难以接受的程度。

还有一种情况是模型参数超过70B，即使Q4量化也要40GB以上，32GB内存都装不下，这套方案就彻底没戏了。35B是8G显存+32G内存的甜蜜点，再大就力不从心了。

8. 我踩过的坑和最后几条实用建议

折腾这套方案的过程中，我踩了不少坑，这里挑几个最有代表性的说一下。

第一个坑是盲目追求高量化等级。一开始我非要跑Q5_K_M，觉得质量好，结果24GB的文件在32GB内存的机器上，系统频繁swap，速度掉到3 token/秒，还不如Q4。后来换成Q4_K_M，速度翻倍，质量差距在日常使用中根本感知不到。

第二个坑是**-ngl设得太激进**。有次我设了-ngl 22，启动时没报错，跑了几轮对话之后突然崩溃，显存溢出。后来才知道，启动时的显存占用和运行一段时间后的占用不一样，KV Cache是动态增长的。所以-ngl要留余量，不能卡着极限设。

第三个坑是忽略了CPU散热。混合推理时CPU也是满载的，我原来的散热器压不住，跑十几分钟就降频，速度从8掉到5。换了个好点的风冷之后，速度稳定了。

最后分享几条实用建议。第一，先用小模型验证工具链是否正常，再上大模型，这样排查问题简单。第二，把最佳参数记下来，写成一个启动脚本，每次直接跑脚本，不用重新调。第三，定期检查llama.cpp的更新，这个项目迭代很快，新版本经常有性能优化。

这套方案我用了大半年，从最初的磕磕绊绊到现在稳定运行，中间交了不少学费。但回过头看，8G显存能跑35B模型这件事本身，就已经值回票价了。如果你手头正好有类似的硬件，不妨照着试试，调参的过程本身就是很好的学习。