Como as estimativas são feitas

Esta página foi escrita e traduzida automaticamente por IA e verificada por software em relação às suas fontes, sem edição humana. As especificações vêm das fontes listadas; os requisitos de memória e as velocidades são estimativas calculadas com fórmulas publicadas. Como usamos IA

Cada número deste site é uma especificação em que duas fontes abertas independentes concordam ou o resultado do código determinístico descrito abaixo. O mesmo código roda quando as páginas são geradas e no seu navegador.

Valores atualizados em 19 de out. de 2026

O que é modelado

Modelado: llama.cpp carregando um arquivo GGUF, somente texto, todas as camadas na GPU, Flash Attention ativado, micro-lote de 512, um usuário. Para várias placas: placas idênticas em uma mesma máquina, com a divisão de camadas padrão do llama.cpp. Modelos multimodais são contabilizados sem o projetor de visão e sem o processamento de imagens.

Ollama e LM Studio usam llama.cpp, mas podem usar padrões diferentes. vLLM, MLX e Transformers alocam memória de forma diferente e não são modelados. Um resultado “Cabe” não significa que um determinado driver ou back end ofereça suporte à arquitetura ou à quantização do modelo.

Fórmula, termo a termo

Para cada placa d, a estimativa Q_d é a mesma quantidade que o llama.cpp exibe por dispositivo como buffers de modelo + KV + RS + computação. As camadas são distribuídas entre as placas com a divisão padrão do llama.cpp; o embedding de entrada permanece na memória do sistema.

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)
Cabe: ∀ d: Q⁺_d ÷ 0,95 + 1 GiB ≤ C_low
Não cabe: Q⁻ ÷ 1,10 > C_high (N = 1);   Σ_d Q⁻_d ÷ 1,10 > N × C_high (N > 1)
No limite: caso contrário
C_low = G − D_card − U;   C_high = G
tok/s ≤ B ÷ (R + R_KV)

W_d

Pesos na placa d: os bytes das camadas colocadas nela, lidos da tabela de tensores do GGUF, mais a camada de saída na última placa.

KV_d

KV cache na placa d: elementos K e V por token de cada camada de atenção na placa, vezes bytes por elemento, vezes células em cache. A atenção latente multi-cabeça armazena apenas K.

S_d

Estado recorrente: estado de tamanho fixo das camadas recorrentes e de atenção linear (32 bits), um por sequência paralela.

C_d, L, M, P

Buffer de computação: L é o buffer de logits, M a máscara de atenção, P as entradas por cópia que o paralelismo em pipeline mantém em cada placa quando várias placas são usadas.

Q⁺

Q⁺: a estimativa por placa usada para “Cabe” — 4 sequências paralelas (o padrão -np auto do llama-server), camadas exatamente no limite entre placas contadas nas duas placas.

Q⁻

Q⁻: a estimativa usada para “Não cabe” — 1 sequência, cada camada contada uma única vez, conforme o código-fonte a atribui.

X

X: a memória disponível por placa necessária para “Cabe”. As páginas a exibem como “Memória disponível necessária para Cabe”.

G, N

G: a memória nominal de uma placa (os “24 GB” do fabricante contados como 24 GiB); N: o número de placas idênticas.

C_low

C_low: memória considerada disponível para “Cabe” — memória nominal menos a diferença entre o nominal e o informado da placa (D_card) e o maior uso de inicialização e de execução nos logs públicos do perfil (U), arredondada para baixo para um múltiplo de 64 MiB.

C_high

C_high: a memória nominal total, usada para “Não cabe”.

B, R, R_KV

B: largura de banda da memória (bytes por segundo); R: bytes de pesos lidos por token gerado (tensores não especialistas mais a parcela de especialistas em uso); R_KV: bytes de KV cache lidos por token.

Constantes

Os pesos não são estimados a partir da contagem de parâmetros: os arquivos GGUF de cada quantização são lidos (cabeçalho e tabela de tensores) em uma revisão fixa, e os bytes de cada camada são somados. Tensores que o llama.cpp mantém na memória do sistema (embeddings de entrada) ficam de fora.

Cabe, no limite ou não cabe

