放弃等RTX 3090：用8G老显卡跑本地大模型

在本地部署大语言模型的想法，我琢磨很久了。

倒不是指望端侧小模型能彻底取代云端的大模型，而是在实际业务里，本地推理有独特的优势。日常做软件开发、对接电商接口、搭建仓储物流系统，很多环节都用得上：从发货单中提取结构化信息、自动匹配供应商货号、本地数据分析，甚至是让 AI Agent 协助执行自动化运维任务。

我原本的计划很常规：等手里那张 24GB 显存的微星 RTX 3090 SUPRIM X 修好再开工。毕竟大显存才是本地跑模型的底气。

然而那张卡出了硬件问题，满屏花斑、屏幕闪烁，显存报错不断。在把它彻底清理并排查出具体原因之前，我不得不找点别的替代品。

手边刚好有一张闲置的 NVIDIA RTX 2070，显存只有 8GB。

这卡发布于 2018 年。在现在的生成式 AI 讨论里，几乎没有人会推荐一块 8 年前的 8GB 显卡。

但抱着「反正闲着也是闲着，能慢到哪去」的心态，我在 Ubuntu 系统上配齐了环境，用 llama.cpp 载入了几个小型语言模型。

原本以为打几个字要等半天，结果屏幕上的代码生成速度直接飙到了 50、60，甚至逼近 80 tokens/s。

在这一块老掉牙的 RTX 2070 上，惊喜才刚刚开始。

基础测试：速度出乎意料

测试环境没有特殊黑科技：Ubuntu 24.04.5，NVIDIA 驱动版本 595.99.02，编译了 CUDA 加速的 llama.cpp。

我选了四款常见的小模型做对比：

模型	量化格式	实际代码生成速度
Qwen3.5 4B	Q4_K_M	78.45 tokens/s
Gemma 4 E4B Instruct	Q4_K_M	64.67 tokens/s
Qwen3.5 9B	Q4_K_M	51.49 tokens/s
Gemma 4 12B Instruct	Q3_K_M	31.15 tokens/s

注：这些数据来自实际编写代码时的吞吐，并非严格控制上下文长度的标准基准测试。但足够说明问题：即使是参数量最大的 12B 模型，在降到 Q3 量化后，31 tokens/s 的速度也完全在可用范围内。

两款 4B 级别的模型更是流畅到没有任何粘滞感。提问、拿结果、改提示词、重新生成，交互节奏非常轻快。

但光跑得快没用，还得看它能不能干活。

写一个俄罗斯方块：大模型不一定赢

为了检验逻辑能力，我给它们布置了一个完整的小任务：

用单文件 HTML（包含原生 JavaScript 与 CSS）写出可直接在浏览器运行的俄罗斯方块。要求包含经典的全部 7 种方块、旋转、碰撞检测、消行积分、难度等级与重新开始功能，严禁引入任何外部前端框架。

首先上场的是 Gemma 4 E4B。

令人意外的是，它一次性吐出的初版代码直接就能玩。方块下落顺畅，键盘响应正常，得分逻辑也在运转。虽然界面简陋，但这仅仅是一个 4B 参数的模型在老显卡上单次生成的成果。

换到参数更大的 Qwen3.5 9B，情况反而变糟了。连续两次尝试，生成的 JavaScript 代码都存在关键语法错误，游戏页面直接白屏报错无法初始化。更小的 Qwen 4B 同样在方块旋转算法和边界碰撞判定上出现了逻辑硬伤。

参数更大的模型，不等于一次性交付更高质量的代码。

随后，我尝试让表现最好的 Gemma 继续重构和优化自己的俄罗斯方块，有意思的事情发生了。

AI 的死穴：自己修 Bug 往往越修越烂

我让 Gemma 给游戏增加新功能并优化渲染性能。它自信满满地列出了修改清单，并保证所有逻辑完美运作。

结果一刷新，画面直接崩了。

再让它修复，画面虽然找回，计时器又出了故障。改到后来，游戏出现了一个荒唐的恶性 Bug：方块下落速度越来越快，彻底失控。

排查后发现，Gemma 重构时把 setTimeout 递归调用的生命周期写乱了。每次重置或触发条件时，它都会新开一个定时循环，却忘了注销旧定时器。多个定时器同时执行，下落速度直接翻倍。

最值得玩味的是它的反应：当你直接把整段代码丢给它问「这段代码有没有 Bug」时，它会非常自信地告诉你逻辑完全正确，甚至还会夸夸其谈这段架构写得多么优雅。

但换一种方式，我不给它模糊提问，而是列出具体的复现流程：「当重置按钮触发时，变量 A 和定时器 B 会发生什么？请追踪两轮循环内的调用堆栈。」

