TrueFoundry: revisión de fin de año de 2023

A medida que 2023 se acerca a su fin, es hora de reflexionar sobre True Foundry viaje durante el año pasado. Esta reflexión no es solo una celebración de nuestros logros, sino también un reconocimiento de los desafíos a los que nos hemos enfrentado, una apreciación de las oportunidades que se nos han presentado y los aprendizajes que hemos aprendido. En lugar de centrarnos en los detalles operativos, te guiaremos a través de un recorrido cronológico de aprendizajes y realizaciones, basándonos en nuestra tesis sobre los MLOP y cómo se desarrollaron las cosas en la realidad.

Personalmente, soy un entusiasta del espacio, por lo que me parece adecuada la analogía tradicional de las empresas emergentes como cohetes espaciales. Si tuviera que describir los plazos imaginando que estamos construyendo un cohete, entonces... 2022 fue el año de armar el motor y realizar una prueba de conducción, ¡mientras que en 2023 marcamos el rumbo de las estrellas y aseguramos los propulsores para nuestra odisea cósmica! Tengo muchas ganas de explicarles nuestro viaje de 2023, pero permítanme poner un poco de contexto sobre TrueFoundry y el comienzo del año 2023.

TrueFoundry y el año 2022

TrueFoundry está creando una PaaS independiente de la nube en Kubernetes, que estandariza el entrenamiento y la implementación de modelos de aprendizaje automático mediante API listas para la producción y fáciles de usar para los desarrolladores.

En 2022, dedicamos tiempo a formar nuestro equipo, a desarrollar la capa básica de la plataforma en diferentes proveedores de nube y a trabajar en estrecha colaboración con nuestros primeros socios de diseño. Desarrollamos la capa principal de implementación de servicios y creamos experiencias basadas en la interfaz de usuario, la CLI y el SDK de Python, ¡y disfrutamos de la experiencia de nuestro primer cliente! Nos habíamos dado cuenta de que vender en el espacio de MLOps era difícil porque la mayoría de las empresas habían creado»algo que funcionó» y la resistencia al cambio era muy alta.

Por otro lado, habíamos validado realmente los problemas que estábamos resolviendo:

• Los modelos de aprendizaje automático no estaban llegando a la producción
• Las implementaciones de ML se retrasaron debido a la transferencia de modelos 
• Los científicos de datos se enfrentaron a importantes problemas de administración de infraestructuras
• La adopción del K8 en el mundo del aprendizaje automático fue mínima
• Los modelos de aprendizaje automático que seguían una línea de implementación diferente a la del software completo estaban muy estropeados
• Las empresas gastaban entre 2 y 10 veces más de lo necesario en trabajar con aprendizaje automático

Para entonces, habíamos identificado que estábamos resolviendo un problema importante con un enorme impacto económico, pero el desafío era que no se trataba de un problema urgente para el cliente. Lo que aprendimos de este episodio:

Resolver un problema importante es fundamental para la sostenibilidad, pero no se puede fabricar la urgencia: el cliente y el mercado lo decidirán. Es el equivalente en el mundo empresarial a las leyes de la física. No luches contra eso, ¡sigue buscando!

Arranca en 2023

Con eso, comenzamos 2023, cuando teníamos que ejecutar varios experimentos de GTM en función de lo que aprendimos al trabajar con socios de diseño. Dando algunos ejemplos concretos de los experimentos que realizamos:

1. Hipótesis de nubes cruzadas: El 84% de las empresas utilizan varias nubes y ejecutar cargas de trabajo en varios proveedores de nube es realmente difícil. Si bien esto supuso una enorme pérdida de tiempo y costes desde el punto de vista organizativo, no pudimos encontrar un único punto de contacto que tuviera este problema como su principal problema.
2. Cargas de trabajo de aprendizaje automático impulsadas por K8: El mundo del software completo ya había empezado a cosechar los beneficios de la escala de los K8 y del ecosistema que lo rodeaba, y estaba claro que el aprendizaje automático solo los acentuaría. Si bien algunos equipos dieron prioridad a la migración del K8, siempre pasó a un segundo plano en comparación con el trabajo orientado al usuario para nuestros clientes.
3. Optimización de costos: Nos dimos cuenta de que la mayoría de nuestros socios de diseño ahorraron entre un 40 y un 50% de los costos de infraestructura de nube al trabajar con nuestra plataforma, y nos dirigimos a las organizaciones que tenían la reducción de costos como su objetivo para el año. No cabe duda de que esto tuvo éxito, pero nos dimos cuenta de que el equipo encargado de reducir los costes era, en su mayoría, DevOps. Sus estatutos incluían la reducción de costes por única vez y tenían poco o ningún control sobre los flujos de trabajo de los desarrolladores, lo que volvería a poner de manifiesto el problema.

De acuerdo, hubo una serie de experimentos parcialmente exitosos o fallidos a través de los cuales nos dimos cuenta de lo frecuentes que eran los problemas que intentábamos resolver, pero aún así no pudimos encontrar el camino para identificar: una persona de cliente limitada, con un problema que es urgente y que puede identificarse externamente de forma repetida.

Esto ocurrió hasta que todo el mundo quiso trabajar con los LLM y se nos presentó una oportunidad oportuna.