“Cabe” significa apenas isto: a verificação de carregamento do --fit padrão do llama.cpp colocaria todas as camadas na GPU. O llama.cpp faz essa verificação ao carregar um modelo (os buffers estimados mais uma reserva de 1 GiB por placa não devem ultrapassar a memória livre na inicialização); este site a recalcula com as mesmas regras de buffer e deixa margem para erros de estimativa. Isso não garante que o pico de memória durante a inferência (pools de memória, prompts longos e outras alocações em tempo de execução) caiba.

Os testes de referência (gold standard) permitem que a estimativa fique até 5% abaixo e até 10% acima do valor real, então cada lado da decisão usa seu próprio limite:

• Cabe quando, em cada placa, Q⁺ ÷ 0,95 + 1 GiB não é maior que C_low. Q⁺ assume 4 sequências paralelas.
• Não cabe quando Q⁻ ÷ 1,10 é maior que a memória total C_high (com várias placas: a soma das placas comparada com N × C_high, porque o --fit padrão ajusta a divisão por conta própria).
• No limite no meio: pode ou não caber. Reduza o contexto ou use uma quantização menor.
• Desconhecido quando nenhum perfil de execução cobre o dispositivo, para GPUs de estação de trabalho e de data center (a configuração de memória delas não é estabelecida por logs públicos), ou quando a memória contada como disponível é menor que 2 GiB: só X é mostrado, mais “Não cabe” se o modelo for grande demais até para a memória total.

X = o maior Q⁺ ÷ 0,95 + 1 GiB por placa é a memória disponível necessária para “Cabe”. As páginas escrevem “Memória disponível necessária para Cabe”, e não “pelo menos”, porque um resultado no limite precisa da mesma quantidade.

As tabelas verificam as quantizações da maior para a menor no contexto padrão. Uma linha mostra a maior quantização que cabe (com X, o maior contexto e o teto de velocidade) ou, se nenhuma couber, a maior que está no limite (com X) ou, se todas forem grandes demais, a menor quantização com seu X.

O maior contexto é buscado entre o contexto padrão e o menor valor entre o máximo do modelo e o maior contexto coberto por logs medidos (262.144 células em uma placa, 131.072 em várias). Se ainda couber ali, as páginas mostram “≥” esse valor: contextos maiores não foram verificados.

Várias placas idênticas só são consideradas quando uma placa não basta, apenas para GPUs de desktop, de estação de trabalho e de data center com perfil de execução, e cada quantidade de 2 a 8 é verificada separadamente (adicionar uma placa nem sempre reduz a carga da placa mais pesada, e o paralelismo de pipeline adiciona 4 cópias das entradas de camada). A página informa a menor quantidade que cabe com a divisão uniforme padrão; não é um mínimo, porque o --fit padrão pode ajustar a divisão e talvez funcione com menos placas. GPUs de estação de trabalho e de data center, e GPUs com menos de 2 GiB contados como disponíveis, recebem apenas “Não cabe nem em 8 placas” (ou nenhuma quantidade).

Perfis de execução

A quantidade de memória contada como disponível vem apenas de logs públicos do llama.cpp: o total que cada dispositivo informa, a memória livre quando a verificação --fit do llama.cpp é executada e, quando impressa, a memória não contabilizada após uma execução. D_card = nominal − total informado desse modelo de GPU (o maior, se houver vários logs); U = o maior valor entre total − livre na verificação --fit e a memória não contabilizada positiva após uma execução, entre todas as observações válidas do perfil. Quando um log tem apenas uma leitura da lista de dispositivos, soma-se a maior diferença entre a lista e a verificação observada no perfil. As observações são excluídas quando há um monitor conectado, outros programas já usavam a GPU, a memória livre excede o total, ou um servidor compartilhado adiciona uso não relacionado. Um perfil sem observações suficientes não gera veredictos.

GPUs de consumo sem medição própria usam a maior diferença entre o total nominal e o informado medida em placas de consumo e de estação de trabalho, na configuração padrão. GPUs de estação de trabalho e de data center não recebem “Cabe” nem “No limite”, tendo medição ou não, porque os logs públicos não mostram a configuração de memória delas (por exemplo, se o ECC está ativado): ficam como “Desconhecido”, a menos que o modelo seja grande demais até para a memória total, e para várias placas só se informa “Não cabe nem em 8 placas”. GPUs de notebook, Apple silicon e outros computadores com memória unificada não têm perfil nesta versão.

