估算是如何得出的

本页面由 AI 自动撰写和翻译，并由软件对照来源进行检查，没有人工编辑。规格来自所列来源；显存需求和速度是按已公布的公式计算出的估算值。我们如何使用 AI

本站的每个数字，要么是两个相互独立的开放来源一致认可的规格，要么是下文所述的确定性代码的计算结果。同一套代码既在构建页面时运行，也在您的浏览器中运行。

数值更新于 2026年10月19日

建模范围

建模范围：llama.cpp 加载 GGUF 文件，仅文本，所有层都放在 GPU 上，开启 Flash Attention，微批次大小为 512，单用户。对于多卡：同一台机器中的相同显卡，使用 llama.cpp 默认的层拆分。多模态模型的计算不包括其视觉投影器和图像处理。

Ollama 和 LM Studio 使用 llama.cpp，但默认设置可能不同。vLLM、MLX 和 Transformers 的显存分配方式不同，未纳入建模。“能装下”的结果并不表示某个驱动或后端支持该模型的架构或量化。

公式逐项说明

对每张显卡 d，估算值 Q_d 与 llama.cpp 按设备打印的模型 + KV + RS + 计算缓冲区是同一个量。各层按 llama.cpp 的默认拆分方式分配到各显卡；输入嵌入保留在系统内存中。

Q_d = W_d + KV_d + S_d + C_d
W_d = Σ_{il ∈ d} layer_bytes[il] + [d = N] × out_bytes
KV_d = Σ_{il ∈ d} (k_il + v_il) × b_kv × cells_il;   b_kv: F16 = 2, Q8_0 = 34/32, Q4_0 = 18/32
cells_full = ⌈ctx / 256⌉ × 256
cells_window = ⌈min(ctx, window × n_seq + 512) / 256⌉ × 256
S_d = Σ_{il ∈ d} state_il × 4 B × n_seq
M = (cells_full + cells_window) × 512 × 4 B
L = max(0.25 GiB, n_vocab × 512 × 4 B)
P = M + n_embd × 512 × 4 B
C_d = L + M                        (N = 1)
C_d = L + 3 × P                    (N > 1, d = N)
C_d = 0.25 GiB + 4 × P             (N > 1, d < N)

X = max_d (Q⁺_d ÷ 0.95 + 1 GiB)
能装下：∀ d: Q⁺_d ÷ 0.95 + 1 GiB ≤ C_low
装不下：Q⁻ ÷ 1.10 > C_high (N = 1);   Σ_d Q⁻_d ÷ 1.10 > N × C_high (N > 1)
临界：其他情况
C_low = G − D_card − U;   C_high = G
tok/s ≤ B ÷ (R + R_KV)

W_d: 显卡 d 上的权重：放置在该卡上的各层的字节数（从 GGUF 张量表读取），加上最后一张卡上的输出层。
KV_d: 显卡 d 上的 KV 缓存：该卡上每个注意力层每个 token 的 K 和 V 元素数，乘以每个元素的字节数，再乘以缓存单元数。多头潜在注意力只存储 K。
S_d: 循环状态：循环层和线性注意力层的固定大小状态（32 位），每个并行序列一份。
C_d, L, M, P: 计算缓冲区：L 为 logits 缓冲区，M 为注意力掩码，P 为使用多张显卡时流水线并行在每张卡上保留的每份副本输入。
Q⁺: Q⁺：用于“能装下”的每卡估算值——4 个并行序列（llama-server 的默认值 -np auto），恰好位于显卡边界的层在两张卡上都计入。
Q⁻: Q⁻：用于“装不下”的估算值——1 个序列，每层只计一次，与源代码的分配方式一致。
X: X：每张卡“能装下”所需的可用显存。页面上显示为“能装下所需的可用显存”。
G, N: G：单张显卡的标称显存（厂商标注的“24 GB”按 24 GiB 计算）；N：相同显卡的数量。
C_low: C_low：视为“能装下”可用的显存——标称显存减去该卡标称值与上报值之差（D_card），再减去档案公开日志中最大的启动和运行时占用（U），并向下取整到 64 MiB 的倍数。
C_high: C_high：全部标称显存，用于“装不下”的判断。
B, R, R_KV: B：显存带宽（字节/秒）；R：每生成一个 token 读取的权重字节数（非专家张量加上正在使用的专家所占份额）；R_KV：每个 token 读取的 KV 缓存字节数。

常量

常量	值	含义
`ubatch`	512	llama.cpp 默认的微批大小（-ub）。
`ctxPad`	256	KV 缓存单元会被填充到该数字的整数倍。
`computeFloorBytes`	0.25 GiB	每张卡最小的计算缓冲区。
`maskBytesPerCell`	4 B	注意力掩码（32 位）中每个单元、每个微批 token 所占的字节数。
`fitReservePerDeviceBytes`	1.00 GiB	llama.cpp 默认的 --fit 在每张卡上保留的空闲预留量（-fitt 1024 MiB）。
`underestimateTolerance`	5%	金标准测试允许的最大低估幅度；“能装下”将估算值除以（1 减去该值）。
`overestimateTolerance`	10%	金标准测试允许的最大高估幅度；“装不下”将估算值除以（1 加上该值）。
`stateBytesPerElem`	4 B	循环状态每个元素的字节数。
`defaultCtx`	8,192	表格的默认上下文：此数量的 token；若模型最大上下文更短，则取模型最大值。
`defaultSeqs`	4	“能装下”所假设的并行序列数（llama-server -np auto，统一 KV 缓存）。
`goldCoveredCtx`	262,144	金标准日志所覆盖的单卡最长上下文（单元数）；最长上下文搜索在此停止。
`maxCards`	8	最多考虑的相同显卡数量。
`minUsefulCapacityBytes`	2.00 GiB	在判定结论时，单张显卡上算作可用的最小显存；低于此值时结果为“未知”（“即使 8 张卡也装不下”除外）。
`pipelineCopies`	4	多卡流水线并行时，每张卡上层输入的副本数（GGML_SCHED_MAX_COPIES）。
`goldCoveredCtxMulti`	131,072	金标准日志所覆盖的多卡最长上下文（单元数）。
`cLowStepBytes`	64 MiB	独立 GPU 的 C_low（标称 − D_card − U）向下取整到此值的倍数。

权重不是根据参数量估算的：在固定的修订版本上读取每种量化的 GGUF 文件（文件头和张量表），并将每一层的字节数相加。llama.cpp 保留在系统内存中的张量（输入嵌入）不计入。

能装下、临界还是装不下

“能装下”仅表示：llama.cpp 默认的 --fit 加载检查会把所有层放到 GPU 上。llama.cpp 在加载模型时进行该检查（估算的缓冲区加上每张卡 1 GiB 的预留，不得超过启动时的空闲显存）；本站使用相同的缓冲区规则重新计算，并为估算误差留出余量。这并不保证推理期间的峰值显存（内存池、长提示词和其他运行时分配）也能装下。

金标准测试允许估算值最多偏低 5%、最多偏高 10%，因此判定的每一侧使用各自的界限：

能装下当在每张卡上，Q⁺ ÷ 0.95 + 1 GiB 不超过 C_low 时。Q⁺ 假定 4 个并行序列。
装不下当 Q⁻ ÷ 1.10 大于完整显存 C_high 时（多张卡时：各卡之和与 N × C_high 比较，因为默认的 --fit 会自行调整拆分）。
临界介于两者之间：可能装得下，也可能装不下。请缩短上下文或使用更低的量化。
未知当没有运行档案覆盖该设备、属于工作站和数据中心显卡（其显存配置无法由公开日志确定），或被视为可用的显存低于 2 GiB 时：只显示 X；若模型即使对于完整显存也过大，则另显示“装不下”。

X = 每张卡最大的 Q⁺ ÷ 0.95 + 1 GiB，即“能装下”所需的可用显存。页面将其写作“能装下所需的可用显存”，而不是“至少”，因为临界结果也需要同样多的显存。

表格在默认上下文下从最高量化到最低量化依次检查。每行显示能装下的最高量化（附 X、最长上下文和速度上限）；若都装不下，则显示最高的临界量化（附 X）；若全都太大，则显示最低量化及其 X。

最长上下文在默认上下文与模型最大上下文及实测日志所覆盖的最长上下文（262,144 个单元为单卡，131,072 个为多卡）中较小者之间搜索。如果在该值处仍能装下，页面会显示“≥”该值：更长的上下文未经检查。

只有在单卡装不下时，才会考虑多张相同的显卡；仅适用于有运行档案的桌面级、工作站和数据中心 GPU，并且会对 2 到 8 之间的每个卡数分别检查（增加一张卡并不总能降低负载最重那张卡的负担，而且流水线并行会增加 4 份层输入副本）。页面给出的是在默认均分方式下能装下的最小卡数；这并不是最低值，因为默认的 --fit 可以调整拆分方式，可能用更少的卡也能运行。工作站和数据中心 GPU，以及计为可用的显存不足 2 GiB 的 GPU，只会显示“即使 8 张卡也装不下”（或不显示卡数）。

