手里只有一张 8GB 显存的卡却想把 35B 大模型跑在本地——这个念头很多人都有过但查完显存占用公式基本就放弃了35B 光权重就不是 8GB 能装下的更别提推理时的中间激活和 KV cache。我这几天的实测发现这事儿并没有想象中那么“不可能”而是要用一套完全不同的思路极低比特量化 层卸载offload让显存和内存一起扛。这篇文章就是把整个过程原原本本记录下来包括底层账本怎么算、模型和框架怎么选、每一步怎么跑、实测速度是多少、以及在 Windows 上踩过的所有坑。适合手里只有 RTX 3060 / 3070 / 4060 这类 8GB 消费级显卡、又想在本地部署大模型的人参考。先说结论8GB 跑 35B 是真实可行的只是要接受“能跑但跑得很有风格”——速度在个位数 token/s质量受量化损失影响。这篇文章不会教你把它调成 100 token/s 的幻觉方案只会告诉你真实的边界在哪里。1. 8GB 显存跑 35B 的底层账本权重、量化和层卸载1.1 35B 模型权重到底有多大我先把这个最基础的账算清楚。模型的显存占用第一大头就是权重本身。计算公式很简单显存占用 ≈ 参数量 × 每个参数的存储位数 / 8假设一个 35B 模型FP16也就是每个参数占 2 字节35 × 10^9 × 2 bytes ≈ 70GB也就是说不做任何压缩光权重就需要 70GB 显存。这还没算推理时的 KV cache 和激活值。所以理论上 8GB 显卡跑 35B 的 FP16 原版是绝对不可能的。那量化就是把“每个参数的存储位数”降下来。我用一张表把常见精度对应的权重体积列出来按 35B 参数估算精度每个参数字节数35B 模型权重近似体积FP162 字节约 70GBQ8_K1 字节约 35GBQ4_K_M0.5 字节约 20GBQ3_K_M0.375 字节约 14GBQ2_K0.25 字节约 11GBIQ2_XS约 0.22 字节约 9GB注意这只是权重体积实际加载时还要留出 KV cache、计算图的中间激活等空间。所以 Q4_K_M 的 20GB 虽然看着不大但 8GB 显卡依然装不下。真正能靠近 8GB 门槛的只有 Q2_K / IQ2_XS / IQ3_XXS 这几个极低比特档位。这也是这次实测选型的起点。1.2 量化到 Q2 之后保住的到底是什么很多人一听到 Q2 就摇头觉得“这还能用吗”我的理解是量化确实有损但 LLM 对权重的冗余度比传统模型高得多。K-quant 这类方法不是简单地每个字节砍一刀而是按张量分组每组统计出缩放因子再用较低的比特数表示组内的相对大小。直观理解就是原始权重文件像一张高清照片Q4 是压缩成 JPEG 中等质量Q2 是压成模糊版缩略图——核心轮廓还在但细节会丢。我用 Qwen2.5-32B-Instruct 的 Q2_K 实测下来典型的表现是中文日常问答、文本摘要、翻译能流畅作答逻辑基本在线。需要严谨推理的数学题明显变弱经常在关键步骤上“飘”过去。代码生成简单的函数能写复杂的业务逻辑容易编造不存在的 API。长文本理解偶尔会漏掉中间段落的信息。所以 Q2 的真正定位不是“日常生产主力”而是“在 8GB 显存限制下让 35B 跑起来的入场券”。如果你能接受它的质量折损就有机会体验本地大模型如果不能建议直接看第 4.3 节的质量边界。1.3 最后一公里的解法层卸载offload就算量化到 9-11GB8GB 显存依然装不下。这就轮到 layer offload 登场。llama.cpp 系推理框架Ollama 底层就是用它允许你把 Transformer 的一部分层放在 GPU其余层放在 CPU 内存。启动参数-ngl N或--n-gpu-layers N就是指定放多少层到显卡。比如一个 64 层的模型-ngl 24表示前 24 层在 GPU 上计算剩下 40 层走 CPU。每一层计算完结果通过 PCIe 总线传给下一层可能在 GPU 也可能在 CPU。这样做的代价是速度。GPU 推理快CPU 推理慢而 CPU 推理速度的真正瓶颈不是 CPU 算力而是内存带宽。CPU 要从内存里把权重读一遍才能算完一层所以每生成一个 token必须把 CPU 侧那部分权重完整读取一次。我举个例子32B 模型的 Q2_K 文件约 11GB如果 GPU 放了 20 层CPU 侧大约还剩 7GB 权重。我的机器是 DDR4 3200 双通道实测可用带宽约 40GB/s那么 CPU 侧的理论速度上限就是40GB/s ÷ 7GB ≈ 5.7 token/s再算上激活、KV cache 读写的损耗实际可能只有 3-5 token/s。如果你的内存是 DDR5 或者四通道速度还能再高一点如果是单条内存带宽减半速度会直接腰斩。这也是为什么同是 8GB 显卡不同机器的体验差距可以很大的根本原因。所以“8GB 跑 35B”的真正含义是用极低比特量化把权重压到 10GB 上下再用内存补上放不下的部分最后接受一个个位数的生成速度。2. 实测前的选型模型文件、推理框架和本机配置2.1 我的硬件环境为了让数据有参考价值我先交代清楚测试环境。整个过程中我只用了一张 8GB 显存的显卡显卡RTX 3070 8GB同档的 RTX 4060 / 3060 8GB 结论也适用CPUIntel i5-12400F6 核 12 线程内存32GB DDR4 3200 双通道注意是双通道这个很关键硬盘NVMe SSD模型文件近 11GB机械硬盘加载会慢到怀疑人生系统Windows 11中间为了排查问题切换到 WSL2 对比过为什么强调双通道因为 CPU 推理速度 内存带宽而双通道内存带宽是单通道的两倍。如果你只有单条 16GB 内存跑大模型的体验会非常差强烈建议先加内存条而不是换显卡。2.2 35B 档位里选哪个模型标题里写的是 35B但这其实是个概数市面上这个体量的开源模型有好几个Qwen2.5-32B-Instruct、Yi-34B、Command R 35B、Gemma-2-27B 等。这些模型的量化文件体积接近跑法也一致但体验差异不小。我实测后的选型结论是首选 Qwen2.5-32B-Instruct。原因有三个中文能力在同体量里是第一梯队日常问答、写作、知识库问答都明显好于 Yi-34B。社区的 GGUF 量化版本最全从 Q2_K 到 Q8 都有现成文件不用自己动手量化。Ollama 模型库里有官方的量化标签拉取方便后续接入也简单。如果你要处理英文为主的任务Command R 35B 也可以试试但我测下来它 Q2 化之后退化比 Qwen 更明显所以就不推荐了。另外不要选 MoE 结构的 35B 档模型比如 Mixtral 8x7B它们的推理方式和 dense 模型差别很大8GB 显存跑 MoE 的调度开销更麻烦不在本文讨论范围。2.3 框架怎么选Ollama 还是 llama.cpp现在本地推理框架最主流的两个就是 Ollama 和 llama.cpp 原版。我的建议是先会用 llama.cpp 理解原理日常用 Ollama 图省事。两者底层是同一套推理内核但侧重点完全不同我做了一张对比表对比项llama.cppOllama安装复杂度需要下载 release 或自行编译一键安装自带服务层卸载控制-ngl N参数直接控制环境变量或 Modelfile 参数测速工具自带llama-bench/timer手动计时日志完整度每层显存占用、加载时间都有日志精简排查问题不方便日常使用命令行交互稍显原始自带 API server接入方便这次实测我先用 llama.cpp 因为我要看每层加载时显存的实时占用方便理解 offload 到底在工作跑通之后再用 Ollama 复现配置确认日常使用的可行性。如果你只想快速跑起来直接看 3.3 节从 Ollama 入手也行。3. 完整部署记录从下载 GGUF 到跑出第一句话3.1 下载量化模型文件第一步是拿到模型文件。这里我不会用 Ollama 的拉取命令因为我想让你理解文件本身的来龙去脉。去 Hugging Face 搜索Qwen2.5-32B-Instruct-GGUF认准组织名是 Qwen 官方或者可靠的量化作者一般看下载量和版本记录。文件列表里选择qwen2.5-32b-instruct-q2_K.gguf或者qwen2.5-32b-instruct-iq2_xs.gguf。这两个怎么选我实测的区别是q2_K体积约 11GB速度略快模型表达能力稍微好一点。iq2_xs体积约 9GB更接近 8GB 显存的极限但量化方式更激进中文表达的稳定性略差。我建议第一次测试用q2_K质量稍好卡顿感也没那么强。下载后把文件放到一个纯英文路径下比如D:\models\qwen32-q2.gguf。中文路径在 llama.cpp 的 Windows 版里偶尔会出怪问题不值得为它浪费时间。3.2 用 llama.cpp 启动并验证运行llama.cpp 的 Windows 版本有两种拿法直接在 GitHub releases 页面下载llama-bin-windows-cuda-...zip或者自己编译。我只推荐下载 release 包省事里面已经带了 CUDA 支持前提是你装了 NVIDIA 驱动CUDA 工具链都不用额外装。解压后打开命令行进到目录执行llama-cli -m D:\models\qwen32-q2.gguf -ngl 24 -c 4096 -fa -p 你好请用三句话介绍你自己参数拆解一下-m指定模型文件-ngl 24把前 24 层放到 GPU-c 4096上下文窗口 4096 token-fa开启 Flash Attention能显著降低长上下文的 KV cache 占用量-p输入提示词第一次启动会有一段加载过程日志里会显示每一层被放到 GPU 还是 CPU。看到类似llm_load_tensors: offloading 24 layers to GPU的日志就说明 offload 生效了。等模型加载完可能停顿几秒才开始输出这是 CPU 在预热不用慌。我的机器上-ngl 24时显存占用约 6.5GB内存占用约 8GB生成速度约 4 token/s 左右。这个速度下让它写一篇 150 字的自我介绍大概要等半分钟到一分钟属于“能等但不能急”的状态。3.3 用 Ollama 复现同一套配置Ollama 这边如果你的网络环境和模型库都正常可以试试直接拉量化版本ollama pull qwen2.5:32b-instruct-q2_K但如果你拉不到这个特定标签更稳妥的办法是导入本地 GGUF 文件。写一个ModelfileFROM D:\models\qwen32-q2.gguf然后执行ollama create qwen32-q2 -f Modelfile ollama run qwen32-q2关于层卸载的设置Ollama 在不同版本里控制方式不一样。我实测有效的是两种在运行时敲/set parameter num_gpu 24或者启动服务前设置环境变量OLLAMA_GPU_LAYERS24。如果你的 Ollama 版本对这两个都不敏感那就说明版本太旧或者被其他配置覆盖了这时候我最推荐的方案是——直接用 llama.cpp别在 Ollama 的封装里折腾。Ollama 适合日常用不适合精细调参。4. 实测数据与逐项调优速度、显存、质量的三角拔河4.1 基准测速结果与瓶颈分析我跑了一组不同-ngl参数下的对比数据。测试 prompt 是一段 256 token 的文本生成 128 token 作为测速样本用的是 llama.cpp 自带的llama-benchllama-bench -m D:\models\qwen32-q2.gguf -ngl 20 -p 256 -n 128实测数据如下RTX 3070 8GB DDR4 3200 双通道 32GB 内存ngl 参数显存占用内存占用生成速度0纯 CPU0.3GB约 12GB1.8 token/s103.2GB约 8GB2.6 token/s205.1GB约 6GB3.7 token/s246.5GB约 5GB4.1 token/s287.6GB约 4GB4.5 token/s32显存溢出--明显看到-ngl越高速度越快但收益是递减的。从0到10提升了 0.8 token/s从24到28只提升了 0.4 token/s。原因就是层越多放 GPUCPU 侧剩余权重越少内存带宽压力越小但 GPU 侧数据处理、PCIe 传输的开销也开始出现。所以不是无脑把-ngl拉到最高就好而是要在“不溢出”的前提下尽量高。我的实践值是 24-28再高就可能在上下文稍微拉长时触发显存溢出。这个速度意味着什么以写周报为例一篇 300 字的文本中文一个字大约占 1-1.5 个 token满打满算 500 token4 token/s 就是大约 2 分钟。人读一遍 2 分钟没问题但如果要做多轮对话每轮都等两分钟体验就很折磨。所以 8GB 跑 35B 更适合“一次性生成”的任务而不是高频交互。4.2 把速度拉上去的五个实操调整同样的硬件测速数据是能靠调整往上提一截的。我试过这些方法按效果排序确保内存跑在双通道且频率正确。这是最容易被忽略的。很多人内存买了 3200MHz实际 BIOS 里默认跑 2133MHz带宽直接掉了三分之一。进 BIOS 开 XMP / EXPO把频率拉回标称值CPU 侧推理速度立竿见影。调整-ngl到显存余量 1GB 左右的位置。显存留太满启动时没问题但上下文一增长 KV cache 就会爆。留 1GB 是个安全阈值。开启 Flash Attention-fa。它主要解决 KV cache 的显存占用问题对速度也有小幅帮助。上下文 4096 时能省下 1GB 左右的显存相当于多放几层到 GPU。控制上下文长度。-c 8192比-c 4096的 KV cache 占用大一倍对 8GB 显存来说压力很大。日常使用建议 4096 就够除非你明确要做超长文档分析。关掉后台占显存的程序。浏览器开一堆标签页可能吃掉 500MB-1GB 显存如果开启了 GPU 加速加上微信、直播软件这些8GB 卡实际可用可能只有 6GB。跑模型前检查任务管理器把不用的全退掉。这样一轮调下来同样的模型在我的机器上从默认的 3.5 token/s 提到了 4.5 token/s提升大概 25%。虽然没有质变但已经接近这套硬件方案的物理上限了。4.3 Q2 质量到底能不能用几个任务实测速度是一回事质量是另一回事。我用 Qwen2.5-32B 的 Q2_K 实测了几类典型任务结论比较明确中文文案润色基本可用。改写通顺度尚可但偶尔会出现用词”飘“的情况比如把“虽然”写成“尽管”发现上下文不一致。1000 字以内的文档摘要可用。能抓住要点但细节丢失比 Q4 明显重要数字偶尔会记错。英文翻译质量中等偏上。简单句子没问题长句的语序会偏直译。Python 代码生成写 50 行以内的独立函数还行项目级代码明显不行。逻辑推理如数学应用题不行。Q2 化之后推理链条很容易断这是我放弃用它做复杂推理任务的主要原因。如果换成 Q4_K_M需要 20GB 显存上面这些任务的质量会有质的提升但 8GB 显卡跑不了。所以结论是8GB 跑 35B 适合“文本理解类”任务而不是“推理生成类”任务。这个边界要心里有数别拿它的短板去跟在线 API 比要比的是“能不能在完全离线的环境里完成基础任务”。5. 踩坑记录反复折腾里最折磨人的几个问题5.1 显存溢出但问题不在显存测试中我遇到过最诡异的现象-ngl 28时启动正常生成到第 300 个 token 突然报CUDA out of memory。一开始我以为模型权重占用估算错了后来用 nvidia-smi 盯实时显存才发现随着生成进行KV cache 在持续增长到了某个点就把最后 200MB 显存吃掉了。这不是权重放不下的问题而是我没给 KV cache 留够余量。解决方案有两个一是把-ngl降一档二是把上下文从 8192 降到 4096。这里我学到的一个实用技巧是如果只是长对话中途崩用/clear清一下上下文历史就能继续不用重启整个模型。5.2 上下文一拉长内存先爆炸8GB 显存的机器通常配 32GB 内存但你做长文档分析时可能会发现内存先顶不住。32B 模型的 KV cache 大约每 1000 token 占用 0.2-0.5GB取决于是否开启 GQA 和 Flash Attention8K 上下文就要 2-4GB。如果你同时开了多轮对话保留历史内存占用会更快上涨。我的建议是跑 35B 档的模型时内存低于 32GB 真的不建议开超过 4096 的上下文。我试过 16GB 内存跑这个模型加载完权重加 KV cache 后系统直接开始疯狂读写页面文件速度掉到 0.5 token/s基本等于死机。如果你要长上下文优先加内存条而不是调参数硬抗。5.3 Windows 下的显存碎片化同样的参数在 Windows 原生跑和在 WSL2 里跑显存占用可能差 0.5-1GB。原因是 Windows 图形栈DWM、浏览器硬件加速等会占用一部分显存而且驱动分配显存时碎片化更严重。如果你跟我一样在 Windows 上折腾半天-ngl上不去可以试试把 llama.cpp 放到 WSL2 里跑同样的-ngl往往能多塞几层进去。这里分享一个排查命令生成过程中开一个watch -n 0.5 nvidia-smiWSL 里实时看显存曲线比盯着日志盲猜有效得多。5.4 关于“解除限制词”的正确打开方式网上很多人在搜索“本地部署大模型怎么解除限制词”我在本地跑了大模型之后更加确认不要在这个方向上花时间。本地模型同样包含安全对齐机制这是底线不是可调参数。如果觉得模型回答太保守正确的做法是换能力更强的模型、把 prompt 写得更加具体或者用合规数据做微调而不是去找各种绕过模板。微调时注意保留安全审核环节别把护栏一并剪掉。这个边界守住本地模型用起来才算踏实。6. 8GB 跑 35B 到底值不值得我的最终结论6.1 什么场景下这笔投入算“值”我跑完这一整套实验后认为下面的几个场景是非常值得的内网/离线环境公司内网完全不连外网API 不可用这时候能跑起来比跑多快重要得多。4 token/s 慢是慢但至少有一个私有化的大模型能用。本地知识库问答配合 RAG 检索先把文档召回再让模型基于片段做摘要和回答。这个场景对生成速度不敏感因为用户本来就要读结果等 1-2 分钟可以接受。隐私敏感数据文档不出门模型只做理解Q2 的损失换来数据不出本机在意的用户觉得很值。纯粹想理解大模型推理机制8GB 跑 35B 会让你对显存、内存带宽、量化、KV cache 这些概念有极其直观的感受比看十篇文章都管用。6.2 什么场景建议直接放弃反过来如果目标是下面这些事我不建议你折腾这条路高频对话客服机器人每轮回答等半分钟用户早就跑了。严肃的代码生成和审查Q2 化之后代码幻觉率偏高反而增加排查成本。追求质量下限的场景你的 prompt 本身很复杂、对输出精准度要求高用 Q2 等于自讨苦吃。可用 API 且无隐私顾虑的场景哪怕付费 API 的跑分更高、速度更快就按性价比做决策。本地跑不是图腾而是手段。6.3 如果还想往上走两条现实升级路径如果你体验完 8GB 跑 35B觉得思路可行但硬件受限我建议按性价比排序考虑先加内存把 32GB 升级到 64GBCPU 侧瓶颈缓解可以尝试跑 Q4 量化并 offload 更多层到 CPU或者直接尝试 70B 模型的 Q2 版本纯 CPU 内存足够的情况下也可以跑速度约 1-2 token/s。这是最省钱的方向。换一张 16GB 显存的卡例如 RTX 4080 / 4090D 二手或者 RTX 5070 Ti。16GB 可以完整吃下 35B 的 Q4_K_M速度和质量都会上一个台阶日常问答基本可用了。这一步一步升级的过程中你会发现本地大模型的体验瓶颈从来不是某一个硬件而是“显存、内存带宽、量化质量”这三者的平衡。8GB 跑 35B 只是把这种平衡推到极限状态的一次实验它让你清楚地知道每一块硬件的短板在哪里——这也是我觉得这次折腾最值的地方。跑通的那一刻挺有成就感但别把这套配置当日常主力它是理解推理原理的极好跳板而不是终点。