在RTX 2070 / 2070 Super（8 GB）上推荐使用哪个大语言模型？ ?

#RTX 2070 和 2070 Super：8GB 显存能实现什么？

在 RTX 2070 或 2070 Super 上，7 到 9B 参数的模型在 Q4 量化下可以完全装入显存：这是这些显卡的舒适区。根据 QuelLLM 目录，Granite 4.2 8B 在 Q4 下需要 4,6 GB 权重，Qwen 3.5 9B 约需 6 GB。只要上下文长度保持合理，就还有空间留给上下文。像 Gemma 4 12B 这样的 12B 模型（Q4 下为 7 GB）只留下不到一吉字节给缓存和系统：理论上能跑，但实际体验很差。在速度方面，2070 Super 在 llama.cpp 的基准测试中，运行 Q4_0 量化的 7B 模型可达每秒 88 个 token，远超人类的阅读速度。因此，这些显卡的真正瓶颈不是速度，而是内存容量。

RTX 2070

2018年10月，2304个CUDA核心，8 GB GDDR6显存，256位总线，达448 GB/s（256位，14 Gbit/s）

RTX 2070 Super

2019年7月，2560个CUDA核心，仍为8GB显存，带宽仍为448GB/s，功耗为215W。

它们在运行 LLM 时有何区别

几乎没有区别：带宽和显存容量相同。Super 版本的核心更多，主要有助于处理提示词，而不是生成。

最后这一点有些反直觉：生成文本时，GPU 每生成一个 token 都会重新读取模型的全部权重，因此内存带宽比核心数量更重要。两张内存带宽均为 448 GB/s 的显卡，在文本生成时的吞吐量会很接近，即使其中一张在游戏中明显更快。

#8 GB 能容纳哪些模型

模型权重只占显存需求的一部分：还要加上上下文缓存（KV 缓存），它会随着对话变长而增大，并为驱动程序和显示预留一些空间。对于 8 GB 显存的显卡，如果您希望使用数千 token 的上下文，经验法则是选择权重大小不超过 6 GB 的模型。作为参考，llama.cpp 的测试工具在一张 8 GB 的 RTX 3060 Ti 上检测到 7 838 MiB 空闲显存，略低于理论上的 8 192 MiB：即使尚未加载模型，也已经有几百兆字节被占用。

8B 模型的 Q8 版本（9 GB）装不下：在 8 GB 显存下，通常应采用 Q4 量化，较小的模型仍可使用 Q5。要比较不同量化级别，关于如何选择 Q4、Q5、Q8 的指南详细介绍了预期的质量损失。对于具体项目，本网站的 VRAM 计算器会根据模型和上下文给出准确的显存占用。

• 选择量化方案（Q4、Q5、Q8、FP16）
• 给定模型和上下文的显存计算器

#速度：基准测试衡量什么

唯一可用的公开参考是 llama.cpp 仓库中的协作表格，用户在其中发布同一条命令的运行结果：对 Llama 2 7B 的 Q4_0 量化版本运行 llama-bench，文件大小为 3.56 GiB，所有模型层均放在 GPU 上。表格说明，即使使用相同的芯片，结果也会因驱动程序、操作系统和显卡制造商而有所不同。这些并非本站测得的数据：下列数字来自该表格，其中“读取”列表示提示处理吞吐量（pp512），而“生成”列表示回答生成吞吐量（tg128）。

两点经验。首先，2070 Super的生成速度高于RTX 3060 12GB（88.1对75.6个token/秒，相差约17%）：速度并非决定替换其核心因素。其次，RTX 2060 Super的带宽为448 GB/s，与2070 Super相同，但生成速度仅为60个token/秒，比前者低32%。因此，带宽上限并非准确预测值：显卡驱动状态、频率和显卡规格同样重要。请将这些数值视为数量级参考。

#从测试模型推算到当前模型：比例换算

测试模型的大小为 3.82 GB（3.56 GiB）。由于生成速度受权重读取速度限制，在其他条件相同的情况下，模型体积越大，生成速度就会按比例降低。对于 Q4 量化的 Granite 4.2 8B（4.6 GB），最多可得到 88 × 3.82 ÷ 4.6，即约每秒 73 个 token；对于 Q4 量化的 Qwen 3.5 9B（6 GB），则约为每秒 56 个 token。这些是理论上限，而不是实测值：较新的架构（混合架构模型、混合专家模型）以及上下文长度都会影响结果，可能使其升高，也可能使其降低。

