DeepInfer erklärt: So optimiert DeepSeek die KI-Inferenz

DeepInfer ist DeepSeeks Software für die Inferenz, also die Ausführung bereits trainierter KI-Modelle. Sie setzt unter anderem bei der Verteilung von Berechnungen, der Token-Erzeugung und der Wiederverwendung von Kontext an. Daran lässt sich erklären, warum die Effizienz eines KI-Dienstes von mehr als schnellen Chips abhängt. Quelle: DeepInfer-Projektbeschreibung.

Das Modell muss die Eingabe verarbeiten, seine Berechnungen über viele Speicherbereiche und womöglich mehrere Chips verteilen und anschließend die Antwort erzeugen. Gleichzeitig warten andere Menschen auf ihre Ergebnisse. Ein Dienst muss deshalb mehr leisten, als eine einzelne Anfrage möglichst schnell abzuarbeiten.

Inferenz: Was nach dem Training passiert

Beim Training werden die Parameter eines Modells angepasst. Inferenz ist die spätere Nutzung: Das bereits trainierte Modell verarbeitet eine Eingabe und berechnet eine Ausgabe.

Vorher wird Text in Tokens zerlegt. Ein Token ist keine feste Wortportion. Häufige Wörter können eine Einheit bilden, andere Wörter werden in mehrere Teile aufgeteilt. Sprache, Schreibweise und verwendeter Tokenizer beeinflussen die Zerlegung. Deshalb lassen sich Tokenzahlen nicht zuverlässig mit einer einzigen Faustregel in Wörter oder Buchseiten umrechnen. Die Tokenizer-Dokumentation von Hugging Face zeigt die zugrunde liegenden Verfahren.

Für einen langen Bericht bedeutet das: Selbst wenn die gewünschte Antwort kurz ist, kann die Eingabe umfangreich sein. Und eine Rückfrage kann wieder auf große Teile dieses Kontexts Bezug nehmen. Der sichtbare Antworttext beschreibt nur einen Teil der geleisteten Arbeit.

Gesprächsstruktur und normaler Text sind verschiedene Dinge

Ein Modell erhält nicht bloß eine lose Zeichenfolge. Eine Anwendung muss auch kenntlich machen, welche Nachricht vom Nutzer stammt und wo andere Teile des Gesprächs beginnen.

DeepSeek Recipe trennt ausdrücklich eingefügte Steuer-Tokens von gewöhnlichem Text. Schreibt jemand die Zeichenfolge eines solchen Steuerzeichens in eine Nutzernachricht, wird sie als Inhalt kodiert. Sie wird dadurch nicht automatisch zu einer echten Gesprächsgrenze. Das erläutert die Recipe-Dokumentation.

Das ist eine nützliche technische Grenze. Eine vollständige Abwehr von Prompt Injection entsteht daraus jedoch nicht: Ein manipulativer Satz kann auch ohne besondere Steuerzeichen versuchen, das Verhalten des Modells zu beeinflussen.

Erst die Eingabe verarbeiten, dann die Antwort schreiben

Bei Sprachmodellen werden zwei Arbeitsphasen unterschieden:

Phase	Aufgabe	Typische Herausforderung
Prefill	Die vorhandene Eingabe verarbeiten	Viel Rechenarbeit auf einmal
Decode	Die Antwort schrittweise erzeugen	Daten rechtzeitig bereitstellen und laufende Antworten bedienen

Diese unterschiedlichen Profile können eine Trennung sinnvoll machen. Eine Gruppe von Beschleunigern verarbeitet neue Eingaben, eine andere setzt die bereits laufenden Antworten fort. Die Dynamo-Dokumentation von NVIDIA beschreibt diesen Ansatz als Disaggregated Serving.

Denk an einen Copyshop mit zwei Aufgaben: Ein großer Auftrag muss zunächst vorbereitet werden, während bereits fertige Aufträge gedruckt werden. Eine getrennte Vorbereitung verhindert, dass jede neue Großbestellung den laufenden Betrieb unterbricht. Dafür muss das vorbereitete Material zuverlässig zur richtigen Druckstation gelangen.

