8GB显存跑35B大模型：量化与卸载实战全记录

很多人第一眼看到“消费级显卡本地大模型实测8GB 跑 35B”第一反应多半是标题党。毕竟常识摆在那里30B 级别的模型光权重文件用 FP16 精度存下来就得 60GB 以上8GB 显存连塞个零头都不够。但实测下来可以负责任地说这件事确实能做而且不是靠什么黑科技硬撑是靠量化、卸载、调度这三板斧老老实实跑通的。如果你手里的显卡恰恰是 RTX 3060、4060、3070 这些 8GB 显存的主流消费级型号又想在本地跑一个比 7B、8B 小模型聪明得多的 35B 大模型那这篇实录就是给你准备的。我会把从环境准备、模型选型、Ollama 部署、参数调整到实测数据的完整过程都摊开讲包括那些文档里不会写的坑。整个过程不需要改硬件、不需要魔改驱动只需要你愿意折腾一个晚上。先说结论8GB 显存跑 35B 模型生成速度大概在 7 到 12 token/s 之间取决于你的内存带宽和量化等级。这个速度没法跟云端 API 比但作为本地私密部署能换来比 7B/14B 明显高一个档次的回答质量我觉得值。下面开始完整实录。1. 8GB 显存跑 35B量化与卸载的底层逻辑1.1 为什么常规思维认为这事不可能先捋一下模型体积这个概念。以 Qwen2.5-35B 为例35B 指的是模型有 350 亿个参数。每个参数如果按 FP16半精度浮点数存储占 2 字节那么光权重就是 350 × 2 70GB。这还没算 KV cache、激活值这些运行时开销。8GB 显存想去直接加载连零头都不够。即使把精度降到 INT81 字节/参数模型也要 35GB 左右。所以 8GB 显存跑 35B本质上只有一个可行路径低比特量化4bit 甚至更低加 GPU/CPU 混合卸载。4bit 量化后的模型权重体积大约是 FP16 的四分之一35B × 0.5 字节 ≈ 17.5GB 到 21GB不同量化方法略有差异。这个体积依然超过 8GB 显存但好在超过了不多可以通过把部分层放到系统内存里来解决。1.2 关键角色K-quant 量化与 GGUF 格式Ollama 加载模型走的是 llama.cpp 那一套生态模型文件格式是 GGUF。GGUF 背后有一套量化方案其中最常见的是 K-quant 系列比如 Q4_K_M、Q5_K_M、Q6_K。这里解释一下Q4_K_M 不是简单的“把每个权重四舍五入到 4bit”它其实是混合精度量化大部分权重用 4bit但关键的 attention 层或其他敏感部分保留 5bit、6bit 甚至更高精度然后再用一个小的 FP16 block scale 做缩放。这种设计在压缩率和质量损失之间找到了一个很好的平衡点实测下来 Q4_K_M 在 35B 模型上的回答质量跟 FP16 相比损失很小推理速度损失却非常小。推荐 Q4_K_M是因为它是目前 8GB 显存能跑 35B 的“甜点参数”。Q3_K 虽然更小但质量下降开始明显很多场景下你能感觉到模型“变蠢了”。Q5_K_M 质量更好但体积逼近 22GB内存压力太大生成速度会明显下滑。1.3 GPU/CPU 混合卸载llama.cpp 的层分配机制Ollama 底层用的 llama.cpp 支持一个核心特性把模型按层拆分前 N 层放在 GPU 显存后面的层放在系统内存推理时两者协同计算。这里有个关键参数叫num_gpu在 Ollama 里对应OLLAMA_NUM_GPU或者通过 Modelfile 里设置。它控制加载多少层到 GPU。模型总共有多少层是可以查的以 Qwen2.5-35B-Instruct 为例大概是 64 层 Transformer 层加 embedding 等。8GB 显存大概能放下 20 到 25 层剩余几十层交给内存里的 CPU 跑。这个分配逻辑用大白话解释就是显卡和 CPU 像两个人接力搬砖。显卡搬得快但“口袋小”一次只能装几块砖CPU 搬得慢但“仓库大”可以存很多砖。两人必须步调一致地配合任何一个人拖后腿都会影响整体速度。实测下来层分配是否均匀对 token/s 的影响非常大后面调优部分我会给出具体的分配策略。1.4 显存装不下的部分内存带宽决定生死当模型的后半部分跑在 CPU 上时系统内存带宽就成了真正的瓶颈。每一轮推理CPU 都要从内存里把几十 GB 的权重读一遍。DDR4-3200 双通道的带宽大约 50GB/sDDR5-4800 双通道能到 76GB/s而 GDDR6 显存带宽普遍在 200GB/s 以上。这个差距直接反映在生成速度上。同样的 35B 模型如果全部由显存承载比如 24GB 显卡生成速度能到 40 到 60 token/s落到 8GB 显存 内存卸载的场景大概率只能跑到 7 到 12 token/s。所以如果你觉得速度慢先别急着怪显卡你的内存频率和通道数可能才是主犯。2. 实测环境与工具选型这些硬件和软件搭配经过验证2.1 实测主机配置清单先把实测用的机器配置亮出来方便你对比自己的情况显卡RTX 4060 8GB笔记本版本功率受限桌面版会略快处理器Intel i7-13620H10 核 16 线程其中 6 个性能核 4 个能效核内存32GB DDR5-4800 双通道硬盘NVMe SSD 1TB系统盘和模型盘同一块系统Windows 11 23H2软件Ollama 0.3.x版本更新很快建议装最新版这套配置大概是 2023 到 2024 年主流游戏本的典型水平。如果你用的是台式机配 RTX 3060 12GB 或者 RTX 4060 8GB 桌面版效果只会更好因为桌面 GPU 的功耗墙更宽松。2.2 为什么选 Ollama 而不是直接裸用 llama.cpp可能有人会说直接用 llama.cpp 命令行不是更“纯净”吗确实可以但对于多数人来说没必要。Ollama 的价值在于它把模型下载、量化选择、运行参数、API 服务全封装好了一个ollama run命令搞定。而且 Ollama 在 Windows 上提供了很好的 GPU 检测和层卸载支持不需要你手动去编译 CUDA 版本。如果你是有经验的开发者想要精细控制推理参数可以直接调用 Ollama 的 REST API它暴露了/api/generate和/api/chat接口写个 Python 脚本就能对接。这也是后面我会讲的落地方式。2.3 模型选型为什么最终锁定 Qwen2.5-35B实测选择了通义千问家族的 Qwen2.5-35B-InstructGGUF Q4_K_M 量化版原因有三个第一35B 这个参数规模在开源模型里属于“性价比拐点”。7B 和 14B 模型虽然快但在复杂推理、长文本理解、代码生成方面明显吃力70B 模型质量更高但在 8GB 显存环境下即使量化也很难跑得动——70B 的 4bit 量化体积有 40GB 左右内存占用太夸张。35B 刚好卡在“能跑”和“聪明”的交叉点上。第二Qwen2.5 系列本身的中文能力在开源阵营里是第一梯队。它的训练数据里中文占比很高回答国内用户常见问题、处理中文长文本、生成中文代码注释效果明显比同规模的 Llama 系模型好。第三Ollama 的模型仓库里直接就有qwen2.5:35b标签拉取即用不需要去 Hugging Face 手动下 GGUF 文件再写 Modelfile。对新手很友好。3. 完整部署实操从零到跑起来每一步都有记录3.1 安装 Ollama 与基础设置Ollama 的 Windows 版安装包可以直接从官网下载安装过程没什么特别之处一路下一步就行。装完之后先别急着拉模型做三件事。第一件事确认 GPU 能被 Ollama 识别。打开终端执行ollama --version然后看看安装目录下有没有ollama.exe和配套的 CUDA 运行库。通常安装包会自动带上适合本机的 CUDA 版本。第二件事确认显存和内存状态。用任务管理器切到“性能”标签记下 GPU 专用 GPU 内存也就是 8GB和共享 GPU 内存一般会显示系统内存的一半。Ollama 主要占用的是“专用 GPU 内存”但共享部分也会用到。第三件事设置环境变量。Windows 下按 Win 键搜索“环境变量”打开后新建系统变量OLLAMA_NUM_GPU20 OLLAMA_KEEP_ALIVE10m OLLAMA_MODELSC:\ollama_modelsOLLAMA_NUM_GPU20是手动指定加载 20 层到 GPU。为什么是 20 而不是 24 或 16这个数值我是在反复调整后得出的最优解后面调优章节详聊。OLLAMA_KEEP_ALIVE10m是让模型在内存里驻留 10 分钟避免每次提问都重新加载模型那要几十秒。OLLAMA_MODELS作用是自定义模型存放路径如果不设置默认在 C 盘用户目录下很容易把系统盘塞满。改完环境变量后需要重启 Ollama 服务才生效。可以在任务管理器里结束 Ollama 的进程或者直接在终端执行ollama serve重新启动。3.2 拉取模型并验证显存占用设置完环境变量后开始拉模型ollama pull qwen2.5:35b这个模型对应的是 Q4_K_M 量化版大小大约 20GB。下载速度取决于你的网络一般来说 10 到 30 分钟不等。下载完成后先跑一个最简单的测试ollama run qwen2.5:35b 你好用一句话介绍你自己。第一次运行会有一个模型加载过程需要十几秒到几十秒。这时候立刻切到任务管理器看 GPU 显存占用如果显存占用接近 7.5GB说明 GPU 层分配生效了如果只有几百 MB那就说明模型全部跑在 CPU 上速度会惨不忍睹。实测中第一次运行因为系统还在做 CUDA 初始化显存占用可能不稳定多跑两次再下结论。3.3 针对 8GB 显存的 Modelfile 调优光靠环境变量还不够Ollama 允许通过 Modelfile 对推理参数做更细的控制。在终端执行ollama show --modelfile qwen2.5:35b会看到默认的 Modelfile包含了参数模板。我建议单独创建一个调好参数的模型副本ollama create qwen35b-8g -f ModelfileModelfile 内容如下直接用记事本创建即可注意编码用 UTF-8FROM qwen2.5:35b PARAMETER num_ctx 4096 PARAMETER num_gpu 20 PARAMETER num_batch 256 PARAMETER temperature 0.7这里几个参数解释一下num_ctx 4096上下文窗口长度。35B 模型在 8GB 显存下能负担的 KV cache 有限4096 是稳定值。如果你有耐心调可以慢慢往上试探到 8192但显存压力会明显增大甚至可能导致显存溢出直接报错。num_gpu 20明确把前 20 层放到 GPU跟环境变量保持一致。num_batch 256批量推理大小。这个值偏大会增加显存里的中间激活值占用但能提高一定吞吐。实测中 256 比默认值稍微快一两个 token/s。temperature 0.7采样温度。0.7 是一个平衡创造性和准确性的值。如果你只是做事实性问答建议降到 0.3 到 0.5。设置完成后用ollama run qwen35b-8g来启动这个定制模型。3.4 首次长对话实测验证它真的“能干活”模型跑起来后我没有立刻跑 benchmark而是先做了一轮真实场景问答验证它到底是不是“能用”。我连续问了十几个问题涵盖代码解释、文案写作、数学推理、知识问答几类“用 Python 写一个装饰器记录函数执行时间”“解释一下数据库事务的 ACID 特性”“以‘雨中城市’为题写一段 200 字散文”“27 的 4 次方根是多少给出计算过程”各项表现总结如下代码生成能写出完整可运行的装饰器注释清晰但偶尔会有小的语法冗余。知识问答ACID 解释准确层次分明。长文本生成时的连贯性明显好于 7B 模型不会出现前言不搭后语的情况。数学推理27 的四次方根给出了完整过程结果正确。这种多步推理在 7B 模型上经常出错35B 的表现确实上了一个台阶。第一次完整对话包含加载时间从输入到拿到完整回复大约花了 3 分钟实际生成速度大约 9 token/s。这个速度不急不躁但等待时确实能感觉到它在“思考”。4. 性能调优与实测数据速度、质量与资源占用全记录4.1 层分配调优反复试验后得出的最优解num_gpu这个参数是 8GB 显存跑大模型的“胜负手”。我花了大概两个小时来回调整记录如下num_gpu 值显存占用首 token 延迟生成速度表现0纯 CPU0.2GB约 15 秒1.5 token/s慢到无法使用104.1GB约 8 秒4.2 token/s偏慢CPU 负载很高165.8GB约 5 秒6.8 token/s可用但仍偏慢207.2GB约 3 秒9.3 token/s甜点区间速度/稳定兼备227.8GB约 2.5 秒8.1 token/s偶发显存溢出不稳248.0GB约 2 秒无法稳定频繁 OOM为什么 20 是最优点这涉及 GPU 显存里的资源竞争。除了模型权重还有 KV cache、激活值、CUDA context 都要占用显存。当你把 22 层塞进 GPU 时余量只剩不到 0.2GB一旦num_batch稍微调大或者上下文变长就直接爆显存。反而 20 层时留出约 0.8GB 余量整个推理过程更稳定生成速度也不会因为频繁的内存交换而掉速。另外发现一个反直觉的现象num_gpu从 16 升到 20 时生成速度从 6.8 涨到 9.3但再往 22 调速度反而掉到 8.1。原因很可能是显存余量不足时llama.cpp 内部的显存碎片整理和重新分配开销变大了得不偿失。提示调num_gpu时要盯住一个指标——任务管理器里 GPU 的“专用 GPU 内存”占用。如果长期贴着 7.9GB 跑说明你离 OOM 只有一步务必降一档。4.2 量化等级对比Q4_K_M 到底牺牲了什么为了评估量化对回答质量的影响我做了个对比测试。用一个 14B 的 Q8 模型、一个 35B 的 Q4_K_M 模型分别回答同一道逻辑题和同一个代码生成任务然后对比输出的差异。代码生成这块14B Q8 和 35B Q4_K_M 都能写出可运行的代码但 35B 对复杂需求的拆分更细比如“从数据库读取数据并做分页展示”这种需求14B 会给出一个简化版35B 会主动补充异常处理、分页参数校验、缓存等细节。逻辑推理这块差距更明显。同一道题“三个人分 17 匹马老大分 1/2老二分 1/3老三分 1/9怎么分”14B 有概率直接告诉你“17 不能被 2 整除所以无解”35B 能想到“借一匹马来分”这个经典解法。这就是参数量带来的推理深度差异。所以 Q4_K_M 把模型体积压到四分之一会损失一部分精度但 35B 的基础能力足够强压缩后依然优于 14B 的 Q8。这在本地部署场景是划算的。4.3 温度、上下文窗口等参数的影响记录除了层分配其他参数也对实际体验有影响整理如下temperature从 0.7 降到 0.2回答变得更保守更直接适合代码生成和事实问答但写作文案时会显得干巴巴。建议准备两套参数一套 0.7 用于对话聊天一套 0.3 用于代码和知识问答。num_ctx从 4096 升到 8192上下文翻倍后显存里 KV cache 占用明显增加生成速度会掉到 7.5 token/s 左右。如果你主要是“问答型”使用4096 足够如果要喂长文档做总结就得接受速度损失。num_batch从 128 升到 512吞吐量有小幅提升但显存峰值占用也会涨容易触发 OOM。8GB 显存下 256 是最稳的。4.4 与 7B / 14B 模型的实测对比最后做个横向对比用同样的硬件跑不同规模的模型模型量化显存占用生成速度问答质量评分主观Qwen2.5-7BQ4_K_M4.1GB45 token/s6/10Qwen2.5-14BQ4_K_M7.0GB18 token/s7.5/10Qwen2.5-35BQ4_K_M7.2GB 约 13GB 内存9.3 token/s9/10数据很清楚35B 在 8GB 显存下能跑到 9.3 token/s质量显著优于 7B但速度只有 7B 的五分之一。如果你需要的是“本地实时聊天助手”7B 更合适如果你要的是“能深度推理的本地专家”35B 值得那点等待。5. 常见问题与排查技巧本地大模型部署踩坑实录5.1 速度异常慢只有 1-2 token/s这是最常见的问题。优先检查四件事第一确认num_gpu已经设置生效。在模型运行时打开任务管理器如果“GPU 专用内存”占用只有几百 MB说明模型根本没加载到显存。可以执行ollama ps查看当前加载模型的 GPU 层数。第二检查内存是不是单通道。单通道 DDR5 的内存带宽只有双通道的一半对 CPU 卸载部分的影响是灾难性的。用 CPU-Z 或任务管理器查看“已插槽”数和内存速度如果是单条内存且主板支持双通道加一条相同规格内存组双通道速度能翻倍。第三清理后台程序。尤其是浏览器开了大量标签页、录屏软件、游戏平台客户端它们会抢显存和内存带宽。实测中我把浏览器全关后生成速度从 7.1 提到了 9.3 token/s。第四检查 GPU 驱动是否过旧。Ollama 对 CUDA 版本有要求如果驱动太老可能回退到 CPU-only 模式速度直接崩。更新到当前版本驱动即可。5.2 CUDA errorout of memory 显存溢出这个问题我在调参时遇到了好几次。Ollama 报错一般长这样CUDA error: out of memory。原因只有一个塞进 GPU 的东西超出 8GB 了。排查思路是逐步降低三层参数num_gpu每次减 2num_ctx从 8192 降到 4096num_batch从 512 降到 128。三者中num_gpu影响最大优先调它。另外注意OLLAMA_KEEP_ALIVE设置太短时每次重新加载模型都可能因内存碎片导致 OOM调到 10 分钟以上能好一些。还有一个隐藏因素集成显卡。很多笔记本有独显和核显双 GPUOllama 可能会把模型加载到核显上核显共享内存看似很大但性能极差。在 NVIDIA 控制面板里设置 Ollama 使用“高性能 GPU”或者在系统设置的图形首选项里指定应用使用独立显卡能解决这个问题。5.3 加载模型要等 40 秒如何让响应更快35B 的 Q4_K_M 文件有 20GB从磁盘加载到内存显存确实需要不少时间。如果你是“问一句、等半天”的使用方式大概率是每次问答后模型被立刻卸载了。解决方法就是设置OLLAMA_KEEP_ALIVE让它保持驻留。我设置为10m后连续对话时第二次提问的响应速度从 30 秒降到了 3 秒。需要注意的是模型驻留内存会占用约 20GB 系统内存如果你的机器只有 16GB 内存建议设置为2m即 2 分钟平衡内存占用和响应速度。另外模型文件放在 SSD 和机械硬盘上的加载速度差距巨大。实测从 NVMe SSD 加载 20GB 模型约需 20 秒如果放到 SATA 机械硬盘可能要 1 分钟以上。有条件的话把OLLAMA_MODELS指定到 NVMe 盘。5.4 回答质量差模型“变笨”了怎么办35B 模型在 Q4_K_M 量化下本身质量是够用的但如果你感受到了明显的“智商下滑”查两个地方一是确认你跑的确实是 35B 而不是被 Ollama 的标签搞混了。终端执行ollama list检查已安装模型的名称和大小如果你下到的是qwen2.5:32b或更早的版本参数规模可能不同。二是看温度设置。默认温度如果是 0.7 或 1.0回答会偏发散感觉“不着调”。对事实问答、代码生成这种任务把温度降到 0.3回答会更稳定更准确。三是排查上下文污染。如果你在长对话里累计喂了很多不相关内容模型会被前面的内容带偏。num_ctx只有 4096 时前面的上下文会被截断如果你问的问题依赖太早的信息自然答不准。此时可以开一个新对话或清理上下文。5.5 页面文件虚拟内存不足导致的崩溃Windows 默认的虚拟内存是“系统托管”但如果你物理内存只有 16GB加载 35B 模型时20GB 模型 系统开销很容易把虚拟内存吃满程序直接闪退或被系统杀掉。解决办法手动设置虚拟内存。右键“此电脑” → 属性 → 高级系统设置 → 性能设置 → 高级 → 虚拟内存更改把 C 盘虚拟内存设为“自定义大小”初始大小和最大值都设为 32GB 或 48GB。注意虚拟内存文件会占磁盘空间确保你的系统盘有足够余量。5.6 问题排查速查表症状常见原因快速解决速度只有 1-3 token/snum_gpu 未生效 / 模型跑在 CPU 上检查 ollama ps调高 num_gpuCUDA out of memory显存超出 8GB降 num_gpu / num_ctx / num_batch首次加载极慢模型在 HDD 上 / 虚拟内存不足转移模型到 SSD扩大虚拟内存回答很飘、逻辑混乱温度过高 / 上下文污染temperature 降到 0.3开新对话GPU 占用 0%调用了核显在系统设置中指定使用独立 GPU模型加载后频繁卸载OLLAMA_KEEP_ALIVE 为默认值设置为 10m 或更长6. 除了聊聊天35B 本地模型的干活场景实测6.1 本地私有知识库问答模型跑通之后最大价值在于私密性。我把自己的一些技术笔记和项目文档整理成一个知识库目录用 Ollama 的/api/generate接口写了个简单的 Python 脚本再配合嵌入模型比如nomic-embed-text这类 500MB 左右的轻量模型就能实现“基于本地文档的问答”。核心逻辑不复杂先把文档分块用嵌入模型转成向量存进本地向量数据库比如 Chroma 或 FAISS提问时把问题也转成向量检索出最相关的几个片段然后拼进 prompt 里扔给 35B 模型做总结。35B 模型的优势在于它能理解长片段之间的隐含关系给出的答案比 7B 模型更像“消化过”而不是“拼接”出来的。实操中我遇到的最大坑是Ollama 的嵌入接口和对话接口不是同一个端口需要分别调用而且嵌入模型和对话模型同时加载时显存占用会叠加8GB 会非常紧张。我的做法是设置两个不同OLLAMA_KEEP_ALIVE的环境变量或者干脆把知识库检索的脚本部署在另一台机器上让推理机只跑 35B 模型。6.2 代码辅助与批量脚本生成35B 模型在代码生成上明显更靠谱。实测我让它写“从本地 CSV 读取数据并生成折线图的 Python 脚本”它给了完整代码还主动补充了中文乱码处理和图表样式优化基本可以复制直接用。日常写脚本的频率很高的话这个模型可以省下很多搜索引擎来回切换的时间。比较实用的用法是配合 Open WebUI 这类前端工具把 Ollama 包装成一个局域网内可访问的 AI 服务手机、平板、别的电脑都能通过浏览器使用。整个体验跟商业 AI 助手已经很接近了唯一差别就是速度慢一些。6.3 从 35B 到更大规模8GB 显存的边界在哪里既然 35B 能跑那 70B 能不能跑实测答案是能启动但不推荐。70B 模型的 Q4_K_M 体积大约 40GB8GB 显存里只能放不到 10 层剩下 50 多层全跑 CPU生成速度掉到 2 token/s 以下等一个回答要十几分钟完全没有实用价值。我的结论是8GB 显存本地部署的“甜点规模”就是 30B 到 40B 之间的密集模型或者那些 MoE混合专家架构的中等规模模型——比如参数总量很大但激活参数很小的模型它的 KV cache 需求小速度会更快。如果你真的需要 70B 级别的能力更现实的路径是租云 GPU 或者在本地攒一台 24GB 显存以上的机器。这个边界不是软件能突破的是物理规律。7. 个人心得与最终建议折腾完这一整套我的感受挺直接8GB 显存跑 35B 模型不是“能不能”的问题而是“值不值”的问题。如果你手里只有普通消费级显卡又不想把数据交给云端 API那这套方案是目前性价比最高的路径。9 token/s 的速度确实不算快但考虑到它换来的是完全本地、完全私有、支持离线、可自由定制的 35B 级模型这笔交易是划算的。给想复现的朋友三个建议第一先把大方向想清楚你到底是想要速度还是质量。想要速度就老老实实用 7B 或 14B想要质量才值得碰 35B别指望二者兼得。第二调参时必须盯着任务管理器显存余量、内存带宽占用、GPU 利用率这些数据比任何教程都诚实。第三如果测试中频繁崩溃优先排查虚拟内存和驱动版本这俩比推理参数更基础。顺便分享一个最后才知道的小技巧ollama run qwen35b-8g进入交互模式后输入/?能看所有快捷键。/set parameter temperature 0.3可以直接在会话里调温不用每次改完 Modelfile 重启。对需要反复对比不同参数效果的人来说这个功能能省下大量时间。