1. 8G显存跑35B模型这件事先搞清楚它到底难在哪先把结论摆在前面8G显存跑35B参数的大模型不是靠黑科技硬塞进去的而是靠量化压缩 CPU/GPU混合推理这套组合拳把原本需要几十G显存才能装下的模型拆成显存装一部分、内存装一部分、CPU算一部分的分工模式。听起来简单但真正动手的时候坑比想象中多得多。我最初接触这个需求是因为手头只有一台带RTX 40608G显存的笔记本却想跑一个35B级别的MoE模型做本地推理测试。当时第一反应是不可能因为按FP16精度算35B参数光权重就要70GB左右8G显存连零头都不够。但后来发现量化能把权重压到4bit甚至更低35B模型在Q4_K_M量化下大约占20GB左右虽然还是塞不进8G显存但配合CPU混合推理把一部分层放到内存里由CPU计算就变得可行了。这里要先厘清一个概念35B大模型通常指的是总参数量350亿左右的模型如果是MoE混合专家架构实际激活的参数可能只有几B这也是为什么有些35B模型跑起来比稠密13B还快。而GGUF格式是llama.cpp生态里最常用的量化模型格式它天生支持CPU/GPU混合推理把模型按层切分一部分放GPU、一部分放CPU这正是8G显存能跑大模型的关键。所以这篇文章要解决的问题很具体在8G显存的硬件条件下如何通过量化和CPU混合推理把一个35B级别的GGUF模型跑起来并且跑得尽量快、尽量稳。适合谁看适合手头显卡显存不大、但想本地跑大模型做实验、做私有化推理、或者单纯想省云服务器钱的开发者。如果你有24G以上的显存这篇文章对你参考价值有限但如果你只有8G甚至6G显存那接下来的内容基本能帮你省掉几天试错时间。2. 量化到底在做什么从FP16到Q4_K_M的压缩逻辑2.1 量化不是降智而是有损压缩很多人一听量化就担心模型变傻。这个担心有道理但要看量化到什么程度。量化的本质是用更少的比特数来表示原本的权重数值。FP16每个权重占2字节Q4量化每个权重平均只占0.5字节左右压缩比接近4倍。压缩过程中肯定会损失精度但现代量化方法比如k-quant系列通过分块量化、保留关键层精度等手段把损失控制得很小。拿Q4_K_M来说它属于k-quant量化的一种K表示使用了k-quant算法M表示medium级别。它的做法是把权重分成若干块每块用不同的缩放因子同时对部分重要权重比如attention的某些投影层保留更高精度。实测下来Q4_K_M在大多数任务上的表现和FP16差距很小困惑度perplexity上升通常不到5%但体积缩小到原来的四分之一左右。2.2 常见量化档位怎么选不同量化档位的体积和效果差异很大我整理了一张对照表方便你根据显存和内存情况选择量化档位每权重比特35B模型体积约质量损失适用场景Q8_08bit约35GB极小内存充足追求质量Q6_K6bit约28GB很小内存较大平衡质量Q5_K_M5bit约24GB小内存中等Q4_K_M4bit约20GB较小8G显存大内存首选Q3_K_M3bit约16GB中等内存紧张Q2_K2bit约12GB较大极限压缩不推荐从这张表能看出来Q4_K_M是8G显存场景下的甜点档位。20GB左右的模型体积意味着即使8G显存只能装下三分之一剩下的12GB左右可以放到内存里由CPU处理。如果你的内存有32GB跑Q4_K_M完全没问题如果只有16GB内存建议降到Q3_K_M。2.3 为什么GGUF格式适合混合推理GGUF是llama.cpp推出的模型格式它和传统的PyTorch权重最大的区别在于GGUF把模型元数据、词表、权重全部打包在一个文件里并且支持按层加载。这个特性对混合推理至关重要因为llama.cpp可以决定把前N层放到GPU、剩下的层留在CPU内存里推理时数据在GPU和CPU之间流动。相比之下如果你用transformers加载FP16模型它默认会把整个模型往显存里塞塞不下就直接报OOM。虽然可以用device_map做分层加载但灵活性和效率都不如llama.cpp的GGUF方案。这也是为什么现在本地跑大模型GGUF几乎是标配。提示下载GGUF模型时一定要看清楚文件名里的量化标识比如Q4_K_M、Q5_K_M。同一个模型往往有十几个量化版本选错了要么跑不动要么浪费硬件性能。3. 混合推理的层分配策略哪些层给GPU哪些留给CPU3.1 层分配的核心原则混合推理的关键参数是n_gpu_layers它决定把多少层放到GPU上。这个数字不是随便填的填多了会OOM填少了GPU利用率不足、速度慢。核心原则是在显存不溢出的前提下尽可能多地把层放到GPU上因为GPU的计算速度远快于CPU。那怎么确定这个数字我的做法是先用一个保守值试跑比如先设n_gpu_layers10然后逐步往上加观察显存占用。llama.cpp在加载模型时会打印显存分配情况你可以根据输出调整。一般来说8G显存扣除系统和CUDA上下文占用大约1-1.5GB实际可用约6.5GB。35B模型Q4_K_M每层大约占0.5-0.7GB取决于层结构和是否MoE所以能放大约10-13层到GPU。3.2 不同模型架构的差异这里要特别注意MoE架构和稠密架构的区别。稠密35B模型每一层参数都参与计算层与层之间显存占用比较均匀。而MoE模型比如某些35B-A3B的变体虽然总参数35B但每层激活的专家数量有限实际计算量小很多显存占用也更低。这意味着MoE模型可以放更多层到GPU甚至有可能把大部分层都放上去。我实测过一个35B-A3B的MoE模型在8G显存下把n_gpu_layers设到20层还能稳定运行速度比稠密模型快不少。所以选模型的时候如果硬件有限优先考虑MoE架构。3.3 内存带宽才是真正的瓶颈很多人以为混合推理慢是因为CPU算力弱其实更关键的瓶颈是内存带宽。CPU推理时权重需要从内存读到CPU缓存再计算内存带宽决定了数据搬运速度。DDR4内存带宽大约25-50GB/sDDR5能到60-90GB/s而GPU显存带宽动辄几百GB/s甚至上千GB/s。所以当大量层放在CPU上时推理速度会被内存带宽拖累。这也是为什么混合推理的token生成速度通常只有纯GPU推理的几分之一。8G显存跑35B模型能跑到3-8 tokens/s就算不错了具体取决于CPU性能、内存带宽和层分配比例。如果你的预期是几十tokens/s那这套方案满足不了你得考虑更大显存的显卡或者云服务。4. 从零跑通llama.cpp环境搭建与参数配置4.1 编译带CUDA支持的llama.cppllama.cpp默认编译是不带GPU加速的必须显式开启CUDA。步骤如下以Linux为例Windows下用CMake GUI或命令行类似git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake .. -DGGML_CUDAON -DCMAKE_CUDA_ARCHITECTURESnative cmake --build . --config Release -jCMAKE_CUDA_ARCHITECTURESnative会让编译器自动检测你的GPU架构避免编译出不兼容的kernel。编译完成后build/bin目录下会有llama-cli、llama-server等可执行文件。注意编译前确认CUDA Toolkit版本和显卡驱动匹配。如果编译报错找不到CUDA检查nvcc --version是否正常输出以及CMake是否能找到CUDA路径。4.2 下载GGUF模型模型下载渠道很多常见的是Hugging Face上的GGUF仓库。下载时优先选Q4_K_M或Q5_K_M版本。下载完成后把文件放到一个固定目录比如~/models/。如果你用huggingface-cli下载命令大概是这样huggingface-cli download repo_id filename --local-dir ~/models下载大文件时建议用支持断点续传的工具因为20GB的文件中途断了重下很痛苦。4.3 启动参数详解跑混合推理的核心命令是llama-cli关键参数如下./llama-cli -m ~/models/model-Q4_K_M.gguf \ -ngl 12 \ -c 4096 \ -t 8 \ -n 512 \ --temp 0.7 \ -p 你的提示词逐个解释这些参数-ngl 12n_gpu_layers放到GPU的层数这是最关键的参数需要根据显存调整。-c 4096上下文长度越大占用内存越多。8G显存场景建议从2048或4096起步。-t 8CPU线程数一般设成物理核心数不要设成超线程数否则反而变慢。-n 512生成的最大token数。--temp 0.7温度参数控制随机性。如果你想用API方式调用用llama-server./llama-server -m ~/models/model-Q4_K_M.gguf -ngl 12 -c 4096 -t 8 --host 0.0.0.0 --port 8080启动后就能通过http://localhost:8080用OpenAI兼容接口调用了。4.4 显存溢出的排查方法如果启动时报CUDA out of memory说明-ngl设大了。这时候不要慌按以下步骤排查先把-ngl降到0确认纯CPU能跑通排除模型文件损坏的可能。逐步增加-ngl每次加2观察显存占用。可以用nvidia-smi -l 1实时监控。找到临界值后往回退1-2层留出余量避免推理过程中因为KV cache增长而OOM。如果上下文设得很大比如8192KV cache会占用不少显存这时候要么减小上下文要么减少GPU层数。我踩过的一个坑是启动时-ngl设得刚好不OOM但对话几轮之后上下文变长KV cache膨胀导致OOM。所以一定要留余量别卡着极限设。5. 实测数据与性能调优速度、内存、质量的三角平衡5.1 实测环境与基准数据我的测试环境是RTX 4060 Laptop8G显存、i7-13650HX14核20线程、32GB DDR5-4800内存。测试模型是一个35B-A3B的MoE模型Q4_K_M量化文件约20GB。不同-ngl设置下的实测数据n_gpu_layers显存占用内存占用生成速度备注00.5GB22GB2.1 tokens/s纯CPU慢但稳85.2GB17GB3.8 tokens/s保守设置127.1GB15GB5.2 tokens/s甜点值168.6GB13GBOOM超出显存20--OOM不可行从数据能看出来-ngl 12是这台机器的甜点值速度比纯CPU快了约2.5倍。再往上加就OOM了。如果你的内存带宽更高比如DDR5-6000纯CPU部分的速度会更快整体表现也会更好。5.2 影响速度的几个隐藏因素除了层分配还有几个因素会明显影响速度KV cache的量化。llama.cpp支持把KV cache也量化用--cache-type-k q8_0 --cache-type-v q8_0参数。这能显著减少显存和内存占用代价是轻微的质量损失。在8G显存场景下这个优化很值得开因为它能让你把更多层放到GPU上。批处理大小。-b参数控制批处理大小默认512。如果你的内存带宽充足适当增大批处理能提升吞吐但会占用更多内存。单用户交互场景下默认值通常够用。线程亲和性。在多CCD的AMD CPU或者大小核的Intel CPU上线程调度会影响性能。可以用taskset绑定CPU核心避免线程在大小核之间跳来跳去。我在i7上实测绑定到大核能提升约10%的速度。5.3 质量与速度的取舍量化和混合推理都会带来质量损失但损失程度不同。量化损失是模型层面的混合推理本身不损失质量只是计算位置不同。所以如果你发现输出质量下降优先怀疑量化档位选低了而不是混合推理的问题。我的建议是如果Q4_K_M的质量能接受就别为了速度降到Q3或Q2。Q3以下的质量损失在复杂推理任务上很明显会出现逻辑断裂、事实错误增多的情况。宁可慢一点也要保证输出可用。6. 那些文档里不会写的坑我踩过的五个真实问题6.1 模型文件下载不完整导致加载失败GGUF文件很大下载中断是常事。如果文件不完整llama.cpp加载时会报各种奇怪的错误比如invalid magic或者unexpected EOF。排查方法是检查文件大小是否和仓库标注一致或者用sha256sum校验哈希。我遇到过一次下载到99%中断的情况文件大小差了几十MB但表面看不出来折腾了半天才发现是文件问题。6.2 上下文长度设太大导致内存爆掉上下文长度直接决定KV cache大小。35B模型在4096上下文下KV cache可能占几个GB。如果你把上下文设到32768KV cache能吃掉十几GB内存加上模型本身的20GB32GB内存直接爆。所以上下文长度要按需设置别一上来就拉满。6.3 线程数设成超线程数反而变慢很多人觉得线程越多越快把-t设成逻辑核心数比如20。但实际上CPU推理是计算密集型任务超线程带来的收益很小反而因为缓存竞争导致性能下降。正确做法是设成物理核心数i7-13650HX就是14。我实测-t 14比-t 20快了约15%。6.4 不同量化版本混用导致输出异常有时候你下载了Q4_K_M的模型但用的却是Q5的配置文件或者错误的chat template输出会变得很奇怪比如重复、乱码、不遵循指令。GGUF文件里通常内置了chat template但如果你手动指定了错误的template就会出问题。建议用模型自带的template不要随意覆盖。6.5 显存碎片化导致间歇性OOM这个坑最隐蔽。有时候启动时显存够用但跑了一段时间后突然OOM。原因是显存碎片化或者KV cache动态增长。解决办法是启动时留出至少500MB余量并且定期重启服务。如果是长时间运行的服务建议用llama-server并设置合理的上下文上限。7. 还能怎么优化进阶思路与替代方案7.1 用更小的量化配合更多GPU层如果你能接受Q3_K_M的质量模型体积降到16GB左右这样就能把更多层放到GPU上速度会明显提升。这是一个质量换速度的取舍适合对速度要求高、对质量要求相对宽松的场景。7.2 考虑更小的模型说实话8G显存跑35B模型体验只能算能用谈不上好用。如果你的任务不需要35B级别的能力用7B或13B的模型配合Q5量化速度能到20-30 tokens/s体验好得多。不要为了跑大模型而跑大模型选适合任务的模型才是正道。7.3 内存升级的性价比如果你的主板支持把内存从32GB升到64GB能让你跑更大的上下文或者更高的量化档位。DDR5内存现在价格不算离谱升级内存的性价比比换显卡高得多。我后来把内存升到64GB同样的模型能跑8192上下文了体验提升明显。7.4 替代推理框架的对比除了llama.cpp还有一些框架支持混合推理比如Ollama底层也是llama.cpp、text-generation-webui等。Ollama的优势是安装简单、模型管理方便但参数控制不如llama.cpp细致。如果你不想折腾编译Ollama是个不错的起点。但如果你要精细控制层分配和量化参数还是得用llama.cpp。我在实际使用中的体会是8G显存跑35B模型本质上是在硬件限制下做的一场资源调度游戏。量化决定了模型能不能装下层分配决定了跑得快不快而内存带宽决定了天花板在哪。这套方案能跑通但别期待它有惊艳的速度。如果你的需求是本地实验、离线推理、或者隐私敏感的场景它完全够用如果你要的是高并发、低延迟的生产服务还是老老实实上大显存显卡或者云服务吧。最后分享一个小技巧跑之前先用llama-bench测一下不同-ngl下的速度比盲目试错高效得多。
