Dieser Beitrag wurde gemeinsam mit Jad Chamoun, Director of Engineering bei Forethought Technologies, Inc., und Salina Wu, Senior ML Engineer bei Forethought Technologies, Inc., verfasst.
Voraussicht ist eine führende generative KI-Suite für den Kundenservice. Im Mittelpunkt der Suite steht die Innovation Unterstützen Sie GPT™ Technologie, die maschinelles Lernen nutzt, um den Kundensupport-Lebenszyklus zu transformieren – die Ablenkung zu erhöhen, die CSAT zu verbessern und die Produktivität der Agenten zu steigern. SupportGPT™ nutzt modernste Information Retrieval (IR)-Systeme und große Sprachmodelle (LLMs), um jährlich über 30 Millionen Kundeninteraktionen zu ermöglichen.
Der Hauptanwendungsfall von SupportGPT ist die Verbesserung der Qualität und Effizienz der Interaktionen und Abläufe im Kundensupport. Durch den Einsatz modernster IR-Systeme, die auf Einbettungen und Ranking-Modellen basieren, kann SupportGPT schnell nach relevanten Informationen suchen und genaue und prägnante Antworten auf Kundenanfragen liefern. Forethought verwendet auf jeden Kunden abgestimmte Modelle, um Kundenabsichten zu erkennen und so Kundeninteraktionen zu lösen. Die Integration großer Sprachmodelle trägt dazu bei, die Interaktion mit automatisierten Agenten zu humanisieren und so ein ansprechenderes und zufriedenstellenderes Support-Erlebnis zu schaffen.
SupportGPT unterstützt Kundensupportmitarbeiter außerdem, indem es Vorschläge zur automatischen Vervollständigung macht und entsprechende Antworten auf Kundentickets erstellt, die mit denen des Unternehmens auf der Grundlage früherer Antworten übereinstimmen. Durch den Einsatz fortschrittlicher Sprachmodelle können Agenten schneller und präziser auf die Anliegen der Kunden eingehen, was zu einer höheren Kundenzufriedenheit führt.
Darüber hinaus ermöglicht die Architektur von SupportGPT das Erkennen von Lücken in den Support-Wissensdatenbanken, was Agenten dabei hilft, den Kunden genauere Informationen bereitzustellen. Sobald diese Lücken identifiziert sind, kann SupportGPT automatisch Artikel und andere Inhalte generieren, um diese Wissenslücken zu schließen und sicherzustellen, dass die Support-Wissensdatenbank kundenorientiert und aktuell bleibt.
In diesem Beitrag teilen wir mit, wie Forethought verwendet wird Amazon Sage Maker Multimodell-Endpunkte in generativen KI-Anwendungsfällen, um über 66 % Kosten einzusparen.
Infrastrukturelle Herausforderungen
Um diese Funktionen auf den Markt zu bringen, skaliert Forethought seine ML-Workloads effizient und bietet hyperpersonalisierte Lösungen, die auf den spezifischen Anwendungsfall jedes Kunden zugeschnitten sind. Diese Hyperpersonalisierung wird durch die Feinabstimmung von Einbettungsmodellen und Klassifikatoren für Kundendaten erreicht und gewährleistet so genaue Ergebnisse beim Informationsabruf und Domänenwissen, das auf die individuellen Bedürfnisse jedes Kunden zugeschnitten ist. Die maßgeschneiderten Autovervollständigungsmodelle sind außerdem auf Kundendaten abgestimmt, um die Genauigkeit und Relevanz der generierten Antworten weiter zu verbessern.
Eine der größten Herausforderungen bei der KI-Verarbeitung ist die effiziente Nutzung von Hardwareressourcen wie GPUs. Um diese Herausforderung zu bewältigen, nutzt Forethought Multi-Model-Endpunkte (MMEs) von SageMaker, um mehrere KI-Modelle auf einem einzigen Inferenzendpunkt und einer einzigen Skalierung auszuführen. Da die Hyperpersonalisierung von Modellen das Trainieren und Bereitstellen einzigartiger Modelle erfordert, skaliert die Anzahl der Modelle linear mit der Anzahl der Kunden, was kostspielig werden kann.
Um das richtige Gleichgewicht zwischen Leistung, Echtzeit-Inferenz und Kosten zu erreichen, entschied sich Forethought für die Verwendung von SageMaker-MMEs, die GPU-Beschleunigung unterstützen. SageMaker-MMEs ermöglichen es Forethought, leistungsstarke, skalierbare und kostengünstige Lösungen mit einer Latenzzeit von weniger als einer Sekunde bereitzustellen und so mehrere Kundensupportszenarien in großem Maßstab abzudecken.
SageMaker und Forethought
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).
Als Forethought wuchs und Hunderte von Modellen hostete, die auch GPU-Ressourcen erforderten, sahen wir eine Möglichkeit, mithilfe von SageMaker-MMEs eine kostengünstigere, zuverlässigere und verwaltbarere Architektur zu schaffen. Vor der Migration zu SageMaker MMEs wurden unsere Modelle auf Kubernetes bereitgestellt Amazon Elastic Kubernetes-Service (Amazon EKS). Obwohl Amazon EKS Verwaltungsfunktionen bereitstellte, war sofort klar, dass wir eine Infrastruktur verwalteten, die nicht speziell auf Inferenz zugeschnitten war. Forethought musste die Modellinferenz auf Amazon EKS selbst verwalten, was eine Belastung für die technische Effizienz darstellte. Um beispielsweise teure GPU-Ressourcen zwischen mehreren Modellen zu teilen, waren wir für die Zuweisung starrer Speicheranteile an Modelle verantwortlich, die während der Bereitstellung angegeben wurden. Wir wollten die folgenden Hauptprobleme mit unserer bestehenden Infrastruktur angehen:
- Hohe Kosten – Um sicherzustellen, dass jedes Modell über genügend Ressourcen verfügt, gehen wir bei der Anzahl der Modelle, die pro Instanz passen, sehr zurückhaltend vor. Dies führte dazu, dass die Kosten für das Model-Hosting deutlich höher ausfielen als nötig.
- Geringe Zuverlässigkeit – Obwohl wir bei der Speicherzuweisung konservativ vorgehen, haben nicht alle Modelle die gleichen Anforderungen, und gelegentlich lösten einige Modelle OOM-Fehler (Out of Memory) aus.
- Ineffiziente Verwaltung – Wir mussten für jeden Modelltyp (z. B. Klassifikatoren, Einbettungen und automatische Vervollständigung) unterschiedliche Bereitstellungsmanifeste verwalten, was zeitaufwändig und fehleranfällig war. Wir mussten auch die Logik beibehalten, um die Speicherzuweisung für verschiedene Modelltypen zu bestimmen.
Letztendlich brauchten wir eine Inferenzplattform, die uns die schwere Arbeit der Verwaltung unserer Modelle zur Laufzeit abnimmt, um die Kosten, die Zuverlässigkeit und die Verwaltung der Bereitstellung unserer Modelle zu verbessern. Mit den MMEs von SageMaker konnten wir auf diese Bedürfnisse eingehen.
Durch das intelligente und dynamische Laden und Entladen von Modellen sowie die Skalierungsfunktionen stellten SageMaker-MMEs eine deutlich kostengünstigere und zuverlässigere Lösung für das Hosten unserer Modelle bereit. Wir können jetzt viel mehr Modelle pro Instanz anpassen und müssen uns keine Sorgen über OOM-Fehler machen, da SageMaker-MMEs das Laden und Entladen von Modellen dynamisch handhaben. Darüber hinaus sind Bereitstellungen jetzt so einfach wie das Aufrufen der Boto3 SageMaker-APIs und das Anhängen der richtigen Richtlinien für die automatische Skalierung.
Das folgende Diagramm veranschaulicht unsere Legacy-Architektur.
Um unsere Migration zu SageMaker-MMEs zu beginnen, haben wir die besten Anwendungsfälle für MMEs ermittelt und ermittelt, welche unserer Modelle am meisten von dieser Änderung profitieren würden. MMEs werden am besten für Folgendes verwendet:
- Modelle, von denen eine geringe Latenz erwartet wird, die aber einer Kaltstartzeit (beim ersten Laden) standhalten können
- Modelle, die häufig und regelmäßig aufgerufen werden
- Modelle, die teilweise GPU-Ressourcen benötigen
- Modelle mit gemeinsamen Anforderungen und Inferenzlogik
Wir haben unsere Einbettungsmodelle und Autovervollständigungs-Sprachmodelle als die besten Kandidaten für unsere Migration identifiziert. Um diese Modelle unter MMEs zu organisieren, würden wir eine MME pro Modelltyp oder Aufgabe erstellen, eine für unsere Einbettungsmodelle und eine weitere für automatisch vervollständigte Sprachmodelle.
Wir hatten bereits eine API-Schicht über unseren Modellen für Modellverwaltung und Inferenz. Unsere Aufgabe bestand darin, die Art und Weise zu überarbeiten, wie diese API unter der Haube von SageMaker Inferenzen auf Modelle bereitstellt und handhabt, mit minimalen Änderungen an der Art und Weise, wie Kunden und Produktteams mit der API interagieren. Außerdem mussten wir unsere Modelle und benutzerdefinierten Inferenzlogik so verpacken, dass sie mithilfe von SageMaker-MMEs mit NVIDIA Triton Inference Server kompatibel sind.
Das folgende Diagramm veranschaulicht unsere neue Architektur.
Benutzerdefinierte Inferenzlogik
Vor der Migration zu SageMaker wurde der benutzerdefinierte Inferenzcode (Vorverarbeitung und Nachverarbeitung) von Forethought in der API-Ebene ausgeführt, wenn ein Modell aufgerufen wurde. Ziel war es, diese Funktionalität auf das Modell selbst zu übertragen, um die Trennung der Verantwortlichkeiten zu verdeutlichen, den Code zu modularisieren und zu vereinfachen und die Belastung der API zu reduzieren.
Einbettungen
Die Einbettungsmodelle von Forethought bestehen aus zwei PyTorch-Modellartefakten, und die Inferenzanforderung bestimmt, welches Modell aufgerufen werden soll. Jedes Modell erfordert vorverarbeiteten Text als Eingabe. Die größten Herausforderungen bestanden in der Integration eines Vorverarbeitungsschritts und der Unterbringung von zwei Modellartefakten pro Modelldefinition. Um den Bedarf an mehreren Schritten in der Inferenzlogik zu decken, hat Forethought ein Triton-Ensemble-Modell mit zwei Schritten entwickelt: einem Python-Backend-Vorverarbeitungsprozess und einem PyTorch-Backend-Modellaufruf. Ensemble-Modelle ermöglichen das Definieren und Anordnen von Schritten in der Inferenzlogik, wobei jeder Schritt durch ein Triton-Modell eines beliebigen Backend-Typs dargestellt wird. Um die Kompatibilität mit dem Triton PyTorch-Backend sicherzustellen, wurden die vorhandenen Modellartefakte in das TorchScript-Format konvertiert. Für jede Modelldefinition wurden separate Triton-Modelle erstellt, und die API-Schicht von Forethought war für die Bestimmung der geeigneten verantwortlich TargetModel
basierend auf der eingehenden Anfrage aufzurufen.
Autocomplete
Die Autovervollständigungsmodelle (von Sequenz zu Sequenz) stellten einen bestimmten Satz von Anforderungen dar. Insbesondere mussten wir die Fähigkeit ermöglichen, mehrere Modellaufrufe zu durchlaufen und umfangreiche Eingaben für jeden Aufruf zwischenzuspeichern, und das alles bei gleichzeitig geringer Latenz. Darüber hinaus erforderten diese Modelle sowohl Vorverarbeitungs- als auch Nachverarbeitungsschritte. Um diesen Anforderungen gerecht zu werden und die gewünschte Flexibilität zu erreichen, hat Forethought Autocomplete-MME-Modelle entwickelt, die das Triton-Python-Backend verwenden, das den Vorteil bietet, das Modell als Python-Code zu schreiben.
Benchmarking
Nachdem die Formen des Triton-Modells festgelegt waren, stellten wir Modelle auf Staging-Endpunkten bereit und führten ein Ressourcen- und Leistungsbenchmarking durch. Unser Hauptziel bestand darin, die Latenz beim Kaltstart im Vergleich zu In-Memory-Modellen zu bestimmen und zu ermitteln, wie sich die Latenz auf die Anforderungsgröße und die Parallelität auswirkt. Wir wollten auch wissen, wie viele Modelle auf jede Instanz passen, wie viele Modelle eine Skalierung der Instanzen mit unserer Richtlinie zur automatischen Skalierung bewirken würden und wie schnell die Skalierung erfolgen würde. Passend zu den Instanztypen, die wir bereits verwendet haben, haben wir unser Benchmarking mit den Instanzen ml.g4dn.xlarge und ml.g4dn.2xlarge durchgeführt.
Die Ergebnisse
Die folgende Tabelle fasst unsere Ergebnisse zusammen.
Anfragegröße | Kaltstartlatenz | Zwischengespeicherte Inferenzlatenz | Gleichzeitige Latenz (5 Anfragen) |
Klein (30 Token) | 12.7 Sekunden | 0.03 Sekunden | 0.12 Sekunden |
Mittel (250 Token) | 12.7 Sekunden | 0.05 Sekunden | 0.12 Sekunden |
Groß (550 Token) | 12.7 Sekunden | 0.13 Sekunden | 0.12 Sekunden |
Bemerkenswert ist, dass die Latenz für Kaltstartanfragen deutlich höher ist als die Latenz für zwischengespeicherte Inferenzanfragen. Dies liegt daran, dass das Modell von der Festplatte oder geladen werden muss Amazon Simple Storage-Service (Amazon S3), wenn eine Kaltstartanforderung gestellt wird. Die Latenzzeit für gleichzeitige Anfragen ist ebenfalls höher als die Latenzzeit für einzelne Anfragen. Dies liegt daran, dass das Modell von gleichzeitigen Anforderungen gemeinsam genutzt werden muss, was zu Konflikten führen kann.
Die folgende Tabelle vergleicht die Latenz der Legacy-Modelle und der SageMaker-Modelle.
Anfragegröße | Legacy-Modelle | SageMaker-Modelle |
Klein (30 Token) | 0.74 Sekunden | 0.24 Sekunden |
Mittel (250 Token) | 0.74 Sekunden | 0.24 Sekunden |
Groß (550 Token) | 0.80 Sekunden | 0.32 Sekunden |
Insgesamt sind die SageMaker-Modelle eine bessere Wahl für das Hosten von Autovervollständigungsmodellen als die Vorgängermodelle. Sie bieten geringere Latenz, Skalierbarkeit, Zuverlässigkeit und Sicherheit.
Ressourcennutzung
Um die optimale Anzahl an Modellen zu ermitteln, die in jede Instanz passen, führten wir eine Reihe von Tests durch. Unser Experiment umfasste das Laden von Modellen in unsere Endpunkte mithilfe eines ml.g4dn.xlarge-Instanztyps ohne automatische Skalierungsrichtlinie.
Diese speziellen Instanzen bieten 15.5 GB Speicher und unser Ziel war es, eine GPU-Speicherauslastung von etwa 80 % pro Instanz zu erreichen. Unter Berücksichtigung der Größe jedes Encoder-Modell-Artefakts ist es uns gelungen, die optimale Anzahl von Triton-Encodern zu finden, die auf eine Instanz geladen werden können, um unsere angestrebte GPU-Speichernutzung zu erreichen. Da jedes unserer Einbettungsmodelle zwei Triton-Encoder-Modellen entspricht, konnten wir außerdem eine festgelegte Anzahl von Einbettungsmodellen pro Instanz unterbringen. Als Ergebnis haben wir die Gesamtzahl der Instanzen berechnet, die erforderlich sind, um alle unsere Einbettungsmodelle bereitzustellen. Dieses Experiment war entscheidend für die Optimierung unserer Ressourcennutzung und die Steigerung der Effizienz unserer Modelle.
Wir haben ein ähnliches Benchmarking für unsere Autocomplete-Modelle durchgeführt. Diese Modelle waren jeweils etwa 292.0 MB groß. Als wir testeten, wie viele Modelle auf eine einzelne ml.g4dn.xlarge-Instanz passen würden, stellten wir fest, dass wir nur vier Modelle unterbringen konnten, bevor unsere Instanz mit dem Entladen von Modellen begann, obwohl die Modelle eine geringe Größe hatten. Unsere Hauptanliegen waren:
- Ursache für einen Anstieg der CPU-Speicherauslastung
- Ursache dafür, dass Modelle entladen wurden, wenn wir versuchten, ein weiteres Modell zu laden, anstatt nur das zuletzt verwendete Modell (LRU).
Wir konnten die Hauptursache für den Anstieg der Speicherauslastung ermitteln, der auf die Initialisierung unserer CUDA-Laufzeitumgebung in unserem Python-Modell zurückzuführen war, die erforderlich war, um unsere Modelle und Daten auf das GPU-Gerät zu übertragen und von diesem zu entfernen. CUDA lädt viele externe Abhängigkeiten in den CPU-Speicher, wenn die Laufzeit initialisiert wird. Da das Triton PyTorch-Backend das Verschieben von Daten auf und von dem GPU-Gerät verarbeitet und abstrahiert, ist dieses Problem bei unseren Einbettungsmodellen nicht aufgetreten. Um dieses Problem zu beheben, haben wir versucht, ml.g4dn.2xlarge-Instanzen zu verwenden, die über die gleiche Menge an GPU-Speicher, aber doppelt so viel CPU-Speicher verfügten. Darüber hinaus haben wir unserem Python-Backend-Code mehrere kleinere Optimierungen hinzugefügt, darunter das Löschen von Tensoren nach der Verwendung, das Leeren des Caches, das Deaktivieren von Farbverläufen und die Müllsammlung. Mit dem größeren Instanztyp konnten wir 10 Modelle pro Instanz unterbringen und die CPU- und GPU-Speicherauslastung wurde viel besser angeglichen.
Das folgende Diagramm veranschaulicht diese Architektur.
Automatische Skalierung
Wir haben sowohl unseren Einbettungen als auch unseren Autovervollständigungs-MMEs Richtlinien zur automatischen Skalierung hinzugefügt. Unsere Richtlinie für unseren Embeddings-Endpunkt zielte mithilfe benutzerdefinierter Metriken auf eine durchschnittliche GPU-Speicherauslastung von 80 % ab. Unsere Autocomplete-Modelle verzeichneten ein Muster aus hohem Verkehr während der Geschäftszeiten und minimalem Verkehr über Nacht. Aus diesem Grund haben wir eine Auto-Scaling-Richtlinie erstellt, die darauf basiert InvocationsPerInstance
So konnten wir entsprechend den Verkehrsmustern skalieren und so Kosten sparen, ohne die Zuverlässigkeit zu beeinträchtigen. Basierend auf unserem Ressourcennutzungs-Benchmarking haben wir unsere Skalierungsrichtlinien mit einem Ziel von 225 konfiguriert InvocationsPerInstance
.
Stellen Sie Logik und Pipeline bereit
Das Erstellen einer MME auf SageMaker ist unkompliziert und ähnelt der Erstellung jedes anderen Endpunkts auf SageMaker. Nachdem der Endpunkt erstellt wurde, ist das Hinzufügen zusätzlicher Modelle zum Endpunkt so einfach wie das Verschieben des Modellartefakts auf den S3-Pfad, auf den der Endpunkt abzielt. An diesem Punkt können wir Rückschlussanfragen für unser neues Modell stellen.
Wir haben eine Logik definiert, die Modellmetadaten aufnimmt, den Endpunkt deterministisch basierend auf den Metadaten formatiert und prüft, ob der Endpunkt vorhanden ist. Ist dies nicht der Fall, erstellen wir den Endpunkt und fügen das Triton-Modellartefakt zum S3-Patch für den Endpunkt hinzu (ebenfalls deterministisch formatiert). Wenn die Modellmetadaten beispielsweise darauf hinweisen, dass es sich um ein Autovervollständigungsmodell handelt, wird ein Endpunkt für Autovervollständigungsmodelle und ein zugehöriger S3-Pfad für Autovervollständigungsmodellartefakte erstellt. Wenn der Endpunkt vorhanden wäre, würden wir das Modellartefakt in den S3-Pfad kopieren.
Nachdem wir nun unsere Modellformen für unsere MME-Modelle und die Funktionalität zum Bereitstellen unserer Modelle in MME hatten, brauchten wir eine Möglichkeit, die Bereitstellung zu automatisieren. Unsere Benutzer müssen angeben, welches Modell sie bereitstellen möchten; Wir kümmern uns um die Verpackung und Bereitstellung des Modells. Der mit dem Modell verpackte benutzerdefinierte Inferenzcode wird versioniert und an Amazon S3 übertragen. Im Verpackungsschritt ziehen wir den Inferenzcode entsprechend der angegebenen Version (oder der neuesten Version) und verwenden YAML-Dateien, die die Dateistrukturen der Triton-Modelle angeben.
Eine Anforderung für uns war, dass alle unsere MME-Modelle in den Speicher geladen werden, um Kaltstartlatenz während Produktionsinferenzanforderungen zum Laden von Modellen zu vermeiden. Um dies zu erreichen, stellen wir genügend Ressourcen bereit, um alle unsere Modelle anzupassen (gemäß dem vorherigen Benchmarking) und rufen jedes Modell in unserem MME stündlich auf.
Das folgende Diagramm veranschaulicht die Modellbereitstellungspipeline.
Das folgende Diagramm veranschaulicht die Modell-Aufwärmpipeline.
Modellaufruf
Unsere bestehende API-Schicht bietet Aufrufern eine Abstraktion, um Rückschlüsse auf alle unsere ML-Modelle zu ziehen. Das bedeutete, dass wir der API-Ebene lediglich Funktionen hinzufügen mussten, um die SageMaker MME je nach Inferenzanforderung mit dem richtigen Zielmodell aufzurufen, ohne Änderungen am aufrufenden Code. Der SageMaker-Inferenzcode nimmt die Inferenzanforderung entgegen, formatiert die in unseren Triton-Modellen definierten Triton-Eingaben und ruft die MMEs mithilfe von Boto3 auf.
Kostenvorteile
Dank der Migration auf SageMaker-MMEs hat Forethought erhebliche Fortschritte bei der Reduzierung der Modell-Hosting-Kosten und der Minderung von Modell-OOM-Fehlern erzielt. Vor dieser Änderung wurden ml.g4dn.xlarge-Instanzen in Amazon EKS ausgeführt. Mit dem Übergang zu MMEs haben wir festgestellt, dass damit 12 Einbettungsmodelle pro Instanz untergebracht werden können und gleichzeitig eine GPU-Speicherauslastung von 80 % erreicht wird. Dies führte zu einem deutlichen Rückgang unserer monatlichen Ausgaben. Um es ins rechte Licht zu rücken: Wir haben eine Kosteneinsparung von bis zu 80 % erzielt. Um den höheren Datenverkehr zu bewältigen, haben wir darüber hinaus darüber nachgedacht, die Replikate zu vergrößern. Unter der Annahme eines Szenarios, in dem wir drei Replikate einsetzen, stellten wir fest, dass unsere Kosteneinsparungen selbst unter diesen Bedingungen immer noch erheblich wären und etwa 43 % betragen würden.
Die Reise mit SageMaker-MMEs hat sich als finanziell vorteilhaft erwiesen, da sie unsere Kosten senkt und gleichzeitig eine optimale Modellleistung gewährleistet. Zuvor wurden unsere Autocomplete-Sprachmodelle in Amazon EKS bereitgestellt, was eine unterschiedliche Anzahl von ml.g4dn.xlarge-Instanzen basierend auf der Speicherzuweisung pro Modell erforderte. Dies führte zu erheblichen monatlichen Kosten. Mit unserer jüngsten Migration zu SageMaker-MMEs konnten wir diese Kosten jedoch erheblich senken. Wir hosten jetzt alle unsere Modelle auf ml.g4dn.2xlarge-Instanzen, was uns die Möglichkeit gibt, Modelle effizienter zu packen. Dadurch konnten wir unsere monatlichen Ausgaben deutlich reduzieren und wir haben nun Kosteneinsparungen in der Größenordnung von 66–74 % erzielt. Dieser Schritt hat gezeigt, wie eine effiziente Ressourcennutzung durch den Einsatz von SageMaker-MMEs zu erheblichen finanziellen Einsparungen führen kann.
Zusammenfassung
In diesem Beitrag haben wir untersucht, wie Forethought Multimodell-Endpunkte von SageMaker nutzt, um die Kosten für Echtzeit-Inferenz zu senken. SageMaker übernimmt die undifferenzierte Schwerstarbeit, sodass Forethought die Engineering-Effizienz steigern kann. Darüber hinaus kann Forethought die Kosten für Echtzeit-Inferenz drastisch senken und gleichzeitig die für geschäftskritische Vorgänge erforderliche Leistung aufrechterhalten. Auf diese Weise ist Forethought in der Lage, seinen Kunden mithilfe hyperpersonalisierter Modelle ein differenziertes Angebot anzubieten. Verwenden Sie SageMaker MME, um Ihre Modelle in großem Maßstab zu hosten und die Hosting-Kosten durch eine verbesserte Endpunktauslastung zu senken. Es reduziert auch den Bereitstellungsaufwand, da Amazon SageMaker das Laden von Modellen im Speicher und deren Skalierung basierend auf den Verkehrsmustern zu Ihrem Endpunkt verwaltet. Codebeispiele zum Hosten mehrerer Modelle mit SageMaker MME finden Sie unter GitHub.
Über die Autoren
Jad Chamoun ist Director of Core Engineering bei Forethought. Sein Team konzentriert sich auf Plattform-Engineering und umfasst Data Engineering, Infrastruktur für maschinelles Lernen und Cloud-Infrastruktur. Sie finden ihn auf LinkedIn.
Salina Wu ist Senior Machine Learning Infrastructure Engineer bei Forethought.ai. Sie arbeitet eng mit dem Team für maschinelles Lernen zusammen, um deren umfassende Schulungs-, Bereitstellungs- und Dateninfrastrukturen aufzubauen und zu warten. Ihre besondere Motivation liegt darin, neue Wege zur Effizienzsteigerung und Kostensenkung im gesamten ML-Bereich einzuführen. Wenn sie nicht bei der Arbeit ist, geht Salina gerne surfen, töpfern und in der Natur unterwegs sein.
James Park ist Lösungsarchitekt bei Amazon Web Services. Er arbeitet mit Amazon.com zusammen, um Technologielösungen auf AWS zu entwerfen, zu erstellen und bereitzustellen, und hat ein besonderes Interesse an KI und maschinellem Lernen. In seiner Freizeit erkundet er gerne neue Kulturen, neue Erfahrungen und bleibt über die neuesten Technologietrends auf dem Laufenden. Sie finden ihn auf LinkedIn.
Sunil Padmanabhan ist Startup Solutions Architect bei AWS. Als ehemaliger Startup-Gründer und CTO beschäftigt er sich leidenschaftlich mit maschinellem Lernen und konzentriert sich darauf, Startups dabei zu helfen, KI/ML für ihre Geschäftsergebnisse zu nutzen und ML/KI-Lösungen in großem Maßstab zu entwerfen und einzusetzen.
Dhawal Patel ist Principal Machine Learning Architect bei AWS. Er hat mit Organisationen von großen Unternehmen bis hin zu mittelständischen Startups an Problemen im Zusammenhang mit verteiltem Computing und künstlicher Intelligenz gearbeitet. Er konzentriert sich auf Deep Learning, einschließlich NLP- und Computer Vision-Domänen. Er hilft Kunden, hochleistungsfähige Modellinferenz auf SageMaker zu erreichen.
- SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
- EVM-Finanzen. Einheitliche Schnittstelle für dezentrale Finanzen. Hier zugreifen.
- Quantum Media Group. IR/PR verstärkt. Hier zugreifen.
- PlatoAiStream. Web3-Datenintelligenz. Wissen verstärkt. Hier zugreifen.
- Quelle: https://aws.amazon.com/blogs/machine-learning/how-forethought-saves-over-66-in-costs-for-generative-ai-models-using-amazon-sagemaker/
- :hast
- :Ist
- :nicht
- :Wo
- $UP
- 1
- 10
- 100
- 12
- 13
- 15%
- 24
- 250
- 30
- 32
- 7
- 80
- a
- Fähigkeit
- Fähig
- Über Uns
- Abstraktion
- Abstracts
- beschleunigt
- Nach
- Genauigkeit
- genau
- genau
- Erreichen
- erreicht
- Erreichen
- über
- hinzufügen
- hinzugefügt
- Hinzufügen
- Zusatz
- Zusätzliche
- zusätzlich
- Adresse
- Adressierung
- advanced
- Vorteil
- Nach der
- Makler
- Agenten
- AI
- KI-Anwendungsfälle
- AI / ML
- gezielt
- ausrichten
- ausgerichtet
- Alle
- Zuteilung
- erlauben
- erlaubt
- bereits
- ebenfalls
- Obwohl
- Amazon
- Amazon Sage Maker
- Amazon Web Services
- Amazon.com
- Betrag
- an
- und
- Jährlich
- Ein anderer
- Antworten
- jedem
- Bienen
- APIs
- ersichtlich
- angemessen
- ca.
- Architektur
- SIND
- um
- Artikel
- künstlich
- künstliche Intelligenz
- AS
- Vorlagen
- damit verbundenen
- At
- Auto
- automatisieren
- Automatisiert
- Im Prinzip so, wie Sie es von Google Maps kennen.
- durchschnittlich
- vermeiden
- ein Weg
- AWS
- Backend
- Balance
- Base
- basierend
- BE
- wurde
- weil
- werden
- war
- Bevor
- beginnen
- Sein
- Benchmarking
- vorteilhaft
- Nutzen
- BESTE
- Besser
- zwischen
- Stärkung
- beide
- bringen
- bauen
- eingebaut
- Last
- Geschäft
- aber
- by
- Cache-Speicher
- berechnet
- rufen Sie uns an!
- namens
- Aufruf
- Aufrufe
- CAN
- Kandidaten
- Fähigkeiten
- Häuser
- Fälle
- Kümmert sich
- Verursachen
- challenges
- Herausforderungen
- Übernehmen
- Änderungen
- aus der Ferne überprüfen
- Wahl
- wählten
- Kunden
- eng
- Cloud
- Cloud-Infrastruktur
- Code
- Kälte
- Das Sammeln
- COM
- Kommen
- gemeinsam
- Unternehmen
- verglichen
- Kompatibilität
- kompatibel
- Computer
- Computer Vision
- Computing
- Bedenken
- Wettbewerber
- Bedingungen
- durchgeführt
- konfiguriert
- konservativ
- erheblich
- betrachtet
- Berücksichtigung
- Container
- Inhalt
- umgewandelt
- Kernbereich
- und beseitigen Muskelschwäche
- entspricht
- Kosten
- Einsparmaßnahmen
- kostengünstiger
- teuer werden
- Kosten
- könnte
- Abdeckung
- erstellen
- erstellt
- Erstellen
- wichtig
- CTO
- Original
- Kunde
- Kundendaten
- Kundenzufriedenheit
- Kundenservice
- Kundensupport
- Kunden
- maßgeschneiderte
- technische Daten
- Datum
- Ablehnen
- verringern
- tief
- tiefe Lernen
- definiert
- Definition
- Übergeben
- liefern
- Synergie
- Abhängig
- einsetzen
- Einsatz
- Bereitstellen
- Einsatz
- Implementierungen
- Design
- erwünscht
- Trotz
- Bestimmen
- entschlossen
- entschlossen
- Festlegung
- entwickelt
- Entwickler
- Gerät
- DID
- anders
- differenziert
- Direktor
- entdeckt
- deutlich
- verteilt
- Verteiltes rechnen
- Dabei
- Domain
- Domains
- Nicht
- Dramatisch
- im
- dynamisch
- dynamisch
- jeder
- Effizienz
- effizient
- effizient
- Einbettung
- ermöglichen
- ermöglicht
- End-to-End
- Endpunkt
- Eingriff
- Ingenieur
- Entwicklung
- zu steigern,
- Eine Verbesserung der
- genug
- gewährleisten
- Gewährleistung
- Unternehmen
- Arbeitsumfeld
- Fehler
- Sogar
- Jedes
- Beispiel
- vorhandenen
- erwartet
- Kosten
- teuer
- ERFAHRUNGEN
- Erfahrungen
- Experiment
- extern
- beschleunigt
- Reichen Sie das
- Mappen
- füllen
- Revolution
- finanziell
- Finden Sie
- Vorname
- passen
- FLOTTE
- Flexibilität
- konzentriert
- Folgende
- Aussichten für
- Format
- Früher
- gefunden
- Gründer
- vier
- für
- voll
- Funktionalität
- weiter
- Außerdem
- Lücken
- erzeugen
- erzeugt
- generativ
- Generative KI
- bekommen
- gif
- gegeben
- Unterstützung
- Kundenziele
- GPU
- GPUs
- Steigungen
- hätten
- Pflege
- Griff
- Griffe
- Handling
- passieren
- Hardware
- Haben
- mit
- he
- schwer
- schweres Heben
- Hilfe
- Unternehmen
- hilft
- GUTE
- Hohe Leistungsfähigkeit
- höher
- ihm
- seine
- Haube
- Gastgeber
- Hosting
- Hostingkosten
- STUNDEN
- Häuser
- Ultraschall
- aber
- HTML
- http
- HTTPS
- hunderte
- identifiziert
- if
- zeigt
- sofort
- zu unterstützen,
- Verbesserung
- in
- Inc.
- Einschließlich
- Eingehende
- Erhöhung
- zeigen
- angegeben
- Information
- Infrastruktur
- Infrastruktur
- innovativ
- Varianten des Eingangssignals:
- Eingänge
- Instanz
- beantragen müssen
- Integration
- Integration
- Intelligenz
- Interaktion
- Interaktionen
- Interesse
- in
- Einführung
- aufgerufen
- ruft auf
- beteiligt
- Problem
- IT
- SEINE
- selbst
- Reise
- jpg
- nur
- Aufbewahrung
- Wesentliche
- Wissen
- Wissen
- Sprache
- grosse
- Große Unternehmen
- größer
- Latency
- neueste
- Schicht
- führen
- führenden
- lernen
- am wenigsten
- geführt
- Legacy
- weniger
- Hebelwirkung
- Hebelwirkungen
- Facelift
- Belastung
- Laden
- Belastungen
- Logik
- Sneaker
- senken
- Maschine
- Maschinelles Lernen
- gemacht
- Main
- halten
- Aufrechterhaltung
- um
- verwalten
- verwaltet
- Management
- Managed
- flächendeckende Gesundheitsprogramme
- viele
- Markt
- Maximierung
- gemeint
- Memory
- Metadaten
- Metrik
- Migration
- Migration
- Million
- minimal
- Moll
- mildernd
- ML
- Modell
- für
- Überwachen
- monatlich
- mehr
- Zudem zeigt
- vor allem warme
- motiviert
- schlauer bewegen
- ziehen um
- viel
- Multi-Modell-Endpunkt
- mehrere
- sollen
- nativen
- Natur
- notwendig,
- Need
- erforderlich
- Bedürfnisse
- Neu
- Nlp
- jetzt an
- Anzahl
- Nvidia
- Ziel
- of
- WOW!
- bieten
- bieten
- Angebote
- vorgenommen,
- on
- einmal
- EINEM
- einzige
- Einkauf & Prozesse
- Gelegenheit
- optimal
- Optimierung
- or
- Auftrag
- Organisationen
- Andere
- UNSERE
- uns
- Ergebnisse
- übrig
- über Nacht
- Pack
- Paket
- verpackt
- Verpackung
- besondere
- besonders
- leidenschaftlich
- Patch
- Weg
- Schnittmuster
- Muster
- Leistung
- Perspektive
- Pipeline
- Plattform
- Plato
- Datenintelligenz von Plato
- PlatoData
- Points
- Politik durchzulesen
- Datenschutzrichtlinien
- Post
- Werkzeuge
- angetriebene
- vorgeführt
- früher
- vorher
- primär
- Principal
- Vor
- Probleme
- Prozessdefinierung
- Verarbeitung
- Produkt
- Produktion
- PRODUKTIVITÄT
- ordnungsgemäße
- zuverlässig
- die
- vorausgesetzt
- bietet
- Bereitstellung
- geschoben
- setzen
- Python
- Pytorch
- Qualität
- Abfragen
- Suche
- schnell
- Angebot
- Bereich
- Rangliste
- erreichen
- Echtzeit
- realisiert
- kürzlich
- kürzlich
- Veteran
- reduziert
- Reduzierung
- bezogene
- Relevanz
- relevant
- Zuverlässigkeit
- zuverlässig
- bleibt bestehen
- vertreten
- Anforderung
- Zugriffe
- falls angefordert
- Anforderung
- Voraussetzungen:
- erfordert
- Ressourcen
- Downloads
- Antworten
- Verantwortlichkeiten
- für ihren Verlust verantwortlich.
- Folge
- was zu
- Die Ergebnisse
- bewertet
- Recht
- starr
- Wurzel
- Führen Sie
- Laufen
- opfern
- sagemaker
- SageMaker-Inferenz
- gleich
- Zufriedenheit
- Speichern
- Einsparung
- Ersparnisse
- sah
- Skalierbarkeit
- skalierbaren
- Skalieren
- vergrößern
- Waage
- Skalierung
- Szenario
- Szenarien
- Wissenschaftler
- Suche
- Sicherheitdienst
- auf der Suche nach
- Senior
- getrennte
- Reihenfolge
- Modellreihe
- brauchen
- Lösungen
- Dienst
- kompensieren
- mehrere
- Shadow
- Formen
- Teilen
- von Locals geführtes
- sie
- signifikant
- bedeutend
- ähnlich
- Einfacher
- vereinfachen
- Single
- Größe
- klein
- smart
- So
- Lösung
- Lösungen
- LÖSEN
- einige
- Raumfahrt
- spezifisch
- speziell
- angegeben
- Spitze
- Aufführung
- Anfang
- begonnen
- Anfang
- Startups
- State-of-the-art
- Schritt
- Shritte
- Immer noch
- Lagerung
- einfach
- Schritte
- wesentlich
- so
- Suite
- Support
- Systeme und Techniken
- Tabelle
- angehen
- zugeschnitten
- Nehmen
- nimmt
- Target
- gezielt
- Ziele
- Aufgabe
- Team
- Teams
- Technologies
- Technologie
- getestet
- Tests
- als
- Vielen Dank
- zur Verbesserung der Gesundheitsgerechtigkeit
- Das
- ihr
- Sie
- Diese
- vom Nutzer definierten
- fehlen uns die Worte.
- nach drei
- Durch
- Tickets
- Zeit
- Zeitaufwendig
- zu
- Tokens
- Top
- Gesamt
- der Verkehr
- Training
- trainiert
- Ausbildung
- privaten Transfer
- Transformieren
- Übergang
- Trends
- versucht
- Triton
- Twice
- XNUMX
- tippe
- Typen
- für
- einzigartiges
- us
- Anwendungsbereich
- -
- Anwendungsfall
- benutzt
- Nutzer
- verwendet
- Verwendung von
- Verwendung
- Version
- sehr
- Seh-
- vs
- wollen
- wollte
- wurde
- Weg..
- Wege
- we
- Netz
- Web-Services
- waren
- wann
- ob
- welche
- während
- mit
- ohne
- Arbeiten
- gearbeitet
- Werk
- Sorgen
- würde
- Schreiben
- wu
- YAML
- Du
- Ihr
- Zephyrnet