Guía de cuantización de LLM: 7 métodos comparados (con los números de benchmark)

Guía de cuantización de LLM: 7 métodos comparados (con los números de benchmark)

Llama 3.3 70B en FP16 necesita 140 GB solo para los pesos. Dos H100. En Q4_K_M, el mismo modelo cabe en unos 42 GB, es decir, una RTX A6000 usada comprada en eBay. Esa brecha es la razón de ser de la cuantización de LLM, y elegir el método equivocado te cuesta calidad que puedes ver o VRAM que no tienes.

Esta guía de cuantización de LLM compara los 7 métodos que importan en 2026, con cada cifra rastreada hasta una fuente publicada.

Conclusiones clave

• La cuantización cambia memoria y ancho de banda por una pérdida de calidad medible y, por lo general, pequeña.
• GPTQ y AWQ son ante todo para GPU; GGUF es el formato que también corre en CPU.
• Q4_K_M ronda los 4,8 bits por peso, no 4. El nombre esconde la sobrecarga.
• La cuantización de 6 bits queda a ~0,1% de la perplejidad de FP16, según el PR de k-quants de llama.cpp.

¿Qué le hace realmente la cuantización de LLM a tu modelo?

La cuantización de LLM almacena los pesos del modelo con una precisión numérica menor, reduciendo memoria y ancho de banda a costa de error de redondeo. Un modelo de 70B parámetros baja de 140 GB en FP16 a unos 42 GB en 4 bits. La inteligencia se queda; los decimales se van. Cada método de esta guía es una variante de ese intercambio.

La escalera de precisión va de FP32 (32 bits) hacia abajo, pasando por FP16 y BF16 (16 bits cada uno), luego INT8 y luego INT4. Cada peldaño reduce a la mitad los bytes por parámetro. El estándar IEEE 754 define los formatos de coma flotante; el artículo de Mark Horowitz de 2014, "Computing's Energy Problem", demostró por qué mover esos bytes, y no la aritmética sobre ellos, domina el coste energético. Esa es la razón física de que la cuantización acelere la inferencia.

Dos parámetros hacen funcionar la cuantización: un factor de escala (un multiplicador que devuelve el rango de enteros a valores reales) y un punto cero (el entero que representa 0,0). La cuantización simétrica centra el rango en cero y prescinde del punto cero; la cuantización asimétrica lo desplaza para usar el rango completo de enteros cuando los pesos se agrupan lejos del cero.

Los pesos se cuantizan bien porque son estáticos y tienen distribución normal. Las activaciones, no. Las activaciones atípicas, a veces 100 veces la mediana, disparan el error de redondeo si las cuantizas sin más. Esa asimetría explica por qué la mayoría de los métodos de aquí cuantizan solo los pesos (W4A16) y dejan las activaciones en FP16.

La cuantización post-entrenamiento (PTQ) convierte un modelo terminado después del entrenamiento. El entrenamiento consciente de la cuantización (QAT) simula el redondeo durante el entrenamiento para que el modelo se adapte. Todo lo de este artículo es PTQ. QAT cuesta más cómputo y una ejecución de entrenamiento; es otra decisión.

Las filas INT4 y NF4 son 4 bits puros teóricos: 4 bits por peso y nada más. Los formatos reales de 4 bits cargan además escalas y mínimos de bloque, así que quedan más arriba. Un modelo 70B en Q4_K_M ocupa unos 42 GB, no 35. La tabla de VRAM más abajo usa las tasas efectivas.

La cuantización no encoge la inteligencia del modelo. Encoge la cantidad de decimales en los que guarda esa inteligencia. Y si pagas por token en inferencia de API, reducir tu factura de API de LLM muchas veces empieza por correr tú mismo un modelo cuantizado.

Los 7 métodos de cuantización, cara a cara

Los siete métodos de abajo cubren todas las vías de producción para cuantizar un LLM en 2026. Dos son solo para GPU (GPTQ, AWQ), uno corre en cualquier parte (GGUF), uno cuantiza en el momento de carga (BitsandBytes), dos apuntan al servicio de alto rendimiento (SmoothQuant, FP8) y uno es nativo de PyTorch (TorchAO). La elección correcta depende de tu hardware, no de qué método puntúa más alto en un ranking.

