Cuellos de botella en la inferencia local de LLMs: VRAM vs TFLOPS

El rendimiento de la inferencia local de LLMs está fuertemente limitado por el ancho de banda de la memoria VRAM (medido en GB/s) y no por la potencia de cálculo bruta (TFLOPS) de la GPU en su fase principal. Esto se debe a que la generación de texto (fase de decoding) es una tarea de tipo memory-bound (limitada por memoria), donde cada token generado requiere cargar la totalidad de los parámetros del modelo desde la VRAM a los registros de cálculo de la GPU. Por lo tanto, una tarjeta gráfica con menor potencia de procesamiento pero un bus de memoria más ancho superará sistemáticamente en velocidad de generación (tokens por segundo) a una GPU con más TFLOPS pero un bus de memoria recortado.

La ejecución local de Modelos de Lenguaje Grande (LLMs) se ha convertido en el pilar fundamental para empresas y desarrolladores que exigen soberanía de datos, latencias predecibles e inmunidad frente a los costes de suscripción de las API comerciales en la nube. Sin embargo, al configurar estaciones de trabajo para IA local en este año 2026, muchos ingenieros se encuentran con una paradoja técnica desconcertante: GPUs de gama media-alta con especificaciones de procesamiento formidables ofrecen una velocidad de generación de texto (medida en tokens por segundo) notablemente inferior a la de hardware de generaciones anteriores o sistemas de arquitectura unificada como los integrados de Apple.

Al abordar este tema, desmitificaremos la arquitectura de hardware que hace posible la inteligencia artificial en el borde (edge computing). Conectando esto con nuestras publicaciones previas sobre la eficiencia de arquitecturas de silicio, el direccionamiento de memoria en sistemas heterogéneos y la optimización de recursos, analizaremos por qué la física de la transferencia de datos a través de la VRAM es el verdadero factor limitante en la inferencia local de LLMs. Aprenderás cómo calcular los límites reales de tu hardware y cómo optimizar la entrega de tokens aplicando la matemática del transporte de datos.

El concepto de intensidad aritmética en la inferencia de hardware

Para comprender la física de la inferencia local de modelos de lenguaje, es obligatorio definir la intensidad aritmética. Este principio informático determina la relación exacta entre el volumen de operaciones de punto flotante realizadas por un procesador y la cantidad de bytes que deben transmitirse hacia la memoria principal del sistema para completar dichas instrucciones.

De acuerdo con el modelo matemático Roofline Model, cualquier algoritmo ejecutado en una GPU se encuadra de forma estricta en una de las siguientes dos categorías funcionales de rendimiento:

• Limitado por cómputo (Compute-Bound): Se manifiesta cuando la intensidad aritmética es elevada. El procesador ejecuta cientos de operaciones sobre cada byte leído de la memoria, supeditando la velocidad global a los TFLOPS brutos de los núcleos físicos del silicio.
• Limitado por memoria (Memory-Bound): Ocurre si la intensidad aritmética es baja. Al realizarse pocos cálculos por cada byte transferido, los núcleos de la GPU procesan la información de manera instantánea y entran en estados de latencia inactiva mientras aguardan el siguiente paquete de datos, condicionando el rendimiento al ancho de banda en gigabytes por segundo.

El comportamiento autorregresivo y la ineficiencia de transferencia

La fase de generación de texto en un modelo autorregresivo representa el escenario más drástico de un algoritmo limitado por memoria. Debido a que el sistema predice un único token a la vez de forma secuencial, la GPU se ve forzada a transferir la totalidad de los miles de millones de parámetros estáticos del modelo desde los chips físicos de la VRAM hasta los registros de cálculo del procesador para emitir una sola palabra. Tras completar la operación, el procesador purga su caché y reitera exactamente la lectura masiva de gigabytes desde la memoria de vídeo para computar el elemento subsiguiente, repitiendo este ciclo ineficiente en cada paso.

Prefill frente a Decoding: Dos mundos computacionales en un solo prompt

Cuando interactúas con un LLM local (por ejemplo, a través de interfaces como Llama.cpp u Ollama), la inferencia ocurre en dos fases físicas con perfiles de carga de trabajo diametralmente opuestos: la fase de Prefill y la fase de Decoding.

1. La Fase de Prefill (Procesamiento del Prompt)

En esta fase inicial, el LLM lee y procesa todo el texto del prompt o contexto de entrada que le has proporcionado. Aquí, la GPU procesa todos los tokens del prompt de forma simultánea en paralelo empleando operaciones de multiplicación de matrices masivas.

Debido a que el volumen de datos de entrada se procesa todo a la vez, la reutilización de datos dentro de la caché interna del silicio de la GPU es extremadamente alta, lo que resulta en una alta intensidad aritmética. La fase de Prefill es, por lo tanto, una tarea limitada por cómputo (compute-bound). En este breve instante de tiempo inicial, contar con una GPU con una enorme cantidad de Tensor Cores y TFLOPS se traduce de forma directa en un procesamiento instantáneo de prompts sumamente largos.

2. La Fase de Decoding (Generación de Tokens)

Una vez procesado el prompt, comienza la generación real de la respuesta. El LLM calcula y emite el primer token, luego lo retroalimenta junto al prompt para calcular el segundo, y así sucesivamente. Como este proceso es estrictamente secuencial y no se puede paralelizar, la reutilización de datos dentro del silicio es prácticamente nula.

