TrueFoundry: Jahresrückblick 2023

Das Jahr 2023 neigt sich dem Ende zu und es ist Zeit, darüber nachzudenken True Foundry's Reise im vergangenen Jahr. Diese Reflexion ist nicht nur eine Würdigung unserer Erfolge, sondern auch eine Anerkennung der Herausforderungen, die wir gemeistert haben, der Wertschätzung der Möglichkeiten, die sich uns geboten haben, und der Erkenntnisse, die wir zu eigen gemacht haben. Anstatt uns auf operative Details zu konzentrieren, begleiten wir Sie durch eine chronologische Reise mit Erkenntnissen und Erkenntnissen, die auf unserer Abschlussarbeit über MLOps basieren — und wie sich die Dinge in der Realität entwickelt haben.

Ich persönlich bin ein Weltraumfan, daher finde ich die traditionelle Analogie von Startups als Raketenschiffen angemessen. Wenn ich die Zeitlinien beschreiben müsste, wenn ich mir vorstelle, wir bauen ein Raketenschiff, dann... 2022 war das Jahr, in dem der Motor zusammengebaut und eine Testfahrt gemacht wurde, wohingegen wir 2023 die Weichen für die Sterne gestellt und die Triebwerke für unsere kosmische Odyssee gesichert haben! Ich freue mich sehr, Sie durch unsere Reise des Jahres 2023 zu begleiten, aber lassen Sie mich einige Hintergrundinformationen zu TrueFoundry und dem Beginn des Jahres 2023 erläutern.

TrueFoundry und Jahr 2022

TrueFoundry entwickelt ein Cloud-unabhängiges PaaS auf Kubernetes, das das Training und den Einsatz von Machine-Learning-Modellen mithilfe produktionsbereiter, entwicklerfreundlicher APIs standardisiert.

Im Jahr 2022 haben wir Zeit damit verbracht, unser Team aufzubauen, die Sanitärschicht der Plattform für verschiedene Cloud-Anbieter zu entwickeln und eng mit unseren ersten Designpartnern zusammengearbeitet. Wir haben die zentrale Servicebereitstellungsebene entwickelt und die Benutzeroberfläche, die CLI und das Python-SDK auf Basis von Benutzeroberflächen entwickelt und hatten die Freude über unseren ersten Kundendollar erlebt! Wir hatten erkannt, dass der Verkauf im MLOps-Bereich schwierig ist, da die meisten Unternehmen bereits gebaut hatten“etwas, das funktioniert hat„und der Widerstand gegen Veränderungen war sehr hoch.

Auf der anderen Seite hatten wir die Probleme, die wir lösten, wirklich bestätigt.

• Modelle für maschinelles Lernen wurden nicht zur Serienreife gebracht
• ML-Bereitstellungen verzögerten sich aufgrund von Modellübergaben 
• Datenwissenschaftler standen vor großen Problemen im Infrastrukturmanagement
• Die Akzeptanz von K8 in der ML-Welt war minimal.
• Modelle für maschinelles Lernen, die einer anderen Bereitstellungspipeline als Full-Stack-Software folgten, waren sehr kaputt
• Unternehmen gaben für maschinelles Lernen das 2- bis 10-fache der Kosten aus, als es wirklich nötig war

Zu diesem Zeitpunkt hatten wir festgestellt, dass wir ein großes Problem mit enormen wirtschaftlichen Auswirkungen lösen würden, aber die Herausforderung bestand darin, dass dies für den Kunden kein dringendes Problem war. Was wir aus dieser Episode gelernt haben-

Die Lösung eines großen Problems ist entscheidend für Nachhaltigkeit, aber Sie können keine Dringlichkeit erfinden — das entscheiden der Kunde und der Markt. Es ist das Äquivalent der Geschäftswelt zu — Gesetzen der Physik. Kämpft nicht dagegen an — sucht weiter!

Auftakt 2023

Damit begannen wir 2023, wo wir mehrere GTM-Experimente durchführen mussten, die auf unseren Erkenntnissen aus der Zusammenarbeit mit Designpartnern beruhten. Um ein paar konkrete Beispiele für die Experimente zu nennen, die wir durchgeführt haben:

