Lasttests für servierende Endpunkte

Dieser Artikel führt Sie durch den wesentlichen Prozess der Auslastungstests Ihres Mosaik AI Model Serving-Endpunkts, um sicherzustellen, dass sie Produktionsworkloads effektiv verarbeiten können. Sie enthält außerdem praktische Beispiele, reale Analogien und schrittweise Anleitungen mithilfe des Locust Load Testing Frameworks, um zu veranschaulichen, wie wichtige Leistungsmetriken wie Anforderungen pro Sekunde und Parallelitätsgrenzwerte gemessen werden, damit Sie Ihre Endpunkte ordnungsgemäß anpassen und Modelle für Ihre Geschäftsanforderungen sicher bereitstellen können.

Was ist ein Auslastungstest?

Ein Auslastungstest ist ein Test, der die reale Nutzung des Mosaik KI-Modells simuliert, das Endpunkte bedient, um sicherzustellen, dass sie Ihre Produktionsanforderungen erfüllen, z. B. Latenz oder Anforderungen pro Sekunde. Ein Auslastungstest misst die Leistung Ihres Endpunkts unter verschiedenen Datenverkehrsebenen und hilft Ihnen dabei, den Endpunkt richtig zu vergrößern, damit Verzögerungen nicht verursacht werden.

Bild: Es ist 8:00 Uhr an einem Wochentag, und ein beliebtes Café im Herzen der Stadt ist gerade eröffnet. Das Aroma frischer Kaffee füllt die Luft. Der Barista ist vorbereitet, die Maschinen sind aufgewärmt, und die Schlange von koffeinberaubten Kunden bildet sich bereits.

Zunächst laufen die Dinge reibungslos. Ein paar Kunden steigen auf, aufgeben ihre Bestellungen, und der Barista beginnt mit der Zubereitung ihrer Getränke. Einige Getränke dauern 30 Sekunden, andere nehmen eine Minute – je nach Komplexität. Der Barista jongliert mehrere Bestellungen mit geübter Effizienz.

Aber bald kommen mehr Menschen an. Fünf Kunden verwandeln sich in zehn, dann zwanzig. Jeder gibt eine Bestellung ab, wartet auf ihr Getränk und plaudert vielleicht ein bisschen am Tresen. Der Barista ist jetzt unter Druck. Selbst wenn ein zweiter Barista einspringt, gerät das System unter Druck – die Warteschlange wächst, Bestellungen stapeln sich und die Kunden müssen länger warten.

Stellen Sie sich nun vor, Sie versuchen zu messen, wie viele Getränke das Café pro Minute bedienen kann, bevor die Kunden frustriert bleiben. Das ist ein Lasttest.

In dieser Analogie:

• Jeder Kunde ist ein Kunde , der eine Anforderung sendet.
• Die Barista(s) repräsentieren Ihre server die Modellinferenzen einzeln oder parallel verarbeitet.
• Die Zeit, um eine Bestellung zu nehmen und das Getränk zu bedienen, ist die Modellimplementierungszeit .
• Verzögerungen beim Sprechen, Bezahlen oder Auffinden der Bestellung sind Ihr Netzwerkaufwand.
• Mehr Kunden, die gleichzeitig ankommen, nennt man Client-Konkurrenz.
• Das Hinzufügen weiterer Baristas oder Maschinen ist wie das Erhöhen der Server-Gleichzeitigkeit.

Wie in jedem guten Café gibt es ein Limit, wie viel die Mitarbeiter gleichzeitig verarbeiten können. Wenn Sie nicht vorausplanen – zum Beispiel, indem Sie mehr Baristas für die Stoßzeiten einplanen – verlassen die Menschen das Café unzufrieden. Das gleiche gilt für Ihre Systeme unter Last. Mithilfe von Auslastungstests können Sie ermitteln, wo sich die Engpässe befinden, wie viel Datenverkehr Ihr System verarbeiten kann, und welche Änderungen Sie für einen reibungsloseren Dienst vornehmen müssen.

Bevor Sie einen Auslastungstest auf Ihrem Endpunkt ausführen, müssen Sie:

• Verstehen Sie die Komponenten und Konzepte für Lasttests.
• Entscheiden und definieren Sie Ihre Produktionsanforderungen.
• Suchen Sie eine repräsentative Nutzlast für das Lasttestframework, das beim Benchmarking Ihres Endpunkts verwendet werden soll.

Lasttestkonzepte und Definitionen

Die folgende Tabelle definiert Konzepte im Zusammenhang mit Lasttests:

Latenzanforderungen

Definieren Sie basierend auf Ihren Geschäftlichen und Kundenanforderungen die ideale Leistung Ihres Systems. Bei einem Modellbereitstellungsendpunkt umfasst die Latenz die Round-Trip-Zeit, die ein Client beim Senden von Daten für die Inferenz erlebt. Dies schließt die Netzwerklatenz sowie die Ableitungszeit ein. Es ist wichtig sicherzustellen, dass Ihre Anforderungen realistisch sind. Wenn Ihr Modell z. B. 15 MS benötigt, um eine Ableitung beim Laden in den Arbeitsspeicher durchzuführen, müssen Sie zusätzliche Zeit für die Netzwerklatenz zulassen, wenn sie für ein Modell bereitgestellt wird, das den Endpunkt bedient.

Wie stehen RPS, Latenz und Parallelität in Beziehung?

Ein Unternehmen hat einige definierte Kriterien für den Erfolg ihres Systems. Bei ML-Systemen sind Geschäftskriterien in der Regel qualitativ hochwertige Ergebnisse, niedrige Latenz und hoher Durchsatz. Die Qualität der Ergebnisse bezieht sich speziell auf das Modell selbst, während End-to-End-Latenz und Durchsatz Eigenschaften des Dienstsystems sind. End-to-End-Latenz besteht aus der Modellausführungszeit und dem Netzwerkaufwand. Der Durchsatz (oder Anforderungen oder Abfragen pro Sekunde) steht in umgekehrter Beziehung zur Latenz und in direkter Beziehung zur Gleichzeitigkeit.

• Je höher die Parallelität ist, desto höher ist der Durchsatz.
• Je höher die Latenzzeit, desto geringer der Durchsatz.

Im Allgemeinen gibt es ein optimales Verhältnis von clientseitiger Parallelität zu serverseitiger Parallelität für jede bestimmte Anwendung. Als Beispiel: "Wie viele Burger kann ein Linienkoch gleichzeitig zubereiten?" Da es möglicherweise viele gemeinsame Schritte im Kochprozess gibt, kann der Linienkoch vier Hamburger gleichzeitig optimal kochen, anstatt jeweils nur einzeln zu kochen. Es gibt ein Limit für diese Parallelisierung, irgendwann fügt der Akt der Durchführung vieler paralleler Handlungen zu viel Latenz hinzu, z. B. wenn der Koch Käse zu 1000 Burgern hinzufügen muss.

Eines der zentralen Ziele eines Lasttests besteht darin, das optimale Verhältnis für Ihre Anwendung zu bestimmen. Das optimale Verhältnis maximiert RPS, erfüllt Ihre Latenzanforderungen und vermeidet Warteschlange. Dieses Verhältnis kann verwendet werden, um die Größe Ihres Endpunkts genau zu bestimmen, sodass Ihre anspruchsvollsten Lasten bewältigt werden.

Wenn der Endpunkt Anforderungen nicht schnell genug verarbeiten kann, beginnt sich eine Warteschlange zu bilden. Dies wird als Warteschlange bezeichnet. Die Erstellung einer Warteschlange führt in der Regel zu einer viel längeren End-to-End-Latenz, da jetzt zusätzliche Zeit für jede Anforderung ausgegeben wird, bevor sie verarbeitet wird. Wenn Anforderungen weiterhin schneller eingehen, als Anforderungen verarbeitet werden können, wächst die Warteschlange, wodurch die Latenz weiter erhöht wird. Aus diesem Grund ist es wichtig zu verstehen, welche Art von Spitzennachfrage Ihr Endpunkt möglicherweise erleben kann, und sicherstellen, dass er mit einem Auslastungstest ordnungsgemäß angepasst wird.

