Alojamiento para aplicaciones de IA: dimensionamiento de CPU, GPU y almacenamiento

Delimitar primero la carga de trabajo de IA

La elección del hardware empieza por la tarea, no por una GPU. En el caso de la Inferencia Un modelo ya existente procesa los datos de entrada y genera, por ejemplo, respuestas. El ajuste fino adapta un modelo preentrenado a datos adicionales o a una tarea concreta; por el contrario, el entrenamiento completo establece los pesos del modelo en el marco de un proceso de entrenamiento independiente.

Estos objetivos dan lugar a perfiles de carga distintos: un servicio de chat debe responder a las consultas, mientras que una tarea de entrenamiento procesa datos durante un periodo de tiempo prolongado y almacena resultados provisionales. Para Alojamiento de IA Por eso, debes tener en cuenta si lo más importante es el tiempo de respuesta, las solicitudes procesadas, la duración de la formación o, por ejemplo, los costes de una tarea concreta.

Documenta la versión del modelo y el tiempo de ejecución, así como el número de parámetros, la arquitectura, la precisión y la cuantificación prevista. Anota, además, las longitudes previstas de entrada y salida, las consultas simultáneas o los tamaños de lote, así como la carga máxima. De este modo, se podrán comparar las ofertas y las pruebas posteriores basándose en los mismos supuestos, en lugar de limitarse a comparar los datos nominales del hardware.

En el caso de un asistente de chat interno, una única consulta breve puede ejecutarse sin problemas, mientras que varias conversaciones largas pueden sobrecargar la memoria. La caché KV mantiene estados adicionales durante la generación de texto; sus necesidades dependen, entre otras cosas, del modelo y del procesamiento. Por lo tanto, no te limites a planificar solo para el diálogo medio, sino también para contextos largos y el uso en paralelo.

Anota también qué datos se tratan, dónde pueden almacenarse y qué nivel de disponibilidad y tiempo de recuperación se requieren. Estos objetivos operativos influyen en la elección entre un único servidor y una arquitectura más compleja. Las hipótesis siguen siendo un punto de partida: solo una prueba con una carga representativa demostrará si son viables.

CPU y RAM en fase de desarrollo

Aunque un modelo se ejecute en una GPU, la CPU colabora a lo largo de la ruta de datos. Puede recibir solicitudes, tokenizar texto, leer archivos y preparar las entradas para el procesamiento del modelo. Si esta preparación es demasiado lenta, la GPU queda a la espera de trabajo; en ese caso, un acelerador más potente no resuelve necesariamente el cuello de botella.

El Memoria de trabajo Dependiendo de la aplicación, ocupa espacio para los componentes del modelo, los datos preparados y las cachés de archivos. A esto hay que añadir el espacio de memoria necesario para los procesos que cargan y transforman los datos de entrenamiento. Por lo tanto, no solo debes planificar el modelo en sí, sino también el proceso desde el conjunto de datos hasta el lote final, y prever reservas suficientes para los picos de procesamiento.

Los DataLoader de PyTorch pueden utilizar varios trabajadores para el procesamiento paralelo de datos. Sin embargo, los trabajadores adicionales también consumen memoria; además, el espacio de memoria compartida puede llegar a ser insuficiente. Por lo tanto, aumenta su número de forma gradual y supervisa los tiempos de espera de los datos y los requisitos de memoria, en lugar de aplicar un valor fijo como recomendación general.

Un mayor número de núcleos de CPU resulta especialmente útil cuando las tareas pendientes pueden ejecutarse en paralelo. Sin embargo, si el rendimiento se ve limitado por los accesos al almacenamiento, por un único paso de procesamiento o por la propia GPU, los núcleos adicionales apenas suponen una diferencia. El comportamiento de la frecuencia de reloj también puede ser relevante para consultas breves; para más información al respecto, consulta el artículo sobre Regulador de la CPU en servidores de alojamiento.

