Ajustad modelos de IA en una GPU en la nube

Si vuestro equipo está planeando un proyecto de ajuste de LLM, construyendo una canalización RAG o experimentando con un modelo multimodal que combina texto y contenido visual, el obstáculo es casi siempre el mismo: alguien os ha pedido que justifiquéis la compra de un servidor de 100 000 a 500 000 euros antes de que un solo desarrollador haya escrito una línea de código de entrenamiento o haya lanzado una aplicación. Esa conversación puede llevar meses, y mientras esperáis a que el departamento financiero apruebe el presupuesto, vuestros competidores ya han lanzado sus productos.

La alternativa es la GPU como servicio. Provisionáis una H100 o A100 cuando la necesitáis, ejecutáis vuestro trabajo de entrenamiento y pagáis solo por las horas que realmente usáis. Sin colas de adquisición, sin hardware inactivo, sin debates sobre gastos de capital. OVHcloud AI Solutions proporciona la pila completa: cuadernos gestionados, trabajos de entrenamiento sin servidor, puntos finales de inferencia y un catálogo de modelos base de pesos abiertos preentrenados, todo ello en una infraestructura soberana de la UE.

Esta guía os explica por qué el entrenamiento con GPU en la nube tiene sentido económico para la mayoría de los equipos de IA generativa, cómo es la plataforma OVHcloud en la práctica y exactamente cómo pasar de un conjunto de datos a un punto final de modelo desplegado sin tocar un solo servidor físico. Refleja una de las tendencias más claras en la infraestructura de IA generativa actual: pagad por horas de GPU, no por hardware de GPU.

Paso 1 — Inicia un AI Notebook con GPU y tu framework de ML

Inicia sesión en el Panel de Control de OVHcloud, navega a AI Notebooks y crea un nuevo notebook. Selecciona tu tipo de GPU (H100 o V100S para trabajos exigentes, L4 para experimentación más ligera), elige Jupyter o VS Code, y selecciona una imagen preconstruida que coincida con tu stack. El notebook está activo en pocos minutos con CUDA, tu framework elegido y un terminal listo para usar.
Conecta tu bucket de Object Storage como un volumen de datos en el momento del lanzamiento. Esto significa que tu conjunto de datos está disponible como una ruta local dentro del notebook sin necesidad de copiarlo manualmente, y tus puntos de control de modelo pueden escribirse directamente en el bucket durante el entrenamiento: un patrón sencillo y eficaz para cualquier equipo, no solo para ingenieros especializados en plataformas de ML.

Paso 2 — Prepara tu conjunto de datos en Object Storage

Object Storage (compatible con S3)* es la capa de datos canónica para los trabajos de entrenamiento de IA. Es compatible con S3, por lo que tus herramientas existentes (boto3, la AWS CLI, rclone) funcionan sin modificaciones. Sube aquí tu corpus de entrenamiento, conjuntos de datos tokenizados y cualquier artefacto preprocesado antes de enviar un trabajo de entrenamiento. Si tu pipeline incluye pasos de aumento de datos, ejecútalos aguas arriba y almacena el conjunto de datos resultante junto al original para la reproducibilidad y el control de versiones.

Una ventaja práctica: no hay costes de salida entre los servicios de OVHcloud. Mover datos desde Object Storage a una instancia de GPU para el entrenamiento, leer puntos de control de vuelta al almacenamiento a mitad del trabajo, o extraer artefactos de modelo a AI Deploy después del entrenamiento: ninguna de estas transferencias conlleva costes ocultos. Iterar sobre tu conjunto de datos, y sobre la calidad de los datos en general, es barato.

Paso 3: envía un trabajo de entrenamiento y elige el tipo de GPU adecuado

Empaqueta tu script de entrenamiento como una imagen de Docker (o utiliza una imagen preconstruida de OVHcloud) y envía un trabajo con la CLI de ovhai:

ovhai job run --gpu 1 --flavor h100-1-gpu --volume my-bucket@GRA/dataset:/workspace/data:ro --volume my-bucket@GRA/output:/workspace/output:rw my-registry/my-training-image:latest