1. Cloud-übergreifende Hypothese: 84% der Unternehmen sind cloudübergreifend und es ist wirklich schwierig, Workloads über mehrere Cloud-Anbieter hinweg auszuführen. Organisatorisch war dies zwar eine enorme Zeit- und Kostensenkung, aber wir konnten keinen einzigen Ansprechpartner finden, der dies als Hauptproblem hatte.
2. K8s-getriebene ML-Workloads: Die Welt der Full-Stack-Software hatte bereits begonnen, die Vorteile der Skalierung von K8s und des sie umgebenden Ökosystems zu nutzen, und es war klar, dass ML diese nur noch verstärkt nutzen würde. Wir fanden zwar einige Teams, die die K8s-Migration als Priorität betrachteten, aber im Vergleich zur benutzerorientierten Arbeit für unsere Kunden rückte sie immer in den Hintergrund.
3. Kostenoptimierung: Wir haben festgestellt, dass die meisten unserer Designpartner durch die Verwendung unserer Plattform 40— 50% der Cloud-Infrastrukturkosten eingespart haben, und wir haben die Unternehmen ins Visier genommen, deren Jahresziel die Kostensenkung war. Natürlich fand das Anklang, aber wir stellten fest, dass das Team, das für die Kostenreduzierung zuständig war, hauptsächlich aus DevOps bestand. Ihre Satzung beinhaltete eine einmalige Kostenreduzierung und hatte wenig bis gar keine Kontrolle über die Workflows der Entwickler, wodurch das Problem erneut zutage treten wird.

Okay, also eine Reihe von teilweise erfolgreichen oder fehlgeschlagenen Experimenten, durch die wir weiter feststellten, wie weit verbreitet die Probleme waren, die wir zu lösen versuchten, aber wir konnten immer noch keinen Weg finden, um eine enge Kundenpersönlichkeit zu identifizieren, mit genau einem Problem, das dringend ist und wiederholt extern identifiziert werden kann.

Dies geschah, bis jeder auf der Welt mit LLMs arbeiten wollte und uns eine Gelegenheit zum richtigen Zeitpunkt geboten wurde.

LLMs haben die Nachfrage nach uns zusammengefasst. Jeder wollte mit LLMs arbeiten und alle standen jetzt „dringend“ vor den gleichen Problemen, die wir zu lösen versuchten.

Einheitlichkeit von LLMops, MLOps und DevOps

Um einige dieser Probleme hier im Zusammenhang mit LLMs zu berücksichtigen, hier-