Para modelos pequeños o consultas poco frecuentes, la inferencia en CPU es una alternativa que merece la pena considerar frente al sistema de GPU disponible de forma permanente. Compara ambas variantes con el mismo modelo, la precisión adecuada y el perfil de carga previsto. Lo decisivo es si la CPU alcanza el tiempo de respuesta requerido incluso en momentos de máxima carga y qué costes se generan realmente en el proceso.

Entender bien qué son la GPU y la VRAM

En el caso de una inferencia que se realiza íntegramente en la GPU, los pesos del modelo deben almacenarse en la memoria disponible de la GPU. El Requisitos de VRAM Pero eso no es todo: el tiempo de ejecución necesita más áreas para resultados intermedios y búferes temporales. Por lo tanto, una tarjeta en la que los pesos encajen matemáticamente no ofrece por sí sola una base segura para el funcionamiento en producción.

En la generación de texto autorregresiva se añade la caché KV. Esta almacena los estados de claves y valores ya calculados, para que puedan reutilizarse en los pasos de generación posteriores. Los contextos largos y las consultas procesadas simultáneamente pueden aumentar esta necesidad adicional de memoria; en qué medida, depende del modelo y del procesamiento.

La documentación de Transformers 4.48.2 describe, entre otras cosas, la cuantificación de la caché y la subalojamiento como formas de ahorrar VRAM. Sin embargo, el beneficio depende de la implementación y de la carga; el procesamiento adicional o las transferencias de datos pueden reducir la velocidad. Por lo tanto, comprueba conjuntamente el consumo de memoria y el tiempo de respuesta, en lugar de considerar automáticamente que un ahorro de memoria supone una mejora del rendimiento.

Durante el entrenamiento, el cálculo de inferencias resulta aún más insuficiente. Además de los pesos, se necesita memoria para almacenar los gradientes, los estados del optimizador y las activaciones guardadas. El tamaño de estas partes depende, entre otras cosas, del optimizador, la precisión y el método de entrenamiento; las secuencias más largas o los lotes más grandes pueden aumentar especialmente la memoria dedicada a las activaciones.

Para una ejecución totalmente residente en la GPU, la VRAM disponible debe poder almacenar los pesos y los datos de ejecución necesarios. Los métodos híbridos pueden mantener partes del procesamiento o los pesos del modelo fuera de la GPU; su idoneidad y el coste de las transferencias de datos dependen del tiempo de ejecución. Esto debe distinguirse de la externalización de la caché KV descrita en Transformers 4.48.2.

Analiza conjuntamente el modelo, la duración de la ejecución y el paralelismo previsto, y comprueba los niveles máximos de memoria bajo una carga representativa. Disponer de memoria suficiente para la modalidad de ejecución elegida no garantiza por sí solo el tiempo de respuesta deseado ni la carga de trabajo deseada.

Calcular de forma aproximada la memoria del modelo

Un primer cálculo de memoria parte del número de parámetros del modelo y del formato en el que se almacenan realmente sus pesos. Este cálculo proporciona un límite mínimo para esa cantidad de memoria, pero aún no supone un dimensionamiento completo del servidor GPU. En concreto, no indica cuánta memoria necesita una solicitud concreta en tiempo de ejecución.

Ejemplo ilustrativo de cálculo, no es una medición: Siete mil millones de parámetros multiplicados por dos bytes dan como resultado 14 mil millones de bytes para los pesos. Si lo dividimos entre 1.073.741.824 bytes por GiB, el resultado es de unos 13,0 GiB. Para ello, es necesario que todos los pesos considerados tengan efectivamente un tamaño uniforme de dos bytes por parámetro; otros formatos o representaciones adicionales modificarían el cálculo.

No se incluye el Caché KV para la generación de texto, los búferes temporales y la sobrecarga de ejecución. Precisamente en contextos largos, la caché puede crecer considerablemente; el número de solicitudes procesadas simultáneamente también es relevante para la reserva necesaria. La documentación sobre la caché de Transformers 4.48.2 describe, además, métodos que pueden ahorrar memoria, aunque, dependiendo del método, pueden reducir la velocidad.

