“8GB 显存跑 35B 模型”，这话放在任何AI玩家群里，大概率都会被认为是异想天开。论显存，35B 参数光FP16精度就要吃 70GB，8GB 连零头都够不着；论常识，在消费级单卡上跑本地大模型，大家普遍预期也就是 7B 到 14B 的水平。但我还真把这事儿干成了——用一张 RTX 4060 Ti 8GB，配合 64GB 内存，把 Qwen2.5-32B-Instruct 以 Q4_K_M 量化方式完整跑了起来。没有魔改驱动，没有云服务器，纯本地，生成速度大约 3 到 5 tokens/s，相当于一个说话不紧不慢的人在和你打字聊天。这篇文章就是我的完整实测记录，包含量化原理、参数计算、工具选择、避坑手册，手把手告诉你 8GB 显卡到底怎么跑 35B 级别模型，哪些事情能做，哪些事情别指望。
先说结论：这条路的核心不是靠显卡，而是靠量化、CPU 卸载（offload）和内存带宽三者的配合。纯 GPU 推理模型装不下，纯 CPU 推理速度又太折磨人，所以最终方案是把模型的“一部分层”放到显卡上计算，剩下的层交给 CPU 和内存处理。这听起来像是土办法，但实际效果比很多人想象中要好得多。如果你手里正好有一张 8GB 显存的显卡，又不想为跑大模型专门去租服务器，这篇文章应该能帮你省下至少两三个晚上的折腾时间。
1. 为什么 8GB 显存能跑 35B：先搞懂三个核心机制
1.1 量化的本质：拿精度换体积
35B 参数在 FP16 精度下，每个参数占 2 字节，光权重就要 70GB 显存。这是绕不过去的物理限制。但大模型推理并不需要每个参数都精确到小数点后好几位。量化技术的思路简单粗暴：用更少的比特数来表示每个权重值。
以 4-bit 量化为例，每个参数只占 0.5 字节，35GB 参数直接缩到 17.5GB 左右。常用的 Q4_K_M 是在 4-bit 基础上对关键张量做了更精细的分配，实际体积通常比理论值略大一些，Qwen2.5-32B-Instruct 的 Q4_K_M 权重文件大约是 19.6GB。内存还是不够，但已经比 70GB 现实多了。这里的关键认知是：量化不是“把文件压缩再解压”，而是训练后直接以低精度存储和计算，推理时不再还原成 FP16。你可以把它理解成把一张 4K 照片压缩成高质量 JPEG，细节有损失，但肉眼看绝大多数场景根本分不出来。
实测下来，Q4_K_M 量化对 32B 模型的智商影响大约在 5% 以内，复杂代码、数学推理、长文本理解都还能保持相当可观的质量。如果你连 Q4_K_M 都不放心，还有 Q5_K_M 和 Q6_K，体积更大但精度更高，只是 8GB 显存下显然没有这个余量。
1.2 为什么必须 CPU 卸载：装不下就只能“外挂”
量化把体积从 70GB 拉到了 19.6GB，但依然远超 8GB 显存。这时候唯一的办法就是“装不下多少算多少”。大模型推理本质上是逐层计算，Transformer 模型几十层网络按顺序处理输入，第 1 层算完才能算第 2 层。这给了我们一个机会：把前面若干层放进 GPU 算，后面的层放在内存里让 CPU 算，层与层之间通过 PCIe 总线传递中间结果。
The llama.cpp 里对应的参数是--n-gpu-layers（Ollama 里叫num_gpu），控制加载到 GPU 上的层数。以 Qwen2.5-32B 为例，它一共有 64 层 Transformer 层，我实测在 8GB 显存下平衡负载和速度的最佳区间是 20 到 28 层。这意味着 GPU 处理约三分之一到四成的计算量，剩下的交给 CPU。整个过程像是流水线上两个工人接力，一个人速度快但只能接一部分活，另一个人慢但任劳任怨把所有剩下的活都兜住。
1.3 速度瓶颈不在显卡，在内存带宽
很多人第一次跑通之后都会懵：GPU 利用率明明只有 30% 左右，为什么速度还是上不去？答案是每个 token 的计算过程中，模型权重都要从内存搬到 CPU 缓存里算一遍。CPU 推理的性能，几乎完全被内存带宽卡死。你的内存如果是 DDR4 3200MHz 双通道，理论带宽约 50GB/s；如果是 DDR5 4800 双通道，能到 76GB/s。看起来都挺快，但跟 GPU 动辄几百 GB/s 的显存带宽一比，差距就是数量级了。
所以这台机器想跑得舒服，内存带宽是第一优先级。实测同样一颗 CPU，内存从单通道换成双通道，速度直接翻倍。这个话题后面在硬件配置部分会详细展开。
2. 环境准备：硬件、软件与模型选型
2.1 我的实测硬件清单
跑通这套方案的最低配置可以很低，但体验天差地别。我这里列一个“勉强能跑”和“舒服运行”的对照，方便你参考自己手里的机器。
| 硬件 | 勉强能跑 | 我的实测配置 | 备注 |
|---|---|---|---|
| GPU | GTX 1660 6GB | RTX 4060 Ti 8GB | 6GB 也能跑，但层数更少，速度更慢 |
| CPU | 6 核 12 线程 | i5-13490F | 核心数越多，CPU 推理越快 |
| 内存 | 32GB DDR4 | 64GB DDR4 3200 双通道 | 19.6GB 模型 + KV cache + 系统开销，32GB 勉强够 |
| 硬盘 | SATA SSD | NVMe PCIe 4.0 | 首次加载模型速度差异明显 |
特别注意内存容量。Q4_K_M 权重约 19.6GB，加载后还要给上下文（KV cache）留空间，再加上操作系统和其他程序占用，32GB 内存实际只剩约 12GB 可用。上下文长度只要开到 8192，KV cache 就要吃掉好几 GB。我用 64GB 内存，上下文开 16384 也没有压力，这在跑 35B 模型时是决定体验上限的关键。
2.2 软件选型：Ollama 还是 llama.cpp
软件层面有两条路线：一条是开箱即用的 Ollama，另一条是手动控制的 llama.cpp 命令行。
我的建议是：第一轮先用 Ollama 把整个流程跑通，建立“能跑”的信心，再回到 llama.cpp 体验真正的参数控制力。Ollama 本质上是对 llama.cpp 的封装，两者底层推理引擎相同，支持相同的量化格式和 CPU offload 机制。区别在于 Ollama 把你的配置选项压缩成了环境变量和Modelfile，而 llama.cpp 把一切裸露在命令行参数里。
Ollama 安装完成后只有一个命令：ollama run qwen2.5:32b。首次运行会先下载模型文件，之后每次启动就是本地推理。它默认的 num_gpu 参数是 999，意思是“能塞多少层进显存就塞多少层”。这正是我们要的，8GB 显存会自动选择大约 20 到 28 层。如果你的 Ollama 版本行为不一样，可以用环境变量强制指定：
# Linux/macOS OLLAMA_NUM_GPU=24 ollama run qwen2.5:32b # Windows PowerShell $env:OLLAMA_NUM_GPU=24 ollama run qwen2.5:32bllama.cpp 路线则需要编译或下载预编译二进制，然后自己拉量化模型文件，再手工指定参数运行。虽然比 Ollama 多了几步，但那种“每个参数都握在自己手里”的踏实感，折腾过的人都懂。两条路线我会在第四章完整演示。
2.3 模型选型：为什么是 Qwen2.5-32B
35B 这个档位目前最成熟的开源选择就是 Qwen2.5-32B-Instruct。它在代码、数学、中文理解几个维度的综合表现非常均衡，社区适配的量化文件最齐全，推理工具支持也最完善。而它的 GGUF 量化版本参数文件正好卡在“8GB 显存 + 64GB 内存”这台机器可以承受的范围上限附近，多一档量化就装不下，少一档性能又不够用。
32B 和 35B 参数量的差别其实不大，但 30B 以上模型相比 7B 模型的提升是肉眼可见的——复杂任务理解、长上下文保持、指令跟随能力都有明显跨越。实测同一个问题“写一个带状态管理的 Python CLI 工具”，7B 模型给出的代码基本是模板拼接，32B 模型则能考虑到异常处理、参数校验、扩展点设计。这就是为什么一群人明知硬件吃力还要往这个档位上挤的原因。
3. 完整实操：从零到跑通 35B 模型
3.1 第一步：安装 Ollama 并确认版本
Ollama 的安装非常省事。Windows 用户直接在官网下载 exe 安装包；macOS 用户brew install ollama；Linux 用户执行官方一键脚本即可。装完先在终端验证：
ollama --version接下来设置并发和上下文参数。这一步建议在做任何其他操作之前先做好，因为这些参数直接影响显存分配策略。在 Linux/macOS 下：
export OLLAMA_NUM_GPU=24 export OLLAMA_CONTEXT_LENGTH=8192 ollama serveWindows 用户通过系统环境变量对话框设置同名变量，然后重新打开终端。这里我把上下文长度设置在 8192，理由有二：一是 Qwen2.5-32B 支持最大 131072 的上下文，但更长的上下文意味着更大的 KV cache 显存开销；二是 8192 已经能处理大部分日常任务，同时把 KV cache 控制在合理范围，让更多显存留给模型层数。
安装完成后，直接下载并运行模型：
ollama run qwen2.5:32b首次运行会显示一个下载进度条，Q4_K_M 量化文件约 19.6GB，取决于你的网速，可能需要十几分钟到一小时不等。下载完成后会自动加载模型并进入对话模式。
3.2 第二步：检查实际显存占用与层数分配
模型跑起来之后，别急着提问。先看看显存的实际使用情况。Windows 下打开任务管理器，切到“性能”标签页查看 GPU 专用显存；Linux 下执行nvidia-smi。
我第一次跑通时，显存占用显示约 7.1GB，模型加载了 24 层到 GPU，其余 40 层留在 CPU 内存里。为什么不是 8GB 全部用完？因为 NVLink 之外还有 1GB 左右的空间要留给系统显示输出、CUDA 上下文和 KV cache，强行填满会在生成过程中直接爆显存。
如果看到显存占用超过 7.8GB 而且模型开始报错，说明num_gpu设置得太激进了。要缩小层数，就把OLLAMA_NUM_GPU往 16 到 20 调，直到显存稳定在 85% 占用率左右。这是个反复试出来的平衡点，后面我会给一个参考表。
3.3 第三步：llama.cpp 裸跑的完整命令
如果你想脱离 Ollama 自己做精细控制，llama.cpp 路线更直接。我使用官方 release 页面的预编译二进制，下载后解压即可，Windows 用户注意选择带cuda标识的版本。
# 先下载量化模型 # 到 Hugging Face 搜索 Qwen/Qwen2.5-32B-Instruct-GGUF，下载 qwen2.5-32b-instruct-q4_k_m.gguf # 运行推理，参数逐个解释 ./llama-cli \ -m ./qwen2.5-32b-instruct-q4_k_m.gguf \ # 模型路径 -ngl 24 \ # 24 层放 GPU，剩余 40 层 CPU -c 8192 \ # 上下文长度 -n 512 \ # 单次生成最大 token 数 -p "用 Python 写一个快速排序，包含注释和测试用例" \ --temp 0.7 \ --repeat-penalty 1.1这里的参数没有一个是多余的。-ngl决定显存与 CPU 的分工比例，-c决定上下文窗口大小，-n控制生成长度防止跑飞，温度--temp 0.7平衡创造性与稳定性。我把上下文 8192 作为默认值，日常对话和代码生成都够用。
如果你跟我一样有“用显存多一点就快一点”的执念，可以试着把-ngl逐步往上加，每加 2 层重新跑一次测试，记住显存占用率。我实测的对照数据在这里：
| ngl 层数 | 显存占用 | 生成速度 (tokens/s) | 稳定性 |
|---|---|---|---|
| 16 | 5.2GB | 2.0 - 2.8 | 很稳 |
| 24 | 6.9GB | 3.1 - 4.2 | 稳定 |
| 28 | 7.6GB | 3.8 - 5.0 | 偶尔波动 |
| 30 | 7.9GB | 4.3 - 5.5 | 有 OOM 风险 |
看到没有，ngl=30理论速度最快，但显存已经顶到 93%，实际使用中很容易因为上下文长度波动直接爆显存，反而得不偿失。长期使用我推荐 24 层，速度和稳定性得到最佳平衡。
4. 实测数据与性能调优记录
4.1 速度实测：不同任务的真实感受
所有数据都基于ngl=24、上下文 8192、DDR4 3200 双通道的模式。一个非常重要的指标是 tokens/s，它代表每秒生成的字符单位数。中文大约 1.5 个 token 对应一个汉字，所以 4 tokens/s 约等于每秒输出 2.5 个汉字。
以下是我不同任务的实测记录：
| 任务类型 | 首 Token 延迟 | 平均速度 | 整体体验 |
|---|---|---|---|
| 短问答“什么是大模型量化” | 1.8 秒 | 4.1 tokens/s | 可接受 |
| 写一段 200 行 Python 代码 | 3.5 秒 | 3.8 tokens/s | 约 4 分钟等待，可接受 |
| 分析一段 1000 字的长文本 | 12 秒 | 3.2 tokens/s | 等待感明显 |
| 对话上下文超过 6000 token | 20 秒+ | 2.5 tokens/s | 有点折磨 |
首 Token 延迟是最容易被忽视的体验杀手。对话时按下回车，到第一个字蹦出来的等待时间，取决于系统对整段 prompt 进行预处理的速度。prompt 越长、CPU 负责的层数越多，等待越长。当上下文累积到几千 token 后，每次回答前都要重新处理前面所有对话，速度下滑是物理规律，不要指望优化能解决一切。
4.2 调优三板斧：内存带宽、层数分配、上下文节制
第一板斧：双通道内存是硬门槛。如果你现在还是单根 16GB 内存，强烈建议再加一根组双通道。实测同样设置下，单通道 1.8 tokens/s，双通道 3.9 tokens/s，提升 117%，这是全天性价比最高的一个小升级。
第二板斧：控制上下文长度。8192不是越大越好。我跑过一个极端测试，把上下文拉到 32768，显存占用暴增 2.5GB，模型能加载的 GPU 层数直接从 24 掉到 16，整体速度反而下降 45%。如果你的任务不需要长历史，果断保持 4096 或 8192。
第三板斧：根据任务调整-ngl。纯代码生成任务，上下文短时，可以把ngl调到 28 换取更快速度；长文档分析任务，则降到 20 给 KV cache 让路。理论上一套参数跑所有任务，但一个配置微调就能省下班时间，何乐而不为。
4.3 量化等级对比：Q4_K_M 是最优解吗
很多第一次用 GGUF 的朋友会对着文件列表发懵，从 Q2_K 到 Q8_0 十来个版本，到底选哪个。我顺手跑了几组对比：
| 量化版 | 文件大小 | 显存需求 | 相对 FP16 质量 | 速度感受 |
|---|---|---|---|---|
| Q2_K | 11.6GB | 可搭配纯 CPU | 明显下降，逻辑易出错 | 快但蠢 |
| Q3_K_M | 15.1GB | 混合加载 | 可用，复杂任务露馅 | 较快 |
| Q4_K_M | 19.6GB | 24 层 GPU + 内存 | 接近原始，推荐 | 平衡 |
| Q5_K_M | 23.5GB | GPU 层数减少 | 更接近原始 | 更慢 |
| Q6_K | 26.1GB | 几乎全 CPU | 很好 | 慢得没脾气 |
结论很清楚：Q4_K_M 是 8GB 显卡跑 32B 模型的甜点。Q2_K 能更快跑完但智商损失太大，Q5 以上体积膨胀严重，把本来就捉襟见肘的显存分配进一步压榨，速度下滑换来的精度提升根本不值。如果你试过 Q4_K_M 觉得质量不够用，那说明这个需求本身就不该在 8GB 显卡上解决。
5. 常见问题与排查技巧实录
5.1 显存溢出（OOM）问题
报错信息通常是 CUDA out of memory 或者ggml_cuda_allocate_tensor: failed to allocate。核心原因是模型层数加得太多，或者上下文长度设置导致 KV cache 膨胀。排查步骤要按这个顺序走：
- 降低
-ngl，一次降 4 层，重新加载测试。 - 调低上下文长度到 4096，释放 KV cache 占用的显存。
- 检查后台是否还有别的程序占显存，浏览器开一堆标签页也是杀显存的元凶。
- 如果重启后再也没复现，大概率是模型加载时其他程序正好占了显存。
我遇到过一次诡异情况：模型加载占用 6.8GB，运行十分钟稳定，突然某次回答报错 OOM。查了半天发现是浏览器里一个在线视频页面抢走了 1.5GB 显存。所以跑大模型时，能关的软件尽量关掉。
5.2 速度慢到难以忍受怎么办
首先确认内存是不是双通道。wmic memorychip list brief或任务管理器里直接看内存插槽数量，确认两根内存条是否插在对的插槽上（一般主板是 2 和 4 槽）。其次检查后台是否有ollama serve的重复进程。有一次我意外开了两个 Ollama 服务，每个都在抢 CPU 资源，速度直接腰斩。
如果这些都排查完了还是慢，那就要接受现实：8GB 显卡跑 32B 模型的速度天花板就在 5 tokens/s 左右。想要大幅提速，唯一现实选择是换更大的显卡，或者模型换小一档（14B）。这不是软件能解决的问题，是物理定律。
5.3 模型回答质量突然变差
大部分情况是上下文被塞满了。Qwen2.5 支持长上下文，但超出模型实际理解能力之后，回答质量会断崖式下跌。表现是前后矛盾、重复句子、逻辑混乱。解决方案是开启新会话，或者裁剪掉历史中间的冗余对话。日常使用我自己习惯每 10 轮左右手动清理一次上下文。
另一个容易忽视的因素是量化版本。如果你用的是 Q3_K_M 或者更低的量化，某些任务上模型会“智力下降”得非常明显，不是模型的问题，是量化丢精度丢过头了。
5.4 一键速查表
| 症状 | 可能原因 | 解决动作 |
|---|---|---|
| 加载模型报 OOM | ngl 太高或显存被占 | 降 ngl 到 24 以下，关后台程序 |
| 速度只有 1.5 tokens/s | 单通道内存 | 加内存组双通道 |
| 首字等待 30 秒以上 | 上下文过长，CPU 预处理慢 | 清上下文或降-c |
| 生成内容重复 | 上下文溢出或温度太低 | 开新会话，--temp调到 0.8 |
| 模型下载中断 | 网络不稳 | 删除残余文件重试，或换镜像 |
| Ollama 突然无法启动 | 环境变量写错 | 检查OLLAMA_NUM_GPU是否为数字 |
6. 实测体验总结与后续扩展思路
这套“8GB 显卡 + 64GB 内存 + Q4_K_M 量化 + 24 层 GPU offload”的方案，我连续用了两周，日常场景大概覆盖了：代码生成与解释、英语翻译、文章摘要、正则表达式构造、简单的数据分析脚本。这些任务表现都不错，完全达到了“能用的本地大模型”线。但它替代不了 ChatGPT 级别的在线服务——响应速度、上下文长度、多轮对话体验都不在一个量级。
如果是想拿它做知识库问答，可以配合llama-index或dify这类工具，把文档切块后做向量检索再喂给 32B 模型做生成。实测检索问答的效果比单纯用 7B 模型好很多，尤其是在专业领域术语和长段落归纳上。
这个配置后续还有几个可以折腾的方向：一是用ExLlamaV2跑 EXL2 量化版模型，某些场景下能多压几层进显存；二是尝试FlashAttention支持更好的推理引擎，能进一步降低 KV cache 占用；三是等 8GB 显卡从 4060 升级到 5090 之后，这套思路可以直接平移，只是层数能全部塞进显存，速度会有质的飞跃。
最后再分享一个实战小技巧：如果你使用 Ollama，可以写一个 shell 脚本把常用参数封装起来。比如我日常的 run 命令都是这样：
ollama run qwen2.5:32b --keepalive 600 --verbose--keepalive让模型在内存里保持运行 10 分钟，多次对话之间不用反复从硬盘加载。--verbose在生成结束后会打出详细的推理统计，包括速度、显存占用和 KV cache 使用情况，是调优时最直观的数据来源。这两个参数都值得记下来。