TrueFoundry: terugblik op het jaar 2023

Nu 2023 ten einde loopt, is het tijd om terug te blikken op de reis van TrueFoundry in het afgelopen jaar. Deze terugblik is niet alleen een viering van onze prestaties, maar ook een erkenning van de uitdagingen die we hebben doorstaan, waardering voor de kansen die we hebben gekregen en de lessen die we hebben omarmd. In plaats van te focussen op operationele details, nemen we je mee op een chronologische reis van inzichten en realisaties, gebaseerd op onze these over MLOps — en hoe de werkelijkheid uitpakte. 

Ik ben persoonlijk een ruimtevaartliefhebber, dus ik vind de traditionele analogie van startups als raketten erg toepasselijk. Als ik de tijdlijn zou moeten beschrijven door me voor te stellen dat we een raket bouwen: 2022 was het jaar waarin we de motor in elkaar zetten en een proefrit maakten, terwijl we in 2023 koers zetten naar de sterren en de stuurturbines vastzetten voor onze kosmische odyssee! Ik vind het erg leuk om je mee te nemen door onze reis van 2023, maar laat me eerst wat context geven over TrueFoundry en het begin van het jaar 2023. 

TrueFoundry en het jaar 2022

TrueFoundry bouwt een cloud-agnostische PaaS op Kubernetes, die het trainen en deployen van Machine learning-modellen standaardiseert met behulp van productieklare, ontwikkelaarsvriendelijke API's. 

In 2022 hebben we tijd besteed aan het opbouwen van ons team, het ontwikkelen van de fundamenten van het platform over verschillende cloudproviders & hebben we nauw samengewerkt met onze eerste design partners. We hebben de kernlaag voor service deployment ontwikkeld en de UI-, CLI- en Python-SDK-gedreven ervaringen gebouwd, waarna we de vreugde van onze eerste klantervaring mochten meemaken! We realiseerden ons dat verkopen in de MLOps-ruimte moeilijk is, omdat de meeste bedrijven "iets wat werkte" hadden gebouwd en de weerstand tegen verandering erg hoog was. 

Aan de andere kant hadden we de problemen die we oplosten echt gevalideerd- 

• Machine learning-modellen haalden de productie niet
• ML-deployments vertraagden door overdrachten van modellen 
• Data scientists liepen tegen grote problemen met infrastructuurbeheer aan
• K8s-adoptie in de ML-wereld was minimaal
• Machine learning-modellen die een andere deployment pipeline volgden dan full-stack software was sterk verstoord 
• Bedrijven gaven 2 tot 10 keer meer uit aan Machine Learning dan echt nodig was

Rond deze tijd hadden we vastgesteld dat we een groot probleem oplosten met een enorme economische impact, maar de uitdaging was: dit was geen urgent probleem in de beleving van de klant. Onze les uit deze episode- 

Het oplossen van een groot pijnpunt is essentieel voor duurzaamheid, maar je kunt geen urgentie veinzen — de klant en de markt bepalen dat. Het is het zakelijke equivalent van de natuurwetten. Vecht daar niet tegen — blijf zoeken! 

De aftrap van 2023

Daarmee begonnen we aan 2023, waarin we meerdere GTM-experimenten moesten uitvoeren op basis van onze inzichten uit de samenwerking met design partners. Om een paar concrete voorbeelden te geven van de experimenten die we hebben uitgevoerd- 

1. Cross-cloud hypothese: 84% van de ondernemingen werkt cross-cloud en het draaien van workloads over meerdere cloudvendors is erg moeilijk. Hoewel dit organisatorisch een enorme verspilling van tijd & kosten was, konden we niet herhaaldelijk één aanspreekpunt vinden voor wie dit het belangrijkste probleem was.
2. K8s-gedreven ML workloads: De full-stack softwarewereld plukte al de vruchten van de schaal van K8s en het ecosysteem eromheen, en het was duidelijk dat ML deze alleen maar versterkt zou zien. Hoewel we enkele teams vonden die K8s-migratie als prioriteit hadden, raakte dit voor onze klanten altijd op de achtergrond vergeleken met klantgericht werk. 
3. Kostenoptimalisatie: We merkten dat de meeste van onze design partners 40–50% op hun cloud-infrastructuurkosten bespaarden door met ons platform te werken, en we richtten ons op organisaties die kostenverlaging als doel voor het jaar hadden. Uiteraard sloeg dit aan, maar we merkten dat het team dat verantwoordelijk was voor kostenverlaging meestal DevOps was; hun opdracht omvatte een eenmalige kostenverlaging en ze hadden weinig tot geen controle over de workflows van ontwikkelaars, waardoor het probleem opnieuw de kop opstak. 

Goed, een aantal deels succesvolle of mislukte experimenten waardoor we nog meer merkten hoe wijdverbreid de problemen waren die we probeerden op te lossen. Maar we konden nog steeds niet ons pad vinden naar het identificeren van een smalle klantpersona, met exact hetzelfde probleem dat urgent is en extern herhaaldelijk kan worden geïdentificeerd. 

Dit gebeurde totdat iedereen in de wereld met LLMs wilden werken en we een welkome kans voorgeschoteld kregen. 