运行档案

多少显存算作可用，仅来自公开的 llama.cpp 日志：各设备上报的总量、llama.cpp 的 --fit 检查运行时的空闲显存，以及（若有打印）运行后未计入的显存。D_card = 标称值 − 该 GPU 型号上报的总量（有多份日志时取最大值）；U = 在档案的所有有效观测中，--fit 检查时的总量 − 空闲与运行后为正的未计入显存两者中的最大值。当日志中只有设备列表中的读数时，会加上该档案中观察到的最大“列表到检查”差值。若连接了显示器、其他程序已占用 GPU、空闲量超过总量，或共享服务器带来无关占用，则排除这些观测。观测不足的档案不给出结论。

档案	U (MiB)	无自身数据的桌面 GPU 的 D（MiB）	观测数	判定
CUDA（NVIDIA）	2,112	1,054	17	已给出
Vulkan（Intel）	832	0	1	未给出：观测不足
Linux 上的 ROCm（AMD）	1,216	144	11	已给出

没有自身测量数据的消费级 GPU，使用在默认配置下于消费级和工作站显卡上测得的标称值与上报总量之间的最大差值。工作站和数据中心显卡无论有无测量数据，都不判定“能装下”或“临界”，因为公开日志无法显示其显存配置（例如是否开启 ECC）：除非模型即使对于完整显存也过大，否则结果为“未知”；对于多张显卡，只给出“8 张卡也装不下”。笔记本 GPU、Apple Silicon 及其他统一内存电脑在本版本中没有档案。

CUDA（NVIDIA）

llama.cpp，CUDA 后端（NVIDIA 独立 GPU），所有层都放在 GPU 上，开启 Flash Attention，微批次大小（-ub）为 512，F16 KV 缓存，上下文（-c）如表中所示；“能装下”按 llama-server 默认的 4 个并行序列（-np auto，统一 KV 缓存）判定，“装不下”按 1 个序列判定；GPU 空闲，没有其他程序占用其显存。

U = 2,112 MiB；无自身测量的桌面 GPU 的 D = 1,054 MiB。

这些日志中运行后未能归因的显存：236–2,050 MiB（4 次观测）。运行时分配不计入“能装下”；U 仅将其作为额外余量，而不是作为上界。

D_card：标称显存减去 llama.cpp 为该 GPU 型号报告的总量（MiB）。
GPU	D_card (MiB)
NVIDIA GeForce RTX 3060 12GB	251
NVIDIA GeForce RTX 3090	453
NVIDIA GeForce RTX 4060 Ti 16GB	5
NVIDIA GeForce RTX 4090	496
NVIDIA GeForce RTX 5060	484
NVIDIA GeForce RTX 5090	659
NVIDIA L4	2,098
NVIDIA RTX A4000	410
NVIDIA RTX PRO 6000 Blackwell Workstation Edition	1,054

来自公开 llama.cpp 日志的观察结果，并附有引用的日志行。
设备	后端	构建版本	标称值	报告的总量（MiB）	启动时可用（MiB）	加载前已用（MiB）	运行后未计入（MiB）	来源
NVIDIA GeForce RTX 3090 (x2, CUDA0)	CUDA	`b11415`	24 GB	24,575	23,054	1,522	—	llama.cpp issues/29811 日志行 `0.00.573.399 I common_memory_breakdown_print: \| - CUDA0 (RTX 3090) \| 24575 = 23054 + (21234 = 17721 + 2964 + 549) + -19713 \|` `0.00.573.400 I common_memory_breakdown_print: \| - CUDA1 (RTX 3090) \| 24575 = 23206 + (20693 = 18689 + 1453 + 549) + -19323 \|` `0.00.969.460 I common_params_fit_impl: - CUDA0 (NVIDIA GeForce RTX 3090): 24575 total, 21234 used, 1819 free vs. target of 1024`
NVIDIA GeForce RTX 4090	CUDA	`b10567 (d7fa69b7d)`	24 GB	24,563	23,040	1,575	—	llama.cpp issues/27680 日志行 `common_param: - CUDA0 : NVIDIA GeForce RTX 4090 (24563 MiB, 23040 MiB free)` `llama_prepare_model_devices: using device CUDA0 (NVIDIA GeForce RTX 4090) (0000:08:00.0) - 23040 MiB free` `load_tensors: offloaded 44/44 layers to GPU`
NVIDIA GeForce RTX 4090 (x2, CUDA0)	CUDA	`9293 (1acee6bf8)`	24 GB	24,080	23,672	460	—	llama.cpp issues/23679 日志行 `0.00.205.036 I - CUDA0 : NVIDIA GeForce RTX 4090 (24080 MiB, 23672 MiB free)` `0.00.283.679 I - CUDA1 : NVIDIA GeForce RTX 4090 (24080 MiB, 23672 MiB free)` `0.00.691.813 I llama_prepare_model_devices: using device CUDA0 (NVIDIA GeForce RTX 4090) (0000:01:00.0) - 23672 MiB free`
NVIDIA GeForce RTX 3090 (x8)	CUDA	`build 1 (0f7fada) ≈ b9557`	24 GB	24,123	23,858	317	—	llama.cpp issues/24608 日志行 `0.01.258.121 I - CUDA0 : NVIDIA GeForce RTX 3090 (24123 MiB, 23858 MiB free)`
NVIDIA GeForce RTX 3090	CUDA	`9274 (52fb93a)`	24 GB	24,126	23,403	775	—	llama.cpp issues/23472 日志行 `0.00.797.657 I common_memory_breakdown_print: \| - CUDA0 (RTX 3090) \| 24126 = 23403 + (25610 = 15621 +`
NVIDIA GeForce RTX 3060	CUDA	`b7342`	12 GB	12,037	—	270	270	llama.cpp issues/17931 日志行 `llama_memory_breakdown_print: \| - CUDA0 (RTX 3060) \| 12037 = 4510 + ( 7256 = 1224 + 4662 + 1369) + 270 \|`
NVIDIA GeForce RTX 4090	CUDA	`7474 (f9ec8858e)`	24 GB	24,082	23,687	447	—	llama.cpp issues/18181 日志行 `llama_params_fit_impl: - CUDA0 (NVIDIA GeForce RTX 4090) : 24082 total,` `llama_model_load_from_file_impl: using device CUDA0 (NVIDIA GeForce RTX 4090) (0000:82:00.0) - 23687 MiB free`
NVIDIA GeForce RTX 5090	CUDA	`8241 (62b8143ad)`	32 GB	32,606	30,927	2,050	2,050	llama.cpp issues/20308 日志行 `0.18.828.015 I llama_model_load_from_file_impl: using device CUDA0 (NVIDIA GeForce RTX 5090) (0000:08:00.0) - 30927 MiB free` `0.03.911.366 I llama_params_fit_impl: - CUDA0 (NVIDIA GeForce RTX 5090): 32606 total,` `0.22.996.049 I load_tensors: offloaded 61/61 layers to GPU`
NVIDIA GeForce RTX 4090	CUDA	`8241 (62b8143ad)`	24 GB	24,563	22,988	1,910	1,910	llama.cpp issues/20308 日志行 `0.18.828.027 I llama_model_load_from_file_impl: using device CUDA1 (NVIDIA GeForce RTX 4090) (0000:01:00.0) - 22988 MiB free` `0.03.911.366 I llama_params_fit_impl: - CUDA1 (NVIDIA GeForce RTX 4090): 24563 total,`
NVIDIA GeForce RTX 5090	CUDA	`9692 (f3e182816)`	32 GB	32,109	31,585	576	—	llama.cpp issues/24758 日志行 `0.01.070.150 I - CUDA0 : NVIDIA GeForce RTX 5090 (32109 MiB, 31585 MiB free)` `llama_prepare_model_devices: using device CUDA0 (NVIDIA GeForce RTX 5090) (0000:01:00.0) - 31583 MiB free`
NVIDIA GeForce RTX 5060	CUDA	`build 1 (fae3a28)`	8 GB	7,708	7,573	187	—	llama.cpp issues/21984 日志行 `CUDA0: NVIDIA GeForce RTX 5060 (7708 MiB, 7573 MiB free)` `Device 0: NVIDIA GeForce RTX 5060, compute capability 12.0, VMM: yes, VRAM: 7708 MiB` `\| 0 N/A N/A 1448 G /usr/lib/xorg/Xorg 4MiB \|`
NVIDIA GeForce RTX 4060 Ti	CUDA	`0.3.0-dev build 10672 (511f9c1)`	16 GB	16,379	15,233	1,198	—	llama.cpp issues/27892 日志行 `0.00.590.294 I cmn common_param: - CUDA0 : NVIDIA GeForce RTX 4060 Ti (16379 MiB, 15233 MiB free)` `0.01.250.688 I llama_prepare_model_devices: using device CUDA0 (NVIDIA GeForce RTX 4060 Ti) (0000:01:00.0) - 15233 MiB free` `0.01.820.045 I load_tensors: offloaded 35/35 layers to GPU`
NVIDIA GeForce RTX 3080 (20 GB variant)	CUDA	`build 1 (234a6eb) ≈ B10733`	20 GB	20,479	19,271	1,260	—	llama.cpp issues/28167 日志行 `0.00.239.888 I cmn common_param: - CUDA0 : NVIDIA GeForce RTX 3080 (20479 MiB, 19271 MiB free)` `using device CUDA0 (NVIDIA GeForce RTX 3080) (0000:09:00.0) - 19271 MiB free` `0.01.318.328 I load_tensors: offloaded 37/37 layers to GPU`
NVIDIA RTX PRO 6000 Blackwell Workstation Edition	CUDA	`7474 (f9ec8858e)`	96 GB	97,250	96,688	614	—	llama.cpp issues/18181 日志行 `llama_params_fit_impl: - CUDA3 (NVIDIA RTX PRO 6000 Blackwell Workstation Edition): 97250 total,` `llama_model_load_from_file_impl: using device CUDA3 (NVIDIA RTX PRO 6000 Blackwell Workstation Edition)` `(0000:01:00.0) - 96688 MiB free`
NVIDIA RTX A4000	CUDA	`9890 (74976e1)`	16 GB	15,974	15,791	235	—	llama.cpp issues/25594 日志行 `0.00.322.214 I cmn common_param: - CUDA0 : NVIDIA RTX A4000 (15974 MiB, 15791 MiB free)` `0.01.255.214 I llama_prepare_model_devices: using device CUDA0 (NVIDIA RTX A4000) (0000:02:00.0) - 15791 MiB free`
NVIDIA A100-SXM4-40GB	CUDA	`8387 (45172df)`	40 GB	40,444	39,968	528	—	llama.cpp issues/20761 日志行 `ggml_cuda_init: found 1 CUDA devices (Total VRAM: 40444 MiB):` `Device 0: NVIDIA A100-SXM4-40GB, compute capability 8.0, VMM: yes, VRAM: 40444 MiB` `llama_model_load_from_file_impl: using device CUDA0 (NVIDIA A100-SXM4-40GB) (0000:41:00.0) - 39968 MiB free`
NVIDIA L4	CUDA	`b9036-b863d41c7`	24 GB	22,478	22,286	244	236	llama.cpp pull/22546 日志行 `Device 0: NVIDIA L4, compute capability 8.9, VMM: yes, VRAM: 22478 MiB` `llama_prepare_model_devices: using device CUDA0 (NVIDIA L4) (0000:00:03.0) - 22286 MiB free` `common_memory_breakdown_print: \| - CUDA0 (L4) \| 22478 = 22234 + (17095 = 8045 + 8242 + 808) + -16851 \|`

