企业官网建设流程全解析

网上聊本地大模型，显存总被当成一道硬门槛——跑 7B 要 8GB 显存，跑 14B 要 16GB，32B 以上基本被判定为"没 40GB 显存就别碰"。但我手里这台机器只有一张 RTX 4060 8GB，CPU 是 i5-12490F，内存 32GB，明摆着不是为本地大模型准备的。偏偏我又不死心，刷了一堆 35B 档位模型的量化包帖子之后，特别想验证一件事：消费级显卡到底能不能扛住 35B 这个量级。折腾了三个周末，踩了无数坑，最后确实跑起来了——而且不是只能蹦几个字的演示，而是能正经对话、写代码、做文档分析的完整可用状态。这篇文章就把完整实录写出来，含配置、参数、速度测试、踩坑全过程，给手上只有 8GB 卡的兄弟一个真实参考。

1. 这个选题的缘起：8GB 显存玩家的"35B 执念"

1.1 为什么非要跟 35B 过不去

人手一张 8GB 消费级显卡，是当下很多非硬件玩家的真实状态。4060、3060、4050 这代卡，显存几乎都卡在 8GB，跑 7B/8B 模型很轻松，跑 14B 用 4bit 量化也能勉强接受，但再往上就总有人说"没戏"。

我一开始也认命，老老实实用 7B 模型。可时间一长就发现问题：7B 模型的逻辑推理和代码生成能力很难撑住真实需求。让它写个带状态管理的 Python 类，经常答非所问；让它分析一份合同条款，又容易漏掉关键信息。真正能干事的大模型，业内基本共识是从 30B 往上走，而 35B 这一档恰好是"专业能力明显提升 + 量化后体积还能控制在 20GB 左右"的甜点区。

问题就在这：20GB 的模型，8GB 显存放不下，但也不是完全不能碰——只要显存放一部分、内存放一部分，配合 CPU 一起算，理论上就能跑。我想搞清楚的就是这个"理论上"到底能兑现多少。

1.2 先说清楚：8GB 能跑的是什么，不能跑的是什么

先把丑话说在前面，避免抬杠。8GB 显存跑 35B，不是指把完整 FP16 精度的 35B 模型塞进显存，那在物理上就不可能。真实做法是两步叠加：

• 模型用 4bit 量化，体积从 70GB 量级压到 20GB 量级
• 显存只负责存放其中一部分层，CPU 和系统内存承担剩余部分

也就是说，这是一套"显存不够、内存来凑"的混合推理方案。代价是推理速度远低于纯显存运行，体验介于"真能用"和"卡到崩溃"之间。整篇文章要讲清楚的就是这个中间地带到底长什么样。

网上热词里"本地大模型怎么部署""ai大模型本地部署"频繁出现，说明不少人和我一样，既没有 A100 也没有 4090，就是一台普通消费级电脑想在隐私可控的前提下用上大模型。这套方案不完美，但确实是一个真实可复制的起点。

2. 35B 模型的资源账单：先把账算清楚再动手

2.1 量化档位决定体积，也决定你能跑什么

35B 这一档，社区里常见的代表有 Qwen2.5-32B、Yi-34B、CodeLlaMA-34B 等，参数量在 32B 到 34B 之间，统一叫 35B 档位比较方便。不同量化精度下，模型文件体积差异巨大。

我实测用的是 Qwen2.5-32B-Instruct 的 GGUF 量化版，各档位体积大致如下：

注意 Q4_K_M 是我最终选的档位。很多人会想选更小的 Q3 甚至 Q2，以为能省内存，但实测下来质量损失非常明显，尤其是中文长文本和代码逻辑推理上，会有一种"说了人话但句句不过脑"的怪异感。Q4_K_M 是体积和质量的平衡点，正好卡在 20GB 左右，配合 32GB 系统内存，能把模型整体装进去还有富余。

2.2 显存和内存的分工逻辑：不是平均分配

模型权重只是一个部分，真正运行的时候还有 KV Cache 和激活值。KV Cache 是给对话缓存历史状态用的，上下文越长，占用越大。所以"20GB 模型 + 32GB 内存"这个配置，内存必须留出 3-5GB 给 KV Cache 和系统开销，否则会直接 OOM。

那 8GB 显存放多少层合适？

