La visión de TrueFoundry

Diseñado para la velocidad: ~ 10 ms de latencia, incluso bajo carga
¡Una forma increíblemente rápida de crear, rastrear e implementar sus modelos!
- Gestiona más de 350 RPS en solo 1 vCPU, sin necesidad de ajustes
- Listo para la producción con soporte empresarial completo
Visión general: una plataforma para desarrolladores que facilite la creación y la administración de servicios siguiendo todas las mejores prácticas y brinde una imagen general completa de la infraestructura, incluida la supervisión de los sistemas, los datos, el costo y el impacto, ¡con un enfoque inicial en el aprendizaje automático!
Visión para TrueFoundry (5 a 10 años)
En esencia, TrueFoundry tiene como objetivo hacer que la experiencia de los desarrolladores sea perfecta para ejecutar y administrar microservicios, donde con el nivel adecuado de abstracciones, los desarrolladores pueden centrarse en escribir la lógica empresarial a velocidades de iteración muy altas.
Imagina un flujo en el que, después de escribir el código, puedo llamar a un genio y explicarle mis requisitos, como el tipo de servicio (Serverless, CronJob, una base de datos, un servicio de API), los requisitos de recursos, como la CPU, la memoria, etc., y el genio crea el servicio con las mejores prácticas, como Gitops, Infrastructure as Code (IAC) y, a continuación, muestra un panel con todas las métricas creadas.
Queremos poder lograr lo siguiente con servicefoundry:
Aprovisionamiento de infraestructura centralizado mediante IAC
ServiceFoundry aprovisionará y alojará los componentes de infraestructura de código abierto más utilizados en la nube del usuario. Algunos ejemplos de esto pueden ser:
- Lance el clúster de Kubernetes con las prácticas recomendadas de seguridad configuradas.
- Instale componentes de infraestructura centralizados (o utilice servicios gestionados) como Kafka, Spark, Redis, Prometheus, Grafana, etc.
- Podemos usar los servicios gestionados en la nube para algunos de ellos, como AWS Elastic Search.
- Lance bases de datos y capas de almacenamiento. (utilice las versiones administradas por ahora)
- Sistemas de orquestación de oleoductos como Airflow, Argo, etc.
- CI/CD (Github Actions, Gitlab, canalizaciones de código de AWS)
- Agregación de registros (ELK, EFK)
- Monitorización (métricas estándar y personalizadas)
- Alertar

Crear servicio
- Cree e implemente servicios basados en plantillas configurables. ServiceFoundry será un conjunto de principios obstinados para automatizar lo siguiente:
- Administración y empaquetado de dependencias (Docker, Zip)
- Probando
- Administración de la configuración (configuraciones estáticas y que cambian dinámicamente)
- Aprovisionamiento de infraestructura (además de la infraestructura centralizada aprovisionada anteriormente)
- Configuración de escalado automático
- CI/CD
- Agregación de registros
- Generación de paneles con métricas estándar (los usuarios pueden agregar métricas personalizadas)
- Alertar
Al igual que lo anterior, también queremos hacer lo mismo para los modelos ML y las bases de datos.

ServiceFoundry tendrá como objetivo agilizar el despliegue y la supervisión de los tipos de servicios estándar:
- Servicio de API LoadBalanced (con ajuste de escala automático en diferentes parámetros)
- Servicio de trabajos (trabajos de Cron, trabajos activados por eventos)
- Sin servidor
- Servicios de Stateful
- Sitio web estático
Catálogo y gráfico de servicios
Todos los servicios creados con ServiceFoundry se pueden ver en un solo lugar junto con sus metadatos completos. Este catálogo también mostrará todos los entornos de cada aplicación, como los de desarrollo, ensayo y producción. Esto lleva a un portal de plataforma para desarrolladores donde los desarrolladores y los líderes empresariales pueden ver los servicios que se ejecutan en la organización. Algunos de los metadatos clave asociados a cada servicio son:
- Enlace al repositorio de Github
- Configuración
- Enlaces de monitoreo
- Equipo y propietarios
- Posibilidad de añadir miembros con diferentes controles de acceso.
- Coste