Vulkan（Intel）

llama.cpp，Vulkan 后端（Intel 独立 GPU），所有层都放在 GPU 上，开启 Flash Attention，微批次大小（-ub）为 512，F16 KV 缓存，上下文（-c）如表中所示；“能装下”按 4 个并行序列判定，“装不下”按 1 个序列判定；GPU 空闲。目前公开的实测数据不足，因此没有任何结论使用此运行档案。

U = 832 MiB；无自身测量的桌面 GPU 的 D = 0 MiB。

D_card：标称显存减去 llama.cpp 为该 GPU 型号报告的总量（MiB）。
GPU	D_card (MiB)
Intel Arc Pro B70	138

来自公开 llama.cpp 日志的观察结果，并附有引用的日志行。
设备	后端	构建版本	标称值	报告的总量（MiB）	启动时可用（MiB）	加载前已用（MiB）	运行后未计入（MiB）	来源
Intel Arc Pro B70	Vulkan	`build_info: b8871-7fc1c4ef7`	32 GB	32,630	31,861	769	—	llama.cpp issues/22275 日志行 `0.01.712.235 I llama_model_load_from_file_impl: using device Vulkan0 (Intel(R) Arc(TM) Pro B70 Graphics) (unknown id)` `- 31861 MiB free` `0.10.080.962 I load_tensors: offloaded 31/31 layers to GPU`

Linux 上的 ROCm（AMD）

llama.cpp，Linux 上的 ROCm 后端（AMD 独立 GPU），所有层都放在 GPU 上，开启 Flash Attention，微批次大小（-ub）为 512，F16 KV 缓存，上下文（-c）如表中所示；“能装下”按 llama-server 默认的 4 个并行序列（-np auto，统一 KV 缓存）判定，“装不下”按 1 个序列判定；GPU 空闲，没有其他程序占用其显存。

U = 1,216 MiB；无自身测量的桌面 GPU 的 D = 144 MiB。

该日志中运行后未能归因的显存：279 MiB（1 次观测）。运行时分配不计入“能装下”；U 仅将其作为额外余量，而不是作为上界。

D_card：标称显存减去 llama.cpp 为该 GPU 型号报告的总量（MiB）。
GPU	D_card (MiB)
AMD Radeon Instinct MI50 (32GB)	16
AMD Radeon AI PRO R9700	144
AMD Radeon RX 6800	16
AMD Radeon RX 6900 XT	16
AMD Radeon RX 7800 XT	16
AMD Radeon RX 7900 XTX	16

