Qué formato de cuantización ejecutar en la práctica.

Empiece aquí

La mayor parte de esta página es aritmética, así que aquí va antes la conclusión. Cuatro preguntas determinan el formato, y se plantean en este orden porque cada una puede zanjar la discusión por sí sola.

Todo lo que sigue explica por qué esas cuatro respuestas son las que son, y le da las cifras para comprobarlas con su propio modelo en vez del nuestro. Si todavía no ha calculado cuánta memoria necesita su modelo, esa aritmética está en otra guía y va primero.

Tres formatos, cuatro nombres

Solo hay tres formatos numéricos de uso común para servir modelos, y se diferencian en una sola cosa: cuántos bytes cuesta cada parámetro. Todo lo demás — AWQ, GPTQ, GGUF, bitsandbytes — es un método para producir uno de estos tres, no un cuarto formato.

Lea las dos columnas numéricas como un par. Son iguales en las dos primeras filas y no son iguales en la tercera, y esa única asimetría es responsable de la mayoría de las sorpresas del resto de esta página.

Los cuatro nombres que realmente se encontrará en un repositorio de modelos se corresponden con esa tabla de la siguiente manera.

Pedir cualquiera de ellos es un solo flag. Son las mismas opciones que usa con detalle la guía de vLLM; lo que importa aquí es solo lo pequeña que es la diferencia entre ellos.

# 1. Reference. The weights as published, nothing to prepare.
$ vllm serve meta-llama/Llama-3.3-70B-Instruct --dtype bfloat16

# 2. FP8, quantised while it loads. No second download, no calibration.
#    --kv-cache-dtype is the half everyone forgets: it is what
#    halves the CACHE as well as the weights.
$ vllm serve meta-llama/Llama-3.3-70B-Instruct \
    --quantization fp8 --kv-cache-dtype fp8

# 3. Four-bit AWQ. A DIFFERENT checkpoint, prepared by someone else.
$ vllm serve casperhansen/llama-3.3-70b-instruct-awq \
    --quantization awq_marlin

# 4. Four-bit GPTQ. Same idea, different repository and flag.
$ vllm serve TechxGenus/Llama-3.3-70B-Instruct-GPTQ \
    --quantization gptq_marlin

La mitad que no se reduce

Cuantizar los pesos a 4 bits no cuantiza la caché de clave/valor. AWQ y GPTQ comprimen los pesos, y solo los pesos; la caché se queda en 16 bits a menos que pida por separado una caché FP8, y en un checkpoint de 4 bits casi nadie lo hace. Esa es la tercera columna de la tabla de arriba, y es la razón por la que la aritmética de abajo no sale como nadie espera.

La consecuencia se ve más fácilmente en un solo modelo. Abajo está Llama 3.3 70B, en 4 bits, en cada longitud de contexto que ofrece el configurador — pesos frente a caché.

La columna de pesos nunca se mueve — ese es precisamente el sentido de cuantizarlos. La columna de caché crece linealmente con el contexto hasta que, en la última fila, es más grande que el modelo al que pertenece.

Llévelo lo bastante lejos y 4 bits deja de ganar por completo. FP8 reduce a la mitad las dos mitades; 4 bits reduce a una cuarta parte una mitad y deja la otra intacta. Así que para cada modelo hay una longitud de contexto en la que ambos se cruzan, y llega antes cuanto más pequeño es el modelo — porque un modelo pequeño tiene poco peso que ahorrar y el mismo crecimiento de caché por token.

Cifras en gigabytes, del más pequeño de los dos formatos, con el perdedor indicado debajo. Léalo de izquierda a derecha y observe cómo se va perdiendo la ventaja de la columna de 4 bits a medida que crece el contexto.

La última fila mantiene su ventaja en todos los casos, porque 70 mil millones de parámetros son muchísimo peso que ahorrar. La fila del medio termina en empate técnico: a 128k, Qwen 3 32B cuesta exactamente lo mismo en cualquiera de los dos formatos, y elegiría FP8 por la calidad. Y la primera fila se invierte por completo at 128k, donde 4 bits pide más memoria que FP8 y encima es el menos fiel de los dos. Esa combinación — más memoria y peor resultado — es el error de cuantización más común que vemos, y resulta invisible si solo se fija en el tamaño del archivo de pesos.

Lo que su tarjeta puede hacer realmente

FP8 es una característica de hardware antes que de software. Una tarjeta cuyos núcleos tensoriales no lo admitan cargará igualmente un checkpoint FP8 — la pila descomprime los pesos a 16 bits antes de la multiplicación — pero solo conserva el ahorro en la descarga y nada de la velocidad, y una caché FP8 no está disponible en absoluto. Cuatro bits es lo contrario: funciona en todas partes, porque los pesos se descomprimen a 16 bits antes del cálculo de todos modos.

