Cómo se hacen las estimaciones

Esta página fue escrita y traducida automáticamente por IA y verificada por software con respecto a sus fuentes, sin edición humana. Las especificaciones provienen de las fuentes indicadas; los requisitos de memoria y las velocidades son estimaciones calculadas con fórmulas publicadas. Cómo usamos la IA

Cada número de este sitio es una especificación en la que coinciden dos fuentes abiertas independientes, o el resultado del código determinista que se describe a continuación. El mismo código se ejecuta cuando se generan las páginas y en tu navegador.

Valores actualizados el 19 oct 2026

Qué se modela

Se modela: llama.cpp cargando un archivo GGUF, solo texto, todas las capas en la GPU, Flash Attention activado, micro-lote de 512, un usuario. Para varias tarjetas: tarjetas idénticas en una misma máquina, con la división de capas predeterminada de llama.cpp. Los modelos multimodales se cuentan sin su proyector de visión ni el procesamiento de imágenes.

Ollama y LM Studio usan llama.cpp, pero pueden usar valores predeterminados distintos. vLLM, MLX y Transformers asignan la memoria de otra manera y no están modelados. Un resultado «Cabe» no significa que un controlador o backend determinado admita la arquitectura o la cuantización del modelo.

La fórmula, término por término

Para cada tarjeta d, la estimación Q_d es la misma cantidad que llama.cpp muestra por dispositivo como búferes de modelo + KV + RS + cómputo. Las capas se asignan a las tarjetas con la división predeterminada de llama.cpp; la incrustación de entrada permanece en la memoria del 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
No cabe: Q⁻ ÷ 1,10 > C_high (N = 1);   Σ_d Q⁻_d ÷ 1,10 > N × C_high (N > 1)
Al límite: en otro caso
C_low = G − D_card − U;   C_high = G
tok/s ≤ B ÷ (R + R_KV)

W_d

Pesos en la tarjeta d: los bytes de las capas ubicadas en ella, leídos de la tabla de tensores del GGUF, más la capa de salida en la última tarjeta.

KV_d

KV cache en la tarjeta d: elementos K y V por token de cada capa de atención de la tarjeta, por bytes por elemento, por celdas en caché. La atención latente multicabezal almacena solo K.

S_d

Estado recurrente: estado de tamaño fijo de las capas recurrentes y de atención lineal (32 bits), uno por secuencia paralela.

C_d, L, M, P

Búfer de cómputo: L es el búfer de logits, M la máscara de atención y P las entradas por copia que el paralelismo de canalización mantiene en cada tarjeta cuando se usan varias tarjetas.

Q⁺

Q⁺: la estimación por tarjeta usada para «Cabe»: 4 secuencias paralelas (el valor predeterminado -np auto de llama-server), con las capas situadas exactamente en el límite entre tarjetas contadas en ambas tarjetas.

Q⁻

Q⁻: la estimación usada para «No cabe»: 1 secuencia, cada capa contada una sola vez, tal como la asigna el código fuente.

X

X: la memoria disponible por tarjeta necesaria para «Cabe». Las páginas la muestran como «Memoria disponible necesaria para Cabe».

G, N

G: la memoria nominal de una tarjeta (los «24 GB» del fabricante se cuentan como 24 GiB); N: el número de tarjetas idénticas.

C_low

C_low: memoria contada como disponible para «Cabe»: memoria nominal menos la diferencia entre el valor nominal y el indicado de la tarjeta (D_card) y el mayor uso de arranque y de ejecución en los registros públicos del perfil (U), redondeado hacia abajo a un múltiplo de 64 MiB.

C_high

C_high: la memoria nominal completa, usada para «No cabe».

B, R, R_KV

B: ancho de banda de memoria (bytes por segundo); R: bytes de pesos leídos por cada token generado (tensores no expertos más la parte de los expertos en uso); R_KV: bytes de KV cache leídos por token.

Constantes

Los pesos no se estiman a partir del número de parámetros: se leen los archivos GGUF de cada cuantización (cabecera y tabla de tensores) en una revisión fijada, y se suman los bytes de cada capa. Los tensores que llama.cpp mantiene en la memoria del sistema (embeddings de entrada) se excluyen.

Cabe, al límite o no cabe

«Cabe» significa solo esto: la comprobación de carga predeterminada --fit de llama.cpp colocaría todas las capas en la GPU. llama.cpp realiza esa comprobación al cargar un modelo (los búferes estimados más una reserva de 1 GiB por tarjeta no deben superar la memoria libre al iniciar); este sitio la recalcula con las mismas reglas de búferes y deja margen para los errores de estimación. No garantiza que la memoria máxima durante la inferencia (reservas de memoria, entradas largas y otras asignaciones en tiempo de ejecución) quepa.

