> Quelle: https://souverana.ch/insights/deepseek-inferenz-betrieb/
> Sprache: de-CH

# Wie DeepSeek so günstig sein kann: Einblick in den Betrieb

DeepSeek betreibt V4.1 Flash für 0.30 US-Dollar pro Million Eingabe-Tokens (das Spitzenmodell von OpenAI kostet 2.00) und verdient daran. Der Beitrag zeigt, wie dieser Betrieb funktioniert und wie sich DeepSeek und die US-Labore in Philosophie und Offenlegung unterscheiden. Daraus folgt, was Sie einen Hoster fragen sollten, bevor Sie bei ihm einkaufen.

Analyse · Veröffentlicht 20.10.2026 · Aktualisiert 20.10.2026 · Joel Barmettler

## Was hinter dem Token-Preis steckt: DeepSeek legt den Betrieb offen

**Ein Modell wie DeepSeek V4.1 Flash kostet 0.30 US-Dollar pro Million Eingabe-Tokens, das Modell GPT-6.1 Sol von OpenAI 2.00 US-Dollar. Trotzdem verdient DeepSeek Geld. Sie machen rund 38 US-Dollar Umsatz pro GPU und Stunde, bei Kosten von grob 2 bis 2.50. Wie das geht, hat DeepSeek am 20. Oktober 2026 offengelegt.**

**Das Wichtigste in Kürze**

-   DeepSeek nimmt pro GPU und Stunde rund 38 US-Dollar ein. Das ist über 35 US-Dollar Marge pro GPU.
-   DeepSeek und die grossen US-Labore setzen unterschiedliche Prioritäten. DeepSeek optimiert auf die Kosten pro Token. Die US-Labore setzen auf immer grössere Modelle. OpenAI finanziert diese Strategie bisher mit Investorengeld und schreibt nach Medienberichten weiter Verluste.
-   Zwei Hebel erklären den tiefen Preis von DeepSeek: Intelligenteres Caching und bessere GPU-Auslastung.
-   DeepSeek legt Gewichte, Software und Betriebszahlen offen, die Trainingsdaten nicht. Offene Gewichte allein heissen also nicht, dass ein Modell transparent ist. Da hat Apertus weiterhin die Nase vorn.

