GGUF vs GPTQ vs AWQ vs EXL2: qué formato de modelo LLM elegir según tu infraestructura (y cuánto te costará equivocarte)

Elegir mal el formato de cuantización de un modelo de lenguaje puede multiplicar por tres tu factura de inferencia o dejarte con un modelo inutilizable en el hardware que ya tienes pagado. No es un debate académico: es una decisión de arquitectura con consecuencias directas en presupuesto y time-to-production.

MarkTechPost publicó esta semana la guía comparativa más completa del momento sobre GGUF, GPTQ, AWQ, EXL2 y EXL3. La guía es técnicamente sólida, pero le falta el ángulo que le importa a un CTO: cuándo cada formato destruye o protege tu margen operativo.

Por qué la cuantización es la palanca de coste que más se ignora

Cuantizar un modelo significa reducir la precisión numérica de sus pesos: de float32 a int8, int4 o incluso int2 en los casos más agresivos. El resultado directo es un modelo más pequeño, que ocupa menos VRAM y ejecuta inferencia más rápida. El coste es una degradación controlada —o no tan controlada— de la calidad de respuesta.

Un modelo Llama 3.1 70B en float16 puro ocupa alrededor de 140 GB de VRAM. En Q4_K_M (un preset habitual en GGUF), baja a aproximadamente 40 GB. La diferencia entre necesitar cuatro A100 o una sola H100 es exactamente esta. A precios de nube en 2026, estamos hablando de una diferencia de entre 8 y 20 dólares por hora de inferencia continua, dependiendo del proveedor.

Ese es el número que debería presidir cualquier debate sobre formatos.

GGUF: el formato del ecosistema, no el más eficiente

GGUF (sucesor de GGML, introducido por llama.cpp) es hoy el formato dominante para despliegues locales y entornos híbridos CPU+GPU. Su gran ventaja competitiva no es técnica sino ecosistémica: prácticamente todo modelo relevante en Hugging Face tiene una versión GGUF disponible en 24-48 horas tras su publicación, gracias a la comunidad TheBloke y sus sucesores.

El soporte de offloading CPU-GPU es genuinamente útil para equipos que corren modelos medianos (7B-13B) en hardware de consumo: una RTX 4090 con 24 GB puede ejecutar un Qwen3 32B en Q4 usando RAM del sistema para las capas que no caben en VRAM. La latencia no es producción-grade, pero para prototipos internos o herramientas de developer productivity, funciona.

El problema real de GGUF en producción: su velocidad de inferencia pura en GPU dedicada es inferior a GPTQ y, especialmente, a EXL2. Si estás sirviendo más de 20 usuarios concurrentes, GGUF empieza a mostrar sus límites de throughput.

GPTQ: el estándar de facto para GPU pura, pero con asteriscos

GPTQ usa un algoritmo de cuantización post-entrenamiento basado en información de segundo orden (Hessian) para minimizar el error al reducir a 4 bits. El resultado es una calidad superior a la cuantización naive para el mismo número de bits, y una velocidad de inferencia en GPU sensiblemente mayor que GGUF.

Compatible nativamente con transformers de Hugging Face, AutoGPTQ y vLLM, GPTQ es la opción más directa si tu stack ya está construido sobre ese ecosistema. El problema es el tiempo de cuantización: cuantizar un modelo de 70B con GPTQ puede llevar entre 4 y 8 horas en una A100, con un coste de nube no trivial. Para modelos que se renuevan cada pocas semanas —que es la velocidad actual del mercado— esto se convierte en overhead operativo real.

Para las empresas que trabajan con una agencia de consultoría IA externa para definir su arquitectura de modelos, este es precisamente el tipo de trade-off que debería estar sobre la mesa antes de comprometer infraestructura.

AWQ: cuando la calidad importa más que la velocidad de conversión

Activation-Aware Weight Quantization (AWQ) mejora sobre GPTQ en un punto específico: en lugar de tratar todos los pesos por igual, identifica los que tienen mayor impacto en las activaciones y los preserva con mayor precisión. El resultado empírico es consistente: en benchmarks de razonamiento (MMLU, HumanEval), AWQ a 4 bits supera a GPTQ a 4 bits en entre 1 y 3 puntos porcentuales, dependiendo del modelo base.

AWQ es compatible con vLLM y TGI (Text Generation Inference de Hugging Face), los dos servidores de inferencia más usados en despliegues de producción empresarial. Si tu caso de uso requiere calidad de respuesta alta y sirves desde una A10G, A100 o H100, AWQ debería ser tu primera opción de evaluación.