Esa columna describe el silicio, lo cual no es exactamente la misma pregunta que dónde tiene sentido usar FP8. La propia nota del catálogo junto al formato menciona Hopper and Blackwell, y eso es una afirmación sobre las pilas de servicio, no sobre los núcleos tensoriales: son las generaciones en las que los kernels FP8 y las cachés FP8 han tenido más uso y menos sorpresas. Ada Lovelace lo ejecutará. Hopper y Blackwell son donde pondríamos un despliegue que dependa de ello.

Una cosa más que conviene saber antes de elegir tarjeta. Llama 3.3 70B en FP8 a 8k necesita 81.9 GB, y una tarjeta de 80 GB — entre otras, la NVIDIA A100 PCIe — se queda 1.9 GB corta. No lo bastante corta como para ser obvio en una hoja de cálculo, y sí lo bastante corta como para fallar en la máquina. La tarjeta que lo cubre por sí sola es la siguiente gama, y el configurador le dirá cuál es antes de pagar, no después.

Lo que se gana en velocidad

Generar un token significa leer los pesos activos de la memoria una vez. Menos bytes por peso significa menos bytes que leer, lo que significa más tokens por segundo — y en un único flujo sin procesamiento por lotes esa relación es casi lineal, porque no hay nada más que la tarjeta esté esperando. Es el mismo techo de ancho de banda de memoria por el que divide la guía de coste por token, y es deliberadamente conservador. Más abajo se aplica a un modelo lo bastante pequeño como para funcionar en cualquier máquina de una sola tarjeta que alquilamos, de modo que el formato y la tarjeta puedan leerse en la misma tabla.

Llama 3.1 8B en una tarjeta, un flujo cada vez. Todas las máquinas de la lista lo alojan en los tres formatos, así que las filas son comparables tanto en horizontal como en vertical — y la proporción entre las tres columnas es la misma en cada línea, porque la determinan los bytes por peso y nada más.

Dos advertencias sobre cómo leer esa tabla. La primera es que describe una solicitud a la vez, y casi nadie sirve una solicitud a la vez: con procesamiento continuo por lotes los pesos se leen una sola vez para todo el lote, así que el límite pasa a ser el cómputo y no la memoria, y la proporción entre las columnas se estrecha. La segunda es que descuantizar cuesta algo. Los pesos de 4 bits deben descomprimirse antes de multiplicarse, y en un modelo pequeño con un tamaño de lote bajo, esa descompresión puede comerse una parte visible de lo que ganó al leer menos. La dirección de la tabla es fiable; los múltiplos exactos no son una promesa.

Lo que le cuesta

Esta es la parte del tema en la que hay que desconfiar de las cifras seguras de sí mismas, incluidas las nuestras. El error de cuantización depende mucho más del modelo que del método, y las comparaciones publicadas se contradicen entre sí porque miden modelos distintos en tareas distintas. Lo que se puede afirmar con honestidad es la forma general que tiene.

Lo cual lleva a la única recomendación de esta página que no es aritmética: ejecute ambos. Está alquilando una máquina con acceso root y sin ningún contador, así que servir el mismo modelo dos veces en dos puertos, pasando sus propios cien prompts por cada uno, le cuesta una tarde y resuelve la cuestión para su carga de trabajo, y no para la de otra persona. Esa es una respuesta sustancialmente mejor que cualquier tabla, esta incluida — y es la razón por la que preferimos mostrarle la fórmula antes que una puntuación.

Qué máquina implica eso

La razón por la que todo esto importa es la factura. Abajo está la máquina más barata de nuestro catálogo que aloja cada modelo entero a 8k de contexto, en cada uno de los tres formatos — entero significa en una sola tarjeta, sin repartirlo, porque un modelo repartido entre tarjetas mete la interconexión en la ecuación, y eso es otra guía.

A 8k de contexto, en las máquinas que realmente alquilamos. Cuando una celda nombra varias tarjetas, es el nodo más pequeño en el que se vende esa tarjeta, no un modelo repartido: las tarjetas más grandes se venden de cuatro en cuatro y de ocho en ocho, así que la forma más barata de evitar repartir un 70B a precisión completa es comprar cuatro y usar una. Esa es exactamente la factura que la cuantización existe para evitar.

Dos hábitos marcan la diferencia entre usar bien esta tabla y dejarse sorprender por ella. Dimensione según el contexto que realmente va a ejecutar, no según el máximo del modelo — la segunda tabla de esta página es lo que les pasa a quienes confunden ambas cosas. Y compruebe el formato en la tarjeta antes de pedir, no después: NVIDIA RTX A6000, NVIDIA A100 PCIe y NVIDIA A100 SXM4 no puede darle las cifras de FP8 sea cual sea la opción que pase. El configurador indica la memoria necesaria y si cabe en una tarjeta, para cada nodo y cada formato, antes de pagar nada. Si lo que está sopesando es alquilar frente a pagar una API por token, ese punto de equilibrio se calcula aparte, y la cuantización lo desplaza en gran medida a favor del hardware.