GPTQ cuantiza capa por capa usando el hessiano inverso para redistribuir el error de redondeo entre los pesos restantes. Necesita un conjunto de calibración y una GPU. El artículo de GPTQ reporta cuantizar un modelo 175B a 3-4 bits en unas 4 GPU-horas.

AWQ identifica el ~1% de los pesos que más importan (los pesos salientes, detectados por la magnitud de las activaciones) y los escala para protegerlos del redondeo. El artículo de AWQ (mejor artículo de MLSys 2024) reporta más de 3x de aceleración frente a la implementación FP16 de HuggingFace, tanto en GPU de escritorio como móviles.

GGUF es un formato de archivo, no un algoritmo. El algoritmo que lleva dentro es el esquema de bloques k-quant del PR #1684 de llama.cpp. Es el único método de esta lista que corre en CPU, lo que lo convierte en el predeterminado para inferencia local. Mira los modelos de pesos abiertos que vale la pena cuantizar para saber qué darle de comer.

BitsandBytes cuantiza en la carga, no antes. NF4 (NormalFloat de 4 bits) es su formato insignia y es la columna vertebral del fine-tuning con QLoRA. No necesita conjunto de calibración.

SmoothQuant migra los valores atípicos de las activaciones a los pesos para que ambos puedan correr en INT8. El artículo reporta hasta 1,56x de aceleración y 2x de reducción de memoria, y apunta al rendimiento en servicio con lotes grandes, donde los métodos W4A16 dejan throughput sobre la mesa.

FP8 (W8A8) es la vía nativa en GPU H100 y B200. Casi sin pérdida a 8 bits, sin dolores de cabeza de calibración, y vLLM lo admite directamente.

TorchAO es la biblioteca de cuantización del propio PyTorch, construida para funcionar con torch.compile. Si tu pipeline ya es PyTorch, es el camino de menor resistencia.

Solo hay dos preguntas de verdad: ¿tu hardware lo corre? ¿y puedes vivir con la calidad que cuesta?

¿Qué muestran realmente los benchmarks publicados?

Los benchmarks publicados dicen que la cuantización a 4 bits cuesta 1-2% de perplejidad en un modelo 7B, y que a 6 bits cuesta menos de 0,1%. Esas cifras vienen del PR #1684 de llama.cpp (2023), medidas por los mantenedores de llama.cpp sobre un único modelo 7B en una RTX 4080. Son los números más citados del mundo de la cuantización y son reales. También son n = 1.

Fuente: PR #1684 de llama.cpp (2023). Modelo 7B, RTX 4080, medido por los mantenedores de llama.cpp. n = 1 modelo.

Una nota sobre la columna de bits/peso: esas son las tasas nominales del tipo k-quant base, y las mezclas _K elevan la tasa efectiva. Q2_K es un buen ejemplo. Aplica la fórmula del propio artículo sobre el 2,5625 nominal y un modelo de 6,74B parámetros y obtienes ~2,0 GB, pero la fila reporta un archivo de 2,67 GB, que despejado hacia atrás da ~3,4 bits por peso. El resto de este artículo usa las tasas efectivas, derivadas de estos tamaños de archivo.

Los números de los métodos GPU vienen directamente de los artículos. GPTQ reporta aceleraciones de inferencia de punta a punta frente a FP16 de aproximadamente 3,25x en una A100 y ~4,5x en una A6000, con un modelo 175B cuantizado a 3-4 bits en unas 4 GPU-horas. AWQ reporta «más de 3x de aceleración frente a la implementación FP16 de HuggingFace, tanto en GPU de escritorio como móviles», además del primer despliegue de Llama-2 70B en una GPU móvil vía TinyChat. Citamos la redacción del artículo en lugar de parafrasear un número con falsa precisión.

La contribución original aquí es aritmética. La memoria para los pesos sigue: pesos (GB) ≈ parám. (B) × bits por peso ÷ 8. La trampa está en qué cifra de bits por peso le metes. El PR #1684 publica la tasa del tipo k-quant base (Q4_K = 4,5), y las mezclas _S/_M/_L se sitúan por encima de esa tasa base porque dan bits extra a los tensores de atención y feed-forward. Así que derivamos las tasas efectivas de los tamaños de archivo que el propio PR publica, sobre un modelo 7B que en realidad tiene 6,74B parámetros: Q2_K con 2,67 GB despeja a ~3,4 bpw, Q4_K_S con 3,56 GB a ~4,5, Q6_K con 5,15 GB a ~6,6. Q4_K_M ronda los 4,8.

