适用于16GB显存GPU的最佳LLM模型

在配备16GB VRAM的RTX 4080上进行LLM速度测试

目录

在本地运行大型语言模型可以为您提供隐私保护、离线功能以及零API成本。 这项基准测试揭示了在RTX 4080上使用Ollama的9种流行LLMs可以预期的具体表现。

在拥有16GB显存的GPU上，我面临一个持续的权衡： 选择更大的模型可能带来更好的质量，或者选择更小的模型以实现更快的推理。

7 llamas - Comparing LLMs on Ollama

TL;DR

以下是使用Ollama 0.15.2在RTX 4080 16GB上LLM性能的比较表：

模型 使用的显存+显存 CPU/GPU 分配 每秒生成的令牌数
gpt-oss:20b 14 GB 100% GPU 139.93
ministral-3:14b 13 GB 100% GPU 70.13
qwen3:14b 12 GB 100% GPU 61.85
qwen3-vl:30b-a3b 22 GB 30%/70% 50.99
glm-4.7-flash 21 GB 27%/73% 33.86
nemotron-3-nano:30b 25 GB 38%/62% 32.77
devstral-small-2:24b 19 GB 18%/82% 18.67
mistral-small3.2:24b 19 GB 18%/82% 18.51
gpt-oss:120b 66 GB 78%/22% 12.64

关键见解：完全适合显存的模型速度明显更快。GPT-OSS 20B达到139.93个令牌/秒，而GPT-OSS 120B由于大量使用CPU卸载，仅达到12.64个令牌/秒——速度相差11倍。

测试硬件设置

基准测试在以下系统上进行：

  • GPU：NVIDIA RTX 4080，16GB显存
  • CPU：Intel Core i7-14700（8个P核心 + 12个E核心）
  • 内存：64GB DDR5-6000

这代表了本地LLM推理的常见高端消费级配置。16GB显存是关键限制因素——它决定了哪些模型可以在GPU上完全运行，而哪些模型需要CPU卸载。

当模型超出显存容量时，了解Ollama如何使用Intel CPU核心变得非常重要，因为CPU性能直接影响卸载层的推理速度。

本基准测试的目的

主要目标是在实际条件下测量推理速度。我已经知道Mistral Small 3.2 24B在语言质量方面表现优异，而Qwen3 14B在特定使用案例中提供了更优的指令遵循能力。

本基准测试回答了实际问题：每个模型生成文本的速度如何，以及超出显存限制时的速度惩罚是多少？

测试参数如下：

  • 上下文大小：19,000个令牌
  • 提示语：“比较澳大利亚首都城市的天气和气候”
  • 指标：评估率（生成期间每秒的令牌数）

Ollama安装和版本

所有测试使用的是Ollama版本0.15.2，这是测试时的最新版本。要了解本基准测试中使用的Ollama命令的完整参考，请查看Ollama速查表。

在Linux上安装Ollama：

curl -fsSL https://ollama.com/install.sh | sh

验证安装：

ollama --version

如果由于空间限制需要将模型存储在不同的驱动器上，请查看如何将Ollama模型移动到不同的驱动器。

测试的模型

以下模型进行了基准测试：

模型 参数 量化 说明
gpt-oss:20b 20B Q4_K_M 整体最快
gpt-oss:120b 120B Q4_K_M 测试中最大的模型
qwen3:14b 14B Q4_K_M 指令遵循最佳
qwen3-vl:30b-a3b 30B Q4_K_M 支持视觉
ministral-3:14b 14B Q4_K_M Mistral的高效模型
mistral-small3.2:24b 24B Q4_K_M 语言质量优异
devstral-small-2:24b 24B Q4_K_M 代码导向
glm-4.7-flash 30B Q4_K_M 思考模型
nemotron-3-nano:30b 30B Q4_K_M NVIDIA的模型

下载任何模型的命令如下：

ollama pull gpt-oss:20b
ollama pull qwen3:14b

理解CPU卸载

当模型的内存需求超过可用显存时，Ollama会自动在GPU和系统内存之间分配模型层。输出显示为类似“18%/82% CPU/GPU”的百分比分配。

这对性能有重大影响。 每个令牌生成都需要在CPU和GPU内存之间进行数据传输——这种瓶颈会随着每层卸载到CPU而累积。

从我们的结果中可以明显看出以下模式：

  • 100% GPU模型：61-140个令牌/秒
  • 70-82% GPU模型：19-51个令牌/秒
  • 22% GPU（主要CPU）：12.6个令牌/秒

这解释了为什么在实际应用中，20B参数模型可以比120B模型快11倍。如果您计划提供多个并发请求，了解Ollama如何处理并行请求对于容量规划至关重要。

详细基准测试结果

完全在GPU上运行的模型

GPT-OSS 20B —— 速度冠军

ollama run gpt-oss:20b --verbose
/set parameter num_ctx 19000

NAME           SIZE     PROCESSOR    CONTEXT
gpt-oss:20b    14 GB    100% GPU     19000

eval count:           2856 token(s)
eval duration:        20.410517947s
eval rate:            139.93 tokens/s

在139.93个令牌/秒的速度下，GPT-OSS 20B在对速度要求高的应用中明显胜出。它仅使用14GB显存，为更大的上下文窗口或其他GPU工作负载提供了空间。

Qwen3 14B —— 优秀平衡

ollama run qwen3:14b --verbose
/set parameter num_ctx 19000

