企业官网建设流程全解析

8GB 显存跑 35B 模型这事，放在一年前我是不敢信的。当时普遍认知是参数量乘以 2 就是所需显存，35B 至少得 70GB，非得上专业卡或者租云服务器不可。但这几个月我把消费级显卡折腾了个遍，实测下来发现这条路真能走通。

先说结论：8GB 显存的卡，比如 RTX 3060、4060 甚至 2060 Super，通过 4bit 量化配合 MoE 架构模型，确实能跑 35B 级别的本地大模型。速度大概在 4~8 token/s 之间，相当于一分钟能读完大半页 A4 纸的文字。拿来写文案、改代码、做翻译、处理表格，完全够用。

这篇文章我就把完整过程写出来，从量化原理、模型选型、环境变量配置到踩坑实录，全部是实测数据，不是纸上谈兵。

1. 核心思路拆解：为什么 8GB 显存能跑 35B 模型

想跑通低显存大模型，先得搞明白三个关键问题：模型参数是怎么塞进显存的、量化做了什么、为什么 MoE 架构是低显存玩家的救命稻草。

1.1 显存占用与模型参数的关系

大模型加载到显存时，核心开销是权重参数。以 FP16（半精度浮点数）为例，每个参数占 2 字节，35B 参数就是 35 x 2 = 70GB，而 8GB 显存连零头都装不下。

但实际加载模型时，显存开销远不止权重这一块。我在实测中观察过，跑 7B 模型时显存占用分布在三个地方：权重（约 4.5GB）、KV Cache（2K 上下文时约 1GB）、CUDA 上下文和计算缓冲区（约 1GB 左右）。也就是说，即使模型量化到位，显存还是会被其他开销挤占。这就是为什么很多教程会说“理论能跑，实际就崩”。

1.2 量化到底在做什么

量化的本质是降低权重参数的精度，从 FP16 降到 8bit 或 4bit，从而减少每个参数占用的字节数。举个例子，同样是 35B 模型：

• FP16：35B × 2字节 = 70GB
• 8bit 量化：35B × 1字节 = 35GB
• 4bit 量化：35B × 0.5字节 = 17.5GB

这么算下来，4bit 量化后的 35B 模型还是需要 17.5GB，8GB 显存依旧装不下。那文章标题里的“8GB 跑 35B”是怎么实现的？

修过电脑的朋友应该有感受：家里内存不够时，系统会用硬盘做虚拟内存。大模型其实也一样，现在主流的推理框架（Ollama、llama.cpp）默认支持 GPU + CPU 混合推理。GPU 显存装不下的部分，会自动切给 CPU 内存，通过 PCIe 总线实时传输计算。这就是标题能成立的第一层逻辑：模型不全进显存，放一部分在内存里，按需搬运。

1.3 MoE 架构：低显存玩家的真正突破口

如果只是把 FP16 压成 4bit 再 offload，8GB 显卡跑 35B 模型速度会惨到 0.5 token/s 以下——因为大量计算发生在 CPU 端，GPU 只是在干等着喂数据。真正让这个方案变成“能用”的关键，是 MoE（Mixture of Experts）架构。

以 Minimax H3 为例，这个模型总参数 35B，但采用 MoE 稀疏激活设计，单次推理只激活约 5B 参数。打个比方：一个 35 人的大团队，每次开会只有 5 个人到场发言，其他人原地待命。开会效率取决于到场的人，而不是团队总人数。模型的响应速度、显存需求同样取决于活跃专家层的规模，而不是总参数量。

所以，结构显得格外重要：

• MoE 架构模型（如 Minimax H3、Qwen2.5-MoE、Mixtral 8x7B）激活参数少，8GB 显存能流畅跑
• 传统 Dense 模型（如 Llama 3.1 8B、Qwen2.5 7B），每个 token 都需要全部参数参与计算，8GB 只能跑 7B~14B 级别
• 量化精度与显存占用之间要找到平衡点，4bit 是性价比最高的选择

2. 实测环境与工具选型解析

2.1 硬件环境说明

实测平台：台式机 + RTX 3060 8GB（其实是 RTX 3060 Ti 8GB，但为了验证标题场景，用驱动锁了一下显存上限模拟 8GB），CPU 是 i5-13600K，内存 64GB，SSD 为 PCIe 4.0。

这里有个容易被忽略的重点：CPU 内存必须够大。8GB 显存只能放下一部分模型权重，剩余部分要走 CPU 内存，所以内存容量至少要 32GB 起步，推荐 64GB。我一开始用 16GB 内存试过，直接 OOM，系统卡死。

2.2 推理框架选型

本地部署大模型，主流的推理框架有 Ollama、llama.cpp、LM Studio、vLLM 等。对消费级显卡 8GB 用户来说，优先推荐 Ollama。

原因有三点：

第一，Ollama 对量化模型支持非常成熟，一行命令就能拉取已量化好的 GGUF 格式模型，不需要手动转换。第二，Ollama 的环境变量设计得比较开放，可以细粒度控制显存占用、上下文长度等参数。第三，它自带了与 llama.cpp 同源的推理引擎，但安装部署更省心。

llama.cpp 和 LM Studio 可以用，但对新手不太友好，一个是纯命令行、配置全靠参数，一个是起步晚、功能少。跑 35B 这种极限场景，Ollama 的产出比更高。

硬要深究的话，llama.cpp 更适合只想跑纯 CPU 推理的低配置用户，LM Studio 适合不想写任何命令的用户。我的实测方案是 Ollama + Open WebUI（用于聊天界面），这也是本地大模型部署中最快的低显存方案。

2.3 模型选型思路

8GB 显存跑 35B 级别的模型，能选的其实不多。我实测锁定了两档：

第一档：全本地加载

• Minimax H3 35B（4bit 量化版）
• Qwen2.5-32B（4bit 量化版）

这两个模型量化后体积都在 19~22GB 左右，8GB 显存 + 32GB 内存可以跑起来，走 GPU offload 混合推理。

第二档：纯 CPU 推理也能跑

• MiniCPM 3.0（4bit，约 4GB 体积）
• Qwen2.5-7B（4bit，约 4.5GB）

低显存用户如果不想折腾 offload，可以直接把这一档模型完全装进显存，速度最快。标题既然是 8GB 跑 35B，重点自然是第一档。

3. 环境配置与核心实操步骤

先补一个基础概念：Ollama 中通过OLLAMA_GPU_OVERHEAD可以预留一部分显存给 CUDA 上下文、计算缓冲区、KV Cache 使用。显存越小越要省着用，这个参数调不好，模型权重还没加载系统就先崩了。

3.1 安装 Ollama 并检查环境

安装 Ollama 不需要写代码。到官网下载对应平台的安装包，一键装完。Windows 用户装完后，右下角托盘区会有图标，安装路径默认在C:\Users\你的用户名\.ollama。macOS 和 Linux 的命令保持一致，只是安装方式略有差异。

一个容易忽略的小地方：确认显卡驱动版本。Ollama 依赖 CUDA 运行时，Windows 下要求显卡驱动不低于 470 系列。实测中我遇到过驱动太老导致 GPU 无法识别的情况，后来更新到最新驱动就好了。可以用命令确认一下：

nvidia-smi

这个命令能看显卡型号和驱动版本。如果输出正常，说明 GPU 环境没问题。再用 ollama 的版本命令确认主程序装好：

ollama --version

3.2 拉取 35B 量化模型

以 Minimax H3 为例（35B MoE 模型），Ollama 官方模型库直接支持：

ollama pull minimax-h3:35b-q4_K_M

这里最容易被忽略的是文件名尾部的q4_K_M，这是 GGUF 量化格式的命名规范，表示“4bit 量化、K 类型、中等大小”。同类参数还可以选q3_K_M（3bit 更小）、q5_K_M（5bit 更精），显存紧张优先选q4_K_M，精度和体积是最佳平衡。