这条规则有实际用途。如果针对您的配置公布的数值远低于上述数量级，例如运行 Q4 量化的 8B 模型时低于每秒 15 个 token，就说明模型的一部分被卸载到了系统内存：先检查显存占用，再把问题归咎于显卡。Ollama 故障排查指南介绍了具体操作步骤。

• 排查 Ollama 故障：GPU 未检测到、运行缓慢、内存错误

#上下文与 KV 缓存：用好 8 GB 显存的关键

随着对话变长，生成吞吐量会下降，因为模型在生成每个 token 时也要重新读取缓存。在显存为 8 GB 的显卡上，下降幅度仍较小：现有的相近型号显卡公开测量结果显示，降幅约为几个百分点。第二个影响体现在显存占用上：K/V 缓存占用的显存与上下文长度成正比。Ollama 的两个设置可以减轻 8 GB 显卡的压力。Flash Attention 可以在上下文增长时减少内存消耗，Ollama 文档还明确说明，启用 Flash Attention 后可以量化 K/V 缓存。根据文档，q8_0 类型使用的内存约为默认 f16 格式的一半，精度损失非常小。

1. 01
   启用 Flash Attention

   通过设置环境变量 OLLAMA_FLASH_ATTENTION=1 启动服务器。Ollama 在硬件和模型支持的情况下会自动启用该功能；此变量用于强制启用。
2. 02
   量化K/V缓存

   添加 OLLAMA_KV_CACHE_TYPE=q8_0。只有在别无选择时才降至 q4_0：文档指出，在长上下文下可能出现效果下降。
3. 03
   检查占用情况

   输入一条长提示词，并使用 nvidia-smi 查看显卡的显存占用：如果显存已满，请缩短上下文，而不是让 Ollama 将模型的一部分转移到系统内存（RAM）中。

OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve

在 2070 Super 上，llama.cpp 测试中启用 Flash Attention 后的生成速度为 87.7 token/秒，未启用时为 88.1 token/秒：因此，这里不能指望它提升生成速度。不过，提示词处理速度从 2 088 token/秒提升至 2 293 token/秒，这对长文档和 RAG 很重要。如果想进一步了解这一主题，可以阅读专门介绍缓存量化的完整指南。

• 量化 KV 缓存：节省 VRAM（长上下文）

#2026 年的 Turing：驱动程序、支持与限制

Turing 显卡仍受支持。Ollama 文档要求计算能力至少为 5.0，驱动版本至少为 550；RTX 2070、2080 和 2080 Ti 均列在其计算能力为 7.5 的显卡列表中。Turing 甚至已经成为最低支持架构：CUDA 13 的版本说明指出，已停止支持早于 Turing 的架构（Maxwell、Volta 和 Pascal）。目前没有依据确定 Turing 支持结束的日期，贸然公布这样的日期并不可靠；谨慎的做法是在每次 CUDA 重大更新时关注这些版本说明。

仍有一个实际限制：新模型通常先以面向较新硬件的格式发布，之后社区才会为您这样的显卡提供 Q4 量化的 GGUF 转换版本。这并不会妨碍使用 Ollama 或 llama.cpp，但模型以可读取格式推出的时间可能会晚一两天。

#2070 Super、3060 12GB 或 3060 Ti：如何选择？

在速度相近的情况下，显存容量决定选择。从 2070 Super 换成 3060 Ti，并不会改变 9B 的模型规模上限；换成 3060 12 GB 则可以运行 120 亿参数的模型并使用长上下文，代价是吞吐量略低。二手价格每周都在变化：做决定前，请查看本站的价格追踪。

• 本地 AI 显卡价格（每周追踪）
• RTX 3060 12 GB 上适合运行哪个 LLM？
• 8 GB VRAM下适合哪些LLM？（所有显卡）

#2026 年评估：保留、购买或转向其他方案

在以下情况下继续保留

您使用的是基于 70 亿至 90 亿参数模型的助手，采用 Q4 量化，用于处理短代码、生成摘要或进行适度的 RAG。运行速度已经很充裕，没有必要更换显卡。

如果您符合以下情况，请考虑其他方案

如果您想运行一个留有实用上下文容量的 12B 模型、一个 14B 或更大的模型，或处理很长的文档，那么至少需要 12 GB 显存，16 GB 才更从容。

二手购买

只有当价格明显低于一张 12 GB 显卡时，2070 Super 才值得考虑。请检查保修情况和风扇状态，因为这些显卡已经使用了好几年。

#常见问题

• 来源：llama.cpp 在 CUDA 上的性能表格
• 来源：Ollama 支持的 NVIDIA 显卡
• 来源：Ollama FAQ（Flash Attention，K/V缓存）
• 数据来源：GeForce 20系列显卡规格