Entrenar un modelo ya se hace junto a sus datos o detrás de una API. La evaluación sigue siendo suya

Para la mayoría de las empresas, entrenar o adaptar un modelo ha significado montar una segunda plataforma: un clúster de GPU, un planificador, imágenes de contenedor, almacenamiento de checkpoints y una copia de los datos de entrenamiento fuera del entorno gobernado donde normalmente residen. Esa segunda plataforma es cara de operar y difícil de auditar, y es una de las razones por las que tantos proyectos de fine-tuning nunca llegan a producción.

Tres anuncios en dos días, el 21 y el 22 de octubre, apuntan a que esa segunda plataforma se disuelve dentro de la primera.

Tres formas de alquilar la pila de entrenamiento

Databricks AI Runtime está en disponibilidad general. Lleva GPU sin servidor a la plataforma de Databricks, con arranques en segundos, entrenamiento en varios nodos, contenedores propios y Ray, y observabilidad en MLflow. Los permisos de Unity Catalog se aplican a los datos de entrenamiento, a los checkpoints y a los registros, las cargas se ejecutan con aislamiento a nivel de máquina virtual, y el consumo aparece en las tablas de facturación de Databricks por carga. Databricks afirma que cientos de empresas ya lo usan, entre ellas Robinhood, PicPay, Merck y FactSet.

AWS convirtió el bucle de entrenamiento en llamadas de API. Las nuevas APIs de sesiones de entrenamiento de SageMaker AI, en disponibilidad general en Virginia del Norte, Oregón y Bombay, permiten escribir el propio algoritmo de postentrenamiento, por ejemplo una recompensa a medida para aprendizaje por refuerzo, llamando a operaciones como forward_backward(), optim_step() y sample() sobre una sesión activa. SageMaker se encarga de asignar las GPU, la ejecución distribuida, la recuperación ante fallos y los checkpoints, y factura por token procesado. Por otro lado, AWS añadió Muse Glimmer, Qwen 3.8 27B y Ministral 3 a su servicio gestionado de personalización, con fine-tuning supervisado, optimización por preferencias y fine-tuning por refuerzo.

Snowflake abrió ML Jobs a contenedores propios. Los equipos pueden ya construir, validar y registrar sus propias imágenes de runtime y ejecutar ML Jobs sobre ellas, en disponibilidad general desde el 22 de octubre, con la misma opción todavía en versión preliminar para notebooks.

Qué controla usted y qué asume la plataforma

	Usted controla	La plataforma asume
Databricks AI Runtime	Código, contenedores, frameworks, política de acceso a datos	Capacidad de GPU, comprobaciones de salud, arranque, aislamiento, registros de facturación
APIs de sesiones de entrenamiento de SageMaker	El propio algoritmo de entrenamiento, paso a paso	Clúster, distribución, recuperación, checkpoints, facturación por token
Personalización gestionada de SageMaker	Datos, elección del modelo, técnica	Casi todo lo demás
ML Jobs de Snowflake con imágenes propias	Dependencias y paquetes de la imagen	Cómputo y el perímetro gobernado de los datos
Todos ellos	Evaluación, procedencia de los datos, decisión de desplegar	Nada

El cambio está en dónde se construyen los modelos

Son productos distintos con una misma dirección: entrenar se está convirtiendo en un servicio gobernado de la plataforma de datos o de la nube, no en un clúster aparte que un equipo debe mantener. Para las empresas, el efecto más importante no es la velocidad. Es que los datos de entrenamiento ya no tienen que salir del lugar donde residen sus reglas de acceso, su linaje y su registro de auditoría. Un modelo ajustado dentro de Unity Catalog o de una cuenta de Snowflake hereda los controles de los datos con los que aprendió, una conversación mucho más sencilla con el delegado de protección de datos que explicar una copia en el almacenamiento de un proveedor de GPU.

Hay un segundo motor, y Databricks lo nombra: los agentes de código ya lanzan experimentos de entrenamiento. Cuando un agente puede iniciar cien ejecuciones durante la noche, como vimos con los agentes que ejecutan experimentos en Third Moment, la infraestructura tiene que arrancar rápido, pararse barato y estar gobernada sin que una persona apruebe cada trabajo.

Lo que no se vuelve más fácil

La evaluación. Ninguno de estos servicios dice si el modelo entrenado es mejor en su tarea. La prueba de la propia Microsoft, en la que un modelo pequeño mejoró un 85% en extracción y el de frontera siguió ganando, lo recuerda: personalizar es una apuesta que hay que medir frente a usar un modelo más potente con un buen prompt, con sus datos, antes de acercarse a producción.

La disciplina de costes. Las GPU sin servidor eliminan los clústeres ociosos, no el consumo. Facturar por token o por segundo hace visible un bucle de experimentos desbocado, pero solo si alguien lee los registros de facturación. El entrenamiento lanzado por agentes necesita los mismos presupuestos con alertas que la inferencia lanzada por agentes.

La responsabilidad sobre las imágenes propias. Un contenedor propio es su cadena de suministro de software. Las imágenes propias de Snowflake y los contenedores que se llevan a Databricks trasladan a su equipo la actualización de dependencias y la gestión de vulnerabilidades.

Las regiones. Las APIs de sesiones de entrenamiento de SageMaker se lanzaron en tres regiones, ninguna en Europa, mientras que la personalización gestionada sí está disponible en Irlanda. Para una empresa española que deba entrenar con datos que no salgan de la UE, la opción hoy es más estrecha de lo que sugieren los anuncios, y en Latinoamérica ninguno de los dos servicios de SageMaker se ofrece en una región local.

El orden práctico

Si su empresa se plantea hacer fine-tuning o postentrenamiento este año, la secuencia que se sostiene es: escribir primero la evaluación, con ejemplos propios; probar la adaptación más barata, a menudo un mejor prompt o una mejor búsqueda; entrenar solo cuando la evaluación muestre que el prompt ha tocado techo; y entrenar donde ya se aplica la gobernanza de los datos. Las plataformas han facilitado mucho el tercer paso. El primero sigue siendo suyo.