Aprendizaje automático en la nube: cómo comparar plataformas

El 18 de mayo de 2021, Google registró en sus notas oficiales que AI Platform (Unified) pasaba a llamarse Vertex AI. Los nombres, interfaces y catálogos han seguido cambiando, pero el problema de las plataformas de aprendizaje automático en la nube permanece: coordinar datos, código, cómputo, modelos y despliegues sin que cada equipo construya toda la infraestructura.

El servicio administrado sustituye una parte del trabajo operativo; no elige bien el objetivo, valida los datos ni garantiza resultados en producción. La capacidad duradera es leer una plataforma como una cadena de responsabilidades y comparar la cadena completa con el mismo experimento. Una lista de funciones o un precio por hora no revela trazabilidad, coste total ni dificultad de salida.

El modelo es una pieza pequeña del sistema

Antes de entrenar hay que localizar y versionar datos, preparar un entorno reproducible y ejecutar experimentos. Después se registra el artefacto, se despliega para inferencia por lotes o en línea, se observa su comportamiento y se decide cuándo actualizarlo o retirarlo. La guía de MLOps de Google Cloud enumera además validación de datos, pruebas, configuración, metadatos, monitorización y recursos alrededor del código del modelo.

Vertex AI reúne entrenamiento AutoML y personalizado, registro, despliegue y herramientas para aplicaciones de IA. Azure Machine Learning organiza trabajos, activos versionados, canalizaciones, modelos y endpoints dentro de espacios de trabajo. Amazon SageMaker AI proporciona entornos y servicios para construir, entrenar y desplegar; AWS documenta que el producto antes llamado Amazon SageMaker adoptó el nombre SageMaker AI el 3 de diciembre de 2024.

Las tres familias cubren gran parte del recorrido con vocabularios y límites distintos. Dos botones con el rótulo «desplegar» no implican la misma identidad, red, formato, escalado, tiempo de arranque ni factura. La unidad de comparación es el sistema que el equipo tendrá que operar, no la función aislada.

Administrado no significa delegado por completo

El proveedor puede operar centros de datos, hardware y capas del servicio. El cliente sigue decidiendo qué datos sube, quién accede, qué permisos concede, cómo configura redes y cifrado y para qué usa cada predicción. El modelo de responsabilidad compartida de Azure explicita que datos, identidades y configuraciones continúan bajo responsabilidad del cliente en todos los modelos de nube.

En aprendizaje automático queda otra capa: el proveedor no responde por una variable objetivo mal elegida, etiquetas sesgadas, fuga entre entrenamiento y prueba o una métrica que oculta errores graves. Tampoco decide si se requiere revisión humana. Un servicio de explicabilidad o equidad ofrece instrumentos; el equipo debe definir grupos, umbrales, consecuencias y acciones.

La primera tabla del piloto debería tener dos columnas: «lo opera el proveedor» y «lo demuestra nuestro equipo». Cada servicio mueve la frontera, pero no elimina la segunda columna. Si una tarea no tiene propietario, el nombre «administrado» solo ha escondido un hueco.

AutoML no elimina las decisiones

AutoML automatiza partes de preparación, selección de algoritmos o ajuste de hiperparámetros según el producto y el tipo de dato. Puede construir una línea base con rapidez. No determina si la etiqueta representa el resultado que importa, si los datos futuros se parecen a los históricos ni si el conjunto de prueba separó pacientes, clientes o periodos de forma adecuada.

Un resultado válido conserva definición de tarea, procedencia y versión de datos, código, entorno, parámetros, separación entre entrenamiento y prueba, métrica y coste de cada error. Si una interfaz produce una puntuación pero dificulta reconstruir esos elementos, ha reducido visibilidad, no riesgo.

El entrenamiento personalizado ofrece más control y permite usar marcos abiertos, pero incorpora imágenes de contenedor, bibliotecas, controladores y configuración. Guardar el archivo final no basta para reproducir un modelo. Hace falta reconstruir el camino completo y registrar quién aprobó su paso a producción.

Seis preguntas antes de elegir