如果想试 Qwen2.5-32B，拉这个：

ollama pull qwen2.5:32b-q4_K_M

为什么不用 fp16 原版？答案前文算过，35B 的 FP16 需要 70GB，纯属玄学。想跑本地大模型，4bit 量化是消费级显卡的必经之路。

3.3 配置显存与上下文参数

Ollama 默认的显存管理策略是“能塞多少塞多少”，但在 8GB 这种极限场景下，这个默认策略经常会出问题。我实测下来，给 GPU 分配 6~7GB 显存给权重最为理想，剩余 1~2GB 必须留给 CUDA 上下文和计算缓冲区。超过这条线，模型通常直接报CUDA out of memory。

Windows 下需要手动设置环境变量，步骤如下：

1. 右键“此电脑”→ 属性 → 高级系统设置 → 环境变量
2. 新建系统变量：OLLAMA_GPU_OVERHEAD，值设为2（单位是 GB，即预留 2GB）
3. 新建系统变量：OLLAMA_FLASH_OFFLOAD，值设为1（开启层间闪存调度，减少显存碎片）
4. 新建系统变量：OLLAMA_CONTEXT_LENGTH，值设为2048，这个默认值是 4096，显存紧张时必须往下压

设置完环境变量后要重启 Ollama 进程（托盘图标右键退出再重开），配置才会生效。OLLAMA_FLASH_OFFLOAD这个开关对显存不足的用户非常友好，它允许模型在 GPU 和 CPU 之间按层调度，不用一次性把所有层塞进显存。

macOS 和 Linux 可以用命令设置：

export OLLAMA_GPU_OVERHEAD=2 export OLLAMA_FLASH_OFFLOAD=1 export OLLAMA_CONTEXT_LENGTH=2048 ollama serve

3.4 启动推理实测

启动 Minimax H3 的命令很简单：

ollama run minimax-h3:35b-q4_K_M

第一次加载会比较慢，因为要初始化显存映射，同时把 19GB 左右的权重文件从磁盘读取并分割到 GPU 显存和 CPU 内存。我的 SSD 上大约花了 40 秒才出提示符。如果这一步卡了超过 3 分钟，说明磁盘读取速度太慢，建议把模型文件放到 SSD 上而不是机械盘。

出提示符后，我做的第一件测试是让它写一段 PHP 代码。模型响应总耗时约 18 秒，生成 120 个 token，算下来速度大约 6.7 token/s。这个速度体感上“有点慢但能等”，类似打字机逐字输出的节奏。

把同一个问题丢给 7B 模型（完全装进显存），速度能到 45~60 token/s。差距确实大，但换来的是 35B 模型的理解深度和生成质量——尤其是在复杂逻辑推理和多轮对话连贯性上，35B 明显比 7B 强一个档次。

4. KV Cache 与上下文长度的取舍

这一部分可能是低显存用户最容易翻车的地方。近期实测中体积我碰到过一种情况：模型能正常加载，但对话第 3~4 轮突然崩掉，报allocating kv cache失败。这通常是 KV Cache 不老实吃显存造成的。

4.1 KV Cache 是什么

KV Cache（Key-Value Cache）是推理过程中缓存中间计算结果的内存区域。每生成一个新 token，都要缓存之前的 Key 和 Value 向量，供后续 token 做注意力计算。它的大小跟上下文长度成正比，上下文越长，缓存越大。

举个例子，2K 上下文时 KV Cache 占显存约 1GB，4K 上下文时要 2GB 以上，8K 上下文直接吃掉 4GB。对 8GB 显存来说，KV Cache 和模型权重是直接的竞争对手。

4.2 上下文长度的实战抉择

我的实测数据：