LLMs bundelden de vraag voor ons. Iedereen wilde met LLMs werken en iedereen werd nu "dringend" geconfronteerd met dezelfde problemen die wij probeerden op te lossen.  

Uniformiteit van LLMOPs, MLOPs & DevOps

Om hier een aantal van die problemen in de context van LLMs te belichten- 

• Demo naar productie: Letterlijk iedereen kon een paar prompts schrijven en een gelikte op GPT-4 gebaseerde demo maken. Elke data scientist zal het erover eens zijn dat het bouwen van een snelle RAG met Langchain een paar uur werk is. De uitdaging is om deze demo's productierijp te maken, wat vereist dat veel puzzelstukjes op een betrouwbare manier samenkomen. Je moet workflows bouwen die het voor data scientists eenvoudiger maken om vanaf het begin over deze apps in een productie-omgeving na te denken. 
• A100s — waar zijn jullie?: We kennen geen enkele developer die met LLMs op hun eigen infra heeft gewerkt en niet heeft geklaagd over de onbeschikbaarheid van GPUs, vooral A100s. Hoe kun je de kans vergroten dat ze deze GPUs krijgen? Geef ze toegang tot meerdere clouds of datacenters- maar het is een chaos om met een multi-cloud architectuur te werken als je niet de juiste tools hebt. 
• Hosten van open source modellen: Het hosten van deze large language models vereist nauwe begeleiding van de infrastructuur, wat de afhankelijkheid van de Data Science-teams van het infra-team vergroot. Als we het juiste platform kunnen maken waar de DS-teams redelijk "infra-onafhankelijk" zijn, zou dit probleem worden beperkt voor relatief eenvoudige use-cases zoals out-of-the-box model hosting.
• Langlopende Fine-tuning jobs- De meeste van onze klanten fine-tunen LLMs en sommigen doen ook aan pre-training. Dit zijn langlopende, kostbare jobs waar je het je niet kunt veroorloven om veel GPU-cycles te verspillen aan menselijke fouten. Best practices voor logging, monitoring & experiment tracking zijn hier cruciaal. Als je bijvoorbeeld niet standaard model checkpoints opslaat en je training job wordt na 2 dagen uitvoering stopgezet, is dat een enorme verspilling van tijd en middelen. 
• Cost Monitoring- LLMs zijn niet goedkoop om te trainen, en ook niet goedkoop om te draaien. Veel bedrijven hebben momenteel negatieve unit economics wanneer ze hun gebruikers bedienen met LLMs, in de veronderstelling dat de kosten op een dag zullen dalen. De afhankelijkheid van cloudplatformen zoals Sagemaker, die een premium rekenen op de EC2 instances en zelden gebruikmaken van spot-instances, verergert het probleem verder. Bovendien is er weinig tot geen zichtbaarheid van infrakosten voor de developers die de eigenaren zijn van de services. Hoewel dit probleem uitgesproken lijkt in het geval van LLMs, is alle hierboven genoemde logica fundamenteel voor alle software. 
• Vector DBs & Secrets Management: Voor het bouwen van op LLM gebaseerde applicaties moesten developers zich redden met meerdere applicaties zoals verschillende Vector DBs, Label studio en een verscheidenheid aan API-services. Elk daarvan vereist tijd om op te zetten en infrastructuur om het delen van API keys binnen de organisatie met het juiste niveau van monitoring mogelijk te maken. Data scientists beschikken vaak niet over de juiste tooling om hiermee om te gaan en de enige oplossing is "vertragen, totdat er veilige oplossingen zijn geïmplementeerd". 

Dit zijn enkele voorbeelden, maar er zijn nog veel meer soortgelijke use cases- zoals het opzetten van async inferencing, GPU-backed notebooks, shared storage drives over notebooks heen, cold start-tijden van grote docker containers, etc. die bedrijven moeilijk konden oplossen. 

Het blijkt dat al onze klanten die bij ons komen voor LLMs, ervaring hebben met een aantal van deze functies, zoals het verminderen van de afhankelijkheid van Data Scientists van Infra, het besparen van kosten, of het schalen van applicaties over cloud providers heen om lock-ins te voorkomen, en zich realiseren dat hetzelfde geldt voor andere Machine Learning-modellen die geen LLMs zijn, en realistisch gezien ook van toepassing is op de rest van de software stack. We zien deze kruisbestuiving van use cases bij klanten die ons begonnen te gebruiken voor het deployen van software of klassieke ML-modellen en nu de voordelen zien met LLMs. 

Conclusie

Dit versterkt ons geloof dat de tijd die we hebben besteed aan het bouwen van onze core infrastructure, met een uitgesproken perspectief dat ML software is en op vergelijkbare wijze moet worden gedeployd, dat K8s op de lange termijn zal winnen en dat bedrijven vendor lock-ins willen vermijden, of het nu gaat om cloud- of andere softwareleveranciers- zijn vruchten afwerpt voor ons en onze klanten. 

Dus concluderend met de raket-analogie- 

Als 2023 het jaar was waarin we het terrein in kaart brachten en de thrusters klaarzetten, kijken we uit naar een 2024 waarin we de boosters ontsteken om dit raketschip voort te stuwen!!!

Wij wensen u allen een zeer Gelukkig nieuwjaar namens het gehele TrueFoundry-team! Welkom 2024.