La intensidad aritmética se desploma a niveles ínfimos, transformando la fase de Decoding en una tarea estrictamente limitada por memoria (memory-bound). No importa si tu tarjeta gráfica tiene 80 TFLOPS de potencia de cálculo; si tu ancho de banda de memoria es de apenas 300 GB/s, los núcleos de procesamiento de tu GPU pasarán la mayor parte de su tiempo de reloj completamente inactivos, esperando pacientemente a que la memoria VRAM les envíe la matriz de pesos del modelo para poder procesar el siguiente token.

Tabla Comparativa DatoCortex

Métrica y Fase de Ejecución	Fase de Prefill (Carga de Prompt)	Fase de Decoding (Generación de Texto)
Naturaleza del Límite de Hardware	Limitada por Cómputo (Compute-Bound)	Limitada por Memoria (Memory-Bound)
Recurso de Hardware Crítico	TFLOPS de la GPU / Tensor Cores	Ancho de banda de la VRAM (GB/s) / Bus de Memoria
Procesamiento de Datos	Paralelo masivo (Todos los tokens de entrada a la vez)	Secuencial estricto (Token por token de forma aislada)
Intensidad Aritmética	Alta (Muchos cálculos matemáticos por byte leído)	Extremadamente baja (Pocos cálculos por byte leído)
Impacto de la Optimización	Afecta el tiempo de respuesta inicial (Time to First Token)	Define la velocidad de generación final (Tokens por Segundo)

La fórmula de velocidad en la fase de generación de tokens

Para cuantificar el rendimiento real de un modelo de lenguaje durante la fase de generación secuencial de texto, la ingeniería de hardware aplica una fórmula matemática directa: la velocidad máxima de tokens por segundo está delimitada por el ancho de banda de la memoria dividido entre el tamaño físico del modelo en disco.

Analicemos este escenario ejecutando un modelo Llama 3 de 8 mil millones de parámetros (8B) bajo precisión nativa FP16, lo que requiere un espacio de almacenamiento constante en la VRAM de aproximadamente 16 gigabytes.

Las limitaciones de la capa física de transporte imponen los siguientes umbrales de rendimiento:

• Matriz profesional: Utilizar un acelerador dedicado con un ancho de banda masivo de 1000 GB/s sitúa el límite físico absoluto de generación en sesenta y dos tokens por segundo.
• Hardware de consumo: Desplegar el mismo modelo sobre una tarjeta común con un bus restringido a 280 GB/s desploma la tasa de refresco a diecisiete tokens por segundo.
• Congestión del bus: La degradación no responde a la falta de potencia de cálculo del silicio, sino a la saturación del canal de datos.

Alivio del ancho de banda de la VRAM mediante formatos de baja precisión

Para evadir esta barrera neumática de transferencia, la ingeniería de software recurre a formatos de cuantización avanzada como GGUF y AWQ. Este proceso consiste en reducir la precisión matemática de los pesos, convirtiendo los valores originales de dieciséis bits a enteros compactos de cuatro bits (INT4).

Esta compresión disminuye el peso del archivo de 16 GB a solo 4.5 GB con una pérdida cognitiva imperceptible. Al aplicar la fórmula nuevamente sobre el bus de 280 GB/s, la GPU solo transfiere una fracción de datos por token, elevando instantáneamente la velocidad a sesenta tokens por segundo mediante el alivio del tráfico interno de la VRAM.

Formatos de compresión, arquitecturas de memoria y optimización en servidores de inferencia

Divergencias de gestión de memoria entre formatos GGUF y AWQ

La selección del formato de compresión define la flexibilidad y la viabilidad de la infraestructura de inteligencia artificial local. El formato GGUF, desarrollado por el ecosistema de código abierto de Llama.cpp GitHub Repository, está optimizado para entornos heterogéneos. Este diseño permite la división dinámica de capas (CPU offloading), enviando bloques de parámetros hacia la memoria RAM si el modelo excede la VRAM física.

Por otro lado, la cuantización AWQ (Activation-aware Weight Quantization) prioriza el rendimiento al requerir que el modelo resida por completo en la VRAM, ejecutándose en los núcleos Tensor de la GPU.

Arquitecturas de memoria unificada y modelos de gran escala

Los sistemas System-on-Chip (SoC) superan el cuello de botella del bus PCIe mediante memoria unificada (UMA), permitiendo a los núcleos compartir un pool de alta velocidad. Con anchos de banda superiores a 800 GB/s, es posible ejecutar modelos de 70B-120B localmente, evitando la necesidad de múltiples GPUs discretas.

Optimización del estado de contexto mediante KV Cache

El uso de la caché de claves y valores (KV Cache) en la VRAM es vital para la eficiencia, al almacenar vectores de atención y evitar recálculos en la fase de decoding. Esta optimización gestiona la longitud del contexto, aunque su escalabilidad está limitada por la VRAM disponible antes de provocar errores de memoria.

Escalado de intensidad aritmética mediante el tamaño de lote (Batch Size)

Si bien la inferencia local suele operar con lotes unitarios (limitado por memoria), los servidores de producción aumentan el batch size para agrupar solicitudes. Herramientas como vLLM Project optimizan este proceso, cargando los pesos una sola vez para procesar múltiples peticiones en paralelo. Esto maximiza la intensidad aritmética, desplazando el cuello de botella del ancho de banda (GB/s) hacia la potencia de cómputo (TFLOPS).

Si quieres conocer otros artículos parecidos a Cuellos de botella en la inferencia local de LLMs: VRAM vs TFLOPS puedes visitar la categoría Procesamiento/ IA.