“8GB 显存的消费级显卡跑本地大模型听起来就是自找麻烦。35B 级别的模型光权重就几十个 GB一张 RTX 4060 8GB 怎么可能塞得下”这是我首先想说的。这段时间我每周都拿手头这台普通游戏主机折腾“消费级显卡 本地大模型”的组合最终真的在 8GB 显存环境下把 35B 量级的模型跑了起来虽然速度谈不上丝滑但整个流程从选模型、做量化、调显存卸载层到接 Dify踩遍了坑也攒了一堆经验。这篇实录就是把这些细节全部摊开给想玩本地大模型、又暂时不想升级显卡的人一条能直接抄的路。先给结论8GB 显存跑 35B靠的是量化加 CPU 内存协同把模型拆开喂给 GPU 和 CPU 分别算。能跑但是要接受 2~5 token 每秒的生成速度。如果你对延迟不敏感只是想本地离线跑一个更大的模型而不是只能看 7B、8B 小模型的脑洞那这套方案值得折腾。1. 这套玩法的边界到底在哪里1.1 8GB显存为什么也能碰35B参数先说个基本算术。大模型推理时最占显存的是模型权重FP16 精度下每个参数大概占用 2 字节一个 35B 参数的模型FP16 权重就需要大约 70GB 显存。这也是为什么常见入门教程都说“跑大模型先准备大显存”。但推理引擎早就不是只能把整个模型放进 GPU 里才能干活了。llama.cpp 这套生态把权重压缩成 GGUF 量化格式可以把参数压到 4bit、3bit 甚至 2bit体积大幅缩小。比如同样一个 35B 模型Q4_K_M 量化后大概 20GBQ2_K 量化后可以到 11~13GB。可问题是即便量化后 20GB 依然超过 8GB 显存。于是就有了另一个关键机制层卸载。模型有很多 transformer 层你可以指定前多少层放在 GPU 里算剩下的层放在系统内存里用 CPU 跑。用运输来类比显存是小港口系统内存是大仓库CPU 是普通货车GPU 是高速列车。货运量太大时小港口装不下全部货物就只好让高速列车先拉一部分普通货车在后面接力。每次生成 token 都要把所有层的权重读一遍所以被 CPU 处理的那部分层越多整体速度越慢。8GB 显存能跑 35B本质上是“用时间换显存”不是“用魔法炸显存”。1.2 测试机的配置与预期这次实测用的机器很普通不是工作站就是因为大家手里的游戏机大概率也就是这个水平。部件配置显卡RTX 4060 8GB处理器AMD R5 5600X内存32GB DDR4 3200 双通道系统盘NVMe SSD系统Windows 11先说这个配置跑 35B 的预期值模型加载完成后如果设置得当生成速度大约在 2.5~4 token/s。这是什么概念相当于老式打字机正常回答一段话可能十几秒到半分钟。当场聊几句还能忍指望它当实时搜索引擎就太勉强了。设定预期还有一个好处后面调试时不会因为慢得夸张就怀疑哪里出了问题。低速是这个方案的一部分不是 bug。2. 模型选型与量化方案的取舍2.1 35B模型的真实大小标题写 35B但市面上叫“35B 量级”的开源模型实际参数量常落在 32B 到 34B 之间比如 Qwen2.5-32B 和 GLM-4-34B。我这轮实测主要拿 Qwen2.5-32B 做例子顺便用 GLM-4-34B 跑了一轮对比。严格说它们不是同一个参数量但推理时的资源需求逻辑是一致的。关键要先搞清楚模型从哪来、下载哪个格式。HuggingFace 上的原版模型大多是 safetensors 格式按 FP16 存储32B 模型就能占 65GB 左右这个格式压根不适合 8GB 显存直接加载。我们要的是 GGUF 版本一般由社区制作发布。不同量化参数的文件体积差异很大选择直接决定了后面能不能用。下面是 Qwen2.5-32B 常见 GGUF 量化档位的大致体积预测量化档位文件大小约推荐用途Q2_K11GB 左右极限低显存环境优先考虑IQ3_XS12.5GB 左右平衡速度与质量的折中Q4_K_M20GB 左右质量好但 CPU 压力大Q5_K_M24GB 左右只适合显存内存都大的机器2.2 量化等级怎么选量化等级不是越高越好也不是越低越快而是要匹配你的总内存和显存预算。FP16 转成 4bit 会损失一部分模型精度但实际问答中Q4 和 Q2 的差距不是“能聊”和“不能聊”的区别更多体现在复杂推理、长文本一致性、代码生成这些细活上。我在 8GB 显存配置下首选 Q2_K 或 IQ3_XS理由是文件体积压到 12GB 左右系统内存 32GB 还能承受同时能给 GPU 的前若干层留出余量。如果你硬要用 Q4_K_M 也不是不行但 20GB 权重意味着大部分层都压在 CPU 上生成速度很可能降到 1~2 token/s体验非常难受。下面这张表是我试过的几个档位的真实感受量化档位显存策略速度观感回答质量Q2_K卸载 24 层到 GPU3 token/s 左右日常对话能接受IQ3_XS卸载 20 层到 GPU2.8 token/s 左右比 Q2 稳一些Q4_K_M卸载 16 层到 GPU1.5 token/s 左右质量最好但慢得崩溃对于小额预算我更推荐“Q2_K 快速体验IQ3_XS 日常使用”。如果想用 35B 做正经文书工作我反而会劝你别折腾量化太低的大模型选一个 14B 的 Q4_K_M整体体验会舒服很多。2.3 推理运行时二选一Ollama 还是 llama.cpp本地推理引擎主要有两个选择Ollama 和 llama.cpp。Ollama 最大的好处是零配置装完以后一条命令就能拉模型跑起来还会自动处理显存和 CPU 的分配对刚入门的人来说非常友好。但它的可调参数相对少适合先验证“这个模型在我的机器上到底能不能跑”不适合深调。llama.cpp 则是一套更底层的工具提供一个 llama-server 程序几乎所有推理参数都能手动控制包括 GPU 层数、上下文长度、批处理大小、CPU 线程数。对于“8GB 跑 35B”这种极限场景我强烈建议最终切到 llama.cpp 来做精细控制。用做饭来比喻Ollama 是给了你一个“一键炖汤”的电炖锅llama.cpp 是给了你一口炒锅让你自己控制火候。刚开始用 Ollama 尝味道确定要正式做菜就换 llama.cpp。3. 从空白环境到跑起来的完整实录3.1 用Ollama快速启动并跑通如果你想最快看到 35B 模型能不能跑装 Ollama 是最短路径。在官网下载 Windows 版安装包装完打开 PowerShell默认服务已经启动。第一步设置服务监听地址因为后面接 Dify 或远程访问要用setx OLLAMA_HOST 0.0.0.0重启 Ollama 服务让环境变量生效。然后拉取量化模型。Ollama 上的标签名一般是qwen2.5:32b-q2_K这种ollama pull qwen2.5:32b-q2_K这一步会下载 11~13GB 的权重磁盘空间要预留好。下载完直接来一句试水ollama run qwen2.5:32b-q2_K 用一句话介绍你自己首次加载会有点慢因为要把权重读进内存。跑起来后打开任务管理器看性能标签如果 GPU 的“专用 GPU 内存”占用在 5~7GB 之间CPU 内存占用十几GB就说明成功进入了“显存不够、内存来凑”的状态。如果直接报CUDA out of memory多半是后台有其他程序吃了显存先关掉浏览器硬件加速再试。3.2 llama.cpp手动部署的详细参数用 Ollama 跑通后我更推荐转到 llama.cpp 做深度优化。这个引擎的 Windows 版在 GitHub 的 release 页面直接下载 zip 解压就能用不需要编译。把下载好的 GGUF 文件放到一个目录比如D:\models\qwen2.5-32b-q2_k.gguf。然后运行llama-server.exe下面是我反复调整后最稳定的一组参数llama-server.exe -m D:\models\qwen2.5-32b-q2_k.gguf ^ --n-gpu-layers 24 ^ --ctx-size 2048 ^ --batch-size 256 ^ --ubatch 64 ^ -t 8 ^ --port 11434逐个解释它们的作用。--n-gpu-layers 24是最关键的参数。它表示把模型的前 24 个 transformer 层丢给 GPU 计算剩下的层留给 CPU。这个数字不是拍脑袋定的要看显存容量。我一开始设成 28模型加载到一半直接 OOM后来把上下文缩短到 2048、层数降到 24 才稳定。在 8GB 显存下我的经验值是“层数从 22 起步逐步加 2每加一次观察一次显存”。--ctx-size 2048是上下文窗口长度默认值可能会是 4096 或更高但对 8GB 显存来说2048 是比较安全的数字。后面会专门算这笔账。--batch-size 256和--ubatch 64是批处理相关参数。模型在“预填充”阶段读入你输入的长文本时会用 batch 提高吞吐量在生成 token 的阶段ubatch 更小可以减少显存峰值。对 8GB 环境这两个值可以保持默认不用贪心往高调。-t 8是让 CPU 使用 8 个线程做卸载层的计算。建议不要设置为 CPU 物理核心数最大值因为同时还得留线程给操作系统和桌面应用我实测 8 线程在 R5 5600X 上表现最好开到 12 反而因为调度争抢略有波动。--port 11434是为了和 Ollama 保持同一个端口后面接 Dify 的时候换服务不用改配置。启动后如果看到server is listening on http://127.0.0.1:11434说明服务正常。在另一个终端随时可以验证curl http://localhost:11434/v1/models这可以确认模型是否被正确加载。3.3 实测数据速度、显存、CPU占用下面这组数据是我在同样一台机器上用 Qwen2.5-32B Q2_K 跑出来的结果。环境温度大约 25 度机箱风道普通整机功耗约 350W 电源。配置显存占用内存占用预填充速度生成速度ngl24, ctx20487.1GB12.8GB8.6 token/s3.3 token/sngl22, ctx20486.6GB13.2GB7.9 token/s3.1 token/sngl26, ctx20487.8GB12.2GB9.2 token/s3.6 token/sngl24, ctx40968.5GB13.1GB8.1 token/s2.9 token/s可以看到ngl26时显存已经接近 8GB 红线虽然没 OOM但如果你后台开个浏览器很可能会触发驱动重置。ctx4096时显存明显涨了约 1.4GB生成速度也有所下降。所以我把 ngl24、ctx2048 当作日常配置整个系统稳定跑了一天都没出问题。生成速度这个数字是硬瓶颈。3.3 token/s 意味着输出一个 500 字中文回答大约需要 3 分半钟。要提升速度换更高频内存、关掉后台程序都比调参更有效。4. 日常使用与性能优化4.1 上下文长度与显存的账很多人觉得 8GB 显存下牺牲点速度没关系但上下文窗口才是真正吞显存的无底洞。推理时除了权重模型还需要缓存每个 token 的 Key 和 Value也就是大家常说的 KV cache。上下文从 2048 提高到 4096KV cache 几乎翻倍显存占用立刻多出 1GB 以上。在 8GB 显卡上这 1GB 就是“稳定运行”和“动不动 OOM”的分界线。所以在配置里我建议把ctx-size当成一个“买菜预算”你今天要处理多少就开多少不要默认拉满。如果只是多轮闲聊2048 绰绰有余如果是要一次性总结长文档那更专业的做法是先切割文本再分段喂给模型而不是把窗口开到 8192。对 8GB 显存环境来说大窗口不是目标是奢侈品。4.2 接入Dify的正确姿势本地模型跑通以后大多数人还想接到 Dify 这种应用里做一个私有的对话 Agent。这一步看着简单实际踩坑的人非常多。先说基础要求本地推理服务必须已经监听本地端口并且支持 OpenAI 兼容接口。Ollama 和 llama.cpp 都支持这种接口所以 Dify 不需要安装任何特殊插件直接用“OpenAI-API-compatible”供应商接就行。如果 Dify 是用 Docker 跑在同一个台机器上的模型服务的地址不能写127.0.0.1要写host.docker.internal。这是网上报错最多的点。正确的 Base URL 长这样http://host.docker.internal:11434/v1如果是直接在宿主机上装 Dify则用http://127.0.0.1:11434/v1API Key 随意这个场景主要走本地局域网填个ollama这样的占位值即可。模型 ID 这一栏非常关键。Ollama 里填qwen2.5:32b-q2_Kllama.cpp 服务跑起来后模型 ID 不一定就是文件名建议先执行curl查一下/v1/models返回的id字段以实际返回值为准。还有一个隐藏问题Dify 默认的网络超时可能是 60 秒。本地 35B 模型生成慢第一 token 延迟动辄几秒到十几秒遇到长问题可能要 30 秒以上才开始输出。如果 Dify 的代理超时太短会直接判定请求失败。建议在 Dify 的模型供应商配置里把网络超时从 60 秒调大到 300 秒否则你会发现测试连接是通的但真正对话总是报错。4.3 并发、线程与功耗一个 35B 模型跑在 8GB 显存上已经是极限边缘别指望它同时服务很多用户。并发请求会让 CPU 内存带宽完全不够分最终所有请求都在排队看起来就像一个“假死”的服务。我的做法是明确设置单并发宁可靠队列把请求一个一个喂过去。在 Ollama 上设环境变量限制最大并行度setx OLLAMA_NUM_PARALLEL 1 setx OLLAMA_MAX_LOADED_MODELS 1llama.cpp 方面如果服务已经跑起来不要一次发大量请求让应用层的队列先去控速。llama.cpp 本身有排队机制单并发请求下问题不大。线程数方面我把-t 8作为默认值。CPU 线程开得过高反而会因为内存控制器争抢和系统调度带来额外波动。整机功耗也要注意跑 35B 时 CPU 可能长时间满载电源别买太卡极限建议留出 50% 以上的余量否则长时间跑下来容易触发保护重启。5. 常见问题与排查实录5.1 启动就OOM或显存溢出这是我在调整参数时遇到最多的现象。Ollama 启动直接崩、llama-server 打印CUDA out of memory、Windows 提示“显卡驱动已停止响应”原因基本都是同一个显存超过了物理容量。排查顺序很简单。第一步关掉所有后台能释放显存的程序浏览器、直播软件、其它模型服务。第二步把ngl往下降到 20 或更低确认能启动。第三步再每 2 层往上试探。另外检查一下ctx-size4096 以上很容易在分配 KV cache 时触发 OOM。如果这些都没问题但还是不稳定可以检查是不是 NVIDIA 驱动版本太老或者太新导致的偶发问题。我遇到过一次驱动更新后显存分配异常回滚到上一版本就恢复稳定了。5.2 生成速度慢得像“复古打字机”如果你连最简单的“你好”都要几十秒才回答这不是正常的 2~4 token/s多半是配置出了问题。先看任务管理器如果 GPU 显存占用非常低说明ngl设得不够高大量层都跑到 CPU 上去了。此时如果把ngl从 10 提到 24速度会明显改善。如果 GPU 显存占用已经很高但速度还是慢那问题多半出在内存带宽。内存带宽是硬指标。DDR4 3200 双通道的理论带宽约 51GB/s听起来很高但每个 token 都要访问模型权重一次生成需要把 CPU 侧的权重读完一遍。所以系统内存是 DDR4 还是 DDR5频率多少双通道是否开启比 CPU 主频影响大得多。还有一点不要用机械硬盘跑模型。如果权重文件放在 HDD 上每次上下文切换、内存不足触发 swap速度会跌到不可用。5.3 输出乱码、中断、回答没有逻辑量化级太低确实会导致模型表达能力下降常见表现是开始答得像模像样越到后面越放飞自我或者频繁断句、重复极端情况直接生成乱码。这时先别急着模型换 Q4。你可以从采样参数入手。我在 llama.cpp 里用这几个值--temp 0.3 --repeat-penalty 1.15 --top-k 40 --top-p 0.9把 temperature 降下来模型输出会稳定很多。Q2_K 本来就损失了信息再用高温采样等于放大了缺陷。如果换参数之后还是乱再考虑换用 IQ3_XS 量化。虽然文件只大了一点点但在逻辑清晰度和中文表达上明显比 Q2_K 稳。只跑纯聊天可以忽略但只要写点有结构的内容我建议直接用 IQ3_XS。5.4 服务端口、防火墙和Dify连接问题Ollama 默认只监听127.0.0.1这是安全问题但对局域网访问却很不方便。设了OLLAMA_HOST0.0.0.0之后必须在 Windows 防火墙里放行 11434 端口否则局域网其他设备还是连不上。llama.cpp 的默认端口是 8080如果 Dify 里已经按照 Ollama 的 11434 配过启动 llama-server 时记得用--port 11434换掉。排查连接问题时最快的方法是先看接口是否响应curl.exe http://127.0.0.1:11434/v1/models如果这里正常而 Dify 仍然报连接失败重点检查 Base URL 是否写错、Docker 容器能否访问宿主机网络、超时时间是否过短。这三个点能覆盖九成的 Dify 接入故障。6. 这套方案适合谁后续还能怎么扩展6.1 什么样的场景值得这么折腾跑通之后我的判断是这套方案不是万金油它有非常明确的适用边界。场景适用度原因离线环境下的长文本总结高能接受分钟级延迟隐私数据不出本机个人写作助手中输出偏慢但质量尚可企业内部知识库问答低并发量稍大就卡顿不如用 14B实时聊天机器人低3 token/s 基本没法做实时交互代码补全极低低量化模型写代码的错误率偏高如果你对速度的需求高于质量那 8GB 更适合用来跑 Qwen 7B 或 14B 的 Q4_K_M整体体验会远好于 35B 的 Q2。35B 方案只适合那些“必须跑大模型、又不愿意花大钱升级硬件”的场景。6.2 后续还能怎么扩展这次实测让我学到最重要的是“显存不够就用内存和量化来凑”但这条路有上限。下一步如果想继续压榨消费级显卡可以考虑两张 8GB 卡并联。llama.cpp 已经支持多 GPU 张量拆分用两张 4060 能把 GPU 侧可加载的层数提升不少不过消费级主板只有 PCIe 4x 的第二条槽带宽限制会让收益打折扣。还有一个低成本的优化方向等社区后续放出更适合低显存的量化格式比如更激进的 IQ2 系列甚至针对特定架构蒸馏出更小的开源模型。我自己现在主要留了 IQ3_XS 版本作为日常默认模型Q2_K 作为应急备份因为很多中文创作任务的最低底线是“说得通、逻辑顺”IQ3_XS 正好卡在这个线上。最后再分享一点经验不要一次性追求“一步到位”。先把 7B 或 14B 模型跑熟理解量化、上下文、KV cache 这些概念后再来碰 35B 会轻松很多。我第一次直接上 35B 时被 OOM 和各种诡异输出折磨了一整晚后来回头把知识补齐第二次整个流程只用了半小时。硬件上限就在那里但对它的理解才是真正提升体验的关键。