来自公开 llama.cpp 日志的观察结果，并附有引用的日志行。
设备	后端	构建版本	标称值	报告的总量（MiB）	启动时可用（MiB）	加载前已用（MiB）	运行后未计入（MiB）	来源
AMD Radeon RX 7900 XTX	ROCm	`version: 9744 (063d9c1)`	24 GB	24,560	24,494	266	—	llama.cpp issues/24858 日志行 `[44157] 0.00.063.214 I - ROCm0 : Radeon RX 7900 XTX (24560 MiB, 24494 MiB free)` `[44157] 0.00.668.217 I llama_prepare_model_devices: using device ROCm0 (Radeon RX 7900 XTX) (0000:0a:00.0) - 24346 MiB free` `[44157] 0.02.978.818 I load_tensors: offloaded 33/33 layers to GPU`
AMD Radeon RX 7800 XT (x2, ROCm0)	ROCm	`version: b8929-9d34231bb`	16 GB	16,368	16,036	467	—	llama.cpp issues/22351 日志行 `Device 0: AMD Radeon RX 7800 XT, gfx1101 (0x1101), VMM: no, Wave Size: 32, VRAM: 16368 MiB` `llama_model_load_from_file_impl: using device ROCm0 (AMD Radeon RX 7800 XT) (0000:01:00.0) - 16036 MiB free` `common_params_fit_impl: - ROCm0 (AMD Radeon RX 7800 XT): 16368 total, 10610 used, 5291 free vs. target of 1024`
AMD Radeon RX 7900 XTX	ROCm	`version: 9307 (549b9d8)`	24 GB	24,560	24,510	1,135	—	llama.cpp issues/23934 日志行 `0.00.042.225 I - ROCm0 : AMD Radeon RX 7900 XTX (24560 MiB, 24510 MiB free)` `OS: Ubuntu 22.04.5 LTS` `Kernel: 6.8.0-117-generic`
AMD Radeon RX 7900 XTX (x4)	ROCm	`unknown`	24 GB	24,560	24,510	1,135	—	llama.cpp issues/27021 日志行 `- ROCm0 : Radeon RX 7900 XTX (24560 MiB, 24510 MiB free)` `- ROCm1 : Radeon RX 7900 XTX (24560 MiB, 24518 MiB free)` `- ROCm2 : Radeon RX 7900 XTX (24560 MiB, 24518 MiB free)`
AMD Radeon AI PRO R9700 (x8)	ROCm	`build 43 (5854625)`	32 GB	32,624	32,534	1,175	—	llama.cpp issues/26208 日志行 `0.00.089.438 I cmn common_param: - ROCm0 : AMD Radeon AI PRO R9700 (32624 MiB, 32534 MiB free)` `0.08.861.240 I load_tensors: offloaded 66/66 layers to GPU` `Host is a Debian 13 install with backports set to priority 500.`
AMD Radeon AI PRO R9700	ROCm	`build 10616 (45bfc6f91)`	32 GB	32,624	32,538	1,171	—	llama.cpp issues/26208 日志行 `[44399] 0.00.093.902 I cmn common_param: - ROCm0 : AMD Radeon Graphics (32624 MiB, 32538 MiB free)` `[44399] 0.00.093.904 I cmn common_param: - ROCm1 : AMD Radeon Graphics (32624 MiB, 32558 MiB free)` `[44399] 0.00.562.846 I common_memory_breakdown_print: \| - ROCm0 (Graphics) \| 32624 = 31454 + (18994 = 7216 + 9095 + 2682) + -17824 \|`
AMD Instinct MI50 32GB	ROCm	`build 9943 (c15c5c77a)`	32 GB	32,752	32,722	1,115	—	llama.cpp issues/25487 日志行 `0.00.046.167 I cmn common_param: - ROCm0 : AMD Instinct MI60 / MI50 (32752 MiB, 32722 MiB free)` `llama_prepare_model_devices: using device ROCm0 (AMD Instinct MI60 / MI50) (0000:43:00.0) - 32570 MiB free` `0.13.494.533 I load_tensors: offloaded 49/52 layers to GPU`
AMD Radeon RX 6800	ROCm	`version: 746 (da296d6)`	16 GB	16,368	—	660	—	llama.cpp issues/26038 日志行 `\| - ROCm0 (RX 6800) \| 16368 = 15708 + (13826 = 13244 + 544 + 37) + -13166 \|` `\| - ROCm0 (RX 6800) \| 16368 = 16010 + (13527 = 13244 + 245 + 37) + -13169 \|` `GPU: AMD Radeon RX 6800`
AMD Radeon Pro VII (x3)	ROCm	`build: aa374175c (6969)`	16 GB	16,368	—	279	279	llama.cpp issues/17058 日志行 `llama_memory_breakdown_print: \| memory breakdown [MiB] \| total free self model context compute unaccounted \|` `llama_memory_breakdown_print: \| - ROCm0 ((TM) Pro VII) \| 16368 = 10268 + (5820 = 5613 + 56 + 150) + 279 \|` `llama_memory_breakdown_print: \| - ROCm1 ((TM) Pro VII) \| 16368 = 10250 + (5852 = 5336 + 54 + 461) + 265 \|`
AMD Radeon RX 6900 XT	ROCm	`version: 9890 (74976e1)`	16 GB	16,368	16,342	1,111	—	llama.cpp issues/25594 日志行 `0.00.322.247 I cmn common_param: - ROCm0 : AMD Radeon RX 6900 XT (16368 MiB, 16342 MiB free)` `0.01.255.231 I llama_prepare_model_devices: using device ROCm0 (AMD Radeon RX 6900 XT) (0000:03:00.0) - 16342 MiB free` `0.01.790.609 I load_tensors: offloaded 66/66 layers to GPU`
AMD Radeon RX 7900 XTX	ROCm	`version: 8707 (3bd9aa1)`	24 GB	24,560	24,376	219	—	llama.cpp issues/22052 日志行 `Device 0: AMD Radeon RX 7900 XTX, gfx1100 (0x1100), VMM: no, Wave Size: 32, VRAM: 24560 MiB` `llama_model_load_from_file_impl: using device ROCm0 (AMD Radeon RX 7900 XTX) (0000:c4:00.0) - 24376 MiB free` `llama_params_fit_impl: - ROCm0 (AMD Radeon RX 7900 XTX): 24560 total, 9473 used, 14868 free vs. target of 1024`

金标准测试

每个案例都是一份公开的 llama.cpp 日志，其中会打印各设备的缓冲区。读取该日志对应的 GGUF 文件，按日志自身的上下文、序列数、微批次大小和 KV 类型，为每张显卡重新计算缓冲区，并与同一张显卡的模型 + KV + RS + 计算缓冲区之和进行比较。38 个案例（50 张显卡）在每次构建时作为自动化测试运行，误差必须保持在 −5% 到 +10% 之间；最大误差为 +8.85%。

案例	GGUF	后端	显卡	设备	上下文	序列数	KV	实测值	本站估算	误差
E01	unsloth/GLM-4.7-Flash-GGUF	Metal	1	MTL0	65,536	4	F16	34,053.1 MiB	34,173.1 MiB	+0.35%
E02	unsloth/GLM-4.7-Flash-GGUF	CUDA	1	CUDA0	380,416	2	F16	76,784.3 MiB	77,208.0 MiB	+0.55%
E03	bartowski/gemma-2-2b-it-GGUF	CUDA	1	CUDA0	4,096	1	F16	3,570.3 MiB	3,581.7 MiB	+0.32%
E05	ggml-org/gemma-3-4b-it-qat-GGUF	Vulkan	1	Vulkan0	131,072	4	F16	6,001.9 MiB	6,261.9 MiB	+4.33%
E06	unsloth/gemma-3-27b-it-GGUF	CUDA	1	CUDA0	8,192	1	Q8_0	14,257.9 MiB	14,266.4 MiB	+0.06%
E07	unsloth/gemma-4-26B-A4B-it-GGUF	ROCm	1	ROCm0	262,144	4	F16	54,994.9 MiB	55,203.4 MiB	+0.38%
E08	bartowski/google_gemma-4-E2B-it-GGUF	Vulkan	1	Vulkan0	12,032	4	F16	2,065.2 MiB	2,090.7 MiB	+1.23%
E10	lmstudio-community/gpt-oss-20b-GGUF	Metal	1	Metal	4,096	1	F16	12,048.6 MiB	12,052.4 MiB	+0.03%
E11	unsloth/gpt-oss-120b-GGUF	Vulkan	1	Vulkan0	131,072	1	F16	65,418.0 MiB	65,654.7 MiB	+0.36%
E12	unsloth/gpt-oss-120b-GGUF	ROCm	3	ROCm0	131,072	1	F16	24,085.8 MiB	24,118.2 MiB	+0.13%
E12	unsloth/gpt-oss-120b-GGUF	ROCm	3	ROCm1	131,072	1	F16	21,826.8 MiB	22,488.5 MiB	+3.03%
E12	unsloth/gpt-oss-120b-GGUF	ROCm	3	ROCm2	131,072	1	F16	21,101.6 MiB	21,325.3 MiB	+1.06%
E13	lmstudio-community/gpt-oss-120b-GGUF	ROCm	3	ROCm0	50,176	4	F16	22,570.5 MiB	22,681.7 MiB	+0.49%
E13	lmstudio-community/gpt-oss-120b-GGUF	ROCm	3	ROCm1	50,176	4	F16	20,664.3 MiB	21,033.4 MiB	+1.79%
E13	lmstudio-community/gpt-oss-120b-GGUF	ROCm	3	ROCm2	50,176	4	F16	19,914.5 MiB	20,003.2 MiB	+0.45%
E15	bartowski/nvidia_Nemotron-H-47B-Reasoning-128K-GGUF	Vulkan	1	Vulkan0	32,768	1	F16	27,959.0 MiB	27,988.9 MiB	+0.11%
E17	LiquidAI/LFM2.5-1.2B-Instruct-GGUF	CUDA	1	CUDA0	128,000	4	Q8_0	2,370.8 MiB	2,489.7 MiB	+5.02%
E18	unsloth/Qwen3.5-27B-GGUF	CUDA	1	CUDA0	10,240	1	F16	17,406.9 MiB	17,406.9 MiB	+0.00%
E19	unsloth/Qwen3.5-35B-A3B-GGUF	Vulkan	1	Vulkan0	16,384	1	F16	21,566.6 MiB	21,585.6 MiB	+0.09%
E20	unsloth/Qwen3.5-9B-GGUF	CUDA	1	CUDA0	256,000	4	Q8_0	20,381.1 MiB	20,576.0 MiB	+0.96%
E23	unsloth/Qwen3-Coder-30B-A3B-Instruct-GGUF	CUDA	2	CUDA0	131,072	1	Q8_0	21,254.9 MiB	21,294.9 MiB	+0.19%
E23	unsloth/Qwen3-Coder-30B-A3B-Instruct-GGUF	CUDA	2	CUDA1	131,072	1	Q8_0	4,032.3 MiB	4,280.2 MiB	+6.15%
E24	bartowski/Mistral-Large-Instruct-2411-GGUF	CUDA	4	CUDA0	32,768	1	F16	32,775.5 MiB	32,783.4 MiB	+0.02%
E24	bartowski/Mistral-Large-Instruct-2411-GGUF	CUDA	4	CUDA1	32,768	1	F16	15,712.7 MiB	15,856.7 MiB	+0.92%
E24	bartowski/Mistral-Large-Instruct-2411-GGUF	CUDA	4	CUDA2	32,768	1	F16	18,503.9 MiB	18,647.9 MiB	+0.78%
E24	bartowski/Mistral-Large-Instruct-2411-GGUF	CUDA	4	CUDA3	32,768	1	F16	15,874.9 MiB	15,930.9 MiB	+0.35%
E25	unsloth/Qwen3.5-27B-GGUF	CUDA	2	CUDA0	10,240	4	F16	13,661.2 MiB	13,738.2 MiB	+0.56%
E25	unsloth/Qwen3.5-27B-GGUF	CUDA	2	CUDA1	10,240	4	F16	14,767.9 MiB	14,423.6 MiB	-2.33%
E26	unsloth/Qwen3.5-27B-GGUF	Vulkan	2	Vulkan0	16,128	4	F16	6,805.8 MiB	6,908.0 MiB	+1.50%
E26	unsloth/Qwen3.5-27B-GGUF	Vulkan	2	Vulkan1	16,128	4	F16	11,830.8 MiB	11,842.3 MiB	+0.10%
E27	lmstudio-community/Qwen3-32B-GGUF	CUDA	1	CUDA0	32,768	1	Q4_0	21,034.4 MiB	21,088.4 MiB	+0.26%
E28	bartowski/Meta-Llama-3.1-8B-Instruct-GGUF	CUDA	1	CUDA0	132,096	4	F16	45,560.0 MiB	45,655.0 MiB	+0.21%
E29	lmstudio-community/granite-4.0-micro-GGUF	CUDA	1	CUDA0	2,050	1	F16	2,381.0 MiB	2,439.3 MiB	+2.45%
E30	unsloth/Llama-3.2-3B-Instruct-GGUF	CUDA	1	CUDA0	74,000	1	F16	10,294.9 MiB	10,439.4 MiB	+1.40%
E31	mradermacher/Sugoi-14B-Ultra-HF-i1-GGUF	CUDA	1	CUDA0	512	1	F16	6,674.4 MiB	6,665.4 MiB	-0.13%
E33	unsloth/Qwen3-30B-A3B-Instruct-2507-GGUF	ROCm	1	ROCm0	4,096	20	F16	34,286.3 MiB	34,717.0 MiB	+1.26%
E35	mradermacher/Strawberrylemonade-70B-v1.2-i1-GGUF	ROCm	2	ROCm0	32,768	2	F16	23,499.4 MiB	23,651.3 MiB	+0.65%
E35	mradermacher/Strawberrylemonade-70B-v1.2-i1-GGUF	ROCm	2	ROCm1	32,768	2	F16	23,230.2 MiB	23,267.7 MiB	+0.16%
E37	Qwen/Qwen3-VL-30B-A3B-Instruct-GGUF	ROCm	1	ROCm0	20,224	4	F16	19,721.2 MiB	19,756.7 MiB	+0.18%
E38	unsloth/Llama-3.2-3B-Instruct-GGUF	ROCm	1	ROCm0	10,240	4	F16	3,300.9 MiB	3,314.4 MiB	+0.41%
E39	unsloth/Qwen3-30B-A3B-Instruct-2507-GGUF	Vulkan	1	Vulkan0	100,864	4	Q8_0	22,043.4 MiB	22,215.6 MiB	+0.78%
E40	bartowski/Meta-Llama-3.1-8B-Instruct-GGUF	Vulkan	1	Vulkan0	8,448	1	F16	5,718.0 MiB	5,732.0 MiB	+0.24%
E41	unsloth/GLM-4.5-Air-GGUF	Vulkan	1	Vulkan0	24,576	4	Q8_0	46,141.9 MiB	46,179.1 MiB	+0.08%
E43	unsloth/Qwen3-VL-8B-Thinking-GGUF	Vulkan	2	Vulkan0	24,576	4	Q8_0	4,416.4 MiB	4,560.3 MiB	+3.26%
E43	unsloth/Qwen3-VL-8B-Thinking-GGUF	Vulkan	2	Vulkan1	24,576	4	Q8_0	2,734.4 MiB	2,766.3 MiB	+1.17%
E44	ggml-org/Qwen2.5-Coder-1.5B-Instruct-Q8_0-GGUF	Vulkan	1	Vulkan0	4,096	1	F16	1,976.4 MiB	1,981.4 MiB	+0.25%
E45	unsloth/Qwen3-30B-A3B-GGUF	Metal	1	Metal	4,096	1	F16	9,307.4 MiB	9,307.4 MiB	-0.00%
E46	bartowski/mistralai_Voxtral-Mini-3B-2507-GGUF	Metal	1	MTL0	16,384	4	F16	6,256.0 MiB	6,276.0 MiB	+0.32%
E47	unsloth/Qwen3-0.6B-GGUF	Metal	1	Metal	34,304	4	F16	4,425.4 MiB	4,488.4 MiB	+1.42%
E48	sweepai/sweep-next-edit-1.5B	Metal	1	Metal	32,768	4	F16	2,462.6 MiB	2,680.6 MiB	+8.85%