Las pruebas de referencia permiten que la estimación sea hasta un 5% demasiado baja y hasta un 10% demasiado alta, por lo que cada lado de la decisión usa su propio límite:

• Cabe cuando, en cada tarjeta, Q⁺ ÷ 0,95 + 1 GiB no supera C_low. Q⁺ supone 4 secuencias paralelas.
• No cabe cuando Q⁻ ÷ 1,10 supera la memoria completa C_high (con varias tarjetas: la suma de todas las tarjetas frente a N × C_high, porque el --fit predeterminado ajusta el reparto por sí mismo).
• Al límite en un punto intermedio: puede que quepa o no. Reduzca la longitud de contexto o use una cuantización menor.
• Desconocido cuando ningún perfil de ejecución cubre el dispositivo, para GPUs de estación de trabajo y de centro de datos (su configuración de memoria no se establece con registros públicos), o cuando la memoria contada como disponible es inferior a 2 GiB: solo se muestra X, y «No cabe» si el modelo es demasiado grande incluso para la memoria completa.

X = el mayor Q⁺ por tarjeta ÷ 0,95 + 1 GiB es la memoria disponible necesaria para «Cabe». Las páginas lo expresan como «Memoria disponible necesaria para Cabe», y no como «al menos», porque un resultado al límite necesita la misma cantidad.

Las tablas comprueban las cuantizaciones de mayor a menor con la longitud de contexto predeterminada. Una fila muestra la mayor cuantización que cabe (con X, la mayor longitud de contexto y el límite superior de velocidad), o, si ninguna cabe, la mayor que queda al límite (con X), o, si todas son demasiado grandes, la menor cuantización con su X.

La mayor longitud de contexto se busca entre la longitud de contexto predeterminada y el menor valor entre el máximo del modelo y la mayor longitud de contexto cubierta por registros medidos (262.144 celdas en una tarjeta, 131.072 en varias). Si aun así cabe, las páginas muestran «≥» ese valor: no se comprobaron longitudes mayores.

Solo se consideran varias tarjetas idénticas cuando una sola tarjeta no cabe, únicamente para GPUs de escritorio, de estación de trabajo y de centro de datos con perfil de ejecución, y cada cantidad de 2 a 8 se comprueba por separado (añadir una tarjeta no siempre reduce la carga de la tarjeta más cargada, y el paralelismo por canalización añade 4 copias de las entradas de capa). La página indica la menor cantidad que cabe con el reparto uniforme predeterminado; no es un mínimo, porque el --fit predeterminado puede ajustar el reparto y podría bastar con menos tarjetas. Las GPUs de estación de trabajo y de centro de datos, y las GPUs con menos de 2 GiB contados como disponibles, solo obtienen «No cabe ni con 8 tarjetas» (o ninguna cantidad).

Perfiles de ejecución

La cantidad de memoria que se considera disponible proviene únicamente de registros públicos de llama.cpp: el total que informa cada dispositivo, la memoria libre cuando se ejecuta la comprobación --fit de llama.cpp y, donde se imprime, la memoria no contabilizada tras una ejecución. D_card = nominal − total informado de ese modelo de GPU (el mayor si hay varios registros); U = el mayor valor entre total − libre en la comprobación --fit y la memoria no contabilizada positiva tras una ejecución, entre todas las observaciones válidas del perfil. Cuando un registro solo tiene una lectura de la lista de dispositivos, se añade la mayor diferencia entre la lista y la comprobación observada en el perfil. Se excluyen las observaciones en las que hay una pantalla conectada, otros programas ya usaban la GPU, la memoria libre supera el total, o un servidor compartido añade un uso ajeno. Un perfil sin suficientes observaciones no da veredictos.

Las GPUs de consumo sin una medición propia usan la mayor diferencia entre el total nominal y el informado medida en tarjetas de consumo y de estación de trabajo, en la configuración predeterminada. Las GPUs de estación de trabajo y de centro de datos no reciben ni «Cabe» ni «Al límite», estén medidas o no, porque los registros públicos no muestran su configuración de memoria (por ejemplo, si ECC está activado): son «Desconocido» salvo que el modelo sea demasiado grande incluso para la memoria completa, y para varias tarjetas solo se indica «No cabe ni en 8 tarjetas». Las GPUs de portátiles, Apple Silicon y otros equipos de memoria unificada no tienen perfil en esta versión.

CUDA (NVIDIA)

