GTX 1060 跑 Qwen 35B 实战：llama.cpp 从 3 tok/s 优化到 17 tok/s

6GB 显存的 GTX 1060 能不能跑 35B 级别的大模型？

如果按传统理解，第一反应多半是“不太现实”。35B 参数量太大，显存只有 6GB，哪怕模型已经量化，也很容易遇到速度慢、内存爆、上下文上不去、跑一会儿就不稳定的问题。

但如果模型是 MoE 架构，再配合 llama.cpp 的分层卸载、CPU 内存承接和参数调优，事情就会变得有意思：它不一定能变成高端显卡那种体验，但可以从“勉强能跑”优化到“日常测试能用”。

这篇按实操思路整理：目标不是神化 GTX 1060，而是讲清楚低显存显卡跑 Qwen 35B 这类模型时，应该先看哪里、调哪里、怎么判断瓶颈。

先说结论

低显存显卡跑 35B 模型，关键不是把所有东西都塞进显存，而是让 GPU 只承担最值得加速的部分。

大致思路是：

1
2
3
4
5
6
7

先能跑起来
-> 看默认速度为什么慢
-> 调整 GPU 卸载层数
-> 利用 MoE 特性减少不必要负担
-> 修复内存和缓存瓶颈
-> 再拉上下文长度
-> 最后处理稳定性

如果一开始就盯着“显存不够怎么办”，很容易走偏。更实际的目标应该是：让显存、内存、CPU、磁盘和上下文缓存配合起来，而不是只看显卡型号。

准备环境

这种玩法建议先准备好几个条件：

• 一张 6GB 显存左右的 NVIDIA 显卡，例如 GTX 1060 6GB；
• 足够的系统内存，越低越容易卡在 swap 或 OOM；
• 已经编译好 CUDA 版本的 llama.cpp；
• 一个适合低显存尝试的量化模型文件；
• 能接受速度不是云端 API 级别；
• 会查看显存、内存和进程占用。

可以先用下面这些命令确认环境：

1
2
3

nvidia-smi
free -h
./llama-cli --help

如果 nvidia-smi 看不到显卡，或者 llama.cpp 没有 CUDA 支持，后面再怎么调参数都不会有理想效果。

第一步：先让模型跑起来

不要一上来就追求 17 tok/s。第一步只看一件事：模型能不能正常加载并输出。

一个基础命令通常长这样：

1
2
3
4

./llama-cli \
  -m /path/to/model.gguf \
  -p "用三句话解释什么是 MoE 模型" \
  -n 128

如果这一步都失败，先不要急着加 GPU 参数，优先检查：

• 模型文件路径是否正确；
• 模型量化格式是否被当前 llama.cpp 支持；
• 系统内存是否足够；
• 是否下载了错误版本的模型；
• 当前二进制是否支持对应模型架构。

能跑起来以后，再开始优化速度。

为什么默认速度可能只有 3 tok/s

低显存环境下，默认参数慢通常不是一个原因造成的。

常见瓶颈有这几类：

所以调优时不要只看一个 tok/s 数字。建议同时开着：

1
2

watch -n 1 nvidia-smi
htop

观察 GPU 显存、GPU 利用率、CPU 占用和系统内存是否同步变化。

第二步：调整 GPU 卸载

llama.cpp 里最常见的加速思路是把部分层卸载到 GPU。

常用参数是：

1

-ngl 20

或者完整一点：

1
2
3
4
5

./llama-cli \
  -m /path/to/model.gguf \
  -p "写一个本地大模型调优 checklist" \
  -n 256 \
  -ngl 20

这里的 20 不是固定答案。低显存显卡要一点点试：

1
2
3
4

-ngl 10
-ngl 15
-ngl 20
-ngl 25

每次调整后看三件事：

1. 是否能正常启动；
2. 显存是否接近打满；
3. tok/s 是否真的提升。

如果显存已经顶满，再继续加 -ngl 只会让程序更不稳定，不一定更快。

第三步：理解 MoE 为什么重要

MoE 模型和普通 dense 模型不太一样。

MoE 的核心特点是：模型参数总量很大，但每次推理不一定激活全部专家。也就是说，标称 35B 并不代表每个 token 都要完整跑一遍 35B 的全部计算。

这也是低显存显卡有机会尝试的关键原因。

但要注意两点：

• MoE 不是免费魔法，模型文件仍然很大；
• 显存不够时，仍然需要 CPU 内存承担大量数据。

所以优化 MoE 模型时，重点是把真正高频、值得加速的部分交给 GPU，把显存放在刀刃上。

第四步：处理内存瓶颈

很多人以为低显存跑不动，只是显存问题。实际更常见的是显存、内存、缓存一起卡。

如果运行时系统内存接近耗尽，或者 swap 开始大量使用，速度会明显下降。可以用：

