Piloto automático: automatización de la gestión de la infraestructura para GenAI

¿Qué es el piloto automático?

Las operaciones de aprendizaje automático (MLOP) suelen implicar procesos manuales complejos que consumen tiempo y recursos. El piloto automático de Truefoundry tiene como objetivo eliminar estas cargas operativas, lo que permite a los desarrolladores centrarse únicamente en escribir código y a los científicos de datos perfeccionar sus modelos. El piloto automático gestiona automáticamente la optimización de los recursos y las correcciones de fiabilidad, y garantiza un flujo de trabajo fluido con una mínima intervención humana.

¿Por qué necesitamos esto?

Las preocupaciones operativas de cualquier ciclo de vida de desarrollo de software se pueden dividir en tres etapas diferentes:

1. Día 0 — Diseño y planificación: Defina la arquitectura, las estrategias de aprovisionamiento, las políticas de seguridad y los marcos de escalado antes de la implementación.
2. Día 1: Despliegue e implementación: Configure la infraestructura, implemente aplicaciones, configure la observabilidad y establezca canalizaciones de CI/CD.
3. Día 2 — Operaciones y mantenimiento: Supervise continuamente, escale automáticamente los recursos, aplique parches de seguridad y gestione la gestión de incidentes.

Estos procesos se han implementado en tres fases diferentes, que van desde la fragmentación de las responsabilidades hasta la eficiencia impulsada por la automatización.

Fase 1: Separar el desarrollo y las operaciones

Esta es la etapa en la que normalmente comienza un equipo. Las tres etapas de las operaciones suelen incluir lo siguiente en esta fase.

• Día 0: Los desarrolladores se centran en el diseño de las aplicaciones, mientras que los equipos de operaciones se ocupan de la infraestructura y la seguridad.
• Día 1: Los desarrolladores empaquetan y preparan las aplicaciones para su implementación, mientras que el equipo de operaciones se centra en aprovisionar los recursos y configurarlos.
• Día 2: Las operaciones gestionan el escalado, la supervisión y los parches de seguridad mientras los desarrolladores siguen solucionando los problemas.

Esta separación de responsabilidades crea fricciones innecesarias entre los equipos de Desarrollo y Operaciones. El problema se agrava al dificultar el intercambio de contextos debido al limitado vocabulario compartido en algunos casos.

Para una sola aplicación, esto puede traducirse en un cronograma de lanzamiento inicial de varias semanas, y cada operación del día 2 subsiguiente demora unos días, con los inevitables problemas de alineación entre los equipos de operaciones y desarrollo.

Criteria	What should you evaluate ?	Priority	TrueFoundry
Latency	Adds <10ms p95 overhead for time-to-first-token?	Must Have	✅ Supported
Data Residency	Keeps logs within your region (EU/US)?	Depends on use case	✅ Supported
Latency-Based Routing	Automatically reroutes based on real-time latency/failures?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported

AI Gateway Evaluation Checklist

A practical guide used by platform & infra teams

Fase 2: Creación de una plataforma interna

En la fase 2, una organización adopta una plataforma interna que permite al equipo de desarrollo configurar y controlar la mayoría de las palancas operativas como mejor le parezca. El equipo de operaciones pasa a desempeñar un papel más centrado en la aplicación y la estandarización, utilizando la plataforma como capa para orquestarlo.

Esta fase tiene algunos inconvenientes -

• Para los desarrolladores, esta fase significa tomar muchas decisiones en las etapas iniciales con un contexto limitado o una experiencia relevante limitada. Esto conduce a un aumento de la carga cognitiva y a una planificación de los recursos subóptima.
• Este enfoque se manifiesta como una explosión del espacio de operaciones para el equipo de operaciones. Un equipo típico puede experimentar un aumento múltiple en la cantidad de servicios y costos de infraestructura si toma una serie de decisiones subóptimas.

Aunque al principio ganamos velocidad, esto se ve compensado por la enorme complejidad del trabajo de un equipo de desarrollo, a la que inevitablemente sigue un choque de preocupaciones entre los dos equipos.

Fase 3: Automatizar la plataforma

En la tercera fase, la propia plataforma comienza a automatizar todas las preocupaciones operativas. Esto elimina la necesidad de tomar muchas decisiones en las tres etapas de la operación.

Esto significa que las 3 etapas operativas se pueden completar el mismo día sin casi ninguna elección operativa por parte de los equipos de desarrollo o de operaciones. Esto es lo que Autopilot intenta hacer.

¿Por qué ahora?

Si bien la necesidad de una mayor automatización ha sido evidente desde hace bastante tiempo, un sistema como el piloto automático se vuelve aún más esencial en el escenario actual, con la entrada en juego de los siguientes nuevos paradigmas

Microservicios

Con la adopción generalizada de la arquitectura de microservicios, la cantidad de servicios de una organización ha experimentado una explosión cámbrica. Esta conveniencia de incorporar cambios o nuevos servicios a la producción tiene la otra cara de ser más difícil de supervisar. El piloto automático es un sistema que puede optimizar estos servicios de forma fiable.

Sistemas agénticos

Los sistemas agénticos son sistemas que ejecutan tareas de forma autónoma. Necesitan una estrategia de implementación sólida y autosuficiente con una infraestructura de respaldo lo suficientemente flexible como para escalar hacia arriba y hacia abajo según sea necesario de forma dinámica. Los agentes de IA actuales de última generación dependen de una infraestructura eficiente y adaptable para funcionar de manera óptima. Se trata de sistemas dinámicos que necesitan diferentes niveles de participación humana. El despliegue generalizado de estos sistemas solo puede ser posible con un sistema en el que todos los aspectos operativos estén automatizados, y ahí es donde entra en juego el piloto automático

