Inferenz beim maschinellen Lernen Wie trainierte Modelle Mehrwert in der Produktion generieren

Wenn eine neue Anforderung eine Produktionsapplikation erreicht, hat ein ML-Modell möglicherweise nur Sekunden Zeit, den neuesten Kontext zu bewerten, ein Ergebnis zu erstellen und es an das System zurückzugeben, das entscheidet, was als Nächstes passiert.

Dieser Moment ist Inferenz: der Prozess, in dem ein trainiertes Modell auf Live-Daten angewendet wird, damit die Anwendung handeln kann. In der Produktion hängt die Inferenz vom gesamten Laufzeitpfad ab. Wenn ein Teil dieses Pfads ausbricht, verlangsamt wird oder von der während des Trainings verwendeten Logik abweicht, kann die Vorhersage zu spät eintreffen oder zu sehr von der Realität abweichen, um nützlich zu sein.

Trace Smith, Senior AI/ML Architect, Applied Field Engineering bei Snowflake, erklärt, warum die Herausforderung der Zuverlässigkeit mehr als nur schnell ist: „Bei Echtzeit-ML-Anwendungen wie Betrugserkennung und vorausschauender Wartung erregen Latenz und Skalierbarkeit Aufmerksamkeit. Doch Konsistenz ist das, was die Produktion oft unterbricht. Die Vereinheitlichung von Transformationen, Funktionslogik und Service verhindert schiefe Trainingsergebnisse und sorgt für zuverlässige Prognosen in großem Umfang.“

Die Inferenz beim maschinellen Lernen ist der Prozess, bei dem ein trainiertes Modell verwendet wird, um eine Ausgabe aus neuen, ungesehenen Eingabedaten zu generieren. Die Ausgabe kann je nach Modell und Aufgabe eine Prognose, Wahrscheinlichkeitsbewertung, Klassifizierung, Einbettung, generierte Antwort oder extrahiertes Feld sein.

Eine Inferenz-Pipeline befindet sich in der Regel zwischen den Quelldaten und dem ML-System, das das Ergebnis nutzt. Es ruft die erforderlichen Features ab, wandelt die Eingabe in das vom Modell erwartete Format um, führt Modellbewertungen durch, wandelt die Rohausgabe in eine brauchbare Form um und liefert diese Ausgabe an eine Tabelle, Anwendung, einen Inferenzendpunkt oder einen nachgelagerten Prozess.

Die Sequenz klingt einfach, aber die Inferenz-Pipeline muss die Erwartungen des Modells aus dem Training bewahren. Wenn beispielsweise ein Feature zum Inferenzzeitpunkt anders berechnet wird, kann dieselbe Spalte ein anderes Geschäftskonzept repräsentieren als im Training. Wenn die Vorverarbeitung nicht einheitlich angewendet wird, erhält das Modell möglicherweise Werte in einem anderen Format, in einem anderen Maßstab oder in einer anderen Verteilung als die, aus denen es gelernt hat. In der Produktion muss die Inferenz den umgebenden Datenpfad konstant genug halten, damit die Ausgabe zuverlässig bleibt.

Beim Training lernt ein Modell: Es passt interne Parameter (Gewichtungen) an, sodass das Modell Muster aus Trainingsdaten erfasst, bei denen es sich in der Regel um gelabelte historische Daten für überwachtes Lernen handelt. Sie ist in der Regel rechenintensiv und wird oft periodisch ausgeführt: wenn neue Daten verfügbar werden, wenn sich die Performance verschlechtert oder wenn sich das Prognoseziel ändert.

Inferenz folgt, wenn das Modell auf neue Eingaben angewendet wird. Produktionsinferenz wiederholt sich über Anfragen, Zeilen, Ereignisse, Dateien oder Prompts hinweg.

Die Unterschiede bei den Infrastrukturanforderungen sind erheblich. Das Training ist in der Regel rechenintensiv, aber begrenzt – ein Job beginnt, läuft möglicherweise über Stunden und endet dann. Die Inferenz ist kontinuierlich und latenzempfindlich. Bei einem Betrugsmodell kann beispielsweise das Zeitfenster zwischen Transaktionsanbahnung und Autorisierung in Millisekunden gemessen werden.

Kosten folgen einer ähnlichen Asymmetrie. Ein großes Modell zu trainieren, kann erhebliche Rechenressourcen erfordern, aber es ist ein einmaliger oder periodischer Aufwand. Inferenz läuft über die gesamte Lebensdauer des Modells, oft in hohem Volumen.

