这个标题听起来有点标题党但真的是我把一台普通 Windows 电脑翻出来折腾了一整天后得出的结论一块 8GB 显存的 RTX 4060确实能跑动 35B 档位的本地大模型。我说的“35B”是指 Qwen2.5-32B、Yi-34B 这类参数规模在 32B~35B 之间的开源模型。按 FP16 精度来算35B 参数要占 70GB 左右别说是 8GB 显卡就算 24GB 的 4090 也没法直接用原版精度跑。能做到这件事的关键只有两个字量化以及没写进标题里的“CPU 卸载”。整套方案跑起来之后生成速度稳定在 2~3 token/s也就是每秒吐两三个字。对实时聊天来说这个速度确实不够爽但对代码补全、文档摘要、邮件润色这类不需要秒回的任务完全能当个稳重的本地助理来用。这篇文章会把整个过程的思路、配置、调参和踩坑全部整理出来。如果你手里也只有一张 8GB 显存的消费级显卡想跑大一点的模型又不想攒钱买工作站那这篇实录应该能帮你省下不少试错时间。1. 方案拆解8GB 显存到底差在哪1.1 参数规模与显存的基本换算先算一笔硬账。一个模型的显存占用最粗的估算方式就是“参数总量 × 每个参数占用的字节数”。FP16 精度下每个参数占 2 字节35B 参数就是 35×270GB。这还没算 KV Cache 和 CUDA 计算时额外预留的空间。所以不管显卡多好直接用原版半精度权重跑这个规模是不现实的8GB 更不用谈。那 Q4_K_M 量化的意义就出来了。量化后的平均比特数大约在 4.5~5 bit换算成字节就是 0.56~0.62 字节左右。35B 参数量化到 Q4_K_M模型体量大概在 18~21GB。比如 Qwen2.5-32B-Instruct 的 Q4_K_M GGUF 文件我本地看是 20GB 出头。到这里问题变成了8GB 显存连这 20GB 都放不下怎么办答案就是层卸载。模型由 embedding 层加几十个 Transformer 层组成Qwen2.5-32B 有 64 层。我们可以把一部分层放到 GPU 上计算另一部分留在系统内存里推理时哪一层的数据在哪个设备上就由谁负责算。GPU 层处理得快内存中的层就要靠 CPU 算中间还要经过 PCIe 总线交换数据。所以 8GB 显卡跑 20GB 模型本质上就是在“显卡能装的层数”和“内存能兜的层数”之间找一个平衡点。这个平衡点找好了就是能用找不好轻则爆显存重则卡到一分钟只出几个字。1.2 为什么选择 35B 而不是 7B 或 70B可能有朋友会问8GB 显存跑 7B 不是更轻松吗确实7B 模型 Q4 量化后只有 4.5GB 左右8GB 显存完全可以放下速度也快得多。但我实测下来发现一个问题7B 模型在复杂任务上的“天花板”太明显了。让它总结短文档还行一旦涉及多步骤推理、长代码生成或者需要记忆前文细节的对话7B 模型经常会出现逻辑断档、格式崩坏、答非所问。它更像一个能执行指令的工具而不是一个有连贯思考能力的大脑。70B 模型呢按理说效果最好但 Q4 量化后也有 40GB 左右。8GB 显存只能用内存硬扛生成速度会掉到 0.5 token/s 以下每一句话都要等两三分钟基本失去实际意义。35B 正好卡在“智力够用”和“硬件能拖得动”的中间。Q4 量化后 20GBCPU 和内存的压力远小于 70B但智力表现又比 7B 高出不少。尤其是在代码生成、结构化输出、复杂指令遵循这些场景里35B 和 7B 的差距是肉眼可见的。如果你只有 8GB 显存那 35B 就是值得为之折腾一把的甜点区。1.3 我的整体路线这次实测我选的软件组合非常简单Windows 11 系统Ollama 作为模型运行时模型选择 Qwen2.5:32b 的量化版本。Ollama 是我目前用过最省事的本地模型容器。它没有复杂的 Python 环境依赖装完就是一个命令行工具直接拉模型、直接跑对话API 也兼容 OpenAI 格式。对于不想在环境配置上花太多时间的玩家这是最合适的起点。整套方案的执行顺序是先装好 Ollama确认显卡能被正常识别拉取 Qwen2.5:32b 量化模型让 Ollama 用默认策略跑一次查看启动日志和显存占用确认实际的层分配情况手动设置 GPU 层数和上下文长度找一个适合 8GB 显存的稳定配置用不同任务实测速度、显存峰值和生成质量为什么不对 Ollama 的默认行为直接放心因为默认策略在很多情况下会尝试“能放多少放多少”这可能导致一些显存碎片没有被利用也可能导致 KV Cache 被压缩得太激进。手动调整一下层数反而能更充分地利用 8GB 这张小卡。2. 核心前置动手前必须搞清楚的 3 个关键点2.1 量化精度与显存之间的取舍很多刚接触本地大模型的朋友容易在量化格式上纠结半天。这里我把常见的几个量化等级直接列出来可以很直观地看到体积差异量化格式平均每参数比特数35B 模型估算体积8GB 显存可行性FP1616 bit约 70GB完全不可行Q8_08.5 bit约 35GB不可行纯内存也太吃力Q6_K6.5 bit约 27GB勉强可配 64GB 内存速度很慢Q5_K_M5.5 bit约 23GB可行但显存能放的层更少Q4_K_M4.5 bit约 20GB我的首选方案Q3_K_M3.5 bit约 15GB显存压力更小但智力下降明显Q4_K_M 是我这次选择的格式原因是它在体积和智力之间保持了最好的平衡。低于 Q4 之后权重信息损失太多模型输出会开始出现一些逻辑上的“幻觉”优于 Q4 的 Q5_K_M体积又会多出 3GB 左右这对于 8GB 显存来说意味着更少的 GPU 层数和更慢的整体速度。还有一个容易忽略的问题量化过后模型的“思考链”能力仍然保留但细节的精准度会有轻微下降。在同一次生成里如果模型反复强调同一个概念偶尔会出现用词不太一致的情况。这在日常对话里没啥感觉但是要让它严格按照 JSON 输出或者写固定格式代码时就得靠 prompt 里的格式约束兜底。2.2 CPU 卸载与上下文长度这笔账怎么算层卸载的效果很大程度上取决于你的系统内存带宽而不是显卡显存带宽。推理时每一层都要读取该层的权重、计算激活值。GPU 层走的是显存带宽速度非常快内存中的 CPU 层走的是内存带宽速度慢一个数量级。所以 GPU 层数占比越高整体速度越快。但问题在于GPU 层数一高显存就被权重占据留给 KV Cache 的空间就变小了。KV Cache 是什么呢简单说就是模型在推理时缓存的中间计算结果用于计算注意力机制。它的大小和上下文长度直接相关。上下文越长KV Cache 越大显存吃得更狠。我实测时把上下文长度控制在 2048这样 KV Cache 大约占用 1GB 多一点剩下的 6GB 多留给权重大概能把 15~20 层放在 GPU 上。如果把上下文调到 8192KV Cache 会翻到 3~4GB能够卸载的层数就明显减少整体速度会掉到 1.5 token/s 以下。所以这笔账一定要算清楚显存总量是固定的要么多放权重层要么多留上下文空间两者不可兼得。2.3 显存占用怎么看才准确Windows 下的任务管理器虽然能看“专用 GPU 内存”但那个数值有时不太准因为 Windows 会预分配一部分显存给桌面合成器和其他图形任务。我更推荐用 NVIDIA 自带的命令行工具nvidia-smi这个命令会把显存总量、已用、模型占用、温度、功耗全部列出来一眼就能看出谁是显存大户。在跑模型之前和跑完一轮之后各执行一次对比一下差值就能知道模型实际吃掉了多少显存。我还遇到过一个特殊情况Ollama 把模型加载到显存后如果你长时间不对话它不会主动释放而是会保留一段时间。这个设计初衷是避免重复加载但对显存小的用户不太友好。如果下一轮测试想清理干净可以执行ollama stop或者直接把 Ollama 进程退出。注意Windows 下不能只看任务管理器里的“内存”栏那个是系统内存不是显存。显存要看“GPU 内存”或者用nvidia-smi查。3. 实操过程从零把 35B 跑在 8GB 上3.1 第一步装好 Ollama 并确认环境Ollama 的安装非常简单到官网下载 Windows 安装包一路 Next 就行。装完以后建议先重启一次系统让环境变量生效。打开 PowerShell输入ollama --version能看到版本号就说明装成功了。下一步是确认显卡能被 Ollama 正常识别。Ollama 没有专门的显卡检查命令但可以通过启动开发模式确认或者直接跑一个小模型试试。比如先拉一个 3B 的模型验证环境ollama run qwen3:4b如果这个小模型能正常回复说明 CPU、GPU、Ollama 三者之间的连接没问题。这个步骤很重要避免后面拉了一个 20GB 的大模型才发现环境有问题白白浪费流量。3.2 第二步拉取 Qwen2.5:32b 量化模型环境确认没问题后直接拉取目标模型ollama run qwen2.5:32b第一次运行会自动下载。这里有一个容易被忽略的点Ollama 默认使用的标签是qwen2.5:32b的默认量化版本也就是 Q4_K_M。如果你想要其他量化格式可以写成ollama run qwen2.5:32b-q4_K_M拉取过程中Ollama 会显示下载进度条。20GB 的文件量根据网络情况可能要等上一阵。如果中途断了不要慌重新执行同样的命令它会基于已经下载的部分继续续传。下载完成后执行ollama list应该能看到模型记录。接着直接启动对话ollama run qwen2.5:32b此时 Ollama 会用默认策略加载模型。我的实际体验是默认策略也能跑起来但存在两个问题一是首 token 延迟偏高二是显存占用会接近 8GB 甚至触发部分数据反复换入换出。所以接下来还是要手动优化。3.3 第三步手动分配 GPU 层数Ollama 的默认加载策略会根据显存剩余量自动决定 GPU 层数但手动控制会稳妥很多。我控制层数是通过环境变量OLLAMA_GPU_LAYERS完成的。在 Windows 里打开“编辑系统环境变量”新建用户变量OLLAMA_GPU_LAYERS18这个数字表示把模型的前 18 层放到 GPU 上其余层放在内存里。为什么是 18 而不是更多我试过 20、22、24。20 层的时候显存已经接近满负荷上下文稍长就会溢出22 层以上直接报out of memory。18 层是一个既能让 GPU 有活干又能给 KV Cache 留足空间的数值。设置完之后一定要重启 Ollama 服务。右键系统托盘里的 Ollama 图标退出再重新启动或者直接在服务管理器里重启ollama服务。不重启环境变量不会生效。重启后再次运行ollama run qwen2.5:32b这次如果用nvidia-smi盯一下应该能看到显存占用稳定在 7.5GB 左右没有爆掉。3.4 第四步实测推理与参数微调在 Ollama 的交互式对话框里直接敲一个问题它能马上开始生成。但我更建议用一次完整对话来测真实速度。方法很简单让模型写一段固定长度的内容比如让它写一篇 500 字的活动方案同时记录从按下回车到生成完毕的时间。对于更精细的调参可以在启动时追加参数。Ollama 的 run 命令支持直接传参ollama run qwen2.5:32b --num-gpu 18 --ctx-size 2048 --threads 8--num-gpu 18指定 GPU 层数--ctx-size 2048限制上下文长度--threads 8设置 CPU 线程数对内存中那部分 CPU 层很有影响我第一次没调线程数默认配置下生成速度只有 1.8 token/s 左右。把线程数从 4 调到 8 以后速度提升到了 2.5 token/s。但注意线程数也不是越大越好。线程过多会增加 CPU 内部调度和缓存竞争反而变慢。我这台机器是 8 核心的无超线程 CPU8 线程刚好是对应核心数。4. 实测数据与调参心得4.1 综合表现汇总这是我这套配置在不同阶段下的表现记录。硬件配置是RTX 4060 8GBAMD R7 5700X32GB DDR4-3200 双通道内存Windows 11 23H2。配置GPU 层数显存占用平均生成速度首 token 延迟默认策略自动约 7.9GB偶尔溢出2.1 token/s约 6 秒手动 18 层 上下文 204818约 7.5GB2.6 token/s约 3 秒手动 18 层 上下文 819218约 7.9GB1.7 token/s约 8 秒手动 10 层 上下文 204810约 6.2GB1.9 token/s约 5 秒从表格里能看出GPU 层数对速度的影响很直接但上下文长度同样会吞噬显存。默认策略之所以不稳定主要是它会在上下文较长时拼命压榨显存导致部分权重不断在显存和内存之间搬运速度不升反降。2.6 token/s 是什么概念呢输入 200 个字的场景模型生成 200 字需要大约 77 秒。看起来慢但如果是让它修改一篇文章里的几个句式或者生成一段符合格式的 JSON这个速度是完全可以接受的。而且这些任务本身也不需要实时交互等一分钟换来本地私有化部署我觉得划算。4.2 不同上下文和批处理设置的影响批处理大小也对性能有影响。Ollama 里对应的参数是--batch-size我试过 128、512、1024。默认值是 512但在 CPU 卸载模式下批处理太大反而会导致内存访问更频繁。实测时把批处理降到 256prompt 处理阶段的速度反而快了一点点。不过这个优化的收益很小远不如调整 GPU 层数来得直接。上下文长度的设置我在实际使用中总结出一个原则能 2048 就不 4096能 4096 就不 8192。因为本地跑 35B 模型本来速度就慢上下文太长的话KV Cache 占掉显存速度雪上加霜。除非你要处理非常大的文档否则 2048 足够覆盖大多数对话和文档摘要场景。如果你想同时跑多个任务Ollama 的并行度设置也需要留意。多任务并行会进一步拉高内存和显存占用8GB 显存下最好一次只加载一个大模型。4.3 效果能打吗速度慢归慢但模型智力是真的行。我主要测试了几个场景第一个是代码生成。让 Qwen2.5:32b 写一段 Python 脚本来解析 CSV 文件并输出统计结果它给出的代码结构完整注释清楚直接复制就能运行。7B 模型写同样需求经常缺 import 或者漏判边界条件差距一下子就出来了。第二个是文档总结。我给它丢了一篇三千多字的产品说明让它提炼成 5 个要点。模型准确抓住了几个核心卖点表达方式也像人写的没有那种生硬的“首先、其次”模板感。第三个是格式化输出。让它把一段口语描述转换成标准 JSON字段名和嵌套结构完全符合要求没有出现多余的解释文字。这个对本地应用开发来说太重要了省去了大量解析后处理的功夫。所以如果你能忍受生成速度35B 档次模型在智商上的优势是非常实在的。5. 常见问题与排查技巧实录5.1 拉取模型总是中断20GB 的模型文件一次拉完运气好要半小时运气不好可能要一小时。中断原因大多是网络波动。重新执行ollama run qwen2.5:32b后会基于已有分片续传但有时候 Ollama 的下载线程会卡住表现为进度条不动百分比短时间无变化。这时候我的做法是重启 Ollama 进程再执行一次。如果还是卡住打开%LOCALAPPDATA%\Ollama\server.log看看有没有 download 相关的报错。还有一招是用 Modelfile 手动导入本地已有的 GGUF 文件。把 GGUF 文件放到一个固定路径编辑一个文本文件FROM /path/to/qwen_32b_q4.gguf然后运行ollama create qwen2.5-32b-local -f Modelfile.txt这样就不依赖网络拉取了。前提是你手头有其他方式拿到这个 GGUF 文件。5.2 显存被系统占用了一部分Windows 系统本身会占掉 0.5~1GB 显存尤其是如果用显卡输出画面的话桌面合成器 DWM 会占一部分显存。这样一来8GB 实际可用可能只有 7GB 多。最有效的办法是如果你是台式机CPU 带核显的话把显示器接到主板的视频接口上让系统桌面用核显输出独显的全部显存都留给模型。如果你用的是笔记本没有这个条件那就尽量在跑模型的时候关闭浏览器和视频播放器。浏览器开几个标签页就可能占掉几百 MB 显存对 8GB 显卡来说非常致命。另外可以在nvidia-smi里看到每个进程的显存占用。如果发现有奇怪的进程占着显存不释放尝试结束它们但要确认不是系统关键进程。5.3 风扇狂转但速度却上不去这种情况我遇到过好几次特别是在 CPU 线程数设置不当的时候。8GB 显存跑 35B瓶颈不在 GPU 计算而在内存带宽和 PCIe 传输。GPU 可能并没有满载反而是 CPU 在拼命计算内存里那些层的权重风扇转得快是 CPU 风扇而不是显卡风扇。排查方法很简单开着nvidia-smi -l 1实时刷新观察 GPU 利用率。如果 GPU-Util 只有百分之二三十但 CPU 核心占用很高说明大部分层在内存里跑这种状态下再怎么调高 GPU 层数也没用显存不够就是不够。唯一能做的就是确认上下文长度已经尽量小减少 KV Cache 对显存的挤压。5.4 报错提示没有足够显存Ollama 跑大模型常见的一个报错是cudaMalloc failed: out of memory。遇到这个别慌按顺序排查先把 GPU 层数调小比如从 18 降到 12把上下文长度从 4096 降到 2048看后台还有没有其他占用显存的程序如果这些都不行可以考虑换一个更激进的量化版本比如 Q3_K_M。模型体积会减少 5GB 左右但智力会有轻微下降。我一般只在必须长上下文的情况下才这么干。还有一个隐藏問題系统内存不足。当模型层卸载到内存后内存不够也会报错但报错提示和显存不足很像。所以最好检查一下任务管理器里的内存占用32GB 内存下运行 20GB 模型加 KV Cache大概会占 13~15GB这个量级是安全的。5.5 思考型模型为什么会更吃力如果你跑的是带深度思考能力的模型比如 QwQ、DeepSeek-R1 蒸馏到 32B 的版本那每轮回答会自动生成一大段隐藏的思考过程。虽然用户感知不到但这段思考过程的 token 数往往是最终答案的好几倍。这意味着在同样的速度下用户等待正式答案的时间会更长。实测下来DeepSeek-R1-Distill-Qwen-32B 的最终答案生成速度也在 2.5 token/s 左右但思考阶段可能要等两三分钟。如果要拿给同事现场演示可能要做好心理准备。如果你对速度敏感只想要稳定输出选普通 Instruct 模型就好如果你重视推理深度能接受等待那思考型模型会给你惊喜。6. 写给同样在低显存上折腾的人实际跑了这么一圈我最大的体会是8GB 显存跑 35B完全可行的前提是接受它的节奏。它不是那种打开网页就能聊天的交互式服务更像一个需要耐心的任务处理员。你给它一个明确的任务让它慢慢处理它能给出远超出 7B 模型的回答质量。如果你打算模仿这套方案我建议先从 14B 甚至 7B 规模的模型开始跑通 Ollama 的整个链路确认显存监控、环境变量、层数控制这些操作都熟了再上 35B。一步到位不是不行但出了问题你会很难判断到底是模型问题、量化问题还是环境配置问题。最后分享一个我踩过几次坑之后总结出来的小技巧跑大模型之前先执行一次ollama stop --all把之前加载过的其他模型全部释放掉。否则残留的小模型也会占显存8GB 的余量本来就紧经不起这种隐性浪费。低显存跑大模型本质上是在显存、内存、时间和效果之间做权衡。你不可能全都要但把一个方面做到极致就已经能获得相当满意的本地 AI 体验了。
8GB显存跑35B大模型：量化+CPU卸载实战实录
这个标题听起来有点标题党但真的是我把一台普通 Windows 电脑翻出来折腾了一整天后得出的结论一块 8GB 显存的 RTX 4060确实能跑动 35B 档位的本地大模型。我说的“35B”是指 Qwen2.5-32B、Yi-34B 这类参数规模在 32B~35B 之间的开源模型。按 FP16 精度来算35B 参数要占 70GB 左右别说是 8GB 显卡就算 24GB 的 4090 也没法直接用原版精度跑。能做到这件事的关键只有两个字量化以及没写进标题里的“CPU 卸载”。整套方案跑起来之后生成速度稳定在 2~3 token/s也就是每秒吐两三个字。对实时聊天来说这个速度确实不够爽但对代码补全、文档摘要、邮件润色这类不需要秒回的任务完全能当个稳重的本地助理来用。这篇文章会把整个过程的思路、配置、调参和踩坑全部整理出来。如果你手里也只有一张 8GB 显存的消费级显卡想跑大一点的模型又不想攒钱买工作站那这篇实录应该能帮你省下不少试错时间。1. 方案拆解8GB 显存到底差在哪1.1 参数规模与显存的基本换算先算一笔硬账。一个模型的显存占用最粗的估算方式就是“参数总量 × 每个参数占用的字节数”。FP16 精度下每个参数占 2 字节35B 参数就是 35×270GB。这还没算 KV Cache 和 CUDA 计算时额外预留的空间。所以不管显卡多好直接用原版半精度权重跑这个规模是不现实的8GB 更不用谈。那 Q4_K_M 量化的意义就出来了。量化后的平均比特数大约在 4.5~5 bit换算成字节就是 0.56~0.62 字节左右。35B 参数量化到 Q4_K_M模型体量大概在 18~21GB。比如 Qwen2.5-32B-Instruct 的 Q4_K_M GGUF 文件我本地看是 20GB 出头。到这里问题变成了8GB 显存连这 20GB 都放不下怎么办答案就是层卸载。模型由 embedding 层加几十个 Transformer 层组成Qwen2.5-32B 有 64 层。我们可以把一部分层放到 GPU 上计算另一部分留在系统内存里推理时哪一层的数据在哪个设备上就由谁负责算。GPU 层处理得快内存中的层就要靠 CPU 算中间还要经过 PCIe 总线交换数据。所以 8GB 显卡跑 20GB 模型本质上就是在“显卡能装的层数”和“内存能兜的层数”之间找一个平衡点。这个平衡点找好了就是能用找不好轻则爆显存重则卡到一分钟只出几个字。1.2 为什么选择 35B 而不是 7B 或 70B可能有朋友会问8GB 显存跑 7B 不是更轻松吗确实7B 模型 Q4 量化后只有 4.5GB 左右8GB 显存完全可以放下速度也快得多。但我实测下来发现一个问题7B 模型在复杂任务上的“天花板”太明显了。让它总结短文档还行一旦涉及多步骤推理、长代码生成或者需要记忆前文细节的对话7B 模型经常会出现逻辑断档、格式崩坏、答非所问。它更像一个能执行指令的工具而不是一个有连贯思考能力的大脑。70B 模型呢按理说效果最好但 Q4 量化后也有 40GB 左右。8GB 显存只能用内存硬扛生成速度会掉到 0.5 token/s 以下每一句话都要等两三分钟基本失去实际意义。35B 正好卡在“智力够用”和“硬件能拖得动”的中间。Q4 量化后 20GBCPU 和内存的压力远小于 70B但智力表现又比 7B 高出不少。尤其是在代码生成、结构化输出、复杂指令遵循这些场景里35B 和 7B 的差距是肉眼可见的。如果你只有 8GB 显存那 35B 就是值得为之折腾一把的甜点区。1.3 我的整体路线这次实测我选的软件组合非常简单Windows 11 系统Ollama 作为模型运行时模型选择 Qwen2.5:32b 的量化版本。Ollama 是我目前用过最省事的本地模型容器。它没有复杂的 Python 环境依赖装完就是一个命令行工具直接拉模型、直接跑对话API 也兼容 OpenAI 格式。对于不想在环境配置上花太多时间的玩家这是最合适的起点。整套方案的执行顺序是先装好 Ollama确认显卡能被正常识别拉取 Qwen2.5:32b 量化模型让 Ollama 用默认策略跑一次查看启动日志和显存占用确认实际的层分配情况手动设置 GPU 层数和上下文长度找一个适合 8GB 显存的稳定配置用不同任务实测速度、显存峰值和生成质量为什么不对 Ollama 的默认行为直接放心因为默认策略在很多情况下会尝试“能放多少放多少”这可能导致一些显存碎片没有被利用也可能导致 KV Cache 被压缩得太激进。手动调整一下层数反而能更充分地利用 8GB 这张小卡。2. 核心前置动手前必须搞清楚的 3 个关键点2.1 量化精度与显存之间的取舍很多刚接触本地大模型的朋友容易在量化格式上纠结半天。这里我把常见的几个量化等级直接列出来可以很直观地看到体积差异量化格式平均每参数比特数35B 模型估算体积8GB 显存可行性FP1616 bit约 70GB完全不可行Q8_08.5 bit约 35GB不可行纯内存也太吃力Q6_K6.5 bit约 27GB勉强可配 64GB 内存速度很慢Q5_K_M5.5 bit约 23GB可行但显存能放的层更少Q4_K_M4.5 bit约 20GB我的首选方案Q3_K_M3.5 bit约 15GB显存压力更小但智力下降明显Q4_K_M 是我这次选择的格式原因是它在体积和智力之间保持了最好的平衡。低于 Q4 之后权重信息损失太多模型输出会开始出现一些逻辑上的“幻觉”优于 Q4 的 Q5_K_M体积又会多出 3GB 左右这对于 8GB 显存来说意味着更少的 GPU 层数和更慢的整体速度。还有一个容易忽略的问题量化过后模型的“思考链”能力仍然保留但细节的精准度会有轻微下降。在同一次生成里如果模型反复强调同一个概念偶尔会出现用词不太一致的情况。这在日常对话里没啥感觉但是要让它严格按照 JSON 输出或者写固定格式代码时就得靠 prompt 里的格式约束兜底。2.2 CPU 卸载与上下文长度这笔账怎么算层卸载的效果很大程度上取决于你的系统内存带宽而不是显卡显存带宽。推理时每一层都要读取该层的权重、计算激活值。GPU 层走的是显存带宽速度非常快内存中的 CPU 层走的是内存带宽速度慢一个数量级。所以 GPU 层数占比越高整体速度越快。但问题在于GPU 层数一高显存就被权重占据留给 KV Cache 的空间就变小了。KV Cache 是什么呢简单说就是模型在推理时缓存的中间计算结果用于计算注意力机制。它的大小和上下文长度直接相关。上下文越长KV Cache 越大显存吃得更狠。我实测时把上下文长度控制在 2048这样 KV Cache 大约占用 1GB 多一点剩下的 6GB 多留给权重大概能把 15~20 层放在 GPU 上。如果把上下文调到 8192KV Cache 会翻到 3~4GB能够卸载的层数就明显减少整体速度会掉到 1.5 token/s 以下。所以这笔账一定要算清楚显存总量是固定的要么多放权重层要么多留上下文空间两者不可兼得。2.3 显存占用怎么看才准确Windows 下的任务管理器虽然能看“专用 GPU 内存”但那个数值有时不太准因为 Windows 会预分配一部分显存给桌面合成器和其他图形任务。我更推荐用 NVIDIA 自带的命令行工具nvidia-smi这个命令会把显存总量、已用、模型占用、温度、功耗全部列出来一眼就能看出谁是显存大户。在跑模型之前和跑完一轮之后各执行一次对比一下差值就能知道模型实际吃掉了多少显存。我还遇到过一个特殊情况Ollama 把模型加载到显存后如果你长时间不对话它不会主动释放而是会保留一段时间。这个设计初衷是避免重复加载但对显存小的用户不太友好。如果下一轮测试想清理干净可以执行ollama stop或者直接把 Ollama 进程退出。注意Windows 下不能只看任务管理器里的“内存”栏那个是系统内存不是显存。显存要看“GPU 内存”或者用nvidia-smi查。3. 实操过程从零把 35B 跑在 8GB 上3.1 第一步装好 Ollama 并确认环境Ollama 的安装非常简单到官网下载 Windows 安装包一路 Next 就行。装完以后建议先重启一次系统让环境变量生效。打开 PowerShell输入ollama --version能看到版本号就说明装成功了。下一步是确认显卡能被 Ollama 正常识别。Ollama 没有专门的显卡检查命令但可以通过启动开发模式确认或者直接跑一个小模型试试。比如先拉一个 3B 的模型验证环境ollama run qwen3:4b如果这个小模型能正常回复说明 CPU、GPU、Ollama 三者之间的连接没问题。这个步骤很重要避免后面拉了一个 20GB 的大模型才发现环境有问题白白浪费流量。3.2 第二步拉取 Qwen2.5:32b 量化模型环境确认没问题后直接拉取目标模型ollama run qwen2.5:32b第一次运行会自动下载。这里有一个容易被忽略的点Ollama 默认使用的标签是qwen2.5:32b的默认量化版本也就是 Q4_K_M。如果你想要其他量化格式可以写成ollama run qwen2.5:32b-q4_K_M拉取过程中Ollama 会显示下载进度条。20GB 的文件量根据网络情况可能要等上一阵。如果中途断了不要慌重新执行同样的命令它会基于已经下载的部分继续续传。下载完成后执行ollama list应该能看到模型记录。接着直接启动对话ollama run qwen2.5:32b此时 Ollama 会用默认策略加载模型。我的实际体验是默认策略也能跑起来但存在两个问题一是首 token 延迟偏高二是显存占用会接近 8GB 甚至触发部分数据反复换入换出。所以接下来还是要手动优化。3.3 第三步手动分配 GPU 层数Ollama 的默认加载策略会根据显存剩余量自动决定 GPU 层数但手动控制会稳妥很多。我控制层数是通过环境变量OLLAMA_GPU_LAYERS完成的。在 Windows 里打开“编辑系统环境变量”新建用户变量OLLAMA_GPU_LAYERS18这个数字表示把模型的前 18 层放到 GPU 上其余层放在内存里。为什么是 18 而不是更多我试过 20、22、24。20 层的时候显存已经接近满负荷上下文稍长就会溢出22 层以上直接报out of memory。18 层是一个既能让 GPU 有活干又能给 KV Cache 留足空间的数值。设置完之后一定要重启 Ollama 服务。右键系统托盘里的 Ollama 图标退出再重新启动或者直接在服务管理器里重启ollama服务。不重启环境变量不会生效。重启后再次运行ollama run qwen2.5:32b这次如果用nvidia-smi盯一下应该能看到显存占用稳定在 7.5GB 左右没有爆掉。3.4 第四步实测推理与参数微调在 Ollama 的交互式对话框里直接敲一个问题它能马上开始生成。但我更建议用一次完整对话来测真实速度。方法很简单让模型写一段固定长度的内容比如让它写一篇 500 字的活动方案同时记录从按下回车到生成完毕的时间。对于更精细的调参可以在启动时追加参数。Ollama 的 run 命令支持直接传参ollama run qwen2.5:32b --num-gpu 18 --ctx-size 2048 --threads 8--num-gpu 18指定 GPU 层数--ctx-size 2048限制上下文长度--threads 8设置 CPU 线程数对内存中那部分 CPU 层很有影响我第一次没调线程数默认配置下生成速度只有 1.8 token/s 左右。把线程数从 4 调到 8 以后速度提升到了 2.5 token/s。但注意线程数也不是越大越好。线程过多会增加 CPU 内部调度和缓存竞争反而变慢。我这台机器是 8 核心的无超线程 CPU8 线程刚好是对应核心数。4. 实测数据与调参心得4.1 综合表现汇总这是我这套配置在不同阶段下的表现记录。硬件配置是RTX 4060 8GBAMD R7 5700X32GB DDR4-3200 双通道内存Windows 11 23H2。配置GPU 层数显存占用平均生成速度首 token 延迟默认策略自动约 7.9GB偶尔溢出2.1 token/s约 6 秒手动 18 层 上下文 204818约 7.5GB2.6 token/s约 3 秒手动 18 层 上下文 819218约 7.9GB1.7 token/s约 8 秒手动 10 层 上下文 204810约 6.2GB1.9 token/s约 5 秒从表格里能看出GPU 层数对速度的影响很直接但上下文长度同样会吞噬显存。默认策略之所以不稳定主要是它会在上下文较长时拼命压榨显存导致部分权重不断在显存和内存之间搬运速度不升反降。2.6 token/s 是什么概念呢输入 200 个字的场景模型生成 200 字需要大约 77 秒。看起来慢但如果是让它修改一篇文章里的几个句式或者生成一段符合格式的 JSON这个速度是完全可以接受的。而且这些任务本身也不需要实时交互等一分钟换来本地私有化部署我觉得划算。4.2 不同上下文和批处理设置的影响批处理大小也对性能有影响。Ollama 里对应的参数是--batch-size我试过 128、512、1024。默认值是 512但在 CPU 卸载模式下批处理太大反而会导致内存访问更频繁。实测时把批处理降到 256prompt 处理阶段的速度反而快了一点点。不过这个优化的收益很小远不如调整 GPU 层数来得直接。上下文长度的设置我在实际使用中总结出一个原则能 2048 就不 4096能 4096 就不 8192。因为本地跑 35B 模型本来速度就慢上下文太长的话KV Cache 占掉显存速度雪上加霜。除非你要处理非常大的文档否则 2048 足够覆盖大多数对话和文档摘要场景。如果你想同时跑多个任务Ollama 的并行度设置也需要留意。多任务并行会进一步拉高内存和显存占用8GB 显存下最好一次只加载一个大模型。4.3 效果能打吗速度慢归慢但模型智力是真的行。我主要测试了几个场景第一个是代码生成。让 Qwen2.5:32b 写一段 Python 脚本来解析 CSV 文件并输出统计结果它给出的代码结构完整注释清楚直接复制就能运行。7B 模型写同样需求经常缺 import 或者漏判边界条件差距一下子就出来了。第二个是文档总结。我给它丢了一篇三千多字的产品说明让它提炼成 5 个要点。模型准确抓住了几个核心卖点表达方式也像人写的没有那种生硬的“首先、其次”模板感。第三个是格式化输出。让它把一段口语描述转换成标准 JSON字段名和嵌套结构完全符合要求没有出现多余的解释文字。这个对本地应用开发来说太重要了省去了大量解析后处理的功夫。所以如果你能忍受生成速度35B 档次模型在智商上的优势是非常实在的。5. 常见问题与排查技巧实录5.1 拉取模型总是中断20GB 的模型文件一次拉完运气好要半小时运气不好可能要一小时。中断原因大多是网络波动。重新执行ollama run qwen2.5:32b后会基于已有分片续传但有时候 Ollama 的下载线程会卡住表现为进度条不动百分比短时间无变化。这时候我的做法是重启 Ollama 进程再执行一次。如果还是卡住打开%LOCALAPPDATA%\Ollama\server.log看看有没有 download 相关的报错。还有一招是用 Modelfile 手动导入本地已有的 GGUF 文件。把 GGUF 文件放到一个固定路径编辑一个文本文件FROM /path/to/qwen_32b_q4.gguf然后运行ollama create qwen2.5-32b-local -f Modelfile.txt这样就不依赖网络拉取了。前提是你手头有其他方式拿到这个 GGUF 文件。5.2 显存被系统占用了一部分Windows 系统本身会占掉 0.5~1GB 显存尤其是如果用显卡输出画面的话桌面合成器 DWM 会占一部分显存。这样一来8GB 实际可用可能只有 7GB 多。最有效的办法是如果你是台式机CPU 带核显的话把显示器接到主板的视频接口上让系统桌面用核显输出独显的全部显存都留给模型。如果你用的是笔记本没有这个条件那就尽量在跑模型的时候关闭浏览器和视频播放器。浏览器开几个标签页就可能占掉几百 MB 显存对 8GB 显卡来说非常致命。另外可以在nvidia-smi里看到每个进程的显存占用。如果发现有奇怪的进程占着显存不释放尝试结束它们但要确认不是系统关键进程。5.3 风扇狂转但速度却上不去这种情况我遇到过好几次特别是在 CPU 线程数设置不当的时候。8GB 显存跑 35B瓶颈不在 GPU 计算而在内存带宽和 PCIe 传输。GPU 可能并没有满载反而是 CPU 在拼命计算内存里那些层的权重风扇转得快是 CPU 风扇而不是显卡风扇。排查方法很简单开着nvidia-smi -l 1实时刷新观察 GPU 利用率。如果 GPU-Util 只有百分之二三十但 CPU 核心占用很高说明大部分层在内存里跑这种状态下再怎么调高 GPU 层数也没用显存不够就是不够。唯一能做的就是确认上下文长度已经尽量小减少 KV Cache 对显存的挤压。5.4 报错提示没有足够显存Ollama 跑大模型常见的一个报错是cudaMalloc failed: out of memory。遇到这个别慌按顺序排查先把 GPU 层数调小比如从 18 降到 12把上下文长度从 4096 降到 2048看后台还有没有其他占用显存的程序如果这些都不行可以考虑换一个更激进的量化版本比如 Q3_K_M。模型体积会减少 5GB 左右但智力会有轻微下降。我一般只在必须长上下文的情况下才这么干。还有一个隐藏問題系统内存不足。当模型层卸载到内存后内存不够也会报错但报错提示和显存不足很像。所以最好检查一下任务管理器里的内存占用32GB 内存下运行 20GB 模型加 KV Cache大概会占 13~15GB这个量级是安全的。5.5 思考型模型为什么会更吃力如果你跑的是带深度思考能力的模型比如 QwQ、DeepSeek-R1 蒸馏到 32B 的版本那每轮回答会自动生成一大段隐藏的思考过程。虽然用户感知不到但这段思考过程的 token 数往往是最终答案的好几倍。这意味着在同样的速度下用户等待正式答案的时间会更长。实测下来DeepSeek-R1-Distill-Qwen-32B 的最终答案生成速度也在 2.5 token/s 左右但思考阶段可能要等两三分钟。如果要拿给同事现场演示可能要做好心理准备。如果你对速度敏感只想要稳定输出选普通 Instruct 模型就好如果你重视推理深度能接受等待那思考型模型会给你惊喜。6. 写给同样在低显存上折腾的人实际跑了这么一圈我最大的体会是8GB 显存跑 35B完全可行的前提是接受它的节奏。它不是那种打开网页就能聊天的交互式服务更像一个需要耐心的任务处理员。你给它一个明确的任务让它慢慢处理它能给出远超出 7B 模型的回答质量。如果你打算模仿这套方案我建议先从 14B 甚至 7B 规模的模型开始跑通 Ollama 的整个链路确认显存监控、环境变量、层数控制这些操作都熟了再上 35B。一步到位不是不行但出了问题你会很难判断到底是模型问题、量化问题还是环境配置问题。最后分享一个我踩过几次坑之后总结出来的小技巧跑大模型之前先执行一次ollama stop --all把之前加载过的其他模型全部释放掉。否则残留的小模型也会占显存8GB 的余量本来就紧经不起这种隐性浪费。低显存跑大模型本质上是在显存、内存、时间和效果之间做权衡。你不可能全都要但把一个方面做到极致就已经能获得相当满意的本地 AI 体验了。
