8GB显存跑35B大模型：量化与分层加载实战实录

1. 为什么要在 8GB 显存上硬啃 35B 1.1 很多人说显存不够模型白搭但“硬啃”不是瞎折腾先说结论8GB 显存跑 35B 参数模型能跑但别指望它像小模型那样打字飞快。我花了一周时间在一张 RTX 4060 8GB 的消费级显卡上把 Qwen2.5-32B-Instruct 的 GGUF 量化模型完整跑了起来并且做了一轮速度、内存、稳定性、输出质量的多维度测试。整个过程涉及量化选型、显存预算、CPU/GPU 协同调度踩过的坑和最终数据都收在这篇实录里。很多人拿到 8GB 显卡第一反应是“显存只有 8GB那不就只能玩 7B 模型吗”这个想法不算错但如果只停留在这一步其实浪费了消费级硬件一半的潜力。传统认知里大模型显存需求按权重精度线性膨胀35B 参数在 FP16 下要占 70GB8GB 显存连零头都不够。可是本地模型生态这几年发展得比多数人想象中快GGUF 量化、分层加载、CPU offload 这些技术已经把“大模型必须住在显存里”这个默认前提彻底改写了。更重要的是35B 这个档位在语言理解、长文本处理、复杂指令跟随上的能力比 7B/8B 强了不止一个层次。同样是做一场会议纪要总结7B 模型可能只给你列个大纲35B 模型能读完整份文档把决策点、争议点、时间节点都抓出来。对本地部署有真实需求的人比如想搭私有知识库、做文档问答、搞离线代码审查的35B 才是真正值得折腾的目标。这篇实录就是给同样拿着 8GB 显卡、想往这个方向多走一步的人写的。1.2 35B 这个档位是什么水平先解释一下“35B”到底是什么意思。它指的是模型参数量在 350 亿左右实际开源社区里常见的是 32B 和 34B 两个规格比如 Qwen2.5-32B、Yi-34B通常被人统称为“35B 级别大模型”。这个级别往上走就是 70B往下是 7B/8B中间夹着的“35B”恰恰是消费级硬件能摸到的性价比天花板。对比一下就能明白差距。7B 模型在 8GB 显存上可以毫无压力地全量驻留速度能冲到每秒 40 个 token 以上但它的知识储备和推理能力比较有限复杂一点的逻辑题、长文档结构理解经常答非所问。70B 模型质量确实更好可哪怕是 Q4 量化后也要 40GB 左右8GB 显存加 32GB 内存都很难兜住速度会慢到没有实用价值。35B 卡在中间Q4 量化后大约 20GB配合 CPU 内存可以塞下而且它的质量问题不大日常用来处理文档、写代码、翻译、做总结基本接近于“能用的助手”。当然这里必须把话说透“能跑”和“好用”是两回事。8GB 显存跑 35B速度很可能只有每秒 1 个 token 出头你打一句“你好”出去它吭哧吭哧半天才有反应。指望它做实时聊天窗口里的陪聊那纯粹是找罪受。但如果你给它的场景是“夜间批量跑 100 份合同摘要”“早上下班前拿到结果”35B 就成了性价比极高的选择慢一点但能力够还不用把数据交给云端。1.3 我实测的目标和底线这篇文章叫“完整实录”所以先把这次实测的目标和底线亮出来免得读者被标题带偏。我给自己定的要求有四条第一模型能正常启动并持续生成不能动不动就报错退出第二速度至少要对批处理场景有意义我的底线是 0.5 token/s低过这个数字等于半小时憋不出三百字第三输出质量不能崩成“废话生成器”尤其是不能出现大段的重复和前后矛盾第四显存和内存占用要可控不能出现系统跑着跑着卡死的情况。这就是为什么我没有一上来就选 9GB、20GB 这种夸张的显存配置去测而是老老实实按 8GB 消费级显卡来。整条链路从模型选择、量化级别、显存层数分配到最终效果每一个环节都值得拆开看。接下来我会把这条路上遇到的关键决策和踩坑过程全部记录下来工具用到的 Ollama 和 llama.cpp 都会讲到参数怎么算、命令怎么敲、坑怎么避开全部一一交代。2. 核心解法量化、分层加载与显存预算2.1 量化是唯一现实路径GGUF 格式做了啥想在 8GB 显存上碰 35B 模型第一道坎就是权重体积。模型权重默认是 FP16 格式一个参数占 2 字节35B 参数就是 70GB。这个体积对消费级硬件来说完全是另一个维度的东西所以必须做量化也就是把每个参数的存储精度从 16bit 压缩到更低位用一点点精度损失换体积骤降。打个比方模型权重就像办公室里的文件柜。FP16 是原版文件一个字都不能少量化是把文件缩印成小字号看着累一点但关键信息还在。社区里目前最流行的量化载体叫 GGUF它来自 llama.cpp 生态设计目标就是让模型能在显存小、内存也不富裕的机器上运行。GGUF 背后有一整套量化算法其中最常用的是 K-quants 系列也就是我们经常在模型文件名里看到的 Q4_K_M、Q5_K_M 这些后缀。具体到数字35B 模型Q8 量化后约 37GBQ6 约 26GBQ5_K_M 约 24GBQ4_K_M 约 20GBQ3_K_M 约 15.5GBQ2_K 约 12GB。看到区别了吗同样一个模型FP16 要 70GBQ4 只要 20GB压缩了近四倍。这正是 8GB 显存敢去碰 35B 的核心底气但只有量化还不够因为 20GB 依然超出 8GB 显存怎么把它塞进去靠的是下一步分层加载。2.2 显存预算怎么算权重、KV Cache、运行缓冲很多人以为 8GB 显存就是 8GB 可以用这是第一个理解误区。实际打开系统显卡驱动、桌面环境、CUDA runtime 就已经吃掉几百 MB。对消费者显卡来说启动任何图形程序、浏览器硬件加速、桌面窗口特效都会占用显存。我实测在 Windows 11 桌面上即使干干净净8GB 显存里可用的大概只有 7GB 左右如果 WSL2 叠加、浏览器开着这个数字还会往下掉到 6GB。就算我们有 7GB 可用显存面对 20GB 的 Q4_K_M 模型依然差了一大截。那剩下的空间怎么算出来的这里要拆解三个组成部分模型权重、KV Cache、运行缓冲。模型权重是大头20GBKV Cache 是推理过程中存储中间 Key/Value 的缓存区上下文越长占用越大4096 上下文下大约需要 1 到 2GB运行缓冲是 CUDA context、计算图、临时张量等杂项通常 0.5 到 1GB。三项加起来完整地跑一个 35B Q4 模型大概需要 22GB 空间远超出 8GB 显存。所以正确的思路不是“把 20GB 塞进 8GB”而是“把模型切成一层一层的显存能放多少层就放多少层剩下的层放在 CPU 内存里”。Transformer 模型天生是分层的每一层的计算只依赖前一层输出这叫“层间顺序执行”。GPU 可以只负责前 20 层跑完把中间结果传给 CPU由 CPU 内存里的另外几十层继续算算完再传回 GPU 处理下一轮 token。这个过程会慢但至少能跑起来。2.3 GPU 和 CPU 怎么分工n_gpu_layers 的平衡艺术既然要把模型分到 GPU 和 CPU 两头接下来就是“分多少层”的问题。llama.cpp 生态里这个参数叫n_gpu_layersOllama 里对应的是num_gpu。它直接决定每层推理是在 GPU 上跑还是在 CPU 上跑。我按经验做了个粗略估算35B 模型通常有 60 到 80 层我拿 Qwen2.5-32B 的 64 层为例子。Q4_K_M 文件约 20.5GB平摊到每层约 320MB。可用显存 7GB减掉 KV Cache 和 CUDA context 占用的 1 到 1.5GB真正能放权重的空间大约 5.5 到 6GB。6GB 除以 320MB结论是差不多只能塞 18 到 20 层。我在实测里就是从num_gpu 20开始调的。这个参数有一个典型的“甜点区”效应。设太低比如只有 10 层大部分层挤在 CPU 上跑速度惨不忍睹设太高比如 25 层甚至 30 层GPU 显存被撑爆程序要么直接崩溃要么触发系统自动交换速度反而断崖式下跌。正确姿势是先设一个保守值比如 15 或 20然后用nvidia-smi盯着显存占用每次加 2 到 5 层直到逼近“再多一层就爆”的临界点然后往回退 2 到 3 层留出余量给 KV Cache 和上下文窗口。这个“显存用到 90% 左右”的状态就是你这台机器的最优配置。当然GPU 层数只是一半另一半是系统内存。Q4_K_M 模型 20GBGPU 放了 6GB剩下约 14GB 必须放在系统内存里加上进程本身和 KV Cache内存占用会到 16 到 18GB。这意味着你的电脑最好有 32GB 内存。16GB 内存也不是不能试但很容易触发 swap速度直接掉到每分钟几个字那种卡顿感会让人当场放弃。3. 实测环境与实操流程3.1 我的测试机器和软件环境先把实测环境交代清楚因为“能不能跑”“跑多快”和硬件强相关没有这套环境参考后面所有数字都毫无意义。我用的机器配置是CPU 为 Intel i5-12400F6 核 12 线程内存 32GB DDR4 3200 双通道显卡是 NVIDIA RTX 40608GB 显存操作系统为 Windows 11 中文版配合 WSL2 Ubuntu 22.04 环境。储存是一块普通 SATA SSD模型文件大约需要 20GB 空间。为什么在 WSL2 里跑而不是 Windows 原生环境两个原因一是 llama.cpp 和 Ollama 在 Linux 下的调度和性能释放更稳定日志信息也更完整二是 WSL2 天然和 NVIDIA 的 Linux 驱动配合良好直接用 CUDA 跑推理方便我用nvidia-smi实时盯显存。如果你不熟悉 WSLWindows 原生安装 Ollama 也一样能跑后面讲到的参数调节在 Windows 下同样生效只是命令行工具名称和路径略有差异。软件方面我用了两套工具做对比测试Ollama 0.5.x 作为快速上手的首选llama.cpp 的最新 release 用来做细粒度调试因为它的启动日志能明明白白打印出“offloaded 20/64 layers to GPU”这类信息对定位性能瓶颈特别有用。两套工具底层都基于 llama.cpp 的推理核心因此运行参数思路完全一致。3.2 按 Ollama 快速部署5 分钟出结果如果你只想快速验证“8GB 能不能跑 35B”Ollama 是最省事的方式。第一步安装 Ollama官方安装包装完就行Windows 和 Linux 都有对应版本。第二步拉取模型。我这次测试用的主模型是 Qwen2.5-32B在 Ollama 仓库里的 tag 写法一般是qwen2.5:32b默认就是量化好的版本不需要自己去找 GGUF 文件。如果不确定具体量化档位先执行ollama show qwen2.5:32b看一下模型信息。这里有个关键坑如果你直接ollama run qwen2.5:32bOllama 默认会尝试把所有层都放进 GPU 显存。8GB 显存放不下 20GB 模型于是要么启动过程漫长要么直接报CUDA error: out of memory退出。解决办法是给模型做一个显存层数限制配置写一个类似 Dockerfile 的 Modelfile内容如下FROM qwen2.5:32b PARAMETER num_gpu 20 PARAMETER num_ctx 4096FROM指定基础模型PARAMETER num_gpu 20告诉 Ollama 只加载 20 层到 GPU剩下的放 CPU 内存。num_ctx 4096设置上下文长度为 4096 token这是内存和速度之间的一个折中。写好后执行ollama create qwen32b-local -f ./Modelfile然后再运行ollama run qwen32b-local模型启动后我用另一个终端窗口跑nvidia-smi -l 1能看到显存占用慢慢上升到 7GB 左右就不再涨同时系统内存占用涨了大约 17GB。这说明分层加载已经生效GPU 和 CPU 各管一段模型没有爆显存任务管理器也没出现卡死。整个过程从零到跑起来确实五分钟内搞定。3.3 如果要更精细控制换成 llama.cpp 裸跑Ollama 的封装足够方便但它像一件“打包好的套餐”很多参数藏在黑盒后面。当你发现速度不对劲、想精确调整每一层的放置、或者想在脚本里批量跑任务时llama.cpp 裸跑更顺手。llama.cpp 的官方 release 包里会提供两个主要命令行工具一个叫llama-cli用于交互式或单次文本生成另一个叫llama-server用来起一个兼容 OpenAI 格式的本地 API 服务。单次生成命令可以这样写llama-cli -m ./models/Qwen2.5-32B-Instruct-Q4_K_M.gguf \ -ngl 20 \ -c 4096 \ -n 256 \ -p 请用200字解释大模型量化为什么能显著降低显存占用-m指定模型文件路径-ngl 20就是前面说的 GPU 层数-c 4096是上下文长度-n 256限制最多生成 256 个 token-p是输入提示词。启动之后终端会打印加载日志我建议你重点看这一行llm_load_tensors: offloaded 20/64 layers to GPU有了这行日志你就知道 GPU 层数确实生效了。如果显示0/64说明配置没生效模型全部在 CPU 上跑难怪慢得像蜗牛。如果想起一个长期服务改用llama-server -m ./models/Qwen2.5-32B-Instruct-Q4_K_M.gguf \ -ngl 20 \ --host 127.0.0.1 \ --port 8080然后本地程序就可以用curl http://127.0.0.1:8080/v1/chat/completions调这个 API后续接知识库、做二次开发都方便。实际用下来llama.cpp 的可控性和日志透明度是 Ollama 替代不了的尤其是排查性能问题时你能清楚看到每一层被分配到哪个设备、KV Cache 用了多少显存、prompt processing 和 token generation 各花了多少时间。3.4 部署方案怎么选Ollama 还是 llama.cpp这两套工具不是互斥关系而是适用场景不同。我在实测中的感受可以总结成一句话Ollama 适合“快速试模型”llama.cpp 适合“深度调性能”。为了让你选起来更省心我直接把两者的差异列个表对比项Ollamallama.cpp上手难度极低装完即用中等需要参数理解显存层数控制通过 Modelfile 的 num_gpu通过 -ngl 参数启动日志简洁但信息少详细到每层 offload 情况API 服务自带 OpenAI 兼容接口有 llama-server稳定可控批量脚本不够灵活命令行参数全适合脚本化社区生态模型拉取方便量化工具、调试工具全家桶如果你只是想知道“8GB 能不能跑 35B”Ollama 五分钟出结果个人强烈推荐先走这一步。但如果你打算长期用这个模型做本地知识库或离线任务最好早点切换到 llama.cpp因为它的运行日志能帮你持续优化参数比如调整完-ngl之后速度变化能看到直接原因。这个细节在 Ollama 里被完全隐藏出了问题都不知道从哪下手。4. 实测数据速度、内存和输出质量4.1 三种常见 35B 量化级别跑出来的真实数字纸上谈兵到这里该上真正的实测数据了。我用相同的提示词“写一段300字关于开源大模型本地部署价值的说明”在三种量化级别下分别做测试每个跑三轮取中间值。上下文设置为 4096GPU 层数按可用显存极限调整。结果如下量化级别模型体积GPU层数生成速度显存占用内存占用实际体验Q4_K_M约20.5GB201.1 token/s7.2GB17GB能跑推荐Q3_K_M约15.5GB301.8 token/s7.4GB12GB速度快一些质量略降Q2_K约11.9GB402.4 token/s7.5GB8.5GB能跑但不再建议主力使用这组数据对应的背景是Q4_K_M 下显存可用空间刚好放 20 层内存承担了约 14GB 模型权重Q3_K_M 由于模型更小每层占用降低GPU 能多分担 10 层所以速度明显快了一大截Q2_K 最小GPU 能放 40 层内存占用只有 8.5GB速度也最好。但请注意Q2_K 的“快”是拿大量模型精度换来的后面质量测试会详细说它到底牺牲了什么。除了量化级别上下文长度也是影响速度的重要变量。同一个 Q4_K_M 模型把上下文从 4096 降到 2048生成速度大约能提升 15% 到 20%。原因是 KV Cache 变小显存里留给权重计算的空间更多GPU 的可用缓冲也更宽裕。如果你只是做短文本问答把num_ctx设成 2048 甚至 1024 是更聪明的选择。4.2 生成的质量会不会被量化“打折”速度数字只是表象真正决定这个模型有没有意义的是输出质量。我在四个维度上做了对比一段英文技术文档的翻译、一个 Python 爬虫函数的编写、一个生活常识问答、一篇 2000 字文档的摘要总结。结论是Q4_K_M 的输出质量与未量化版本几乎没有肉眼可见的差距复杂指令也能正确理解Q3_K_M 在日常任务中表现也还行但长文摘要时开始出现“概述不准、丢点”的情况Q2_K 则明显掉智商会出现语句重复、答非所问偶尔还自己编造内容。为什么低比特量化会让模型变笨原理其实不复杂。模型的知识和推理能力都藏在权重数值的细节里量化相当于把每个参数的存储精度从 16bit 压到 2 到 4bit。高比特意味着保留更精细的数值信息低比特则把这些细节打薄。当量化低到 Q2 级别模型内部一部分知识连接已经被“压糊”了表现就是前后矛盾、事实错乱。社区里常说的“Q4_K_M 是甜点”就是因为它在体积和精度之间取了一个平衡点文件大小只有 FP16 的三分之一质量损失却几乎感觉不到。这里还有个容易踩的坑不要光看后缀数字还要看量化方法。同样是 Q4老式的q4_0和新式的Q4_K_M质量差距不小。建议认准 K-quants 系列也就是文件名里带_K的版本这是 llama.cpp 团队后来重新设计的量化方案质量和体积比都更好。4.3 实测中的几个“没想到”跑完这一轮测试我发现有三个现象是事前没预料到的。第一个是 Ollama 默认的显存策略比想象中激进。我最初直接ollama run它试图把 20GB 模型全塞进 8GB 显存结果加载到一半就崩了而且不是那种明确的报错是进程直接消失。后来加上num_gpu 20才稳定这个细节在我看过的很多教程里都没提到。第二个是内存带宽的影响比 CPU 算力更明显。35B 模型大部分层在 CPU 上跑CPU 每算一层就要读一次系统内存内存的双通道带宽直接决定了速度上限。我的测试机是 DDR4 3200 双通道速度稳定在 1.1 token/s如果换成单通道内存速度至少再降三成。这也是为什么同样配置的机器有人跑 0.8 token/s、有人能跑 1.5 token/s 的原因之一。第三个是 WSL2 环境下 Windows 侧的显存大户会影响推理。开着 Chrome 和若干桌面程序时GPU 显存被占掉一部分WSL2 能用的 CUDA 显存变小推理速度掉了大概 15%。我把浏览器关掉之后速度明显回升。如果你也在 WSL2 里跑大模型记住 Windows 侧的显存使用同样算在 8GB 里。5. 常见问题与排查技巧实录5.1 Ollama 显存爆了怎么办这是 8GB 显存跑 35B 时出现频率最高的问题症状是启动加载到一半直接退出或者日志里出现CUDA error: out of memory。根因基本都是上没有设置 GPU 层数Ollama 默认希望最大程度利用显存结果模型体积远超显存容量系统直接罢工。排查办法很简单开着nvidia-smi -l 1看显存变化同时观察程序退出前显存是否已经撞到 100%。处理方式就是我前面讲的给模型写一个 Modelfile里面明确指定PARAMETER num_gpu。我的建议是从num_gpu 15开始试如果显存占用还在 80% 以下再加到 20逐个试探。记住一点显存要留 5% 到 10% 的余量给 KV Cache 和 CUDA 上下文不要把显存塞到 99%那种状态短时间内看似能用上下文一长缓冲一溢出照样崩溃。5.2 输出特别慢能抢救一下吗如果你发现速度掉到 0.3 到 0.5 token/s等待时间长得让人怀疑人生大概率不是硬件不行而是配置没到位。先检查 GPU 层数是不是设得太低了如果只有 10 层那大部分推理都在 CPU 上慢是必然的再检查上下文长度是不是设得太长8192 上下文对 8GB 显存来说太奢侈KV Cache 至少要吃掉三四 GB把上下文降到 2048 或 4096速度会上一个台阶。还有个容易被忽略的点内存换页。任务管理器里如果看到“内存”占用接近 100%并且磁盘活动异常活跃说明模型权重被放进交换文件了这比任何配置错误都致命。解决办法是关闭大型后台程序把模型换成更小的 Q3 量化版或者干脆加内存。另一种“抢救”方法是换思路从 Dense 模型换成同尺寸的 MoE 模型。MoE 虽然总参数量还是 35B 级别但推理时每次只激活一小部分参数8GB 显存配合内存跑起来速度往往能比 Dense 模型快一半以上。5.3 系统内存不够怎么办16GB 内存跑 35B 真的非常勉强因为 Q4_K_M 模型光权重就要 20GB16GB 内存连文件都装不完系统必然触发 swap速度降到每分钟几个字这种情况下再好的配置也是白搭。如果你只有 16GB 内存有两个务实选择一是换 Q3_K_M 量化版本模型文件约 15.5GB勉强能装下但内存会被占满需要关掉所有后台程序二是继续用 Q4_K_M但把 GPU 层数提高一些让显存多分担一点同时忍受内存几乎被占光的现实。如果你在用 WSL2 跑 Ollama建议在 Windows 用户目录下建一个.wslconfig文件限制 WSL 分配的内存上限避免 Windows 被挤得卡死。示例配置如下[wsl2] memory24GB processors8改完这个文件需要执行wsl --shutdown重启 WSL 才生效。说到底内存不足最好的解决方案永远是加一条内存条32GB 是 8GB 显存跑 35B 的及格线这一步省不得。5.4 那些量化标签 Q4_K_M、Q5_K_S 到底怎么读很多人在下模型的时候看到一长串文件名里的Q4_K_M、Q5_K_S、Q3_K_M等标签完全不知道是什么意思。简单说这些标签表达了“量化位数”和“量化方法”。我按体积从大到小整理一份速查表量化标签约体积35B质量情况适用场景F1670GB原版质量显存充裕的服务器Q8_037GB接近原版大显存或纯CPU推理Q6_K26GB高质量12GB以上显存尝试Q5_K_M24GB高质量12GB以上显存推荐Q4_K_M20GB甜点级8GB显存跑35B首选Q3_K_M15.5GB中等内存紧张时妥协Q2_K12GB明显损失仅做验证或极简环境这里面的K_M和K_S都来自 K-quants 算法S 代表 small更小M 代表 mixed混合。下模型时优先选带_K的版本不要碰老式q4_0、q4_1它们虽然名字也叫 Q4但质量控制不如新算法。如果你想进一步确认 Ollama 里模型的量化细节执行ollama show qwen2.5:32b输出里会告诉你具体的量化等级和参数量不放心就多看一眼。6. 散落在 8GB 跑 35B 这条路上的一些个人心得6.1 8GB 跑 35B 到底图什么折腾完这一整轮我最想强调的一点是8GB 跑 35B 从来不是一件“爽”的事它是一件“值不值”的事。如果你要的是实时对话、快速写代码、即时回复那 7B/8B 模型才是 8GB 显存的正道每秒几十 token 的流畅感是 35B 永远给不了的。但如果你和我一样更多是把本地大模型当成“夜间档的打工人”丢给它一百份PDF让它整理摘要或者让它批量清理日志里的异常记录那 35B Q4 慢归慢产出的质量却比 7B 高出一大截。说白了这是用等待时间换模型能力的典型交易关键看你手头任务值不值得等。从成本角度看这个方案也确实有点意思。一张 2000 元价位的 8GB 消费级显卡配合 32GB 内存就能在本地跑起接近云端商用模型能力的开源大模型全程不需要联网数据不出机器。对在意隐私、又不想按 token 付费的人来说这种“牺牲速度、获得自主”的路线性价比其实很高。6.2 后续可以怎么玩如果你跑通了这个方案后面可以顺理成章再走两步。第一步是把模型接入本地知识库也就是社区里常说的 RAG 方案。用一个小型的 embedding 模型把文档切片转成向量检索出相关内容再把结果 35B 模型做最终回答。这样你手里相当于多了一个“读过本地所有资料、随叫随到”的离线顾问这是 7B 模型很难做好的。第二步是用 35B 模型当“老师”把它的高质量输出蒸馏到一个小模型里用来跑实时任务这在开源社区里已经是挺常见的玩法了。我做测试时已经顺手把摘要能力接到了知识库流程里实测处理本地文档的效果明显好于直接问 7B 模型。6.3 最后分享一个定位甜点区的小技巧收尾之前把我的压箱底技巧交出来。很多人拿到模型后喜欢抄网上的参数推荐但这个推荐值不一定适合你的机器因为每台机器的显存剩余量、内存带宽、CPU 性能都不一样。正确做法是亲自试出一个“甜点区”打开一个终端跑nvidia-smi -l 1实时监控另一个终端启动推理。从-ngl 10开始每跑一轮固定提示词记下速度然后-ngl加 5再测直到显存占用逼近 95% 或出现 OOM。出现 OOM 后回退 5 到 10 层再微调一次你得到的这个层数就是你这台机器最合适的配置。整个过程大约需要十分钟比任何默认参数都靠谱。这个技巧在 8GB、12GB、16GB 显存上通用区别只是最终层数不同。我自己的 RTX 4060 最终停在-ngl 20如果你的卡是 3060 12GB可能能到 30 以上速度也会好不少。测完这个你的“8GB 跑 35B”就不再是玄学而是一套可以稳定复用的本地生产力方案。