El ecosistema de agencias IA en Barcelona que trabaja con verticales de alto valor añadido —legaltech, fintech, healthtech— está adoptando AWQ precisamente por este motivo: el coste del error de modelo en esos sectores es mucho más alto que el coste del hardware.

EXL2 y EXL3: rendimiento máximo para quien controla su stack

ExLlamaV2 (EXL2) es el formato que mayor velocidad de generación de tokens ofrece en GPUs NVIDIA de arquitectura Ampere y Ada Lovelace. En benchmarks comparativos directos, EXL2 a 4 bits genera tokens un 30-50% más rápido que GPTQ equivalente en una RTX 3090 o 4090. Para casos de uso donde la latencia de generación es el KPI crítico —asistentes en tiempo real, agentes IA con bucles de herramientas— esta diferencia no es marginal.

EXL3, la evolución más reciente, introduce cuantización mixta más granular y mejoras adicionales de throughput. Está ganando tracción rápidamente pero todavía tiene menor cobertura de modelos disponibles que EXL2.

El inconveniente es la fricción de ecosistema: EXL2 no integra de forma nativa con vLLM ni con la mayoría de frameworks de despliegue empresarial. Requiere TabbyAPI o soluciones propias. Para equipos con ingenieros de ML sólidos, no es un problema. Para equipos que buscan despliegue rápido con herramientas estándar, es un coste de integración real que hay que presupuestar.

Los equipos que trabajan en el desarrollo de agentes autónomos con alta frecuencia de llamadas al modelo son los que más se benefician de EXL2: la reducción de latencia se acumula exponencialmente en pipelines multi-step.

La matriz de decisión que ninguna guía técnica te da

La guía original de MarkTechPost explica bien los formatos. Lo que no dice con suficiente claridad es esto:

Si estás en Mac con Apple Silicon: GGUF con llama.cpp es la única opción con soporte maduro para Metal. No hay debate.

Si estás prototipando en GPU de consumo (RTX 4070-4090): GGUF para flexibilidad o EXL2 si priorizas velocidad de generación sobre facilidad de setup.

Si estás en producción con GPUs data center (A10G, A100, H100): AWQ o GPTQ con vLLM. AWQ si la calidad de respuesta es crítica; GPTQ si tu equipo ya tiene pipelines construidos alrededor de AutoGPTQ.

Si construyes un producto con SLAs de latencia estrictos y controlas tu infraestructura: EXL2 vale el coste de integración.

A diferencia de lo que sugiere el enfoque técnico-neutral de la mayoría de guías, el verdadero reto para las empresas españolas no será entender los formatos, sino tener la disciplina de no cambiar de formato a mitad del desarrollo. He visto proyectos que empezaron con GGUF por comodidad, llegaron a producción con 50 usuarios concurrentes, y tuvieron que refactorizar completamente a AWQ+vLLM con el producto ya en la calle. El coste de esa migración —en tiempo de ingeniería y en semanas de degradación de servicio— superó con creces el ahorro inicial.

Para empresas que estén evaluando qué stack de inferencia adoptar antes de comprometer desarrollo, hablar con especialistas en automatización con IA o con agencias de IA en Madrid que ya hayan pasado por ciclos completos de producción puede ser el atajo más barato. La decisión de formato no se toma una vez: se toma cada vez que aparece un modelo que vale la pena actualizar, y en 2026 eso significa varias veces al trimestre.

El mercado de cuantización no ha terminado de consolidarse. Con Vantora —la ex UP.Labs que acaba de cerrar una ronda de más de 100 millones para construir startups nativas de IA empresarial— entrando en el espacio, es probable que veamos herramientas de conversión y serving más integradas en los próximos 12 meses. Quien haya apostado por estándares abiertos y ecosistemas con inercia (vLLM, llama.cpp) estará mejor posicionado que quien haya construido sobre soluciones propietarias de nicho. La cuantización seguirá siendo una palanca de coste crítica; la pregunta es si seguirá siendo una decisión manual o se automatizará dentro del ciclo de despliegue. Mi apuesta: automatizada, pero solo para quien ya haya aprendido a hacerla bien a mano.

Temas relacionados en agentes.ai

Si quieres aplicar lo que lees en tu empresa, estos son puntos de partida útiles dentro de agentes.ai:

• Directorio de agencias de agentes de voz
• Agencias de IA en Valencia y en Málaga
• Explora el directorio completo de agencias de IA
• Sigue las últimas noticias de IA en tiempo real