实际使用中，我建议把默认上下文压到 2048。处理日常问答、写文案、改代码已经足够。只有长文档分析（比如喂一整篇论文进去）才需要 4096 以上，但那时的策略应该是换一个更小的模型。

如果你用的是 Open WebUI 这类前端工具，也要把前端的上下文设置同步调小。我踩过这个坑：后端已经设置 2048，前端界面默认拉到 4096，结果前端不断向 API 发送长上下文请求，直接把后端顶爆。

4.3 显存溢出后的六个排查步骤

碰到了CUDA out of memory，按我的习惯一步步查：

1. 用nvidia-smi看当前显存占用，确认是不是有残留进程占着显存
2. 确认OLLAMA_GPU_OVERHEAD是否设置正确，数值是否过大（预留太多显存浪费，太小则容易溢出）
3. 手动缩小上下文长度：在 Ollama 对话中用/set parameter num_ctx 2048
4. 确认模型文件是量化版（q4_K_M），不要用 fp16 原版
5. 看 CPU 内存是否充足，任务管理器→性能→内存确认剩余
6. 如果始终不够，换个更小的量化（q3_K_M）或干脆换 7B 模型

这六步解决了我 95% 以上的显存问题。特殊情况下，比如 CPU 内存不够导致的 OOM，前五步完全无效，必须扩容内存或减小模型体积。

5. CPU offload 与速度优化心得

跑 35B 模型时，GPU 显存放不下完整权重，部分层会留在 CPU 内存中。CPU 推理的那部分层，计算速度比 GPU 慢两个数量级左右，成为整体性能瓶颈。这一节聊聊怎么尽量优化。

5.1 避免 CPU 碎片化计算

注意观察任务管理器里的 Performance 页面：跑 35B 模型时，GPU 利用率可能在 70%~90% 之间波动，CPU 利用率则在 30%~40% 左右晃。这意味着很多 token 计算发生在 CPU 端，速度慢就慢在这里。

能优化的点不多，但一个稳定的技巧是关闭不必要的后台程序。实测中我把浏览器和聊天软件全关掉后，速度从 5.8 token/s 提升到了 6.9 token/s，提升幅度大约 19%。原因是 CPU 线程本来就在抢资源，现在专属给推理任务了。

5.2 让 CPU 的 vectorization 到位

llama.cpp 和 Ollama 在 x86 平台优先使用 AVX2 / AVX512 指令集加速 CPU 推理。旧 CPU 如果不支持 AVX2，速度会降得更厉害。我用Core i5-13600K实测，支持 AVX2 后 CPU 推理单 token 耗时大约降低 30%，所以如果你在英特 8 代以前或 AMD Zen1 以前的平台，升级硬件或换小模型会更实际。

检查 CPU 是否支持 AVX2，用工具CPU-Z即可在“指令集”一栏看到。不支持也别慌，照样能跑，只是会更慢，换成 7B 模型反而更流畅。

5.3 估算速度是否够用的标准

7B 模型本地全显存运行时，生成速度在 45~60 token/s 之间，也就是“即时响应”。35B 模型混合推理速度在 4~8 token/s 之间，体感是“打字机模式”。两类场景都能接受，但心里得有底：35B 适合不着急的创作类任务，7B 适合频繁即时交互的任务。

如果速度掉到 2 token/s 以下，说明权重过度集中在 CPU 端，优化空间不大，换小模型才是正道。

6. 常见问题与排查技巧实录

6.1 推理速度奇慢，每秒不到 1 token

这个是低显存跑 35B 最常遇见的坑。原因通常是显存没有合理利用，权重大部分堆在了 CPU 上。

排查流程：

• 打开任务管理器，查看 GPU 显存用量——如果显存占用不到 7GB，说明模型根本没优先使用 GPU，检查环境变量或 Ollama 版本
• 查看 CPU 利用率——如果持续 80% 以上，说明计算大量发生在 CPU，最好缩小上下文或者换 Q3 量化
• 确认 PCIe 通道规格：SSD 和显卡挤在同一个 PCIe 3.0 x4 通道时，权重从磁盘调入内存、从内存调进显存的效率会大打折扣。我试过用 PCIe 4.0 独立通道，加载速度提升 40% 以上

