Inferenz bei LLMs: Was Antworten schnell oder langsam macht

Die Inferenz bei LLMs besteht aus 2 Hauptphasen: Das Modell verarbeitet den Prompt und erzeugt anschließend die Antwort. Wenn eine Funktion erst spät mit der Ausgabe beginnt, braucht sie eine andere Optimierung als eine, die sofort startet, aber lange bis zum Ende benötigt. Diese Wartezeiten sollten getrennt gemessen werden, bevor ein Modellwechsel, schnelleres Hosting oder gemietete GPUs ins Spiel kommen.

Für den Einstieg empfiehlt sich eine gehostete API, solange kein konkreter Grund für einen eigenen Inferenzbetrieb vorliegt. Ein solcher Grund kann die Kontrolle über die Bereitstellung sein, ein zwingend benötigtes offenes Modell oder eine dauerhafte Auslastung, die eigene Kapazitäten rechtfertigt. Eine langsame Antwort allein reicht nicht: Zunächst muss klar sein, welcher Teil der Anfrage Zeit kostet.

Die folgenden Angaben zur Dokumentation und zum Umfang der Veröffentlichungen wurden am 21. Oktober 2026 anhand der aktuellen Herstellerseiten geprüft. Das Rechenbeispiel verwendet eine veröffentlichte API-Antwort und legt die Berechnung offen. Es handelt sich weder um einen selbst durchgeführten Benchmark noch um eine Aussage darüber, welche Geschwindigkeit eine konkrete Anwendung erreichen wird.

Was ist Inferenz bei LLMs? Erst den Prompt verarbeiten, dann die Antwort erzeugen

LLM-Inferenz bezeichnet die Arbeit, mit der ein trainiertes großes Sprachmodell aus einer Eingabe eine Ausgabe erzeugt. Bei einer typischen Textanfrage wird dazu der Prompt aufbereitet, eine Fortsetzung vorhergesagt und der erzeugte Text zurückgegeben. Das Modell verarbeitet Tokens: Texteinheiten, die aus Wörtern, Wortteilen oder Satzzeichen bestehen können. NVIDIAs Erklärung zur Inferenz.

Ein passender Vergleich ist das Vorbereiten von Notizen vor dem Schreiben einer Antwort. Das bereitgestellte Material zu lesen und zu ordnen entspricht der Vorbereitungsphase. Das Schreiben der Antwort entspricht der Fortsetzungsphase. Vorbereitete Notizen ersparen erneute Vorarbeit, doch die Antwort muss trotzdem geschrieben werden. Technisch speichert das System dabei numerische Zustände, keine lesbaren Notizen.

Prefill verarbeitet die bereits bekannte Eingabe. Anweisungen, abgerufene Dokumente, der Gesprächsverlauf und Tool-Ergebnisse werden zu Prompt-Tokens. Da diese Positionen bereits feststehen, kann das System sie unter Beachtung der Aufmerksamkeitsregeln des Modells gemeinsam verarbeiten. Dabei entsteht der Zustand, aus dem das erste Ausgabetoken erzeugt wird.

Decode erzeugt die Fortsetzung. Bei der üblichen autoregressiven Generierung hängt jedes neue Token von der bisher gewählten Fortsetzung ab. Die Laufzeitumgebung führt das Modell wiederholt aus, wählt das nächste Token, aktualisiert den Zustand und setzt diesen Ablauf fort, bis eine Abbruchbedingung erreicht ist. NVIDIA beschreibt beide Phasen.

Bei einem Supportassistenten kann ein umfangreiches Richtliniendokument die Vorbereitung aufwendig machen, selbst wenn nur eine kurze Antwort gefragt ist. Bei einem Berichtsgenerator kann auf einen überschaubaren Prompt eine lange Wartezeit folgen, während das Modell schreibt. Trotz desselben Endpunkts sind das unterschiedliche Lastprofile.

Worin unterscheiden sich Inferenz und Training?

Training verändert die erlernten Parameter des Modells; Inferenz nutzt sie. Parameter, häufig auch Gewichte genannt, sind die beim Training erlernten Zahlenwerte. Ein Dokument im Prompt liefert dem Modell Kontext für diese Anfrage. Allein dadurch werden die Gewichte nicht neu trainiert. IBMs Erklärung zu Inferenz und Training.

