Wie Veriff die Bereitstellungszeit mithilfe von Amazon SageMaker-Endpunkten mit mehreren Modellen um 80 % verkürzte | Amazon Web Services

Veriff ist ein Plattformpartner zur Identitätsüberprüfung für innovative, wachstumsorientierte Organisationen, darunter Pioniere in den Bereichen Finanzdienstleistungen, FinTech, Krypto, Gaming, Mobilität und Online-Marktplätze. Sie bieten fortschrittliche Technologie, die KI-gestützte Automatisierung mit menschlichem Feedback, tiefen Einblicken und Fachwissen kombiniert.

Veriff bietet eine bewährte Infrastruktur, die es seinen Kunden ermöglicht, in allen relevanten Momenten ihrer Customer Journey auf die Identitäten und persönlichen Eigenschaften ihrer Benutzer zu vertrauen. Veriff genießt das Vertrauen von Kunden wie Bolt, Deel, Monese, Starship, Super Awesome, Trustpilot und Wise.

Als KI-gestützte Lösung muss Veriff Dutzende von Modellen für maschinelles Lernen (ML) auf kostengünstige Weise erstellen und ausführen. Diese Modelle reichen von einfachen baumbasierten Modellen bis hin zu Deep-Learning-Computer-Vision-Modellen, die auf GPUs ausgeführt werden müssen, um eine niedrige Latenz zu erreichen und das Benutzererlebnis zu verbessern. Veriff erweitert sein Angebot derzeit außerdem um weitere Produkte und zielt auf eine hyperpersonalisierte Lösung für seine Kunden ab. Die Bereitstellung unterschiedlicher Modelle für unterschiedliche Kunden erhöht den Bedarf an einer skalierbaren Modellbereitstellungslösung.

In diesem Beitrag zeigen wir Ihnen, wie Veriff seinen Modellbereitstellungsworkflow standardisiert hat Amazon Sage Maker, wodurch Kosten und Entwicklungszeit reduziert werden.

Infrastruktur- und Entwicklungsherausforderungen

Die Backend-Architektur von Veriff basiert auf einem Microservices-Muster, wobei Dienste auf verschiedenen Kubernetes-Clustern ausgeführt werden, die auf der AWS-Infrastruktur gehostet werden. Dieser Ansatz wurde ursprünglich für alle Unternehmensdienste verwendet, einschließlich Microservices, die teure Computer-Vision-ML-Modelle ausführen.

Einige dieser Modelle erforderten die Bereitstellung auf GPU-Instanzen. Veriff war sich der vergleichsweise höheren Kosten GPU-gestützter Instanztypen bewusst und entwickelte eine kundenspezifische Lösung auf Kubernetes, um die Ressourcen einer bestimmten GPU zwischen verschiedenen Dienstreplikaten zu teilen. Eine einzelne GPU verfügt normalerweise über genügend VRAM, um mehrere Computer-Vision-Modelle von Veriff im Speicher zu speichern.

Obwohl die Lösung die GPU-Kosten senkte, war sie auch mit der Einschränkung verbunden, dass Datenwissenschaftler im Voraus angeben mussten, wie viel GPU-Speicher ihr Modell benötigen würde. Darüber hinaus waren DevOps mit der manuellen Bereitstellung von GPU-Instanzen als Reaktion auf Nachfragemuster belastet. Dies führte zu einem Betriebsaufwand und einer Überbereitstellung von Instanzen, was zu einem suboptimalen Kostenprofil führte.

Abgesehen von der GPU-Bereitstellung erforderte dieses Setup auch, dass Datenwissenschaftler für jedes Modell einen REST-API-Wrapper erstellten, der benötigt wurde, um eine generische Schnittstelle für die Nutzung durch andere Unternehmensdienste bereitzustellen und die Vor- und Nachverarbeitung von Modelldaten zu kapseln. Diese APIs erforderten Code in Produktionsqualität, was es für Datenwissenschaftler schwierig machte, Modelle zu produzieren.

Das Data-Science-Plattform-Team von Veriff suchte nach alternativen Wegen zu diesem Ansatz. Das Hauptziel bestand darin, die Datenwissenschaftler des Unternehmens durch die Bereitstellung einfacherer Bereitstellungspipelines bei einem besseren Übergang von der Forschung zur Produktion zu unterstützen. Das sekundäre Ziel bestand darin, die Betriebskosten für die Bereitstellung von GPU-Instanzen zu senken.