Ein Modell, das bei der Offline-Bewertung gut abschneidet, kann in der Produktion immer noch schlecht abschneiden, wenn die Inferenz-Pipeline veraltete Inputs liefert, Latenzbudgets überschreitet oder Ausgaben in einem Format erzeugt, das nachgelagerte Systeme nicht parsen können. Modellqualität und Inferenzqualität sind verwandte, aber separate Probleme.

Die wichtigsten Arten der maschinellen Lerninferenz spiegeln unterschiedliche Timing- und Bereitstellungsanforderungen wider. Bei der Entscheidung, welcher Typ verwendet werden soll, sollten Teams nicht nur berücksichtigen, wie das Modell eine Prognose generiert, sondern auch, wann die Ausgabe benötigt wird und wo das Modell ausgeführt werden kann.

Batch-Inferenz

Batch-Inferenz bewertet viele Datensätze auf einmal, normalerweise nach einem Zeitplan oder als Teil einer definierten Daten-Pipeline. Sie ist besonders nützlich, wenn Prognosen erstellt werden können, bevor sie benötigt werden, z. B. indem Kundenergebnisse über Nacht aktualisiert, Produktdaten vor einer Katalogaktualisierung angereichert oder Prognosen erstellt werden, bevor die Planungsworkflows beginnen.

Die wichtigsten Anforderungen sind Durchsatz, Auftragszuverlässigkeit und Output-Handling. Das System muss das erwartete Datenvolumen verarbeiten, innerhalb des verfügbaren Zeitfensters vervollständigen und Ergebnisse dort schreiben, wo nachgelagerte Analysen, Anwendungen oder operative Teams sie nutzen können.

Batch-Inferenz eignet sich oft gut für Workflows, bei denen die Prognoseausgabe selbst ein Daten-Asset ist. Ein Abwanderungsscore, eine Empfehlungstabelle, eine Bedarfsprognose oder ein Ergebnis einer Dokumentenklassifizierung müssen möglicherweise gespeichert, mit anderen Daten verknüpft und für Berichts-, Planungs- oder Anwendungsworkflows wiederverwendet werden.

Echtzeit- oder Online-Inferenz

Echtzeit-Inferenz, auch Online-Inferenz genannt, generiert eine Prognose als Reaktion auf eine Anfrage. Eine Applikation sendet Eingaben an einen Inferenzendpunkt, das Modell bewertet diese Eingabe und die Applikation erhält eine Antwort.

Online-Inferenz wird in der Regel verwendet, wenn die Prognose eine sofortige Interaktion oder Entscheidung beeinflusst. Die Betrugserkennung bei der Zahlungsautorisierung, das Content-Ranking während einer aktiven Sitzung und die Next-Best-Action-Prompts in einem Live-Gespräch – all das hängt von Prognosen ab, die vor dem Zeitpunkt eintreffen werden.

Echtzeit-Inferenz hängt von der Infrastruktur des Modells ab, die ein Modell laden, Anfragen annehmen, Bewertungen durchführen und Reaktionen innerhalb des Latenzbudgets der Anwendung zurückgeben kann. Sie muss die Latenz pro Anforderung, Parallelität, das Kaltstartverhalten und die Service-Level-Ziele verwalten, da das nutzende System auf das Ergebnis wartet.

Diese Art der Inferenz erhöht auch den Druck auf die Verfügbarkeit von Features. Wenn das Modell vom aktuellen Benutzerverhalten, Bestandsstatus oder Transaktionskontext abhängt, benötigt die Inferenz-Pipeline einen zuverlässigen Pfad, um diese Eingaben schnell und einheitlich abzurufen.

Streaming-Inferenz

Streaming-Inferenz bewertet Daten kontinuierlich, sobald Ereignisse eintreffen, ohne auf einen geplanten Batch oder eine synchrone Anforderung zu warten. Das Modell verarbeitet einen Strom von Eingaben wie Sensormesswerten, Protokollereignissen oder Clickstream-Daten und erzeugt Ausgaben, die nahezu in Echtzeit in nachgelagerte Systeme fließen.

Streaming-Inferenz liegt oft in der Nähe von Betriebsüberwachung, Risikobewertung und Warning-Workflows. Die Modellausgabe kann ein Ereignis weiterleiten, einen Wert aktualisieren, eine Überprüfung auslösen oder einem nachgelagerten System, das den Stream bereits verarbeitet, Kontext hinzufügen. Die Pipeline für die Streaming-Inferenz muss die Ereignisverarbeitung, die Funktionsaktualisierung und die Ausgabebereitstellung koordinieren.

Edge-Inferenz

