企业官网建设流程全解析

手里只有一张 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 参数估算：

注意这只是权重体积，实际加载时还要留出 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-11GB，8GB 显存依然装不下。这就轮到 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 结论也适用）
• CPU：Intel i5-12400F（6 核 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。原因有三个：

1. 中文能力在同体量里是第一梯队，日常问答、写作、知识库问答都明显好于 Yi-34B。
2. 社区的 GGUF 量化版本最全，从 Q2_K 到 Q8 都有现成文件，不用自己动手量化。
3. 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.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 文件。写一个Modelfile：

FROM D:\models\qwen32-q2.gguf

然后执行：

ollama create qwen32-q2 -f Modelfile ollama run qwen32-q2

关于层卸载的设置，Ollama 在不同版本里控制方式不一样。我实测有效的是两种：在运行时敲/set parameter num_gpu 24，或者启动服务前设置环境变量OLLAMA_GPU_LAYERS=24。如果你的 Ollama 版本对这两个都不敏感，那就说明版本太旧或者被其他配置覆盖了，这时候我最推荐的方案是——直接用 llama.cpp，别在 Ollama 的封装里折腾。Ollama 适合日常用，不适合精细调参。

4. 实测数据与逐项调优：速度、显存、质量的三角拔河

4.1 基准测速结果与瓶颈分析

我跑了一组不同-ngl参数下的对比数据。测试 prompt 是一段 256 token 的文本，生成 128 token 作为测速样本，用的是 llama.cpp 自带的llama-bench：

llama-bench -m D:\models\qwen32-q2.gguf -ngl 20 -p 256 -n 128

实测数据如下（RTX 3070 8GB + DDR4 3200 双通道 + 32GB 内存）：

明显看到：-ngl越高速度越快，但收益是递减的。从0到10提升了 0.8 token/s，从24到28只提升了 0.4 token/s。原因就是层越多放 GPU，CPU 侧剩余权重越少，内存带宽压力越小，但 GPU 侧数据处理、PCIe 传输的开销也开始出现。所以不是无脑把-ngl拉到最高就好，而是要在“不溢出”的前提下尽量高。我的实践值是 24-28，再高就可能在上下文稍微拉长时触发显存溢出。

这个速度意味着什么？以写周报为例，一篇 300 字的文本，中文一个字大约占 1-1.5 个 token，满打满算 500 token，4 token/s 就是大约 2 分钟。人读一遍 2 分钟没问题，但如果要做多轮对话，每轮都等两分钟，体验就很折磨。所以 8GB 跑 35B 更适合“一次性生成”的任务，而不是高频交互。

4.2 把速度拉上去的五个实操调整

同样的硬件，测速数据是能靠调整往上提一截的。我试过这些方法，按效果排序：

1. 确保内存跑在双通道且频率正确。这是最容易被忽略的。很多人内存买了 3200MHz，实际 BIOS 里默认跑 2133MHz，带宽直接掉了三分之一。进 BIOS 开 XMP / EXPO，把频率拉回标称值，CPU 侧推理速度立竿见影。

2. 调整-ngl到显存余量 1GB 左右的位置。显存留太满，启动时没问题，但上下文一增长 KV cache 就会爆。留 1GB 是个安全阈值。

3. 开启 Flash Attention（-fa）。它主要解决 KV cache 的显存占用问题，对速度也有小幅帮助。上下文 4096 时能省下 1GB 左右的显存，相当于多放几层到 GPU。

4. 控制上下文长度。-c 8192比-c 4096的 KV cache 占用大一倍，对 8GB 显存来说压力很大。日常使用建议 4096 就够，除非你明确要做超长文档分析。

5. 关掉后台占显存的程序。浏览器开一堆标签页可能吃掉 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 Attention），8K 上下文就要 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-smi（WSL 里）实时看显存曲线，比盯着日志盲猜有效得多。

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，觉得思路可行但硬件受限，我建议按性价比排序考虑：

1. 先加内存，把 32GB 升级到 64GB，CPU 侧瓶颈缓解，可以尝试跑 Q4 量化并 offload 更多层到 CPU，或者直接尝试 70B 模型的 Q2 版本（纯 CPU 内存足够的情况下也可以跑，速度约 1-2 token/s）。这是最省钱的方向。

2. 换一张 16GB 显存的卡（例如 RTX 4080 / 4090D 二手或者 RTX 5070 Ti）。16GB 可以完整吃下 35B 的 Q4_K_M，速度和质量都会上一个台阶，日常问答基本可用了。

这一步一步升级的过程中你会发现，本地大模型的体验瓶颈从来不是某一个硬件，而是“显存、内存带宽、量化质量”这三者的平衡。8GB 跑 35B 只是把这种平衡推到极限状态的一次实验，它让你清楚地知道每一块硬件的短板在哪里——这也是我觉得这次折腾最值的地方。跑通的那一刻挺有成就感，但别把这套配置当日常主力，它是理解推理原理的极好跳板，而不是终点。