Elige tu tipo de GPU según los requisitos de VRAM: un ajuste fino de un modelo de 7B normalmente cabe en una sola H100 con 80 GB de VRAM; modelos más grandes o tamaños de lote mayores pueden requerir una H200, o una solicitud multi-GPU para acelerar el entrenamiento. El trabajo se ejecuta sin servidor, monitorizado a través de registros en tiempo real en el Panel de Control o a través de la API. Cuando termina, tus artefactos de modelo están en Object Storage.

Paso 4: sirve tu modelo con AI Deploy o AI Endpoints

Para un modelo personalizado ajustado, crea una aplicación de AI Deploy que apunte a tu artefacto de modelo en Object Storage. Configura el escalado automático en función del volumen de solicitudes y los umbrales de memoria, y habilita el almacenamiento en caché de respuestas donde tu patrón de tráfico lo permita para reducir aún más el coste de inferencia: una técnica sencilla que combina bien con el procesamiento por lotes de solicitudes para aplicaciones sensibles al rendimiento. Cada capa de caché que añades reduce la latencia media y mejora la relación coste-rendimiento al mismo tiempo. Tu endpoint está activo en cuestión de minutos y se escala para adaptarse al tráfico.

Para modelos estándar de pesos abiertos, omite el paso de despliegue por completo y consulta AI Endpoints directamente. La API es compatible con el formato de cliente de OpenAI, por lo que las integraciones existentes a menudo solo requieren un cambio en la URL base.

El ajuste fino de 7B que se ejecuta en una sola H100 en unas pocas horas

La gran mayoría de los proyectos de IA generativa no se entrenan desde cero. Realizan un ajuste fino de un LLM base existente de pesos abiertos (Mistral 7B, Llama 3 8B, Falcon o una arquitectura de modelo de lenguaje similar) con un conjunto de datos específico del dominio. El ajuste fino es, en sí mismo, una forma de aprendizaje por transferencia: empiezas con un modelo que ya genera lenguaje fluido de forma general y lo especializas para tu tarea con muchas menos horas de GPU que entrenando un modelo desde cero. Utilizando técnicas como LoRA o QLoRA, y cuantización para reducir el uso de memoria durante el entrenamiento, un modelo de 7B puede completarse en una sola H100 en un plazo de 4 a 12 horas, dependiendo del tamaño del conjunto de datos y del número de épocas. La mayoría de los equipos de desarrollo encuentran esta técnica mucho más accesible en la plataforma de OVHcloud que gestionar su propia arquitectura de entrenamiento.

Este es el escenario en el que la computación de pago por uso resulta más atractiva económicamente. Ejecutas tu trabajo de ajuste fino, evalúas el resultado, ajustas el conjunto de datos o los hiperparámetros para evitar el sobreajuste en un corpus pequeño específico del dominio y vuelves a ejecutarlo. Cada iteración cuesta un número predecible de horas de GPU. Puedes realizar una docena de experimentos por menos de lo que cuesta la factura mensual de electricidad de un servidor físico, evaluar regularmente el rendimiento del modelo y mejorar sus capacidades y la calidad del contenido generado en cada pasada; después, publica el resultado una vez que supere tus expectativas.

Para modelos de tamaño medio en el rango de 13B a 70B de parámetros, es posible realizar trabajos con múltiples GPU en OVHcloud (hasta 4 GPU por trabajo bajo los límites actuales). Para el ajuste fino de 70B, planifica el uso de instancias H100 o H200 y apóyate en la cuantización para gestionar las limitaciones de VRAM y controlar el uso de memoria capa por capa.

Cuándo hablar con un arquitecto de soluciones sobre el preentrenamiento a gran escala

Si vuestro proyecto implica preentrenar un modelo desde cero con decenas o cientos de miles de millones de parámetros, ese es un desafío arquitectónico fundamentalmente diferente y un tipo de compromiso con el cliente distinto. El entrenamiento distribuido a través de muchas GPU, la estructura de red personalizada, la gestión de puntos de control a escala de petabytes y la orquestación de trabajos de larga duración no son decisiones de autoservicio; requieren herramientas dedicadas y una arquitectura de referencia construida para vuestro caso.