Para el entrenamiento, el cálculo del peso es aún menos que suficiente. La documentación de Transformers 4.35.0 estima, para una configuración de precisión mixta a modo de ejemplo con AdamW, 18 bytes por parámetro, más las activaciones. En esta cifra se incluyen otros componentes, como los gradientes y los estados del optimizador; las activaciones dependen, entre otras cosas, de la longitud de la secuencia y del tamaño del lote.

Los 18 bytes no son un multiplicador general para todos los entrenamientos: los optimizadores, la precisión y los métodos de entrenamiento pueden modificar los requisitos. Por lo tanto, ni esta cifra ni los 13,0 GiB constituyen una recomendación para un tamaño concreto de VRAM. Para la selección, son decisivos el tiempo de ejecución concreto y los picos de memoria esperados bajo una carga representativa.

Comparar cargas de trabajo y cuellos de botella

Los mismos pesos de modelo pueden generar requisitos muy diferentes en función de la tarea. La tabla muestra posibles puntos de control, sin establecer un orden de importancia ni garantizar que se produzcan cuellos de botella. El recurso que realmente supone una limitación depende, entre otras cosas, del modelo, el flujo de datos, la paralelización y la carga.

En el caso de un asistente de chat interno, el modelo y la generación son solo una parte de la planificación. Establece una longitud máxima de entrada, una longitud esperada de salida y el número de usuarios simultáneos. A continuación, se puede comprobar si el tiempo de respuesta sigue siendo aceptable en momentos de máxima carga y si las ponderaciones, la caché y el búfer caben al mismo tiempo en la memoria disponible.

Una búsqueda de documentos con respuesta generativa sigue un proceso más largo: los documentos se importan y se procesan, se generan representaciones, se busca en un índice y se transfiere el contenido relevante al modelo de lenguaje. La importación y la búsqueda pueden tener requisitos de CPU, RAM y almacenamiento distintos a los de la generación. Por eso, conviene registrar por separado los tiempos y las necesidades de memoria de estos pasos.

Durante el ajuste fino se puede Acumulación de gradientes permiten un tamaño de lote efectivo mayor, aunque solo se procesen simultáneamente lotes individuales más pequeños. Los gradientes de varios pasos se acumulan antes de actualizar los parámetros. Esto puede resultar útil cuando la memoria es limitada, pero no garantiza un aumento del rendimiento; los pasos de procesamiento adicionales pueden suponer una pérdida de tiempo.

El suministro de datos también merece una atención especial: si el preprocesamiento o la carga van por detrás del procesamiento del modelo, una GPU más potente no siempre resulta de ayuda. Por el contrario, un flujo de datos rápido no puede sustituir a una VRAM insuficiente. Por lo tanto, compara las alternativas con los mismos datos de entrada y un perfil de carga comprensible.

Planificar el almacenamiento y las conexiones de la GPU

A la hora de planificar el almacenamiento, conviene distinguir entre el tipo de datos y el acceso: los conjuntos de datos de entrenamiento se leen repetidamente, mientras que los pesos del modelo se cargan antes de su uso. Ambos necesitan una fuente fiable desde la que puedan volver a ponerse a disposición tras un cambio de servidor. La capacidad por sí sola no basta; el tiempo de carga y los patrones de acceso también influyen en el funcionamiento.

Los datos de trabajo temporales pueden almacenarse en un disco NVMe local si se necesita un espacio de trabajo rápido. Aclara con el proveedor si estos datos se conservan tras los reinicios y los cambios de host. Por el contrario, los puntos de control y las copias de seguridad requieren una estrategia de almacenamiento planificada y una ruta de recuperación verificada; un directorio temporal local no constituye automáticamente una copia de seguridad independiente.