Für die Fehlersuche in einem Produkt ist diese Unterscheidung entscheidend. Ignoriert eine Antwort eine Richtlinie, müssen der mitgelieferte Kontext verbessert und das Modellverhalten geprüft werden. Dauert eine korrekte Antwort zu lange, sind die Inferenzzeiten zu untersuchen. Training, Qualität der Informationssuche und Leistung des Inferenzbetriebs sind getrennte Ansatzpunkte.

Warum kosten Ausgabetokens meist mehr?

Bei der Erzeugung einer Fortsetzung lässt sich pro Anfrage meist weniger Arbeit parallel ausführen als bei der Verarbeitung eines bereits bekannten Prompts. Bei kleinen Batches kann ein großer Teil der Decode-Zeit darauf entfallen, Modellgewichte und Aufmerksamkeitszustände durch den Speicher zu bewegen. Werden mehrere bekannte Eingabepositionen gemeinsam verarbeitet, lässt sich die Hardware anders auslasten. Das erklärt zum Teil, warum viele APIs für die Ausgabe höhere Preise verlangen. NVIDIA zu Prefill und Decode.

Das genaue Preisverhältnis legt allerdings der Anbieter fest; es ist keine physikalische Konstante. Auch die Behandlung von Cache-Nutzung, die Modellwahl und die Vertragsbedingungen spielen eine Rolle. Eingabe und Ausgabe zu kürzen hat deshalb nicht zwangsläufig denselben Effekt auf Latenz oder Rechnung.

Die praktische Konsequenz: Braucht eine Funktion eine Kategorie und eine kurze Begründung, sollte sie genau das anfordern. Ein langer Aufsatz verursacht zusätzliche Generierungsarbeit, die auch ein schnellerer Hoster erst leisten muss.

Zeit bis zum ersten Token und Tokens pro Sekunde getrennt messen

Die Zeit bis zum ersten Token zeigt, wie lange die Antwort auf sich warten lässt. Die Generierungsgeschwindigkeit zeigt, wie schnell sie danach weiterläuft. Beide Werte brauchen klar definierte, einheitliche Messgrenzen.

• Time to First Token, kurz TTFT: die Zeit vom Absenden der Modellanfrage bis zum Empfang des ersten nicht leeren Ausgabetokens. Warteschlange, Prompt-Verarbeitung und Netzwerkübertragung können dazu beitragen.
• Latenz zwischen Tokens: der Abstand zwischen den Ausgabetokens nach Beginn der Generierung. Ein Stream kann sofort starten und sich trotzdem langsam anfühlen, wenn diese Abstände groß sind.
• Gesamtlatenz der Anfrage: die Zeit vom Absenden der Anfrage bis zum Empfang ihres letzten Ausgabetokens.
• Systemdurchsatz: die gesamte nutzbare Ausgabe über gleichzeitig laufende Anfragen hinweg. Dieser Wert kann steigen, während einzelne Nutzer länger warten.

Diese Unterscheidungen folgen NVIDIAs Metrikdefinitionen. Sie erklären auch, warum eine plakative Angabe zu Tokens pro Sekunde nicht jede Leistungsfrage beantwortet.

Beim Vergleich von Tokens pro Sekunde kommt es auf den Nenner an. Ein Anbieter teilt möglicherweise die Ausgabetokens durch die reine Generierungszeit, während eine clientseitige Messung auch die anfängliche Wartezeit einschließt. Ein zusammengefasster Serverwert kann die Ausgabe vieler Nutzer enthalten. Solche Zahlen beschreiben unterschiedliche Sachverhalte.

Bei einer gestreamten Antwort mit mehreren Tokens lässt sich der durchschnittliche Abstand zwischen Tokens so berechnen: (final-token time − first-token time) / (output-token count − 1). Die anfängliche Wartezeit bleibt dabei außen vor; die Subtraktion berücksichtigt, dass die Abstände zwischen den Tokens gezählt werden. Die NVIDIA-Definition legt diese Messgrenze ausdrücklich fest.