Dieser Beitrag ist der Beleg zu unserer Rechnung für eine [öffentliche KI in der Schweiz](https://souverana.ch/insights/ki-infrastruktur-schweiz-kosten/), die auf DeepSeeks Betriebszahlen beruht. Wer bezweifelt, dass sich KI so günstig betreiben lässt, findet hier den Beleg.

DeepSeek ist ein chinesisches KI-Labor, das Sprachmodelle entwickelt mit offenen Gewichten gratis veröffentlicht. DeepSeek optimiert konsequent auf Leistung und Kosten, vom Modellaufbau über TileLang, eine eigene Programmiersprache für GPU-Programme, bis zum Rechenzentrum. Die Modelle von DeepSeek können entweder heruntergeladen und selbst betrieben, oder direkt bei DeepSeek via API bezogen werden. Die Preise für ihren Inferenz\-Service sind unschlagbar tief: 0.30 US-Dollar pro Million Eingabe-Tokens bei DeepSeek-v4.1-flash gegenüber 2.00 bei OpenAIs GPT-6.1 Sol (Listenpreise, Oktober 2026).[1–3] Der Preisunterschied hat mit der optimierten Modell-Architektur von DeepSeek zu tun, aber auch mit ihrer ausgeklügelten Weise, ihr Modell-Hosting zu optimieren.

Dieser Beitrag ist der vierte Teil unserer Serie zum Einkauf von Inferenz.

**Serie · Inferenz einkaufen**

1.  [Was LLMs wirklich kosten: Der Preis pro Token täuscht](https://souverana.ch/insights/llm-kosten/)
2.  [Prompt Caching: Warum Agenten in der Schweiz teurer laufen](https://souverana.ch/insights/prompt-caching/)
3.  [Prompt Caching im Betrieb: Was ein Hoster einrichten muss](https://souverana.ch/insights/prompt-caching-betrieb/)
4.  Wie DeepSeek so günstig sein kann: Einblick in den Betrieb (dieser Teil)

## Zwei Philosophien: Kosten pro Token oder Grösse des Modells

DeepSeek und die grossen US-Labore setzen unterschiedliche Prioritäten.

DeepSeek optimiert auf die Kosten pro Token. Das Modell rechnet pro Token nur einen Bruchteil seiner Parameter, ein Cache liefert für wiederkehrende Anfragen günstiger Resultate, und die Server sind speziell auf ihre Aufgabe zugeschnitten. Die Firma DeepSeek optimiert an allen Ecken und Enden auf günstige Betriebskosten.

Die grossen US-Labore setzen auf maximale Intelligenz. Sie bauen Modelle, die in Tests vorn liegen, koste es, was es wolle. Ihre Modelle werden dabei immer grösser - und immer teurer. OpenAI nannte 2025 Verpflichtungen von rund 1.4 Billionen US-Dollar für 30 Gigawatt Rechenleistung. Laut einem Bericht von Reuters plant es inzwischen mit rund 600 Milliarden US-Dollar bis 2030.[4] Amazon, Microsoft, Alphabet und Meta planen für 2026 zusammen Investitionen von rund 700 bis 725 Milliarden US-Dollar.[5] OpenAI selbst ist nicht profitabel. Nach Medienberichten, die sich auf interne Zahlen berufen, lag der Umsatz 2025 bei rund 13 Milliarden US-Dollar, und für 2026 wird ein Verlust von rund 14 Milliarden erwartet.[6] Die Zahlen zu Umsatz und Verlust sind nicht geprüft und je nach Quelle verschieden.

Beide Strategien haben ihren Grund. Das grössere Modell erreicht mehr: Im Artificial-Analysis-Index liegt GPT-6.1 Sol je nach Denkaufwand bei 42 bis 52 Punkten, Deepseek v4.1 Flash bei 39.[1, 7] Für viele Aufgaben genügt ein günstigeres Modell, der Vorsprung des stärksten Modells ist aber gerade bei komplexen Aufgaben wie Coding real.

## Was die Labore offenlegen

Bei einem KI-Modell lassen sich drei Dinge offenlegen: die Gewichte, mit denen man es selbst betreiben kann, die Trainingsdaten, mit denen man es prüfen kann, und die Software für den Betrieb.

|  | DeepSeek | OpenAI, Anthropic, Google (Spitzenmodelle) |
| --- | --- | --- |
| Gewichte | offen, MIT-Lizenz | geschlossen, nur über eine API |
| Trainingsdaten | nicht offen[8] | nicht offen |
| Software für den Betrieb | Engine DeepInfer offen, Cache-Verwaltung und Load Balancing nur beschrieben | nicht veröffentlicht |
| Betriebszahlen | Trefferquote, Durchsatz, Umsatz pro GPU und Stunde (2025 und 2026)[9] | uns ist keine vergleichbare Veröffentlichung bekannt |

OpenAI hat mit gpt-oss und Google mit Gemma kleinere Modelle mit offenen Gewichten veröffentlicht. Spitzenmodelle mit offenen Gewichten gibt es von diesen drei Firmen nicht.

Was DeepSeek auszeichnet, ist die Offenlegung des Betriebs. Betriebszahlen, Software und die Beschreibung der Cache-Verwaltung erlauben es, den Preis eines Hosters nach zu rechnen.[9]

## Der Weg einer Anfrage

Wie DeepSeek die Kosten pro Token im Betreib drückt, zeigt sich am besten entlang einer einzelnen Anfrage.

Eine Anfrage durchläuft bei DeepSeek vier Stationen. Zuerst wandelt Recipe, DeepSeeks Baustein für die Tokenisierung, den Text in Tokens um. Dann prüft der Entrypoint, der erste Server im Ablauf, ob der Anfang der Anfrage schon im Cache liegt. Anschliessend reicht er die Anfrage an einen Load Balancer weiter, der sie auf freie Server verteilt. Danach arbeiten zwei Server hintereinander an der Anfrage: Ein Prefill\-Server liest die gesamte Eingabe auf einmal, ein Decode\-Server schreibt die Antwort Token für Token. Bilder verarbeiten vorab eigene Server, die sie in Zahlen umrechnen.[9]

Weg einer Anfrage

1.  01 **Recipe** Macht aus der Anfrage Tokens und aus der Antwort wieder JSON
2.  02 **Entrypoint** Schlägt den Cache nach und übergibt an den Lastverteiler
3.  03 **Prefill** Liest die Eingabe. 2 bis 8 Karten pro Instanz
4.  04 **Decode** Schreibt die Antwort. 64 bis 128 Karten pro Instanz

**Bild-Encoder** Bilder, eine Karte, die günstigste, die reicht

**Gemeinsamer Cache-Speicher (3FS auf SSD)** Decode schreibt, jeder Prefill-Rechner liest. Hält Tage. Kurzes Fenster (letzte 128 Tokens): Arbeitsspeicher des erzeugenden Rechners, rund 3 Minuten

Eigene Darstellung nach der Beschreibung im DeepSeek-Beitrag vom 20. Oktober 2026. GPU-Zahlen: Eigenangaben von DeepSeek.

Das Modell läuft bei DeepSeek in mehreren Instanzen. Eine Instanz ist eine vollständige Kopie des Modells, verteilt auf eine feste Zahl von GPUs. Prefill- und Decode-Instanzen sind verschieden gross. Eine Prefill-Instanz belegt 2 bis 8 GPUs, höchstens also einen gewöhnlichen Server mit 8 GPUs. DeepSeek nimmt dafür die kleinste GPU-Zahl, auf der das Modell im Grafikspeicher noch Platz hat. Eine Decode-Instanz belegt 64 bis 128 GPUs. So viele fasst ein Supernode, ein Verbund aus vielen GPUs, die über ein sehr schnelles Netz zusammenarbeiten.[9]

Der Grund für die unterschiedlichen Grössen liegt im Aufbau des Modells. DeepSeepk-4.1 Flash ist ein Mixture-of-Experts-Modell. Es besteht aus sehr vielen Experten, das sind spezialisierte Rechenblöcke, und ein Router wählt für jedes Token nur wenige davon aus. Im Grafikspeicher müssen trotzdem alle Experten liegen.

Beim Decode verteilt DeepSeek die Experten besonders weit, nämlich auf alle 64 bis 128 GPUs einer Instanz (Expert Parallelism). Jede GPU hält dann nur einen kleinen Teil der Experten und hat dadurch viel Speicher frei für die Zwischenergebnisse vieler gleichzeitiger Anfragen. Jede GPU bedient ihre eigenen Anfragen und schickt jedes Token zu den GPUs, auf denen die gewählten Experten liegen. Beim Decode lohnt sich diese Verteilung am meisten, weil dort der Speicher der Engpass ist.[9]

## Die Zahlen aus dem Betrieb

> **96 %** der Eingabe stammen bei DeepSeek V4.1 Flash im Produktivbetrieb im Mittel aus dem Cache, bei Eingaben von durchschnittlich 77'000 Tokens.
> 
> Quelle: DeepSeek, V4.1 Flash im Grosseinsatz, Zhihu, 20. Oktober 2026 (Eigenangabe)

| Stufe | Kennzahl | Wert im Produktivbetrieb |
| --- | --- | --- |
| Prefill | Durchsatz pro GPU, ohne Cache-Treffer | 60’000 Tokens/s[9] |
| Prefill | Durchsatz pro GPU, mit Cache-Treffern | 1.5 Mio. Tokens/s |
| Prefill | Mittlere Eingabelänge | 77’000 Tokens |
| Prefill | Wartezeit bis zum ersten Token, Mittel | 400 ms |
| Prefill | Wartezeit bis zum ersten Token, P99 | 1’000 ms |
| Decode | Durchsatz pro GPU | 14’000 Tokens/s |
| Decode | Tempo pro Nutzer (Decode) | 230 Tokens/s (Coding: 300) |
| Cache | Haltedauer nach der letzten Nutzung | 72 Stunden |

Die Server sind laut DeepSeek mit Reserve für Lastspitzen geplant. Das Verhältnis von Prefill- zu Decode-Servern liegt im Betrieb nahe bei 1:1.[9]

Die beiden Prefill-Werte lassen sich ineinander umrechnen. Kommen 96 Prozent der Eingabe aus dem Cache, muss die GPU nur 4 Prozent wirklich rechnen. 60’000 geteilt durch 0.04 ergibt 1.5 Millionen: Der Cache macht Prefill 25-mal schneller. Diese Ersparnis lässt rechnerisch Platz für einen Preis weit unter dem Normalpreis.

Bei einer mittleren Eingabe von 77’000 Tokens vergehen bis zum ersten Token im Mittel 400 Millisekunden, bei den langsamsten 1 Prozent der Anfragen (P99) 1’000 Millisekunden. Beim Decode liefert eine GPU 14’000 Tokens pro Sekunde, jeder Nutzer bekommt 230.[9] Daraus ergibt sich rechnerisch, dass sich rund 60 Nutzer eine GPU teilen (unsere Rechnung).

## Warum Prefill und Decode getrennte Server bekommen

Beim Prefill verarbeitet jede GPU pro Schritt einen Stapel von Eingabe-Tokens. Bei Stapeln von 4’096 Tokens liefert sie rund 66’000 Tokens pro Sekunde, bei 32’768 Tokens rund 87’000. Bei 65’536 Tokens pro Stapel verdoppelt sich die Wartezeit pro Schritt von rund 380 auf 760 Millisekunden, der Durchsatz wächst nicht mehr. Die GPU ist dann ausgelastet, und mehr Eingabe auf einmal bedeutet nur längeres Warten.[9]

Beim Decode verläuft die Kurve gegenläufig: Je mehr Anfragen eine GPU gleichzeitig bedient, desto langsamer wird jeder einzelne Nutzer. Mit 256 gleichzeitigen Anfragen pro GPU liefert eine GPU rund 26’000 Tokens pro Sekunde, jeder Nutzer bekommt aber nur rund 100. Mit 8 Anfragen pro GPU erreicht jeder Nutzer rund 325, die GPU liefert nur noch rund 2’600. Wer jedem Nutzer ein 3.2-mal höheres Tempo bietet, holt aus der GPU nur noch ein Zehntel heraus.[9]

**Diagramm: Prefill: Stapelgrösse gegen Durchsatz und Wartezeit pro Schritt**

*Durchsatz pro GPU (Tokens pro Sekunde) / Wartezeit pro Schritt (Millisekunden)*

| Kategorie | Durchsatz pro GPU (Tokens/s) | Wartezeit pro Schritt (ms) |
| --- | --- | --- |
| 4'096 | 66400 | 62 |
| 8'192 | 75900 | 108 |
| 16'384 | 84300 | 194 |
| 32'768 | 86700 | 378 |
| 65'536 | 86800 | 756 |

Quelle: DeepSeek V4.1 Flash, Offline-Messung, EP4/DP4, Kontext 131'072, Werte aus der Grafik abgelesen

**Diagramm: Decode: gleichzeitige Anfragen pro GPU gegen Durchsatz und Tempo pro Nutzer**

*Durchsatz pro GPU (Tokens pro Sekunde) / Tempo pro Nutzer (Tokens pro Sekunde)*

| Kategorie | Durchsatz pro GPU (Tokens/s) | Tempo pro Nutzer (Tokens/s) |
| --- | --- | --- |
| 8 | 2600 | 325 |
| 16 | 5000 | 314 |
| 32 | 9500 | 297 |
| 64 | 15700 | 246 |
| 128 | 22800 | 179 |
| 256 | 26300 | 103 |

Quelle: DeepSeek V4.1 Flash, Offline-Messung, EP64/DP64, 3 Entwurfs-Tokens, 75 % Akzeptanz pro Token, Kontext 131'072, Werte aus der Grafik abgelesen

Die Kurven passen ungefähr zum Produktivbetrieb. Dort liefert eine GPU 14’000 Tokens pro Sekunde bei 230 pro Nutzer. Die Offline-Kurve ergibt bei diesem Tempo rund 17’000, gelesen zwischen den Punkten für 128 und 64 Anfragen. Der Betrieb liegt also etwa ein Fünftel darunter.[9]

Für den Einkauf folgt daraus: Ein Hoster, der hohes Tempo pro Nutzer zusichert, rechnet mit weniger gefüllten GPUs und muss das im Preis weitergeben, ausser er hat genug Nutzer, um viele Anfragen auf eine GPU zu packen. Ein kleiner Hoster mit wenigen Kunden kann deshalb hohes Tempo und tiefe Preise nur schwer zugleich bieten. Das ist unsere Einschätzung aus den Kurven, DeepSeek macht dazu keine Angabe. Wer selbst hostet, bewegt sich auf derselben Kurve, nur mit weniger Nutzern, wie unsere Rechnung zu den Kosten des Selbsthostens zeigt.

## Die Rechnung: Warum 38 US-Dollar pro GPU und Stunde reichen

DeepSeek nennt 38 US-Dollar Umsatz pro GPU und Stunde, gemittelt über Prefill- und Decode-Server und berechnet zu den Preisen ausserhalb der Spitzenzeit.[9] Das entspricht rund 32 Franken (Kurs vom 1. Oktober 2026).[10] Was DeepSeek eine GPU-Stunde kostet, nennt der Beitrag nicht. Wir verteilen die Anschaffungskosten der Hardware auf vier Jahre und kommen auf grob 2 bis 2.50 US-Dollar pro GPU-Stunde, ohne Strom, Rechenzentrum und Personal. Der Umsatz ist damit das 15- bis 19-Fache der Hardwarekosten. Eine Marge ist das noch nicht: Dafür fehlen die übrigen Kosten, und der Umsatz zu Preisen ausserhalb der Spitzenzeit ist nicht der Umsatz über den ganzen Tag. Der Abstand zeigt aber, dass der Spielraum gross genug ist, um einen Preis wie 0.30 US-Dollar zu tragen.

Dieselben Betriebswerte stecken in unserer Rechnung für die Schweiz. Dort rechnen wir Anschaffung, Strom, Rechenzentrum und Personal vollständig durch. Das Ergebnis steht im Beitrag über die öffentliche KI.

## Was Sie daraus für den Einkauf mitnehmen

DeepSeeks Zahlen geben einen Massstab, an dem sich ein Hoster messen lässt. Daraus ergeben sich sechs Fragen an jeden Hoster. Die Hinweise nennen DeepSeeks eigene Angaben als Vergleichswerte.[9]

01 · Cache-Ort

Liegt der Cache in den einzelnen Servern oder in einem gemeinsamen Speicher?

DeepSeek: gemeinsamer SSD-Cluster. Bei einem lokalen Cache zählt ein Treffer nur, wenn die Anfrage beim selben Server landet.

02 · Haltedauer

Wie lange bleibt ein Eintrag nach der letzten Nutzung erhalten, und steht diese Dauer im Vertrag?

DeepSeek: 3 Tage bei Agenten, 7 Tage bei Chats. Von Freitag 18 Uhr bis Montag 8 Uhr sind es rund 62 Stunden, also weniger als 3 Tage.

03 · Messung

Meldet jede Antwort, wie viele Eingabe-Tokens Treffer waren?

DeepSeek nennt im Mittel 96 Prozent. Ohne Messung pro Anfrage lässt sich kein Preis für Cache-Treffer berechnen.

04 · Aufgabenteilung

Laufen Prefill und Decode auf getrennten Servern, und wie lange müssen die langsamsten 1 Prozent der Anfragen warten?

DeepSeek: Bis zum ersten Token vergehen im Mittel 400 Millisekunden, bei P99 (den langsamsten 1 Prozent) 1'000 Millisekunden, bei Eingaben von durchschnittlich 77'000 Tokens.

05 · Tempo

Mit wie vielen gleichzeitigen Nutzern pro GPU rechnet der Preis, und welches Tempo pro Nutzer ist zugesichert?

Aus DeepSeeks Zahlen gerechnet: rund 60 Nutzer pro GPU bei 230 Tokens pro Sekunde pro Nutzer. Mehr Tempo pro Nutzer bedeutet weniger Tokens pro GPU und Sekunde.

06 · Reserve

Wie viel Reserve hält der Hoster vor, und was passiert bei einem GPU-Ausfall?

DeepSeek betreibt mehr Instanzen, als der Bedarf verlangt, und fährt keine Instanz herunter, solange die Auslastung über 0.8 liegt.

## Die Technik im Detail

Die folgenden Abschnitte zeigen, wie DeepSeek die drei Hebel (Berechnetes wiederverwenden, GPUs auslasten, den Cache sichern) technisch umsetzt: den Cache, die Tokenisierung, das Load Balancing, den Umgang mit Ausfällen und die Beschleunigung des Decodings technisch umsetzt. Sie richten sich an alle, die nachprüfen wollen, ob sich ein solcher Betrieb aufbauen lässt.

## Der Cache: Tage auf SSD, Minuten im Arbeitsspeicher

Beim Lesen der Eingabe rechnet das Modell für jedes Token Zwischenergebnisse aus, den Cache. Speichert man sie, muss das Modell sie bei der nächsten Anfrage mit demselben Anfang nicht noch einmal berechnen. Das lohnt sich vor allem bei Agenten und Chats, die bei jedem Schritt fast denselben Text erneut senden. DeepSeek teilt den Cache von Deepseek-v4.1 Flash in zwei Teile mit verschiedener Lebensdauer.[9]

|  | Block-Cache | Fenster-Cache (SWA) |
| --- | --- | --- |
| Inhalt | Zwischenergebnisse zum ganzen bisherigen Text, in Blöcken zu 128 Tokens | Zwischenergebnisse zu den letzten 128 Tokens (134 Plätze, 6 als Reserve für spekulatives Decoding), in den ersten 20 Schichten |
| Ablageort | Gemeinsamer SSD\-Cluster (3FS) | Arbeitsspeicher des Servers, der ihn erzeugt hat, nur eine Kopie |
| Haltedauer | 3 Tage (Agenten), 7 Tage (Chat) | rund 180 Sekunden |
| Zugriff | Jeder Server | Der erzeugende Server, andere über ein 400-Gigabit-Netz |
| Treffer | Entscheidet, wie viel wiederverwendet wird | Über 98 %, entscheidet, ob der letzte Block neu gerechnet werden muss |

### Der Block-Cache auf dem gemeinsamen Speicher

Den Block-Cache legt DeepSeek ausschliesslich auf einem gemeinsamen Cluster aus SSDs ab. Das hat drei Vorteile. Jeder Prefill-Server kann auf jeden gespeicherten Anfang zugreifen. Speicher und Rechenleistung lassen sich unabhängig voneinander ausbauen. Und fällt ein Server aus, geht kein Cache verloren. Server fallen nach DeepSeeks Angabe mehr als zehnmal so oft aus wie Speicher. Der Cluster fasst rund 110 Petabyte (110’000 Terabyte) und ist auf zufällige Zugriffe auf Blöcke von rund 115 Kilobyte ausgelegt. Der Cluster liest mit Spitzen von rund 11 Terabyte pro Sekunde und schreibt mit rund 910 Gigabyte pro Sekunde.[9]

Den Cache schreibt der Decode-Server. Deshalb lässt sich auch das wiederverwenden, was das Modell selbst geschrieben hat: Im nächsten Zug eines Agenten ist die letzte Antwort Teil der Eingabe.[9]

Die Haltedauer hängt von der Verkehrsart ab. Agenten-Verkehr behält DeepSeek 3 Tage, Chat-Verkehr 7 Tage. Mit 3 Tagen statt 7 würde der Chat-Verkehr nach DeepSeeks Angabe 0.5 bis 1 Prozent Trefferquote verlieren. Die Tabelle in DeepSeeks Beitrag nennt allgemein 72 Stunden.[9]

Wird ein gespeicherter Anfang gefunden, läuft das Laden in drei Stufen ab, und nur die erste hält die Anfrage auf. Erstens sucht der Entrypoint den längsten gespeicherten Anfang, bevor er die Anfrage weiterreicht. Zweitens kopiert ein separater Prozess die Daten vom SSD-Cluster in den Arbeitsspeicher des Servers. Drittens schiebt die Engine sie Schicht für Schicht in den Grafikspeicher, während die GPU schon rechnet. Dafür nutzt DeepSeek GPUDirect RDMA, einen Direktzugriff der Netzwerkkarte auf den Grafikspeicher. Der übliche Kopiermechanismus der GPU verarbeitet kleine Blöcke schlecht, RDMA lastet die Anbindung dagegen aus, ohne Rechenwerke der GPU zu belegen.[9]

Der Cluster schützt die Daten durch Erasure Coding im Verhältnis 10 zu 2: Zu 10 Datenteilen kommen 2 Prüfteile, und der Ausfall von zwei Knoten kostet keine Daten. Beim Lesen fragt das System 11 Knoten gleichzeitig an und baut die Daten aus den ersten 10 Antworten wieder zusammen. Auf jedem Knoten räumt ein Hintergrundprozess die am längsten ungenutzten Einträge weg, damit der Speicher unter einer Obergrenze bleibt.[9]

### Der Fenster-Cache im Arbeitsspeicher

Der Fenster-Cache hält den Zustand der letzten 128 Tokens. Er wird nur innerhalb einer Sitzung über wenige Minuten gebraucht, deshalb bleibt er im Arbeitsspeicher des erzeugenden Servers. Ein Verzeichnis auf den Entrypoint-Servern hält fest, welcher Server welchen Eintrag hat. Ein Eintrag wird nur bei Vielfachen von 128 Tokens gespeichert. Die Haltedauer liegt bei rund 180 Sekunden, die Trefferquote über 98 Prozent. Fehlt ein Eintrag, wird er mit Bounded Replay neu gerechnet.[9]

Block-Cache und Fenster-Cache zusammen bestimmen den Treffer. Der Block-Cache legt fest, wie viel wiederverwendet wird, der Fenster-Cache, ob der letzte Block neu gerechnet werden muss. Bei einer Eingabe der Länge L zählen höchstens L minus 134 Tokens als Treffer. Fehlt der Fenster-Eintrag, fällt der Treffer um einen Block, also um 128 Tokens, kürzer aus.[9]

## Bounded Replay: Ein Teil des Caches wird nur noch angenähert

Bounded Replay ist die wichtigste Änderung am Cache von V4 zu V4.1. Bei V4 lag auch der Fenster-Cache auf dem SSD-Speicher. Fehlte ein Eintrag, rechnete das System ihn exakt nach, und der Aufwand wuchs mit der Zahl der Schichten mal der Fenstergrösse in Tokens. Der Fenster-Cache belegte fast die Hälfte des dauerhaften Speichers, obwohl er nur Minuten lang wiederverwendet wurde, der Block-Cache dagegen Tage. Diese Ablage rechnete sich vor allem bei kurzen Chats nicht. Die im V4-Bericht erwogene Alternative, den Fenster-Cache gar nicht zu speichern und immer exakt nachzurechnen, war im Betrieb zu teuer.[9]

Fehlt ein Fenster-Eintrag, rechnet V4.1 nur die letzten 128 Tokens neu und begrenzt dabei die Aufmerksamkeit des Modells auf diesen Abschnitt. Der Fenster-Cache ist dadurch nur angenähert, kostet aber immer gleich viel, unabhängig von Textlänge und Schichtzahl. Exaktes Nachrechnen hätte 20 Schichten über die letzten 2’560 Tokens verlangt. Dass nur noch 128 Tokens nachgerechnet werden, halbiert nach DeepSeeks Angabe den gesamten Rechenaufwand beim Prefill.[9]

Bei einer Näherung kann sich die Antwort von jener unterscheiden, die ohne Cache entstünde. Wie gross dieser Unterschied ist, wissen wir nicht, denn uns ist keine Messung bekannt. Von aussen sehen Sie als Käufer nicht, ob Ihr Hoster eine solche Näherung einsetzt. Fragen Sie ihn, ob er den Cache exakt oder angenähert wiederherstellt.

## Was sonst noch im Betrieb steckt

### Tokenisierung als Sicherheitsfrage

Recipe, der Baustein für die Tokenisierung, nimmt Anfragen in den drei gängigen Formaten (Chat Completions, Responses und Messages) entgegen und wandelt sie in ein gemeinsames Gesprächsformat um. Daraus baut sie je nach Modellversion den Prompt und die Tokens. Die Ausgabe zerlegt Recipe in Ereignisse für Fliesstext, Denkschritte und Werkzeugaufrufe und gibt diese im jeweiligen Streaming-Format zurück. DeepSeek hat Recipe in Rust geschrieben und als `deepseek-recipe` veröffentlicht, damit Drittanbieter dasselbe Verhalten wie die offizielle API bekommen.[9]

Dahinter steckt ein Sicherheitsproblem. Steuer-Tokens markieren Rollen, Denkgrenzen und Werkzeugaufrufe. Tippt ein Nutzer so etwas wie `<｜User｜>` in sein Textfeld, darf es nicht als Steuerzeichen wirken. Recipe merkt sich beim Bauen des Prompts, wo Steuer-Tokens stehen, und tokenisiert Nutzertext, der wie ein Steuer-Token aussieht, als gewöhnlichen Text. In der Ausgabe erkennt es das Ende der Denkphase und die Werkzeug-Markierungen an der Token-Nummer, damit ein Modell sie nicht mit normalen Tokens nachschreiben und auslösen kann. Bei Agenten mit Werkzeugzugriff kann ein eingeschleustes Steuerzeichen einen Werkzeugaufruf auslösen.[9]

Weil die Stellen der Steuer-Tokens bekannt sind, kann Recipe lange Eingaben zerlegen und die Stücke dazwischen parallel tokenisieren. Das senkt die Zeit bei langen Anfragen.

### Load Balancing: Vier Load Balancer für gleiche Arbeit

Ein Load Balancer verteilt Arbeit auf Server und GPUs. Damit alle GPUs ähnlich viel Arbeit haben und keine auf die langsamste wartet, betreibt DeepSeek vier davon.[9]

| Load Balancer | Was er ausgleicht | Wie |
| --- | --- | --- |
| Prefill | Nicht gecachte Tokens und Länge des schon berechneten Anfangs | Kostenmodell für die Aufmerksamkeit, Längenklassen (bis 16’000, bis 64’000, bis 256’000, darüber), pro Schritt ein Zeitbudget, aus dem der grösste passende Stapel folgt |
| Decode | Anzahl der Anfragen und Summe der Cache-Längen | Kurze Anfragen zu GPUs mit wenigen Anfragen, aber langem Gesamt-Cache, lange Anfragen zu GPUs mit kurzem |
| Bild-Encoder | Bildteile in Arbeit | Zufälliger Server, dort die GPU mit den wenigsten Teilen |
| Experten | Last der beliebten Experten | Reserve-Kopien beliebter Experten, regelmässige Umverteilung |

Der Prefill-Load-Balancer muss Anfragen nicht zum Server mit dem gespeicherten Anfang lenken, weil der Cache gemeinsam liegt. Bei einem lokalen Cache müssen Sitzungen dagegen immer wieder auf denselben Server zurückkehren (dritter Teil).

Beim Ausgleich der Experten misst DeepSeek, wie oft jeder Experte gebraucht wird. Beliebte Experten erhalten Reserve-Kopien auf anderen GPUs, die regelmässig neu verteilt werden. Beim Prefill sind es 4 Reserve-Experten pro GPU, gemessen über 100 Schritte und neu verteilt alle 1’000 Schritte. Beim Decode ist es 1 Reserve-Experte pro GPU: 384 Experten plus 64 Reserve-Kopien ergeben auf 64 GPUs 7 Experten pro GPU, gemessen über 1’000 Schritte und neu verteilt alle 10’000 Schritte. Die langsamste GPU braucht danach im Verhältnis zum Mittel 1.032-mal (2 GPUs), 1.062-mal (4 GPUs) und 1.090-mal (64 GPUs beim Decode) so lang. Weil jeder Schritt auf die langsamste GPU wartet, liegen damit rund 3, 6 und 8 Prozent der GPU-Zeit brach (unsere Rechnung).[9]

### Ausfälle: Reserve und Umleitung

Das Verhältnis von Prefill- zu Decode-Servern passt sich dem Verkehr an. DeepSeek skaliert Prefill nach der Zahl der nicht gecachten Tokens und Decode nach der Zahl der aktiven Anfragen, mit Obergrenzen und Untergrenzen. Fährt ein Decode-Server herunter, hat er eine Minute Zeit. Anfragen, die danach noch laufen, werden samt ihrem Cache auf andere Server verschoben.[9]

Für Ausfälle setzt DeepSeek auf Reserve und Umleitung, weil ein Neustart Minuten dauert. Betriebsbereite Server warten im Leerlauf, und es laufen immer mehr Instanzen, als der Bedarf verlangt. Ein Herunterfahren ist gesperrt, solange die Auslastung über 0.8 liegt. Bei grossem Expert Parallelism legt eine defekte GPU die ganze Instanz lahm, weil jede GPU Experten hält, die alle anderen brauchen. Beim Neustart baut die Plattform die Instanz deshalb mit den verbleibenden gesunden GPUs neu auf. Wie sich die Reserve auswirkt, zeigt der P99-Wert für die Zeit bis zum ersten Token: Bei DeepSeek liegt er bei 1’000 Millisekunden, dem Zweieinhalbfachen des Mittels von 400 Millisekunden.[9] Bei einem Hoster ohne Reserve steigt dieser Wert bei Lastspitzen zuerst. Das ist unsere Einschätzung.

### Decode beschleunigen und Format erzwingen

Beim spekulativen Decoding schlägt ein kleines Entwurfsmodell mehrere Tokens vor, und das grosse Modell prüft sie in einem Schritt. DeepSeek nutzt dafür ein Verfahren namens DSpark. Das Entwurfsmodell schlägt 5 Tokens vor, ein Zusatzteil schätzt für jedes, wie wahrscheinlich das grosse Modell es übernimmt, und das System prüft nur so viele Tokens, wie nach den gemessenen Kurven der Hardware den besten Durchsatz ergeben. Im Betrieb übertraf das die Variante, immer alle 5 Tokens zu prüfen, um 6 Prozent.[9]

Jeder Schritt beim Decode besteht aus Planen, Rechnen, Auswählen des nächsten Tokens und Nachbearbeiten. Planen und Nachbearbeiten laufen auf der CPU, und das Nachbearbeiten braucht das Ergebnis des Auswählens. Ohne Überlappung stünde die GPU still, während die CPU plant und nachbearbeitet. DeepSeek überlappt die Schritte deshalb: Während die GPU Schritt N rechnet, plant die CPU Schritt N+1 und bearbeitet Schritt N minus 1 nach.

Für Formate wie JSON-Schema, reguläre Ausdrücke oder Grammatiken übersetzen separate Server die Vorgabe vorab in einen Automaten. Bei jedem Schritt sperrt er die Tokens, die nicht erlaubt sind. Wer ein Modell Formulare oder Datenbankabfragen in festem Format ausfüllen lässt, nutzt genau diese Funktion.

## Was DeepSeek veröffentlicht und was nicht

DeepSeek hat mit dem Beitrag die Engine **DeepInfer** veröffentlicht. Sie unterstützt verteilte Inferenz, spekulatives Decoding, Bounded Replay und strukturierte Ausgabe und läuft auf NVIDIA-GPUs und Huawei Ascend. Hinzu kommen `deepseek-recipe`, die schon früher veröffentlichte GPU-Sprache TileLang und mehrere Kernel-Bibliotheken. Der Inferenz-Code künftiger Modelle soll ebenfalls in DeepInfer landen.[9]

Nicht vollständig offen sind die Verwaltung des Caches und das Load Balancing. Beide sind an interne Infrastruktur gebunden, der Beitrag beschreibt nur, wie sie arbeiten.[9] Cache-Verwaltung und Load Balancing haben wir im dritten Teil dieser Serie als Aufgabe des Hosters beschrieben. Ein Schweizer Hoster, der V4.1 Flash so betreiben will, bekommt die Engine, muss die Cache-Schicht und das Load Balancing aber selbst bauen oder einkaufen. Das ist unsere Einschätzung.

DeepSeek nennt drei Entwurfsziele. Das System soll auf GPUs mehrerer Hersteller gut laufen, ebenso auf gängiger Hardware (8-GPU-Server für Prefill, Supernodes mit 64 bis 128 GPUs für Decode), und es soll den Cache mindestens 72 Stunden halten. Die Speicherkosten sind dabei von Anfang an eingeplant.[9]

Dieser Beitrag bewertet die Technik. Für Personendaten gelten die Massstäbe unserer Beiträge zu revDSG und souveräner KI unverändert.

## So starten Sie

Nehmen Sie die sechs Fragen in Ihr nächstes Gespräch mit einem Hoster mit, und lassen Sie sich die Antworten schriftlich geben. Messen Sie ausserdem die Cache-Trefferquote Ihres eigenen Agenten mit dem Test aus dem zweiten Teil der Serie. So sehen Sie, welcher Anteil Ihrer Eingabe überhaupt wiederkehrt.

DeepInfer und Expert Parallelism auf 64 GPUs sind für Hoster mit vielen Kunden gebaut. Für einen eigenen Server mit einer bis acht GPUs gelten dieselben Zusammenhänge in kleinerem Massstab. Dann sind die Stapelgrösse und das Prefix-Caching der Server-Software die Stellschrauben.

Sie wollen wissen, welche Anforderungen an Cache, Tempo und Reserve zu Ihrem Einsatz passen, bevor Sie einen Hoster wählen?

[KI-Architektur & Lösungsauswahl](https://souverana.ch/leistungen/ki-architektur/)

## Quellen

[1] DeepSeek. «DeepSeek V4.1 Flash, large-scale inference deployment in practice». Zhihu. 20. Oktober 2026. Eigenangabe von DeepSeek.

Der Autor

Joel Barmettler

KI-Architekt · Souverana, Zürich

Joel Barmettler begleitet Schweizer Unternehmen von der KI-Strategie bis zur Integration: souverän, vertraulich und produktionsreif. Er hat den Swiss AI Hub als Architekt aufgebaut und trägt heute Mitverantwortung für dessen Architektur; jedes Souverana-Mandat führt er persönlich. Mandate vom Einzelunternehmen bis zum Fortune-500-Konzern.

[Erstgespräch buchen](https://meet.brevo.com/joel-barmettler/30-minute-meeting) [Mehr über Souverana](https://souverana.ch/) [LinkedIn](https://www.linkedin.com/in/joel-barmettler-b9ab361b7)

## Häufige Fragen

Wie unterscheidet sich DeepSeeks Ansatz von dem der US-Labore?

DeepSeek optimiert auf die Kosten pro Token: ein Modell, das pro Token nur einen Teil seiner Parameter rechnet, ein Cache mit 96 Prozent Trefferquote und getrennte Server für Prefill und Decode. Die US-Labore setzen auf immer grössere Modelle und bauen dafür Rechenzentren. OpenAI plant bis 2030 nach einem Bericht von Reuters mit rund 600 Milliarden US-Dollar für Rechenleistung und schreibt nach Medienberichten Verluste.

Ist DeepSeek transparenter als OpenAI?

Beim Betrieb ja, bei den Trainingsdaten nein. DeepSeek veröffentlicht Gewichte, Engine und Betriebszahlen, nicht aber die Trainingsdaten. Im Foundation Model Transparency Index der Stanford University vom Dezember 2025 erreicht DeepSeek 32 von 100 Punkten, der Mittelwert über 13 Firmen liegt bei 41.

Warum trennt DeepSeek Prefill und Decode auf verschiedene Server?

Prefill verarbeitet die Eingabe, Decode erzeugt die Antwort Token für Token, und die beiden Aufgaben belasten die Hardware unterschiedlich. Prefill ist rechenbegrenzt und sättigt eine GPU schon bei Stapeln von rund 32'000 Tokens. Decode ist speicherbegrenzt und wird effizient, wenn viele Anfragen gleichzeitig laufen. DeepSeek betreibt V4.1 Flash deshalb mit 2 bis 8 GPUs für Prefill und 64 bis 128 GPUs für Decode (Eigenangabe, 20. Oktober 2026).

Wie lange hält DeepSeek den Cache von V4.1 Flash?

Laut DeepSeek (Beitrag vom 20. Oktober 2026) bleibt der Cache bei Agenten-Verkehr 3 Tage, bei Chat-Verkehr 7 Tage erhalten, gerechnet ab der letzten Nutzung. Er liegt auf einem gemeinsamen SSD-Cluster von rund 110 Petabyte (110'000 Terabyte). Ein zweiter, kurzer Cache (Fenster-Cache) für die letzten 128 Tokens bleibt nur etwa 180 Sekunden im Arbeitsspeicher.

Ist die Software hinter DeepSeeks Betrieb offen?

Zum Teil. DeepSeek hat die Inferenz-Engine DeepInfer (läuft auf NVIDIA-GPUs und Huawei Ascend), die Komponente deepseek-recipe für die Tokenisierung und die GPU-Programmiersprache TileLang veröffentlicht. Die Verwaltung des Caches und das Load Balancing sind an interne Infrastruktur gebunden und nicht vollständig offen. Der Beitrag beschreibt, wie die Cache-Verwaltung und das Load Balancing funktionieren.

Was bedeutet eine Cache-Trefferquote von 96 Prozent?

Von 100 Eingabe-Tokens muss die GPU nur 4 neu rechnen, die anderen 96 liefert der Cache. Bei DeepSeek V4.1 Flash verarbeitet eine GPU im Produktivbetrieb bei Eingaben von durchschnittlich 77'000 Tokens im Prefill 1.5 Millionen statt 60'000 Tokens pro Sekunde. Der Wert ist eine Eigenangabe und nicht unabhängig geprüft.

Lohnt sich diese Architektur für ein einzelnes Unternehmen?

In der Regel nicht. Decode auf 64 bis 128 GPUs und ein SSD-Cluster im Petabyte-Bereich sind für Hoster mit vielen Kunden gebaut. Für einen eigenen Server mit einer bis acht GPUs gelten dieselben Zusammenhänge in kleinerem Massstab: Die Stapelgrösse und das Prefix-Caching der Server-Software sind dort die Stellschrauben.

## Glossar

-   **GPU**: Grafikprozessor. Sprachmodelle laufen fast nur auf GPUs, weil diese sehr viele Rechenschritte gleichzeitig ausführen.
-   **Token**: Die kleinste Verrechnungseinheit eines Sprachmodells; ein Wort besteht aus etwa ein bis drei Tokens. Anbieter verrechnen pro Million Tokens, getrennt nach Eingabe (Input) und Ausgabe (Output).
-   **Open Weight**: Modelle, deren Gewichte öffentlich verfügbar sind und selbst gehostet werden dürfen (z.B. Apertus, DeepSeek, Llama). Voraussetzung für souveränen Betrieb ohne Anbieterbindung.
-   **API**: Eine Programmierschnittstelle, über die Software ein Sprachmodell direkt anspricht, ohne Chat-Oberfläche. Abgerechnet wird meist pro Token.
-   **Inferenz**: Der laufende Betrieb eines trainierten Modells: Anfrage hinein, Antwort heraus. Inferenz ist das, was Sie bei einem Hoster pro Token einkaufen.
-   **Parameter**: Die gelernten Zahlenwerte eines Sprachmodells. Ihre Anzahl beschreibt die Grösse: «8B» heisst acht Milliarden Parameter. Grössere Modelle können mehr, brauchen aber mehr Grafikspeicher.
-   **MIT-Lizenz**: Eine sehr freizügige Open-Source-Lizenz: Software oder Modellgewichte dürfen frei genutzt, verändert und weitergegeben werden, auch kommerziell.
-   **Load Balancer**: Eine Komponente, die Anfragen so auf die vorhandenen GPUs und Server verteilt, dass keine überlastet ist und keine auf die langsamste warten muss.
-   **Cache-Treffer**: Ein Treffer heisst: Der Anfang einer Anfrage liegt schon im Cache und muss nicht neu gerechnet werden. Die Trefferquote ist der Anteil der Eingabe, der aus dem Cache kommt.
-   **Prefill**: Die erste Phase einer Antwort: Das Modell liest die ganze Eingabe in einem Durchgang und baut den KV-Cache auf, den Speicher für den bisherigen Text. Sie ist rechenintensiv, und genau sie spart das Prompt Caching.
-   **Decode**: Die zweite Phase einer Antwort: Das Modell schreibt die Ausgabe Token für Token, jedes hängt vom vorherigen ab. Das Tempo begrenzt hier die Datenbewegung im Speicher, nicht die Rechenleistung.
-   **MoE**: Mixture of Experts: ein Modell, das viele Teilmodelle («Experten») speichert, pro Token aber nur wenige davon rechnet. Gespeichert werden alle Parameter, gerechnet wird mit einem Bruchteil.
-   **Expert Parallelism**: Ein Mixture-of-Experts-Modell besteht aus vielen spezialisierten Rechenblöcken, den Experten. Beim Expert Parallelism liegen sie verteilt auf mehreren GPUs: Je mehr GPUs, desto weniger Experten pro GPU und desto mehr Speicher für gleichzeitige Anfragen.
-   **P99**: Der Wert, den 99 von 100 Anfragen unterbieten. Er zeigt die langsamen Ausreisser, die ein Mittelwert versteckt.
-   **GPU-Stunde**: Eine Stunde Rechenzeit auf einem Grafikprozessor. Das übliche Mass für den Rechenaufwand beim Training grosser Modelle.
-   **Fenster-Cache (SWA)**: Der Teil des KV-Caches, der nur die letzten 128 Tokens umfasst (Sliding Window Attention). Er bleibt nur Minuten im Arbeitsspeicher, weil er nur innerhalb einer Sitzung gebraucht wird.
-   **Spekulatives Decoding**: Ein kleines Entwurfsmodell schlägt mehrere Tokens auf einmal vor, das grosse Modell prüft sie in einem Schritt und übernimmt die richtigen. So entstehen pro Rechenschritt oft mehrere Tokens, ohne dass sich die Antwort ändert.
-   **SSD**: Schneller Flash-Speicher ohne bewegliche Teile. Schneller und teurer als Festplatten, aber deutlich günstiger als Arbeitsspeicher.
-   **RDMA**: Direkter Speicherzugriff über das Netz: Daten wandern von einem Rechner in den Speicher eines anderen oder einer GPU, ohne den Prozessor zu belasten.
-   **Erasure Coding**: Ein Verfahren, das Daten mit Zusatzinformationen auf mehrere Speicher verteilt, sodass sie nach dem Ausfall einzelner Speicher vollständig wiederherstellbar bleiben. Bei 10+2 überstehen zwei Ausfälle.
-   **Bounded Replay**: Geht ein Fenster-Cache-Eintrag verloren, rechnet das System nur die letzten 128 Tokens näherungsweise neu, statt ihn exakt aufzubauen. Der Aufwand bleibt unabhängig von der Textlänge gleich.
-   **Prompt**: Die Eingabe an ein Sprachmodell: Frage, Anweisung und mitgeschickter Text. Was im Prompt steht, bestimmt die Antwort und die Kosten.
-   **Chain of Thought**: Die Zwischenschritte, die ein Modell vor der Antwort schreibt. Sie verbessern oft die Antwort und werden als Denk-Tokens mitverrechnet.
-   **Personendaten**: Alle Angaben, die sich auf eine bestimmte oder bestimmbare Person beziehen, also Kundendaten, Personaldossiers oder auch eine E-Mail-Adresse. Sobald solche Daten im Spiel sind, gilt das revDSG.
-   **revDSG**: Das revidierte Schweizer Datenschutzgesetz, in Kraft seit dem 1. September 2023. Es regelt, wie Unternehmen Personendaten bearbeiten dürfen, und gilt für den Einsatz von KI genauso wie für jede andere Bearbeitung.
-   **Prefix-Caching**: Die Server-Software speichert bereits verarbeitete Anfänge von Anfragen. Beginnt die nächste Anfrage gleich, rechnet sie nur den neuen Teil. Das verkürzt die Wartezeit stark.