Eso cambia el número de titular. Un modelo 70B en Q4_K_M: 70 × 4,8 ÷ 8 = 42 GB. La mayoría de los artículos dicen 35 GB. Usan 4,0 bpw y se saltan por completo la sobrecarga de las escalas de bloque. La comprobación cuesta un clic: Llama-3.3-70B-Instruct-Q4_K_M.gguf pesa 42,5 GB en HuggingFace, igual en los repos de bartowski, lmstudio-community y second-state. Recalculamos cada celda de la tabla de VRAM de abajo con esa base.

Nuestra lectura de estos números: la brecha de perplejidad entre Q6_K (5,9110) y F16 (5,9066) es 0,0044, menor que la brecha entre dos fine-tunes distintos del mismo modelo base. Por eso «usa Q4_K_M o Q5_K_M y ya» es el consejo que sobrevive al contacto con hardware real. La columna de ms/token también muestra que Q2_K no compra velocidad sobre Q4_K_S (ambos a 15,5 ms/token) mientras cuesta 0,75 de perplejidad. Q2_K es el peor intercambio de la tabla.

Lo que los números no te dicen: la perplejidad en wikitext no equivale a calidad en tus prompts. Un modelo en una GPU es n = 1. Las cifras de velocidad dependen del tamaño de lote. Trátalas como orientativas, no universales.

La cuantización a 6 bits queda a un 0,1% de la perplejidad del modelo en precisión completa. A ese nivel, la compresión es casi gratis.

GPTQ vs AWQ: elegir entre los dos métodos GPU

GPTQ y AWQ producen checkpoints de 4 bits para GPU a partir de un conjunto de calibración, y ambos están bien soportados en vLLM. La diferencia está en cómo tratan el error de redondeo. GPTQ lo redistribuye entre los pesos restantes usando el hessiano inverso. AWQ protege el 1% de los pesos que las activaciones señalan como importantes. Ambos funcionan. La elección va sobre tu patrón de servicio.

GPTQ trabaja capa por capa. Para cada capa, cuantiza un peso a la vez y luego ajusta los pesos restantes de esa capa para compensar el redondeo que acaba de hacer. El ajuste usa información de segundo orden de la matriz hessiana, razón por la que necesita un conjunto de calibración para calcularse. El resultado es sólido para inferencia por lotes, donde el throughput importa más que la latencia por token.

AWQ toma otro ángulo. Identifica los pesos salientes mirando las magnitudes de activación en el conjunto de calibración, aproximadamente el 1% superior de los canales. Esos pesos reciben un factor de escala por canal que los mantiene en un rango de mayor precisión durante el redondeo. El conjunto de calibración puede ser más pequeño que el de GPTQ, y AWQ se sobreajusta menos a él porque protege rasgos estructurales en lugar de ajustarse a entradas concretas. El artículo reporta resultados sólidos en servicio sensible a latencia.

Elige GPTQ si: haces inferencia por lotes en una GPU, tienes un buen conjunto de calibración que encaja con tu dominio y la métrica es el throughput.

Elige AWQ si: sirves peticiones de un solo usuario con baja latencia, quieres un conjunto de calibración más pequeño o despliegas en GPU de edge/móviles.

# Serve a published AWQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-AWQ \
  --quantization awq \
  --max-model-len 4096

# Serve a published GPTQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-GPTQ \
  --quantization gptq \
  --max-model-len 4096

Si también estás eligiendo entre motores de servicio, vLLM contra SGLang cubre esa decisión por separado.

GGUF y K-Quants: qué significa realmente Q4_K_M

GGUF es un formato de archivo, no un algoritmo de cuantización. La especificación GGUF define un contenedor para pesos del modelo, metadatos y datos del tokenizador. El algoritmo de cuantización dentro de un archivo GGUF es el esquema de bloques k-quant (o i-quant) del PR #1684 de llama.cpp. Confundir el contenedor con el algoritmo es el error más común en este terreno, y lleva a preguntas como «¿cuál es mejor, GGUF o GPTQ?» que no terminan de tener sentido.

