Verbessern Sie die Leistung von Falcon-Modellen mit Amazon SageMaker | Amazon Web Services

Was ist das optimale Framework und die optimale Konfiguration für das Hosten großer Sprachmodelle (LLMs) für textgenerierende generative KI-Anwendungen? Trotz der Fülle an Optionen zur Bereitstellung von LLMs ist diese Frage aufgrund der Größe der Modelle, unterschiedlicher Modellarchitekturen, Leistungsanforderungen von Anwendungen usw. schwer zu beantworten. Der Amazon Sage Maker LMI-Container (Large Model Inference). erleichtert die Bereitstellung von LLMs durch die Zusammenführung einer Vielzahl verschiedener Frameworks und Techniken, die den Einsatz von LLMs optimieren. Der LMI-Behälter verfügt über einen leistungsstarken Portionsstapel namens DJL serviert das ist unabhängig vom zugrunde liegenden LLM. Es bietet Konfigurationsparameter auf Systemebene, die angepasst werden können, um die beste Leistung der Hosting-Infrastruktur für ein bestimmtes LLM zu erzielen. Es unterstützt auch aktuelle Optimierungen wie kontinuierliches Batching, auch bekannt als iteratives Batching oder rollierendes Batching, was zu erheblichen Verbesserungen des Durchsatzes führt.

In einem früheren Posthaben wir gezeigt, wie Sie den LMI-Container verwenden können, um die Falcon-Modellfamilie auf SageMaker bereitzustellen. In diesem Beitrag zeigen wir, wie man den Durchsatz und die Latenz bei der Bereitstellung von Falcon-40B mit Techniken wie kontinuierlichem Batching verbessern kann. Wir bieten außerdem ein intuitives Verständnis der vom SageMaker LMI-Container bereitgestellten Konfigurationsparameter, die Ihnen dabei helfen können, die beste Konfiguration für Ihre reale Anwendung zu finden.

Grundlagen der textgenerativen Inferenz für LLMs

Schauen wir uns zunächst einige Grundlagen zur Durchführung von Inferenzen für LLMs zur Textgenerierung an.

Weiterleitung, Aktivierungen und der KV-Cache

Bei einer gegebenen Eingabesequenz von Token werden sie in a ausgeführt forward pass über alle Schichten des LLM (wie Falcon), um den nächsten Token zu generieren. A forward pass bezieht sich auf den Prozess, bei dem Eingabedaten durch ein neuronales Netzwerk geleitet werden, um eine Ausgabe zu erzeugen. Bei der Textgenerierung umfasst der Vorwärtsdurchlauf die Eingabe eines anfänglichen Startwerts oder Kontexts in das Sprachmodell und die Generierung des nächsten Zeichens oder Tokens in der Sequenz. Um eine Textsequenz zu generieren, wird der Prozess oft iterativ durchgeführt, das heißt, er wird für jeden Schritt oder jede Position in der Ausgabesequenz wiederholt. Bei jeder Iteration generiert das Modell das nächste Zeichen oder Token, das Teil des generierten Texts wird, und dieser Prozess wird fortgesetzt, bis die gewünschte Textlänge generiert ist.

Textgenerierung mit Sprachmodellen wie Falcon oder GPT sind möglich autoregressive. Dies bedeutet, dass das Modell jeweils einen Token generiert und dabei die zuvor generierten Token konditioniert. Mit anderen Worten: Bei jeder Iteration verwendet das Modell den zuvor generierten Text als Eingabe und sagt das nächste Token basierend auf diesem Kontext voraus. Wie erwähnt in vLLM: Einfache, schnelle und kostengünstige LLM-Bereitstellung mit PagedAttentionBei diesem autoregressiven Dekodierungsprozess erzeugen alle Eingabe-Tokens in das LLM ihre Aufmerksamkeitsschlüssel- und Werttensoren, und diese Tensoren werden im GPU-Speicher gehalten, um die nächsten Token zu generieren. Diese zwischengespeicherten Schlüssel- und Werttensoren werden oft als bezeichnet KV cache.

Vorfüll- und Dekodierungsphasen

Bei einem autoregressiven Dekodierungsprozess, wie er bei der Textgenerierung mit Sprachmodellen wie Falcon verwendet wird, gibt es typischerweise zwei Hauptphasen: die prefill Phase und die decode Phase. Diese Phasen sind entscheidend für die Generierung kohärenter und kontextrelevanter Texte.

