KI-Inferenz in der Produktion: Wie aus Messdaten rechtzeitig ein Ergebnis wird

Was KI-Inferenz bedeutet

Inferenz ist nicht auf Sprachmodelle beschränkt. Der Forschungsbenchmark MLPerf Tiny umfasst beispielsweise auch die Anomalieerkennung an Geräuschdaten. Das belegt einen anderen Anwendungsbereich, aber noch nicht die Eignung eines bestimmten Modells für einen Temperaturverlauf.^[3]

Ein Modell anzuwenden und ein geeignetes Auswertungsverfahren auszuwählen sind unterschiedliche Aufgaben. Ob Grenzwert, Regelkarte oder trainiertes Modell zur Fragestellung passen, muss vor der Laufzeitplanung geklärt sein. Eine kürzere Rechenzeit macht ein ungeeignetes Verfahren nicht geeigneter.

Wann der Prozess das Ergebnis braucht

Als Architekturbeispiel dient eine Charge, deren Temperatur während einer festgelegten Haltephase aufgezeichnet wird. Ein bereits trainiertes Modell bewertet das abgeschlossene Messwertfenster und liefert einen Hinweis für die anschließende fachliche Prüfung. Betrachtet wird weder eine automatische Chargenfreigabe noch eine Regelung der Temperatur.

Im Beispiel soll der Hinweis der fachlichen Prüfung vorliegen, bevor die Charge den nächsten Prozessschritt erreicht; diese Frist legt der Betrieb fest, nicht das Modell.

Benötigt das Modell das vollständige Fenster, kann dieser Lauf erst ausgewertet werden, wenn die dafür erforderlichen Messwerte verfügbar sind. Die Dauer der Haltephase ist deshalb von der anschließenden Verarbeitungszeit zu unterscheiden. Aus einem Modell für abgeschlossene Fenster folgt kein Frühwarnsystem, das denselben Befund bereits während der Phase liefern könnte.

Die fachliche Prüfung benötigt gegebenenfalls zusätzliche Zeit. Auch sie wird nicht dadurch erledigt, dass das Modell sein Ergebnis schnell berechnet.

Was zwischen Messdaten und Hinweis Zeit kostet

Für eine einfache Verarbeitungskette lassen sich mehrere Zeitanteile unterscheiden: Messdaten werden bereitgestellt und gegebenenfalls übertragen, für das Modell vorbereitet, zur Auswertung eingeplant, berechnet und anschließend als Ergebnis bereitgestellt. Schritte können je nach Aufbau anders angeordnet sein oder sich überlappen. Die Kette ist ein Messplan für das Beispiel, keine allgemeingültige Formel.

Ein kurzer Modelllauf kann auf eine längere Wartezeit folgen. Deshalb müssen Anfang und Ende einer Zeitangabe feststehen: Beginnt die Messung mit dem vollständigen Messwertfenster, mit der Annahme der Anfrage oder erst mit dem Start des Modells? Endet sie mit dessen Ausgabe oder mit dem sichtbaren Hinweis in der Anwendung? Ohne diese Grenzen sind zwei Laufzeitangaben nicht sinnvoll vergleichbar.

Die Forschungsarbeit zum MLPerf Inference Benchmark beschreibt ausdrücklich, dass die Vorverarbeitung in ihrem Messaufbau nicht zeitlich erfasst wird. MLPerf Tiny grenzt Vor- und Nachverarbeitung ebenfalls aus seinem Messfenster aus. Solche Ergebnisse können eine klar definierte Modellmessung tragen; sie beschreiben damit nicht automatisch die gesamte Dauer vom Messwert bis zum verfügbaren Hinweis.^[1][3]

Auch die Eingangsseite braucht einen klaren Bezug: Zeitstempel und Status der Messmeldung helfen, Entstehung und Eingang eines Werts auseinanderzuhalten. Werden Zeitpunkte verschiedener Rechner miteinander verglichen, muss deren Zeitbasis für diese Messung geeignet sein.

Warum Durchsatz und Antwortzeit zusammen geprüft werden

Die Antwortzeit beschreibt die Dauer eines festgelegten Vorgangs. Der Durchsatz beschreibt, wie viele Eingaben oder Anfragen innerhalb einer Zeitspanne verarbeitet werden. Ein System kann viele Fenster insgesamt bearbeiten und trotzdem einzelne Ergebnisse zu spät liefern. Für die Prozessfrage werden deshalb beide Größen benötigt.^[1]

MLPerf Inference unterscheidet dafür mehrere Lastszenarien und verwendet je nach Szenario unterschiedliche Kennzahlen. Im Server-Szenario wird Durchsatz unter einer Latenzbedingung betrachtet; ein Offline-Szenario behandelt bereits verfügbare Eingaben. Das sind methodische Unterschiede, keine aus dem Benchmark übernehmbaren Zeitvorgaben für eine Charge.^[1]