Zusätzlich sollte die Anwendung die Zeit von der Nutzeraktion bis zum nutzbaren Ergebnis messen. Dazu gehören die Dokumentensuche vor dem Modellaufruf, externe Tool-Aufrufe und die anschließende Validierung. Ein Wechsel des Inferenzanbieters beseitigt keine Wartezeit auf die eigene Datenbank.

Eine Anfrage und ihre einzelnen Wartezeiten

Das veröffentlichte Antwortbeispiel von Groq zeigt, warum ein Feld namens total_time genauer betrachtet werden muss. Groq ist ein Anbieter gehosteter Inferenz und liefert Zeitangaben in den Nutzungsdaten seiner API. Die Referenz zur Chat Completions API enthält ein Beispiel mit 18 Prompt-Tokens und 556 Completion-Tokens.

Die veröffentlichten Werte des Beispiels, von Sekunden in Millisekunden umgerechnet und gerundet; die englische Zahlenschreibweise der Quelle bleibt erhalten:

Quelle: Groqs beispielhaftes Nutzungsobjekt. Diese Zeiten stammen aus einem Dokumentationsbeispiel und sind keine zu erwartenden Latenzen im Produktivbetrieb.

In diesem Beispiel umfasst die gemeldete Gesamtzeit die Prompt-Verarbeitung und die Generierung:

Prompt + Completion = 0.000680594 + 0.463333333 = 0.464013927 Sekunden. Das entspricht exakt dem gemeldeten Wert von total_time. Die Warteschlange liegt in diesem Beispiel außerhalb dieser Summe.

Warteschlange + Prompt + Completion = 0.501507683 Sekunden, also ungefähr 501.508 ms. Das ist unsere Zwischensumme der benannten serverseitigen Bestandteile. Die gesamte Wartezeit der Anwendung ergibt sich daraus weiterhin nicht, denn das Beispiel enthält weder clientseitige Netzwerkzeiten noch Angaben zu den übrigen Abläufen der Anwendung.

Teilt man die 556 Ausgabetokens des Beispiels durch die Completion-Zeit von 0.463333333 Sekunden, ergeben sich ungefähr 1,200 Ausgabetokens pro Sekunde. Das ist eine Rechnung anhand einer Beispielantwort, kein Benchmark und keine Zusage. Groq dokumentiert diese Berechnung aus Token-Anzahl und Completion-Zeit in seinen Hinweisen zu Inferenzmetriken.

Für die eigene Funktion ist genau diese Aufteilung hilfreich. Eine lange Warteschlange verweist auf die Annahme von Anfragen und die Kapazität. Eine lange Prompt-Verarbeitung verweist auf den Aufwand für die Eingabe. Eine lange Completion verweist auf die Generierung. Wartet der Client deutlich länger, als die gemeldeten Serveranteile erklären, müssen Netzwerk und Anwendungsablauf untersucht werden.

Inferenz optimieren: Die Maßnahme muss zur Wartezeit passen

Eine Optimierung hilft nur, wenn sie einen wesentlichen Teil der tatsächlichen Last verändert. Dieselbe Funktion kann für einen Dokumentenassistenten wertvoll und bei kurzen, voneinander unabhängigen Prompts nahezu bedeutungslos sein.

Die Verfahren sind bei NVIDIA und in den nachfolgend verlinkten Laufzeitdokumentationen beschrieben. Die letzte Spalte benennt die Grenzen, die bei einer Entscheidung über die Bereitstellung berücksichtigt werden müssen.

KV-Cache: Bereits geleistete Arbeit weiterverwenden

Ein Key-Value-Cache, kurz KV-Cache, hält Aufmerksamkeitszustände früherer Tokens vor. Über den Aufmerksamkeitsmechanismus bezieht ein Transformer früheren Kontext in seine aktuelle Vorhersage ein. Werden die früheren Schlüssel und Werte gespeichert, müssen sie nicht bei jedem weiteren Generierungsschritt neu berechnet werden. Wie der Cache wächst oder verwaltet wird, hängt von der Aufmerksamkeitsarchitektur des Modells und den Vorgaben des Inferenzbetriebs ab. NVIDIAs Erklärung zum KV-Cache.