CUDA (NVIDIA)

llama.cpp, back end CUDA (GPU dedicada NVIDIA), todas as camadas na GPU, Flash Attention ativada, micro-batch (-ub) 512, KV cache em F16, contexto (-c) conforme indicado; “Cabe” é avaliado com as 4 sequências paralelas padrão do llama-server (-np auto, KV cache unificado) e “Não cabe” com 1 sequência; GPU ociosa, sem outros programas usando sua memória.

U = 2.112 MiB; D para GPUs de desktop sem medição própria = 1.054 MiB.

Memória não contabilizada após uma execução nestes logs: 236–2.050 MiB (4 observações). As alocações em tempo de execução não fazem parte de “Cabe”; U as inclui apenas como folga adicional, não como limite superior.

D_card: memória nominal menos o total que o llama.cpp informou para esse modelo de 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

Observações de logs públicos do llama.cpp, com as linhas de log citadas.

Dispositivo	Backend de execução	Compilação	Nominal	Total informado (MiB)	Livre na inicialização (MiB)	Usado antes do carregamento (MiB)	Não contabilizado após a execução (MiB)	Fonte
NVIDIA GeForce RTX 3090 (x2, CUDA0)	CUDA	b11415	24 GB	24.575	23.054	1.522	—	llama.cpp issues/29811 Linhas do log 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 Linhas do log 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 Linhas do log 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 Linhas do log 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 Linhas do log 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 Linhas do log 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 Linhas do log 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 Linhas do log 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 Linhas do log 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 Linhas do log 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 Linhas do log 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 Linhas do log 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 Linhas do log 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 Linhas do log 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 Linhas do log 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 Linhas do log 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 Linhas do log 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, back end Vulkan (GPU dedicada Intel), todas as camadas na GPU, Flash Attention ativada, micro-batch (-ub) 512, KV cache em F16, contexto (-c) conforme indicado; “Cabe” é avaliado com 4 sequências paralelas e “Não cabe” com 1 sequência; GPU ociosa. Ainda não há medições públicas suficientes, então nenhum veredito usa este perfil.

U = 832 MiB; D para GPUs de desktop sem medição própria = 0 MiB.

D_card: memória nominal menos o total que o llama.cpp informou para esse modelo de GPU (MiB).

GPU	D_card (MiB)
Intel Arc Pro B70	138

Observações de logs públicos do llama.cpp, com as linhas de log citadas.

Dispositivo	Backend de execução	Compilação	Nominal	Total informado (MiB)	Livre na inicialização (MiB)	Usado antes do carregamento (MiB)	Não contabilizado após a execução (MiB)	Fonte
Intel Arc Pro B70	Vulkan	build_info: b8871-7fc1c4ef7	32 GB	32.630	31.861	769	—	llama.cpp issues/22275 Linhas do log 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

ROCm no Linux (AMD)

llama.cpp, back end ROCm no Linux (GPU dedicada AMD), todas as camadas na GPU, Flash Attention ativada, micro-batch (-ub) 512, KV cache em F16, contexto (-c) conforme indicado; “Cabe” é avaliado com as 4 sequências paralelas padrão do llama-server (-np auto, KV cache unificado) e “Não cabe” com 1 sequência; GPU ociosa, sem outros programas usando sua memória.

U = 1.216 MiB; D para GPUs de desktop sem medição própria = 144 MiB.

Memória não contabilizada após uma execução neste log: 279 MiB (1 observação). As alocações em tempo de execução não fazem parte de “Cabe”; U as inclui apenas como folga adicional, não como limite superior.

D_card: memória nominal menos o total que o llama.cpp informou para esse modelo de 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

Observações de logs públicos do llama.cpp, com as linhas de log citadas.