Für unser Beispiel kommt als eigener Lastfall hinzu, dass mehrere Anlagen ihre Haltephase nahezu gleichzeitig abschließen. Dann treffen mehrere auszuwertende Fenster zusammen. Zu prüfen ist, ob diese Ankünfte Wartezeiten verursachen und ob die Hinweise trotzdem innerhalb der festgelegten Frist verfügbar werden. Dieser Fall ist eine Ableitung aus dem Produktionsablauf, keine Zuschreibung an die Benchmark-Szenarien.

Anfragen zu bündeln kann den Durchsatz erhöhen, aber zugleich die Antwortzeit verlängern. Die Serving-Forschung zu Clipper beschreibt genau diesen Zielkonflikt. Ob Bündelung im konkreten Aufbau hilft, muss deshalb unter der vorgesehenen Last und der benötigten Frist gemessen werden.^[2]

Ein Mittelwert allein zeigt nicht, wie lange langsamere Vorgänge benötigen. Ergänzend kann die Verteilung der Antwortzeiten betrachtet werden, etwa ein Perzentil und die tatsächlich beobachteten Fristüberschreitungen. Ein Perzentil aus einem Testlauf ist jedoch keine Zusage, dass eine maximale Frist in jedem künftigen Fall eingehalten wird.^[1]

Welche Kapazität der konkrete Lauf benötigt

Aus diesen Messprinzipien lässt sich ein Prüfplan für die vorgesehene Umgebung ableiten. Er beginnt beim Anwendungslauf und seinen Bedingungen, nicht bei einer pauschalen Aussage über die nötige Rechenleistung. Die folgenden Fragen sind ein Architekturvorschlag für das Beispiel, keine verbindliche Benchmark-Vorschrift.

• Welche Modellfassung wird mit welchem Eingabeformat und welchem Fensterumfang ausgeführt?
• Welche Vorbereitung und Ergebnisverarbeitung gehören zum gemessenen Ablauf?
• Welche Software und technische Umgebung werden verwendet?
• Welche Last ist zu erwarten, und welche gleichzeitig eintreffenden Fenster sollen zusätzlich geprüft werden?
• Welche fachlichen Qualitätsbedingungen und welche Frist muss der Lauf erfüllen?

Gemessen werden dann die festgelegte Gesamtdauer und – soweit im Aufbau erfassbar – ihre einzelnen Anteile. Durchsatz, Antwortzeitverteilung, fehlgeschlagene Vorgänge und Fristüberschreitungen werden getrennt festgehalten. So lässt sich untersuchen, ob das Modell selbst, eine Warteschlange oder ein anderer Teil der Verarbeitung den Ablauf begrenzt.

Ein Vergleich verschiedener Umgebungen braucht dieselbe fachliche Aufgabe und nachvollziehbar festgehaltene Bedingungen. MLPerf Inference verbindet Leistungsmessungen mit Qualitätsanforderungen. Für unseren Vergleich folgt daraus: Eine schnellere Variante ist ungeeignet, wenn sie die zuvor festgelegte Ergebnisqualität nicht mehr erreicht.^[1]

Wird beim Kapazitätstest auch die Modellfassung verändert, sollten die Modellfassungen auf denselben Fällen verglichen werden. Die Laufzeitmessung ersetzt diesen fachlichen Vergleich nicht. Ebenso wenig lässt sich aus einer Token-Rate für ein Sprachmodell ableiten, wie schnell ein anderes Modell unsere Temperaturfenster bewertet.

Was bei einem verspäteten Ergebnis offen bleibt

Für die Anzeige im Beispiel bleiben drei Angaben getrennt: ob das Fenster schon ausgewertet ist, ob das Ergebnis innerhalb der festgelegten Frist bereitgestellt wurde und was die abgeschlossene Auswertung ergeben hat. Ein Ergebnis kann deshalb zugleich verspätet und unauffällig sein.

Diese Unterscheidung betrifft das Auswertungsergebnis und ergänzt die Unterscheidung von fehlenden und verspäteten Messmeldungen auf der Eingangsseite. Ein auffälliger Befund benötigt anschließend eine fachliche Prüfung des Hinweises. Eine noch ausstehende Auswertung darf in dieser Anzeige nicht wie ein unauffälliges Ergebnis erscheinen.

Primärquellen und weiterführende Literatur

[1] MLPerf Inference Benchmark. Vijay Janapa Reddi et al., arXiv:1911.02549v2, 2020. Verwendet werden die Methoden und Messgrenzen dieser Fassung, keine aktuellen Benchmark-Ranglisten. Originalquelle

[2] Clipper: A Low-Latency Online Prediction Serving System. Daniel Crankshaw et al., arXiv:1612.03079v2, 2017. Repository-Manuskript. Originalquelle

[3] MLPerf Tiny Benchmark. Colby Banbury et al., arXiv:2106.07597v4, 2021. Originalquelle