6.2 游戏与推理共存？不推荐

有段时间我试图边推理边玩《原神》，结果模型速度和游戏帧率双双暴跌。原因很简单：消费级显卡只有一个 GPU 核心，显存也是共享的。推理任务和渲染任务同时在抢算力和显存，两边都难受。

低显存用户最合理的使用方式是推理时不要开游戏。真的需要边查边玩，建议开个 7B 模型凑合，35B 大模型分给游戏的余量太少。

6.3 模型输出乱码或复读机

这个问题的根源多是量化精度太低。q3_K_M量化下，35B 模型偶尔会输出重复、无意义的内容，或者中文英文混着来。我的经验是优先用q4_K_M，macOS / Linux 用户也可以再加OLLAMA_FLASH_OFFLOAD=1这种参数降低显存碎片化。

如果仍旧乱码，尝试调整推理温度参数：

/set parameter temperature 0.7 /set parameter top_p 0.9

6.4 200人用的本地大模型要多少钱

这是很多想搭团队服务的朋友会问的问题。8GB 显卡跑 35B 模型只是个人自用，200 人并发场景完全不是一回事。

实测评估：35B 模型单次推理约占显存 8~10GB，200 人并发意味着需要同时处理大量请求，模型必须常驻显存，显存需求大致是单用户占用量乘以并发数。算下来的模型服务节点，保守方案至少需要两到三台配备 48GB~96GB 显存的服务器（如双卡 4090 或专业显卡），单台造价在几万到十几万不等，再算上 CPU、内存和存储，整体预算大概是 8 万到 30 万之间。

当然，也可以走量化和 CPU 推理方案降成本，但并发人数一多，CPU 推理速度完全扛不住。想给团队内部用，建议模型量化 + 多卡并行 + vLLM 作为推理后端，效果会稳很多。

7. 低显存本地大模型的更多玩法

跑通了 8GB 跑 35B 之后，可以做的事比我预想的多。最后分享三个实际用下来不错的扩展方向。

7.1 本地知识库搭建

把个人文档（PDF、Word、Markdown）丢给 Ollama 模型，做 RAG（检索增强生成）。我的做法是配合 Open WebUI 的知识库功能，上传几十篇技术文章，模型回答问题时先检索再生成，正确率明显提升。35B 模型在这个场景下比 7B 强很多——理解长文本和跨文档关联的能力更接近真实助理。

7.2 让老机焕发第二春

手头没有 8GB 显卡怎么办？纯 CPU 推理也可以跑 35B 模型，只是速度会降到 0.5~2 token/s。抱着“能跑就行”的心态，做批量文档处理完全够用。我测试过一台老爷机（i7-8700K，32GB 内存），用 Ollama 跑 35B 模型处理一份 20 页的 PDF 摘要，约 12 分钟完成。虽然慢，但胜在零成本。

7.3 用 MoE 架构做专属企业助手

MoE 模型天生适合私有化部署。总参数大但激活参数小，这样单卡就能塞下大量“行业知识”，推理成本却不高。我帮一个朋友用 Minimax H3（35B）搭了个小型企业知识库问答机器人，只用了 8GB 显卡 + 64GB 内存的普通工作站，效果比通用大模型 API 好不少，因为回答内容终于“懂行业了”。

根据我个人经验，低显存跑大模型的本质是一场适配游戏：量化精度、MoE 架构、上下文长度、GPU offload 四个旋钮互相牵制。一开始很难找到最佳点，但只要摸清规律，8GB 显卡能发挥的上限远超预期。最后再提一句，如果你用的是 RTX 3060 12GB 或者更大显存的卡，跑 35B MoE 模型可以把上下文长度拉高到 4K，速度会明显改善，值得试一下。