El almacenamiento compartido o basado en objetos puede facilitar la distribución y el almacenamiento de registros, ponderaciones y puntos de control. Lo fundamental es que la aplicación admita el tipo de acceso elegido y que los datos se puedan cargar y recuperar en el plazo previsto. Puede resultar útil disponer de un espacio de trabajo local adicional, pero este no sustituye al almacenamiento permanente.

Almacenamiento GPUDirect Permite, en condiciones adecuadas de hardware, software y sistema de archivos, una ruta de datos más directa entre el almacenamiento y la memoria de la GPU. Esto resulta especialmente interesante cuando la entrada y la salida se encuentran en la ruta crítica y la aplicación utiliza la ruta compatible. Si la CPU tiene que decodificar o preprocesar los datos primero, esto puede limitar las ventajas.

Cuando hay varias GPU, hay que distinguir entre replicación y distribución. La replicación proporciona copias del modelo para distribuir las solicitudes; no convierte automáticamente las áreas separadas de VRAM en una memoria compartida. La documentación de vLLM 0.20.1 describe este tipo de implementación en paralelo de datos; de ello no se deduce ninguna afirmación sobre ninguna otra versión en tiempo de ejecución.

Por el contrario, el paralelismo tensorial y en pipeline distribuyen partes del procesamiento y generan necesidades de comunicación. Para ello, comprueba las conexiones entre las GPU y, en el caso de varios servidores, la topología de red y la compatibilidad con el modelo y el entorno de ejecución. La documentación de vLLM 0.8.5 aborda estas estrategias para el servicio distribuido; sus indicaciones concretas dependen de la versión.

Detectar cuellos de botella bajo carga

Una comparación significativa comienza con un análisis documentado perfil de carga. Anota la versión del modelo, la precisión, la variante concreta de hardware y la versión del entorno de ejecución. Añade las longitudes típicas y máximas del contexto, las longitudes de salida y el número de consultas simultáneas. De este modo, se podrá comprobar posteriormente cualquier cambio en la infraestructura en las mismas condiciones.

Durante la inferencia, mide el tiempo hasta el primer token y la velocidad de generación. Además, registra los errores y los tiempos de respuesta tanto con una carga habitual como en los picos previstos. Un rendimiento medio elevado no es suficiente si algunas consultas tienen que esperar demasiado tiempo o fallan debido a contextos largos o a un alto grado de paralelismo.

Para el entrenamiento y el ajuste fino, lo más adecuado es partir de pasos o ejemplos procesados por unidad de tiempo. Además, observa cuánto tiempo tarda el canal de datos en recibir el siguiente lote. Los DataLoader de PyTorch pueden preparar los datos con varios trabajadores; sus necesidades de memoria y la carga sobre la memoria compartida también deben tenerse en cuenta en la evaluación.

Registra los picos de uso de la memoria de la GPU y la RAM, así como la utilización del almacenamiento y los tiempos de espera. En un sistema NVIDIA existente, el comando de lectura muestra nvidia-smi Dependiendo del dispositivo y del controlador, muestra, entre otras cosas, el estado de la GPU y el uso de la memoria. No modifica ninguna configuración operativa, pero no sustituye a las mediciones de la aplicación.

Una baja utilización de la GPU, por sí sola, no indica ningún problema ni en la CPU ni en el almacenamiento. Compáralo en el tiempo con los tiempos de espera de los datos, el historial de solicitudes y la ocupación de memoria, y, a ser posible, cambia solo un parámetro relevante por comparación. Documenta también los límites de la prueba, por ejemplo, si aún faltan picos de carga poco frecuentes o entradas especialmente largas.

Gestionar de forma fiable la infraestructura de IA

La planificación operativa debe incluir una combinación verificable de variante de GPU, controlador, marco de trabajo y tiempo de ejecución del modelo. Antes de realizar actualizaciones, comprueba qué versiones son compatibles entre sí y cómo volver a la combinación anterior en caso de problemas. En el caso de rutas de datos específicas, como GPUDirect Storage, el hardware, el software y el sistema de archivos también deben ser adecuados para el uso previsto.

