Wie Inferenz funktioniert

Jede Antwort eines lokalen Modells folgt demselben Hin- und Rückweg: Ihr Text wird in Tokens umgewandelt, das Modell liest den gesamten Prompt auf einmal ein und schreibt dann die Antwort Token für Token. Das Verständnis dieser Schritte erklärt zwei Dinge, auf die jeder Nutzer lokaler Modelle stößt – warum ein langer Prompt einen Moment zum „Denken“ braucht, bevor das erste Wort erscheint, und warum die Generierungsgeschwindigkeit vom Speicher und nicht nur von der reinen Rechenleistung abhängt. Diese Seite ist die 101 für den Rest des Konzepte-Tracks. Wenn Sie hier nur eine Seite lesen, lesen Sie diese.

​

Schritt 1: Tokenisierung

Bevor das Modell etwas sieht, wird Ihr Prompt in Tokens aufgeteilt – kleine Textblöcke, die jeweils etwa ein paar Zeichen oder ein Wortstück umfassen. Die Tokenisierung ist deterministisch und nahezu augenblicklich; es handelt sich lediglich um eine Nachschlageoperation im Vokabular des Modells. Das Modell sieht niemals den rohen Text, sondern nur eine Sequenz von Token-IDs.

​

Schritt 2: Prefill (rechenlastig)

Prefill ist der Vorgang, bei dem das Modell Ihren gesamten Prompt liest – jedes Token, das Sie gesendet haben, in einem Durchgang –, bevor es ein einziges Wort zurückgibt. Dieser Schritt ist rechenlastig: Die GPU führt schwere Matrixberechnungen über den gesamten Prompt auf einmal durch, sodass er mit der verfügbaren Rechenleistung skaliert. Prefill hat zwei Auswirkungen, die Sie kennen sollten:

• Dies ist der Vorgang, auf den Sie warten, wenn eine Antwort langsam startet. Die Verzögerung zwischen dem Senden eines Prompts und dem Erscheinen des ersten Tokens wird als Zeit bis zum ersten Token (TTFT) bezeichnet und besteht fast ausschließlich aus der Prefill-Zeit.
• Es erstellt den KV-Cache – eine fortlaufende Aufzeichnung des Prompts, sodass das Modell ihn bei jedem nachfolgenden Token nicht erneut verarbeiten muss. Siehe KV-Cache und Kontext, um zu erfahren, was dieser Cache an Speicher kostet.

Längere Prompts bedeuten mehr Prefill-Arbeit, was zu einer längeren TTFT führt.

​

Schritt 3: Dekodierung (speicherbandbreitenlastig)

Sobald das Prefill abgeschlossen ist, beginnt das Modell mit der Dekodierung: Es generiert die Antwort Token für Token. Jedes neue Token wird an die Sequenz angehängt, und das nächste Token wird basierend auf allem vorherigen vorhergesagt. Die Dekodierung verhält sich sehr unterschiedlich zum Prefill. Bei jedem einzelnen Schritt muss das Modell seine Gewichte (oder bei einem Mixture-of-Experts-Modell nur die aktiven Experten) sowie den gesamten KV-Cache aus dem Speicher lesen. Da pro Token im Verhältnis zur zu bewegenden Datenmenge nur wenig neue Berechnung stattfindet, ist die Dekodierung speicherbandbreitenlastig – sie wird dadurch begrenzt, wie schnell Daten vom Speicher zu den Recheneinheiten gelangen können, nicht dadurch, wie viel reine Rechenleistung Sie haben. Dies ist das, was Tokens pro Sekunde misst, und genau deshalb:

• Eine GPU mit weniger Rechenleistung, aber schnellerem Speicher eine „schnellere“ Chip mit langsamerem Speicher bei der Dekodierung übertreffen kann.
• Längere Kontexte die Dekodierung verlangsamen, da bei jedem einzelnen Schritt mehr KV-Cache gelesen werden muss, zusätzlich zu den höheren Speicherkosten (siehe KV-Cache und Kontext).

​

Schritt 4: Tokens werden zurückgestreamt

Sobald das Modell jedes Token erzeugt, wird es zurück in Text dekodiert und sofort an den Client gestreamt – deshalb sehen Sie Antworten Wort für Wort erscheinen, anstatt alles auf einmal. Wenn Sie Tokios verwenden, wird dieser Stream von Ihrem lokalen Backend durch den Connector und das Gateway zurück zu der App oder dem Agenten geleitet, der die Anfrage gesendet hat; siehe Wie Tokios Anfragen weiterleitet für diesen Teil der Reise.

​

Was wo im Speicher landet

Alles oben Gesagte geschieht in Bezug auf drei Dinge, die im VRAM (oder im einheitlichen Speicher) residieren: Die Gewichte sind der Mindestbedarf – Sie können das Modell nicht ausführen, ohne dass diese vollständig geladen (oder teilweise ausgelagert; siehe Speicher und Auslagerung) sind. Der KV-Cache ist der Teil, der wächst, wenn Ihre Konversation oder Ihr Dokument länger wird, weshalb „Es hat mit einem kurzen Prompt funktioniert, aber bei einem langen ist der Speicher aufgebraucht“ ein so häufiges Fehlermuster ist.

​

Vertiefung

​

Sobald Sie verstehen, wie es läuft

Alles oben Gesagte geschieht auf Ihrem Computer, mit einem Modell, das auf localhost läuft. Sobald Sie sich damit vertraut fühlen, ist die nächste Frage, wie Sie von einem anderen Ort als Ihrem eigenen Computer darauf zugreifen können.