Modal startet Endpoint Candidates: Änderungen an der Inferenz mit Live-Traffic testen

Was Endpoint Candidates leisten

Laut Modal stehen Latenz, Durchsatz und Kostenoptimierung im Zentrum moderner Inferenz-Entwicklung, und keine dieser Kennzahlen lasse sich ohne Tests und Messungen verlässlich verbessern. Endpoint Candidates seien das erste von mehreren Werkzeugen, mit denen das Unternehmen Nutzern helfen wolle, ihre eigenen Inferenz-Server zu optimieren.

Ein Candidate ist ein alternatives Deployment, das einem bestehenden Dedicated Endpoint zugeordnet wird. Er kann die Produktion spiegeln, indem er einen Teil des Produktions-Traffics verarbeitet, während Modal die zugrunde liegende Infrastruktur betreibt. Teams können damit neue Modell-Checkpoints oder sogar komplett andere Modelle testen, ohne eine eigene Infrastruktur für Traffic-Spiegelung und Deployment aufzubauen, so das Unternehmen.

So erstellen, bewerten und befördern Sie einen Candidate

Der Einstieg erfolgt über einen bestehenden Dedicated Endpoint in einer Modal-Umgebung. Nutzer wählen Create candidate und entscheiden sich entweder für ein offenes Modell aus Modals Katalog oder für eigene Gewichte aus einem Hugging-Face-Repository oder einem Modal Volume. Sobald der Candidate bereit ist, konfigurieren sie eine Traffic-Stichprobe, um Produktionsanfragen darauf zu spiegeln.

Die Produktion bearbeitet weiterhin jede ursprüngliche Anfrage und liefert die Antwort, die Nutzer sehen. Das Dashboard zeigt die Inferenz-Metriken des Candidate, darunter Latenz und Durchsatz, und unterstützt Performance-Benchmarks, die das Verhalten unter Last sichtbar machen. Jeder Candidate hat eine eigene URL, sodass bestehende Evaluierungen dagegen laufen können, um die Qualität der Ausgaben zu beurteilen.

• Wird ein Candidate im Dashboard befördert, startet ein Produktions-Rollout unter der bestehenden Endpoint-URL.
• Andere Candidates bleiben für unabhängige Tests verfügbar.
• Für Endpoint Candidates gilt die übliche Modal-Compute-Preisgestaltung, einschließlich der Rechenleistung für gespiegelte Anfragen.

Wie langsame Spiegel die Produktion nicht ausbremsen

Modal zufolge bestand eine der größten Schwierigkeiten beim Bau der Traffic-Spiegelung darin, zu verhindern, dass langsame Spiegel die Produktion aufhalten. Erhalten mehrere Candidates Kopien einer großen Anfrage, lesen sie die Daten möglicherweise unterschiedlich schnell, und ein Proxy kann am Ende große Datenmengen zwischenspeichern, während er auf die langsameren wartet.

Um das zu lösen, hat Modal seinen auf Pingora basierenden Proxy so erweitert, dass er jeden Anfrage-Stream für jeden Candidate, der eine Kopie erhält, in einen eigenen, begrenzten Puffer aufteilt. Jeder Spiegel liest unabhängig. Trifft ein neuer Datenblock ein und ein Puffer ist voll, bricht der Proxy diese gespiegelte Anfrage ab, während die Produktion und die übrigen Spiegel weiterlaufen.

Eine Begrenzung pro Spiegel allein deckt einen ausgelasteten Proxy nicht ab, der viele Anfragen gleichzeitig spiegelt. Deshalb begrenzt Modal zusätzlich die von Spiegeln vorgehaltenen Body-Daten pro Proxy-Prozess. Spiegel teilen sich Datenblöcke des Request-Body, sodass jeder Block nur einmal auf das Budget angerechnet wird. Da ein Netzwerk-Schreibvorgang einen Block auch nach dem Verlassen eines Puffers noch halten kann, zählt der Block so lange weiter, bis der letzte Spiegel ihn freigibt. Würde das Hinzufügen des nächsten Blocks das Budget überschreiten, bricht der Proxy die Spiegel dieser Anfrage ab, während die ursprüngliche Anfrage weiterläuft.

Die Spiegelung erfolgt bewusst nach dem Best-Effort-Prinzip. Gespiegelte Anfragen können unter Druck verworfen werden, damit die Produktion nicht auf einen langsamen oder fehlerhaften Candidate warten muss.

Was das für Nutzer bedeutet

Für Teams, die Dedicated Endpoints auf Modal betreiben, bieten Candidates die Möglichkeit, ein neues Modell oder einen neuen Checkpoint vor dem Wechsel mit realem Traffic zu vergleichen. Da gespiegelte Anfragen nur nach bestem Bemühen verarbeitet werden, können unter Last einzelne Kopien verloren gehen, und die gespiegelte Rechenleistung wird zu Standardpreisen berechnet.

Modal will nach eigenen Angaben mehr Kontrolle über die Platzierung von Rechenressourcen und über Serving-Rezepte ergänzen sowie umfangreichere Metrik-Ansichten für den Vergleich von Deployments. Zudem soll mehr Experimentieren automatisiert werden. Das Unternehmen verknüpft dies mit seiner früheren Arbeit an Auto Endpoints zur Automatisierung der Inferenz-Optimierung und beschreibt Candidates als Ort, an dem sich solche Optimierungen bewähren sollen: Modal könnte vielversprechende Änderungen mit dem Traffic eines Kunden testen und anschließend gemessene Verbesserungen bei Latenz, Durchsatz oder Kosten aufzeigen.