Die Vorfüllphase umfasst Folgendes:

• Ausgangskontext – Die Prefill-Phase beginnt mit einem anfänglichen Kontext oder Starttext, der vom Benutzer bereitgestellt wird. Dieser Ausgangskontext kann ein Satz, eine Phrase oder auch nur ein einzelnes Wort sein. Es legt den Ausgangspunkt für die Texterstellung fest und liefert den Kontext für das, was als nächstes kommt.
• Modellkonditionierung – Der bereitgestellte Kontext wird zur Konditionierung des Sprachmodells verwendet. Das Modell verwendet diesen Kontext als Eingabe und generiert basierend auf seinem Verständnis des Kontexts das nächste Token (Wort oder Zeichen) in der Sequenz.
• Token-Generierung – Das Modell generiert jeweils ein Token und sagt voraus, was als nächstes im Text kommen soll. Dieses Token wird an den Kontext angehängt und erweitert ihn so effektiv.
• Iterativer Prozess – Der Prozess der Token-Generierung wird iterativ wiederholt. Bei jedem Schritt generiert das Modell ein Token und berücksichtigt dabei den aktualisierten Kontext, der nun die in den vorherigen Schritten generierten Token enthält.

Die Vorfüllphase wird fortgesetzt, bis eine vorgegebene Stoppbedingung erfüllt ist. Diese Bedingung kann eine maximale Länge für den generierten Text, ein bestimmtes Token, das das Ende des Textes signalisiert, oder ein beliebiges anderes vom Benutzer oder der Anwendung festgelegtes Kriterium sein.

Die Dekodierungsphase umfasst Folgendes:

• Abschlüsse – Nach der Vorfüllphase haben Sie einen teilweise generierten Text, der möglicherweise unvollständig ist oder irgendwann abgeschnitten wird. Die Dekodierungsphase ist dafür verantwortlich, den Text so zu vervollständigen, dass er kohärent und grammatikalisch korrekt ist.
• Fortsetzung vom letzten Token – In der Dekodierphase beginnt das Modell mit dem letzten Token, das während der Vorfüllphase generiert wurde. Es verwendet dieses Token als Anfangskontext und generiert das nächste Token, um den Text fortzusetzen.
• Iterativer Abschluss – Wie in der Prefill-Phase ist der Prozess der Token-Generierung wieder iterativ. Das Modell generiert jeweils einen Token und orientiert sich dabei an den vorhergehenden Token in der Sequenz.
• Stoppbedingung – In der Dekodierungsphase gibt es auch eine Stoppbedingung, die mit der in der Vorfüllphase identisch sein kann, z. B. das Erreichen einer maximalen Länge oder die Begegnung mit einem Textende-Token. Wenn diese Bedingung erfüllt ist, wird der Generierungsprozess gestoppt.

Die Kombination der Vorfüll- und Dekodierungsphasen ermöglicht es autoregressiven Modellen, Text zu generieren, der auf einem anfänglichen Kontext aufbaut und kohärente, kontextrelevante und kontextkonsistente Textsequenzen erzeugt.

Beziehen auf Ein verteiltes Bereitstellungssystem für transformatorbasierte generative Modelle für eine detaillierte Erklärung des Prozesses.

Optimierung des Durchsatzes durch dynamisches Batching

Bisher haben wir nur über einen einzigen Eingang gesprochen. In der Praxis gehen wir davon aus, dass wir mit mehreren zufällig von den Anwendungsclients eingehenden Anfragen zur Inferenz gleichzeitig oder gestaffelt umgehen können. Auf herkömmliche Weise kann einfaches Batching verwendet werden, um den Durchsatz und die Auslastung der Rechenressourcen der GPU zu erhöhen. Beim Batching werden effektiv die numerischen Darstellungen von mehr als einer Anfrage in einem Batch kombiniert und parallele Ausführungen der autoregressiven Vorwärtsdurchläufe durchgeführt. Diese intelligente Dosierung erfolgt auf der Ausgabeseite. Der DJLServing-Server von SageMaker LMI kann so konfiguriert werden, dass er mehrere Anfragen stapelweise zusammenfasst, um sie parallel zu verarbeiten, indem die folgenden Parameter festgelegt werden dienende.Eigenschaften:

• max_batch_delay = 100 – Die maximale Verzögerung für die Stapelaggregation in Millisekunden. Der Standardwert beträgt 100 Millisekunden.
• Batch_Größe = 32 – Die dynamische Batchgröße. Der Standardwert ist 1.