被排除的日志及原因

E04：Flash Attention 处于关闭状态；本站按 Flash Attention 开启来建模。
E09：使用了 --swa-full 运行，这是一种非默认的滑动窗口缓存。
E16：多个序列但没有统一 KV 缓存；这种缓存布局未建模。
E32：Flash Attention 处于关闭状态；本站按 Flash Attention 开启来建模。
E34：Flash Attention 处于关闭状态；本站按 Flash Attention 开启来建模。
E42：Flash Attention 处于关闭状态；本站按 Flash Attention 开启来建模。

按架构划分的 llama.cpp 规则

各架构如何布局其 KV 缓存和状态，转录自 llama.cpp 源代码，提交为 5aeac37a35。

架构	KV 缓存布局	来源
`llama`	每一层都使用全注意力	src/models/llama.cpp
`qwen2`	每一层都使用全注意力	src/models/qwen2.cpp
`qwen2moe`	每一层都使用全注意力	src/models/qwen2moe.cpp
`qwen2vl`	每一层都使用全注意力	src/models/qwen2vl.cpp
`qwen3`	每一层都使用全注意力	src/models/qwen3.cpp
`qwen3moe`	每一层都使用全注意力	src/models/qwen3moe.cpp
`qwen3vl`	每一层都使用全注意力	src/models/qwen3vl.cpp
`qwen3vlmoe`	每一层都使用全注意力	src/models/qwen3vlmoe.cpp
`mistral3`	每一层都使用全注意力	src/models/mistral3.cpp
`mistral4`	每一层都使用全注意力	src/models/mistral4.cpp
`phi2`	每一层都使用全注意力	src/models/phi2.cpp
`phi3`	每一层都使用全注意力	src/models/phi3.cpp
`phimoe`	每一层都使用全注意力	src/models/phimoe.cpp
`gemma`	每一层都使用全注意力	src/models/gemma.cpp
`glm4`	每一层都使用全注意力	src/models/glm4.cpp
`glm4moe`	每一层都使用全注意力	src/models/glm4-moe.cpp
`granite`	每一层都使用全注意力	src/models/granite.cpp
`granitemoe`	每一层都使用全注意力	src/models/granite-moe.cpp
`command-r`	每一层都使用全注意力	src/models/command-r.cpp
`olmo`	每一层都使用全注意力	src/models/olmo.cpp
`olmoe`	每一层都使用全注意力	src/models/olmoe.cpp
`starcoder2`	每一层都使用全注意力	src/models/starcoder2.cpp
`internlm2`	每一层都使用全注意力	src/models/internlm2.cpp
`minimax-m2`	每一层都使用全注意力	src/models/minimax-m2.cpp
`hunyuan-moe`	每一层都使用全注意力	src/models/hunyuan-moe.cpp
`hunyuan-dense`	每一层都使用全注意力	src/models/hunyuan-dense.cpp
`hy_v3`	每一层都使用全注意力	src/models/hy-v3.cpp
`ernie4_5`	每一层都使用全注意力	src/models/ernie4-5.cpp
`ernie4_5-moe`	每一层都使用全注意力	src/models/ernie4-5-moe.cpp
`seed_oss`	每一层都使用全注意力	src/models/seed-oss.cpp
`smollm3`	每一层都使用全注意力	src/models/smollm3.cpp
`apertus`	每一层都使用全注意力	src/models/apertus.cpp
`exaone`	每一层都使用全注意力	src/models/exaone.cpp
`nemotron`	每一层都使用全注意力	src/models/nemotron.cpp
`bailingmoe`	每一层都使用全注意力	src/models/bailingmoe.cpp
`bailingmoe2`	每一层都使用全注意力	src/models/bailingmoe2.cpp
`dots1`	每一层都使用全注意力	src/models/dots1.cpp
`arcee`	每一层都使用全注意力	src/models/arcee.cpp
`grovemoe`	每一层都使用全注意力	src/models/grovemoe.cpp
`nanbeige`	每一层都使用全注意力	src/models/nanbeige.cpp
`k2-horizon`	每一层都使用全注意力	src/models/k2-horizon.cpp
`deci`	缓存布局尚未建模——采用此架构的模型不会列出	src/models/deci.cpp
`deepseek2`	每一层都使用全注意力	src/models/deepseek2.cpp
`deepseek`	每一层都使用全注意力	src/models/deepseek.cpp
`minicpm3`	每一层都使用全注意力	src/models/minicpm3.cpp
`deepseek32`	带索引器键的稀疏注意力（计入额外的 K）	src/models/deepseek32.cpp
`glm-dsa`	带索引器键的稀疏注意力（计入额外的 K）	src/models/glm-dsa.cpp
`gemma2`	滑动窗口：每个全注意力层对应 1 个滑动窗口层，除非 GGUF 文件给出了逐层模式	src/models/gemma2.cpp
`gemma3`	滑动窗口：每个全注意力层对应 5 个滑动窗口层，除非 GGUF 文件给出了逐层模式	src/models/gemma3.cpp
`gemma3n`	滑动窗口：每个全注意力层对应 4 个滑动窗口层，除非 GGUF 文件给出了逐层模式；缓存布局尚未建模——采用此架构的模型不会列出	src/models/gemma3n.cpp
`gemma4`	滑动窗口，逐层模式从 GGUF 文件中读取	src/models/gemma4.cpp
`cohere2`	滑动窗口：每个全注意力层对应 3 个滑动窗口层，除非 GGUF 文件给出了逐层模式	src/models/cohere2.cpp
`cohere2moe`	滑动窗口：每个全注意力层对应 3 个滑动窗口层，除非 GGUF 文件给出了逐层模式	src/models/cohere2moe.cpp
`gpt-oss`	滑动窗口：每个全注意力层对应 1 个滑动窗口层，除非 GGUF 文件给出了逐层模式	src/models/openai-moe.cpp
`exaone4`	滑动窗口：每个全注意力层对应 3 个滑动窗口层，除非 GGUF 文件给出了逐层模式	src/models/exaone4.cpp
`exaone-moe`	滑动窗口：每个全注意力层对应 3 个滑动窗口层，除非 GGUF 文件给出了逐层模式	src/models/exaone-moe.cpp
`afmoe`	滑动窗口：每个全注意力层对应 3 个滑动窗口层，除非 GGUF 文件给出了逐层模式	src/models/afmoe.cpp
`llama4`	分块注意力：每个全注意力层对应 3 个分块注意力层	src/models/llama4.cpp
`muse-glimmer`	滑动窗口：每个全注意力层对应 3 个滑动窗口层，除非 GGUF 文件给出了逐层模式	src/models/muse-glimmer.cpp
`muse-spark`	滑动窗口，逐层模式从 GGUF 文件中读取	src/models/muse-spark.cpp
`mellum`	滑动窗口：每个全注意力层对应 3 个滑动窗口层，除非 GGUF 文件给出了逐层模式	src/models/mellum.cpp
`smallthinker`	滑动窗口：每个全注意力层对应 3 个滑动窗口层，除非 GGUF 文件给出了逐层模式	src/models/smallthinker.cpp
`laguna`	滑动窗口：每个全注意力层对应 3 个滑动窗口层，除非 GGUF 文件给出了逐层模式	src/models/laguna.cpp
`granite_swa`	滑动窗口，逐层模式从 GGUF 文件中读取	src/models/granite-swa.cpp
`maple`	滑动窗口，逐层模式从 GGUF 文件中读取	src/models/maple.cpp
`spark2_5`	滑动窗口，逐层模式从 GGUF 文件中读取	src/models/spark2-5.cpp
`step35`	滑动窗口，逐层模式从 GGUF 文件中读取	src/models/step35.cpp
`mimo2`	滑动窗口，逐层模式从 GGUF 文件中读取	src/models/mimo2.cpp
`kolibri1`	滑动窗口，逐层模式从 GGUF 文件中读取	src/models/kolibri1.cpp
`beam`	滑动窗口，逐层模式从 GGUF 文件中读取	src/models/beam.cpp
`maion-coder`	滑动窗口，逐层模式从 GGUF 文件中读取	src/models/maion-coder.cpp
`olmo2`	滑动窗口：每个全注意力层对应 3 个滑动窗口层，除非 GGUF 文件给出了逐层模式	src/models/olmo2.cpp
`plamo3`	缓存布局尚未建模——采用此架构的模型不会列出	src/models/plamo3.cpp
`qwen3next`	具有固定大小状态的循环/线性注意力层	src/models/qwen3next.cpp
`qwen35`	具有固定大小状态的循环/线性注意力层	src/models/qwen35.cpp
`qwen35moe`	具有固定大小状态的循环/线性注意力层	src/models/qwen35moe.cpp
`qwen4exp`	具有固定大小状态的循环/线性注意力层；缓存布局尚未建模——采用此架构的模型不会列出	src/models/qwen4exp.cpp
`nemotron_h`	具有固定大小状态的循环/线性注意力层	src/models/nemotron-h.cpp
`nemotron_h_moe`	具有固定大小状态的循环/线性注意力层	src/models/nemotron-h.cpp
`granitehybrid`	具有固定大小状态的循环/线性注意力层	src/models/granite-hybrid.cpp
`jamba`	具有固定大小状态的循环/线性注意力层	src/models/jamba.cpp
`lfm2`	具有固定大小状态的循环/线性注意力层	src/models/lfm2.cpp
`lfm2moe`	具有固定大小状态的循环/线性注意力层	src/models/lfm2moe.cpp
`falcon-h1`	缓存布局尚未建模——采用此架构的模型不会列出	src/models/falcon-h1.cpp
`kimi-linear`	具有固定大小状态的循环/线性注意力层	src/models/kimi-linear.cpp
`kimi-k3`	具有固定大小状态的循环/线性注意力层	src/models/kimi-k3.cpp
`glm5-next`	具有固定大小状态的循环/线性注意力层；带索引器键的稀疏注意力（计入额外的 K）	src/models/glm5-next.cpp
`minimax-01`	缓存布局尚未建模——采用此架构的模型不会列出	src/models/minimax-01.cpp
`plamo2`	缓存布局尚未建模——采用此架构的模型不会列出	src/models/plamo2.cpp
`deepseek4`	缓存布局尚未建模——采用此架构的模型不会列出	src/models/deepseek4.cpp
`dots3note`	缓存布局尚未建模——采用此架构的模型不会列出	src/models/dots3note.cpp
`hy_v4`	缓存布局尚未建模——采用此架构的模型不会列出	src/models/hy-v4.cpp
`minimax-m3`	缓存布局尚未建模——采用此架构的模型不会列出	src/models/minimax-m3.cpp