1. ¿Dónde pueden vivir y circular los datos? Se dibujan regiones, redes, identidades y orígenes antes de escoger. Mover grandes conjuntos o abrir accesos entre nubes puede pesar más que una diferencia de entrenamiento. Residencia, cifrado y auditoría se verifican en la configuración concreta.

2. ¿Qué queda trazado? Cada versión debe enlazar datos, código, entorno, parámetros, métricas, evaluación y aprobación. La interfaz visual es secundaria si no permite reconstruir por qué una versión llegó a producción o volver a la anterior.

3. ¿Cómo se sirve? Un cálculo nocturno pide inferencia por lotes; una aplicación interactiva, un endpoint con latencia y disponibilidad medidas. Mantener un acelerador encendido para una carga esporádica y arrancarlo bajo demanda son decisiones diferentes.

4. ¿Cómo se detecta deterioro? CPU y memoria no bastan. Hay que vigilar cambios de entrada, calidad cuando llegan etiquetas, errores por segmento y versiones activas. La alerta debe tener dueño y respuesta: abstenerse, volver atrás, revisar o reentrenar.

5. ¿Qué permite salir? Antes de adoptar una función propietaria se exporta un modelo de prueba, se ejecuta fuera del servicio cuando sea posible y se enumeran dependencias de datos, registro, canalización, endpoint e identidad. La portabilidad perfecta es rara; el coste de salida puede medirse.

6. ¿Quién usará el sistema? Un notebook individual, un equipo regulado y cientos de modelos en producción necesitan controles distintos. Se comparan además incorporación de usuarios, separación de entornos, aprobación, cuotas, soporte y respuesta ante incidentes.

La factura sigue a la arquitectura

El coste se acumula en almacenamiento, preparación, horas de CPU o acelerador, búsquedas de hiperparámetros, endpoints activos, peticiones, registros, monitorización y transferencia. Google publica las tarifas de Vertex AI, Microsoft las de Azure Machine Learning y AWS las de SageMaker AI. Sirven para calcular un escenario; no para declarar un ganador universal.

La prueba reproduce una carga pequeña pero real y etiqueta cada recurso. Mide tiempo de preparación, entrenamiento, utilización, almacenamiento intermedio, latencia, coste en reposo, observabilidad y transferencia. Después proyecta los contadores con uso bajo, esperado y alto. Créditos y descuentos se muestran aparte para no ocultar el coste sin promoción.

También hay coste humano: horas para permisos, integración, depuración, despliegue y guardias. Una plataforma más barata por hora puede resultar más cara si exige mantener piezas adicionales; otra más integrada puede elevar la dependencia. Ambos efectos se miden, no se suponen.

Un piloto comparable y reversible

Se fija el mismo conjunto de datos, partición de prueba, código de referencia, región razonablemente equivalente y criterio de aceptación. En cada plataforma se completa un recorrido mínimo: preparar, entrenar, registrar, desplegar, monitorizar, volver a la versión predecesora y retirar. El resultado se puntúa en calidad, esfuerzo, trazabilidad, seguridad, latencia, coste y reversibilidad.

El equipo guarda infraestructura como código, contenedor, esquema de datos, formato de exportación y una lista de servicios propietarios. Ejecuta además una restauración: crear el entorno desde cero y demostrar que otro operador puede localizar el modelo, sus datos y su aprobación. Una salida teórica que nadie ha probado no es un plan.

Al final se documenta qué quedó fuera y qué restricción decide. Un equipo puede aceptar trabajo manual porque domina la identidad y red de una nube; otro priorizará cercanía a sus datos o una región concreta. Son condiciones del sistema, no propiedades universales del proveedor.

La nube puede operar infraestructura y ofrecer AutoML, canalizaciones, registros y endpoints. El equipo conserva la obligación de definir la tarea, validar datos, medir errores, controlar accesos, vigilar producción y preparar la salida. Cuando esa frontera está escrita, Vertex AI, Azure Machine Learning y SageMaker AI dejan de ser catálogos incomparables y se convierten en opciones verificables con el mismo ensayo.

El entregable final no es solo un proveedor elegido: es un registro de decisión con cargas, supuestos, mediciones, responsabilidades y señales que obligarán a revisar la elección. Así, una futura migración parte de evidencia y no de memoria institucional.