Dispositivo	Backend de execução	Compilação	Nominal	Total informado (MiB)	Livre na inicialização (MiB)	Usado antes do carregamento (MiB)	Não contabilizado após a execução (MiB)	Fonte
AMD Radeon RX 7900 XTX	ROCm	version: 9744 (063d9c1)	24 GB	24.560	24.494	266	—	llama.cpp issues/24858 Linhas do log [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 Linhas do log 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 Linhas do log 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 Linhas do log - 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 Linhas do log 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 Linhas do log [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 Linhas do log 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 Linhas do log | - 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 Linhas do log 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 Linhas do log 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 Linhas do log 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

Testes de referência

Cada caso é um log público do llama.cpp que mostra os buffers por dispositivo. Os arquivos GGUF desse log são lidos, os buffers são recalculados por placa com o contexto, as sequências, o micro-lote e o tipo de KV do próprio log, e comparados com modelo + KV + RS + computação para a mesma placa. 38 casos (50 placas) rodam como testes automatizados a cada build e devem ficar entre −5% e +10%; o maior erro é +8,85%.

Logs deixados de fora e por quê

• E04: Flash Attention estava desligado; este site modela Flash Attention ligado.
• E09: Executado com --swa-full, um cache de janela deslizante fora do padrão.
• E16: Várias sequências sem KV cache unificado; esse layout de cache não é modelado.
• E32: Flash Attention estava desligado; este site modela Flash Attention ligado.
• E34: Flash Attention estava desligado; este site modela Flash Attention ligado.
• E42: Flash Attention estava desligado; este site modela Flash Attention ligado.

Regras do llama.cpp por arquitetura

A forma como cada arquitetura organiza seu KV cache e seu estado foi transcrita do código-fonte do llama.cpp no commit 5aeac37a35.

Fontes e como as especificações são verificadas

• Os sites dos fabricantes nunca são acessados, porque seus termos proíbem o acesso automatizado. A especificação do fabricante vem de conjuntos de dados abertos que vinculam, linha a linha, uma folha de dados do fabricante (GetDeploying e Epoch AI, quando a folha de dados está em um domínio do fabricante ou em um serviço de hospedagem de documentos que o próprio fabricante usa para suas folhas de dados) e da documentação do ROCm da AMD. Esses links de folhas de dados são exibidos como “referência do fabricante”, marcados como não acessados por este site. Os links de folhas de dados contam como do fabricante quando estão em um destes domínios (incluindo serviços de hospedagem de documentos que os fabricantes usam): amd.com, apple.com, dam-cdn.nvd.orangelogic.com, geforce.com, intel.com, nvdam.widen.net, nvidia.com
• A Wikipedia é usada como verificação cruzada independente. Suas notas de rodapé não são usadas como fonte de um valor, porque as notas de rodapé de colunas e de nomes de produtos não mostram de onde veio um campo específico.
• O voto da especificação do fabricante e o voto da verificação cruzada devem vir de editores diferentes, sem referência entre eles: se a página da Wikipedia (ou a linha do conjunto de dados) usada na verificação cruzada citar o outro editor, ela conta como derivada, e não como um segundo voto. Uma fonte que copia outra sem declarar isso não pode ser detectada a partir de evidências públicas.
• Um valor é exibido (two_source) quando um voto de especificação do fabricante e uma verificação cruzada independente concordam e nenhuma fonte saudável discorda. Caso contrário, é “conflict” (as fontes discordam), “single” (sem voto de especificação do fabricante ou sem verificação cruzada independente) ou “missing”.
• As linhas que um conjunto de dados aberto atribui à TechPowerUp (linhas da Epoch AI cujo link da folha de dados aponta para techpowerup.com) não são lidas de forma alguma, porque os termos da TechPowerUp proíbem conjuntos de dados derivados: elas não votam nem contam como divergência.
• Concordância significa: tamanho de memória exatamente igual, largura de banda dentro de 1%, outros números dentro de 2%, texto igual após normalização.
• O valor exibido é o que o maior número de fontes concordantes informa exatamente; o número e o link de cada fonte estão listados ao lado. Os links da Wikipedia apontam para a revisão exata usada.
• Computadores Apple Silicon, DGX Spark e Strix Halo não são publicados nesta versão: nenhuma fonte aberta vincula uma ficha técnica do fabricante a eles linha a linha.
• Os dados dos modelos vêm do Hugging Face em revisões fixas. Cada modelo usa um repositório GGUF para todas as suas quantizações, escolhido por uma ordem fixa de editores; a arquitetura é lida do cabeçalho GGUF e, quando o config.json original é legível, verificada em comparação com ele.
• Os pesos originais, mostrados apenas como referência, contam os arquivos safetensors do repositório no nível superior e em pastas model*: com um model.safetensors.index.json, os arquivos que ele nomeia mais os conjuntos completos em outras pastas model*; sem ele, todos os conjuntos completos, sendo que um arquivo unificado e uma cópia fragmentada idêntica são contados uma só vez. Outras pastas (por exemplo, decodificadores armazenados separadamente), original/, arquivos consolidated*, adaptadores LoRA e arquivos .bin / .pt não são contados. Quando os arquivos não formam um conjunto inequívoco, nenhum tamanho é informado.

Contagem de parâmetros

Os parâmetros são contados a partir da tabela de tensores do arquivo GGUF escolhido: todos os tensores que o llama.cpp carrega, incluindo a tabela de embedding de entrada. As camadas de previsão de vários tokens (MTP / NextN), que o llama.cpp não carrega por padrão, não são contadas; as páginas de modelos que as têm informam quantas são. Os parâmetros ativos por token contam os tensores que não são de especialistas mais os especialistas em uso (especialistas usados ÷ especialistas por camada), mas não a consulta à embedding de entrada, porque apenas uma linha dela é lida por token. Quando um modelo usa uma mesma matriz como embedding de entrada e como camada de saída (embeddings compartilhadas), cada token é multiplicado por ela inteira, por isso ela é contada uma vez, como camada de saída. Os cartões de modelo muitas vezes também contam a tabela de embedding de entrada e as camadas MTP, então seus valores podem ser visivelmente maiores, especialmente em modelos pequenos de mistura de especialistas com vocabulários grandes. A contagem do repositório original é mostrada separadamente.

Os parâmetros ativos são informados apenas para modelos de mistura de especialistas, isto é, modelos cujo cabeçalho GGUF lista mais de um especialista por camada. Um modelo com um único especialista por camada (contagem de especialistas 1) é denso: todos os parâmetros são usados para cada token, então nenhum valor ativo separado é exibido.

A contagem do repositório original é o total que o Hugging Face informa para os seus pesos em safetensors; alguns repositórios a declaram de forma incorreta nos metadados. Ela só é exibida, e só é incluída nos downloads, quando é confirmada: deve ser maior que 100M parâmetros, estar dentro de 1% das contagens de parâmetros por tipo que o Hugging Face lê dos arquivos de pesos do repositório e, para modelos com um arquivo GGUF, ficar entre 0,5 e 2,5 vezes a contagem do GGUF (o original também pode conter um codificador de visão ou de áudio ou camadas de predição de vários tokens; o GGUF pode ser maior quando armazena uma embedding compartilhada uma segunda vez como camada de saída). Modelos sem arquivo GGUF precisam passar pelas duas primeiras verificações. Caso contrário, a contagem é omitida.

O que cada status mostra

Teto de velocidade

Gerar um token lê os pesos ativos e o KV cache uma vez, portanto os tokens por segundo não podem exceder a largura de banda dividida pelos bytes lidos por token. Para modelos de mistura de especialistas, conta-se apenas a parcela de especialistas em uso, a partir da tabela de tensores do GGUF. É um limite superior teórico; nenhuma velocidade é informada quando a largura de banda não é confirmada por duas fontes.

Benchmarks públicos

Velocidades medidas do llama.cpp, publicadas pelo projeto llama.cpp em seu repositório (llama-bench, no commit fixado do llama.cpp). As máquinas citadas nestas notas (DGX Spark, Apple M2 Ultra) não recebem vereditos neste site nesta versão; os números mostram como a velocidade medida se compara com o limite superior de largura de banda e como ela cai conforme o contexto aumenta: llama.cpp benches/ (5aeac37a)

Macs e outros computadores com memória unificada

Esses computadores permitem que a GPU use apenas parte da memória, e as fontes abertas para eles não citam referências por valor. Eles não são publicados nesta versão; os perfis de execução para eles são mantidos para quando as fontes permitirem.

Unidades

As quantidades de memória calculadas aqui estão em GiB (1.073.741.824 bytes). Os "24 GB" de memória de vídeo dos fabricantes de GPU são 24 GiB. O Hugging Face mostra tamanhos de arquivo em GB decimais, então um arquivo de 5,03 GB aparece aqui como 4,68 GiB. A largura de banda está em GB/s (10⁹ bytes por segundo).

Atualizações

O Hugging Face é verificado a cada 6 horas em busca de novos modelos e novos arquivos GGUF; as especificações de GPUs são reverificadas diariamente.