TrueFoundry MLOps (primera plataforma de aprendizaje automático)
El objetivo inicial de TrueFoundry será proporcionar una plataforma mLOps perfecta que se centre en el proceso posterior a la creación de modelos y facilite a los científicos de datos la implementación, el monitoreo y el reentrenamiento de sus modelos.
Una canalización de aprendizaje automático se compone de la siguiente infraestructura centralizada:

Una breve explicación de los diferentes pasos involucrados es:
- Canalización de datos y almacén de funciones: Básicamente, se trata de un problema de big data en el que necesitamos que las funciones que se utilizarán en el modelo se calculen a partir del lago de datos y estén disponibles en los plazos requeridos tanto para la formación como para la producción sin disparidades. Por lo general, utiliza un motor de orquestación del flujo de trabajo, como los canales Airflow, Argo y Kubeflow.
- Entrenamiento modelo: El entrenamiento de modelos es esencialmente un trabajo distribuido con un uso intensivo de cómputos que puede ejecutarse en varias máquinas. También debería ofrecer una resiliencia integrada mediante el almacenamiento y la restauración de puntos de control.
- Modelo de servicio: Básicamente, se trata de un microservicio que recibe solicitudes para hacer las predicciones del modelo y puede tener requisitos variados, como GPU, altos requisitos de computación y memoria. Por lo general, cada modelo se aloja como un único microservicio; por lo tanto, cuando un equipo escala a decenas de modelos, se convierte en un problema gestionar decenas de microservicios, lo que en sí mismo es un gran problema.
- Monitorización del modelo: Esto incluye tanto la supervisión de las métricas del sistema como la supervisión específica del aprendizaje automático relacionada con el rendimiento y el deterioro del modelo. Esto también requiere que los sistemas almacenen los datos registrados, ejecuten agregaciones en ellos y, por último, calculen las métricas.
- Gestión de modelos: Esto rastrea todos los datos relacionados con los modelos y sus diferentes versiones y experimentos. Es muy útil para depurar problemas más adelante y revertirlos.
Debido a la gran cantidad de partes móviles y diferentes tecnologías involucradas, generalmente varias personas participan en un proyecto de ML, como DataEngineer, Datascientist, ML Engineer, DevOps y Product Manager. Un proyecto exitoso requiere la coordinación entre todas estas diferentes personas, lo que provoca muchos retrasos y reduce la velocidad de un científico de datos.
Un flujo de trabajo típico en las empresas para una canalización de aprendizaje automático tiene un aspecto similar al siguiente:

Objetivo clave detrás de la plataforma ML
Queremos automatizar las partes del proceso de aprendizaje automático que se pueden automatizar y permitir que los científicos de datos puedan probar sus modelos en producción e iterarlos rápidamente con la menor dependencia posible de otros equipos. Nos motivan los productos creados por los equipos de plataformas de las principales empresas de tecnología, que permiten a todos los equipos avanzar mucho más rápido e implementarlos e iterarlos por su cuenta.
Ahora no nos ocupamos de ninguno de los problemas relacionados con los datos; esa sección se presentará más adelante.
Una plataforma de aprendizaje automático clave se compone de los siguientes servicios (además de la infraestructura central)
- Capacitación (un trabajo programado con diferentes factores desencadenantes)
- Model Service (un servicio de API LoadBalanced)
- Almacenamiento (artefactos, conjuntos de datos, datos de inferencia de modelos)
- ML Monitoring Service (un servicio para calcular métricas a partir de datos)
- Servicio de ingeniería de funciones
Si podemos implementar fácilmente estos servicios, mantener el control de versiones en las diferentes etapas y generar monitoreo para cada una de ellas, el problema de ML Ops será un problema mucho más simple.
Este blog se publicó por primera vez en Medium en https://abhishekch09.medium.com/d8e159743a4b
TrueFoundry AI Gateway ofrece una latencia de entre 3 y 4 ms, gestiona más de 350 RPS en una vCPU, se escala horizontalmente con facilidad y está listo para la producción, mientras que LitellM presenta una latencia alta, tiene dificultades para superar un RPS moderado, carece de escalado integrado y es ideal para cargas de trabajo ligeras o de prototipos.
La forma más rápida de crear, gobernar y escalar su IA


















.png)


.webp)




.webp)