Lösungsüberblick

Veriff benötigte eine neue Lösung, die zwei Probleme löste:

• Ermöglichen Sie die einfache Erstellung von REST-API-Wrappern um ML-Modelle
• Ermöglichen Sie die optimale und möglichst automatische Verwaltung der bereitgestellten GPU-Instanzkapazität

Letztendlich einigte sich das Team der ML-Plattform auf die Entscheidung, es zu verwenden Sagemaker-Endpunkte mit mehreren Modellen (MMEs). Ausschlaggebend für diese Entscheidung war die Unterstützung von MME für NVIDIA Triton Inferenzserver (ein ML-fokussierter Server, der es einfach macht, Modelle als REST-APIs zu verpacken; Veriff experimentierte auch bereits mit Triton) sowie seine Fähigkeit, die automatische Skalierung von GPU-Instanzen über einfache Richtlinien zur automatischen Skalierung nativ zu verwalten.

Bei Veriff wurden zwei MMEs erstellt, eines für die Inszenierung und eines für die Produktion. Dieser Ansatz ermöglicht es ihnen, Testschritte in einer Staging-Umgebung auszuführen, ohne die Produktionsmodelle zu beeinträchtigen.

SageMaker-MMEs

SageMaker ist ein vollständig verwalteter Dienst, der Entwicklern und Datenwissenschaftlern die Möglichkeit bietet, ML-Modelle schnell zu erstellen, zu trainieren und bereitzustellen. SageMaker-MMEs bieten eine skalierbare und kostengünstige Lösung für die Bereitstellung einer großen Anzahl von Modellen für Echtzeit-Inferenz. MMEs nutzen einen Shared-Serving-Container und eine Flotte von Ressourcen, die beschleunigte Instanzen wie GPUs zum Hosten aller Ihrer Modelle nutzen können. Dies reduziert die Hosting-Kosten durch Maximierung der Endpunktauslastung im Vergleich zur Verwendung von Einzelmodell-Endpunkten. Außerdem wird der Bereitstellungsaufwand reduziert, da SageMaker das Laden und Entladen von Modellen im Speicher und deren Skalierung basierend auf den Datenverkehrsmustern des Endpunkts verwaltet. Darüber hinaus profitieren alle SageMaker-Echtzeitendpunkte von integrierten Funktionen zur Verwaltung und Überwachung von Modellen, wie z. B. dem Einbeziehen Schattenvarianten, automatische Skalierung, und native Integration mit Amazon CloudWatch (Weitere Informationen finden Sie unter CloudWatch-Metriken für Endpunktbereitstellungen mit mehreren Modellen).

Benutzerdefinierte Triton-Ensemblemodelle

Es gab mehrere Gründe, warum sich Veriff für den Einsatz von Triton Inference Server entschieden hat. Die wichtigsten sind:

• Es ermöglicht Datenwissenschaftlern, REST-APIs aus Modellen zu erstellen, indem sie Modellartefaktdateien in einem Standardverzeichnisformat anordnen (keine Codelösung).
• Es ist mit allen wichtigen KI-Frameworks kompatibel (PyTorch, Tensorflow, XGBoost und mehr)
• Es bietet ML-spezifische Low-Level- und Serveroptimierungen wie z dynamisches Batching von Anfragen

Mit Triton können Datenwissenschaftler problemlos Modelle bereitstellen, da sie nur formatierte Modellrepositorys erstellen müssen, anstatt Code zum Erstellen von REST-APIs zu schreiben (Triton unterstützt auch). Python-Modelle wenn eine benutzerdefinierte Inferenzlogik erforderlich ist). Dies verkürzt die Zeit für die Modellbereitstellung und gibt Datenwissenschaftlern mehr Zeit, sich auf die Erstellung von Modellen zu konzentrieren, anstatt sie bereitzustellen.

Ein weiteres wichtiges Merkmal von Triton ist, dass Sie damit bauen können Modellensembles, das sind Gruppen von Modellen, die miteinander verkettet sind. Diese Ensembles können so betrieben werden, als wären sie ein einzelnes Triton-Modell. Veriff nutzt diese Funktion derzeit, um Vorverarbeitungs- und Nachverarbeitungslogik für jedes ML-Modell mithilfe von Python-Modellen bereitzustellen (wie bereits erwähnt), um sicherzustellen, dass es bei der Verwendung von Modellen in der Produktion keine Diskrepanzen in den Eingabedaten oder der Modellausgabe gibt.