Edge-Inferenz führt das Modell auf einem Gerät oder einem lokalen System aus und nicht in einer zentralen Umgebung. Diese Art von Inferenz ist häufig, wenn Latenz, Konnektivität, Datenschutz oder Datenübertragungsbeschränkungen eine zentrale Inferenz unpraktisch machen. Edge-Inferenz ist in Umgebungen üblich, in denen die Vorhersage in der Nähe der Datenquelle erfolgen muss, wie z. B. bei mobilen Anwendungen, Sensoren, Fahrzeugen, Kameras oder Industriesystemen.

Die Einschränkung ist, dass Edge-Umgebungen über begrenzte Rechenressourcen, Speicher und Leistung verfügen. Modelle müssen in der Regel komprimiert werden – durch Quantifizierung, Pruning oder Wissensdestillation –, bevor sie zuverlässig innerhalb der Grenzen des Geräts ausgeführt werden können.

Sobald ein Modell in Produktion geht, benötigen Teams Kennzahlen, die sowohl das Modellverhalten als auch das Laufzeitverhalten beschreiben. Genauigkeit, Präzision, Erinnerung und andere Qualitätsmaße für Modelle haben ihren Platz, aber sie können nicht zeigen, ob die Inferenz-Pipeline ihr Latenzziel erreicht, das benötigte Volumen verarbeitet oder Ergebnisse zu nachhaltigen Kosten liefert.

Die zu messenden Kennzahlen hängen vom Inferenzmuster ab. Batch-Aufträge erfordern in der Regel Durchsatz, Fertigstellungszeit und Kosten pro Prognose. Online-Inferenz betont Latenz, Fehlerquote und Kaltstartverhalten. LLM-Inferenz fügt Maßnahmen auf Token-Ebene hinzu, da Ausgabelänge, Generierungsgeschwindigkeit und Kontextgröße sich direkt auf Latenz und Kosten auswirken.

Die Inferenzoptimierung hat zwei Ausgangspunkte: das Modell und die Pipeline.

Modellseitig sind Größe und Präzision die wichtigsten Variablen. Die Quantifizierung reduziert die numerische Genauigkeit von Gewichtungen und Aktivierungen – der Wechsel von FP32 zu INT8 reduziert den Speicherbedarf und verbessert oft den Durchsatz auf kompatibler Hardware. Dabei besteht ein gewisses Genauigkeitsrisiko, das Teams anhand produktionsähnlicher Daten validieren. Durch das Pruning werden Parameter entfernt, die wenig zur Ausgabequalität beitragen, wodurch der Rechen- und Speicherbedarf für ein Modell reduziert wird, das die Genauigkeitsleiste noch erfüllt. Die Wissensdestillation trainiert ein kleineres Modell, um das Verhalten eines größeren zu approximieren – nützlich, wenn das vollständige Modell zwar genau ist, aber für die Zielumgebung zu teuer oder langsam.

Pipelineseitig ist Batching der am besten zugängliche Hebel. Die Gruppierung von Anfragen verbessert die Hardwareauslastung und den Durchsatz, führt jedoch zu einer Latenzzeit, die Batch-Workloads leichter absorbieren können als Echtzeit-Endpunkte. Dynamisches Batching passt die Gruppengröße an den eingehenden Datenverkehr an, wodurch diese konkurrierenden Anforderungen ausgeglichen werden.

Hardwareauswahl beeinflusst Kosten und Performance. CPUs arbeiten für Workloads mit geringerem Volumen oder weniger rechenintensiv, während GPUs erhebliche Durchsatzvorteile für Deep-Learning-Inferenzen bieten, wenn Batch- und Modellgrößen sie gut auslasten können.

Modellformat und Laufzeit beeinflussen die Portabilität und die Ausführungsgeschwindigkeit. ONNX gibt Teams die Möglichkeit, Modelle über Frameworks und Laufzeiten hinweg darzustellen. TensorRT kann die Deep-Learning-Inferenz auf GPUs durch Techniken wie Ebenenfusion, Präzisionskalibrierung, Kernselektion und Graphoptimierung optimieren.

LLM-Inferenz hat zusätzliche Optimierungsüberlegungen. Promptlänge, Kontextfensternutzung und maximale Ausgabentokenlimits wirken sich alle auf die Rechenkosten pro Anforderung aus. Ein KV-Cache speichert die Aufmerksamkeitsschlüssel-Wert-Berechnungen aus dem vorherigen Kontext, damit das Modell sie nicht für jedes Token neu berechnet. Bei der spekulativen Entschlüsselung werden Token mit einem kleineren Modellentwurf vorgeschlagen, die ein größeres Modell überprüft. So wird der Durchsatz verbessert, wenn der Verifizierungsprozess genügend Tokenentwürfe akzeptiert. Ungefähre Varianten können Qualität gegen Geschwindigkeit tauschen.