• Von der Demo zur Produktion: Im wahrsten Sinne des Wortes könnte jeder ein paar Eingabeaufforderungen schreiben und eine schicke GPT-4-basierte Demo erstellen. Jeder Datenwissenschaftler würde zustimmen, dass das Erstellen eines schnellen RAG mit Langchain wie ein paar Stunden Arbeit ist. Die Herausforderung besteht darin, dass diese Demos produktionsbereit sind, was das Zusammensetzen vieler Teile auf zuverlässige Weise erfordert. Sie müssen Workflows erstellen, die es Datenwissenschaftlern erleichtern, sich diese Apps von Anfang an in einer Produktionsumgebung auszudenken..
• A100s — wo bist du?: Wir kennen keinen einzigen Entwickler, der mit LLMs in seiner Infrastruktur gearbeitet hat und sich nicht über die Nichtverfügbarkeit von GPUs, insbesondere A100s, beschwert hat. Wie kann man die Wahrscheinlichkeit erhöhen, dass sie diese GPUs bekommen? Setzen Sie sie mehreren Clouds oder Rechenzentren aus — aber Es ist ein Chaos, mit einer Multi-Cloud-Architektur umzugehen, wenn Sie nicht über die richtigen Tools verfügen.
• Hosting von Open-Source-Modellen: Das Hosten dieser großen Sprachmodelle erfordert eine enge Verwaltung der Infrastruktur, was die Abhängigkeit der Data-Science-Teams vom Infra-Team erhöht. Wenn wir die richtige Plattform schaffen könnten, wo DS-Teams sind einigermaßen „infraunabhängig“ — dieses Problem würde für relativ einfache Anwendungsfälle wie Out-of-Box-Model-Hosting behoben.
• Langfristige Feintuning-Jobs- Die meisten unserer Kunden arbeiten an der Feinabstimmung von LLMs und einige sind auch im Vortraining. Nun, das sind langwierige und teure Jobs, bei denen Sie es sich nicht leisten können, viele GPU-Zyklen durch menschliche Fehler zu verschwenden. Bewährte Verfahren zur Protokollierung, Überwachung und Versuchsverfolgung sind hier von entscheidender Bedeutung. Wenn Sie beispielsweise Modell-Checkpoints nicht standardmäßig speichern und Ihr Trainingsjob 2 Tage nach der Ausführung zunichte gemacht wird, ist das eine enorme Zeit- und Ressourcenverschwendung.
• Überwachung der Kosten- LLMs sind weder billig auszubilden noch billig zu betreiben. Viele Unternehmen schätzen die Einheitsökonomie derzeit negativ ein, wenn sie ihre Nutzer mit LLMs bedienen, und gehen davon aus, dass die Kosten eines Tages sinken werden. Die Abhängigkeit von Cloud-Plattformen wie Sagemaker, die für die EC2-Instances einen Aufpreis verlangen und Spot-Instances selten nutzen, verschärft das Problem weiter. Außerdem sind die Infrastrukturkosten für die Entwickler, die Eigentümer der Dienste sind, kaum bis gar nicht sichtbar. Während dieses Problem bei LLMs ausgeprägt zu sein scheint, ist die gesamte oben erwähnte Logik für jede Software von grundlegender Bedeutung..
• Verwaltung von Vektor-DBs und Geheimnissen: Bei der Entwicklung von LLM-basierten Anwendungen mussten sich Entwickler mit mehreren Anwendungen wie verschiedenen Vector-DBs, Label Studio und einer Vielzahl von API-Diensten auseinandersetzen. Jede von ihnen benötigt Zeit für die Einrichtung und Infrastruktur, um die gemeinsame Nutzung von API-Schlüsseln im gesamten Unternehmen mit dem richtigen Maß an Überwachung zu ermöglichen. Datenwissenschaftler sind nicht mit den richtigen Tools ausgestattet, um damit umzugehen, und die einzige Lösung besteht darin, „langsamer zu werden, bis sichere Lösungen implementiert sind“..

Dies sind einige Beispiele, aber es gibt viele andere ähnliche Anwendungsfälle — wie die Einrichtung asynchroner Inferenzierung, GPU-gestützte Notebooks, gemeinsam genutzte Speicherlaufwerke für mehrere Notebooks, Kaltstartzeiten großer Docker-Container usw., für die Unternehmen nur schwer eine Lösung gefunden haben.

Es stellt sich heraus, dass alle unsere Kunden, die LLMs nutzen, einige dieser Funktionen nutzen, wie z. B. die Verringerung der Abhängigkeit von Data Scientists von Infra oder die Kosteneinsparung oder die Skalierung von Anwendungen über Cloud-Anbieter hinweg, um Lock-ins zu vermeiden. Sie erkennen, dass dies auch für andere Machine-Learning-Modelle gilt, die keine LLMs sind, und realistischerweise auch für den Rest des Software-Stacks gilt. Wir beobachten diese wechselseitige Befruchtung von Anwendungsfällen für Kunden, die angefangen haben, uns für die Bereitstellung von Software oder klassischen ML-Modellen zu nutzen und nun von den Vorteilen von LLMs profitieren.

Fazit

Dies bestärkt uns in unserer Überzeugung, dass sich die Zeit, die wir für den Aufbau unserer Kerninfrastruktur aufgewendet haben, mit der eigensinnigen Perspektive, dass ML Software ist und in ähnlicher Weise eingesetzt werden sollte, dass K8s langfristig gewinnen werden und dass Unternehmen keine Anbieterbindung vermeiden wollen, ob es sich um Cloud- oder andere Softwareanbieter handelt, sich für uns und unsere Kunden auszahlt.

Also zum Schluss mit der Raketenschiff-Analogie...

Wenn 2023 das Jahr war, in dem wir das Gebiet kartografiert und die Triebwerke vorbereitet haben, freuen wir uns auf 2024, in dem wir die Booster zum Antrieb dieses Raketenschiffs zünden werden!!!

Ich wünsche euch allen ein herzliches Frohes neues Jahr im Namen des gesamten TrueFoundry-Teams! Willkommen 2024.