Diese Wiederverwendung benötigt Speicher. Passen die Modellgewichte auf eine GPU, heißt das noch nicht, dass dort auch lange Gespräche vieler gleichzeitiger Nutzer Platz finden. Neben den Gewichten müssen aktive Anfragezustände und Arbeitsspeicherbedarf eingeplant werden.

Prefix Caching ermöglicht die Wiederverwendung über Anfragen mit demselben Anfang hinweg. Erhält ein Assistent wiederholt dieselben Anweisungen und dasselbe Referenzdokument, kann er dieses bereits verarbeitete Präfix erneut nutzen. Den veränderten hinteren Teil muss er weiterhin verarbeiten und eine neue Antwort erzeugen.

vLLM, eine quelloffene Engine für Inferenz und Modellbereitstellung, hält ausdrücklich fest, dass sein automatisches Prefix Caching Prefill-Arbeit einspart, nicht Decode-Arbeit. Die Grenzen des vLLM-Caches.

Nützlicher gemeinsamer Kontext sollte am Anfang der Anfragen stehen; anschließend lässt sich die gemeldete Cache-Nutzung prüfen. Haben die Prompts wenig gemeinsam oder entfällt die meiste Wartezeit auf lange Antworten, löst die Wiederverwendung von Präfixen nur einen kleinen Teil des Problems. Der Leitfaden zum KV-Cache erklärt Zustände, Aufbewahrung und anbieterspezifische Wiederverwendung ausführlicher.

Batching: Kapazität auf mehrere Anfragen verteilen

Continuous Batching verbessert die Auslastung eines Servers. Abgeschlossene Sequenzen können ausscheiden und neue Anfragen hinzukommen, während andere Sequenzen weiter Text erzeugen. Dadurch muss nicht eine ganze Gruppe bis zur Fertigstellung ihrer längsten Antwort offenbleiben. NVIDIAs Erklärung zu Continuous Batching.

Wer viele Kunden bedient, kann seine Kapazität so produktiver nutzen. Für eine Person, die auf eine einzelne Antwort wartet, ist höherer Gesamtdurchsatz jedoch nicht automatisch ein Fortschritt. Entscheidend ist, die Verteilung der Antwortzeiten unter der gleichzeitigen Last zu testen, die die Funktion bewältigen muss.

Continuous Batching innerhalb einer Inferenz-Engine ist nicht dasselbe wie eine asynchrone Batch-API. Bei Letzterer werden Aufgaben zur späteren Bearbeitung eingereicht, etwa für Klassifizierungen über Nacht. Das ist eine andere Produktentscheidung als die effiziente Einplanung laufender Chatanfragen.

Chunked Prefill verringert die gegenseitige Beeinträchtigung neuer Prompts und bereits laufender Antworten. Dazu wird ein großer Prefill in kleinere Abschnitte aufgeteilt, die neben Decode-Arbeit eingeplant werden können. vLLM dokumentiert, dass sich mit dem Token-Budget der Ablaufplanung auch das Verhältnis zwischen der Latenz bis zum ersten Token und der Latenz zwischen Tokens verändert. vLLMs Leitfaden zur Optimierung.

Das ist relevant, wenn ein Dokument hochgeladen wird, während andere Kunden bereits chatten. Ziel ist, die laufenden Streams reaktionsfähig zu halten und zugleich neue Arbeit anzunehmen. Die Optimierung einer einzelnen Anfrage auf einem ansonsten leeren Server greift dafür zu kurz.

Quantisierung: Weniger Speicher pro Wert

Quantisierung reduziert die Genauigkeit, mit der Zahlenwerte dargestellt werden. Kleinere Darstellungen können den Speicherbedarf senken und eine durch Speicherbandbreite begrenzte Ausführung unterstützen. Die Quantisierung von Gewichten und die des KV-Caches betreffen unterschiedliche Speicherbereiche. vLLMs Dokumentation zur Quantisierung.

Entscheidend ist, ob die gewählte Darstellung auf einer kompatiblen Laufzeitumgebung und Hardware das Verhalten erhält, das die Anwendung benötigt. Geprüft werden sollten die für die Funktion wichtigen Aufgaben: Dokumentenextraktion, Tool-Argumente und die Verarbeitung langer Kontexte. Eine kleinere Datei und ein erfolgreich geladenes Modell belegen noch kein brauchbares Ergebnis.