来源及规格的核对方式

本站从不抓取厂商网站，因为其条款禁止自动访问。厂商规格来自逐行链接厂商数据表的开放数据集（GetDeploying 和 Epoch AI，前提是数据表位于厂商域名，或位于厂商自己用于存放数据表的文档托管站点），以及 AMD 的 ROCm 文档。这些数据表链接显示为“厂商出处”，并标明本站未抓取。数据表链接位于以下域名之一（包括厂商使用的文档托管站点）时，视为厂商出处： amd.com, apple.com, dam-cdn.nvd.orangelogic.com, geforce.com, intel.com, nvdam.widen.net, nvidia.com
Wikipedia 用作独立的交叉核对。其脚注不作为数值的来源，因为表格列和产品名称的脚注无法说明某个具体字段来自哪里。
厂商规格的一票与交叉核对的一票必须来自彼此没有引用关系的不同发布者：如果进行交叉核对的 Wikipedia 页面（或数据集行）引用了另一个发布者，则视为衍生，不算作第二票。若某个来源未说明就抄自另一来源，无法通过公开证据发现。
当厂商规格的一票与独立的交叉核对一致，且没有正常来源与之不一致时，显示该值（two_source）。否则为“conflict”（来源不一致）、“single”（没有厂商规格的票或没有独立的交叉核对）或“missing”。
开放数据集中归于 TechPowerUp 的数据行（数据表链接指向 techpowerup.com 的 Epoch AI 数据行）完全不会被读取，因为 TechPowerUp 的条款禁止衍生数据集：这些行既不参与表决，也不算作分歧。
一致的含义：显存容量完全相等，带宽相差不超过 1%，其他数值相差不超过 2%，文本在规范化后相同。
显示的值是被最多来源精确给出的那个数值；每个来源各自给出的数值和链接都列在该值旁边。Wikipedia 链接指向所使用的确切修订版本。
本版本不发布 Apple silicon、DGX Spark 和 Strix Halo 计算机：没有开放来源逐行链接它们的厂商数据手册。
模型数据来自固定修订版本的 Hugging Face。每个模型的所有量化都使用同一个 GGUF 仓库，按固定的发布者顺序选择；架构从 GGUF 头部读取，并在可读取原始 config.json 时与其交叉核对。
原始权重仅供参考，统计仓库顶层和 model* 文件夹中的 safetensors 文件：若有 model.safetensors.index.json，则统计其中列出的文件，以及其他 model* 文件夹中的完整文件集；若没有，则统计每一个完整文件集，其中合并文件与内容相同的分片副本只计一次。其他文件夹（例如单独存放的解码器）、original/、consolidated* 文件、LoRA 适配器以及 .bin / .pt 文件均不计入。当这些文件无法构成唯一明确的文件集时，不给出大小。

