企业官网建设流程全解析

1. 为什么要在 8GB 显存上硬啃 35B ？

1.1 很多人说显存不够模型白搭，但“硬啃”不是瞎折腾

先说结论：8GB 显存跑 35B 参数模型，能跑，但别指望它像小模型那样打字飞快。我花了一周时间，在一张 RTX 4060 8GB 的消费级显卡上，把 Qwen2.5-32B-Instruct 的 GGUF 量化模型完整跑了起来，并且做了一轮速度、内存、稳定性、输出质量的多维度测试。整个过程涉及量化选型、显存预算、CPU/GPU 协同调度，踩过的坑和最终数据都收在这篇实录里。

很多人拿到 8GB 显卡第一反应是：“显存只有 8GB，那不就只能玩 7B 模型吗？”这个想法不算错，但如果只停留在这一步，其实浪费了消费级硬件一半的潜力。传统认知里，大模型显存需求按权重精度线性膨胀，35B 参数在 FP16 下要占 70GB，8GB 显存连零头都不够。可是本地模型生态这几年发展得比多数人想象中快，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 量化后约 37GB，Q6 约 26GB，Q5_K_M 约 24GB，Q4_K_M 约 20GB，Q3_K_M 约 15.5GB，Q2_K 约 12GB。看到区别了吗？同样一个模型，FP16 要 70GB，Q4 只要 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、运行缓冲。模型权重是大头，20GB；KV 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_layers，Ollama 里对应的是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 模型 20GB，GPU 放了 6GB，剩下约 14GB 必须放在系统内存里，加上进程本身和 KV Cache，内存占用会到 16 到 18GB。这意味着你的电脑最好有 32GB 内存。16GB 内存也不是不能试，但很容易触发 swap，速度直接掉到每分钟几个字，那种卡顿感会让人当场放弃。

3. 实测环境与实操流程

3.1 我的测试机器和软件环境

先把实测环境交代清楚，因为“能不能跑”“跑多快”和硬件强相关，没有这套环境参考，后面所有数字都毫无意义。我用的机器配置是：CPU 为 Intel i5-12400F，6 核 12 线程；内存 32GB DDR4 3200 双通道；显卡是 NVIDIA RTX 4060，8GB 显存；操作系统为 Windows 11 中文版，配合 WSL2 Ubuntu 22.04 环境。储存是一块普通 SATA SSD，模型文件大约需要 20GB 空间。

为什么在 WSL2 里跑而不是 Windows 原生环境？两个原因：一是 llama.cpp 和 Ollama 在 Linux 下的调度和性能释放更稳定，日志信息也更完整；二是 WSL2 天然和 NVIDIA 的 Linux 驱动配合良好，直接用 CUDA 跑推理，方便我用nvidia-smi实时盯显存。如果你不熟悉 WSL，Windows 原生安装 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:32b，Ollama 默认会尝试把所有层都放进 GPU 显存。8GB 显存放不下 20GB 模型，于是要么启动过程漫长，要么直接报CUDA error: out of memory退出。解决办法是给模型做一个显存层数限制配置，写一个类似 Dockerfile 的 Modelfile，内容如下：

FROM qwen2.5:32b PARAMETER num_gpu 20 PARAMETER num_ctx 4096

FROM指定基础模型，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 适合“深度调性能”。为了让你选起来更省心，我直接把两者的差异列个表：

如果你只是想知道“8GB 能不能跑 35B”，Ollama 五分钟出结果，个人强烈推荐先走这一步。但如果你打算长期用这个模型做本地知识库或离线任务，最好早点切换到 llama.cpp，因为它的运行日志能帮你持续优化参数，比如调整完-ngl之后，速度变化能看到直接原因。这个细节在 Ollama 里被完全隐藏，出了问题都不知道从哪下手。

4. 实测数据：速度、内存和输出质量

4.1 三种常见 35B 量化级别跑出来的真实数字

纸上谈兵到这里，该上真正的实测数据了。我用相同的提示词“写一段300字关于开源大模型本地部署价值的说明”，在三种量化级别下分别做测试，每个跑三轮取中间值。上下文设置为 4096，GPU 层数按可用显存极限调整。结果如下：

这组数据对应的背景是：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 模型光权重就要 20GB，16GB 内存连文件都装不完，系统必然触发 swap，速度降到每分钟几个字，这种情况下再好的配置也是白搭。如果你只有 16GB 内存，有两个务实选择：一是换 Q3_K_M 量化版本，模型文件约 15.5GB，勉强能装下但内存会被占满，需要关掉所有后台程序；二是继续用 Q4_K_M，但把 GPU 层数提高一些，让显存多分担一点，同时忍受内存几乎被占光的现实。

如果你在用 WSL2 跑 Ollama，建议在 Windows 用户目录下建一个.wslconfig文件，限制 WSL 分配的内存上限，避免 Windows 被挤得卡死。示例配置如下：

[wsl2] memory=24GB processors=8

改完这个文件，需要执行wsl --shutdown重启 WSL 才生效。说到底，内存不足最好的解决方案永远是加一条内存条，32GB 是 8GB 显存跑 35B 的及格线，这一步省不得。

5.4 那些量化标签 Q4_K_M、Q5_K_S 到底怎么读？

很多人在下模型的时候看到一长串文件名里的Q4_K_M、Q5_K_S、Q3_K_M等标签，完全不知道是什么意思。简单说，这些标签表达了“量化位数”和“量化方法”。我按体积从大到小整理一份速查表：

这里面的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”就不再是玄学，而是一套可以稳定复用的本地生产力方案。