Para el preentrenamiento a gran escala, el primer paso correcto es una conversación con un arquitecto de soluciones de IA de OVHcloud. Pueden evaluar vuestros requisitos de computación, discutir las opciones de clúster de GPU y la herramienta adecuada para cada etapa, y ayudaros a diseñar una arquitectura de entrenamiento que se ajuste a vuestra escala y a vuestra mejora de rendimiento objetivo. El enlace para solicitar esa conversación se encuentra en la sección 'Empezar' a continuación.

Comparativa de costes: servidor H100 local frente a pago por uso de OVHcloud

Coste de adquisición, electricidad, operaciones y amortización
El coste total de un servidor GPU local incluye más que el precio de etiqueta. Un sistema típico de 8×H100 SXM cuesta entre 150.000 y 250.000 euros en su adquisición. Añadid a eso: actualizaciones de la infraestructura eléctrica, refrigeración, espacio en rack, un contrato de mantenimiento de tres años y el salario del ingeniero responsable de mantenerlo en funcionamiento. Amortizado a lo largo de 36 meses, el coste total de propiedad se desglosa en una cantidad sustancialmente mayor que el precio de lista del hardware por sí solo.

En OVHcloud, no hay coste de adquisición. Pagáis solo por las horas de GPU que consumís, facturadas por minuto, sin compromiso y sin coste por inactividad. Si vuestro proyecto se cancela, no pagáis nada más allá de lo que ya hayáis ejecutado.

Sin exposición a la CLOUD Act en los datos de entrenamiento

La CLOUD Act de EE. UU. permite a las autoridades estadounidenses obligar a las empresas con sede en EE. UU. a presentar datos almacenados en cualquier parte del mundo, incluidos los datos alojados en centros de datos europeos por proveedores de nube estadounidenses. Si vuestro corpus de entrenamiento contiene datos personales, registros sanitarios, documentos legales, transacciones financieras o cualquier otra categoría regulada, entrenar en una infraestructura sujeta a la legislación estadounidense crea un riesgo de cumplimiento que es difícil de mitigar completamente solo mediante medidas contractuales.

OVHcloud es una empresa europea sin matriz estadounidense. No existe una dependencia estructural de la CLOUD Act. Vuestros datos de entrenamiento permanecen en la jurisdicción de la UE bajo la legislación de la UE. Para los equipos de sectores regulados (sanidad, servicios financieros, tecnología legal, sector público), esto no es una ventaja teórica; es un requisito y, cada vez más, el criterio clave por el que preguntan los equipos de compras desde el principio.

Sustrato de la Ley de IA de la UE, RGPD, HDS e ISO 27701

La infraestructura de OVHcloud cuenta con las certificaciones ISO 27001, ISO 27017, ISO 27018 e ISO 27701. La certificación HDS es relevante para los equipos que entrenan modelos con datos sanitarios en Francia. Para el RGPD, los datos de entrenamiento procesados en OVHcloud se almacenan y procesan dentro de la UE bajo la legislación de la UE, lo que simplifica significativamente las Evaluaciones de Impacto relativas a la Protección de Datos y ayuda a garantizar el cumplimiento continuo.

Una aclaración importante: OVHcloud proporciona el sustrato de infraestructura soberana. El cumplimiento de la Ley de IA de la UE a nivel de modelo (fichas de modelo, detección de sesgos, registros de auditoría, obligaciones de transparencia) sigue siendo responsabilidad vuestra como desarrolladores del sistema de IA. La infraestructura soberana respalda vuestras obligaciones de cumplimiento; no las cumple automáticamente.

Por parte de los analistas, GigaOM Radar reconoció a OVHcloud por su interconectividad y disponibilidad soberana, e IDC nombró a OVHcloud un actor importante (Major Player) en IaaS de nube pública europea.