参数量

参数量根据所选 GGUF 文件的 GGUF 张量表统计：包括 llama.cpp 加载的每一个张量，也包括输入嵌入表。多 token 预测（MTP / NextN）层默认不会被 llama.cpp 加载，因此不计入；含有这些层的模型页面会说明其数量。每个 token 的激活参数统计非专家张量加上正在使用的专家（使用的专家数 ÷ 每层专家数），但不含输入嵌入查表，因为每个 token 只读取其中一行。当模型把同一个矩阵同时用作输入嵌入和输出层（共享嵌入）时，每个 token 都要与整个矩阵相乘，因此它只计一次，按输出层计算。模型卡往往还会计入输入嵌入表和 MTP 层，所以其数字可能明显更高，对词表很大的小型混合专家模型尤其如此。原始仓库自己给出的统计数字会单独显示。

只有混合专家（MoE）模型才会给出激活参数，即 GGUF 头部显示每层有多个专家的模型。每层只有一个专家（专家数为 1）的模型是稠密模型：每个 token 都会用到全部参数，因此不单独显示激活参数。

原始仓库自身给出的参数量，是 Hugging Face 为其 safetensors 权重报告的总数；有些仓库在元数据中写错了这个数。只有经过确认，才会显示该数值并将其包含在下载文件中：它必须大于 100M 个参数，与 Hugging Face 从该仓库权重文件中读取的各类型参数量之和相差在 1% 以内；对于有 GGUF 文件的模型，还必须是 GGUF 参数量的 0.5 到 2.5 倍之间（原始模型还可能包含视觉或音频编码器，或多 token 预测层；当 GGUF 把共享的嵌入层作为输出层再存一次时，GGUF 的参数量可能更大）。没有 GGUF 文件的模型只需通过前两项检查。否则该参数量不予列出。

各状态的含义

状态	页面显示
`two_source`	已显示：开放来源所链接的厂商规格与独立的交叉核对结果一致。
`conflict`	开放来源之间存在分歧，因此不显示该数值；依赖该数值的估算（例如速度）也不提供。
`single`	未显示：开放来源未能给出两个相互独立、彼此一致且附有厂商出处的数值。
`missing`	未显示：开放来源未能给出两个相互独立、彼此一致且附有厂商出处的数值。
`withheld`	该条目此前已发布，但其来源现在存在分歧、某个来源发生了变化，或它不再符合收录规则。其页面（不被索引）连同来源链接会保留；数值、估算和结论均被隐藏。来源正常满 30 天后，该条目将被撤下；当两个来源再次一致时，它会恢复。
`retired`	在来源正常的情况下已暂缓 30 天。该页面作为墓碑页保留（不被索引），如有替代条目则链接到该条目。

速度上限

生成一个 token 时，会读取一次激活权重和 KV 缓存，因此 tokens/s 不会超过带宽除以每个 token 读取的字节数。对于混合专家模型，只计入正在使用的专家所占的份额，数据来自 GGUF 张量表。这是理论上界；如果带宽没有两个来源确认，则不给出速度。

公开基准测试

由 llama.cpp 项目在其仓库中发布的 llama.cpp 实测速度（llama-bench，基于固定的 llama.cpp 提交）。这些说明中的机器（DGX Spark、Apple M2 Ultra）在本版本中不给出结论；这些数字展示了实测速度与带宽上界的对比，以及速度如何随上下文增长而下降： llama.cpp benches/ (5aeac37a)