Aus dem Formatnamen allein lässt sich keine Beschleunigung ableiten. Ausschlaggebend sind unterstützte Rechenkerne, Hardware und Lastprofil. Der Leitfaden zur LLM-Quantisierung hilft bei der Wahl zwischen Formaten und bei der Frage, welcher Speicherbedarf jeweils sinkt.

Speculative Decoding: Erst entwerfen, dann prüfen

Speculative Decoding versucht, pro Prüfdurchlauf mehr von der Fortsetzung zu übernehmen. Ein weniger aufwendiger Entwurfsmechanismus schlägt Tokens vor, die das Zielmodell anschließend prüft. Akzeptierte Entwürfe können sequenzielle Generierungsarbeit einsparen; verworfene Entwürfe und die Prüfung verursachen weiterhin Aufwand. vLLMs Dokumentation zu Speculative Decoding.

Der Entwurf kann von einem anderen Modell oder einem unterstützten Vorhersageverfahren stammen. Der Nutzen hängt von der Akzeptanz der Vorschläge, dem Zielmodell, den Sampling-Einstellungen, der Hardware und dem Anfrageaufkommen ab. Ist die Generierung der Engpass, lohnt sich eine Prüfung. Eine langsame Dokumentensuche wird dadurch nicht schneller, und eine kürzere anfängliche Warteschlange ist ebenfalls nicht garantiert.

Standardverfahren mit Rejection Sampling sollen die Zielverteilung innerhalb numerischer Grenzen erhalten. Diese Zusage gilt nicht pauschal für jede Funktion mit dem Etikett „speculative“: vLLM unterscheidet in derselben Dokumentation zwischen seinen Standardgarantien und bewusst verlustbehafteten Prüfverfahren.

LLM-Hosting und Systemarchitektur: Wer betreibt die Inferenz?

Vor der Hardwarewahl muss geklärt werden, wer welche Verantwortung trägt. Eine API des Modellherstellers, ein Inferenzanbieter und eine eigene Laufzeitumgebung können jeweils aus Prompts Antworten erzeugen. Der Aufwand, der beim eigenen Team verbleibt, unterscheidet sich jedoch.

Modell-API: Zugang zu den Modellen des Herstellers

Die Claude API von Anthropic bietet gehosteten, programmatischen Zugang zu Claude-Modellen. Ihre Messages API nimmt Anfragen entgegen und erzeugt Antworten. Streaming und Schnittstellen für die Tool-Nutzung sind vom Hersteller dokumentiert. Überblick zur Claude API.

Dieser Weg passt zu Entwicklungsteams, die vor allem das benötigte Modellverhalten in ein Produkt integrieren wollen. Prompts, Kontext, Ausgabeanforderungen und Kontrollmechanismen der Anwendung liegen beim Team; die Inferenzinfrastruktur betreibt der Hersteller.

Die Grenze liegt bei der Kontrolle. Der gekaufte Modellzugang verschafft weder Zugriff auf den Scheduler des Anbieters noch eine Bereitstellung dieses Modells in der eigenen Infrastruktur. Die API ist passend, wenn Modell und Vertragsbedingungen die Aufgabe erfüllen. Eine langsame API-Antwort sollte erst dann Anlass für ein GPU-Projekt sein, wenn gemessen wurde, wo die Wartezeit entsteht.

Inferenzanbieter: Den Hoster unabhängig wählen

Groq bietet eine gehostete Chat-Completions-API mit einem dokumentierten Modellkatalog. Die Modellseiten nennen Fähigkeiten und Grenzen je Modell. Daher muss der konkret vorgesehene Endpunkt geprüft werden. Groqs Modellkatalog.

So lässt sich ein Hoster für ein verfügbares Modell bewerten, ohne dessen Hardware selbst zu betreiben. Maßgeblich ist die tatsächlich bereitgestellte Kombination aus Modellverfügbarkeit, Anfragelimits und Funktionsumfang. Dass eine Modellfamilie anderswo auftaucht, belegt weder die Verfügbarkeit des benötigten Checkpoints beim Anbieter noch die Unterstützung jedes Anfragefelds.