Im Rechenzentrum kostet genau diese Übergabe Zeit und Netzwerkleistung. Die Trennung ist deshalb eine Gestaltungsmöglichkeit, kein allgemeiner Beschleunigungsschalter. Bei kleinen Lasten kann ein anderer Aufbau günstiger sein als bei vielen gleichzeitigen langen Anfragen.

Viele Experten, aber nur einige rechnen mit

Das von DeepInfer unterstützte DeepSeek-V4.1-Flash ist ein Mixture-of-Experts-Modell, kurz MoE. In einer entsprechenden Schicht stehen zahlreiche gelernte Teilnetze bereit. Für ein bestimmtes Token wird nur eine Auswahl aktiviert.

Die offizielle Model Card nennt 384 geroutete Experten je MoE-Schicht. Pro Token werden sechs davon ausgewählt; hinzu kommt ein geteilter Experte. „Experte“ bezeichnet hier ein Teilnetz, keinen kleinen Mathematiker oder Übersetzer mit einer fest zugewiesenen Berufsbezeichnung.

Auch die Schichten sind anders organisiert als bei einem durchgehend gleich arbeitenden Stapel: Auf 20 Encoder-Schichten folgen 20 Decoder-Schichten. Der Decoder nutzt globale Kontextinformationen aus dem Encoder. DeepSeek gibt dafür acht Milliarden aktivierte Parameter pro Token beim Prefill und 16 Milliarden beim Decode an.

Damit kann weniger Arbeit anfallen, ohne dass sämtliche Modellgewichte verschwinden. Die nicht gerade verwendeten Experten müssen weiterhin verfügbar sein. Rechenbedarf und Speicherbedarf sind also verschiedene Größen.

Warum die Anordnung von Daten den Aufwand beim Zugriff verändert, zeigt der Einstieg in Datenstrukturen an kleineren Beispielen. Diese Grundfrage wird bei verteilten KI-Modellen um die Wege zwischen den Chips erweitert.

Wenn der Transport die Berechnung ausbremst

Wer Experten auf mehrere Chips verteilt, gewinnt Platz und parallele Rechenmöglichkeiten. Gleichzeitig entstehen zusätzliche Wege. Die Daten eines Tokens müssen zu den ausgewählten Experten, deren Ergebnisse anschließend wieder zusammengeführt werden.

DeepEP stellt dafür spezialisierte Kommunikationsoperationen bereit. Die Projektbeschreibung spricht unter anderem von Dispatch und Combine: verteilen und zusammenführen. Die Bibliothek unterstützt diese Kommunikation sowohl beim Training als auch bei der Inferenz. Quelle: DeepEP.

Ein einfaches Beispiel verdeutlicht den Engpass: Vier Arbeitsstationen können einen Auftrag jeweils in einer Millisekunde erledigen. Braucht das Material fünf Millisekunden bis zur zuständigen Station, hilft deren reine Rechengeschwindigkeit nur begrenzt. Noch schnellere Stationen würden am Hauptproblem vorbeigehen.

Hinzu kommt eine ungleiche Auslastung. Wenn bestimmte Experten besonders häufig angefordert werden, können andere Chips freie Kapazität haben, während diese Experten den Ablauf aufhalten. DeepSeek hält deshalb zusätzliche Kopien häufig genutzter Experten bereit und passt ihre Verteilung anhand gesammelter Lastdaten an. Das Deployment-Q&A beschreibt eine periodische Neuzuordnung. Sie reagiert auf beobachtete Last; sie kennt künftige Anfragen nicht im Voraus.

DSpark: Mehr vorschlagen, passend viel prüfen

Beim gewöhnlichen autoregressiven Schreiben entsteht die Fortsetzung Schritt für Schritt. Spekulatives Decoding bereitet mehrere mögliche Tokens vor, die das Zielmodell anschließend prüft.

Der Vorteil hängt davon ab, wie gut diese Vorschläge passen und wie teuer ihre Überprüfung ist. Eine lange Reihe schlechter Vorschläge kann mehr Aufwand erzeugen, als sie spart. DSpark berücksichtigt deshalb geschätzte Annahmewahrscheinlichkeiten und das Durchsatzprofil der verwendeten Engine, wenn es die Prüflänge festlegt. Das Verfahren verbindet eine parallele Entwurfsstruktur mit einem kleinen sequenziellen Teil. Quelle: DSpark-Originalpublikation.

