本文最后更新于 2026-05-27，文章内容可能已经过时。

8G显存跑35B大模型：我测了三天，结果出乎意料

想象一下这个画面：一台配着RTX 3070的普通游戏机，屏幕上正在流式输出一个35B参数大模型的回答。

你的第一反应可能是"这是P的吧"。

我第一次看到这个场景时也这么想。但这是真的——得益于 llama.cpp 的量化技术，这件事在2024年已经成为普通人触手可及的现实。不过，在你兴冲冲地去下载模型之前，有几个关键问题你必须先搞清楚：速度有多慢？效果打几折？值不值得折腾？

我花了三天时间，用一台RTX 3070 8G的机器做了系统性测试，把数据和坑都给你摆出来。

---

打破认知：8G显存真的能跑35B？

先解释一下这件事为什么"反直觉"。

按照朴素的理解，35B参数的模型，每个参数用FP16（16位浮点数）存储，理论显存需求是 35 × 2 = 70GB。RTX 3070只有8GB显存，连零头都不够。

关键就在于量化（Quantization）。

量化的本质是用更低精度的数据格式来存储模型权重。llama.cpp 支持多种量化格式，其中最常用的几种：

| 量化格式 | 每参数比特数 | 35B模型体积 | 所需显存（约） | 效果损失 | | FP16（原始） | 16 bit | ~70 GB | 75 GB+ | 无损基准 | | Q8_0 | 8 bit | ~35 GB | 38 GB+ | 极低 | | Q4_K_M | 4.5 bit | ~20 GB | 22 GB+ | 低 | | Q3_K_S | 3.5 bit | ~15 GB | 17 GB+ | 中 | | Q2_K | 2.6 bit | ~12 GB | 13 GB+ | 较高 |

⚠️ 等等，22GB的Q4_K_M怎么塞进8G显存？

答案是：CPU+GPU混合推理（Partial Offloading）。

llama.cpp 允许你把模型的一部分层（Layer）卸载到GPU，其余层留在内存（RAM）里用CPU计算。8G显存大约能装下35B Q4_K_M模型的15-20层，其余40+层跑在内存里。代价是速度会显著下降——但"能跑"这件事本身已经成立了。

---

实测环境与跑分数据

测试配置

CPU：Intel Core i7-12700K
内存：32GB DDR4 3200MHz
GPU：NVIDIA RTX 3070 8GB VRAM
存储：Samsung 980 Pro NVMe SSD
系统：Ubuntu 22.04 LTS
llama.cpp：最新编译版（CUDA 12.1）
测试模型：Qwen2.5-32B（接近35B规格）

注：32B和35B在量化后的显存占用差异约在1-2GB以内，测试结论对35B模型同样适用。

三种量化精度的实测数据

我分别测试了Q8_0、Q4_K_M、Q3_K_S三种精度，每种测试5次取平均值。

GPU层数设置：-ngl 20（20层卸载到GPU） | 量化格式 | 模型文件大小 | GPU显存占用 | 内存占用 | 首Token延迟 | 生成速度（token/s） | | Q8_0 | ~34 GB | 7.8 GB | 28 GB+ | ~8s | 约3-4 | | Q4_K_M | ~19 GB | 7.6 GB | 14 GB+ | ~5s | 约6-8 | | Q3_K_S | ~14 GB | 7.4 GB | 9 GB+ | ~4s | 约8-10 |

几个关键发现：

1. Q8_0在8G显存下几乎跑不动：32GB内存在测试中接近上限，系统频繁swap，速度掉到3 token/s以下，体验极差。

2. Q4_K_M是甜蜜点：6-8 token/s的速度勉强可用，等一段时间能看到完整回答。

3. Q3_K_S最快但效果有明显下降（后文详述）。

💡 6-8 token/s是什么概念？正常人阅读速度大约是5-8 token/s，所以你的眼睛基本能跟上输出速度，但一旦遇到长文生成，等待感会很明显。