El esquema de nombres se descifra así. Q significa esquema de bloques k-quant; IQ significa i-quant con matriz de importancia (una variante más nueva que usa una matriz de importancia para lograr mejor calidad con la misma profundidad de bits). El número es la profundidad de bits nominal. _K marca la familia k-quant frente a formatos heredados como Q4_0. _S, _M, _L controlan qué grupos de tensores reciben bits extra: small, medium, large. Un sufijo más alto significa más bits para los tensores de atención y feed-forward que más importan.

Tasas efectivas, despejadas hacia atrás desde los tamaños de archivo del 7B (6,74B parámetros) publicados en el PR #1684, no de las cifras del tipo base. Las filas heredadas son exactas por construcción: un bloque Q4_0 son 32 pesos a 4 bits más una escala FP16, es decir, 4,5 bits por peso, y Q8_0 son 32 pesos a 8 bits más una escala FP16, es decir, 8,5. El PR lo corrobora: lista los archivos 7B Q4_0 y Q4_K_S con los mismos 3,56 GB.

Q4_K_M no son 4 bits por peso. Son unos 4,8. Las escalas y mínimos de bloque tienen que vivir en algún sitio, y la mezcla _M gasta luego bits extra en los tensores de atención y feed-forward, que es exactamente por lo que Q4_K_M queda por encima de Q4_K_S y Q3_K_M queda por encima de Q3_K_S en lugar de igualarlo.

Por qué GGUF corre donde GPTQ no puede: admite inferencia en CPU y offload de capas entre la VRAM de la GPU y la RAM del sistema. Un modelo 32B que no cabe entero en tu GPU puede correr con la mitad de sus capas fuera, lento pero funcional. GPTQ no tiene vía de CPU.

# Pull a specific quant tag with Ollama
ollama run llama3.1:8b-instruct-q4_K_M

# Convert an F16 GGUF to Q4_K_M with llama.cpp
llama-quantize model-f16.gguf model-q4_k_m.gguf Q4_K_M

¿Nuevo en los modelos locales? Empieza por poner en marcha tu primer modelo local antes de cuantizar nada. Y si quieres una interfaz en el navegador, Open WebUI sobre Ollama toma unos diez minutos. La documentación GGUF de HuggingFace explica cómo expone el Hub los nombres de los tipos de quant.

BitsandBytes, Marlin, SmoothQuant y TorchAO

Estos cuatro cubren las vías de producción restantes. Ninguno es «un GPTQ mejor». Resuelven problemas distintos.

BitsandBytes cuantiza en el momento de carga, no antes. Lo apuntas a un checkpoint FP16 y convierte sobre la marcha a NF4 o FP4. Sin conjunto de calibración, sin paso offline. Su mayor claim a la fama es QLoRA: un modelo base congelado de 4 bits con adaptadores LoRA entrenados encima, que hace posible el fine-tuning de un modelo 65B en una sola GPU con 48 GB de VRAM. QLoRA es una técnica de entrenamiento, no de inferencia, pero es la razón por la que la mayoría conoce BitsandBytes primero.

Marlin no es un método de cuantización. Es un kernel GEMM de precisión mixta INT4xFP16 que hace más rápidos los checkpoints de 4 bits existentes con tamaños de lote moderados. El artículo de Marlin reporta aceleraciones en A100 y H100. Si tu stack de servicio lo admite, lo activas sobre un modelo ya cuantizado. No «cuantizas con Marlin».

SmoothQuant desplaza los atípicos de las activaciones hacia los pesos mediante un factor de escala por canal, haciendo viable W8A8 (pesos y activaciones, ambos en INT8). El artículo apunta al servicio con lotes grandes, donde los métodos W4A16 dejan throughput sobre la mesa. Si sirves cientos de peticiones concurrentes, esta es la jugada.

TorchAO es cuantización nativa de PyTorch que funciona con torch.compile. Sin dependencias externas, sin conversión de formato. Si tu pipeline de inferencia ya es PyTorch, es la opción con menos fricción. Para ejecutar modelos de embeddings en local, la vía de Ollama suele ser más simple, pero TorchAO encaja en stacks PyTorch a medida.

¿Cuánta VRAM necesita un modelo cuantizado?

La fórmula es pesos (GB) ≈ parám. (B) × bits por peso ÷ 8. Un modelo 70B en Q4_K_M: 70 × 4,8 ÷ 8 = 42,0 GB. Las tasas de abajo son efectivas, despejadas hacia atrás desde los tamaños de archivo que publica el PR #1684 de llama.cpp, y no de los números del tipo base, porque las mezclas _M siempre corren por encima de su tasa k-quant base. Recalculamos en lugar de copiar el atajo habitual de 4,0 bpw.