Im Folgenden sehen Sie, wie ein typisches Triton-Modell-Repository für diese Arbeitslast aussieht:

Das model.py Die Datei enthält Vorverarbeitungs- und Nachverarbeitungscode. Die trainierten Modellgewichte sind im screen_detection_inferencer Verzeichnis, unter Modellversion 1 (Das Modell liegt in diesem Beispiel im ONNX-Format vor, kann aber auch im TensorFlow-, PyTorch-Format oder anderen Formaten vorliegen.) Die Definition des Ensemblemodells befindet sich in der screen_detection_pipeline Verzeichnis, in dem Ein- und Ausgänge zwischen Schritten in einer Konfigurationsdatei abgebildet werden.

Zusätzliche Abhängigkeiten, die zum Ausführen der Python-Modelle erforderlich sind, werden in a detailliert beschrieben requirements.txt Datei und müssen Conda-gepackt werden, um eine Conda-Umgebung zu erstellen (python_env.tar.gz). Weitere Informationen finden Sie unter Verwalten von Python-Laufzeit und -Bibliotheken. Außerdem müssen Konfigurationsdateien für Python-Schritte darauf verweisen python_env.tar.gz Verwendung der EXECUTION_ENV_PATH Richtlinie.

Der Modellordner muss dann mit TAR komprimiert und umbenannt werden model_version.txt. Schließlich das Ergebnis <model_name>_<model_version>.tar.gz Datei wird in die kopiert Amazon Simple Storage-Service (Amazon S3)-Bucket, der mit dem MME verbunden ist, sodass SageMaker das Modell erkennen und bereitstellen kann.

Modellversionierung und kontinuierliche Bereitstellung

Wie im vorherigen Abschnitt deutlich wurde, ist der Aufbau eines Triton-Modellrepositorys unkompliziert. Bei manueller Ausführung ist es jedoch mühsam und fehleranfällig, alle für die Bereitstellung erforderlichen Schritte auszuführen. Um dieses Problem zu lösen, hat Veriff ein Monorepo erstellt, das alle Modelle enthält, die in MMEs bereitgestellt werden sollen, wo Datenwissenschaftler in einem Gitflow-ähnlichen Ansatz zusammenarbeiten. Dieses Monorepo verfügt über die folgenden Funktionen:

• Es wird mit verwaltet Hosen.
• Codequalitätstools wie Black und MyPy werden mit Pants angewendet.
• Für jedes Modell werden Unit-Tests definiert, die überprüfen, ob die Modellausgabe die erwartete Ausgabe für eine bestimmte Modelleingabe ist.
• Modellgewichte werden neben Modellrepositorys gespeichert. Diese Gewichte können also große Binärdateien sein DVC wird verwendet, um sie versioniert mit Git zu synchronisieren.

Dieses Monorepo ist in ein Continuous Integration (CI)-Tool integriert. Für jeden neuen Push zum Repo oder neuen Modell werden die folgenden Schritte ausgeführt:

1. Bestehen Sie die Codequalitätsprüfung.
2. Laden Sie die Modellgewichte herunter.
3. Erstellen Sie die Conda-Umgebung.
4. Starten Sie einen Triton-Server mithilfe der Conda-Umgebung und verarbeiten Sie damit in Komponententests definierte Anforderungen.
5. Erstellen Sie die endgültige Modell-TAR-Datei (<model_name>_<model_version>.tar.gz).

Diese Schritte stellen sicher, dass die Modelle die für die Bereitstellung erforderliche Qualität aufweisen. Daher wird bei jedem Push an einen Repo-Zweig die resultierende TAR-Datei (in einem weiteren CI-Schritt) in den Staging-S3-Bucket kopiert. Wenn Pushvorgänge im Hauptzweig durchgeführt werden, wird die Modelldatei in den Produktions-S3-Bucket kopiert. Das folgende Diagramm zeigt dieses CI/CD-System.

Kosten- und Bereitstellungsgeschwindigkeitsvorteile

Durch die Verwendung von MMEs kann Veriff einen Monorepo-Ansatz verwenden, um Modelle für die Produktion bereitzustellen. Zusammenfassend besteht der neue Modellbereitstellungsworkflow von Veriff aus den folgenden Schritten:

1. Erstellen Sie im Monorepo einen Zweig mit dem neuen Modell oder der neuen Modellversion.
2. Definieren Sie Komponententests und führen Sie sie auf einem Entwicklungscomputer aus.
3. Drücken Sie den Zweig, wenn das Modell zum Testen in der Staging-Umgebung bereit ist.
4. Führen Sie den Zweig mit dem Hauptzweig zusammen, wenn das Modell für die Verwendung in der Produktion bereit ist.

Mit dieser neuen Lösung ist die Bereitstellung eines Modells bei Veriff ein unkomplizierter Teil des Entwicklungsprozesses. Die Entwicklungszeit für neue Modelle hat sich von 10 Tagen auf durchschnittlich 2 Tage verkürzt.

Die verwalteten Infrastrukturbereitstellungs- und Auto-Scaling-Funktionen von SageMaker brachten Veriff zusätzliche Vorteile. Sie nutzten die AufrufeproInstanz CloudWatch-Metrik zur Skalierung entsprechend den Verkehrsmustern, wodurch Kosten gespart werden, ohne die Zuverlässigkeit zu beeinträchtigen. Um den Schwellenwert für die Metrik zu definieren, führten sie Lasttests am Staging-Endpunkt durch, um den besten Kompromiss zwischen Latenz und Kosten zu finden.

Nach der Bereitstellung von sieben Produktionsmodellen für MMEs und der Analyse der Ausgaben meldete Veriff eine Kostenreduzierung von 75 % bei der GPU-Modellbereitstellung im Vergleich zur ursprünglichen Kubernetes-basierten Lösung. Auch die Betriebskosten wurden gesenkt, da den DevOps-Ingenieuren des Unternehmens die Last der manuellen Bereitstellung von Instanzen abgenommen wurde.

Zusammenfassung

In diesem Beitrag haben wir untersucht, warum Veriff Sagemaker-MMEs der selbstverwalteten Modellbereitstellung auf Kubernetes vorgezogen hat. SageMaker übernimmt die undifferenzierte Schwerarbeit und ermöglicht es Veriff, die Modellentwicklungszeit zu verkürzen, die Engineering-Effizienz zu steigern und die Kosten für Echtzeit-Inferenz drastisch zu senken und gleichzeitig die für ihre geschäftskritischen Vorgänge erforderliche Leistung aufrechtzuerhalten. Abschließend stellten wir Veriffs einfache, aber effektive CI/CD-Pipeline für die Modellbereitstellung und den Mechanismus zur Modellversionierung vor, der als Referenzimplementierung für die Kombination von Best Practices für die Softwareentwicklung und SageMaker-MMEs verwendet werden kann. Codebeispiele zum Hosten mehrerer Modelle mithilfe von SageMaker-MMEs finden Sie unter GitHub.

---

Über die Autoren

Ricard Borràs ist Senior Machine Learning bei Veriff, wo er die MLOps-Bemühungen im Unternehmen leitet. Er hilft Datenwissenschaftlern, schnellere und bessere KI-/ML-Produkte zu entwickeln, indem er im Unternehmen eine Data Science-Plattform aufbaut und mehrere Open-Source-Lösungen mit AWS-Diensten kombiniert.

Joao Moura ist ein AI/ML Specialist Solutions Architect bei AWS mit Sitz in Spanien. Er unterstützt Kunden bei Deep-Learning-Modellen, groß angelegtem Training und Inferenzoptimierung sowie beim Aufbau groß angelegter ML-Plattformen auf AWS.

Miguel Ferreira arbeitet als Sr. Solutions Architect bei AWS mit Sitz in Helsinki, Finnland. KI/ML war ein lebenslanges Interesse und er hat mehreren Kunden dabei geholfen, Amazon SageMaker in ihre ML-Workflows zu integrieren.

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• PlatoData.Network Vertikale generative KI. Motiviere dich selbst. Hier zugreifen.
• PlatoAiStream. Web3-Intelligenz. Wissen verstärkt. Hier zugreifen.
• PlatoESG. Kohlenstoff, CleanTech, Energie, Umwelt, Solar, Abfallwirtschaft. Hier zugreifen.
• PlatoHealth. Informationen zu Biotechnologie und klinischen Studien. Hier zugreifen.
• Quelle: https://aws.amazon.com/blogs/machine-learning/how-veriff-decreased-deployment-time-by-80-using-amazon-sagemaker-multi-model-endpoints/