Dies zeigt im Grunde, dass DJLServing Anfragen für jeweils 100 Millisekunden in die Warteschlange stellt. Wenn die Anzahl der in die Warteschlange gestellten Anfragen die angegebene Batch_size erreicht, wird die Ausführung des Batchs zur Inferenz im Backend geplant. Dies ist bekannt als dynamic batching. Es ist dynamisch, da sich die Batchgröße von Batch zu Batch ändern kann, je nachdem, wie viele Anfragen in diesem Zeitraum hinzugefügt wurden. Da Anforderungen jedoch unterschiedliche Merkmale aufweisen können (z. B. können einige Anforderungen die Form von 20 Eingabe-Tokens und 500 Ausgabe-Tokens haben, während andere möglicherweise umgekehrt sind und 500 Eingabe-Tokens, aber nur 20 Ausgabe-Tokens umfassen), können einige Anforderungen jedoch möglicherweise anders sein Führen Sie die Verarbeitung schneller durch als andere in der gleichen Charge. Dies könnte zu einer Unterauslastung der GPU führen, während darauf gewartet wird, dass alle laufenden Anforderungen im Stapel ihre Dekodierungsphase abschließen, selbst wenn in der Warteschlange weitere Anforderungen auf die Verarbeitung warten. Das folgende Diagramm veranschaulicht diesen Prozess.

Optimierung des Durchsatzes durch kontinuierliche Dosierung

Mit der continuous batching, auch bekannt als iterative or rolling Bei der Stapelverarbeitung nutzen wir die Unterschiede zwischen der Vorfüll- und der Dekodierungsstufe. Um kontinuierliches Batching zu aktivieren, stellt DJServing die folgenden zusätzlichen Konfigurationen gemäß „serving.properties“ bereit:

• Sie=MPI – Wir empfehlen Ihnen, die MPI-Engine für die kontinuierliche Stapelverarbeitung zu verwenden.
• option.rolling_batch=auto oder lmi-dist – Wir empfehlen die Verwendung von auto, da dadurch automatisch der am besten geeignete Rolling-Batch-Algorithmus zusammen mit anderen Optimierungen in der Zukunft ausgewählt wird.
• option.max_rolling_batch_size=32 – Dies begrenzt die Anzahl gleichzeitiger Anfragen. Der Standardwert ist 32.

Bei der kontinuierlichen Batchverarbeitung wartet der Serving-Stack (DJLServing) nicht darauf, dass alle laufenden Anfragen in einem Batch seine Decodierungsphase abschließen. Stattdessen werden bei logischen Unterbrechungen (am Ende einer Iteration in der Dekodierungsphase) zusätzliche Anforderungen eingezogen, die in der Warteschlange warten, während der aktuelle Stapel noch verarbeitet wird (daher der Name). rollende Charge). Diese Prüfung auf ausstehende Anforderungen wird am Ende jeder Iteration der Dekodierungsphase durchgeführt. Denken Sie daran, dass wir für jede Anfrage die Vorfüllphase und anschließend die sequentielle Dekodierungsphase ausführen müssen. Da wir alle Token von der ersten Eingabeaufforderung einer Anfrage für die Vorabfüllungsphase parallel verarbeiten können, pausieren wir jedes Mal, wenn eine neue Anfrage eingeht, vorübergehend die Dekodierungsphase der laufenden Anfragen des Stapels – wir speichern vorübergehend seinen KV-Cache und Aktivierungen im Speicher und führt die Vorbefüllungsphase der neuen Anforderungen aus.

Die Größe dieses Caches kann mit der folgenden Option konfiguriert werden:

Wenn die Vorabfüllung abgeschlossen ist, kombinieren wir die neuen Anfragen und die alten pausierten Anfragen in einem neuen rollierenden Stapel, der parallel mit seiner Dekodierungsphase fortfahren kann. Beachten Sie, dass die alten pausierten Anfragen ihre Dekodierungsphase dort fortsetzen können, wo sie aufgehört haben, und die neuen Anfragen mit ihrem ersten neuen Token beginnen.