Calculado a partir de bits por peso efectivos: Q8_0 = 8,5, Q6_K = 6,56, Q5_K_M = 5,7, Q4_K_M = 4,8, Q3_K_M = 3,9. Derivados de los tamaños de archivo del 7B (6,74B parámetros) del PR #1684 y luego cruzados con un build 70B publicado: Llama-3.3-70B-Instruct-Q4_K_M.gguf pesa 42,5 GB en HuggingFace, frente a los 42,0 GB predichos aquí.

La advertencia honesta: esto son solo los pesos. La caché KV, la longitud de contexto y la sobrecarga del framework se suman encima. La caché KV escala con la longitud de contexto y el tamaño de lote. Una sesión con contexto de 32k en un modelo 70B puede añadir varios GB. La tabla de pesos es el suelo, no el presupuesto. Tu ventana de contexto también alquila VRAM. Para la foto completa, mira los requisitos de VRAM por modelo en detalle.

¿Qué método de cuantización deberías usar?

Tu hardware decide antes que tus preferencias. Un método que no corre en tu GPU no es una opción, es un deseo. La tabla de abajo mapea configuraciones comunes al método que de verdad funciona para ellas, según las restricciones de hardware y los intercambios de calidad cubiertos arriba.

Para la mayoría de los lectores con hardware de consumo, un GGUF Q4_K_M o Q5_K_M precuantizado es la respuesta correcta. Bájalo de HuggingFace, córrelo en Ollama o llama.cpp y deja de optimizar. La diferencia de calidad entre Q4_K_M y Q5_K_M es lo bastante pequeña para que elijas según si el archivo cabe, no según una tabla de perplejidad. Todo lo que va más allá es optimizar por optimizar, y solo vale la pena cuando ya confirmaste que el modelo resuelve tu problema en Q4.

La guía de las herramientas que realmente ejecutan estos modelos en local cubre la parte del servicio una vez que elegiste un nivel de quant.

Cinco formas en que la cuantización sale mal

Los fallos de cuantización son casi siempre problemas de configuración, no del método. Estos cinco aparecen sin parar.

1. El conjunto de calibración no encaja con tu dominio. GPTQ y AWQ se ajustan ambos a los datos de calibración. Si calibras con Wikipedia y despliegas con transcripciones médicas, el modelo cuantizado rinde peor en los tokens que nunca vio. Solución: usa un conjunto de calibración sacado de tu distribución de entrada real; incluso 128 muestras ayudan.

2. Tamaño de grupo demasiado grande. El tamaño de grupo de GPTQ controla cuántos pesos comparten un factor de escala. 128 es el estándar. 256 o 512 ahorra cómputo durante la cuantización, pero choca con un acantilado de calidad en modelos pequeños. Solución: quédate en 128 a menos que hayas confirmado que la calidad aguanta en tus prompts.

3. Esperar que Q2_K sea usable. Según los datos del PR #1684, Q2_K cuesta ~0,87 de perplejidad frente a F16 y no compra velocidad sobre Q4_K_S (ambos a 15,5 ms/token en el benchmark 7B). Obtienes un archivo más pequeño y peor salida sin ganancia de latencia. Solución: Q4_K_S es el suelo a menos que el tamaño de archivo sea una restricción dura.

4. Medir con perplejidad en wikitext en lugar de con tus propios prompts. La perplejidad es una métrica de modelado de lenguaje. No mide si el modelo sigue tu system prompt, formatea JSON correctamente o maneja el vocabulario de tu dominio. Solución: pasa 20-30 de tus prompts reales por el modelo cuantizado y sin cuantizar y compara las salidas.

5. Confundir GGUF el contenedor con el algoritmo de cuantización que lleva dentro. Esto lleva a comparar «GGUF vs GPTQ» como si fueran la misma categoría. No lo son. GGUF es un formato de archivo. El esquema k-quant de su interior es el algoritmo. Solución: compara niveles k-quant (Q4_K_M vs Q5_K_M), no formatos de archivo.

Preguntas frecuentes

¿Qué es la cuantización de LLM?