Cerebras bietet eine gehostete Inferenz-API und ein SDK, einschließlich gestreamter Generierung. Die Schnellstartanleitung zeigt die Einrichtung des API-Schlüssels und den Ablauf einer Anfrage. Schnellstart für Cerebras Inference.

Cerebras sollte als weiterer Kandidat anhand der tatsächlichen Prompt-Längen, Ausgabeanforderungen und Lastverläufe geprüft werden. Entscheidend bleibt, ob der Dienst passt: angebotenes Modell, benötigte Funktionen und Kapazitätsbedingungen müssen stimmen. Ein schneller Stream bei einem kurzen Beispiel reicht als Beleg für eine dokumentenintensive Produktivfunktion nicht aus. Der Preisleitfaden zu Cerebras und der Preisleitfaden zu Groq behandeln diese wirtschaftlichen Fragen.

Preisbeispiel für gehostete Inferenz: Groq führt Alibabas Qwen3.8-27B mit $0.80 pro Million Eingabetokens und $4.00 pro Million Ausgabetokens. Beim Vergleich von gehosteter Nutzung mit selbst finanzierten Kapazitäten und Betriebsaufwand ist die aktuelle Modellübersicht maßgeblich.

Dieses Beispiel gilt für das genannte Modell. Es ist weder eine Preisangabe zum früheren Zeitmessungsbeispiel noch ein Leistungsvergleich zwischen Groq und einem anderen Modell oder einer anderen Bereitstellung.

Eigene Inferenz-Engine: Laufzeitumgebung und Kapazität selbst verantworten

vLLM bietet eine Laufzeitumgebung für die Modellbereitstellung mit Continuous Batching, Streaming, Prefix Caching und einem API-Server. Das sind nützliche Bausteine, wenn der Betrieb für gleichzeitige Anfragen zur eigenen Aufgabe gehört. Welche Modelle, Hardware und Optimierungswege unterstützt werden, muss für die konkrete Bereitstellung dennoch geprüft werden. Dokumentierte Funktionen von vLLM.

Die Grenze liegt beim Dienst rund um die Engine: Kapazitäten bereitstellen, Änderungen ausrollen, Anfragen zulassen, Fehler überwachen und genügend Reserven für Lastspitzen vorhalten. Eine Laufzeitumgebung kann Arbeit auf vorhandenen Geräten einplanen. Welche Zuverlässigkeit die Anwendung braucht, kann sie nicht entscheiden.

Ollama ist eine Laufzeitumgebung für Modelle auf dem eigenen Rechner oder Server und unterstützt die Ausführung auf CPU und GPU. Die FAQ dokumentiert gleichzeitige Verarbeitung, Warteschlangen und den zusätzlichen Speicherbedarf paralleler Anfragen. Ollamas Hinweise zur Parallelverarbeitung.

Ollama ist ein sinnvoller Einstieg für die lokale Entwicklung oder eine kontrollierte interne Nutzung. Die Grenzen setzen Speicher und Betriebskapazität hinter der komfortablen Oberfläche. Der Vergleich von Ollama und vLLM hilft bei der Wahl zwischen Ollama und einer stärker auf den Inferenzbetrieb ausgerichteten Bereitstellung. Die Entscheidung muss anschließend mit gleichzeitigen Anfragen überprüft werden; ein einzelner erfolgreicher Chat genügt nicht.

DeepInfer von DeepSeek ist ein spezialisiertes Inferenzframework, dessen öffentliches Repository am 20. Oktober 2026 startete. Die README beschreibt die offene Veröffentlichung als Offline-Inferenz mit Komponenten für den Betrieb in großem Maßstab. Unterstützt werden DeepSeek-V4.1-Flash, NVIDIA SM100 GPUs und Huawei Ascend 950 NPUs. Repository-Verlauf, README des Herstellers.