1

free -h

或者：

1

vmstat 1

观察是否出现频繁 swap。

优化方向包括：

• 换更小的量化版本；
• 降低上下文长度；
• 降低 batch；
• 减少并发任务；
• 关闭不必要的后台程序；
• 确保模型放在速度较快的 SSD 上；
• 给系统留足内存余量。

如果系统内存本身太小，6GB 显卡再怎么调也很难舒服。

第五步：上下文长度不要一开始拉满

很多模型默认宣传支持很长上下文，但低显存机器不要一开始就拉满。

建议先从较小上下文开始：

1

-c 4096

确认稳定后再尝试：

1

-c 8192

再往上加时，要观察内存和速度变化。

上下文越长，KV cache 压力越大。低显存设备上，长上下文通常比单纯生成短回答更容易暴露问题。

如果你的目标只是本地问答、代码片段解释、短文本总结，没必要一开始追求特别大的上下文。

第六步：关注 batch 参数

llama.cpp 的 batch 参数会影响 prompt 处理和生成表现。不同版本参数名称可能略有变化，可以先看帮助：

1

./llama-cli --help

常见思路是：

• prompt 很长时，适当调 batch 可能改善处理速度；
• 显存紧张时，batch 太大可能导致不稳定；
• 不要照抄别人的数值，按自己机器测试。

调参时建议一次只改一个参数。

比如先固定模型、上下文和 -ngl，再尝试 batch。否则你很难判断到底是哪一个参数带来了变化。

第七步：记录自己的五个关键参数

低显存本地推理最怕“今天能跑，明天忘了怎么配”。

建议每次测试都记录这几个参数：

可以简单写成：

1
2
3
4
5
6
7

model: Qwen-xx-35B-xxx.gguf
gpu: GTX 1060 6GB
ngl: 20
ctx: 4096
batch: 默认
speed: 约 17 tok/s
status: 短文本稳定，长上下文需继续测试

这样下次换模型或换机器时，就能快速对比。

一个更稳的测试流程

推荐按这个顺序做：

1. 不加 GPU 卸载，确认模型能加载；
2. 加较低 -ngl，确认能输出；
3. 逐步提高 -ngl，找到显存临界点；
4. 固定 -ngl，调整上下文长度；
5. 固定上下文，再测试 batch；
6. 用同一段 prompt 对比 tok/s；
7. 跑 10 到 20 分钟，观察是否稳定；
8. 记录最终参数。

不要每次换一个 prompt 测速度。prompt 不同，结果没有可比性。

可以准备一个固定测试提示词：

1

请用 800 字解释 MoE 模型为什么适合低显存推理，并给出三个注意事项。

每轮都用同一个提示词，才方便判断优化是否真的有效。

常见失败尝试

低显存调大模型时，这几类操作很容易浪费时间：

1. 盲目拉高 GPU 卸载层数

看到 -ngl 提升速度，就一直往上加。

问题是 GTX 1060 只有 6GB 显存，越过临界点后，程序可能直接报错，或者看似启动了但运行不稳定。

2. 一开始就拉超长上下文

长上下文对内存和 KV cache 压力很大。先用短上下文把模型跑稳，再扩上下文更实际。

3. 只看平均 tok/s

tok/s 是重要指标，但不是唯一指标。

你还要看：

• 首 token 延迟；
• prompt 处理速度；
• 显存是否溢出；
• 长时间运行是否稳定；
• 系统是否卡到影响其他操作。

4. 不记录参数

本地推理调优经常需要反复试。没有记录，很容易陷入“刚才那个能跑的参数是多少来着”的循环。

适合 GTX 1060 的预期

GTX 1060 这类老显卡适合做什么？

适合：

• 学习 llama.cpp；
• 测试 GGUF 模型；
• 跑短文本问答；
• 做本地模型参数实验；
• 体验 MoE 模型的低资源运行方式；
• 验证某个模型是否值得换更好硬件部署。

不太适合：

• 高并发服务；
• 超长上下文重度使用；
• 多用户同时推理；
• 大规模 RAG 生产环境；
• 对延迟非常敏感的实时应用。

把 GTX 1060 当成实验机器，它很有价值。把它当成生产级大模型服务器，就容易失望。

一句话总结

6GB 显存跑 Qwen 35B 这类模型，真正的重点不是“硬塞进显卡”，而是用 llama.cpp 把 GPU 卸载、MoE 特性、系统内存、上下文长度和 batch 参数协调起来。

如果你手里刚好有 GTX 1060 这种老显卡，可以按这个顺序试：

1

先跑通 -> 调 -ngl -> 看显存 -> 控上下文 -> 查内存 -> 测 batch -> 记录 tok/s

从 3 tok/s 到 17 tok/s，不靠玄学，靠的是一步步把瓶颈拆开。