Ein 2-Personen-Team bedient 1,5 Millionen Nutzer mit TrueFoundry

In den letzten Monaten hatten wir die Gelegenheit, mit einem extrem talentierten, schlanken Team zusammenzuarbeiten. Sie haben ein hochmodernes Deep-Learning-Modell entwickelt und Partnerschaften geschlossen, um es an mehr als 10 Millionen Nutzer auszuliefern.

Das letzte fehlende Puzzleteil in ihrer Erfolgsgeschichte war die Bewältigung der technischen Herausforderungen. Das Modell war rechenintensiv, und bei dem Umfang, in dem sie dieses Modell ihren Endnutzern zur Verfügung stellen wollten, benötigten sie einen zuverlässigen und leistungsstarken Infrastruktur-Stack, den die beiden allein verwalten konnten (1 DevOps Engineer und 1 ML Engineer).

Bedarf an asynchronem Deployment

Das Modell wurde entwickelt, um Audio-Eingaben unterschiedlicher Größe zu verarbeiten. Da das Modell eine hohe Verarbeitungszeit hatte (durchschnittlich ~5 Sekunden), benötigte es eine asynchrone Inferenz für jede Anfrage, um diese Anfragen zu verarbeiten und zu beantworten.

Das Team hatte einen Stack auf AWS Sagemaker entwickelt

Das Team hat seinen ursprünglichen Stack für die Bereitstellung des Modells auf Sagemaker aufgebaut. Als sie jedoch ihren ersten Pilotversuch mit diesem Design durchführten, erkannten sie, dass eine zuverlässige Bereitstellung des Modells in der gewünschten Skalierung mit diesem Stack schwierig werden würde.

Nutzer sahen sich mit Verzögerungen von 8–10 Minuten konfrontiert

Selbst nach der Implementierung des asynchronen Setups dauerte das Hochskalieren der Instanzen viel Zeit (8–10 Minuten pro Maschine), was die Endnutzererfahrung stark beeinträchtigte, da die Nutzer diese Verzögerung in Kauf nehmen mussten.

Während des PoC kam es jedoch zu enormen Verzögerungen bei den Antwortzeiten. Da viele der Sagemaker-bezogenen Steuerungselemente für sie neu waren, verloren sie wertvolle Zeit bei der Suche nach der Ursache für die Verzögerungen. Einige der Herausforderungen, mit denen sie konfrontiert waren, lauteten:

1. Schwer zu erlernen: Als DS/MLEs fanden sie es schwierig, die neuen Konzepte zu verstehen, die für die Nutzung von Sagemaker erforderlich sind.
2. Eingeschränkte Transparenz: Die Ursachenanalyse von Problemen, insbesondere in der Produktion, war aufgrund von unintuitiven Dashboards und Schnittstellen schwierig.
3. Schwer zu skalieren: Die Skalierung von Sagemaker war langsam, was zu Verzögerungen bei den Nutzerantworten und einer schlechten Kundenerfahrung führte.
4. Separate Kontingente: AWS verlangt, dass Sie einen separaten Antrag stellen, um Kapazitäten für Sagemaker-reservierte GPU-Instanzen zu erhalten. Das Team empfand diesen Prozess als langsam und einschränkend.
5. Kostspielig: Die Nutzung von GPUs mit Sagemaker war für das Team teuer, da Sagemaker solche Instanzen um 25–40 % gegenüber rohem EKS aufschlägt.

Nach dem PoC verlor das Team das Vertrauen in Sagemaker und entschied, dass sie eine Lösung benötigten, die die beiden (ein ML Engineer und ein DevOps Engineer) für ihre Zielgruppe von über 10 Mio. Nutzern bereitstellen konnten.

Bereitstellung des Systems auf TrueFoundry in <2 Tagen

Als wir mit dem Team in Kontakt traten, war ihr Pilotversuch noch etwa 7 Tage entfernt. Wir versicherten dem Team, dass wir sie bei der Migration des gesamten Stacks und dem Wiederaufbau mithilfe der Module von TrueFoundry in <2 Tagen unterstützen können, damit sie reichlich Zeit zum Testen haben, bevor ihr Pilotprojekt in die Produktion gehen musste.

Deutlich schnelleres Skalieren

Das Team führte Benchmarks durch, indem es einen Stoß von 88 Anfragen an das Modell sendete, um die Leistung im Vergleich zu Sagemaker zu vergleichen. TrueFoundry skalierte 78 % schneller hoch als Sagemaker, was dem Nutzer wesentlich schnellere Antworten lieferte. Die Gesamtzeit bis zur Beantwortung der Anfrage war mit TrueFoundry um 40 % schneller.

‍

‍

‍

Zuverlässiges Skalieren auf 150+ Knoten

Das Team konnte die Anwendung problemlos auf über 150 GPU-Knoten skalieren, weil:

1. Einfach zu konfigurieren: Sie mussten lediglich ein Argument auf der Benutzeroberfläche ändern und konnten Autoscaling-Regeln basierend auf dem Backlog eingehender Anfragen einfach konfigurieren. Dies hätte ansonsten mehrere Abstimmungsrunden mit dem Engineering-Team erfordert.

2. Erhöhtes GPU-Kontingent: Mit TrueFoundry konnten sie sowohl Spot- als auch Raw-ECS nutzen. Aufgrund des GPU-Engpasses bei Cloud-Anbietern bot TrueFoundry dem Team auch die Option, über verschiedene GPU-Anbieter und Regionen hinweg zu skalieren.

3. Spot-Nutzung und Autoscaling: Das Team musste keinen zusätzlichen Aufwand betreiben, um die Nutzung von Spot-Instanzen für seine Dienste zu konfigurieren. Die Instanzen wurden zudem herunterskaliert, wenn der Traffic gering war. Durch die Nutzung des Zuverlässigkeitsmechanismus von TrueFoundry für die Spot-Nutzung und die Autoscaling-Einstellungen sparte das Team während der Testphase über 100.000 US-Dollar ein.
4. Dev- und Demo-Umgebung: Das Team hat außerdem einen Dev- und Demo-Dienst des Modells bereitgestellt, um Feedback zu sammeln, während die Maschinen bei Nichtgebrauch herunterskaliert werden.

Bereits 1,5 Mio. Nutzer bedient – und täglich werden es mehr!

Mithilfe von TrueFoundry kann das 2-köpfige Team seine gesamte Arbeitslast, die oft auf mehr als 150 GPU-Knoten skaliert, eigenständig verwalten! Bei der Zusammenarbeit mit uns war der bemerkenswerteste Punkt für das Team unser Kundensupport und die kurzen Antwortzeiten. TrueFoundry setzt sich voll und ganz für den Erfolg seiner Kunden ein und wir hoffen, dass alle unsere Kunden in einem ähnlichen Umfang wie bei diesem Projekt skalieren und Wirkung erzielen können!