Die Veröffentlichung ist kein vollständiger Inferenzdienst. DeepSeek nennt ein KV-Cache-System, die Trennung von Encoding, Prefill und Decode sowie Lastverteilung über Replikate ausdrücklich als benötigte, aber nicht enthaltene Komponenten. Damit ist fehlende Infrastruktur auf Dienstebene gemeint. Daraus lässt sich nicht ableiten, dass die Inferenz-Engine keinerlei Aufmerksamkeitszustände zwischenspeichert. Die von DeepInfer benannten Auslassungen.

Für ein Infrastrukturteam, das genau dieses Modell und diese Hardware einsetzen möchte, lohnt sich die Prüfung des Codes. Für ein Entwicklungsteam, das diese Woche eine gewöhnliche Anwendung verbessern will, ist er keine Abkürzung um den eigenen Dienstbetrieb herum. Die Modellentscheidung zu DeepSeek V4 sollte von der Entscheidung getrennt bleiben, dessen Inferenzinfrastruktur aufzubauen.

Eigenbetrieb ist sinnvoll, wenn er eine konkret benannte Anforderung erfüllt und die Verantwortung personell getragen werden kann. Dauerhafte Nachfrage kann eine Prüfung rechtfertigen; unregelmäßige Nachfrage kann bezahlte Kapazität ungenutzt lassen. Aktiver Kontext, gleichzeitige Anfragen, Ausfälle und Spitzenlasten gehören in die Entscheidung. Es gibt keine allgemein belastbare Auslastungsschwelle, ab der eigene GPUs die bessere Wahl sind.

Wo die Versprechen schnellerer Inferenz zu weit gehen

Eine höhere Generierungsrate ist nur dann nützlich, wenn sie das Ergebnis verbessert, auf das der Nutzer wartet. Streaming macht Fortschritt früher sichtbar, beseitigt aber nicht die verbleibende Generierungsarbeit. Muss ein Ablauf eine vollständige strukturierte Antwort validieren, bleibt das Warten bis zum Ende möglicherweise erforderlich.

Welche LLM-Inferenz am schnellsten ist, hängt von der Last ab

Ein aussagekräftiger Vergleich legt Modellverhalten, Prompt-Länge, Ausgabelänge, Cache-Bedingungen und Parallelität offen. Andernfalls kann das schnellere Ergebnis schlicht auf einer leichteren Anfrage oder einer anderen Zeitbasis im Nenner beruhen. Der Gesamtdurchsatz eines Anbieters ist keine Zusage für die Wartezeit eines einzelnen Kunden auf das erste Token.

Dieselbe Sorgfalt gilt für Optimierungsversprechen. Ein Cache-Treffer spart wiederholte Vorarbeit, soweit sie sich wiederverwenden lässt; er beschleunigt nicht jeden Teil einer Aufgabe. Kleinere numerische Darstellungen belegen keine unveränderte Ergebnisqualität. Ein offenes Inferenzframework liefert noch keinen vollständig betreibbaren Dienst.

Messungen und unnötige Arbeit lassen sich sofort angehen. Ein Infrastrukturwechsel sollte warten, bis diese Messungen einen Grund dafür liefern. Erfüllt ein kurzer API-Aufruf bereits die Anforderungen an Qualität und Latenz, schafft eine neu veröffentlichte Inferenz-Engine kein Problem, das gelöst werden müsste.

Häufige Fragen zur KI-Inferenz

Was bedeutet Inferenz beim maschinellen Lernen?

ML steht für Machine Learning, also maschinelles Lernen. Bei der Inferenz wird ein trainiertes Modell auf neue Eingaben angewendet, um eine Ausgabe zu erhalten. Die Texterzeugung mit LLMs ist ein Anwendungsfall dieses allgemeineren Prozesses.

Wofür steht LLM im Zusammenhang mit künstlicher Intelligenz?

LLM steht für Large Language Model, also großes Sprachmodell. Bei der hier behandelten Texterzeugung verarbeitet es Kontext und sagt Tokens voraus, aus denen eine Fortsetzung entsteht.

Was bedeutet Inferenz im Zusammenhang mit Sprache?

Gemeint ist in diesem Zusammenhang meist die Inferenz durch ein Sprachmodell. Der Ausdruck bezeichnet keine vorgeschriebene Programmiersprache. Eine Anwendung kann das Modell über seine API oder Laufzeitumgebung aufrufen.

