Cuantización e inferencia rápida en tu propio hardware

La primera reacción de muchos ingenieros al ver los requisitos de hardware de un modelo de lenguaje de última generación es de sorpresa. Un modelo de 70.000 millones de parámetros en su formato nativo FP32 necesitaría unos 280 GB de memoria GPU, más de lo que la mayoría de organizaciones tiene en un único servidor y mucho más de lo que desean provisionar solo para responder consultas internas. La cuantización es la técnica que hace que estas cifras sean manejables, y comprenderla es esencial para cualquiera que diseñe una pila de IA en local.

Qué hace realmente la cuantización

Una red neuronal es en esencia una colección muy grande de números: los pesos aprendidos durante el entrenamiento. Por defecto, esos pesos se almacenan como valores en coma flotante de 32 bits (FP32), consumiendo 4 bytes cada uno. La cuantización sustituye los números de alta precisión por representaciones de menor precisión: flotantes de 16 bits (FP16 o BF16), enteros de 8 bits (INT8) o incluso enteros de 4 bits (INT4). La huella de memoria se reduce proporcionalmente y, en hardware con soporte nativo para aritmética de menor precisión, la inferencia también se acelera.

• FP16 / BF16 — flotantes de media precisión. Prácticamente sin pérdidas para la mayoría de tareas; la opción predilecta para despliegues en producción donde la precisión es crítica. Ahorro de memoria: 2x respecto a FP32.
• INT8 — enteros de 8 bits, producidos habitualmente mediante métodos de cuantización post-entrenamiento (PTQ) como GPTQ o llm.int8(). Degradación de calidad modesta en razonamiento complejo; significativa en la mayoría de tareas prácticas. Ahorro de memoria: 4x respecto a FP32.
• INT4 — enteros de 4 bits, la frontera de la cuantización agresiva. Herramientas como GGUF Q4_K_M y AWQ ofrecen una calidad sorprendentemente buena para su tamaño. Ahorro de memoria: 8x respecto a FP32, con una degradación aceptable en cargas de trabajo de chat y resumen.

El compromiso entre calidad y tamaño

La cuantización no es gratuita. Cada bit que se elimina es información descartada y en algún punto eso se manifiesta como salidas degradadas: alucinaciones, errores de razonamiento o pérdida de matiz. La conclusión práctica de los despliegues de Privonis es que el compromiso es sorprendentemente favorable para la mayoría de tareas empresariales. Un modelo de 70B cuantizado a INT4 supera en general a uno de 13B en FP16, aunque ambos ocupen una memoria GPU similar. Ante la duda, usa el modelo más grande que quepa a la mayor precisión que soporte tu hardware.

Elegir la cuantización correcta tiene menos que ver con el número de bits y más con ajustar la capacidad del modelo a la tarea: un 70B en INT4 bien elegido supera a un 13B en FP16 mal escogido en todo momento.

Servidores de inferencia: de dónde viene el rendimiento

Ejecutar un modelo cuantizado es solo la mitad de la historia. Servirlo de forma eficiente bajo carga concurrente requiere un servidor de inferencia que comprenda la estructura de la atención transformer. La opción de código abierto dominante hoy es vLLM, que introdujo PagedAttention: una técnica de gestión de memoria inspirada en la memoria virtual de los sistemas operativos que permite al servidor intercalar muchas solicitudes simultáneamente sin desperdiciar memoria GPU en bloques de caché KV preasignados. El efecto práctico es una mejora de 10 a 30 veces en el rendimiento frente a un bucle simple de una sola solicitud.

Otras opciones destacadas incluyen llama.cpp (optimizado para CPU, excelente para modelos más pequeños en hardware de consumo), Ollama (envoltorio amigable para desarrolladores sobre llama.cpp), TGI de Hugging Face (sólida compatibilidad con formatos de modelos de Hugging Face) y TensorRT-LLM de NVIDIA (máximo rendimiento en hardware NVIDIA, a costa de un proceso de compilación más complejo). Privonis evalúa y compara todos ellos para cada configuración de cliente.

Agrupación de solicitudes y rendimiento

Las GPUs alcanzan su máxima eficiencia cuando procesan muchas operaciones simultáneamente: para eso fueron diseñadas. El batching continuo (también llamado batching dinámico o planificación a nivel de iteración) permite a un servidor de inferencia agrupar tokens de múltiples solicitudes concurrentes en una única llamada a kernel de GPU, mejorando drásticamente la utilización. Sin batching, una única consulta de usuario podría usar el 5 % de la capacidad de la GPU; con batching continuo, es posible llevar la utilización al 70–80 % bajo patrones de tráfico reales. Para una empresa con decenas de usuarios simultáneos, la diferencia entre un servidor con batching y uno sin él puede significar la diferencia entre necesitar uno o cuatro servidores GPU.

Elegir la cuantización adecuada para tu GPU

El árbol de decisión es más sencillo de lo que parece. Empieza por tu presupuesto de memoria VRAM, resta el margen para el sistema operativo y el servidor de inferencia (normalmente 4–8 GB) y encuentra el modelo más grande que quepa al nivel de precisión más alto. Algunos puntos de referencia prácticos:

• 24 GB VRAM (p. ej. RTX 4090, A5000) — ejecuta cómodamente un modelo de 13B en FP16 o uno de 34B en INT4.
• 48 GB VRAM (p. ej. RTX 6000 Ada, A6000) — ejecuta un modelo de 34B en FP16 o uno de 70B en INT4.
• 2 × 80 GB (p. ej. par de A100 con NVLink) — ejecuta un modelo de 70B en FP16 o uno de 140B en INT4 con paralelismo tensorial.
• Solo CPU (sin GPU) — llama.cpp con un modelo Q4_K_M de 7B o 13B es viable para herramientas de desarrollo con baja concurrencia; se pueden esperar entre 5 y 15 tokens por segundo.

Poniendo todo junto con Privonis

Seleccionar un formato de cuantización y un servidor de inferencia es un trabajo de ingeniería que requiere perfilado en tu hardware específico con tu carga de trabajo concreta. Privonis se ocupa de ese benchmarking como parte de cada despliegue: ejecutamos pruebas de rendimiento, medimos la calidad de salida sobre una muestra representativa de tus prompts reales y entregamos una configuración que maximiza el rendimiento dentro de tu presupuesto de hardware. El resultado es una pila de inferencia en producción que tu equipo puede operar sin necesitar un ingeniero de ML especializado de guardia. Si quieres explorar qué encaja en tu entorno, nuestro equipo estará encantado de hacer los números contigo.