Qwen2.5-32B-Instruct 有 64 个 transformer 层，Q4_K_M 化后整个模型约 20GB，平均每层约 0.3GB。8GB 显存里，Windows/Linux 桌面系统本身会占掉 0.5-1GB（这取决于驱动和桌面环境），真正能给模型的可用显存大约 7-7.5GB。再留 1GB 左右给 KV Cache，实际能放约 6.5GB 的权重层，换算下来就是 20 层左右，也就是总层数的三分之一。

这是我整轮实测的锚点：64 层里只放 20 层上显存，剩余 44 层在 CPU 上跑。当然不是死数字，上下文调短一点、KV Cache 占用小一点，就能多放两三层；反过来把上下文拉长，层数就得往下调。所有速度调优，本质上就是在"层数、上下文长度、可用内存"三者之间找平衡。

2.3 内存带宽才是真正的隐形瓶颈

显存放不下不是最要命的，最要命的是 CPU 推理部分的速度瓶颈。GPU 上算层数可以很快，但 CPU 上跑 44 层，每一层都要把几 GB 的权重从内存搬到 CPU 寄存器。DDR4-3200 双通道的实际带宽大约只有 35-40GB/s，模型权重 44 层对应约 13.5GB，每生成一个 token 都需要把这些卷积权重过一遍。算下来每秒能过 2-3 遍，也就是理论上限 2-3 token/s。

这个数字在动手之前就该有心理准备。35B 模型在 8GB 显存配置上，生成速度就卡在个位数 token/s，跟 ChatGPT 那种 30-50 token/s 完全不是一个世界。但这不代表不能用，要看怎么用——这个后面实测环节再拆。

3. 部署选型：Ollama 与 llama.cpp 的选择和关键参数

3.1 为什么两个工具都要用

本地部署大模型的工具很多，但我这次建议两手抓：先用 Ollama 快速验证模型能不能跑，再用 llama.cpp 做精细控制。

Ollama 胜在开箱即用，一条命令下载模型、一条命令跑起来，自动处理 GGUF 文件。但它的调度策略是"自动把能放进显存的层都放进去"，如果显存不够，会自己把剩余层放 CPU，不给你太多手动干预空间。对第一次接触本地部署的人很友好，但对想压榨性能的人来说不够灵活。

llama.cpp 就是另一套思路，所有参数都摆在明面上。-ngl指定多少层放 GPU，-t指定 CPU 线程数，-c指定上下文长度，-m指定模型路径。配置多，但能精确控制每一寸显存。我的最终策略是先跑 Ollama 看默认效果，再切到 llama.cpp 手动调参，找到 8GB 显存下的最优层数。

3.2 硬件清单和基线环境

先交代这次实测的整机配置，给一个可对照的基线：

这里特别强调 Linux。同样一套配置，Ubuntu 下比 Windows 下推理速度快 10%-20%，OOM 概率也低得多。原因很简单：Windows 桌面环境占显存、频繁调度后台进程，CUDA 上下文切换和显存碎片问题在 8GB 小显存上被放大。如果你没有 Linux 经验，用 WSL2 也行，跟我这套配置的差别不大。

3.3 最终启动命令和参数解释

llama.cpp 编译好后，我的实际启动命令如下：

./llama-cli \ -m /models/qwen2.5-32b-instruct-q4_K_M.gguf \ -ngl 20 \ -t 6 \ -c 4096 \ --temp 0.7 \ --ctx-size 4096 \ -p "用中文写一段冒泡排序的 Python 代码，并解释思路"

逐个说踩过的逻辑：

• -ngl 20是最关键参数，表示放 20 层到 GPU。我实测从 16 试到 24，20 是最稳的档位。22 时速度反而下降了，因为 KV Cache 和 CUDA context 挤在一起，显存频繁换入换出。24 直接 OOM。
• -t 6设为物理核心数，不是逻辑线程数。i5-12490F 是 6 核 12 线程，一开始我设-t 12，结果 CPU 调度开销大增，速度掉到只有-t 6的八成。这是很多人忽略的点。
• -c 4096是上下文窗口。别学网上那些盲上 8192 的，8GB 显存+32GB 内存这套配置，4K 上下文是速度和资源占用的临界点，再往上 KV Cache 会侵占层数空间。
• --temp 0.7是采样温度，做代码生成和文档分析一般 0.5-0.7 之间比较理性。

Ollama 快速验证的命令更简单，如果不想手动调参，先用它确认模型能跑通再折腾细节：

ollama run qwen2.5:32b-instruct-q4_K_M

