Un servidor para inferencia LLM se dimensiona teniendo en cuenta mucho más que el tamaño del modelo. Primero se determinan la longitud real de las solicitudes de entrada y las respuestas, la frecuencia máxima de solicitudes, el número de solicitudes procesadas simultáneamente y la latencia aceptable. Después se calcula por separado la memoria necesaria para los pesos del modelo y la caché KV, se estima el flujo de tokens y solo entonces se seleccionan la GPU, la CPU, la RAM, el almacenamiento NVMe y la red. Un pequeño chatbot interno puede necesitar un solo acelerador, mientras que el mismo modelo con un contexto largo y decenas de conversaciones activas puede requerir varias GPU o varias réplicas de servidor.
Modelo + contexto + solicitudes activas + latencia objetivo + reserva = configuración del servidor.
El propio modelo puede caber por completo en la memoria de la GPU y, aun así, el servicio puede empezar a rechazar solicitudes cuando aumenta la carga. Esto ocurre porque la memoria no se utiliza únicamente para los pesos. Una parte importante la ocupan la caché KV, los búferes temporales, las estructuras de servicio y los datos utilizados por el entorno de software.
El número de usuarios por sí solo tampoco dice demasiado. Cien empleados que utilizan un chatbot varias veces al día generan una carga muy distinta de la de veinte clientes que envían simultáneamente documentos voluminosos y esperan respuestas detalladas.
GPU servers
Por qué el tamaño del modelo no es suficiente
Al seleccionar un servidor, es necesario comprobar cuatro restricciones independientes.
Capacidad
La memoria de la GPU debe alojar simultáneamente los pesos, la caché KV de las solicitudes activas, los búferes temporales, las estructuras de servicio y una reserva para la fragmentación. Iniciar el modelo sin usuarios solo confirma que cabe el conjunto mínimo de datos.
Latencia y rendimiento
El usuario espera primero a que se procese el contexto y aparezca la primera parte de la respuesta, y después a que continúe la generación. Una prueba con un contexto de 500 tokens no puede extrapolarse a una carga de trabajo de 8.000 o 16.000 tokens.
El servidor también debe procesar el flujo entrante más rápido de lo que crece la cola. Por eso, el rendimiento debe medirse con longitudes de entrada y salida definidas, niveles de concurrencia concretos y límites de latencia establecidos.
Escalado
Existen tres arquitecturas posibles:
- Un modelo se divide entre varias GPU.
- Se ejecutan varias copias independientes del modelo.
- El modelo o sus réplicas se distribuyen entre varios servidores.
El paralelismo del modelo es necesario cuando este no cabe en un solo acelerador. Las réplicas son más adecuadas para aumentar el número de usuarios atendidos y mejorar la tolerancia a fallos. Una arquitectura multinodo se utiliza cuando un solo servidor no ofrece recursos suficientes, pero requiere una red rápida y una administración más compleja.
Qué datos se necesitan para el cálculo
En una aplicación existente, los parámetros se obtienen de los registros de solicitudes. Para un proyecto nuevo se preparan tres perfiles: normal, máximo y desfavorable, pero todavía aceptable.
| Parámetro | Qué medir | En qué influye |
|---|---|---|
| Modelo | Parámetros, capas, cabezas KV y tamaño de cabeza | Tamaño de los pesos del modelo y caché KV |
| Formato de los pesos | 16, 8 o 4 bits | Consumo de memoria de la GPU |
| Contexto | Mediana, percentil 95 y límite | Tiempo hasta el primer token y caché KV |
| Respuesta | Longitud media, percentil 95 y límite | Duración de la solicitud y flujo de salida |
| Frecuencia | Solicitudes por segundo o minuto durante el pico | Concurrencia y tamaño de la cola |
| Latencia | Primer token, intervalos entre tokens y tiempo total | Clase de GPU y número de réplicas |
| Disponibilidad | Tiempo de inactividad aceptable | Redundancia |
| Crecimiento | Carga prevista dentro de 6–12 meses | Margen de ampliación de la plataforma |
El contexto debe medirse con el tokenizador del modelo concreto. Convertir caracteres o palabras en tokens no es preciso, porque la tokenización depende del idioma y del vocabulario.
El contexto máximo anunciado por el modelo no debe asignarse a todas las solicitudes. Para el cálculo se necesita la distribución real de longitudes y un límite definido a nivel de producto. La media tampoco es suficiente: si el cinco por ciento de las solicitudes es considerablemente más largo que el resto, una configuración basada en la media empeorará la latencia precisamente en la parte más exigente de la carga.
Cómo calcular la memoria para los pesos del modelo
NVIDIA H200 es un ejemplo de GPU para servidores con una gran cantidad de memoria de alta velocidad. Fuente: NVIDIA.
Fuente de la imagen: NVIDIA
El tamaño preliminar de los pesos se calcula con la siguiente fórmula:
Memoria de los pesos ≈ número de parámetros × bits por parámetro ÷ 8
Para una estimación rápida:
- 7.000 millones de parámetros en formato de 16 bits: unos 14 GB;
- 14.000 millones: unos 28 GB;
- 32.000 millones: unos 64 GB;
- 70.000 millones: unos 140 GB;
- 70.000 millones en formato de 8 bits: unos 70 GB;
- 70.000 millones en formato de 4 bits: unos 35 GB.
Este es el tamaño teórico de los pesos por sí solos. Las recomendaciones de Hugging Face para optimizar la inferencia explican la cuantización y otras formas de reducir el consumo de memoria, pero la huella total del servicio no puede determinarse mediante una sola fórmula.
A los pesos hay que añadir:
- escalas y metadatos de cuantización;
- tensores temporales y espacios de trabajo de las bibliotecas;
- memoria para los grafos de ejecución;
- la caché KV;
- estructuras del planificador;
- fragmentación;
- margen para un funcionamiento estable durante los picos de carga.
Por este motivo, no conviene elegir un acelerador suponiendo que los pesos pueden ocupar casi toda la memoria disponible. Aunque el modelo se inicie, puede no quedar espacio para el contexto y las solicitudes simultáneas.
Qué cambia la cuantización
Convertir los pesos de 16 a 4 bits reduce teóricamente su tamaño unas cuatro veces, pero el consumo total de memoria no disminuye en la misma proporción. La caché KV puede seguir almacenándose en formato de 16 u 8 bits, mientras que los búferes y algunas operaciones pueden utilizar una precisión mayor.
También existen otras limitaciones:
- los distintos modelos pierden calidad en diferente medida;
- el formato debe ser compatible con el entorno y la GPU seleccionados;
- un modelo de 4 bits no es necesariamente más rápido que uno de 8 bits;
- la conversión de formatos puede reducir en algunos casos la mejora de rendimiento;
- los modelos de mezcla de expertos suelen mantener en memoria los pesos de todos los expertos, aunque para un token concreto solo esté activa una parte.
La cuantización resuelve principalmente un problema de capacidad. Su efecto sobre la calidad y la velocidad debe comprobarse con solicitudes de producción.
Caché KV: cómo el contexto y las solicitudes simultáneas consumen memoria
Durante la generación, el modelo almacena claves y valores intermedios correspondientes a los tokens que ya se han procesado. De este modo, no es necesario volver a calcular todo el contexto anterior para cada token nuevo. Estos datos se denominan caché de claves y valores, o caché KV.
La caché crece junto con la secuencia y existe por separado para cada solicitud activa. Incluye tanto los tokens del contexto de entrada como la parte de la respuesta que ya se ha generado.
Para las arquitecturas transformer habituales se utiliza la siguiente fórmula aproximada:
Caché KV = 2 × número de capas × número de cabezas KV × tamaño de cabeza × bytes por elemento × tokens × secuencias activas
El factor 2 representa las claves y los valores. El número de cabezas KV debe obtenerse de la configuración del modelo y no sustituirse por el número total de cabezas de atención. La asignación paginada, la reutilización de bloques y los límites de la caché se describen en la documentación de TensorRT-LLM.
Ejemplo para un modelo hipotético de 70.000 millones de parámetros
Supongamos la siguiente arquitectura:
- 80 capas;
- 8 cabezas KV;
- tamaño de cabeza de 128;
- 2 bytes por elemento.
Un token de una secuencia requiere:
2 × 80 × 8 × 128 × 2 = 327.680 bytes, o aproximadamente 0,3125 MiB.
Por tanto:
- 8.192 tokens utilizan unos 2,5 GiB para una secuencia;
- 16.384 tokens utilizan unos 5 GiB;
- 16 secuencias de 8.192 tokens utilizan unos 40 GiB;
- 32 secuencias de 16.384 tokens utilizan unos 160 GiB.
Los pesos de un modelo de 4 bits ocupan teóricamente unos 35 GB. Sin embargo, con dieciséis solicitudes largas simultáneas, la suma de los pesos y la caché KV ya se aproxima a 75 GB antes de añadir los búferes y la reserva. En un acelerador con 80 GB de memoria, esta configuración estará cerca del límite de capacidad, aunque el modelo inactivo ocupe menos de la mitad de la memoria.
El consumo de la caché KV suele reducirse de varias formas:
- limitar el contexto de trabajo;
- resumir o eliminar el historial antiguo de la conversación;
- establecer una longitud máxima de respuesta;
- reducir el número de secuencias activas por réplica;
- utilizar un formato de caché más compacto cuando sea compatible;
- utilizar asignación paginada de memoria;
- reutilizar prefijos de solicitudes idénticos;
- separar las tareas en segundo plano de larga duración de la cola interactiva.
En los sistemas RAG es especialmente importante controlar el número y el tamaño de los fragmentos recuperados. Incluir todos los resultados de búsqueda en el prompt aumenta tanto la caché KV como el tiempo de procesamiento de la entrada. Un reranking adicional suele ser más eficiente que ampliar simplemente el contexto.
Cómo convertir el número de usuarios en solicitudes activas
Para el servidor, los usuarios registrados son menos importantes que las solicitudes que esperan en la cola, se encuentran en la fase de procesamiento del contexto o están generando una respuesta.
Solicitudes activas ≈ frecuencia máxima de llegada × tiempo medio de procesamiento
Si llega una solicitud por segundo y la respuesta tarda 20 segundos en generarse, se atienden simultáneamente unas 20 solicitudes. Si el tiempo de procesamiento aumenta a 40 segundos, la carga simultánea se duplica con la misma frecuencia de llegada.
Hay que tener en cuenta los picos breves, la duración completa de las respuestas transmitidas por streaming, las solicitudes largas, los límites del cliente y la cancelación de la generación cuando ya no es necesaria. Los reintentos después de un tiempo de espera agotado también son peligrosos: durante una sobrecarga crean solicitudes adicionales.
Mil empleados pueden generar solo dos o tres conversaciones activas, mientras que unos pocos clientes grandes de una API pueden mantener activas decenas de secuencias de forma constante.
Qué métricas de latencia deben medirse
No existe una única métrica universal de latencia para un servicio LLM. En una aplicación interactiva son importantes tres mediciones.
Tiempo hasta el primer token
Es el periodo que transcurre desde el envío de una solicitud hasta la recepción de la primera parte de la respuesta. Incluye el tiempo en cola, la tokenización, el procesamiento del contexto de entrada y el inicio de la generación. Esta métrica es especialmente perceptible en un chatbot: el texto que aparece progresivamente se considera normal, mientras que un periodo largo sin salida parece un bloqueo de la aplicación.
Latencia entre tokens
Indica la fluidez con la que se genera el resto de la respuesta. Depende del tamaño del modelo, el ancho de banda de la memoria de la GPU, el procesamiento por lotes, la competencia entre solicitudes y la comunicación entre aceleradores.
Tiempo total de respuesta
Depende tanto de la velocidad de generación como de la longitud de la salida. Por eso, las configuraciones deben compararse utilizando las mismas distribuciones de entrada y salida. Las métricas de inferencia LLM separan el tiempo hasta el primer token, los intervalos de generación, la latencia de extremo a extremo y el rendimiento.
Los tokens de entrada, los tokens de salida y las solicitudes completadas por segundo deben medirse por separado. Un rendimiento agregado elevado no garantiza un buen servicio: los lotes grandes pueden mejorar la utilización de la GPU y, al mismo tiempo, aumentar la espera de cada usuario.
Resulta más útil contar las solicitudes que se completan dentro de los límites especificados. Por ejemplo, contabilizar solo las respuestas cuyo primer token llega en menos de dos segundos y cuyos intervalos de generación se mantienen dentro de los valores aceptables. Este enfoque se utiliza en GenAI-Perf.
Qué componentes del servidor determinan el resultado
Dell PowerEdge XE9680.
Fuente de la imagen: infohub.delltechnologies.com
GPU y memoria de vídeo
Al seleccionar un acelerador, se evalúan:
- La capacidad y el ancho de banda de la memoria de la GPU.
- El rendimiento con el formato elegido para el modelo.
- El método de conexión entre varias GPU.
- El consumo energético y los requisitos de refrigeración.
La capacidad determina si cabrán los pesos, la caché KV y los búferes. El ancho de banda de la memoria es especialmente importante durante la generación autorregresiva. Varias GPU no forman automáticamente un espacio de memoria compartido: el entorno de software debe dividir el modelo y los datos deben transferirse entre los aceleradores. PCIe estándar y una interconexión de alta velocidad pueden ofrecer latencias diferentes incluso con la misma capacidad total de memoria.
Procesadores centrales
Las CPU se ocupan de la tokenización, las API, el enrutamiento, las operaciones de red y parte de la canalización RAG. Al procesar documentos, también realizan la descompresión, la conversión de formatos y la división del texto en fragmentos.
Además del número de núcleos y su rendimiento, son importantes:
- las líneas PCIe;
- la ubicación de las GPU con respecto a los zócalos de CPU;
- el ancho de banda de la memoria;
- la topología NUMA;
- el número de dispositivos de almacenamiento y adaptadores de red disponibles.
Para configuraciones densas, se pueden considerar servidores AMD EPYC y servidores Intel Xeon. La elección debe basarse en la topología de la plataforma y en la compatibilidad con los aceleradores y el conjunto de software, y no únicamente en el nombre del procesador.
Memoria RAM y NVMe
La RAM se utiliza para cargar el modelo, ejecutar contenedores, mantener la caché de archivos, las bases de datos vectoriales, los índices, la preparación de documentos y el almacenamiento de adaptadores. Descargar una parte del modelo en la RAM puede permitir iniciar una configuración demasiado grande, pero las transferencias continuas a través de PCIe suelen aumentar la latencia.
El almacenamiento NVMe influye principalmente en los arranques en frío, el cambio de modelos, los índices RAG y el procesamiento por lotes. Si la generación, la base de datos vectorial y la indexación se ejecutan en el mismo servidor, es preferible separar sus operaciones de E/S entre distintas unidades o grupos de almacenamiento.
Red
En una API de texto, la conexión del cliente rara vez es el principal cuello de botella. La red adquiere mayor importancia cuando la base de datos vectorial se encuentra en otro nodo, el modelo está distribuido entre varios servidores o varios nodos intercambian grandes volúmenes de datos. La latencia y la estabilidad son tan importantes como los gigabits por segundo.
Alimentación, chasis y refrigeración
Es necesario comprobar:
- el formato físico y la potencia de las GPU compatibles;
- los risers, los cables y el espacio entre las tarjetas;
- el consumo total;
- la potencia permitida en el rack;
- si las frecuencias se mantienen durante cargas prolongadas;
- el funcionamiento después del fallo de una fuente de alimentación.
Las plataformas especializadas son más adecuadas para varias tarjetas aceleradoras de tamaño completo. Las gamas Dell PowerEdge de 16.ª generación y Dell PowerEdge de 17.ª generación incluyen sistemas de distintas clases, pero la compatibilidad debe comprobarse para el chasis concreto, el tipo de GPU y la potencia de diseño térmico.
Por qué el entorno de software es tan importante como el hardware
GPU idénticas pueden ofrecer un rendimiento diferente debido al planificador y a la implementación de la gestión de memoria. Los entornos modernos de inferencia utilizan:
- procesamiento continuo por lotes;
- asignación paginada de la caché KV;
- almacenamiento en caché de prefijos compartidos;
- procesamiento por partes de contextos largos;
- cuantización;
- paralelismo del modelo entre varias GPU;
- varias réplicas;
- decodificación especulativa;
- colas separadas para tareas interactivas y en segundo plano.
Estas funciones se describen en la documentación de vLLM, pero cada optimización tiene limitaciones. El almacenamiento en caché de prefijos compartidos solo resulta útil cuando el prefijo se repite. Los lotes grandes aumentan el rendimiento total, pero pueden empeorar el tiempo hasta el primer token. Dividir el modelo añade comunicación entre las GPU, mientras que la decodificación especulativa requiere memoria adicional. La configuración debe elegirse a partir de mediciones realizadas con la carga de trabajo real. (vLLM)
Most popular GPU
Cálculo de la configuración paso a paso
Primero se especifican el modelo exacto, el formato de los pesos y la arquitectura de atención. Después:
- Se calcula el tamaño teórico de los pesos y se mide el consumo real después de cargar el modelo.
- Se determinan la mediana, el percentil 95 y el límite tanto para la entrada como para la salida.
- Se calcula la caché KV para el pico habitual y para la solicitud permitida más exigente.
- Se estima el rendimiento de tokens de entrada y de salida.
- Se elige entre el paralelismo del modelo y las réplicas independientes.
- Se valida el resultado mediante una prueba de carga después del calentamiento.
El rendimiento de entrada y salida se calcula por separado:
Tokens de entrada/s = solicitudes/s × longitud media de entrada
Tokens de salida/s = solicitudes/s × longitud media de respuesta
Una entrada larga aumenta el tiempo de procesamiento del contexto y el tiempo hasta el primer token. Una respuesta larga mantiene activa la solicitud durante más tiempo y aumenta la carga simultánea.
Ejemplo de cálculo para un modelo 70B
Datos de entrada:
- 70.000 millones de parámetros;
- pesos de 4 bits;
- entrada media: 4.000 tokens;
- percentil 95: 8.000 tokens;
- respuesta media: 300 tokens;
- una solicitud por segundo;
- aproximadamente 20 secuencias activas;
- la caché KV de 16 bits del ejemplo anterior.
Los pesos ocupan teóricamente unos 35 GB. La caché KV de una secuencia de 8.000 tokens ocupa aproximadamente 2,44 GiB y, para veinte secuencias, unos 48,8 GiB. El total ya supera los 83 GB antes de incluir los metadatos de cuantización, los búferes y la reserva.
Una sola GPU de 80 GB no puede garantizar esta carga en el percentil 95. Existen varias soluciones posibles:
- un acelerador con más memoria;
- dos GPU conectadas;
- un límite de contexto más bajo;
- menos secuencias activas por réplica;
- un grupo separado para las solicitudes largas;
- varias réplicas con los usuarios distribuidos entre ellas.
El rendimiento será de aproximadamente 4.000 tokens de entrada y 300 tokens de salida por segundo. Estas cifras definen el perfil de prueba, pero no predicen la latencia de una GPU concreta: debe medirse con el modelo y el entorno de software seleccionados.
Configuraciones para distintas cargas de trabajo
| Escenario | Riesgo principal | Prioridad |
|---|---|---|
| Chatbot interno | Un servidor innecesariamente caro que permanece inactivo | Primer token rápido e historial limitado |
| Sistema RAG | Contexto largo y crecimiento de la caché KV | Selección de fragmentos, RAM y NVMe |
| API de producto | Colas y latencia inestable | Réplicas, límites y redundancia |
| Procesamiento por lotes | La GPU espera a que se preparen los datos | Lotes grandes y suministro rápido de datos |
| Plataforma multiusuario | Los modelos compiten por la memoria | Grupos separados, cuotas y enrutamiento |
Chatbot interno
Para un pequeño asistente corporativo puede ser suficiente una GPU con 24–48 GB si el modelo es compacto, el historial de conversación está limitado y hay pocos diálogos activos al mismo tiempo. Si el tiempo de inactividad no es aceptable, se necesita una segunda réplica incluso cuando una sola ofrece rendimiento suficiente.
Sistema RAG
El contexto incluye el prompt del sistema, la pregunta, el historial de la conversación y los documentos recuperados. Conviene limitar el número de fragmentos y utilizar filtrado y reranking. La base de datos vectorial y el servicio de generación no tienen que ejecutarse en el mismo nodo, especialmente cuando la indexación requiere muchos recursos.
API de producto
Se escalan réplicas con un rendimiento útil medido, no simplemente «el número total de GPU». Para los clientes se establecen límites de longitud de entrada, longitud de salida y concurrencia. Las actualizaciones sin tiempo de inactividad requieren una réplica adicional ya calentada.
Procesamiento por lotes
En este caso se acepta una latencia mayor para cada tarea, por lo que el procesamiento por lotes puede ser más agresivo. La CPU y el almacenamiento NVMe deben suministrar datos con suficiente rapidez para mantener ocupada la GPU. La cola en segundo plano debe separarse de la cola interactiva.
Plataforma multiusuario
Varios modelos y adaptadores compiten por la memoria de la GPU. Se necesitan grupos separados, cuotas de tokens y concurrencia, enrutamiento según la longitud del contexto y capacidad reservada para el fallo de un nodo. A menudo resulta más eficiente utilizar varias réplicas independientes que agrupar todas las GPU para un único modelo.
Varias GPU o varios servidores
Se eligen varias GPU en un mismo servidor cuando el modelo no cabe en un solo acelerador o cuando es necesario acelerar una única instancia de gran tamaño. Hay que comprobar la conexión entre las GPU, la compatibilidad con el tipo de paralelismo elegido, la alimentación y la refrigeración.
Es preferible utilizar varias réplicas cuando el modelo cabe en una sola GPU, pero es necesario atender a más usuarios. Esta arquitectura se escala con mayor facilidad añadiendo otra réplica, permite actualizar sin detener por completo el servicio y mantiene el funcionamiento si falla un acelerador.
Un único modelo solo debe distribuirse entre varios servidores cuando un servidor no puede proporcionar recursos suficientes. Esta arquitectura depende de una red interna rápida y es más difícil de operar; rara vez es la opción óptima para modelos pequeños y medianos.
Errores de cálculo
Las configuraciones suelen subestimarse porque los equipos:
- solo tienen en cuenta el archivo de pesos;
- utilizan la carga media en lugar de la carga máxima;
- multiplican el contexto máximo por todos los usuarios registrados;
- olvidan la caché KV y la longitud de la respuesta;
- comparan pruebas con entradas diferentes;
- ocupan casi toda la memoria de la GPU con los pesos;
- suponen que un modelo de 4 bits es automáticamente cuatro veces más rápido;
- mezclan la indexación RAG con la API interactiva;
- ignoran la topología PCIe, la alimentación y la refrigeración;
- prueban el sistema con una única solicitud corta;
- no incluyen una réplica de reserva.
Un servidor para inferencia LLM debe seleccionarse en el siguiente orden: describir el perfil de carga, calcular los pesos y la caché KV, determinar el flujo de tokens, elegir la arquitectura de GPU y solo entonces configurar la CPU, la RAM, el almacenamiento NVMe, la red y el chasis. El cálculo de memoria responde a la pregunta de si la carga cabe en el sistema. Solo una prueba de carga del modelo concreto en el entorno de software seleccionado puede determinar si se cumplirán los objetivos de latencia y capacidad de usuarios.
Índice:
Caché KV: cómo el contexto y las solicitudes simultáneas consumen memoria
Por qué el entorno de software es tan importante como el hardware