Los LLM sumaron la demanda para nosotros. Todos querían trabajar con los LLM y ahora todos se enfrentaban «urgentemente» a los mismos problemas que intentábamos resolver.

Uniformidad de LLMOps, MLOps y DevOps

Explicando algunos de esos problemas aquí en el contexto de los LLM aquí:

• De la demostración a la producción: Literalmente, todo el mundo podría escribir unas cuantas instrucciones y hacer una ostentosa demo basada en GPT-4. Todos los científicos de datos estarían de acuerdo en que crear un RAG rápido con Langchain es como un par de horas de trabajo. El desafío es que estas demostraciones estén listas para la producción, lo que requiere juntar muchas piezas de manera confiable. Debe crear flujos de trabajo que faciliten a los científicos de datos pensar en estas aplicaciones en un entorno de producción desde el principio..
• A100s: ¿dónde estás?: No sabemos de ningún desarrollador que haya trabajado con LLM en su infraestructura que no se haya quejado de la falta de disponibilidad de las GPU, especialmente de las A100. ¿Cómo puedes aumentar la probabilidad de que adquieran estas GPU? Expóngalos a múltiples nubes o centros de datos, pero es un desastre lidiar con una arquitectura multinube si no tienes las herramientas adecuadas.
• Alojamiento de modelos de código abierto: El alojamiento de estos grandes modelos lingüísticos requiere un control estricto de la infraestructura, lo que aumenta la dependencia de los equipos de ciencia de datos del equipo de infraestructura. Si pudiéramos crear la plataforma adecuada donde Los equipos de DS son razonablemente «independientes de la infraestructura»; este problema se reduciría en casos de uso relativamente simples, como el alojamiento de modelos listos para usar.
• Trabajos de ajuste fino de larga duración- La mayoría de nuestros clientes están perfeccionando los LLM y algunos también están realizando una formación previa. Ahora bien, se trata de trabajos costosos y de larga duración en los que no puedes permitirte desperdiciar muchos ciclos de GPU debido a errores humanos. Las mejores prácticas de registro, monitoreo y seguimiento de experimentos son fundamentales aquí. Por ejemplo, si no guardas los puntos de control de los modelos de forma predeterminada y tu trabajo de formación se pierde dos días después de la ejecución, es una enorme pérdida de tiempo y recursos.
• Monitorización de costos- Los LLM no son baratos de entrenar ni baratos de administrar. En la actualidad, muchas empresas tienen una economía unitaria negativa cuando atienden a sus usuarios mediante LLM, suponiendo que algún día los costos bajen. La dependencia de plataformas en la nube como Sagemaker, que cobran más por las instancias EC2 y rara vez aprovechan las instancias puntuales, agrava aún más el problema. Además, los desarrolladores propietarios de los servicios tienen poca o ninguna visibilidad de los costes de infraestructura. Si bien este problema parece pronunciado en el caso de los LLM, toda la lógica mencionada anteriormente es fundamental para todo el software..
• Administración de bases de datos vectoriales y secretos: Para crear aplicaciones basadas en LLM, los desarrolladores se encontraron con múltiples aplicaciones, como diferentes bases de datos de vectores, Label studio y una variedad de servicios de API. La configuración de cada uno de ellos requiere tiempo y una infraestructura que permita compartir las claves de API en toda la organización con el nivel adecuado de supervisión. Los científicos de datos no cuentan con las herramientas adecuadas para hacer frente a este problema y la única solución es «reducir la velocidad hasta que se implementen soluciones seguras».

Estos son algunos ejemplos, pero hay muchos otros casos de uso similares, como la configuración de inferencias asíncronas, los ordenadores portátiles con respaldo de GPU, la unidad de almacenamiento compartida entre ordenadores portátiles, los tiempos de arranque en frío de grandes contenedores Docker, etc., que las empresas encontraron difíciles de resolver.

Resulta que todos nuestros clientes que utilizan LLM están utilizando algunas de estas funciones, como reducir la dependencia de los científicos de datos de la infraestructura, ahorrar costes o escalar las aplicaciones entre proveedores de nube sin quedarse atrapados, nos damos cuenta de que lo mismo ocurre con otros modelos de aprendizaje automático que no son LLM y, siendo realistas, también se aplica al resto de la pila de software. Vemos esta polinización cruzada de casos de uso para clientes que empezaron a utilizarnos para implementar software o modelos de aprendizaje automático clásicos y que ahora están viendo los beneficios de los sistemas de aprendizaje automático.

Conclusión

Esto refuerza nuestra creencia de que el tiempo que dedicamos a construir nuestra infraestructura principal, con una perspectiva obstinada de que el aprendizaje automático es software y debe implementarse de manera similar, de que los K8 ganarán a largo plazo y de que las empresas querrán evitar la dependencia de proveedores, ya sea en la nube u otros proveedores de software, está dando sus frutos para nosotros y nuestros clientes.

Así que concluyendo usando la analogía de un cohete espacial...

Si 2023 fue el año en el que cartografiamos el territorio y preparamos los propulsores, ¡esperamos con ansias un 2024 en el que encenderemos los propulsores para propulsar este cohete!

Les deseo a todos una muy ¡Feliz año nuevo en nombre de todo el equipo de TrueFoundry! Bienvenido 2024.