Sie haben vielleicht bereits bemerkt, dass Continuous Batching ein fast ähnlicher Ansatz ist, mit dem wir Aufgaben in unserem täglichen Leben auf natürliche Weise parallelisieren. Zu zufälligen Zeiten gehen Nachrichten, E-Mails und Telefonbenachrichtigungen (möglicherweise neue Anfragen) ein (analog zu mehreren Anfragen, die bei GPUs zufällig gestaffelt eingehen). Dies alles geschieht, während wir unsere Aufgaben während des Flugs erledigen – E-Mails verfassen, programmieren, an Besprechungen teilnehmen (analog zu den aktuellen Verarbeitungsaufgaben in den GPUs). Bei logischen Pausen pausieren wir unsere Aufgaben während des Flugs und überprüfen unsere Benachrichtigungen, um zu entscheiden, ob von unserer Seite Handlungsbedarf besteht. Wenn dies der Fall ist, fügen wir diese zu unseren Aufgaben während des Flugs hinzu (echte rollierende Charge), oder Setzen Sie es auf eine To-Do-Liste (die Warteschlange).

Alles in allem: Wie man über die Speichernutzung von GPUs nachdenkt

Es wird empfohlen, Ihr Modell einem Lasttest zu unterziehen, um herauszufinden, welche Konfiguration für Ihren Geschäftsanwendungsfall am kostengünstigsten ist. Um ein Verständnis zu schaffen, visualisieren wir den Speicherbedarf der GPUs, während das Modell geladen wird und aufeinanderfolgende Anforderungen in einem fortlaufenden Stapel verarbeitet werden. Nehmen wir für diesen Beitrag an, dass wir das Falcon-40B-Modell auf eine Instanz des G5-Instance-Typs laden, auf der NVIDIA A10G-GPUs mit jeweils 24 GB Speicher installiert sind. Beachten Sie, dass ein ähnliches Verständnis für die Instance-Typen p3, p4 und p5 gilt, die mit den GPU-Serien V100, A100 und H100 geliefert werden.

Im Folgenden finden Sie eine Übersicht, wie Sie einen ungefähren Wert des Gesamtspeicherbedarfs für Falcon-40B ermitteln können:

• Modellgröße = Anzahl der Modellparameter (40 Milliarden für Falcon-40B) x 4 Bytes pro Parameter (für FP32) = 160 GB
• Ungefährer Gesamtspeicherbedarf zum Laden von Falcon-40B für die Inferenz = Modellgröße (=160 GB) + KV-Cache (Attention Cache) (=*20 GB) + zusätzlicher Speicheraufwand durch ML Frameworks (ca. 2 GB)

Wenn wir für Falcon-40B das Modell komprimieren, indem wir es auf den Datentyp bfloat16 (2 Byte) quantisieren, beträgt die Modellgröße etwa 80 GB. Wie Sie sehen können, ist dies immer noch größer als der von einem Beschleunigergerät unterstützte Speicher, daher müssen wir eine spezielle Modellpartitionierungstechnik (Sharding) anwenden Tensorparallelität (TP)-Ansatz und Aufteilung des Modells auf mehrere Beschleunigergeräte. Nehmen wir an, wir haben g5.24xlarge gewählt, das über 4 A10G-GPU-Geräte verfügt. Wenn wir DJLServing (serving.properties) wie folgt konfigurieren, können wir davon ausgehen, dass die 80 GB Modellgewichte gleichmäßig auf alle 4 GPUs aufgeteilt werden:

Mit der tensor_parallel_degree Bei der Einstellung 4 sind bereits etwa 20 GB des 24 GB großen GPU-Speichers (ca. 84 %) ausgelastet, noch bevor eine einzelne Anfrage verarbeitet wurde. Die restlichen 16 % der GPU werden für den KV-Cache für die eingehenden Anfragen verwendet. Es ist möglich, dass für Ihr Geschäftsszenario und dessen Latenz- und Durchsatzanforderungen 2–3 GB des verbleibenden Speichers mehr als ausreichend sind. Wenn nicht, können Sie die Instanzgröße auf g5.48xlarge erhöhen, das über 8 GPUs verfügt und „tensor_parallel_degree“ auf 8 setzt. In einem solchen Fall werden nur etwa 10 GB des verfügbaren 24-GB-Speichers jeder GPU für Modellgewichtungen und uns genutzt Ich habe etwa 60 % der verbleibenden GPU für die Aktivierungen und den KV-Cache. Intuitiv können wir erkennen, dass diese Konfiguration uns möglicherweise einen höheren Durchsatz ermöglicht. Da wir jetzt über einen größeren Puffer verfügen, können wir außerdem die erhöhen max_rolling_batch_prefill_tokens und max_rolling_batch_size Parameter zur weiteren Optimierung des Durchsatzes. Zusammen steuern diese beiden Parameter die Vorbelegungen der Aktivierungsvorfüllungen und des KV-Cache für das Modell. Eine größere Zahl für diese beiden Parameter führt zu einem größeren Durchsatz, vorausgesetzt, Sie verfügen über genügend Puffer für den KV-Cache im GPU-Speicher.