它瞬间定位到了问题根源，精准指出了多个定时器并发冲突的原因，并给出了干净的修复代码。

小参数模型并不缺乏逻辑推理能力，但它们极度缺乏「自我发现漏洞」的自审能力。

这就解释了为什么给编辑器装上 AI 插件不等于多了一个靠谱工程师。如果缺乏外部输入——比如自动化测试用例、明确的异常报错和确定性的状态追踪，模型只会顺着自己的幻觉一路狂奔。

极限压榨：8GB 显存硬塞 128K 上下文

8GB 显卡跑本地模型，最大的瓶颈通常被认为是上下文窗口。随着对话变长，KV Cache 会迅速吞噬本就不富裕的显存。

我测试了这些模型在当前硬件下能够正常初始化的极限上下文配置：

• Qwen3.5 4B (Q4)：成功加载 128K 上下文
• Gemma 4 E4B (Q4)：成功加载 128K 上下文
• Qwen3.5 9B (Q4)：最高支持 32K 上下文
• Gemma 4 12B (Q3)：成功加载 128K 上下文（显存占用约 7115 MiB）

要在 8GB 显存内将 12B 模型撑到 128K 上下文，关键在于 KV Cache 的量化。如果使用默认的 Q8 精度，显存瞬间打满 OOM；而切换到 Q4 格式的 KV Cache 后，系统成功拉起，还余下数百兆缓冲空间。

必须说明：能以 128K 上下文成功启动服务，并不代表把 128K 全部塞满文字后模型还能维持高检索召回率与推理速度。 但这足以证明，只要合理利用量化工具，老架构显卡的内存边界远比想象中宽阔。

算力暴涨 57%，推理速度却毫无变化？

在压榨这块 RTX 2070 的过程中，我尝试了一个名为 turing-unlock 的开源驱动补丁。部分采用 Turing 架构的显卡在底层限制了部分半精度浮点计算能力，该工具声称可以解锁完整的 FP16 性能。

打上补丁后实测，底层的 FP16 矩阵乘法跑分从 33.19 TFLOPS 一路冲到 52.35 TFLOPS，理论算力足足提升了 57.7%。

我兴冲冲地回到 llama.cpp 里重新跑 Qwen3.5 4B 测试：

• 解锁前：生成速度 101.13 tokens/s
• 解锁后：生成速度 101.43 tokens/s

提升幅度约等于 0.3%。

理论算力大幅提升，实际大模型推理纹丝不动。这给沉迷参数的人上了一课：量化大模型的端侧推理主要受限于显存带宽、内存延迟以及整型算子调度，单卡理论 FP16 浮点峰值再高，也填不满瓶颈处的短板。跑分好看和实际好用完全是两码事。

让本地模型调用真实工具

如果大模型只能当聊天机器人，那本地部署的价值就折损了大半。

在最后阶段，我尝试引入 Agent 框架。我通过 llama.cpp 的 --jinja 参数开启工具调用接口，并将运行在本地的 Gemma E4B 接入了 OpenClaw 框架，跑在严格限制权限的只读 Docker 沙箱内。

我给它下达了探索工作区并检查配置文件的指令。没有任何云端大模型参与，这个跑在 2018 年老显卡上的 4B 模型，自行分析了需求，向本地环境生成了 ls 和 read 工具调用。

它准确读取了返回的真实文件内容，并在上下文里提取出关键配置，给出了条理分明的总结汇报。

虽然这只是一个最基础的文件遍历测试，但底层链路已经跑通：哪怕是一张百元级的旧显卡，搭配几亿到几十亿参数的轻量模型，也已经具备了作为边缘 Agent 处理确定性任务的完整能力。

不必被硬件焦虑绑架

折腾这一圈之前，我和大多数人一样陷在硬件焦虑里：显存够不够用？模型参数是不是太小？是不是必须买到 RTX 3090 甚至 4090 才能开始做本地 AI？

实测之后，我的思路变了。

高端显卡自然更好，它让你有余力去跑高精度、大参数的全尺寸模型。但如果你的目标是探索工作流自动化、理解工具调用链、在局域网内给业务系统搭建专用的小型辅助接口，那么一张躺在二手箱里的旧显卡，配合持续进化的开源模型生态，已经完全够用了。

现在的开源生态里，真正限制发挥的往往不是硬件，而是你有没有给模型设计出足够闭环的验证机制和上下文工程。

把确定性的逻辑交给自动化脚本，把模糊识别、提炼和工具分发交给本地小模型。先动手在老硬件上把流程跑顺，往往比等待一块完美的显卡有价值得多。