Establece quién puede leer o modificar los modelos, los datos de entrenamiento, los protocolos y las interfaces de administración. Además, en el caso de los datos sensibles, la ubicación de almacenamiento, la transmisión de datos y el plazo de conservación deben ajustarse a los requisitos de protección de datos. Comprueba estos aspectos para todos los servicios implicados, no solo para el servidor en el que se ejecuta el modelo.

A Punto de control Guarda un estado del entrenamiento para reanudarlo más adelante. Planifica qué estados necesita tu software de entrenamiento para ello, con qué frecuencia se guardan y cuánto tiempo se conservan. Los pesos del modelo para la entrega y los puntos de control para la reanudación tienen fines distintos y deben identificarse en consecuencia.

El almacenamiento local de trabajo no es necesariamente permanente ni sustituye a una copia de seguridad independiente. Pregunta al proveedor qué ocurre con los datos locales en caso de reinicio, sustitución del servidor o finalización del contrato. Guarda los datos necesarios al margen del entorno de trabajo y comprueba la restauración en la práctica, incluyendo el tiempo que tarda en volver a estar operativo.

En el caso de los trabajos distribuidos, la supervisión abarca, además de las GPU individuales, los nodos, las conexiones de red y el progreso de toda la aplicación. Planifica desde qué punto guardado se reiniciará un trabajo tras un fallo y qué recursos deben estar disponibles para ello. Si las partes del modelo están distribuidas entre varios servidores, sus conexiones también influyen en el funcionamiento; las indicaciones de la documentación de vLLM 0.8.5 dependen de la versión.

Seleccionar el modelo de alojamiento y el servidor con GPU

En el caso de trabajos esporádicos, se puede contratar a un trabajador temporal Servidor con GPU Puede resultar conveniente: pagas según las condiciones concretas de la oferta por la capacidad que necesitas, en lugar de mantener una capacidad disponible de forma permanente. Compara también los plazos de puesta en marcha, la disponibilidad en el momento deseado y los costes de almacenamiento y transmisión de datos.

En caso de una carga uniforme, merece la pena optar por una infraestructura reservada de forma permanente. Puede ofrecer un mayor control sobre el tiempo de ejecución y la ruta de los datos, pero requiere una planificación propia para las actualizaciones, la supervisión y la recuperación. Un servicio de inferencia gestionado se encarga de parte de esta gestión; a cambio, comprueba qué modelos, configuraciones y rutas de datos están realmente disponibles en él.

Para la selección de la infraestructura de aprendizaje automático, se necesitan datos sobre variante concreta de GPU en cuanto a: capacidad de VRAM, ancho de banda de memoria, formatos de cálculo compatibles y diseño. No apliques sin comprobar los valores máximos de una familia de productos a todas las variantes. Compara los datos de rendimiento únicamente con sus condiciones de prueba y el modelo previsto, en lugar de basar tu decisión únicamente en un valor máximo teórico.

El tipo de escalabilidad también forma parte de la oferta: las instancias replicadas pueden distribuir las solicitudes, mientras que la división del modelo requiere el apoyo del tiempo de ejecución y la topología de conexión. La documentación de vLLM aborda el paralelismo de datos en la versión 0.20.1 y el servicio distribuido en la versión 0.8.5; estas afirmaciones no deben extrapolarse a otras versiones sin antes verificarlas.

Primero, define el modelo y el perfil de carga; a continuación, calcula la capacidad de almacenamiento y la ruta de datos, y solicita presupuestos adecuados. Después, comprueba el tiempo de respuesta, los errores y los recursos necesarios con consultas representativas o datos de entrenamiento. Encontrarás más aspectos para la clasificación en el Alojamiento en GPU para aplicaciones web. Sin esta comparación de cargas de trabajo, no es posible establecer una recomendación general sobre la GPU.