为什么有些行只有上限，没有估计值？

估计值是用 7–33B 稠密模型的 GGUF 文件在 llama.cpp 上的实测校准的。推荐档位是 AWQ 或 GPTQ（由 vLLM 运行）的行、MoE 模型，以及超出这个体量范围的模型，都没有和真实跑分核对过，所以只给带宽上限 —— 硬印一个猜测值，看起来会和核对过的数字一样可靠，但它并不是。

提示词或对话很长时会变慢吗？

会。这里的数字对应上下文几乎为空时的生成速度，也就是 `tg128` 测的情况。上下文变长后，每个 token 还要多读 KV 缓存，生成会变慢；很长的提示词还会让第一个字出现之前多等一段时间。显存计算器会根据每张卡实测的提示词处理速度，单独给出这个等待时间。

插两张卡会快一倍吗？

默认设置下不会。llama.cpp 和 Ollama 按层把模型拆到几张卡上，每个 token 都要几张卡轮流算一遍，所以速度上限仍是一张卡的水平；第二张卡换来的是容量 —— 能放更大的模型或更长的上下文 —— 而不是速度。vLLM 的张量并行可以提升速度，但需要卡与卡之间有高速互联。

在你的显卡上能跑多快？

最常见几张卡上、能装下的模型每秒能生成多少 token：有实测跑分的卡按它自己的实测缩放出估计值，另给出显存带宽决定的硬上限。

每张卡列出的是本站为它推荐的模型：在聊天、代码、图像三类任务里，能从容装下的最大模型，以及只占约三分之二显存、留出余量的最大模型。每个数字都直接取自显存计算器（4K 上下文、batch 1），每一行都能以相同设置在计算器里打开。

估计 —— 这张卡在 llama.cpp 社区跑分里实测的 Llama 2 7B 生成速度，按模型权重字节数缩放。范围是核对实测数据时真实结果落在的区间。只有 7–33B 的稠密 GGUF 模型给估计值。

上限 —— 显存带宽除以每个 token 要读取的字节数，实际不可能更快。MoE 模型每个 token 只读取激活的专家，所以上限高得多、也更宽松：本站实测过的两个 MoE 模型只达到它的四分之一左右。

RTX 5060 Ti 16G

16 GB · 448 GB/s

模型	量化档位	4K 显存	估计 (tok/s)	上限 (tok/s)
Mistral Small 24B Instruct	AWQ INT4	13.2 GB	—	≤ 39	计算器
Devstral Small 1.1 24B	AWQ INT4	13.0 GB	—	≤ 40	计算器
Magistral Small 1.2 24B	AWQ INT4	13.0 GB	—	≤ 40	计算器
Falcon 3 10B Instruct	Q4_K_M	7.3 GB	~55 (55–72)	≤ 75	计算器
Gemma 4 E4B IT	Q8_0	8.7 GB	~42 (42–56)	≤ 58	计算器

RTX 4060 Ti 8G

8 GB · 288 GB/s

模型	量化档位	4K 显存	估计 (tok/s)	上限 (tok/s)
Falcon 3 10B Instruct	GPTQ INT4	6.1 GB	—	≤ 58	计算器
Qwen3.5 9B	Q4_K_M	6.6 GB	~40 (39–49)	≤ 49	计算器
Qwen3 4B Instruct	Q6_K	4.0 GB	—	≤ 92	计算器
Qwen3.5 2B	Q8_0	2.2 GB	—	≤ 145	计算器

RTX 4060 Ti 16G

16 GB · 288 GB/s

模型	量化档位	4K 显存	估计 (tok/s)	上限 (tok/s)
Mistral Small 24B Instruct	AWQ INT4	13.2 GB	—	≤ 25	计算器
Devstral Small 1.1 24B	AWQ INT4	13.0 GB	—	≤ 26	计算器
Magistral Small 1.2 24B	AWQ INT4	13.0 GB	—	≤ 26	计算器
Falcon 3 10B Instruct	Q4_K_M	7.3 GB	~39 (38–48)	≤ 48	计算器
Gemma 4 E4B IT	Q8_0	8.7 GB	~30 (29–37)	≤ 37	计算器

RTX 5070

12 GB · 672 GB/s

模型	量化档位	4K 显存	估计 (tok/s)	上限 (tok/s)
DeepSeek-V2-Lite Chat	Q4_K_M	10.1 GB	—	≤ 486 · MoE	计算器
Gemma 3 12B IT	Q5_K_M	9.8 GB	~56 (56–74)	≤ 82	计算器
Granite 3.1 8B Instruct	Q4_K_M	5.9 GB	~98 (97–129)	≤ 142	计算器
Gemma 4 E2B IT	Q8_0	5.2 GB	—	≤ 143	计算器

RTX 3090

24 GB · 936 GB/s

模型	量化档位	4K 显存	估计 (tok/s)	上限 (tok/s)
Recursive Flint 40B-A2.5B	Q3_K_M	20.6 GB	—	≤ 804 · MoE	计算器
MiniCPM-V 4.7 35B-A3B	Q4_K_S	20.9 GB	—	≤ 572 · MoE	计算器
ERNIE 4.5 21B-A3B	Q4_K_M	14.2 GB	—	≤ 537 · MoE	计算器
GPT-OSS 20B	MXFP4	12.8 GB	—	≤ 473 · MoE	计算器
Gemma 3 12B IT	Q5_K_M	9.8 GB	~70 (69–91)	≤ 114	计算器

