Union.ai

La idea central es que una ejecución no tiene que reiniciarse cuando falla el hardware que la sostiene. Union registra cada tarea, sus entradas y salidas, y un log de repetición. Si una GPU se cae a mitad del entrenamiento o un contenedor muere por falta de memoria, la ejecución sigue desde el punto del fallo. En el reintento también puede pedir otros recursos, de modo que un mismo paso pasa de una A100 a una H100 sin tocar una línea de código. Ahí está la diferencia entre reintentar y recuperar, y es la razón por la que los trabajos largos terminan más a menudo.

Flyte 2 elimina el lenguaje de flujos. Las tareas son funciones de Python y las tareas llaman a otras tareas. Los bucles, los condicionales y los bloques try/except son Python corriente, y el reparto es asyncio.gather. No hay un archivo YAML que describa el grafo ni un paso de compilación antes de ejecutar. Un equipo lo aprende en una tarde, y eso baja el coste de incorporar gente nueva. El mismo programa corre en local, en un devbox o en un clúster, así que el ciclo de depuración se mantiene rápido.

Cada conjunto de datos, punto de control e informe se convierte en un artefacto con nombre y versión, y la plataforma guarda qué ejecución lo produjo y qué componentes lo consumen después. Puedes unir componentes con eventos de artefactos en lugar de con un planificador. Una versión nueva de un punto de control dispara su evaluación, un modelo promocionado dispara la puntuación y un lote fresco de trazas de producción dispara la construcción del conjunto de datos. Cada componente lo puede escribir y mantener un equipo distinto, y ninguno importa el código del otro. Union publica implementaciones de referencia en GitHub, con pruebas en CI.

Una sola declaración de entorno convierte una tarea en un clúster de torchrun, con nodos y procesos obreros ya cableados. Una ejecución puede repartirse entre muchos nodos y alojar miles de acciones, que es lo que piden los entrenamientos con GRPO y LoRA. Los complementos integrados cubren Ray, Spark y Dask para cargas que quedan fuera del modelo de tareas estándar. Donde la plataforma marca diferencia es en el manejo de fallos: estos clústeres usan capacidad spot por defecto, y un nodo reclamado solo cuesta el trabajo en curso.

Puedes servir un modelo desde tus GPU con un punto final compatible con OpenAI, declarado igual que cualquier otra tarea. El escalado va de cero réplicas en los momentos tranquilos al máximo configurado, y los pesos se transmiten desde el almacenamiento de objetos directamente a la memoria de la GPU, lo que acorta el arranque en frío. La misma puerta puede gobernar las llamadas a proveedores externos de API, de manera que el equipo ve en un solo sitio el gasto y el enrutamiento de modelos. El punto final se alimenta directamente de la salida del entrenamiento, y eso elimina la copia manual a un registro aparte.

Los trabajos por lotes y los servicios de larga vida comparten modelo de programación, modelo de empaquetado y capa de planificación de GPU. No es un detalle menor. Significa que un evaluador por lotes y un punto final en vivo pueden apuntar al mismo artefacto de punto de control, y que el conjunto de GPU se reparte entre ambos. Cuando un servicio baja de réplicas, su capacidad vuelve a la cola de entrenamiento en lugar de quedarse parada. Los equipos que antes mantenían dos pilas se quedan con una, y el seguimiento de costes se simplifica.

Union corre en tu VPC sobre AWS, Azure o GCP, con opción local y de red aislada en Enterprise. El plano de control llega al clúster por un túnel de salida, y el proxy de datos que firma URL y recoge registros vive dentro de tu red. Enterprise añade SSO y SAML, RBAC personalizado, claves de cifrado gestionadas por el cliente, claves propias, puntos finales privados y un plano de control dedicado a un solo inquilino. La cobertura incluye SOC 2 Type II y un BAA de HIPAA bajo petición.