La cuantización de LLM reduce la precisión numérica de los pesos de un modelo, normalmente de coma flotante de 16 bits a enteros de 4 u 8 bits. Esto recorta el uso de memoria y acelera la inferencia al reducir el ancho de banda. Un modelo 70B baja de 140 GB a unos 42 GB a 4 bits. El coste en calidad suele ser 1-2% de perplejidad a 4 bits, y menos a 6 bits.

¿La cuantización reduce la precisión de un modelo?

Sí, pero menos de lo que la mayoría espera. Según los benchmarks del PR #1684 de llama.cpp, Q4_K_S en un modelo 7B cuesta un 2% de perplejidad frente a F16, y Q6_K cuesta menos de 0,1%. El impacto práctico en prompts reales suele ser menor de lo que sugiere el número de perplejidad, sobre todo de Q4_K_M hacia arriba.

¿GPTQ o AWQ, cuál es mejor?

Ninguno es mejor en universal. GPTQ usa redistribución de error con hessiano inverso y encaja con inferencia por lotes en GPU. AWQ protege los pesos salientes mediante escalado consciente de las activaciones y encaja con servicio sensible a latencia. AWQ necesita un conjunto de calibración más pequeño y se sobreajusta menos a él. Si sirves peticiones de un solo usuario con baja latencia, empieza con AWQ.

¿Qué significa Q4_K_M?

Q4_K_M es un nivel de cuantización k-quant de GGUF. «Q4» significa profundidad nominal de 4 bits, «K» marca el esquema de bloques k-quant (frente al heredado Q4_0) y «M» significa medium: los tensores de atención y feed-forward reciben bits extra. Los bits por peso efectivos son unos 4,8, no 4,0, porque las escalas y mínimos de bloque añaden sobrecarga y la mezcla medium gasta más encima.

¿Puedo correr un modelo cuantizado en una CPU?

Sí, pero solo vía GGUF. GPTQ y AWQ son formatos solo para GPU. Los modelos k-quant de GGUF corren en CPU mediante llama.cpp u Ollama, y admiten offload de capas entre la VRAM de la GPU y la RAM del sistema. Q4_K_M es el quant estándar para CPU. Espera generación de tokens más lenta que en GPU, pero inferencia funcional.

¿Cuál es la diferencia entre GGUF y GGML?

GGML es la biblioteca de tensores y el formato de archivo más antiguos que llama.cpp usaba originalmente. GGUF lo reemplazó en agosto de 2023 como un formato contenedor más flexible, con mejor soporte de metadatos. Los archivos GGUF son los que descargas hoy de HuggingFace. Los archivos GGML son heredados y ya casi no se distribuyen.

¿Debería cuantizar un modelo yo mismo o descargar uno precuantizado?

Descarga primero uno precuantizado. Las comunidades de llama.cpp y HuggingFace ya han cuantizado la mayoría de los modelos populares en todos los niveles. Cuantizar tú mismo solo tiene sentido si necesitas un conjunto de calibración específico para tu dominio, o si no existe una versión precuantizada de tu modelo.

¿Cuándo debería usar cuantización en lugar de un modelo más pequeño?

Usa cuantización cuando necesitas la capacidad del modelo grande pero no cabe en memoria. Un modelo 70B cuantizado generalmente supera a un 13B sin cuantizar en tareas de razonamiento complejo. Usa un modelo más pequeño cuando la restricción es la latencia, ya que los modelos pequeños generan tokens más rápido independientemente de la cuantización.

¿Cuál es la diferencia entre cuantización y destilación?

La cuantización reduce la precisión numérica de los pesos de un modelo existente. La destilación entrena un modelo más pequeño para imitar a uno grande, produciendo una arquitectura genuinamente distinta (y más pequeña). La cuantización conserva la arquitectura del modelo original y es reversible en principio. La destilación crea un modelo nuevo y requiere una ejecución de entrenamiento.

La versión corta: la cuantización es cómo metes el modelo que quieres en el hardware que tienes. Para la mayoría en GPU de consumo o Apple Silicon, un GGUF Q4_K_M precuantizado bajado de HuggingFace es la solución completa. GPTQ y AWQ son las respuestas para servir en GPU. FP8 y SmoothQuant son las respuestas de throughput en producción. Todo lo demás es optimización después de confirmar que el modelo funciona.

Si estás decidiendo qué autoalojar y quieres una segunda opinión sobre el emparejamiento hardware-método, estaremos encantados de hablar.