---

效果到底打几折？量化损失实测

这是全文最核心的部分，也是大多数同类文章刻意回避的地方。

我选了三个典型场景做对比，使用完全相同的Prompt，对比Q4_K_M量化版与云端全精度版（通过API调用）的输出差异。

场景一：中文写作（议论文开头）

Prompt： 请写一段关于"人工智能是否会取代人类创造力"的议论文开头，要求有文采，200字左右。 Q4_K_M本地版输出：

当AlphaGo的棋子落定，当ChatGPT的文字涌现，人们开始惶惶然追问：创造力，这一人类引以为傲的精神火种，是否终将在算法的洪流中熄灭？答案或许并不悲观。创造力的本质不在于信息的排列组合，而在于对意义的追问与对美的感知……

全精度云端版输出：

当第一行代码生成出令人动容的诗句，当神经网络描绘出超越大师的画作，一个古老的命题再度浮出水面……

结论： 中文写作场景，Q4量化几乎无损。两个版本的文采和逻辑结构相当，普通用户很难区分。✅

---

场景二：代码生成（Python算法题）

Prompt： 用Python实现一个LRU缓存，要求线程安全，给出完整代码和注释。 Q4_K_M本地版： 生成了基本可用的实现，使用了threading.Lock，但注释较简略，且在边界条件处理上有一个细节遗漏（capacity=0时的行为未定义）。 全精度云端版： 代码更完整，包含了完善的边界处理、详细注释和使用示例。 结论： 代码生成场景，Q4量化有轻微损失，体现在细节完整性上。对于日常编程辅助够用，但用于生产代码需要人工复查。⚠️

---

场景三：逻辑推理（数学应用题）

Prompt：

一个水池有两个注水管和一个排水管。A管单独注满需6小时，B管单独注满需4小时，排水管单独排空需3小时。三管同时开，几小时能注满？

Q4_K_M本地版： 给出了错误答案，推理过程出现了分数计算错误。 全精度云端版： 正确计算出答案（12小时），推理步骤清晰。 结论： 逻辑推理和数学计算场景，Q4量化有明显损失，不建议依赖本地量化模型处理精确计算任务。❌

---

量化损失总结

---

从零到跑通：安装配置避坑指南

编译安装（以Linux/Ubuntu为例）

# 1. 克隆仓库
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

2. 编译（含CUDA支持）
GGML_CUDA=1 开启GPU加速，必须安装CUDA 11.8+
make GGML_CUDA=1 -j$(nproc)

如果编译报错找不到cuda，指定路径：
CUDA_PATH=/usr/local/cuda make GGML_CUDA=1 -j$(nproc)

Windows用户

# 推荐直接下载预编译版本
前往 https://github.com/ggerganov/llama.cpp/releases
下载 llama-*-bin-win-cuda-cu12.1-x64.zip
解压后直接使用，无需编译

模型下载（国内用户重点看这里）

# 方法一：HuggingFace直连（经常超时）
huggingface-cli download Qwen/Qwen2.5-32B-Instruct-GGUF

方法二：使用镜像站（推荐国内用户）
export HF_ENDPOINT=https://hf-mirror.com
huggingface-cli download Qwen/Qwen2.5-32B-Instruct-GGUF \
--include "qwen2.5-32b-instruct-q4_k_m*.gguf"

方法三：modelscope（魔搭，最稳定）
pip install modelscope
modelscope download --model qwen/Qwen2.5-32B-Instruct-GGUF

⚠️ 最常见的坑： GGUF文件经常被拆分成多个分片（如-00001-of-00005.gguf），必须全部下载完才能使用，缺一不可。

启动推理