Beispiele für Auslastungstestszenarios

Bei Auslastungstests und in realen Systemen ist die Beziehung zwischen Client-Konkurrenz, Server-Konkurrenz und Latenz dynamisch und wechselseitig abhängig. Sehen wir uns diese Beziehung mit einem einfachen Beispiel an:

Szenario 1: Einfache Einrichtung

In diesem Setup sendet ein einzelner Client Anforderungen sequenziell – er wartet auf eine Antwort, bevor die nächste Anforderung ausgestellt wird. Da die Gesamtzeit pro Anforderung die Summe der Modellausführungs- und Overheadlatenz (40 ms + 10 ms) ist, beträgt die gemessene End-to-End-Latenz 50 ms.

• Anzahl der Clients: 1
• Bereitgestellte Gleichzeitigkeit: 1
• Overhead-Latenz: 10 ms
• Modellausführungszeit 40 ms

Daher führt der Client eine Anforderung alle 50 ms durch, was 20 Anforderungen pro Sekunde oder Abfragen pro Sekunde entspricht.

Szenario 2: Erhöhung der bereitgestellten Gleichzeitigkeit

In diesem Fall haben Sie die doppelte bereitgestellte Gleichzeitigkeit und einen einzelnen Client, der die Anforderungen sequentiell ausführt. Dies bedeutet, dass die Gesamtlatenz immer noch 50 ms (40 ms + 10 ms) beträgt und das System nur 20 Anforderungen pro Sekunde (QPS) anzeigt.

• Anzahl der Clients: 1
• Bereitgestellte Gleichzeitigkeit: 1 -> 2
• Overhead-Latenz: 10 ms
• Modellausführungszeit 40 ms

Szenario 3: Hinzufügen eines weiteren Clients zum System.

Jetzt haben Sie zwei Clients, die Anfragen an einen Endpunkt mit zwei bereitgestellten Parallelitäten senden. In diesem Fall können die Anforderungen jedes Clients unabhängig voneinander und gleichzeitig vom Endpunkt verarbeitet werden (perfekte Lastverteilung vorausgesetzt). Während die Gesamtlatenz noch 50 ms beträgt (40 ms + 10 ms), beobachtet das System 40 Anforderungen pro Sekunden, da jeder Client 20 qps sendet.

• Anzahl der Clients: 1 -> 2
• Bereitgestellte Gleichzeitigkeit: 2
• Overhead-Latenz: 10 ms
• Modellausführungszeit 40 ms

Das Erhöhen der bereitgestellten Parallelität und die Anzahl der Clients, die Anforderungen stellen, erhöht die Gesamtzahl der in Ihrem System beobachteten QPS, ohne dass die Latenz beeinträchtigt wird.

Szenario 4: Verringern Sie die bereitgestellte Gleichzeitigkeit

In diesem letzten Szenario ist die Anzahl der Clients größer als die bereitgestellte Parallelität. Dieses Setup führt eine weitere Variable, Warteschlange, im System und deren Auswirkungen auf QPS und Latenz ein.

• Anzahl der Clients: 2
• Bereitgestellte Gleichzeitigkeit: 2 -> 1
• Overhead-Latenz: 10 ms
• Modellausführungszeit: 40 ms

Hier haben Sie zwei Clients, die gleichzeitig Anforderungen stellen. Der Endpunkt kann jedoch nur jeweils eine einzelne Anforderung verarbeiten. Dadurch wird die zweite Anforderung gezwungen, zu warten, bevor die erste Anforderung verarbeitet wurde. Das Warten, oder richtiger gesagt, das Warten in der Warteschlange der zweiten Anforderung kann sich negativ auf die Latenz des Systems auswirken. Vorausgesetzt, der Server lässt die Warteschlangenfunktion zu (standardmäßig in Databricks Model Serving aktiviert), sieht der zweite Client eine Latenz von 90 ms: 10 ms (Netzwerkaufwand) + 40 ms (Warteschlangenwartezeit) + 40 ms (Modellausführungszeit). Dies ist deutlich schlechter als die zuvor gesehenen 50 ms.