“8GB 显存跑 35B 模型”这话放在任何AI玩家群里大概率都会被认为是异想天开。论显存35B 参数光FP16精度就要吃 70GB8GB 连零头都够不着论常识在消费级单卡上跑本地大模型大家普遍预期也就是 7B 到 14B 的水平。但我还真把这事儿干成了——用一张 RTX 4060 Ti 8GB配合 64GB 内存把 Qwen2.5-32B-Instruct 以 Q4_K_M 量化方式完整跑了起来。没有魔改驱动没有云服务器纯本地生成速度大约 3 到 5 tokens/s相当于一个说话不紧不慢的人在和你打字聊天。这篇文章就是我的完整实测记录包含量化原理、参数计算、工具选择、避坑手册手把手告诉你 8GB 显卡到底怎么跑 35B 级别模型哪些事情能做哪些事情别指望。先说结论这条路的核心不是靠显卡而是靠量化、CPU 卸载offload和内存带宽三者的配合。纯 GPU 推理模型装不下纯 CPU 推理速度又太折磨人所以最终方案是把模型的“一部分层”放到显卡上计算剩下的层交给 CPU 和内存处理。这听起来像是土办法但实际效果比很多人想象中要好得多。如果你手里正好有一张 8GB 显存的显卡又不想为跑大模型专门去租服务器这篇文章应该能帮你省下至少两三个晚上的折腾时间。1. 为什么 8GB 显存能跑 35B先搞懂三个核心机制1.1 量化的本质拿精度换体积35B 参数在 FP16 精度下每个参数占 2 字节光权重就要 70GB 显存。这是绕不过去的物理限制。但大模型推理并不需要每个参数都精确到小数点后好几位。量化技术的思路简单粗暴用更少的比特数来表示每个权重值。以 4-bit 量化为例每个参数只占 0.5 字节35GB 参数直接缩到 17.5GB 左右。常用的 Q4_K_M 是在 4-bit 基础上对关键张量做了更精细的分配实际体积通常比理论值略大一些Qwen2.5-32B-Instruct 的 Q4_K_M 权重文件大约是 19.6GB。内存还是不够但已经比 70GB 现实多了。这里的关键认知是量化不是“把文件压缩再解压”而是训练后直接以低精度存储和计算推理时不再还原成 FP16。你可以把它理解成把一张 4K 照片压缩成高质量 JPEG细节有损失但肉眼看绝大多数场景根本分不出来。实测下来Q4_K_M 量化对 32B 模型的智商影响大约在 5% 以内复杂代码、数学推理、长文本理解都还能保持相当可观的质量。如果你连 Q4_K_M 都不放心还有 Q5_K_M 和 Q6_K体积更大但精度更高只是 8GB 显存下显然没有这个余量。1.2 为什么必须 CPU 卸载装不下就只能“外挂”量化把体积从 70GB 拉到了 19.6GB但依然远超 8GB 显存。这时候唯一的办法就是“装不下多少算多少”。大模型推理本质上是逐层计算Transformer 模型几十层网络按顺序处理输入第 1 层算完才能算第 2 层。这给了我们一个机会把前面若干层放进 GPU 算后面的层放在内存里让 CPU 算层与层之间通过 PCIe 总线传递中间结果。The llama.cpp 里对应的参数是--n-gpu-layersOllama 里叫num_gpu控制加载到 GPU 上的层数。以 Qwen2.5-32B 为例它一共有 64 层 Transformer 层我实测在 8GB 显存下平衡负载和速度的最佳区间是 20 到 28 层。这意味着 GPU 处理约三分之一到四成的计算量剩下的交给 CPU。整个过程像是流水线上两个工人接力一个人速度快但只能接一部分活另一个人慢但任劳任怨把所有剩下的活都兜住。1.3 速度瓶颈不在显卡在内存带宽很多人第一次跑通之后都会懵GPU 利用率明明只有 30% 左右为什么速度还是上不去答案是每个 token 的计算过程中模型权重都要从内存搬到 CPU 缓存里算一遍。CPU 推理的性能几乎完全被内存带宽卡死。你的内存如果是 DDR4 3200MHz 双通道理论带宽约 50GB/s如果是 DDR5 4800 双通道能到 76GB/s。看起来都挺快但跟 GPU 动辄几百 GB/s 的显存带宽一比差距就是数量级了。所以这台机器想跑得舒服内存带宽是第一优先级。实测同样一颗 CPU内存从单通道换成双通道速度直接翻倍。这个话题后面在硬件配置部分会详细展开。2. 环境准备硬件、软件与模型选型2.1 我的实测硬件清单跑通这套方案的最低配置可以很低但体验天差地别。我这里列一个“勉强能跑”和“舒服运行”的对照方便你参考自己手里的机器。硬件勉强能跑我的实测配置备注GPUGTX 1660 6GBRTX 4060 Ti 8GB6GB 也能跑但层数更少速度更慢CPU6 核 12 线程i5-13490F核心数越多CPU 推理越快内存32GB DDR464GB DDR4 3200 双通道19.6GB 模型 KV cache 系统开销32GB 勉强够硬盘SATA SSDNVMe PCIe 4.0首次加载模型速度差异明显特别注意内存容量。Q4_K_M 权重约 19.6GB加载后还要给上下文KV cache留空间再加上操作系统和其他程序占用32GB 内存实际只剩约 12GB 可用。上下文长度只要开到 8192KV cache 就要吃掉好几 GB。我用 64GB 内存上下文开 16384 也没有压力这在跑 35B 模型时是决定体验上限的关键。2.2 软件选型Ollama 还是 llama.cpp软件层面有两条路线一条是开箱即用的 Ollama另一条是手动控制的 llama.cpp 命令行。我的建议是第一轮先用 Ollama 把整个流程跑通建立“能跑”的信心再回到 llama.cpp 体验真正的参数控制力。Ollama 本质上是对 llama.cpp 的封装两者底层推理引擎相同支持相同的量化格式和 CPU offload 机制。区别在于 Ollama 把你的配置选项压缩成了环境变量和Modelfile而 llama.cpp 把一切裸露在命令行参数里。Ollama 安装完成后只有一个命令ollama run qwen2.5:32b。首次运行会先下载模型文件之后每次启动就是本地推理。它默认的 num_gpu 参数是 999意思是“能塞多少层进显存就塞多少层”。这正是我们要的8GB 显存会自动选择大约 20 到 28 层。如果你的 Ollama 版本行为不一样可以用环境变量强制指定# Linux/macOS OLLAMA_NUM_GPU24 ollama run qwen2.5:32b # Windows PowerShell $env:OLLAMA_NUM_GPU24 ollama run qwen2.5:32bllama.cpp 路线则需要编译或下载预编译二进制然后自己拉量化模型文件再手工指定参数运行。虽然比 Ollama 多了几步但那种“每个参数都握在自己手里”的踏实感折腾过的人都懂。两条路线我会在第四章完整演示。2.3 模型选型为什么是 Qwen2.5-32B35B 这个档位目前最成熟的开源选择就是 Qwen2.5-32B-Instruct。它在代码、数学、中文理解几个维度的综合表现非常均衡社区适配的量化文件最齐全推理工具支持也最完善。而它的 GGUF 量化版本参数文件正好卡在“8GB 显存 64GB 内存”这台机器可以承受的范围上限附近多一档量化就装不下少一档性能又不够用。32B 和 35B 参数量的差别其实不大但 30B 以上模型相比 7B 模型的提升是肉眼可见的——复杂任务理解、长上下文保持、指令跟随能力都有明显跨越。实测同一个问题“写一个带状态管理的 Python CLI 工具”7B 模型给出的代码基本是模板拼接32B 模型则能考虑到异常处理、参数校验、扩展点设计。这就是为什么一群人明知硬件吃力还要往这个档位上挤的原因。3. 完整实操从零到跑通 35B 模型3.1 第一步安装 Ollama 并确认版本Ollama 的安装非常省事。Windows 用户直接在官网下载 exe 安装包macOS 用户brew install ollamaLinux 用户执行官方一键脚本即可。装完先在终端验证ollama --version接下来设置并发和上下文参数。这一步建议在做任何其他操作之前先做好因为这些参数直接影响显存分配策略。在 Linux/macOS 下export OLLAMA_NUM_GPU24 export OLLAMA_CONTEXT_LENGTH8192 ollama serveWindows 用户通过系统环境变量对话框设置同名变量然后重新打开终端。这里我把上下文长度设置在 8192理由有二一是 Qwen2.5-32B 支持最大 131072 的上下文但更长的上下文意味着更大的 KV cache 显存开销二是 8192 已经能处理大部分日常任务同时把 KV cache 控制在合理范围让更多显存留给模型层数。安装完成后直接下载并运行模型ollama run qwen2.5:32b首次运行会显示一个下载进度条Q4_K_M 量化文件约 19.6GB取决于你的网速可能需要十几分钟到一小时不等。下载完成后会自动加载模型并进入对话模式。3.2 第二步检查实际显存占用与层数分配模型跑起来之后别急着提问。先看看显存的实际使用情况。Windows 下打开任务管理器切到“性能”标签页查看 GPU 专用显存Linux 下执行nvidia-smi。我第一次跑通时显存占用显示约 7.1GB模型加载了 24 层到 GPU其余 40 层留在 CPU 内存里。为什么不是 8GB 全部用完因为 NVLink 之外还有 1GB 左右的空间要留给系统显示输出、CUDA 上下文和 KV cache强行填满会在生成过程中直接爆显存。如果看到显存占用超过 7.8GB 而且模型开始报错说明num_gpu设置得太激进了。要缩小层数就把OLLAMA_NUM_GPU往 16 到 20 调直到显存稳定在 85% 占用率左右。这是个反复试出来的平衡点后面我会给一个参考表。3.3 第三步llama.cpp 裸跑的完整命令如果你想脱离 Ollama 自己做精细控制llama.cpp 路线更直接。我使用官方 release 页面的预编译二进制下载后解压即可Windows 用户注意选择带cuda标识的版本。# 先下载量化模型 # 到 Hugging Face 搜索 Qwen/Qwen2.5-32B-Instruct-GGUF下载 qwen2.5-32b-instruct-q4_k_m.gguf # 运行推理参数逐个解释 ./llama-cli \ -m ./qwen2.5-32b-instruct-q4_k_m.gguf \ # 模型路径 -ngl 24 \ # 24 层放 GPU剩余 40 层 CPU -c 8192 \ # 上下文长度 -n 512 \ # 单次生成最大 token 数 -p 用 Python 写一个快速排序包含注释和测试用例 \ --temp 0.7 \ --repeat-penalty 1.1这里的参数没有一个是多余的。-ngl决定显存与 CPU 的分工比例-c决定上下文窗口大小-n控制生成长度防止跑飞温度--temp 0.7平衡创造性与稳定性。我把上下文 8192 作为默认值日常对话和代码生成都够用。如果你跟我一样有“用显存多一点就快一点”的执念可以试着把-ngl逐步往上加每加 2 层重新跑一次测试记住显存占用率。我实测的对照数据在这里ngl 层数显存占用生成速度 (tokens/s)稳定性165.2GB2.0 - 2.8很稳246.9GB3.1 - 4.2稳定287.6GB3.8 - 5.0偶尔波动307.9GB4.3 - 5.5有 OOM 风险看到没有ngl30理论速度最快但显存已经顶到 93%实际使用中很容易因为上下文长度波动直接爆显存反而得不偿失。长期使用我推荐 24 层速度和稳定性得到最佳平衡。4. 实测数据与性能调优记录4.1 速度实测不同任务的真实感受所有数据都基于ngl24、上下文 8192、DDR4 3200 双通道的模式。一个非常重要的指标是 tokens/s它代表每秒生成的字符单位数。中文大约 1.5 个 token 对应一个汉字所以 4 tokens/s 约等于每秒输出 2.5 个汉字。以下是我不同任务的实测记录任务类型首 Token 延迟平均速度整体体验短问答“什么是大模型量化”1.8 秒4.1 tokens/s可接受写一段 200 行 Python 代码3.5 秒3.8 tokens/s约 4 分钟等待可接受分析一段 1000 字的长文本12 秒3.2 tokens/s等待感明显对话上下文超过 6000 token20 秒2.5 tokens/s有点折磨首 Token 延迟是最容易被忽视的体验杀手。对话时按下回车到第一个字蹦出来的等待时间取决于系统对整段 prompt 进行预处理的速度。prompt 越长、CPU 负责的层数越多等待越长。当上下文累积到几千 token 后每次回答前都要重新处理前面所有对话速度下滑是物理规律不要指望优化能解决一切。4.2 调优三板斧内存带宽、层数分配、上下文节制第一板斧双通道内存是硬门槛。如果你现在还是单根 16GB 内存强烈建议再加一根组双通道。实测同样设置下单通道 1.8 tokens/s双通道 3.9 tokens/s提升 117%这是全天性价比最高的一个小升级。第二板斧控制上下文长度。8192不是越大越好。我跑过一个极端测试把上下文拉到 32768显存占用暴增 2.5GB模型能加载的 GPU 层数直接从 24 掉到 16整体速度反而下降 45%。如果你的任务不需要长历史果断保持 4096 或 8192。第三板斧根据任务调整-ngl。纯代码生成任务上下文短时可以把ngl调到 28 换取更快速度长文档分析任务则降到 20 给 KV cache 让路。理论上一套参数跑所有任务但一个配置微调就能省下班时间何乐而不为。4.3 量化等级对比Q4_K_M 是最优解吗很多第一次用 GGUF 的朋友会对着文件列表发懵从 Q2_K 到 Q8_0 十来个版本到底选哪个。我顺手跑了几组对比量化版文件大小显存需求相对 FP16 质量速度感受Q2_K11.6GB可搭配纯 CPU明显下降逻辑易出错快但蠢Q3_K_M15.1GB混合加载可用复杂任务露馅较快Q4_K_M19.6GB24 层 GPU 内存接近原始推荐平衡Q5_K_M23.5GBGPU 层数减少更接近原始更慢Q6_K26.1GB几乎全 CPU很好慢得没脾气结论很清楚Q4_K_M 是 8GB 显卡跑 32B 模型的甜点。Q2_K 能更快跑完但智商损失太大Q5 以上体积膨胀严重把本来就捉襟见肘的显存分配进一步压榨速度下滑换来的精度提升根本不值。如果你试过 Q4_K_M 觉得质量不够用那说明这个需求本身就不该在 8GB 显卡上解决。5. 常见问题与排查技巧实录5.1 显存溢出OOM问题报错信息通常是 CUDA out of memory 或者ggml_cuda_allocate_tensor: failed to allocate。核心原因是模型层数加得太多或者上下文长度设置导致 KV cache 膨胀。排查步骤要按这个顺序走降低-ngl一次降 4 层重新加载测试。调低上下文长度到 4096释放 KV cache 占用的显存。检查后台是否还有别的程序占显存浏览器开一堆标签页也是杀显存的元凶。如果重启后再也没复现大概率是模型加载时其他程序正好占了显存。我遇到过一次诡异情况模型加载占用 6.8GB运行十分钟稳定突然某次回答报错 OOM。查了半天发现是浏览器里一个在线视频页面抢走了 1.5GB 显存。所以跑大模型时能关的软件尽量关掉。5.2 速度慢到难以忍受怎么办首先确认内存是不是双通道。wmic memorychip list brief或任务管理器里直接看内存插槽数量确认两根内存条是否插在对的插槽上一般主板是 2 和 4 槽。其次检查后台是否有ollama serve的重复进程。有一次我意外开了两个 Ollama 服务每个都在抢 CPU 资源速度直接腰斩。如果这些都排查完了还是慢那就要接受现实8GB 显卡跑 32B 模型的速度天花板就在 5 tokens/s 左右。想要大幅提速唯一现实选择是换更大的显卡或者模型换小一档14B。这不是软件能解决的问题是物理定律。5.3 模型回答质量突然变差大部分情况是上下文被塞满了。Qwen2.5 支持长上下文但超出模型实际理解能力之后回答质量会断崖式下跌。表现是前后矛盾、重复句子、逻辑混乱。解决方案是开启新会话或者裁剪掉历史中间的冗余对话。日常使用我自己习惯每 10 轮左右手动清理一次上下文。另一个容易忽视的因素是量化版本。如果你用的是 Q3_K_M 或者更低的量化某些任务上模型会“智力下降”得非常明显不是模型的问题是量化丢精度丢过头了。5.4 一键速查表症状可能原因解决动作加载模型报 OOMngl 太高或显存被占降 ngl 到 24 以下关后台程序速度只有 1.5 tokens/s单通道内存加内存组双通道首字等待 30 秒以上上下文过长CPU 预处理慢清上下文或降-c生成内容重复上下文溢出或温度太低开新会话--temp调到 0.8模型下载中断网络不稳删除残余文件重试或换镜像Ollama 突然无法启动环境变量写错检查OLLAMA_NUM_GPU是否为数字6. 实测体验总结与后续扩展思路这套“8GB 显卡 64GB 内存 Q4_K_M 量化 24 层 GPU offload”的方案我连续用了两周日常场景大概覆盖了代码生成与解释、英语翻译、文章摘要、正则表达式构造、简单的数据分析脚本。这些任务表现都不错完全达到了“能用的本地大模型”线。但它替代不了 ChatGPT 级别的在线服务——响应速度、上下文长度、多轮对话体验都不在一个量级。如果是想拿它做知识库问答可以配合llama-index或dify这类工具把文档切块后做向量检索再喂给 32B 模型做生成。实测检索问答的效果比单纯用 7B 模型好很多尤其是在专业领域术语和长段落归纳上。这个配置后续还有几个可以折腾的方向一是用ExLlamaV2跑 EXL2 量化版模型某些场景下能多压几层进显存二是尝试FlashAttention支持更好的推理引擎能进一步降低 KV cache 占用三是等 8GB 显卡从 4060 升级到 5090 之后这套思路可以直接平移只是层数能全部塞进显存速度会有质的飞跃。最后再分享一个实战小技巧如果你使用 Ollama可以写一个 shell 脚本把常用参数封装起来。比如我日常的 run 命令都是这样ollama run qwen2.5:32b --keepalive 600 --verbose--keepalive让模型在内存里保持运行 10 分钟多次对话之间不用反复从硬盘加载。--verbose在生成结束后会打出详细的推理统计包括速度、显存占用和 KV cache 使用情况是调优时最直观的数据来源。这两个参数都值得记下来。