# 基础启动命令（含参数注释）
./llama-cli \
-m ./models/qwen2.5-32b-instruct-q4_k_m.gguf \  # 模型路径
-ngl 20 \          # 卸载到GPU的层数（8G显存建议15-22）
-c 4096 \          # 上下文长度（越大越耗显存）
--temp 0.7 \       # 温度（创意写作用0.7-0.9，推理用0.1-0.3）
-n 512 \           # 最大生成token数
-p "你好，请介绍一下自己" \  # Prompt
--color            # 彩色输出

macOS用户（Metal加速）

# macOS自动使用Metal，无需额外配置
编译时不需要CUDA flag
make -j$(sysctl -n hw.ncpu)

M系列芯片统一内存，可以跑更大模型
M2 Pro 16GB可以流畅跑Q4_K_M的13B，Q4_K_M的32B也能跑但较慢

完整耗时参考（32G内存 + 100Mbps网络）

| 阶段 | 耗时 | | llama.cpp编译 | 约5-8分钟 | | Q4_K_M 32B模型下载（19GB） | 约30-50分钟（镜像站） | | 模型首次加载 | 约20-40秒 | | 首Token输出 | 约4-6秒 | | 从零到第一个字 | 约1-1.5小时 |

---

本地部署 vs 云端API：你真正需要哪个？

说完了怎么跑，来聊聊要不要跑这个更重要的问题。

本地部署的真实优势

隐私保护：数据不出本地，适合处理敏感文档、公司内部资料
无网络依赖：断网也能用，适合特定场景
长期零边际成本：一次折腾，后续使用不花钱
极客满足感：真的，这个不是玩笑，能跑起来那一刻确实很爽

本地部署的真实代价

速度：6-8 token/s vs 云端的50-100+ token/s，差距是数量级的
效果有损：Q4量化的35B，综合效果大约等于云端全精度的13B
折腾成本：从零到跑通，顺利的话1-2小时，踩坑的话一个下午起步
硬件门槛：32GB内存是基本要求，内存不够会频繁swap甚至崩溃
更新成本：模型迭代快，每次换新模型又要重新下载十几GB

核心结论：本地部署最大的代价是速度和精度的双重妥协。

Q4量化的35B，实际效果大约等于云端全精度的13B。如果你的需求是日常高频使用、对输出质量有要求，折腾本地部署的性价比其实并不高。

对于效果优先的用户，直接调用云端API是更理性的选择。[api.884819.xyz](https://api.884819.xyz) 聚合了主流大模型的API接口，包括GPT系列、Claude、Deepseek、通义千问等，按量计费、无需部署。国产模型（Deepseek/千问等）完全免费，新用户注册即送体验token，首次使用成本甚至低于你折腾llama.cpp花掉的那个下午。

本地部署和云端API不是非此即彼的关系——懂得混用才是进阶玩家的姿势：隐私敏感的任务走本地，日常高频任务走API，两者各司其职。

---

写在最后

llama.cpp确实把"在消费级硬件上跑大模型"这件事变成了现实，这是值得肯定的技术成就。但我做完这三天测试后，得出的结论比我预期的更复杂：

它适合你，如果： 你有隐私需求、你有32GB以上内存、你不介意等待、你享受折腾过程本身。 它不适合你，如果： 你需要高频使用、你对推理和计算任务有准确性要求、你的时间比折腾成本更宝贵。

技术没有对错，只有适不适合。

---

llama.cpp解决了"能不能跑"的问题，但下一个问题更有意思：同样是本地部署，用Ollama封装 vs 直接用llama.cpp，哪个更适合普通用户？

Ollama把复杂的命令行操作包装成了类似Docker的体验，看起来友好很多——但它真的更好用吗？在启动速度、模型管理、多模型切换上各有什么取舍？还有一个很多人忽略的关键差异，我留到下篇再说。

关注我们，下篇更新时第一时间收到通知。

---

本文由8848AI原创，转载请注明出处。关注8848AI，带你从零开始学AI。

#AI教程 #本地部署 #llama.cpp #大模型 #量化 #8848AI #人工智能 #GPU