TrueFoundry : bilan de fin d'année 2023

Alors que 2023 touche à sa fin, il est temps de réfléchir à TrueFoundry voyage au cours de l'année écoulée. Cette réflexion n'est pas seulement une célébration de nos réalisations, mais aussi une reconnaissance des défis que nous avons relevés, une appréciation des opportunités qui nous ont été présentées et des enseignements que nous avons tirés. Au lieu de nous concentrer sur les détails opérationnels, nous vous guiderons à travers un parcours chronologique d'apprentissages et de réalisations indexés sur notre thèse sur les MLOPs et sur la façon dont les choses se sont déroulées dans la réalité.

Personnellement, je suis un passionné de l'espace. Je trouve donc que l'analogie traditionnelle entre les startups et les fusées convient parfaitement. Si je devais décrire la chronologie en imaginant que nous construisons une fusée, alors... 2022 a été l'année de l'assemblage du moteur et de la réalisation d'un essai, alors qu'en 2023, nous avons mis le cap sur les étoiles et avons sécurisé les propulseurs de notre odyssée cosmique ! Je suis très heureuse de vous présenter notre parcours en 2023, mais permettez-moi de vous situer dans le contexte de TrueFoundry et du début de l'année 2023.

TrueFoundry et année 2022

TrueFoundry développe un PaaS indépendant du cloud sur Kubernetes, qui normalise la formation et le déploiement de modèles d'apprentissage automatique à l'aide d'API prêtes pour la production et conviviales pour les développeurs.

En 2022, nous avons consacré du temps à constituer notre équipe, à développer la couche de base de la plateforme auprès de différents fournisseurs de cloud et à travailler en étroite collaboration avec nos premiers partenaires de conception. Nous avons développé la couche de déploiement des services de base et développé l'interface utilisateur, la CLI et les expériences basées sur le SDK Python et avons connu la joie de recevoir notre premier dollar client ! Nous avions réalisé qu'il était difficile de vendre de l'espace MLOps car la plupart des entreprises avaient construit »quelque chose qui a fonctionné» et la résistance au changement était très élevée.

D'un autre côté, nous avions vraiment validé les problèmes que nous étions en train de résoudre-

• Les modèles d'apprentissage automatique n'étaient pas mis en production
• Les déploiements de machine learning ont été retardés en raison des transferts de modèles 
• Les data scientists étaient confrontés à des problèmes majeurs de gestion de l'infrastructure
• L'adoption de K8 dans le monde du ML a été minime
• Les modèles d'apprentissage automatique suivant un pipeline de déploiement différent de celui des logiciels complets étaient très défaillants
• Les entreprises dépensaient 2 à 10 fois plus de coûts que ce qui était réellement nécessaire pour utiliser l'apprentissage automatique

À ce moment-là, nous avions identifié que nous étions en train de résoudre un problème majeur ayant un impact économique énorme, mais le défi était le suivant : il ne s'agissait pas d'un problème urgent pour le client. Les leçons que nous avons tirées de cet épisode...

Il est essentiel de résoudre un problème majeur pour la durabilité, mais vous ne pouvez pas créer l'urgence, c'est le client et le marché qui en décideront. C'est l'équivalent des lois de la physique dans le monde des affaires. Ne vous y opposez pas, continuez à chercher !

Coup d'envoi en 2023

C'est ainsi que nous avons commencé l'année 2023, où nous avions plusieurs expériences GTM à mener sur la base de ce que nous avons appris en travaillant avec des partenaires de conception. Donnant quelques exemples concrets des expériences que nous avons menées...

1. Hypothèse inter-nuages: 84 % des entreprises utilisent des solutions multicloud et il est très difficile d'exécuter des charges de travail entre plusieurs fournisseurs de cloud. Bien que cela ait représenté une perte de temps et d'argent considérable sur le plan organisationnel, nous n'avons pas pu trouver de manière répétée un seul point de contact qui ait eu ce problème en tête de ses préoccupations.
2. Charges de travail ML pilotées par K8s: Le monde des logiciels complets avait déjà commencé à récolter les fruits de l'évolutivité des K8 et de l'écosystème qui l'entoure et il était clair que le ML ne ferait que renforcer ces avantages. Bien que certaines équipes aient fait de la migration de K8 une priorité, celle-ci a toujours été reléguée au second plan par rapport au travail en contact avec les utilisateurs pour nos clients.
3. Optimisation des coûts: Nous avons remarqué que la plupart de nos partenaires de conception avaient réalisé des économies de 40 à 50 % sur les coûts liés à l'infrastructure cloud en utilisant notre plateforme et nous avons ciblé les organisations qui avaient pour objectif de réduire leurs coûts pour l'année. Bien sûr, cela a trouvé un écho, mais nous avons remarqué que l'équipe chargée de la réduction des coûts était principalement composée de DevOps, et que leur charte incluait une réduction ponctuelle des coûts et n'avait que peu ou pas de contrôle sur les flux de travail des développeurs, ce qui ne fera que réapparaître le problème.

D'accord, un certain nombre d'expériences, partiellement réussies ou échouées, nous ont permis de constater à quel point les problèmes que nous essayions de résoudre étaient courants, mais nous n'arrivions toujours pas à identifier : un profil client restreint, avec exactement le problème urgent et pouvant être identifié de manière répétée en externe.

Cela s'est produit jusqu'à ce que tout le monde veuille travailler avec des LLM et que l'opportunité nous a été présentée au bon moment.