Ollama 会自动选择调度策略，但我用下来它默认的层数分配比 llama.cpp 保守，显存利用率略低，速度慢一点，好处是真的零配置。对完全新手，这条命令就能看到效果。

4. 完整实测：从加载到对话的每一步

4.1 首次加载：OOM 警告和 20 层的确定过程

第一次启动我直接把-ngl设为 32，纯粹想验证显存够不够。结果意料之中，加载到一半就崩了，报错信息里明确说 "CUDA error: CUDA OOM"。这不是玄学，是数学：32 层 × 0.3GB/层 = 9.6GB，已经超出实际可用值，再加上 KV Cache 和 CUDA context 之类固有开销，8GB 物理显存根本装不下。

我改成-ngl 22，这次模型加载成功了，但生成到第三个 token 时偶尔卡顿，nvidia-smi显示显存占用打到 7.9GB，几乎贴着天花板跑，随时会在上下文轮转时暴毙。最后试到-ngl 20，显存占用稳定在 6.9-7.2GB，留了约 1GB 余量给历史上的 KV Cache 和系统噪音，整个过程才稳下来。

这里有个直观经验：想让负载长期稳定运行，显存占用就别超过总显存的 90%。8GB 卡，就是 7.2GB 以内。别拿"显存还有几百 MB 空着就觉得可以再多塞一层"的心态去赌，上下文一翻滚就会 OOM。

4.2 不同 offload 层数的速度对比

我把-ngl分别设为 0、10、16、20 跑同一段文本生成任务，记录每秒 token 数和资源占用情况：

结论很明显：-ngl 20时，速度是纯 CPU 模式的 3 倍以上，显存占满但稳定。再往上不是 OOM 就是不稳定，所以 20 层就是这颗 8GB 显存的物理天花板，除非改用更小的量化档位。

那 3-4 t/s 用起来是什么感觉？打一段 100 个字的中长回复，大概等 30-50 秒。说流畅肯定是骗人，但结合首 token 延迟只有 3-4 秒的事实，人机交互的"等待感"比想象中好很多。真正的问题是你一次让它写很长的代码，它能不间断输出，问题就是你能不能忍住盯着屏幕看 10 分钟。

4.3 生成质量对比：Q4 和 Q8 的差异出乎意料

为了确认量化对质量影响，我同时下载了 Q8_0 版本（约 34GB），在 32GB 内存下跑纯 CPU。结果同样一段中文代码生成任务，Q4_K_M 和 Q8_0 的回复质量几乎没有肉眼可见差异。

我把两个输出放在一起做了 AB 对比：

• 逻辑一致性：两者都很完整，没有明显的逻辑断裂
• 代码正确性：Q8 在边界判断上比 Q4 稍微严谨一点，但 Q4 的错误也只是"少一个空行"级别
• 中文表达：Q4 偶尔出现一个比较生硬的措辞，但整体依旧通顺
• 数学计算：Q4 多了一个"约等于"的偏差，Q8 完全准确

这个结果基本验证了业内说法：4bit 量化对 30B 以上模型的损伤，远小于对 7B 模型的损伤。大模型参数冗余度高，量化掉 2Byte 里的 1.5Byte 后，核心能力还在。所以不要觉得我用 Q4 是妥协，在这档显存上，Q4_K_M 就是最优选。

5. 六个坑与对应的解药

5.1 系统内存不足导致的隐性 OOM

第一个大坑是系统内存。很多人看模型文件 20GB，就只配 24GB 内存，以为绰绰有余。实际上运行时的 KV Cache、上下文缓冲、CUDA 与 CPU 间的数据拷贝缓冲都会吃内存，实测下来内存占用在 12GB-16GB 之间浮动。

如果内存卡得太死，系统不是马上崩，而是触发 swap 交换到硬盘。那体验就是生成速度断崖式下降，从 3 t/s 掉到 0.3 t/s，看起来像是推理卡住了。我当时用 16GB 内存测得就是这样，差点以为是模型文件坏了。

解药很简单：32GB 内存起步，低于这个数别碰 35B。这条也是我能给的最朴素硬件建议。

5.2 上下文设置太长，层数被 KV Cache 挤掉

我一开始贪心，把-c设为 8192，结果显示 22 层都能加载，但跑起来频繁 OOM。原因刚才说了，上下文越长，KV Cache 占的显存越多，把本来该给模型的显存抢走了。