NAME         SIZE     PROCESSOR    CONTEXT
qwen3:14b    12 GB    100% GPU     19000

eval count:           3094 token(s)
eval duration:        50.020594575s
eval rate:            61.85 tokens/s

在使用经验中，Qwen3 14B提供了最佳的指令遵循能力，其内存占用为12GB，使用起来非常舒适。在61.85个令牌/秒的速度下，它对于交互式使用来说响应速度足够快。

对于将Qwen3集成到应用中的开发人员，请查看使用Ollama和Qwen3进行LLM结构化输出以提取结构化JSON响应。

Ministral 3 14B —— 快速且紧凑

ollama run ministral-3:14b --verbose
/set parameter num_ctx 19000

NAME               SIZE     PROCESSOR    CONTEXT
ministral-3:14b    13 GB    100% GPU     19000

eval count:           1481 token(s)
eval duration:        21.11734277s
eval rate:            70.13 tokens/s

Mistral的较小模型在完全适合显存的情况下每秒生成70.13个令牌。当需要Mistral家族质量并追求最大速度时，这是一个不错的选择。

需要CPU卸载的模型

Qwen3-VL 30B —— 最佳部分卸载性能

ollama run qwen3-vl:30b-a3b-instruct --verbose
/set parameter num_ctx 19000

NAME                         SIZE     PROCESSOR          CONTEXT
qwen3-vl:30b-a3b-instruct    22 GB    30%/70% CPU/GPU    19000

eval count:           1450 token(s)
eval duration:        28.439319709s
eval rate:            50.99 tokens/s

尽管有30%的层在CPU上，Qwen3-VL仍保持50.99个令牌/秒的速度——比一些100% GPU模型更快。视觉能力为多模态任务增加了多功能性。

Mistral Small 3.2 24B —— 质量与速度的权衡

ollama run mistral-small3.2:24b --verbose
/set parameter num_ctx 19000

NAME                    SIZE     PROCESSOR          CONTEXT
mistral-small3.2:24b    19 GB    18%/82% CPU/GPU    19000

eval count:           831 token(s)
eval duration:        44.899859038s
eval rate:            18.51 tokens/s

Mistral Small 3.2提供了优越的语言质量，但付出了速度的高昂代价。在18.51个令牌/秒的速度下，它在交互式聊天中明显更慢。对于质量比延迟更重要的任务，这是值得的。

GLM 4.7 Flash —— MoE思考模型

ollama run glm-4.7-flash --verbose
/set parameter num_ctx 19000

NAME                 SIZE     PROCESSOR          CONTEXT
glm-4.7-flash        21 GB    27%/73% CPU/GPU    19000

eval count:           2446 token(s)
eval duration:        1m12.239164004s
eval rate:            33.86 tokens/s

GLM 4.7 Flash是一个30B-A3B的专家混合模型——总共有30B个参数，但每个令牌只有3B是活跃的。作为一个“思考”模型，它在生成响应之前会生成内部推理。33.86个令牌/秒包括了思考和输出令牌。尽管有CPU卸载，MoE架构仍使其保持合理的速度。

GPT-OSS 120B —— 强大的模型

ollama run gpt-oss:120b --verbose
/set parameter num_ctx 19000

NAME            SIZE     PROCESSOR          CONTEXT
gpt-oss:120b    66 GB    78%/22% CPU/GPU    19000

eval count:           5008 token(s)
eval duration:        6m36.168233066s
eval rate:            12.64 tokens/s

在16GB显存上运行120B模型在技术上是可能的，但非常痛苦。78%在CPU上，12.64个令牌/秒使交互式使用变得令人沮丧。更适合用于对延迟不敏感的批量处理。

实用建议

用于交互式聊天

使用完全适合显存的模型：

  1. GPT-OSS 20B —— 最大速度（139.93 t/s）
  2. Ministral 3 14B —— Mistral质量的良好速度（70.13 t/s）
  3. Qwen3 14B —— 最佳指令遵循（61.85 t/s）

为了获得更好的聊天体验，请考虑适用于本地Ollama的开源聊天UI。

用于批量处理

当速度不是那么关键时：

  • Mistral Small 3.2 24B —— 优越的语言质量
  • Qwen3-VL 30B —— 视觉+文本能力

用于开发和编码

如果您正在使用Ollama构建应用程序：

替代托管选项

如果Ollama的限制让您担忧（请参阅Ollama劣化担忧），请查看本地LLM托管指南或比较Docker模型运行器与Ollama。

结论

在16GB显存下，如果您选择得当，可以以令人印象的速度运行功能强大的LLM。关键发现如下：

  1. 保持在显存限制内，以便进行交互使用。对于大多数实际用途，20B模型以140个令牌/秒的速度击败120B模型以12个令牌/秒的速度。

  2. GPT-OSS 20B在纯速度上胜出，但Qwen3 14B在指令遵循任务中提供了速度和能力的最佳平衡。

  3. CPU卸载是可行的，但预期会有3-10倍的减速。对于批量处理是可以接受的，但对于聊天来说是令人沮丧的。

  4. 上下文大小很重要。此处使用的19K上下文显著增加了显存使用。为了更好的GPU利用率，请减少上下文大小。

如需结合本地LLM和网络结果的AI驱动搜索，请查看使用Ollama自托管Perplexica。

有用的链接

内部资源

外部参考资料