Un servidor para RAG y agentes de IA no puede elegirse únicamente por la cantidad y la potencia de sus GPU. El rendimiento depende de toda la cadena: lectura de documentos, creación del índice, búsqueda, trabajo del procesador y la memoria operativa, transferencia de datos por la red, procesamiento de contextos largos y ubicación de la caché KV. Para un proyecto piloto, los componentes pueden combinarse en un solo nodo, pero una configuración de producción debe dimensionarse según el volumen de la base de conocimientos, el número de solicitudes simultáneas y la latencia admisible.
RAG (Retrieval-Augmented Generation) es la generación de respuestas apoyada por la búsqueda en una base de conocimientos externa al modelo, ya sea la wiki interna de una empresa, fuentes de Internet o una carpeta de documentos. Antes de llamar al modelo de lenguaje de gran tamaño, el sistema encuentra fragmentos relevantes de los documentos y los añade a la consulta. Un agente de IA realiza más acciones: aclara la tarea, accede a bases de datos y API, ejecuta búsquedas adicionales, comprueba los resultados intermedios y, después, genera la respuesta.
Por tanto, una alta velocidad de generación de tokens no significa necesariamente que el usuario vaya a ver el resultado rápidamente. La GPU puede permanecer inactiva mientras el servidor lee el índice desde el almacenamiento, filtra documentos según los permisos de acceso o espera la respuesta de un sistema externo.
GPU servers
Qué etapas componen un sistema RAG
RAG tiene dos modos de funcionamiento: preparación de la base de conocimientos y procesamiento de solicitudes. Cada uno impone una carga diferente al hardware.
Preparación de la base de conocimientos
Antes de iniciar la búsqueda, el sistema debe:
- Obtener documentos de archivos, portales, correo electrónico o bases de datos.
- Extraer texto de archivos PDF, documentos ofimáticos, páginas HTML, imágenes y tablas.
- Reconocer documentos escaneados, limpiar los datos y eliminar duplicados.
- Dividir el material en fragmentos.
- Crear una representación vectorial para cada fragmento.
- Guardar el texto, los vectores, los metadatos y los permisos de acceso.
- Crear el índice de búsqueda.
- Preparar una copia de seguridad de los datos de origen y de la configuración.
En esta etapa son especialmente importantes el procesador, la RAM y el rendimiento de escritura de NVMe. Una carga masiva puede ocupar todos los núcleos, crear una cola de operaciones de entrada y salida y expulsar el índice activo de la caché del sistema.
Procesamiento de solicitudes
Después de recibir una pregunta, el sistema:
- Verifica al usuario y sus permisos.
- Crea un vector para la pregunta.
- Busca candidatos en la base de datos vectorial.
- Los filtra por idioma, fecha, tipo de documento y nivel de acceso.
- Vuelve a ordenar los fragmentos recuperados.
- Construye el contexto para el modelo de lenguaje.
- Genera la respuesta y guarda los datos de servicio.
En un escenario con agentes, esta secuencia se repite. La documentación de NVIDIA sobre RAG con agentes describe una arquitectura en la que una tarea se divide en etapas, mientras distintos miniagentes realizan la búsqueda, generan una respuesta parcial y lanzan una nueva consulta cuando los datos disponibles no son suficientes. Por tanto, una sola pregunta del usuario puede provocar decenas de llamadas a la búsqueda, al modelo y a sistemas externos.
| Etapa | Trabajo principal | Recursos clave | Posible limitación |
|---|---|---|---|
| Carga de documentos | Lectura, reconocimiento y limpieza | CPU, RAM, NVMe | Análisis lento de archivos |
| Creación de vectores | Inferencia del modelo de embeddings | GPU o CPU, RAM | Bajo rendimiento por lotes |
| Creación del índice | Escritura de la estructura de búsqueda | RAM, NVMe, CPU | Memoria insuficiente |
| Búsqueda | Lectura del índice y filtrado | RAM, NVMe, CPU | Fallos de caché del sistema |
| Reordenación | Evaluación de los fragmentos recuperados | GPU o CPU | Cola de solicitudes |
| Procesamiento del contexto | Lectura de una entrada larga por el modelo | GPU, caché KV | Espera prolongada hasta el primer token |
| Generación | Generación secuencial de la respuesta | GPU, caché KV | Baja velocidad de salida |
| Acciones del agente | Llamadas a API y ciclos repetidos | CPU, red | Acumulación de latencia |
De qué se encarga la GPU
La GPU realiza los cálculos del modelo de lenguaje, del modelo de embeddings y del modelo de reordenación. Estas tareas no tienen por qué ejecutarse en el mismo acelerador.
La memoria de vídeo no se utiliza únicamente para los pesos del modelo. También aloja:
- búferes de trabajo del motor;
- la caché KV de las solicitudes activas;
- datos temporales del procesamiento del contexto;
- modelos adicionales;
- margen para picos y fragmentación.
Por eso, un modelo que cabe durante una prueba con una sola solicitud puede fallar cuando aumenta la concurrencia. La situación contraria también es habitual: la utilización de la GPU es baja, pero las respuestas son lentas. En ese caso, el acelerador probablemente está esperando a la búsqueda, la tokenización, las lecturas del disco o una llamada de red. Comprar una GPU más potente no eliminará la latencia de otra capa.
Por qué es importante el procesador
El procesador gestiona las operaciones que rodean al modelo de lenguaje:
- extracción y limpieza de texto;
- reconocimiento de documentos;
- división en fragmentos y tokenización;
- filtrado por metadatos;
- funcionamiento de la base de datos vectorial;
- contenedores, colas y API;
- cifrado del tráfico;
- herramientas del agente de IA.
El número de núcleos es importante para la indexación en segundo plano, pero también deben tenerse en cuenta el rendimiento de un solo núcleo, el número de canales de memoria, las líneas PCIe disponibles y el esquema de conexión de los dispositivos.
Si la GPU está conectada a un procesador mientras el dispositivo de almacenamiento o el adaptador de red está gestionado por otro nodo NUMA, los datos deben desplazarse entre sockets. Con una carga elevada, esto aumenta la latencia y crea competencia por el enlace entre procesadores.
Los servidores AMD EPYC de un solo socket resultan prácticos cuando se necesitan muchas líneas PCIe y canales de memoria sin dividir los recursos entre sockets, siempre que NUMA esté configurado correctamente y se tenga en cuenta la arquitectura del procesador. Los servidores Intel Xeon están disponibles en una amplia variedad de configuraciones de uno y dos sockets. La plataforma debe elegirse por su topología PCIe real, el número de aceleradores, la capacidad de memoria y las bahías de discos disponibles, no solo por la familia del procesador.
Distribución interna de un servidor de IA con varios aceleradores: GPU, zona de procesadores, alimentación y sistema de refrigeración.
Fuente de la imagen: Dell Technologies
RAM: el índice y la caché del sistema
El tamaño de los documentos de origen no indica cuánta RAM necesitará el sistema. Después de dividirlos, un solo documento se convierte en numerosos fragmentos. Para cada uno se almacenan un vector, el texto, un identificador, metadatos y una parte de la estructura de búsqueda.
En la RAM pueden encontrarse simultáneamente:
- los vectores activos y el grafo de búsqueda;
- los índices de campos utilizados para el filtrado;
- los fragmentos consultados con frecuencia;
- la caché de archivos del sistema;
- los procesos de la base de datos y las colas de solicitudes;
- una nueva versión del índice durante su reconstrucción;
- una parte del modelo o de la caché KV descargada de la memoria de vídeo.
Una base de datos vectorial puede mantener parte de sus datos en disco. Por ejemplo, Qdrant recomienda calcular por separado los vectores, los metadatos, los índices, la replicación y el modo de almacenamiento. Cuando los datos se colocan en disco, el rendimiento depende en mayor medida del tamaño de la caché del sistema y de la latencia del almacenamiento.
Si el conjunto de trabajo no cabe en la RAM, el servidor lee páginas desde NVMe con más frecuencia. La latencia media puede parecer aceptable, mientras que algunas solicitudes tardarán notablemente más. Un archivo de intercambio no resuelve el problema porque se encuentra en el mismo almacenamiento NVMe. También se necesita margen de memoria para las actualizaciones: durante un tiempo, la versión anterior del índice sigue atendiendo solicitudes, mientras la nueva ya ocupa RAM y espacio en disco.
Por qué RAG necesita almacenamiento NVMe rápido
En el almacenamiento se guardan los documentos de origen, el texto limpio, los fragmentos, los vectores, el índice, los registros de la base de datos, los archivos de los modelos, los datos temporales de reconstrucción y las copias de seguridad.
La carga combina diferentes operaciones:
- lectura secuencial de archivos de modelos de gran tamaño;
- lectura aleatoria de pequeños bloques del índice;
- escritura sostenida durante la carga de documentos;
- escritura síncrona de los registros de la base de datos;
- lectura de la versión antigua del índice mientras se escribe la nueva;
- copias de seguridad en segundo plano.
Por tanto, la velocidad máxima indicada en las especificaciones no es el único parámetro importante. También deben evaluarse la latencia de las operaciones, el número de operaciones de entrada y salida por segundo, el rendimiento sostenido de escritura, la resistencia a las escrituras y la protección frente a pérdidas de alimentación. Un SSD de consumo puede funcionar bien en una prueba breve, pero reducir su velocidad después de llenar su caché interna.
La base de datos, los registros, los modelos y las copias de seguridad no deberían colocarse en una sola matriz sin un dimensionamiento adecuado. De lo contrario, la reconstrucción del índice o la copia de una instantánea competirán con las búsquedas de los usuarios. También es importante recordar que RAID ayuda a sobrevivir al fallo de un disco y/o a obtener rendimiento adicional, pero no sustituye a una copia de seguridad.
El almacenamiento NVMe local suele ofrecer la latencia más baja. El almacenamiento compartido simplifica el funcionamiento de varios nodos, pero añade una ruta de red. En una arquitectura compatible, NVIDIA GPUDirect Storage reduce las copias innecesarias a través de la memoria del sistema al transferir datos entre el almacenamiento y la GPU. La ventaja depende del software, el sistema de archivos, la topología PCIe y el patrón de carga.
Red: el ancho de banda no es el único factor
En un único servidor con una base de datos local, la mayor parte del intercambio de datos permanece dentro del sistema. Una vez separados los componentes, la red pasa a formar parte de cada solicitud.
Por ella circulan:
- las solicitudes y respuestas de los usuarios;
- las consultas a la base de datos vectorial;
- los fragmentos recuperados y sus metadatos;
- las llamadas a API corporativas;
- el acceso al almacenamiento compartido;
- la replicación del índice;
- los registros y las copias de seguridad;
- el intercambio entre nodos de inferencia distribuida.
El tiempo de respuesta se ve afectado por la latencia, sus variaciones, la pérdida de paquetes y la congestión de las colas. Un paquete pequeño con el resultado de una búsqueda puede retrasar la generación, aunque la utilización media del enlace sea baja.
Para un solo servidor con almacenamiento NVMe local, incluso una red de centro de datos de 1 GbE puede ser suficiente, aunque es preferible orientarse a 10 GbE. Los enlaces de 25 o 100 Gbit/s y el acceso directo remoto a memoria están justificados para almacenamiento remoto, un modelo distribuido, la replicación de un índice grande o la transferencia de la caché KV entre nodos. Las copias de seguridad y la reconstrucción del índice no deben poder ocupar sin control el mismo enlace que utilizan las solicitudes de producción.
Caché KV: el consumidor oculto de memoria de vídeo
Mientras procesa el texto, el modelo guarda datos intermedios del mecanismo de atención para los tokens que ya ha leído. Esto evita volver a calcularlos al generar cada token posterior. Estos datos se denominan caché KV.
La caché KV no es una base de datos vectorial, una copia de los documentos ni los pesos del modelo. Es la memoria de trabajo de las secuencias activas. Cuanto más largo sea el contexto y mayor sea el número de solicitudes simultáneas, más espacio ocupará.
Una estimación simplificada es:
número de capas × 2 × número de cabezas KV × tamaño de la cabeza × número de tokens × número de secuencias × tamaño de un elemento.
El factor 2 corresponde a las claves y los valores. El tamaño del elemento depende del formato de los datos, mientras que el número de cabezas KV depende de la arquitectura del modelo.
Para un modelo hipotético con 80 capas, 8 cabezas KV, un tamaño de cabeza de 128, dos bytes por valor y un contexto de 32 768 tokens, la caché necesitaría aproximadamente 10 GB para una secuencia completamente llena. Ocho secuencias independientes requerirían unos 80 GB y dieciséis, alrededor de 160 GB. Esta estimación no incluye la sobrecarga de servicio, la distribución entre GPU ni la reutilización de prefijos compartidos, pero muestra por qué un modelo puede caber con una sola solicitud y dejar de caber bajo carga.
Cómo reducir el consumo de la caché KV
Normalmente se combinan varios métodos:
- limitar la longitud habitual y máxima del contexto;
- gestionar el número de secuencias activas;
- asignar la caché por bloques y liberar las páginas no utilizadas;
- reutilizar instrucciones comunes del sistema;
- reducir la precisión del almacenamiento;
- descargar parte de la caché a la RAM;
- utilizar NVMe o almacenamiento externo para prefijos repetidos;
- separar el procesamiento de la entrada y la generación entre nodos.
Según la documentación de vLLM, almacenar la caché KV en FP8 reduce su tamaño y permite alojar más tokens. Este modo debe probarse con el modelo y el acelerador seleccionados: el ahorro de memoria puede ir acompañado de cálculos adicionales y de requisitos para el escalado de valores.
Por qué un contexto largo retrasa el primer token
Primero, el modelo debe leer las instrucciones, el historial y los documentos recuperados. La generación comienza únicamente después. El primer token puede retrasarse por un contexto excesivamente grande, una cola en la GPU, memoria de vídeo insuficiente o la imposibilidad de reutilizar un prefijo calculado previamente.
Por tanto, una ventana de contexto grande no debe considerarse una forma gratuita de mejorar la calidad. Primero conviene mejorar la búsqueda, eliminar duplicados y reordenar los fragmentos con mayor precisión, en lugar de enviar al modelo todos los documentos recuperados.
Most popular GPU
Cuellos de botella habituales
| Síntoma | Causa probable | Qué medir | Qué cambiar |
|---|---|---|---|
| La GPU está inactiva y las respuestas son lentas | Búsqueda, CPU o red | Latencia de las etapas y utilización de los núcleos | Optimizar la búsqueda y la transferencia de datos |
| El primer token tarda mucho en aparecer | Contexto grande o cola | Longitud de la entrada, tiempo en cola y procesamiento del contexto | Reducir el contexto y configurar la caché |
| La generación es lenta | Limitación de la GPU o de la memoria | Tokens por segundo y utilización de la GPU | Ajustar el modelo y el paralelismo |
| La búsqueda se ralentiza a medida que crece la base de datos | El índice no cabe en la RAM | Lecturas de NVMe y fallos de caché | Añadir RAM o cambiar el modo de almacenamiento |
| La indexación empeora el rendimiento de las respuestas | Competencia por la CPU y NVMe | Cola del disco y utilización de los núcleos | Separar los procesos o establecer límites |
| Se agota la memoria de vídeo | La caché KV está creciendo | Número de secuencias y tokens | Reducir la concurrencia o descargar la caché |
| Los filtros son lentos | Índices de metadatos inadecuados | Búsqueda con y sin filtros | Crear índices para los campos necesarios |
| La copia aumenta la latencia | Disco o enlace de red compartido | Tráfico de disco y de red | Asignar una ventana de mantenimiento o una ruta independiente |
Debe optimizarse toda la ruta de la solicitud, no una cifra aislada de una prueba de GPU. Reducir el tiempo de búsqueda en una fracción de segundo puede tener un efecto mayor que aumentar la velocidad de generación, especialmente si un agente realiza la búsqueda varias veces.
Qué métricas se deben medir
Desde el punto de vista del usuario, son importantes el tiempo total de respuesta, el tiempo hasta el primer token, la mediana, los percentiles 95 y 99, el número de pasos del agente y la tasa de errores.
Para el modelo, deben medirse:
- el número de tokens de entrada y salida;
- el tiempo en cola;
- el tiempo de procesamiento del contexto;
- la velocidad de generación;
- el uso de la memoria de vídeo;
- el número de secuencias activas;
- la ocupación y reutilización de la caché KV.
Para la búsqueda y el servidor, deben medirse los tiempos de vectorización, búsqueda, filtrado y reordenación, la utilización de cada núcleo, el uso de la RAM y la caché del sistema, la latencia de NVMe, la latencia de red y las retransmisiones.
Un valor medio oculta las ralentizaciones poco frecuentes. Si una de cada cien solicitudes tarda 20 segundos, los usuarios notarán el problema aunque la media siga siendo aceptable.
Un servidor o varios nodos
Todos los componentes pueden instalarse en un solo servidor cuando la base de datos es pequeña, el número de usuarios es limitado y las actualizaciones son poco frecuentes. Este diseño es más sencillo, menos costoso y genera menos saltos de red.
A medida que el sistema crece, aparecen limitaciones:
- la indexación compite con la inferencia del modelo;
- la base de datos vectorial se queda sin RAM;
- las operaciones de disco interfieren con la búsqueda;
- la búsqueda y la generación no pueden escalarse de forma independiente;
- el fallo de un nodo detiene todo el sistema.
Una plataforma como el Dell PowerEdge R760 puede utilizarse como nodo de cálculo o de búsqueda, pero la configuración debe comprobarse según el número de GPU compatibles, los risers, la alimentación, la refrigeración y las opciones de bahías de discos. El mismo nombre de modelo de servidor no significa que todas las configuraciones tengan las mismas capacidades.
Separar el modelo de la base de datos vectorial está justificado cuando el índice crece más rápido que la carga del modelo, los documentos se actualizan de forma continua o varios servicios utilizan la misma base de conocimientos. En ese caso, los nodos de búsqueda pueden escalarse añadiendo RAM y almacenamiento NVMe, mientras que los nodos de inferencia se amplían con GPU.
Para sistemas grandes resulta útil una canalización independiente de carga de datos. Esta analiza los documentos, crea los vectores, construye una nueva versión del índice y la valida antes de publicarla. La base de datos de producción continúa atendiendo solicitudes sin competir con la indexación masiva.
Descargar la caché KV a un almacenamiento rápido no es necesario para todos los sistemas. Puede ser útil con prefijos largos y repetidos y en conversaciones de varios pasos, pero aumenta los requisitos de red y almacenamiento. Una prueba de Dell Technologies utilizó vLLM, LMCache, almacenamiento externo y una red con acceso directo remoto a memoria. Los resultados corresponden a ese entorno de prueba concreto y no sustituyen las pruebas con la propia carga.
Cómo dimensionar la configuración
El dimensionamiento comienza con el perfil de la carga, no con el modelo del chasis.
Capa del modelo
Es necesario definir el modelo principal, el formato de los pesos, el número de GPU, el contexto habitual y máximo, la longitud de la respuesta, el número de solicitudes simultáneas y el tiempo admisible hasta el primer token. También deben tenerse en cuenta los modelos de embeddings y reordenación.
Memoria de vídeo
A los pesos del modelo deben añadirse los búferes de trabajo, la caché KV, los modelos adicionales y el margen para picos. El cálculo debe realizarse con el número real de secuencias simultáneas.
Capa de búsqueda
Deben tenerse en cuenta el número de documentos, el número medio de fragmentos, la dimensionalidad de los vectores, el formato numérico, la estructura del índice, los metadatos, las réplicas, la frecuencia de actualización y el crecimiento de la base de datos.
RAM
Deben sumarse el índice activo, los vectores, los índices de metadatos, la caché del sistema, los procesos de la base de datos, la memoria para la reconstrucción y la posible descarga desde la GPU. Se necesita margen para que los picos de carga no obliguen al sistema a leer continuamente desde el disco.
Almacenamiento
El almacenamiento NVMe debe tener capacidad suficiente para los documentos, los fragmentos, los vectores, el índice, los registros, la copia temporal creada durante la reconstrucción, los modelos, las instantáneas y las copias de seguridad locales. Deben comprobarse la resistencia a las escrituras y el rendimiento con lecturas y actualizaciones simultáneas.
Topología del servidor
La plataforma debe admitir las GPU, unidades NVMe, adaptadores de red y controladores seleccionados sin restricciones críticas por el uso compartido de líneas. También deben comprobarse la ubicación de los dispositivos respecto a los procesadores, la alimentación, la refrigeración y las opciones de ampliación. Para cargas de este tipo pueden considerarse los servidores Dell de IA, pero la configuración concreta debe ser compatible con los aceleradores y dispositivos de almacenamiento necesarios.
Prueba integral
La prueba debe reproducir la cadena de producción:
pregunta → creación del vector → búsqueda → filtrado → reordenación → construcción del contexto → procesamiento por el modelo → acciones del agente → respuesta.
Las actualizaciones en segundo plano y el registro deben ejecutarse al mismo tiempo. Probar únicamente un modelo de lenguaje con una consulta preparada solo muestra una parte del rendimiento del sistema.
Copias de seguridad y recuperación
Para la recuperación se necesita algo más que los pesos del modelo y los documentos. También deben guardarse los datos limpios, las reglas de división en fragmentos, la versión del modelo de embeddings, los parámetros del índice, los metadatos, los permisos de acceso, las instantáneas de la base de datos, las instrucciones del sistema y la configuración de las herramientas del agente. Los secretos y las claves deben almacenarse por separado.
El índice puede reconstruirse, pero en una base de datos grande el proceso tarda mucho tiempo y vuelve a cargar la CPU, la GPU y el almacenamiento NVMe. Una réplica protege frente al fallo de un nodo, pero no frente a una eliminación accidental. Por eso, las copias de seguridad deben guardarse separadas de la matriz de producción, y la pérdida de datos y el tiempo de recuperación admisibles deben definirse de antemano.
Conclusión
El rendimiento de RAG y de los agentes de IA viene determinado por el equilibrio de toda la infraestructura. La GPU ejecuta los modelos, la RAM mantiene el índice activo y la caché, NVMe proporciona acceso a los datos, el procesador se ocupa de la preparación y la búsqueda, y la red conecta los servicios separados. La caché KV, además, relaciona la longitud del contexto y la concurrencia con el consumo de memoria de vídeo. Una configuración fiable solo puede elegirse después de calcular toda la ruta de los datos y ejecutar una prueba integral bajo una carga similar a la de producción, incluidos los posibles picos.
Índice:
