先坦白讲，刚看到“8GB 跑 35B”这个标题的时候，我第一反应是“又要看标题党了”。毕竟按常识算，35B 参数模型哪怕是 4bit 量化，光权重就要 18GB 左右，8GB 显存的卡连一半都装不下。但实测做完之后，我得承认：这事不是不能干，只是很多人不知道路该怎么走。这篇实录就是把我从选模型、调参数、测速度到踩坑排错的全过程写下来，给同样只有消费级显卡、又想在本机跑大模型的人一个可以直接抄作业的参考。
先说结论：8GB 显存的 N 卡（3060/4060/2060S 这类）确实能跑 35B 级别的大模型，但前提是接受一个事实——它不是“显卡在跑”，而是“显卡帮你加速，CPU 和内存一起扛”。速度不会像云端 API 那样流畅，不过在代码补全、文本续写、知识问答这些场景下，体验已经能用。
下面我把整个实测过程尽量拆细，从底层原理讲到具体命令，再到我踩过的几个坑。如果你手里正好有一台 8GB 显存的机器，建议按顺序看完再动手。
1. 先算笔账：35B 模型到底吃多少资源
1.1 显存占用不是只算权重
很多人以为“模型 35B，那就把 35B 参数全部塞进显存”，这个理解在大模型场景下是有偏差的。35B 指的是参数量，但实际运行时的显存占用由三部分决定：权重、KV Cache、激活值。
- 权重：FP16 精度下，一个参数占 2 字节，35B 参数 = 70GB。这是绝对装不下的。
- 量化权重：4bit 量化（如 Q4_K_M）后一个参数约 0.5 字节，35B 参数 ≈ 18GB。Vulkan/CUDA 加载时还要做反量化，但显存占用量级就是这个数。
- KV Cache：对话长度越长，占的显存越多。8GB 显存想完整跑 2048 上下文，KV Cache 可能吃掉 1~2GB。
- 激活值：推理过程中间产生的张量，和 batch size、序列长度相关，通常也要几百 MB 到几 GB。
所以即便用 4bit 量化，把完整的 35B 模型塞进 8GB 显存也是无解的。这也是为什么一开始很多人都说“不可能”。
真正能跑起来的思路叫层卸载（Layer Offload）：模型还是完整加载，但只有一部分 Transformer 层放进 GPU，其余层留在 CPU 内存里。GPU 负责计算它有的那部分层，CPU 计算剩下的层。每一层计算完之后，把中间结果传回 GPU 或内存继续下一层。显存不够？那就少放几层给 GPU，剩下的让 CPU 硬算。速度慢，但能跑。
1.2 CPU+GPU 混合推理的实际开销
这个方案的核心瓶颈在两个地方：内存带宽和PCIe 传输带宽。
CPU 推理大模型，算力其实不是最缺的，最缺的是内存带宽。35B 的 Q4_K_M 量化版大概是 19~20GB，每生成一个 token，理论上要遍历一遍全部参数（准确说是它涉及的那部分层），也就是要从系统内存里读约 20GB 数据。如果你的内存是双通道 DDR4-3200，带宽大概 50GB/s，那纯 CPU 推理速度上限就是 2~3 token/s 左右。如果是老平台单通道或低频内存，速度会掉到 1 token/s 以下。
如果一部分层放在 GPU 里，那么每层计算时，数据在 GPU 显存和 CPU 内存之间有个交接。层卸载的数量越多，PCIe 传输就越频繁，因为 GPU 算完的中间结果要传回去给 CPU 处理下一层，反之亦然。所以这里有个很有意思的现象：卸载太多层，GPU 算得快，但 PCIe 传输增多；卸载太少层，CPU 直接成为瓶颈。最终速度取决于两者之间的平衡点，而不只是“GPU 越强越好”。
8GB 显存的卡，在 35B 模型场景里，通常 GPU 只能放 14~20 层（取决于模型总层数和量化精度），剩余 20~30 层留在 CPU。实测下来，速度大约在 1.5~3 token/s，和看电子书类似——不快，但确实能跑。
2. 准备阶段：模型选型与部署工具
2.1 “35B 档位”到底有哪些模型可选
严格说，市面上正好 35B 参数的模型不多，但我们常说的“35B 档位”通常指 32B~34B 这个区间。我在实测中主要试了两个系列。
Qwen2.5-32B-Instruct：通义千问 2.5 的 32B 版本，指令跟随能力很扎实，中文语境下表现明显比同档位国外模型好。32B 参数量，Q4_K_M 量化后文件约 19GB，和“35B”口径基本一致。
Yi-34B-Chat：零一万物出的 34B 模型，早期 01.AI 开源版本，英文和代码能力不错，中文水平也在线。Q4_K_M 量化后也是 19~20GB。
另外还有 CodeQwen1.5-34B、DeepSeek-Coder-33B 这类代码向模型，如果主要用途是代码补全和解释，也可以看这个方向。
我建议普通用户优先 Qwen2.5-32B。原因有两点：一是模型文档和社区讨论最丰富，遇到问题容易搜到；二是它在 CPU 推理场景下做了不少优化，运行时的实际表现比理论值略好一点。
2.2 量化等级怎么选：别盲目上最低精度
GGUF 格式的量化等级对显存和内存的占用影响非常大，常见的几个等级是：
| 量化格式 | 近似单参数占用 | 32B 模型约占用 | 速度影响 | 质量影响 |
|---|---|---|---|---|
| Q8_0 | 1 字节 | 34GB | 慢 | 几乎无损 |
| Q6_K | 0.75 字节 | 25GB | 中等 | 很少损失 |
| Q5_K_M | 0.65 字节 | 22GB | 中等 | 少量损失 |
| Q4_K_M | 0.55 字节 | 19GB | 较快 | 可接受 |
| Q3_K_M | 0.4 字节 | 15GB | 较快 | 较明显损失 |
| Q2_K | 0.3 字节 | 12GB | 最快 | 明显损失 |
8GB 显存 + 32GB 内存的组合，正常情况下我应该推荐 Q4_K_M，这是质量和体积最平衡的点。但如果你的内存只有 16GB，Q4_K_M 的 19GB 文件加上运行时开销会冒风险，这时候退到 Q3_K_M 是更稳的选择。我自己实测时特意对比过 Q4_K_M 和 Q3_K_M 的输出质量，在知识问答场景下，Q3_K_M 的答案偶尔会缺失关键实体，这种损失在正式使用时很影响体验。
注意：量化等级不是越低越好。Q2_K 虽然只要 12GB 文件，但生成内容的随机性和重复度明显上升，甚至会频繁输出不存在的词。如果机器实在带不动，宁可换小一号的模型（比如 14B），也别硬上低质量量化。
2.3 部署工具：Ollama 与 llama.cpp 的分工
这次实测我用了两套工具：
Ollama：胜在简单，安装完就是一条命令拉模型、一条命令跑起来，自带 OpenAI 兼容接口，后续接 AnythingLLM、Open WebUI 这类前端非常方便。但它对“精确控制哪几层放 GPU”这种需求支持得比较隐蔽，需要靠 Modelfile 传参数。
llama.cpp 的 llama-server：更接近底层，启动时可以显式指定--n-gpu-layers，也就是一次告诉我“GPU 里放多少层”。调试性能问题时，它能带日志输出详细时间分布，方便确认瓶颈到底在 GPU 还是 CPU。缺点是编译和使用门槛略高。
如果你完全没接触过这两个工具，先装 Ollama。等后面想深挖性能，再装 llama.cpp 做精细调优。两者共用 GGUF 格式的模型，文件可以复用，不冲突。
3. 完整实操记录：从安装到跑通对话
3.1 环境信息
先交代我这次实测的硬件环境：
- CPU：i5-12400（6 核 12 线程）
- 内存：32GB DDR4-3200 双通道
- 显卡：RTX 3060 8GB，驱动 551.86
- 系统：Windows 11 22H2
- Ollama 版本：0.5.7
- llama.cpp 版本：b3985（Vulkan 版本我也顺手测了，后面说）
这套配置在消费级里偏入门，显卡性能不算强，但很能代表大多数想“白嫖”本地大模型的用户现状。
3.2 安装 Ollama 与模型拉取
Ollama 的 Windows 安装包直接去官网下载，安装完后建议做两件事：
第一，把模型存放路径改到非系统盘。默认会放在C:\Users\用户名\.ollama\models，如果 C 盘剩余空间不充裕，一个 20GB 的模型很容易塞爆系统盘。修改方式是设置环境变量OLLAMA_MODELS，指向你希望存放模型的目录，比如D:\ollama_models，然后重启 Ollama。
第二，确认一下 Ollama 的版本，旧版本对 GGUF 模型的支持有差异，实测中发现 0.5.7 的表现比之前的 0.3.x 明显更好。
拉取模型时，注意指定量化标签：
ollama pull qwen2.5:32b-instruct-q4_K_M如果不带后面的-q4_K_M，Ollama 会默认拉取一个体积更大的版本，可能是 Q8 甚至 F16，这对 8GB 显存的机器非常不友好。所以建议每次都用完整标签明确指定量化等级。
拉取完成后，可以直接试运行：
ollama run qwen2.5:32b-instruct-q4_K_M这时候如果你打开任务管理器，会看到显存占用冲高到 6~8GB，同时内存占用也有十几个 GB。因为 Ollama 默认会尽量把所有层都往 GPU 塞，塞不下的才留给 CPU。在 8GB 显存下，它通常会尝试 30 多层全放，然后被系统硬塞回一部分。这个过程可能会导致首次运行卡顿几分钟，因为系统在做内存分配和权重重新布局。
3.3 明确指定 GPU 层数：用 Modelfile 精确控制
Ollama 默认的行为是“尽量多放 GPU”，但在 8GB 显存跑 35B 这个场景下，这个默认策略并不智能。它会显示基于预算进行调整，但实际推理时因为显存溢出或换页，速度反而更慢，甚至报CUDA out of memory。
更可控的做法是：给这个模型写一个 Modelfile，明确指定 GPU 层数。
先拉一个基础模型，然后创建 Modelfile：
FROM qwen2.5:32b-instruct-q4_K_M PARAMETER num_gpu 16 PARAMETER num_ctx 2048这里num_gpu就是告诉 Ollama“最多在 GPU 里放 16 层”。为什么选 16 层而不是 20 层？我是根据显存实际占用反推的：Q4_K_M 的 32B 模型，每层权重约 0.5GB，16 层大约占 8GB，但还要给 KV Cache 留出余量，所以保险起见选 16。如果你把num_gpu调到 20 层，显存会吃到 9~10GB，8GB 的卡直接溢出。
创建完 Modelfile 后，用下面命令生成一个自定义模型并运行：
ollama create qwen32b-8g -f Modelfile ollama run qwen32b-8g这样跑起来之后，GPU 里装 16 层，剩余的 24 层（Qwen2.5-32B 总层数约 40 层左右）由 CPU 计算。这时候打开任务管理器，显存占用会稳定在 6~7GB，内存占用 20GB 左右，不会再出现反复换页的卡顿。
3.4 实测速度与输出质量
我用同一个问题跑了三组配置，分别是：默认全自动分配、固定 GPU 16 层、以及固定 GPU 24 层（大部分层在 GPU）。测试问题是一个中等难度的中文知识题：“用 500 字解释什么是梯度消失，并给出两种缓解方法。”
| 配置 | 显存占用 | 速度（token/s） | 首次响应 | 输出情况 |
|---|---|---|---|---|
| Ollama 默认 | 7.2GB | 1.8~2.2 | 约 12 秒 | 正常 |
| GPU 16 层 | 6.8GB | 2.5~3.0 | 约 8 秒 | 正常 |
| GPU 24 层 | 8.1GB 溢出 | 卡死 | >30 秒 | 未生成 |
数据说明一件事：在 8GB 显存上，盲目多放层并不会更快，甚至会因为显存溢出导致直接失败。16 层的速度明显比默认好，主要原因是显存里有了足够的 KV Cache 余量，推理不必频繁做内存回收。
速度 3 token/s 大概什么概念？生成 500 字的答案需要约 170 秒，等得比较辛苦，适合边干别的边等结果。但如果只是做单轮问答，或者配合外部知识库做检索问答，这个速度能接受。
我还对比了 Q3_K_M 量化的速度，同样 16 层，能跑到 3.5 token/s 左右，但输出质量下降得比较明显，所以后续测试我都固定用 Q4_K_M。
4. 调优方向与问题排查实录
4.1 提升速度的四个方向
如果你的实测速度比我的还低，按优先级从高到低检查这几项：
内存频率与双通道：CPU 推理 35B 模型时，内存带宽就是生命线。单通道内存和双通道内存的速度差距可能是 40% 以上。如果你用的是单根 16GB 内存条，强烈建议再加一根组成双通道。注意两根容量最好一致，频率也要对齐，否则系统会自动降到最低频率。
LLM 的线程数设置：Ollama 默认会用满所有 CPU 线程，但有时候反而因为超线程导致缓存争抢。你可以试试限制线程数，比如在 Modelfile 里加PARAMETER num_thread 8（对应 6 核 12 线程的一半），实测某些平台上限到物理核心数反而更快。
Prompt 长度：35B 模型的 KV Cache 开销很大，上下文越长，每生成一个 token 需要处理的历史信息越多。如果只是做问答，把num_ctx从默认 4096 降到 2048，首次响应会快不少，内存压力也小。
关闭其他显存占用程序：浏览器硬件加速、视频渲染、甚至 Discord 的某些特效都会占显存。8GB 的卡本来就捉襟见肘，跑推理之前先关掉这些。我的实测环境中，Chrome 开 10 个标签页能吃掉 1.5GB 显存，直接影响层卸载数量。
4.2 遇到过的三个典型问题
问题一：启动时报 “unable to allocate memory”
这个报错基本就是显存或内存不够了。排查思路：打开任务管理器看内存是否还有余量；看显存占用是不是被其他程序占了。如果内存只剩 4~6GB，而模型文件要 19GB，那基本没法跑。这时候要么关程序，要么换 Q3_K_M 量化版本的模型。
问题二：推理过程中速度忽快忽慢，甚至像死机一样停几秒
这是典型的显存溢出触发了系统换页。Windows 会把一部分显存数据换到内存，然后再换回来，这个过程非常痛苦。解决办法就是减少num_gpu层数，给 KV Cache 留出余量。我遇到过一次，把层数从 20 降到 16 之后立刻消失。
问题三：输出的中文有乱码或重复句子
这个分两种情况。如果使用 Ollama 默认的 API 接口，很可能是上下文窗口不足导致模型“忘了前面说了什么”，开始复读。把num_ctx适当调大一些就行。如果换 Q2_K 量化的模型出现这个问题，那就是量化损失太重了，模型输出概率分布已经被破坏，没法通过调参解决，只能换回质量更高的量化等级。
4.3 反复试出来的避坑细节
- 不要用 Vulkan 版本跑 8GB 显存。我在 llama.cpp 的 Vulkan 后端也试过，Vulkan 在内存在 Windows 上的分配方式比较激进，很容易吃满显存后黑屏或崩溃。CUDA 版本稳得多。如果只能用 A 卡，建议至少 12GB 显存再考虑 35B 模型。
- 不要在机械硬盘上放模型文件。20GB 的模型，第一次加载时要全部读进内存。如果放机械硬盘，加载时间可能长达 5~10 分钟，而固态硬盘只要 20 秒左右。
- Ollama 后台服务默认开机自启，如果你不玩的时候不想白白占内存，在任务管理器里把 “Ollama” 的启动项关掉。否则每次开机它都会常驻，白吃几个 GB 内存。
5. 硬件的下一步：要不要升级
如果看完上面的实测，你发现自己真的需要更流畅的体验，我给的直接建议是“先别急着换显卡”。因为 35B 模型在这个场景的瓶颈是 CPU 内存带宽，显卡显存再大也只能覆盖一部分。
真正值得做的事是：把内存从单通道改成双通道，或者把内存频率往上提一档。DDR4-2666 换成 DDR4-3600，速度提升甚至比换显卡还明显。反过来，如果把 3060 8GB 换成 4060 Ti 16GB，也就是 GPU 能多卸几层，速度确实会提升，但 CPU 部分依旧是瓶颈，并不会突然变成“秒出”。
所以我的建议是：先按文章里的方法把现有配置调最优，把 Modelfile 的参数吃透，再决定要不要升级。对于大多数“尝鲜”和“本地知识库”用途，8GB 显存 + 32GB 内存的组合已经足够玩起来了。
如果你打算长期跑本地大模型，优先考虑 16GB 显存的卡，比如 4060 Ti 16GB 或者 4070 Ti Super。16GB 显存配合 32GB 内存，Q4_K_M 的 35B 模型可以把一半以上的层放 GPU，速度能到 6~8 token/s，体验会好很多。
我在实际测试中最意外的一个收获是：调低 GPU 层数之后，虽然显存占得少了，但整体系统的稳定性提高了不少。以前默认配置跑半小时左右，偶尔会崩一次，自定义 Modelfile 固定层数之后跑了一下午都没出问题。如果你也想尝试 8GB 显存跑 35B，第一步不是去调出更高速度，而是先让你的程序稳定跑起来不被 OOM，再考虑 layer 数量和速度之间的平衡。这个顺序我觉得比什么都重要。