llama-bench 结果按原样发布（单位：tokens/s；每个数字都链接到来源文件）。提示词处理 = 读取提示词；生成 = 产生新的 token。
机器	模型（GGUF 仓库）	后端	测试	每秒 token 数（tokens/s）
NVIDIA DGX Spark (GB10)	ggml-org/gpt-oss-20b-GGUF (gpt-oss 20B MXFP4 MoE)	CUDA	提示词处理，2048 个 token	4,505.8
NVIDIA DGX Spark (GB10)	ggml-org/gpt-oss-20b-GGUF (gpt-oss 20B MXFP4 MoE)	CUDA	生成，32 个 token	83.4
NVIDIA DGX Spark (GB10)	ggml-org/gpt-oss-20b-GGUF (gpt-oss 20B MXFP4 MoE)	CUDA	提示词处理，2048 个 token · 在 32,768 个 token 的上下文之后	2,689.4
NVIDIA DGX Spark (GB10)	ggml-org/gpt-oss-20b-GGUF (gpt-oss 20B MXFP4 MoE)	CUDA	生成，32 个 token · 在 32,768 个 token 的上下文之后	61.7
NVIDIA DGX Spark (GB10)	ggml-org/gpt-oss-120b-GGUF (gpt-oss 120B MXFP4 MoE)	CUDA	提示词处理，2048 个 token	2,443.9
NVIDIA DGX Spark (GB10)	ggml-org/gpt-oss-120b-GGUF (gpt-oss 120B MXFP4 MoE)	CUDA	生成，32 个 token	58.7
NVIDIA DGX Spark (GB10)	ggml-org/gpt-oss-120b-GGUF (gpt-oss 120B MXFP4 MoE)	CUDA	提示词处理，2048 个 token · 在 32,768 个 token 的上下文之后	1,567.1
NVIDIA DGX Spark (GB10)	ggml-org/gpt-oss-120b-GGUF (gpt-oss 120B MXFP4 MoE)	CUDA	生成，32 个 token · 在 32,768 个 token 的上下文之后	42.8
NVIDIA DGX Spark (GB10)	ggml-org/Qwen3-Coder-30B-A3B-Instruct-Q8_0-GGUF (qwen3moe 30B.A3B Q8_0)	CUDA	提示词处理，2048 个 token	2,987.0
NVIDIA DGX Spark (GB10)	ggml-org/Qwen3-Coder-30B-A3B-Instruct-Q8_0-GGUF (qwen3moe 30B.A3B Q8_0)	CUDA	生成，32 个 token	61.1
NVIDIA DGX Spark (GB10)	ggml-org/Qwen3-Coder-30B-A3B-Instruct-Q8_0-GGUF (qwen3moe 30B.A3B Q8_0)	CUDA	提示词处理，2048 个 token · 在 32,768 个 token 的上下文之后	1,348.2
NVIDIA DGX Spark (GB10)	ggml-org/Qwen3-Coder-30B-A3B-Instruct-Q8_0-GGUF (qwen3moe 30B.A3B Q8_0)	CUDA	生成，32 个 token · 在 32,768 个 token 的上下文之后	30.2
NVIDIA DGX Spark (GB10)	ggml-org/Qwen2.5-Coder-7B-Q8_0-GGUF (qwen2 7B Q8_0)	CUDA	提示词处理，2048 个 token	2,250.3
NVIDIA DGX Spark (GB10)	ggml-org/Qwen2.5-Coder-7B-Q8_0-GGUF (qwen2 7B Q8_0)	CUDA	生成，32 个 token	29.4
NVIDIA DGX Spark (GB10)	ggml-org/Qwen2.5-Coder-7B-Q8_0-GGUF (qwen2 7B Q8_0)	CUDA	提示词处理，2048 个 token · 在 32,768 个 token 的上下文之后	1,471.2
NVIDIA DGX Spark (GB10)	ggml-org/Qwen2.5-Coder-7B-Q8_0-GGUF (qwen2 7B Q8_0)	CUDA	生成，32 个 token · 在 32,768 个 token 的上下文之后	22.5
NVIDIA DGX Spark (GB10)	ggml-org/gemma-3-4b-it-qat-GGUF (gemma3 4B Q4_0)	CUDA	提示词处理，2048 个 token	5,948.7
NVIDIA DGX Spark (GB10)	ggml-org/gemma-3-4b-it-qat-GGUF (gemma3 4B Q4_0)	CUDA	生成，32 个 token	81.1
NVIDIA DGX Spark (GB10)	ggml-org/gemma-3-4b-it-qat-GGUF (gemma3 4B Q4_0)	CUDA	提示词处理，2048 个 token · 在 32,768 个 token 的上下文之后	5,023.3
NVIDIA DGX Spark (GB10)	ggml-org/gemma-3-4b-it-qat-GGUF (gemma3 4B Q4_0)	CUDA	生成，32 个 token · 在 32,768 个 token 的上下文之后	62.3
NVIDIA DGX Spark (GB10)	ggml-org/GLM-4.7-Flash-GGUF (deepseek2 30B.A3B Q8_0)	CUDA	提示词处理，2048 个 token	2,364.2
NVIDIA DGX Spark (GB10)	ggml-org/GLM-4.7-Flash-GGUF (deepseek2 30B.A3B Q8_0)	CUDA	生成，32 个 token	48.7
NVIDIA DGX Spark (GB10)	ggml-org/GLM-4.7-Flash-GGUF (deepseek2 30B.A3B Q8_0)	CUDA	提示词处理，2048 个 token · 在 32,768 个 token 的上下文之后	567.2
NVIDIA DGX Spark (GB10)	ggml-org/GLM-4.7-Flash-GGUF (deepseek2 30B.A3B Q8_0)	CUDA	生成，32 个 token · 在 32,768 个 token 的上下文之后	32.7
NVIDIA DGX Spark (GB10)	ggml-org/Nemotron-3-Super-120B-GGUF (nemotron 120B.A12B Q4_K)	CUDA	提示词处理，2048 个 token	768.8
NVIDIA DGX Spark (GB10)	ggml-org/Nemotron-3-Super-120B-GGUF (nemotron 120B.A12B Q4_K)	CUDA	生成，32 个 token	19.9
NVIDIA DGX Spark (GB10)	ggml-org/Nemotron-3-Super-120B-GGUF (nemotron 120B.A12B Q4_K)	CUDA	提示词处理，2048 个 token · 在 32,768 个 token 的上下文之后	724.4
NVIDIA DGX Spark (GB10)	ggml-org/Nemotron-3-Super-120B-GGUF (nemotron 120B.A12B Q4_K)	CUDA	生成，32 个 token · 在 32,768 个 token 的上下文之后	19.5
NVIDIA DGX Spark (GB10)	ggml-org/Nemotron-3-Nano-4B-GGUF (nemotron 4B Q8_0)	CUDA	提示词处理，2048 个 token	2,761.9
NVIDIA DGX Spark (GB10)	ggml-org/Nemotron-3-Nano-4B-GGUF (nemotron 4B Q8_0)	CUDA	生成，32 个 token	52.9
NVIDIA DGX Spark (GB10)	ggml-org/Nemotron-3-Nano-4B-GGUF (nemotron 4B Q8_0)	CUDA	提示词处理，2048 个 token · 在 32,768 个 token 的上下文之后	2,041.5
NVIDIA DGX Spark (GB10)	ggml-org/Nemotron-3-Nano-4B-GGUF (nemotron 4B Q8_0)	CUDA	生成，32 个 token · 在 32,768 个 token 的上下文之后	46.7
Apple M2 Ultra	ggml-org/gpt-oss-20b-GGUF (gpt-oss 20B MXFP4 MoE)	MTL,BLAS	提示词处理，2048 个 token	2,713.4
Apple M2 Ultra	ggml-org/gpt-oss-20b-GGUF (gpt-oss 20B MXFP4 MoE)	MTL,BLAS	生成，32 个 token	130.0
Apple M2 Ultra	ggml-org/gpt-oss-20b-GGUF (gpt-oss 20B MXFP4 MoE)	MTL,BLAS	提示词处理，2048 个 token · 在 32,768 个 token 的上下文之后	1,122.6
Apple M2 Ultra	ggml-org/gpt-oss-20b-GGUF (gpt-oss 20B MXFP4 MoE)	MTL,BLAS	生成，32 个 token · 在 32,768 个 token 的上下文之后	98.3
Apple M2 Ultra	ggml-org/gpt-oss-120b-GGUF (gpt-oss 120B MXFP4 MoE)	MTL,BLAS	提示词处理，2048 个 token	1,648.7
Apple M2 Ultra	ggml-org/gpt-oss-120b-GGUF (gpt-oss 120B MXFP4 MoE)	MTL,BLAS	生成，32 个 token	85.6
Apple M2 Ultra	ggml-org/gpt-oss-120b-GGUF (gpt-oss 120B MXFP4 MoE)	MTL,BLAS	提示词处理，2048 个 token · 在 32,768 个 token 的上下文之后	721.1
Apple M2 Ultra	ggml-org/gpt-oss-120b-GGUF (gpt-oss 120B MXFP4 MoE)	MTL,BLAS	生成，32 个 token · 在 32,768 个 token 的上下文之后	65.5
Apple M2 Ultra	ggml-org/Qwen3-Coder-30B-A3B-Instruct-Q8_0-GGUF (qwen3moe 30B.A3B Q8_0)	MTL,BLAS	提示词处理，2048 个 token	2,453.1
Apple M2 Ultra	ggml-org/Qwen3-Coder-30B-A3B-Instruct-Q8_0-GGUF (qwen3moe 30B.A3B Q8_0)	MTL,BLAS	生成，32 个 token	79.0
Apple M2 Ultra	ggml-org/Qwen3-Coder-30B-A3B-Instruct-Q8_0-GGUF (qwen3moe 30B.A3B Q8_0)	MTL,BLAS	提示词处理，2048 个 token · 在 32,768 个 token 的上下文之后	431.3
Apple M2 Ultra	ggml-org/Qwen3-Coder-30B-A3B-Instruct-Q8_0-GGUF (qwen3moe 30B.A3B Q8_0)	MTL,BLAS	生成，32 个 token · 在 32,768 个 token 的上下文之后	45.3
Apple M2 Ultra	ggml-org/Qwen2.5-Coder-7B-Q8_0-GGUF (qwen2 7B Q8_0)	MTL,BLAS	提示词处理，2048 个 token	1,565.9
Apple M2 Ultra	ggml-org/Qwen2.5-Coder-7B-Q8_0-GGUF (qwen2 7B Q8_0)	MTL,BLAS	生成，32 个 token	79.7
Apple M2 Ultra	ggml-org/Qwen2.5-Coder-7B-Q8_0-GGUF (qwen2 7B Q8_0)	MTL,BLAS	提示词处理，2048 个 token · 在 32,768 个 token 的上下文之后	612.2
Apple M2 Ultra	ggml-org/Qwen2.5-Coder-7B-Q8_0-GGUF (qwen2 7B Q8_0)	MTL,BLAS	生成，32 个 token · 在 32,768 个 token 的上下文之后	56.8
Apple M2 Ultra	ggml-org/gemma-3-4b-it-qat-GGUF (gemma3 4B Q4_0)	MTL,BLAS	提示词处理，2048 个 token	2,923.6
Apple M2 Ultra	ggml-org/gemma-3-4b-it-qat-GGUF (gemma3 4B Q4_0)	MTL,BLAS	生成，32 个 token	134.3
Apple M2 Ultra	ggml-org/gemma-3-4b-it-qat-GGUF (gemma3 4B Q4_0)	MTL,BLAS	提示词处理，2048 个 token · 在 32,768 个 token 的上下文之后	2,129.2
Apple M2 Ultra	ggml-org/gemma-3-4b-it-qat-GGUF (gemma3 4B Q4_0)	MTL,BLAS	生成，32 个 token · 在 32,768 个 token 的上下文之后	113.1
Apple M2 Ultra	ggml-org/GLM-4.7-Flash-GGUF (deepseek2 30B.A3B Q8_0)	MTL,BLAS	提示词处理，2048 个 token	1,629.3
Apple M2 Ultra	ggml-org/GLM-4.7-Flash-GGUF (deepseek2 30B.A3B Q8_0)	MTL,BLAS	生成，32 个 token	59.6
Apple M2 Ultra	ggml-org/GLM-4.7-Flash-GGUF (deepseek2 30B.A3B Q8_0)	MTL,BLAS	提示词处理，2048 个 token · 在 32,768 个 token 的上下文之后	151.4
Apple M2 Ultra	ggml-org/GLM-4.7-Flash-GGUF (deepseek2 30B.A3B Q8_0)	MTL,BLAS	生成，32 个 token · 在 32,768 个 token 的上下文之后	21.8

Mac 及其他统一内存计算机

这类电脑只允许 GPU 使用其部分内存，而且它们的开放来源没有逐项给出参考出处。本版本不发布这些设备；它们的运行档案已保留，待来源允许时再使用。

单位

这里计算的显存量以 GiB（1,073,741,824 字节）为单位。GPU 厂商所说的“24 GB”显存就是 24 GiB。Hugging Face 以十进制 GB 显示文件大小，因此 5.03 GB 的文件在这里显示为 4.68 GiB。带宽以 GB/s（每秒 10⁹ 字节）为单位。

更新

每 6 小时扫描一次 Hugging Face，查找新模型和新的 GGUF 文件；GPU 规格每天重新核对。