llama.cpp, motor de ejecución CUDA (GPU discreta NVIDIA), todas las capas en la GPU, Flash Attention activado, micro-lote (-ub) 512, KV cache F16, contexto (-c) según se indica; «Cabe» se determina con las 4 secuencias paralelas predeterminadas de llama-server (-np auto, KV cache unificada) y «No cabe» con 1 secuencia; GPU inactiva, sin otros programas que usen su memoria.

U = 2112 MiB; D para GPUs de escritorio sin medición propia = 1054 MiB.

Memoria sin contabilizar tras una ejecución en estos registros: 236–2050 MiB (4 observaciones). Las asignaciones en tiempo de ejecución no forman parte de «Cabe»; U las incluye solo como margen adicional, no como límite superior.

D_card: memoria nominal menos el total que llama.cpp informó para ese 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	2098
NVIDIA RTX A4000	410
NVIDIA RTX PRO 6000 Blackwell Workstation Edition	1054

Observaciones de registros públicos de llama.cpp, con las líneas de registro citadas.

Dispositivo	Motor de ejecución	Compilación	Nominal	Total informado (MiB)	Libre al inicio (MiB)	Usado antes de la carga (MiB)	Sin contabilizar tras la ejecución (MiB)	Fuente
NVIDIA GeForce RTX 3090 (x2, CUDA0)	CUDA	b11415	24 GB	24.575	23.054	1522	—	llama.cpp issues/29811 Líneas de registro 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	1575	—	llama.cpp issues/27680 Líneas de registro 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 Líneas de registro 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 Líneas de registro 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 Líneas de registro 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 Líneas de registro 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 Líneas de registro 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	2050	2050	llama.cpp issues/20308 Líneas de registro 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	1910	1910	llama.cpp issues/20308 Líneas de registro 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 Líneas de registro 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	7708	7573	187	—	llama.cpp issues/21984 Líneas de registro 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	1198	—	llama.cpp issues/27892 Líneas de registro 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	1260	—	llama.cpp issues/28167 Líneas de registro 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 Líneas de registro 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 Líneas de registro 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 Líneas de registro 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 Líneas de registro 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, motor Vulkan (GPU discreta Intel), todas las capas en la GPU, Flash Attention activado, micro-lote (-ub) 512, KV cache F16, contexto (-c) como se indica; «cabe» se evalúa con 4 secuencias paralelas y «no cabe» con 1 secuencia; GPU inactiva. Todavía no hay suficientes mediciones públicas, por lo que ningún veredicto usa este perfil.

U = 832 MiB; D para GPUs de escritorio sin medición propia = 0 MiB.

D_card: memoria nominal menos el total que llama.cpp informó para ese modelo de GPU (MiB).

GPU	D_card (MiB)
Intel Arc Pro B70	138

Observaciones de registros públicos de llama.cpp, con las líneas de registro citadas.

Dispositivo	Motor de ejecución	Compilación	Nominal	Total informado (MiB)	Libre al inicio (MiB)	Usado antes de la carga (MiB)	Sin contabilizar tras la ejecución (MiB)	Fuente
Intel Arc Pro B70	Vulkan	build_info: b8871-7fc1c4ef7	32 GB	32.630	31.861	769	—	llama.cpp issues/22275 Líneas de registro 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 en Linux (AMD)

llama.cpp, motor ROCm en Linux (GPU discreta AMD), todas las capas en la GPU, Flash Attention activado, micro-lote (-ub) 512, KV cache F16, contexto (-c) como se indica; «cabe» se evalúa con las 4 secuencias paralelas predeterminadas de llama-server (-np auto, KV cache unificada) y «no cabe» con 1 secuencia; GPU inactiva, sin otros programas que usen su memoria.

U = 1216 MiB; D para GPUs de escritorio sin medición propia = 144 MiB.

Memoria sin contabilizar tras una ejecución en este registro: 279 MiB (1 observación). Las asignaciones en tiempo de ejecución no forman parte de «Cabe»; U las incluye solo como margen adicional, no como límite superior.

D_card: memoria nominal menos el total que llama.cpp informó para ese 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

Observaciones de registros públicos de llama.cpp, con las líneas de registro citadas.