Was unterscheidet Inferenz von Vorhersage beim maschinellen Lernen?

Inferenz ist der Vorgang, bei dem das trainierte Modell ausgeführt wird. Eine Vorhersage ist eine Ausgabe dieses Vorgangs. Bei der autoregressiven Spracherzeugung entsteht die Antwort aus wiederholten Vorhersagen des jeweils nächsten Tokens.

Welche drei Arten der Inferenz gibt es?

Geht es um Schlussfolgerungen, sind damit meist Deduktion, Induktion und Abduktion gemeint. Das sind logische Kategorien. Eine Hersteller-API, ein gehosteter Inferenzanbieter und eine selbst betriebene Laufzeitumgebung sind Bereitstellungsoptionen, keine dieser drei Schlussfolgerungsmethoden.

Was sind fünf Beispiele für Inferenz?

Typische Aufgaben für Sprachmodelle sind das Klassifizieren einer E-Mail, das Zusammenfassen eines Dokuments, das Übersetzen eines Abschnitts, das Entwerfen einer Antwort und das Erzeugen von Code. Das sind Aufgabenbeispiele, keine Leistungsversprechen für ein bestimmtes Modell.

Wie sieht ein konkretes Beispiel für Inferenz aus?

Eine Supportanwendung übermittelt die Frage eines Kunden zusammen mit dem passenden Richtlinientext an ein trainiertes Modell. Dieses erzeugt einen Antwortentwurf. Sowohl die Verarbeitung des bereitgestellten Kontexts als auch die Erzeugung der Antwort gehören zur Inferenz.

Wie führt man eine Inferenz aus?

Für eine LLM-Anwendung wird ein trainiertes Modell ausgewählt, der passende Prompt über eine API oder Laufzeitumgebung übergeben und die zurückgegebene Ausgabe bewertet. Ein bereits trainiertes Modell lässt sich nutzen, ohne es selbst zu trainieren.

Was ist Inferenz, einfach erklärt?

Ein Modell nutzt das Gelernte, um aus einer neuen Eingabe eine Ausgabe zu erzeugen. Bei einem Chatbot ist das die Arbeit des Modells zwischen dem Empfang des Gesprächs und der Ausgabe der nächsten Antwort.

Was sich nächste Woche konkret verbessern lässt

Entwicklungsteams sollten Anfragen messbar machen, Betriebsteams sie unter Last prüfen und Einkäufer die daraus abgeleiteten Anforderungen an den Dienst vergleichen. Diese Aufgaben greifen ineinander, lassen sich aber nicht gegeneinander austauschen.

1. 1

   Den gesamten Ablauf erfassen

   Für eine repräsentative Aufgabe werden die Anzahl der Eingabe- und Ausgabetokens, die erste nicht leere Ausgabe, die letzte Ausgabe und die verfügbaren Zeitfelder des Anbieters aufgezeichnet. Neben der Modellzeit müssen auch Informationssuche und Tool-Aufrufe gemessen werden. Anfragen mit und ohne Cache-Nutzung sind getrennt zu kennzeichnen.

2. 2

   Am größten Zeitanteil ansetzen

   Dominiert die wiederholte Prompt-Verarbeitung, sollten die Wiederverwendung von Präfixen und unnötiger Kontext untersucht werden. Dominiert die Generierung, helfen möglicherweise kürzere Ausgaben oder die Prüfung eines passenden Modells beziehungsweise einer geeigneten Decode-Konfiguration. Dominiert die Warteschlange, sind zunächst Kapazität und Anfragezulassung zu prüfen, bevor der Prompt umgeschrieben wird.

3. 3

   Realistisches Anfrageaufkommen nachbilden

   Ergebnisqualität und Latenz werden mit der erwarteten Zahl gleichzeitiger Anfragen verglichen, einschließlich langer Eingaben und Ausgaben. Auf dieser Grundlage lässt sich die bisherige API beibehalten, ein anderer Hoster prüfen oder der Betrieb eigener Kapazitäten begründen. Vor dem Eigenbetrieb muss feststehen, wer bei Ausfällen verantwortlich ist.

Der Newsletter liefert praxisnahe Erklärungen zu den Systemen hinter KI-Produkten.