RTX 4090

24 GB · 1008 GB/s

模型	量化档位	4K 显存	估计 (tok/s)	上限 (tok/s)
Recursive Flint 40B-A2.5B	Q3_K_M	20.6 GB	—	≤ 866 · MoE	计算器
MiniCPM-V 4.7 35B-A3B	Q4_K_S	20.9 GB	—	≤ 616 · MoE	计算器
ERNIE 4.5 21B-A3B	Q4_K_M	14.2 GB	—	≤ 578 · MoE	计算器
GPT-OSS 20B	MXFP4	12.8 GB	—	≤ 509 · MoE	计算器
Gemma 3 12B IT	Q5_K_M	9.8 GB	~82 (81–108)	≤ 122	计算器

RTX 5090

32 GB · 1792 GB/s

模型	量化档位	4K 显存	估计 (tok/s)	上限 (tok/s)
Nemotron 3.5 Bolt 74B-A9B	IQ2_XXS	23.1 GB	—	≤ 705 · MoE	计算器
GLM-4.7-Flash	Q4_K_M	19.2 GB	—	≤ 1037 · MoE	计算器
Gemma 3 27B IT	Q4_K_M	18.4 GB	~67 (66–88)	≤ 114	计算器

Radeon RX 9070 XT

16 GB · 640 GB/s

模型	量化档位	4K 显存	估计 (tok/s)	上限 (tok/s)
Mistral Small 24B Instruct	AWQ INT4	13.2 GB	—	≤ 56	计算器
Devstral Small 1.1 24B	AWQ INT4	13.0 GB	—	≤ 57	计算器
Magistral Small 1.2 24B	AWQ INT4	13.0 GB	—	≤ 57	计算器
Falcon 3 10B Instruct	Q4_K_M	7.3 GB	~61 (61–80)	≤ 107	计算器
Gemma 4 E4B IT	Q8_0	8.7 GB	~47 (47–62)	≤ 82	计算器

Mac M4 Pro 24G

24 GB · 273 GB/s

模型	量化档位	4K 显存	估计 (tok/s)	上限 (tok/s)
Qwen3-VL 30B-A3B Instruct	Q3_K_M	15.8 GB	—	≤ 198 · MoE	计算器
North Mini Code 1.0 30B-A3B	Q3_K_M	15.3 GB	—	≤ 205 · MoE	计算器
DeepSeek-V2-Lite Chat	Q4_K_M	10.1 GB	—	≤ 198 · MoE	计算器
Gemma 3 12B IT	Q5_K_M	9.8 GB	~22 (22–29)	≤ 33	计算器

模型	量化档位	4K 显存	估计 (tok/s)	上限 (tok/s)
Nemotron 3.5 Bolt 74B-A9B	IQ2_XXS	23.1 GB	—	无带宽数据	计算器
GLM-4.7-Flash	Q4_K_M	19.2 GB	—	无带宽数据	计算器
Gemma 3 27B IT	Q4_K_M	18.4 GB	—	无带宽数据	计算器

为什么显存带宽决定上限

稠密模型每生成一个 token，都要把全部权重从显存里读一遍。所以每秒 token 数永远不可能超过 `带宽 ÷ 权重字节数`：RTX 4090 每秒约能搬运 1 TB，一个权重占 10 GB 的模型在它上面最多约每秒 100 个 token，算力再强也一样。这也是为什么更小的量化档位不仅更省显存、也更快；以及为什么显存一样但带宽更高的卡，跑同一个模型会更快。MoE（混合专家）模型每个 token 只读取被路由到的专家，所以它的上限按激活参数计算，会高得多。

为什么估计值低于上限

没有哪个运行时能跑满显卡的峰值带宽：计算内核、驱动和每个 token 的固定开销都要占时间，而且每张卡损耗不同。所以估计值从这张卡自己的实测出发 —— 它在 llama.cpp 社区跑分里 Llama 2 7B Q4_0 的 tg128 结果 —— 再按所选模型每个 token 要多读或少读多少字节来缩放。用本站基准表里的稠密 GGUF 实测数据核对，真实速度落在估计值的 0.99 到 1.31 倍之间，这就是估计值旁边印的范围。超出 7–33B 稠密 GGUF 模型的范围，这个核对就不适用，那些行只给上限。

常见问题

为什么有些行只有上限，没有估计值？: 估计值是用 7–33B 稠密模型的 GGUF 文件在 llama.cpp 上的实测校准的。推荐档位是 AWQ 或 GPTQ（由 vLLM 运行）的行、MoE 模型，以及超出这个体量范围的模型，都没有和真实跑分核对过，所以只给带宽上限 —— 硬印一个猜测值，看起来会和核对过的数字一样可靠，但它并不是。
提示词或对话很长时会变慢吗？: 会。这里的数字对应上下文几乎为空时的生成速度，也就是 tg128 测的情况。上下文变长后，每个 token 还要多读 KV 缓存，生成会变慢；很长的提示词还会让第一个字出现之前多等一段时间。显存计算器会根据每张卡实测的提示词处理速度，单独给出这个等待时间。
插两张卡会快一倍吗？: 默认设置下不会。llama.cpp 和 Ollama 按层把模型拆到几张卡上，每个 token 都要几张卡轮流算一遍，所以速度上限仍是一张卡的水平；第二张卡换来的是容量 —— 能放更大的模型或更长的上下文 —— 而不是速度。vLLM 的张量并行可以提升速度，但需要卡与卡之间有高速互联。