Kontinuierliches Batching mit PagedAttention

PagedAttention ist ein neuer, von der UC Berkeley entwickelter Optimierungsalgorithmus, der den kontinuierlichen Batch-Prozess verbessert, indem er ermöglicht, dass der Aufmerksamkeitscache (KV-Cache) nicht zusammenhängend ist, indem Speicher in Seiten oder Blöcken fester Größe zugewiesen wird. Dies ist inspiriert von virtuellen Speicher- und Paging-Konzepten, die von Betriebssystemen verwendet werden.

Gemäß der vLLM Auf Papier wird der Aufmerksamkeitscache jeder Tokensequenz in Blöcke unterteilt und über eine Blocktabelle physischen Blöcken zugeordnet. Während der Aufmerksamkeitsberechnung kann ein PagedAttention-Kernel die Blocktabelle verwenden, um die Blöcke effizient aus dem physischen Speicher abzurufen. Dies führt zu einer erheblichen Reduzierung der Speicherverschwendung und ermöglicht eine größere Stapelgröße, eine höhere GPU-Auslastung und einen höheren Durchsatz.

Leistungsvergleich

Um einen effektiven Lasttest Ihrer Bereitstellungskonfiguration sicherzustellen, wird empfohlen, zunächst das Geschäftsszenario zu berücksichtigen und die Merkmale der Eingabe und Ausgabe für die LLM-basierte Anwendung klar zu definieren. Wenn Sie beispielsweise an einem Anwendungsfall für eine Call-Center-Zusammenfassung arbeiten, könnte die Eingabe aus größerem Text bestehen, etwa aus einem 500-Token-Chat-Transkript zwischen einem Kundendienstmitarbeiter und einem Kunden, aber die Ausgabe könnte relativ kleiner sein, etwa 100 Token, die eine Zusammenfassung des Transkripts darstellen. Wenn Sie andererseits an einem Codegenerierungsszenario arbeiten, könnte die Eingabe nur 15 Token umfassen, etwa „Schreiben Sie eine effiziente Implementierung in Python zur Beschreibung aller EC2-Ressourcen, einschließlich Paginierung“, aber die Ausgabe könnte viel sein größer und erreicht 500 Token. Es ist auch wichtig zu überlegen, ob das Erreichen einer geringeren Latenz oder die Maximierung des Durchsatzes für Ihr spezifisches Szenario oberste Priorität hat.

Nachdem Sie ein umfassendes Verständnis des Geschäftsszenarios gewonnen haben, können Sie die optimale Konfiguration für Ihre Hosting-Umgebung analysieren und ermitteln. In diesem Zusammenhang umfasst die Hosting-Umgebung verschiedene Schlüsselelemente, einschließlich des Instanztyps und anderer Konfigurationsparameter wie z tensor_parallel_degree, max_rolling_batch_size, max_rolling_batch_prefill_tokens, und mehr. Unser Ziel ist es, das effektivste Setup zu ermitteln, um unsere Anforderungen an Reaktionszeit, Durchsatz und Modellausgabequalität zu unterstützen.

In unserer Analyse haben wir die Leistung verglichen, um die Vorteile der kontinuierlichen Dosierung gegenüber der herkömmlichen dynamischen Dosierung zu veranschaulichen. Wir haben die in der folgenden Tabelle aufgeführten Konfigurationen in „serving.properties“ für die dynamische und iterative Stapelverarbeitung unter Verwendung eines LMI-Containers auf SageMaker verwendet.

Dynamische Stapelverarbeitung	Kontinuierliche Dosierung	Kontinuierliche Stapelverarbeitung mit PagedAttention
engine=Python option.model_id=tiiuae/falcon-40b option.tensor_parallel_degree=8 option.dtype=fp16 batch_size=4 max_batch_delay=100 option.trust_remote_code = true	Motor = MPI option.model_id = {{s3_url}} option.trust_remote_code = true option.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = auto option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = Falsch	Motor = MPI option.model_id = {{s3_url}} option.trust_remote_code = true option.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = auto option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = True

