先说一个反直觉的结论显存只有 8GB 的消费级显卡确实能把 35B 参数量级的大模型跑起来——而且不是加载成功就完事的勉强意义上的跑是能正常对话、写代码、做问答的那种跑。我一开始也不信毕竟 35B 模型光权重文件就 20 多 GB8GB 显存连它的一半都塞不进去。直到我把模型量化到 4bit再把一大半的计算层切给 CPU亲眼看着显存吃掉 7.5GB、内存吃掉 20 多 GB然后模型一笔一画回复我我才意识到本地大模型部署这件事真正的瓶颈根本不在显卡长什么样而在于你怎么分配整台机器的算力。这篇文章是我的完整实测记录包含我用的硬件配置、每个命令行参数、跑出来的真实速度数据以及几次差点劝退的翻车经历。适合手里只有 8GB 显卡、但又想在本地跑大模型的玩家和开发者参考。看完你会发现35B 确实能跑但值不值得跑、怎么跑才不难受完全是另一个问题。1. 8GB 显存的物理账35B 模型为什么按理说装不下1.1 用字节算一笔账35B 模型说得准确点是参数数量在 340 亿到 380 亿之间的一类开源模型。参数量决定的是什么是模型权重文件的体积——本质就是一大堆矩阵数字。以最常见的 FP16半精度浮点存储方式来计算权重占用 350 亿参数 × 2 字节 ≈ 70GB如果用 FP32单精度浮点350 亿 × 4 字节 ≈ 140GB即使是 INT8 量化350 亿 × 1 字节 ≈ 35GB这组数字意味着在模型必须整体放进显存的前提下8GB 显存别说跑 35B连 14B 模型的原版权重都装不下。很多人说8GB 跑不了 35B在这个前提下是完全正确的一点没错。但这里有个关键破绽为什么模型一定要整体放显存里其实并不是。你只要接受模型跑得没那么快事情就有转机。方案就是两条腿走路量化压缩 CPU/GPU 混合推理。这也是网上各种消费级显卡跑大模型教程背后真正的原理不是玄学是实打实的算法工程。1.2 量化把高清原图压成 JPG量化是把模型权重的精度从 FP16/FP32 压到更小的位数。大家常说的 GGUF 文件就是封装好的量化模型它内部会有不同档位的压法。拿 35B 模型来说常见档位对应的大小大概是这样的量化档位说明35B 大约体积Q2_K压得最狠速度快但质量崩得明显13GB 左右Q3_K_M能看但对比 Q4 明显丢细节16GB 左右Q4_K_M公认质量/体积平衡点19~20GBQ5_K_M质量更好体积也更大23GB 左右Q6_K / Q8_0质量接近原始大体积劝退28GB 以上用生活化的话说量化就像把高清原图压成 JPG压得越狠文件越小但细节损失越明显。Q4 相当于网页用的中等质量 JPG看着还行Q2 就是马赛克只适合远观。那为什么还要用 35B 的 Q4 去打小模型的高精度版本因为参数量本身是硬通货。35B 即使打了 4bit 量化它记住的领域知识、长尾事实、逻辑链条的丰富度仍然明显强于 14B 模型。我实测下来的感受是代码补全和数学推理这两类任务35B Q4 的表现是能给我惊喜的而 14B 更多是还行。1.3 CPU/GPU 异构模型是一列火车GPU 只用一小段铁轨理解了量化下一步就是理解混合推理。llama.cppOllama 底层用的就是它提出了一个思路Transformer 模型是很多层堆叠起来的每一层都是注意力 前馈网络的结构。你可以把前 N 层放在 GPU 上计算剩下的层放到 CPU 和系统内存里计算。推理的时候输入先过 GPU 上的前 N 层算完把中间结果传给 CPUCPU 接着算后面的层算完再传回来如此接力直到生成完整的输出。这个过程中 GPU 和 CPU 在交替干活所以叫异构推理。打个比方模型推理就像一列几十节车厢的火车GPU 只是其中一段高速铁轨。火车能顺利通过这一段不代表整条线路都必须修成高铁。只要你的系统内存足够大——能装下模型权重的剩余部分——火车就能慢慢开。慢但能到站。这就是 8GB 显存跑 35B 的核心突破口。网上各种低显存跑大模型的教程本质都是这套机制区别只是调参方式llama.cpp 用--n-gpu-layers参数Ollama 用OLLAMA_NUM_GPU环境变量或 Modelfile 里的num_gpu。理解了底层逻辑后面调参才不会瞎试。2. 实测平台的成色显卡只是入场券CPU 和内存才是胜负手2.1 我这次用的具体配置先交代清楚我这套测试环境方便你对照自己的机器做判断组件配置说明显卡RTX 4060 8GB典型的甜品级消费卡8GB 显存是当前主流门槛CPUIntel i5-13600K14 核 20 线程混合推理时 CPU 侧算力直接决定下限内存64GB DDR5 5600MHz 双通道这是全篇最重要的硬件没有之一硬盘1TB NVMe SSD20GB 的模型文件SSD 能显著缩短加载时间系统Windows 11 23H2直接跑 Ollama for Windows不折腾 WSL有人会问显存 8GB 的卡那么多为什么非用 RTX 4060因为我把手头的 3060 8GB 和 4060 8GB 都测了一遍结论是对于混合推理这种模式GPU 的绝对算力确实有用但不是决定性因素——决定性的反而是 CPU 的核心数和内存带宽。这也是我一直想强调的你表面上是在考验显卡实际是在考验整台电脑的综合实力。2.2 内存带宽才是真正的硬指标这里有一个所有实测玩家都绕不开的公式。CPU 每生成一个 token一个约等于一个汉字或一个英文单词的 token都要从系统内存里把当前这一层权重的全部数据读一遍。模型越大权重越多内存带宽越窄速度就越慢。以 Q4_K_M 的 35B 模型约 20GB为例如果所有层都在 CPU 侧跑每生成一个 tokenCPU 需要读取约 20GB 的权重数据DDR5 双通道理论带宽约 50~60GB/s实际达到 70%~80% 就算不错纯 CPU 推理的理论极限 ≈ 内存带宽 ÷ 权重大小 ≈ 50GB/s ÷ 20GB ≈ 2.5 token/s这个估算值和我的实测结果非常接近。而当我让 40% 的层跑在 GPU 上CPU 每生成一个 token 只需要读剩余 12GB 左右的权重理论速度就能提到 4 token/s 上下。这就是为什么调整 GPU 层数比换一块显卡对速度的影响更立竿见影。我在测试中还试过单通道内存结果惨不忍睹带宽直接减半速度掉到 1.3 token/s 左右一个 300 字的回复要等三四分钟。所以如果你只有 8GB 显卡、16GB 内存并且是单通道那我非常不建议碰 35B老老实实跑 7B/8B 模型体验会好很多。2.3 软件层选型Ollama 还是 llama.cppWindows 上部署本地大模型主流就三条路我简单对比一下工具上手难度层数控制适合场景Ollama低环境变量 / Modelfile快速体验、日常使用一条命令拉模型llama.cpp高命令行-ngl精确控制调试排障、验证精调参效果LM Studio最低图形界面拖动滑块完全不想碰命令行的用户我这次先用 Ollama 跑通再用 llama.cpp 做对照调参。为什么这样组合因为 Ollama 把模型下载、量化、依赖管理都打包好了Windows 装完直接ollama serve就能拉模型而当你遇到速度问题、想精确控制层数时直接编译一个 llama.cpp用--n-gpu-layers的数值变化来观察最直观。两套工具共用同一个 GGUF 模型文件切换成本很低。如果你也是 Windows 11建议装完 Ollama 后做两件事一是确认 Ollama 是用管理员权限运行的二是把系统图形设置里的硬件加速 GPU 计划打开。这两点对 Ollama 的实际表现有影响很多人忽略了。3. 部署实录把 35B 塞进 8GB 显存的全过程3.1 模型选择我为什么拿 Qwen2.5-32B 当主角严格地说35B 并不是某个固定模型的名字而是对 30B~38B 参数范围模型的通用俗称。我这次的主测模型是 Qwen2.5-32B-Instruct选它有两个原因它在中文能力和代码能力上表现均衡是社区口碑较好的 30B 开源模型它恰好有 Q4_K_M 的 GGUF 量化版本文件体积 19GB 左右符合消费级环境能装载的范围如果你手里已经有别的 35B 模型比如 DeepSeek 的 34B、Yi-34B思路完全一样只是文件名不同。不要迷恋 35B 这个数字本身——模型质量的差异更多来自训练数据和架构而不是参数数量小数点后一位。下载渠道推荐两个Ollama 内置库执行ollama run qwen2.5:32b它会自动拉取一个量化版本省事HuggingFace搜索Qwen/Qwen2.5-32B-Instruct-GGUF挑 q4_k_m.gguf 文件下载用 Ollama 内置库的优点是省事缺点是你不知道它底层用的默认参数是不是最优的。所以我建议下载 GGUF 文件后自己写 Modelfile精确控制层数和上下文理由下面马上讲。3.2 用 Ollama 创建模型并启动关键参数怎么填我的做法是先把 GGUF 文件放到一个本地目录然后写一个 Modelfile内容如下FROM ./qwen2.5-32b-instruct-q4_k_m.gguf PARAMETER num_ctx 2048 PARAMETER temperature 0.7 PARAMETER num_gpu 20 PARAMETER num_thread 12接着执行ollama create qwen35b -f Modelfile ollama run qwen35b这里每个参数都有讲究解释一下num_ctx上下文窗口长度。2048 表示模型最多能看到最近的 2048 个 token。这个参数直接决定 KV cache 的显存占用。8GB 显存下 2048 是安全值开到 8192显存里的 KV cache 会迅速膨胀OOM 概率直线飙升。num_gpu放在 GPU 上的层数。Qwen2.5-32B 一共 64 层20 层意味着大约三成权重跑在 GPU 上剩下 44 层给 CPU。这个值怎么定我的经验是从 0 开始往上加直到显存占用逼近 7GB 左右就收手留 1GB 给 KV cache 和窗口余量。实测中 20 层是我这套平台的安全甜点区。num_threadCPU 线程数。不要无脑设成 CPU 全部线程。i5-13600K 有 20 线程但我实测 16 线程比 20 线程更快——线程开太满时系统线程调度和内存带宽争抢反而拖慢整体速度。物理核心数附近往往就是甜点区。如果你用 llama.cpp 直接跑等效命令是llama-cli -m qwen2.5-32b-instruct-q4_k_m.gguf -ngl 20 -c 2048 -t 12 --temp 0.7这套参数跑下来稳定生成的实测速度我放在第 4 章。先说结论比不能用好得多但和流畅不沾边。3.3 第一次启动的现场显存、内存、CPU 谁在干活第一次敲下ollama run之后我直接打开任务管理器盯着看。加载阶段是最揪心的19GB 的 GGUF 文件从 NVMe 读出来要十几秒然后是模型权重映射进系统内存CPU 占用瞬间拉满。运行起来之后的资源分布大致是这样资源状态解读GPU 显存7.4GB 左右20 层权重 部分 KV cache已经很接近极限GPU 利用率30%~55% 波动GPU 只在处理那 20 层时忙其余时间在等 CPUCPU 占用接近 100%44 层的权重读取和计算都在 CPU 侧系统内存28GB 左右模型权重 19GB KV cache 运行开销这个分布是健康的没有 OOM没有内存爆掉单纯就是慢。如果你想让模型实时显示每个 token 的生成情况可以开启 Ollama 的 verbose 模式创建模型时加PARAMETER verbose true或者在启动时设置环境变量OLLAMA_DEBUG1就能看到实时的层分配和 token 速度输出。那天晚上我还踩了一个典型的坑刚启动时我用一个特别长的中文问题去测结果模型输出了一堆和问题无关的 XML 和 JSON 结构。原因很简单——num_ctx只有 2048我的输入加上历史记录超出了窗口模型在窗口外的部分被截断只能靠上下文里的残片瞎编。这个问题我会在第 5 章专门展开。4. 实测数据速度到底是多少资源怎么分配最合理4.1 不同 GPU 层数下的速度对照我把同一份 QA 任务、同样的num_ctx2048分别跑了 GPU 分管 0 层、12 层、20 层、28 层四组每档测三轮取中位数GPU 层数显存占用生成速度首次响应延迟是否稳定0纯 CPU0.8GB2.1 token/s较长稳定内存 20GB12 层4.5GB2.8 token/s中等稳定20 层7.4GB3.9 token/s较短稳定28 层7.9GB4.5 token/s较短偶尔 OOM可以看到20 层到 28 层速度提升只有 15% 左右但 OOM 风险直线上升。28 层时显存已经到 7.9GB只要对话历史里多几个 tokenKV cache 一膨胀就直接崩。所以我的最终推荐是num_gpu20配合num_ctx2048。这个组合在 8GB 显存下留出约 0.6GB 显存余量既能消化短对话时 KV cache 的正常波动又不至于把速度压得太可怜。如果你用的是 12GB 显存的显卡可以把num_gpu提到 30 层甚至更多效果会好一截。作为参考num_ctx8192时同样 20 层显存占用会多出约 1.2GB。8GB 环境下这几乎是必然 OOM。短上下文是低显存跑大模型必须接受的代价没有太多讨价还价的空间。4.2 这些速度在实际场景里是什么体感3.9 token/s 意味着什么我用几个实际任务给出了感知写一段 150 字的工作周报约 40 秒解释一段 20 行的 Python 脚本约 1 分钟连续 5 轮日常对话每轮回答 200 字约 3 分钟生成一篇 1000 字的文章大纲约 4 分钟说实话作为 ChatGPT 重度用户这个速度会让人有点烦躁。但换个使用场景就完全不一样了你想让模型在本地处理隐私数据、断网环境下做校对、或者只是晚上慢慢打磨一个专属知识库这种速度完全够用。它的价值不在于秒回而在于数据不出门这件事本身。顺带说一句如果只是为了日常问答我强烈建议在 8GB 环境上装一个 14B 模型当主力35B 只在内容质量要求较高的场景再切过来用。两套模型共存各自发挥优势比死磕一个 35B 舒服得多。4.3 和 14B、20B 在 8GB 下的横向对比为了搞清 35B 到底值不值得硬上我在同样的 8GB 环境里又测了 14B 和 20B 模型模型量化文件体积实测速度质量体感7BQ4_K_M4.4GB25 token/s能用但明显浅薄14BQ4_K_M8.8GB11 token/s日常对话流畅20BQ4_K_M12.6GB6 token/s综合不错偶尔惊艳35BQ4_K_M19.1GB3.9 token/s质量明显高一个档次我的判断是如果你只做日常问答、写点小脚本8GB 显存配合 14B 是舒适区如果你非要 35B就要接受质量换速度的结果。35B 和 20B 的差距在我测的代码推理题和中文长文本总结上体现得最明显——35B 给出的答案结构更严谨、废话更少。但这个差距远没有参数数字翻倍那么夸张。打个比方20B 到 35B 是从合格到良好而不是从不可用到可用。5. 翻车记录这四类问题我全部踩过直接给处理思路5.1 OOM显存不足是第一大杀手OOM显存溢出是跑 35B 时最常听到的报错。我前后碰到过三次根因其实都是同一个GPU 层数调得太乐观或者上下文窗口开得太大。处理思路按顺序排查先确认num_gpu是否过高。8GB 显存实测的极限区间就是 20~24 层超过 24 层基本必翻车再确认num_ctx。2048 最安全4096 属于拼运气杀掉所有占显存的后台程序。浏览器开 20 个标签页吃掉 1GB 显存是很常见的事注意 Windows 任务管理器里GPU 专用内存和共享 GPU 内存是两回事——真正能稳定使用的是前者建议在ollama serve启动时开着资源监视器观察显存的实时余量。第一次 OOM 后我就养成了这个习惯后面两次翻车都是靠它定位到原因是num_ctx太高而不是层数太多。5.2 输出乱码和幻觉不一定是模型笨很可能是窗口被截断了这是我在 3.3 里提到的那个问题。num_ctx2048意味着模型只能看到最近的 2048 个 token。当你的对话历史加上当前输入超过这个长度旧内容被截断模型手里只剩一段残缺的上下文输出自然开始胡言乱语。解决办法有两个换更大的num_ctx比如 4096但代价是 KV cache 显存占用变大。8GB 环境下要用 4096就得把num_gpu降到 16 层左右才稳更实际的做法每次对话控制在 2~3 轮以内或者聊一会儿就用/clear清理上下文。本地模型没有云端后台帮你自动管理上下文你得自己当上下文管理员另一个容易踩的坑是把 1000 字的长文档一次性贴进去问问题那 2048 的窗口一大半就被输入占掉了模型只能照着最后几百字硬答。长文本分析在没有足够上下文空间时效果会断崖式下降——这是低显存跑大模型的硬伤不怪模型怪窗口。5.3 速度慢到怀疑人生先别急着怪显卡很多人看到 8GB 跑 35B 慢第一反应是显卡不够。但根据我在第 2 章的分析混合推理的速度瓶颈主要是内存带宽和 CPU 线程设置显卡反而是次要因素。如果你用的是 i5 或 R5 级别的 CPU、DDR4 内存想提速顺序是这样的确认内存是双通道并且开了 XMP/EXPO。单通道直接血崩这个错误很多人反复踩适当调大num_gpu到 20~24 层。这是性价比最高的一步调线程数到物理核心数附近别盲开最大线程。我实测 12 线程比 20 线程更稳有条件就换高频内存。从 DDR5 4800 换到 6000同配置下速度能提升 15%~20%关闭所有大型后台程序尤其是浏览器避免内存带宽竞争我最后一次优化是把num_gpu从 16 调到 20线程从 16 调到 12速度从 3.2 token/s 提到 3.9 token/s零成本提升 20%。很多时候慢不是因为硬件差而是参数没喂到点上。5.4 量化质量悖论为什么 35B Q4 有时还不如 14B Q8最后说一个反直觉的观察。我在侧试中发现Q4 量化的 35B 在某些复杂推理题上表现反而不如 Q8 量化的 14B。原因在于量化会引入噪声而推理链路越长、步骤越多噪声累积就越明显。简单问答场景下大参数量优势明显多步推理场景下量化精度损失可能直接吃掉参数量的优势。如果你对推理质量要求极高可以试两个方案一是用更高量级的量化版本比如 Q5_K_M接受更大的体积和更慢的速度二是把复杂任务拆成多轮每轮只问一步减少单次推理的误差累积。我在实测中把翻译并总结一段英文技术文档拆成先翻译、再单独总结两步之后输出稳定性明显提升。量化精度和任务复杂度的关系是低显存玩家真正值得花时间研究的点。最后说点实操体会。8GB 显存跑 35B 这件事技术上是可行的价值上也说得通但它有一个明确的前提你得接受慢工出细活的定位。它是给那些愿意折腾、追求数据不出门的玩家准备的一个底线方案。如果你手里恰好是 8GB 显卡我的建议是先照着这套参数跑一遍把num_gpu20、num_ctx2048当作起点然后根据你自己的 CPU 和内存带宽去微调。每台机器的脾气都不一样别人口中的根本跑不动和流畅得很都只对自己的机器成立。另外别急着换大显存显卡——先把双通道内存和高频内存安排上再回来做一轮测试。很多时候你会发现钱没花多少速度却上了一个台阶。8GB 跑 35B 是我踩过最值的坑希望这份实录能让你少走几步弯路。