Ein 2-köpfiges Team, das 1,5 Millionen Menschen mit TrueFoundry das Modell bedient

In den letzten Monaten hatten wir die Gelegenheit, mit einem schlanken Team zusammenzuarbeiten. Sie haben ein hochmodernes Deep-Learning-Modell entwickelt und Partnerschaften geschlossen, um es extrem talenten Nutzern zur Verfügung zu stellen.

Das letzte fehlende Stück in ihrer Erfolgsgeschichte war die Handhabung der Technik, um dies zu erreichen. Das Modell war rechenintensiv, und in dem Umfang, in dem sie dieses Modell seinen Endbenutzern anbieten wollten, benötigten sie einen zuverlässigen und leistungsstarken Infrastruktur-Stack, den beide verwalten konnten (1 DevOps Engineer und 1 ML Engineer).

Notwendigkeit einer asynchronen Bereitstellung

Das Modell wurde für die Verarbeitung von Audioeingängen unterschiedlicher Größe gebaut. Da das Modell eine hohe Verarbeitungszeit hatte (durchschnittlich ~5 Sekunden), benötigte es für jede Anfrage eine asynchrone Inferenz, um diese Anfragen zu verarbeiten und zu beantworten.

Das Team hatte einen Stack auf AWS Sagemaker entwickelt

Das Team hat seinen ersten Stack für die Bereitstellung des Modells auf Sagemaker erstellt. Als sie jedoch ihr erstes Pilotprojekt mit diesem Design durchführten, wurde ihnen klar, dass es mit diesem Stack schwierig sein würde, das Modell zuverlässig im gewünschten Maßstab bereitzustellen.

Benutzer sahen sich mit Verzögerungen von 8 bis 10 Minuten konfrontiert

Selbst nach der Verwendung des Async-Setups wurde das Endbenutzererlebnis beeinträchtigt, da die Skalierung der Instanzen einige Zeit in Anspruch nahm (8 bis 10 Minuten pro Computer), als sie diese Verzögerung hinnehmen mussten.

Während des PoC waren sie jedoch mit enormen Verzögerungen bei den Reaktionszeiten konfrontiert. Da sie mit vielen der SageMaker-bezogenen Steuerungen noch nicht vertraut waren, verloren sie wichtige Zeit damit, den Grund für die Verzögerungen zu finden. Einige der Herausforderungen, mit denen sie konfrontiert waren, waren:

1. Schwer zu lernen: Sie fanden es als DS/MLEs schwierig, die neuen Konzepte zu verstehen, die für die Verwendung von Sagemaker erforderlich waren.
2. Eingeschränkte Sicht: Eine Ursachenanalyse der Probleme, insbesondere in der Produktion, war aufgrund unintuitiver Dashboards und Benutzeroberflächen schwierig.
3. Schwer zu skalieren: Die Skalierung von Sagamaker war langsam, was zu Verzögerungen bei den Benutzerreaktionen und einem schlechten Kundenerlebnis führte.
4. Separate Quote: AWS verlangt, dass Sie gesondert dafür sprechen, Kapazität für von SageMaker reservierte GPU-Instances zu erhalten. Das Team empfand diesen Prozess als langsam und restriktiv.
5. Teuer: Die Verwendung von GPUs mit Sagemaker war für das Team teuer, da Sagemaker solche Instanzen um 25-40% höher bewertet als Raw-EKS.

Nach dem PoC verlor das Team das Vertrauen in Sagemaker und entschied, dass es eine Lösung benötigte, die die beiden (ein ML Engineer und ein DevOps Engineer) ihrer Zielgruppe von über 10 Millionen Benutzern anbieten konnten.

Bereitstellung des Systems auf TrueFoundry in <2 Tagen

Als wir anfingen, mit dem Team in Kontakt zu treten, war ihr Pilot ~7 Tage entfernt. Wir versicherten dem Team, dass wir ihnen helfen könnten, den gesamten Stack zu migrieren und ihn mithilfe der TrueFoundry-Module in <2 Tagen neu aufzubauen, sodass sie ausreichend Zeit zum Testen haben, bevor ihr Pilotprojekt in Produktion gehen musste.

Viel schnellere Skalierung

Das Team führte Benchmarks durch, indem es eine Reihe von 88 Anfragen an das Modell sendete, um die Leistung mit der von Sagemaker zu vergleichen. TrueFoundry hochskaliert 78% schneller als Sagemaker, wodurch der Benutzer viel schnellere Antworten erhält. Der Die gesamte Zeit, die für die Beantwortung der Anfrage benötigt wurde, war mit TrueFoundry um 40% schneller.

‍

‍

‍

Zuverlässige Skalierung auf über 150 Knoten

Das Team war einfach in der Lage, die Anwendung auf über 150 GPU-Knoten zu skalieren, weil:

1. Einfach zu konfigurieren: Sie mussten nur ein Argument auf der Benutzeroberfläche ändern und konnten auf einfache Weise Autoscaling-Regeln konfigurieren, die auf dem Rückstand eingehender Anfragen basierten. Dies hätte sonst mehrere Hin und Her mit dem Engineering-Team erfordert.

2. Höhere GPU-Quote: Mit TrueFoundry konnten sie sowohl Spot als auch Raw ECS verwenden. Aufgrund des GPU-Mangels bei Cloud-Anbietern bot TrueFoundry dem Team auch die Möglichkeit, über verschiedene GPU-Anbieter und Regionen hinweg zu skalieren.

3. Spot-Nutzung und Autoscaling: Das Team musste keine zusätzlichen Anstrengungen unternehmen, um die Verwendung von Spot-Instances für seine Dienste zu konfigurieren. Die Instanzen wurden auch herunterskaliert, wenn der Traffic gering war. Mithilfe des Zuverlässigkeitsmechanismus von TrueFoundry für Spot-Nutzung und Autoscaling-Einstellungen sparte das Team während der Pilotphase über 100.000$ ein.
4. Entwicklungs- und Demo-Umgebung: Das Team hat außerdem einen Entwicklungs- und Demo-Service für das Modell eingerichtet, um Feedback zu sammeln und gleichzeitig die Maschinen herunterzufahren, wenn sie nicht verwendet werden.

1,5 Millionen Nutzer werden bereits bedient und täglich werden es mehr!

Verwenden Wahre Gießerei, das 2-köpfige Team kann seine gesamte Arbeitslast verwalten, die oft auf mehr als 150 GPU-Knoten skaliert wird!! von selbst. Während der Zusammenarbeit mit uns fielen dem Team vor allem unser Kundensupport und die niedrigen Reaktionszeiten auf. TrueFoundry investiert in den Erfolg seiner Kunden und hofft, dass alle unsere Kunden in einem ähnlichen Maßstab wie bei diesem Projekt skalieren und Wirkung erzielen können!