Die beiden Konfigurationen wurden für Falcon-40B mit dem auf ml.g16xlarge bereitgestellten FP5.48-Datentyp in verschiedenen Szenarien verglichen, die reale Anwendungen darstellen:

• Eine kleine Anzahl von Eingabe-Tokens, wobei eine große Anzahl von Tokens generiert wird – In diesem Szenario wurde die Anzahl der Eingabe-Tokens auf 32 festgelegt und es wurden 128 neue Tokens generiert

Batch-Strategie	Durchsatz (Tokens/Sek.)	Latenz p90 (Sek.)
Dynamische Stapelverarbeitung	5.53	58.34
Kontinuierliche Dosierung	56.04	4.74
Kontinuierliche Stapelverarbeitung mit PagedAttention	59.18	4.76

• Eine große Eingabe mit einer kleinen Anzahl generierter Token – Hier legen wir die Anzahl der Eingabe-Tokens auf 256 fest und veranlassen den LLM, die Eingaben auf 32 Tokens zusammenzufassen

Batch-Strategie	Durchsatz (Tokens/Sek.)	Latenz p90 (Sek.)
Dynamische Stapelverarbeitung	19.96	59.31
Kontinuierliche Dosierung	46.69	3.88
Kontinuierliche Stapelverarbeitung mit PagedAttention	44.75	2.67

Wir können sehen, dass die kontinuierliche Stapelverarbeitung mit PagedAttention im Vergleich zur Verwendung der dynamischen Stapelverarbeitung auf SageMaker bei Verwendung des LMI-Containers eine um das Zehnfache und in Szenario 10 um das 1-fache höhere Durchsatzverbesserung in Szenario 2.3 bietet.

Zusammenfassung

In diesem Beitrag haben wir untersucht, wie LLMs Speicher nutzen, und erklärt, wie kontinuierliches Batching den Durchsatz mithilfe eines LMI-Containers auf SageMaker verbessert. Wir haben die Vorteile der kontinuierlichen Chargenbildung für Falcon-40B mithilfe eines LMI-Containers auf SageMaker anhand von Benchmark-Ergebnissen demonstriert. Den Code finden Sie auf der GitHub Repo.

---

Über die Autoren

Abhi Shivaditya ist Senior Solutions Architect bei AWS und arbeitet mit strategischen globalen Unternehmensorganisationen zusammen, um die Einführung von AWS-Services in Bereichen wie künstliche Intelligenz, verteiltes Computing, Netzwerk und Speicher zu erleichtern. Seine Expertise liegt im Deep Learning in den Bereichen Natural Language Processing (NLP) und Computer Vision. Abhi unterstützt Kunden bei der effizienten Bereitstellung leistungsstarker Modelle für maschinelles Lernen innerhalb des AWS-Ökosystems.

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.

Pinak Panigrahi arbeitet mit Kunden zusammen, um auf maschinellem Lernen basierende Lösungen zu entwickeln, um strategische Geschäftsprobleme auf AWS zu lösen. Wenn er sich nicht gerade mit maschinellem Lernen beschäftigt, kann man ihn beim Wandern, beim Lesen eines Buches oder beim Sportschauen antreffen.

Abhi Sodhani ist Senior AI/ML Solutions Architect bei AWS, wo er sich darauf spezialisiert hat, Kunden technisches Fachwissen und Beratung zu generativen KI- und ML-Lösungen anzubieten. Sein Hauptaugenmerk liegt darauf, Digital Native-Unternehmen dabei zu unterstützen, das volle Potenzial generativer KI- und ML-Technologien auszuschöpfen, damit sie ihre Geschäftsziele effektiv erreichen können. Über seine beruflichen Aktivitäten hinaus zeigt Abhi eine starke Leidenschaft für intellektuelle Aktivitäten wie Lesen sowie für Aktivitäten, die das körperliche und geistige Wohlbefinden fördern, wie Yoga und Meditation.

Qing Lan ist Softwareentwicklungsingenieur bei AWS. Er hat an mehreren herausfordernden Produkten bei Amazon gearbeitet, darunter Hochleistungs-ML-Inferenzlösungen und Hochleistungs-Protokollierungssysteme. Das Team von Qing führte erfolgreich das erste Billion-Parameter-Modell in Amazon Advertising mit sehr geringer Latenz ein. Qing verfügt über fundierte Kenntnisse in den Bereichen Infrastrukturoptimierung und Deep-Learning-Beschleunigung.

• 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/improve-performance-of-falcon-models-with-amazon-sagemaker/