Dispositivo	Motor de ejecución	Compilación	Nominal	Total informado (MiB)	Libre al inicio (MiB)	Usado antes de la carga (MiB)	Sin contabilizar tras la ejecución (MiB)	Fuente
AMD Radeon RX 7900 XTX	ROCm	version: 9744 (063d9c1)	24 GB	24.560	24.494	266	—	llama.cpp issues/24858 Líneas de registro [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 Líneas de registro 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	1135	—	llama.cpp issues/23934 Líneas de registro 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	1135	—	llama.cpp issues/27021 Líneas de registro - 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	1175	—	llama.cpp issues/26208 Líneas de registro 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	1171	—	llama.cpp issues/26208 Líneas de registro [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	1115	—	llama.cpp issues/25487 Líneas de registro 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 Líneas de registro | - 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 Líneas de registro 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	1111	—	llama.cpp issues/25594 Líneas de registro 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 Líneas de registro 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

Pruebas de referencia

Cada caso es un registro público de llama.cpp que muestra los buffers por dispositivo. Se leen los archivos GGUF de ese registro, se recalculan los buffers por tarjeta con el contexto, las secuencias, el micro-lote y el tipo de KV del propio registro, y se comparan con modelo + KV + RS + cómputo de la misma tarjeta. 38 casos (50 tarjetas) se ejecutan como pruebas automáticas en cada compilación y deben mantenerse entre −5% y +10%; el mayor error es +8,85%.

Registros excluidos y por qué

• E04: Flash Attention estaba desactivado; este sitio modela Flash Attention activado.
• E09: Ejecutado con --swa-full, una caché de ventana deslizante que no es la predeterminada.
• E16: Varias secuencias sin una KV cache unificada; esa disposición de la caché no está modelada.
• E32: Flash Attention estaba desactivado; este sitio modela Flash Attention activado.
• E34: Flash Attention estaba desactivado; este sitio modela Flash Attention activado.
• E42: Flash Attention estaba desactivado; este sitio modela Flash Attention activado.

Reglas de llama.cpp por arquitectura

La forma en que cada arquitectura organiza su KV cache y su estado se ha transcrito del código fuente de llama.cpp en el commit 5aeac37a35.

Fuentes y cómo se verifican las especificaciones

• Nunca se consultan los sitios web de los fabricantes, porque sus términos prohíben el acceso automatizado. La especificación del fabricante procede de conjuntos de datos abiertos que enlazan una hoja de especificaciones del fabricante fila por fila (GetDeploying y Epoch AI, cuando la hoja está en un dominio del fabricante o en un servidor de documentos que el propio fabricante usa para sus hojas de especificaciones) y de la documentación de ROCm de AMD. Esos enlaces a hojas de especificaciones se muestran como «referencia del fabricante», marcados como no consultados por este sitio. Los enlaces a hojas de especificaciones se consideran del fabricante cuando están en alguno de estos dominios (incluidos los servidores de documentos que usan los fabricantes): amd.com, apple.com, dam-cdn.nvd.orangelogic.com, geforce.com, intel.com, nvdam.widen.net, nvidia.com
• Wikipedia se usa como verificación cruzada independiente. Sus notas al pie no se usan como fuente de un valor, porque las notas al pie de columnas y nombres de producto no muestran de dónde procede un campo concreto.
• El voto de la especificación del fabricante y el voto de contraste deben provenir de editores distintos sin referencia entre ellos: si la página de Wikipedia (o la fila del conjunto de datos) que contrasta cita al otro editor, cuenta como derivada, no como un segundo voto. Una fuente que copia a otra sin decirlo no puede detectarse a partir de evidencia pública.
• Se muestra un valor (two_source) cuando un voto de especificación del fabricante y una verificación cruzada independiente coinciden y ninguna fuente en buen estado discrepa. En caso contrario, el estado es «conflicto» (las fuentes discrepan), «fuente única» (sin voto de especificación del fabricante o sin verificación cruzada independiente) o «sin datos».
• Las filas que un conjunto de datos abierto atribuye a TechPowerUp (filas de Epoch AI cuyo enlace de la hoja de datos apunta a techpowerup.com) no se leen en absoluto, porque los términos de TechPowerUp prohíben los conjuntos de datos derivados: no votan ni cuentan como desacuerdo.
• Coincidir significa: tamaño de memoria exactamente igual, ancho de banda dentro del 1 %, otros números dentro del 2 %, texto igual tras la normalización.
• El valor mostrado es el que dan exactamente más fuentes coincidentes; junto a él se indican la cifra y el enlace de cada fuente. Los enlaces de Wikipedia apuntan a la revisión exacta utilizada.
• Los equipos con Apple Silicon, DGX Spark y Strix Halo no se publican en esta versión: ninguna fuente abierta enlaza una hoja de datos del fabricante para ellos fila por fila.
• Los datos de los modelos provienen de Hugging Face en revisiones fijadas. Cada modelo usa un único repositorio GGUF para todas sus cuantizaciones, elegido según un orden fijo de editores; la arquitectura se lee de la cabecera GGUF y, cuando el config.json original es legible, se contrasta con él.
• Los pesos originales, mostrados solo como referencia, cuentan los archivos safetensors del repositorio en el nivel superior y en las carpetas model*: con un model.safetensors.index.json, los archivos que este nombra más los conjuntos completos de otras carpetas model*; sin él, todos los conjuntos completos, contando una sola vez un archivo unificado y una copia fragmentada idéntica. No se cuentan otras carpetas (por ejemplo, decodificadores almacenados por separado), original/, los archivos consolidated*, los adaptadores LoRA ni los archivos .bin / .pt. Cuando los archivos no forman un único conjunto inequívoco, no se indica ningún tamaño.

Recuento de parámetros

Los parámetros se cuentan a partir de la tabla de tensores GGUF del archivo GGUF elegido: todos los tensores que carga llama.cpp, incluida la tabla de embedding de entrada. No se cuentan las capas de predicción de múltiples tokens (MTP / NextN), que llama.cpp no carga por defecto; las páginas de los modelos que las tienen indican cuántas son. Los parámetros activos por token cuentan los tensores que no son de expertos más los expertos en uso (expertos usados ÷ expertos por capa), pero no la búsqueda en el embedding de entrada, porque por cada token solo se lee una fila. Cuando un modelo usa una misma matriz como embedding de entrada y como capa de salida (embeddings compartidos), cada token se multiplica por toda ella, por lo que se cuenta una sola vez, como capa de salida. Las fichas de los modelos suelen contar también la tabla de embedding de entrada y las capas MTP, por lo que sus cifras pueden ser notablemente mayores, sobre todo en modelos de mezcla de expertos pequeños con vocabularios grandes. El recuento propio del repositorio original se muestra por separado.

Los parámetros activos solo se indican para los modelos de mezcla de expertos, es decir, aquellos cuya cabecera GGUF indica más de un experto por capa. Un modelo con un solo experto por capa (número de expertos 1) es denso: se usan todos los parámetros para cada token, por lo que no se muestra una cifra de parámetros activos aparte.

El recuento propio del repositorio original es el total que Hugging Face informa para sus pesos safetensors; algunos repositorios lo indican de forma incorrecta en sus metadatos. Solo se muestra, y solo se incluye en las descargas, cuando está confirmado: debe ser superior a 100M parámetros, estar dentro del 1% de los recuentos de parámetros por tipo que Hugging Face lee de los archivos de pesos del repositorio y, para los modelos con un archivo GGUF, estar entre 0,5 y 2,5 veces el recuento del GGUF (el original también puede contener un codificador de visión o de audio, o capas de predicción de múltiples tokens; el GGUF puede ser mayor cuando almacena por segunda vez un embedding compartido como su capa de salida). Los modelos sin archivo GGUF necesitan cumplir las dos primeras comprobaciones. De lo contrario, el recuento se omite.

Qué muestra cada estado

Límite de velocidad

Generar un token lee una vez los pesos activos y la KV cache, por lo que los tokens por segundo no pueden superar el ancho de banda dividido entre los bytes leídos por token. En los modelos de mezcla de expertos solo se cuenta la proporción de expertos en uso, a partir de la tabla de tensores GGUF. Es un límite superior teórico; no se indica ninguna velocidad cuando el ancho de banda no está confirmado por dos fuentes.

Pruebas de rendimiento públicas

Velocidades medidas de llama.cpp publicadas por el proyecto llama.cpp en su repositorio (llama-bench, en el commit fijado de llama.cpp). Las máquinas de estas notas (DGX Spark, Apple M2 Ultra) no reciben veredictos en este sitio en esta versión; las cifras muestran cómo se compara la velocidad medida con el límite superior de ancho de banda y cómo disminuye a medida que crece el contexto: llama.cpp benches/ (5aeac37a)

Macs y otros equipos con memoria unificada

Estos equipos permiten que la GPU use solo una parte de su memoria, y las fuentes abiertas disponibles para ellos no citan referencias por cada valor. No se publican en esta versión; los perfiles de ejecución para ellos se conservan para cuando las fuentes lo permitan.

Unidades

Las cantidades de memoria calculadas aquí están en GiB (1.073.741.824 bytes). Los "24 GB" de memoria de vídeo de los fabricantes de GPU son 24 GiB. Hugging Face muestra el tamaño de los archivos en GB decimales, por lo que un archivo de 5.03 GB aparece aquí como 4.68 GiB. El ancho de banda está en GB/s (10⁹ bytes por segundo).

Actualizaciones

Hugging Face se analiza cada 6 horas en busca de nuevos modelos y nuevos archivos GGUF; las especificaciones de las GPU se vuelven a verificar a diario.