Es ist wichtig zu beachten, dass die Optimierung erfordert, dass Sie wissen, für was Sie optimieren. Latenzverringerung und Verbesserung des Durchsatzes erfordern oft unterschiedliche Ansätze, die beide mit Kostenzielen in Konflikt stehen können. Teams, die vor der Optimierung messen, vermeiden, ein Problem gegen ein anderes einzutauschen.

ML-Inferenz verwendet Daten, Modelle und Ausgaben, die allesamt Governance-Anforderungen erfüllen können. Beispielsweise können die Eingabedaten sensible Felder enthalten, oder das Modell kann für einige Anwendungsfälle zugelassen werden, nicht aber für andere. Das bedeutet, dass Teams wissen müssen, welche Daten verwendet wurden, welche Modellversion die Ausgabe generiert hat, wer auf das Ergebnis zugreifen kann und ob die Prognose für den sie nutzenden Workflow geeignet ist. Datenherkunft, Zugriffskontrollen, Modellmetadaten und Modellüberwachung helfen dabei, diesen Kontext herzustellen.

Governance ist besonders dann wichtig, wenn Inferenzergebnisse zu wiederverwendbaren Daten-Assets werden. Ohne klare Eigentums-, Versions- und Zugriffsrichtlinien lassen sich diese Ausgaben nur schwer prüfen, erklären oder sicher wiederverwenden.

Produktionsinferenz-Workflows sind Daten-Workflows. Das Modell benötigt Inputs, die von Unternehmensdatensystemen stammen, und die Outputs müssen in der Regel zurück in dieselben Systeme gehen – mit Kundendatensätzen verknüpft, in eine Tabelle geschrieben, die ein BI-Tool liest, und in eine nachgelagerte Pipeline übergeben.

Snowflake unterstützt die Modellinferenz über zwei Rechen-Engines: die Warehouse-SQL-Engine und Snowpark Container Services. Die Snowflake Model Registry bietet eine einheitliche Oberfläche für beides.

Bei Batch-Workloads mit hohem Durchsatz nutzen Snowflake Batch Inference Jobs Snowpark Container Services, um verteilte Rechenressourcen für eine umfangreiche Bewertung statischer oder periodisch aktualisierter Datasets bereitzustellen. Dazu gehören auch unstrukturierte Daten, die in Snowflake-Stages gespeichert sind. Snowflake unterstützt die Bereitstellung von Modellen als verwaltete HTTP-Endpunkte über Snowpark Container Services und sorgt so dafür, dass die Modellbereitstellung mit derselben Umgebung verbunden ist, in der sich die zugrunde liegenden Daten befinden.

Cortex AI Functions erweitert die Inferenz auf LLM-gestützte Analysen kontrollierter Daten – Vervollständigung, Einbettung, Extraktion, Stimmungsanalyse, Zusammenfassung, Übersetzung und multimodale Dokumentenverarbeitung mit Funktionen wie AI_PARSE_DOCUMENT. Diese werden mit Daten ausgeführt, die sich bereits in Snowflake befinden, ohne sie auf ein externes System zu verschieben.

Der Wert ist architektonische Einheitlichkeit. Verschiedene Inferenz-Workloads erfordern zwar weiterhin unterschiedliche Ausführungsmuster, können aber mit den Daten-, Modellverwaltungs- und Ausgabe-Workflows verbunden bleiben, die Produktionsteams bereits verwenden. Snowflake gibt Teams die Möglichkeit, das Muster auszuwählen, das zum Workload passt, während die Inferenz nah an den Unternehmensdaten bleibt, von denen sie abhängig sind.

Die Inferenzarchitektur sollte dem Datenpfad folgen. Das Modell benötigt Eingaben, die mit der während des Trainings verwendeten Logik übereinstimmen, die Pipeline benötigt genügend Rechenressourcen, um die Timing-Anforderungen des Workflows zu erfüllen, und die Ausgabe muss dort landen, wo Analytics, Anwendungen oder nachgelagerte Systeme sie verwenden können. Die Trennung dieser Teile führt zu Datenbewegungen, -duplizierungen und unnötigen Möglichkeiten für die Feature-Logik oder die Ausgabeverarbeitung.

Wenn Teams die Inferenz näher an ihren Unternehmensdaten durchführen, können sie die Modellergebnisse als Produktionsdaten und nicht als isolierte Modellantworten behandeln. Das Ergebnis ist ein zuverlässigerer Weg von den Quelldaten über die Modellbewertung bis hin zu Geschäftsmaßnahmen – mit weniger Übergaben zwischen den Systemen, die die Daten aufbereiten, das Modell ausführen und die Ausgaben nutzen.