Estudio de caso

Para uno de los usuarios de la plataforma Truefoundry, el costo de los clústeres de desarrollo era un problema importante. Con alrededor de 200 servicios implementados, este era el caso típico de varios servicios con pequeñas ineficiencias que se acumulaban y generaban un aumento masivo de los costos generales. Cualquier intento de optimización de costos tendría que hacerse a nivel de servicio individual. Este requisito de trabajo extremo hizo que el exceso de costos empeorara y nunca se convirtiera en una prioridad.

Tras habilitar el piloto automático, este cliente pudo ahorrar 1500$ en costes en solo 2 clústeres. Además, se aplicaron más de 50 correcciones relacionadas con la confiabilidad cuando las cargas de trabajo carecían de CPU o presentaban problemas relacionados con el consumo de memoria

‍

¿Qué puede hacer Autopilot actualmente?

‍

Optimización de la CPU, la memoria y el almacenamiento

El piloto automático elimina automáticamente la configuración de la CPU y la memoria de una aplicación. El piloto automático hace esto observando dos fuentes de entrada:

• Uso histórico: El piloto automático analiza el uso histórico de una aplicación para volver con una configuración óptima en el futuro
• Ajustes en tiempo real: El piloto automático también reacciona a las alertas y otras fuentes de eventos para realizar una mitigación en tiempo real y así eliminar un problema de raíz. Esto mejora el MTTR y evita de forma proactiva muchos problemas que, de otro modo, se agravaría considerablemente.

Salud del clúster

El piloto automático también se ocupa del estado y el costo de los componentes individuales instalados en un clúster, como Istio, ArgoCD, Carpenter, etc. La falla de cualquiera de estos componentes puede tener consecuencias desastrosas para las cargas de trabajo que se ejecutan en ese clúster. El piloto automático garantiza que estos componentes funcionen de forma rentable y, al mismo tiempo, sigan funcionando. Para ello, busca de forma proactiva los picos de recursos y contabiliza dichos picos.

Capacidad de nodo

Más allá de los servicios, el piloto automático también optimiza la infraestructura subyacente a los servicios en ejecución. Esto significa recomendar la capacidad de nodo ideal para una aplicación. Esto se logra teniendo en cuenta las métricas de la aplicación, el entorno y otros factores.

Escalado automático

Muchos equipos de desarrollo optan por escalar sus aplicaciones para alcanzar la carga máxima a la que se espera que se enfrente una aplicación. Esto conlleva un gran coste adicional cuando estas réplicas adicionales no están en uso. Una solución obvia es implementar el escalado automático, pero ni siquiera eso es aplicable cuando los patrones de tráfico son impredecibles. El piloto automático revisa las métricas históricas de cada servicio y genera una recomendación para habilitar o deshabilitar el escalado automático en función del carácter histórico de la aplicación.

‍

¿Qué sigue?

Si bien ya vemos muchos beneficios en términos de costo y confiabilidad al usar el piloto automático en la producción, aún queda mucho por hacer para hacer realidad la visión de automatización completa establecida anteriormente. Algunos de los aspectos operativos que vale la pena automatizar a continuación son:

• Escalado automático periódico: predecir e implementar el escalado automático periódico, teniendo en cuenta el tráfico histórico, puede permitirnos habilitar el escalado automático incluso para cargas de trabajo con picos de trabajo.
• Recomendación de cierre automático: filtrar y cerrar los servicios o cargas de trabajo que no están en uso puede generar enormes ahorros de costos
• Comparación automática: si bien ya es posible estimar los recursos de un servicio, se puede hacer una mejor estimación si se ejecutan los puntos de referencia con tráfico en vivo o simulado y se observan las métricas empresariales afectadas. El piloto automático busca automatizar este proceso, que puede llevar mucho tiempo para la mayoría de los equipos de desarrollo.
• Optimización de la infraestructura de clústeres: la utilización de la CPU de clústeres en toda la industria es, en promedio, del 10% eslabón . Si bien la mala configuración de las aplicaciones para la CPU es una parte importante del problema, una gran parte también se debe a las ineficiencias en la distribución de la carga en la infraestructura subyacente. Esto puede deberse a que hay muchos nodos infrautilizados, a que demasiados nodos pequeños desperdicien espacio en conjuntos de demonios, etc. Arreglar las configuraciones de aprovisionamiento de infraestructura y aprovechar herramientas como karpenter a nivel de nube puede ayudar en gran medida a mejorar este aspecto.

Conclusión

El piloto automático de Truefoundry es una herramienta transformadora en la evolución de los MLOP, que aborda los desafíos operativos críticos a lo largo del ciclo de vida del desarrollo de software. El piloto automático permite a los equipos centrarse en la innovación y no en los gastos operativos, ya que automatiza la optimización de los recursos, la gestión del estado de los clústeres y el escalado automático. A medida que crece la adopción de microservicios y sistemas de agencia, la necesidad de dicha automatización se hace cada vez más urgente. Con sus capacidades actuales y su ambiciosa hoja de ruta, Autopilot está a punto de revolucionar la forma en que las organizaciones abordan la eficiencia operativa, la confiabilidad y la optimización de costos.

‍