LLM a regroupé la demande pour nous. Tout le monde voulait travailler avec des LLM et tout le monde était désormais confronté « de toute urgence » aux mêmes problèmes que nous essayions de résoudre.

Uniformité des LLMOP, des MLOP et des DevOps

Si l'on tient compte de certains de ces problèmes dans le contexte des LLM ici...

• De la démonstration à la production: Littéralement, tout le monde pouvait écrire quelques instructions et créer une démo chic basée sur GPT-4. Tous les data scientists conviendront que la création d'un RAG rapide à l'aide de Langchain représente quelques heures de travail. Le défi consiste à préparer ces démos pour la production, ce qui nécessite d'assembler de nombreuses pièces de manière fiable. Vous devez créer des flux de travail qui permettent aux data scientists de concevoir plus facilement ces applications dans un environnement de production dès le départ..
• A100 : où êtes-vous ?: Nous ne connaissons aucun développeur ayant travaillé avec des LLM sur son infrastructure qui ne se soit plaint de l'indisponibilité des GPU, en particulier des A100. Comment pouvez-vous augmenter la probabilité qu'ils obtiennent ces GPU ? Exposez-les à plusieurs clouds ou centres de données, mais il est difficile de gérer une architecture multicloud si vous ne disposez pas des bons outils.
• Hébergement de modèles open source: L'hébergement de ces grands modèles de langage nécessite une gestion étroite de l'infrastructure, ce qui accroît la dépendance des équipes de science des données vis-à-vis de l'équipe d'infrastructure. Si nous pouvions créer la bonne plateforme où Les équipes DS sont relativement « indépendantes de l'infrastructure ». Ce problème serait résolu pour des cas d'utilisation relativement simples, tels que l'hébergement de modèles prêts à l'emploi.
• Travaux de réglage de longue durée- La plupart de nos clients peaufinent des LLM et certains sont également en cours de préformation. Maintenant, il s'agit de tâches coûteuses de longue durée où vous ne pouvez pas vous permettre de perdre de nombreux cycles GPU à cause d'erreurs humaines. Les meilleures pratiques de journalisation, de surveillance et de suivi des expériences sont essentielles à cet égard. Par exemple, si vous n'enregistrez pas les points de contrôle des modèles par défaut et que votre tâche de formation est supprimée deux jours après son exécution, c'est une énorme perte de temps et de ressources.
• Surveillance des coûts- Les LLM ne sont ni bon marché à former, ni bon marché à gérer. De nombreuses entreprises ont actuellement une économie unitaire négative lorsqu'elles fournissent des services à leurs utilisateurs à l'aide de LLM, en supposant qu'un jour les coûts diminueront. La dépendance à l'égard de plateformes cloud telles que Sagemaker, qui facturent une prime sur les instances EC2 et exploitent rarement les instances ponctuelles, aggrave encore le problème. En outre, les développeurs propriétaires des services n'ont que peu ou pas de visibilité sur les coûts d'infrastructure. Bien que ce problème semble prononcé dans le cas des LLM, toute la logique mentionnée ci-dessus est fondamentale pour tous les logiciels.
• Gestion des bases de données vectorielles et des secrets: Pour créer des applications basées sur LLM, les développeurs se sont retrouvés aux prises avec de multiples applications, telles que différentes bases de données Vector, Label Studio et divers services d'API. Chacune d'entre elles nécessite un temps de configuration et une infrastructure permettant le partage des clés d'API au sein de l'organisation avec le niveau de surveillance approprié. Les data scientists ne disposent pas des outils appropriés pour y faire face et la seule solution est de « ralentir, jusqu'à ce que des solutions sûres soient mises en œuvre ».

Ce ne sont que quelques exemples, mais il existe de nombreux autres cas d'utilisation similaires, tels que la configuration de l'inférence asynchrone, les ordinateurs portables assistés par GPU, le partage du disque de stockage entre ordinateurs portables, les temps de démarrage à froid de grands conteneurs Docker, etc. que les entreprises ont eu du mal à résoudre.

Il s'avère que tous nos clients qui utilisent les LLM bénéficient de certaines de ces fonctionnalités, telles que la réduction de la dépendance des data scientists à l'égard de l'infrastructure, la réduction des coûts, ou la mise à l'échelle des applications entre les fournisseurs de cloud en évitant les blocages. Sachez qu'il en va de même pour d'autres modèles d'apprentissage automatique qui ne sont pas des LLM et, de manière réaliste, également pour le reste de la pile logicielle. Nous constatons cette pollinisation croisée de cas d'utilisation pour les clients qui ont commencé à nous utiliser pour déployer des logiciels ou des modèles de machine learning classiques et qui voient désormais les avantages des LLM.

Conclusion

Cela renforce notre conviction que le temps que nous avons passé à construire notre infrastructure de base, avec la conviction que le ML est un logiciel et devrait être déployé de la même manière, que K8s gagnera sur le long terme et que les entreprises voudront éviter les blocages de fournisseurs, qu'il s'agisse du cloud ou d'autres fournisseurs de logiciels, est rentable pour nous et pour nos clients.

Donc, pour conclure en utilisant l'analogie des fusées...

Si 2023 a été l'année où nous avons cartographié le territoire et préparé les propulseurs, nous attendons avec impatience 2024 où nous allumerons les propulseurs pour propulser cette fusée ! ! !

Je vous souhaite à tous une très bonne Bonne année au nom de toute l'équipe TrueFoundry ! Bienvenue en 2024.