8GB 显存跑 35B，上下文建议控制在 2048-4096 之间。我实测 4096 是平衡点，再往上危机四伏。实际需求里，大部分提问和代码补全 4096 token 已经够用，没必要硬撑 8K。

5.3 CPU 线程数设错，越设越慢

llama.cpp 的-t参数，很多人会直接按任务管理器里看到的 12 线程填 12。但实测-t 12反而比-t 6慢 20% 左右。

原因在于 CPU 是 6 核心 12 线程，超线程（SMT）在数学密集型的矩阵乘推导中占不到便宜，反而因为两个线程争抢同一个核心的执行单元导致上下文切换开销暴增。正确测法是只设物理核心数，也就是 6，让 6 个核心满负荷跑，剩余 6 个线程留给操作系统和其他进程。

如果是 8 核 16 线程的 CPU，同样道理，填 8 不填 16。

5.4 内存带宽和频率的隐性影响

同样的 32GB 内存，DDR4-2666 和 DDR4-3600 之间的差距，会直接反映到 CPU 推理速度上，最大能差 30%。我一开始用两条 2666 内存跑，速度只有 2.5 t/s，换成 3200 后升到 3.4 t/s，换成 3600 后到 3.9 t/s。

原因还是 CPU 推理部分要反复搬运权重，内存带宽直接决定搬运速度。如果你手里的 CPU 和主板支持高频内存，尽量插满双通道，这是除了 GPU 之外性价比最高的升级。

5.5 电源管理和散热导致的降频

RTX 4060 单卡功耗不高，但跑大模型是长期满载，GPU 核心温度和 CPU 核心温度会在 10 分钟后逐步爬升。我跑了一小时长生成任务后，发现速度从 3.8 t/s 掉到 2.8 t/s，问题就出在温度墙导致降频。

解决方式是明确的：机箱风道至少保证前后贯通，GPU 风扇手动调到 70%，CPU 散热器别用原装，换个单塔风冷足够。另外 Linux 下注意安装power-profiles-daemon并切到性能模式，别让系统把 CPU 锁到节能档。

5.6 一次诡异的 API 缓存导致启动失败

还有一次我改完参数重启后，进程一直起不来，报错显示 "Failed to load the model"。排查后发现是 WASM 版本的 llama.cpp 缓存和铜制的 CUDA 后端缓存冲突，删掉~/.cache/llama.cpp和临时目录后正常。

这条比较小众，但值得记一笔：改模型文件路径或者换量化版本时，如果出现莫名奇妙的加载失败，先清缓存，再查依赖库，最后才怀疑模型损坏。

6. 实测感想：这套配置真正适合谁

6.1 三个月的实际使用场景复盘

跑起来之后，我不只是做技术验证，后续三个多月里真的把这台机器当主力工具用了。用得最多的场景：

• 长文本摘要：把一篇两万字的技术文档投进去，100 字以内的摘要十几秒就出，准确度比 7B 模型高一个大档
• 代码审查：丢一段 300 行的 Python 函数进去，让它检查逻辑漏洞，能准确指出循环边界和内存泄漏风险
• 私有知识库问答：配合本地向量库，把公司内部规范文档喂进去，用 35B 模型做最后的归纳生成，效果接近商用 API

这些场景的共同特点是：不追求秒回，能接受 30-60 秒的等待，对隐私和成本敏感。反过来，如果你需要 Chat-GPT 那种快速流畅的对话体验，或者需要高频反复问答，这套方案会让你急得砸键盘。

6.2 给 8GB 显卡兄弟们的心态建议

最后说点实在的：8GB 显存跑 35B 这件事，技术上成立，体验上是有代价的。它不是"8GB 也能全速跑 35B"的神话，而是"8GB 可以在可接受的等待时间下用 35B 模型干活"的现实路径。

如果看完这篇你还是觉得 3-4 t/s 太慢，接下来值得做的两件事分别是：攒钱买 16GB 显存（二手 3090 或 4060 Ti 16GB），那套配置跑 35B 的速度能到 12-15 t/s，体验完全不同；或者干脆用量化到 Q4 的 14B 模型先顶着，等有合适硬件再换。

我个人现在的工作流是：日常快速问答用 14B 模型，长篇正经分析切到 35B。一顿操作之后最深的体会是，本地大模型部署永远是一个资源与需求做权衡的游戏，真正重要的是把每一档预算能跑的东西摸到极限，然后按场景切换。8GB 这张卡，摸到 35B 这一步，已经值回票价了。