Man kann sich das wie vorbereitete Textbausteine vorstellen: Ein brauchbarer Anfang lässt sich gemeinsam prüfen und übernehmen. Am ersten unpassenden Stück muss der Ablauf neu ansetzen. Die geschickte Entscheidung besteht darin, wie weit sich die Vorbereitung unter den aktuellen Bedingungen lohnt.

Diese Prüfung ist keine Faktenrecherche. Sie entscheidet nicht, ob eine Jahreszahl im Text stimmt. Eine schneller erzeugte falsche Antwort bleibt falsch. Die Unterscheidung zwischen Betriebsleistung und Antwortqualität ist auch bei Gemini 4 Argon und seinen Benchmarks wichtig.

Bounded Replay: Ein Stück neu rechnen, um Zustand zu sparen

Bei der Rückfrage „Was bedeutet der dritte Punkt?“ ist der ursprüngliche Bericht weiter relevant. Bereits berechnete Kontextinformationen lassen sich zwischenspeichern, statt alles erneut zu verarbeiten.

DeepSeeks Architektur unterscheidet dabei globale Kontextinformationen und einen Zustand für ein kurzes lokales Fenster. Bounded Replay kann fehlenden lokalen Zustand durch die erneute Verarbeitung eines begrenzten Abschnitts aufbauen. Der ältere globale Kontext muss weiterhin vorhanden sein.

Der vLLM-Bericht zu DeepSeek-V4.1-Flash erklärt ein Fenster von 128 Tokens. Die Rekonstruktion ist eine Näherung, keine bitgenaue Wiederholung. In den dort genannten Qualitätsprüfungen wurden keine bedeutsamen Unterschiede festgestellt; daraus folgt keine Garantie für jede denkbare Aufgabe.

DeepInfer hält in seiner Standardkonfiguration 140 Tokens zurück, um auch den benötigten Spielraum für Rücksprünge abzudecken. Diese Einstellung steht im Repository. Die Zahl ist keine Behauptung, dass sich ein komplettes Gespräch aus den letzten 140 Tokens wiederherstellen ließe.

Was die Betriebszahlen aussagen

DeepSeek nennt für einen Cluster 155 Billionen bediente Tokens täglich und 38 US-Dollar Umsatz je GPU-Stunde bei Nebenzeitpreisen. Das sind Angaben des Unternehmens aus seinem Deployment-Q&A.

Daraus lässt sich keine Gewinnmarge berechnen. Dafür fehlen unter anderem belastbare Kosten für Hardware, Energie, Netzwerk und Betrieb. Auch ist eine bediente Tokenmenge nicht mit derselben Menge neu geschriebener Wörter gleichzusetzen.

Für einen fairen Leistungsvergleich wären andere Fragen nützlicher: Wie lange wartet eine Person auf den Anfang der Antwort? Wie gleichmäßig kommt der weitere Text? Wie viele Anfragen lassen sich bei dieser Wartezeit gleichzeitig bedienen? Und welche Hardware und Kosten sind dafür nötig?

Offener Code und ein vollständiger Dienst

DeepInfer veröffentlicht den Berechnungskern mit wichtigen Inferenzfunktionen. Das Repository nennt Nvidia SM100 und Huawei Ascend 950 als unterstützte Hardware. Ein vollständiges Cache-System und Teile der übergreifenden Dienstorganisation sind nicht enthalten. Quelle: DeepInfer.

Die Veröffentlichung bietet damit Material zum Untersuchen und Weiterentwickeln. Sie ist kein Versprechen, den gesamten DeepSeek-Dienst nach einem Download auf einem gewöhnlichen Laptop betreiben zu können.

Der Blick in diese Technik verändert vor allem eine Vorstellung: Die Kosten einer KI-Antwort entstehen nicht an einer einzigen Stelle. Sie hängen auch daran, wie selten ein teurer Chip auf Daten, einen überlasteten Nachbarn oder den nächsten passenden Auftrag warten muss.