Warum DeepSeek im großen Maßstab günstig ist, lokal aber teuer

• Einige AI-Modelle wie DeepSeek-V3 sind bei der Bereitstellung im großen Maßstab günstig und schnell, bei der lokalen Ausführung jedoch langsam und teuer
• Der Grund liegt in einem grundlegenden Trade-off zwischen throughput (Durchsatz) und latency (Latenz), der mit der Effizienz der GPU-Auslastung zusammenhängt
• Wenn die Batch-Größe erhöht wird, arbeitet die GPU effizienter, aber Nutzer müssen warten, bis sich Tokens angesammelt haben, was zu höherer Latenz führt
• Modelle mit Mixture-of-Experts-Architektur und tiefer Pipeline benötigen hohe Batch-Größen und längere Latenz
• In einer lokalen Einzelbenutzerumgebung ist es schwierig, einen ausreichend großen Batch zu bilden, was zu Leistungseinbußen und höheren Kosten führt
• OpenAI, Anthropic usw. erreichen schnelle Antworten durch effizientere Architekturen, hochentwickelte Batch-Strategien oder den Einsatz übermäßig vieler GPUs

---

Batch-Inferenz und GPU-Effizienz

• GPUs sind Hardware, die für große Matrixmultiplikationen (GEMM) optimiert ist
• Werden Tokens mehrerer Nutzer auf einmal zu einer großen Matrix zusammengefasst und als Batch ausgeführt, steigt der Durchsatz wegen geringem Roundtrip-Overhead und besserer Speichereffizienz stark an
• Inferenzserver stapeln die Tokens mehrerer Anfragen in einer Queue, wählen einen Batch geeigneter Größe aus und führen große GEMM-Berechnungen aus
• Dabei muss der Server einen Trade-off zwischen Batch-Größe (mehr throughput) und Wartezeit (mehr latency) wählen

Warum einige Modelle auf große Batches optimiert sind

Mixture of Experts (MoE) und Batching

• Die MoE-Architektur (DeepSeek-V3, mutmaßlich auch GPT-4) ist ein Hauptgrund für die geringe GPU-Effizienz
• Hunderte von „Experten“-Blöcken erfordern jeweils getrennte Matrixmultiplikationen; bei kleinen Batches hat jeder Experte wenig zu tun, wodurch die Effizienz sinkt
• Erst bei vielen gleichzeitigen Anfragen können alle Experten ausreichend ausgelastet werden; auf Service-Ebene sind große Batches daher unverzichtbar
• Bei kurzer Wartezeit (Fenster 5 ms) sind Experten häufig untätig, bei langer Wartezeit (Fenster 200 ms) lässt sich maximale Effizienz erreichen

Batch-Probleme bei Modellen mit tiefer Pipeline

• Große Transformer mit Hunderten von Schichten werden über mehrere GPUs hinweg schichtweise aufgeteilt (Pipelining) ausgeführt
• Ist die Zahl der Tokens in einem Batch kleiner als die Pipeline-Schritte, entsteht ein „Pipeline-Bubble“-Effekt, der den Durchsatz verringert
• Um dies zu vermeiden, sind große Batches (also längere Wartezeiten) erforderlich, wodurch sich die Antwortzeit des Modells verlängert

Warum sich die Queue nicht immer vollständig füllen lässt

• Theoretisch scheint sich eine Bubble vermeiden zu lassen, wenn durch viel gleichzeitigen Traffic die Queue immer voll ist
• In der Praxis müssen für das Batching im Attention-Schritt von Transformern jedoch die Matrixgrößen (Längen) identisch sein, weshalb eine perfekte Umsetzung mit einer einzigen Queue schwierig ist
• Außerdem führen getrennte FFN- und Attention-Schritte zu stark steigendem Speicher-Overhead und ineffizienter Datenbewegung

Zusammenfassung und Fazit

• Die Verarbeitung großer Batches ist entscheidend, um GPU-Kosten zu senken und den Durchsatz zu erhöhen, führt für Nutzer aber zu längerer Wartezeit
• Modelle mit Mixture-of-Experts- und großer Pipeline-Architektur sind von Natur aus für hocheffiziente Batch-Umgebungen mit Wartezeit optimiert
• In Umgebungen mit wenig Traffic wie lokal lässt sich ein optimierter großer Batch nicht bilden, wodurch die GPU-Effizienz stark einbricht und die Ausführungskosten steigen
• OpenAI, Anthropic usw. zeigen schnelle Reaktionszeiten; mögliche Gründe sind:
  • (1) eine effizientere Architektur ohne MoE
  • (2) Batch-/Pipeline-Optimierung und hochentwickelte Inferenz-Tricks
  • (3) eine Architektur, die mehr GPUs als nötig einsetzt und sich Geschwindigkeit einkauft

Zusatz: Unterschied zwischen Prefill-Batching und dem hier behandelten Batching

• Bei Transformern kann auch der Prefill eines einzelnen Nutzer-Prompts (lange Eingabe) im Batch ausgeführt werden, um die anfängliche Inferenz zu beschleunigen
• Das hier behandelte Batching betrifft jedoch den eigentlichen Token-Generierungsschritt über Anfragen mehrerer Nutzer hinweg, bei dem der Trade-off zwischen Durchsatz und Latenz entsteht
• Prefill-Batching steht nicht in direktem Zusammenhang mit den im Text beschriebenen großen gleichzeitigen Batches

Hinweise

• Reale Inferenzsysteme nutzen oft zusätzlich continuous batching und führen Berechnungen aus, sobald ein Batch voll ist
• Die grundlegende Struktur des throughput-latency-Trade-offs bleibt dabei jedoch unverändert

[GN⁺]

Hacker-News-Kommentare

• Ich betreibe DeepSeek V3 selbst zu Hause und finde, dass die Kosten überschaubar sind und Geschwindigkeit sowie Leistung zufriedenstellend ausfallen. Viele denken, dass man große Modelle ohne GPU nicht betreiben kann, aber meiner Erfahrung nach sind CPU-Server praktischer und verbrauchen sogar weniger Strom. Mein Heimserver basiert auf einer EPYC-9004-Serie der Mittelklasse mit einem Supermicro-Board und 384 GB RAM; die Gesamtkosten liegen bei rund 4000 Dollar. Wenn man statt GPUs einfach viel RAM nutzt, ist der Stromverbrauch oft sogar niedriger als bei einem Gaming-Desktop. Mit dem Unsloth Dynamic GGUF-Modell werden etwa 270 GB RAM genutzt, und tatsächlich kann es mit nahezu derselben Qualität wie das Original viele verschiedene Aufgaben bewältigen. Normalerweise lasse ich es mit 16k Kontext laufen und erweitere bei Bedarf auf 24k. Die Token-Generierung liegt bei 9–10 pro Sekunde, bei großem Kontext bei etwa 7. Es gibt auch Beispiele, in denen in einer 2-CPU-Umgebung das vollständige Modell mit noch höherer Tokenrate läuft.
  • Ich frage mich, wie nahe Unsloth Dynamic GGUF in der Praxis wirklich an die Leistung des Originals herankommt. Meiner Erfahrung nach ist der Unterschied bei einfachen Aufgaben nicht groß, aber bei komplexen Aufgaben oder langem Kontext zeigt er sich deutlich. Unsloth leistet zwar hervorragende Arbeit, aber es ist schade, dass es kaum direkte Vergleichsdaten mit dem unquantisierten Originalmodell gibt. Realistisch betrachtet fehlt vielen Menschen und Unternehmen schlicht die Möglichkeit, das Originalmodell selbst zu betreiben.
  • Ich frage mich, ob es möglich ist, DeepSeek mit einem Tool wie Ollama für Codegenerierung auf einer 40-Core-CPU mit 256 GB RAM zu betreiben. Ich denke dabei an eine Speicherzuweisung von etwa 200 GB für das Modell.
  • Es wird erwähnt, dass die persönliche Website nicht erreichbar ist. Ich stelle mich als Jeff Carr, Mitgründer von DigitalOcean, vor und hoffe, Kontakt aufnehmen zu können.
  • Ich dachte, eine GPU mit sehr schnellem Speicher sei zwingend erforderlich, frage mich nun aber, ob Inferenz bei großem Speicher wirklich auch ganz ohne GPU möglich ist. Mich interessiert, wie das allein mit nicht vereinheitlichtem Speicher funktionieren kann.
  • Ich stimme zu, dass DeepSeek V3 unter den Open-Weight-Modellen tatsächlich sehr praxistauglich ist. Viele Aufgaben benötigen gar nicht so viele Reasoning-Token wie oft angenommen, und dass man nicht warten muss, ist ein großer Vorteil. Attraktiv ist auch, dass man bei Bedarf jederzeit eine höhere Reasoning-Option wählen kann. Wenn man es nicht selbst betreibt, gibt es auch einige Anbieter, die den vollständigen Kontext (16k), 80 tps und die Zusicherung bieten, die Daten nicht zu nutzen. Das Beispiel mit dem 9004-Heimserver ist eine beeindruckende Konfiguration.
• Dieser Blogbeitrag wird als beeindruckend bewertet. Dem Fazit („Batching ist nötig“) wird zugestimmt, aber die Diskussion über MoE-Modellinferenz sollte differenzierter sein. Der Grund, warum große Batches wichtig sind, liegt darin, dass LLM-Inferenz nicht durch fehlende Rechenleistung begrenzt ist, sondern dadurch, dass alle Weights aus dem VRAM geladen werden müssen. Vergleicht man die TFLOPS und die Speicherbandbreite einer H100, ergibt sich rechnerisch, dass pro Byte eigentlich Raum für 300 FLOP besteht. Je größer der Batch, desto mehr Berechnungen kann man mit jedem geladenen Parameter durchführen, daher muss die Batch-Größe maximiert werden. Daher wird der Begriff „roofline model“ verwendet. Da die Modelle immer größer werden und nicht mehr vollständig in den VRAM passen, müssen sie auf mehrere GPUs oder Nodes verteilt werden. Selbst NVLink oder InfiniBand sind nicht so schnell wie direktes Laden aus dem VRAM, wodurch ein Flaschenhals entsteht. Die Stärke von MoE liegt im Expert Parallelism, also darin, unterschiedliche Experts im Speicher verschiedener Nodes zu halten und die Kommunikation zwischen den Nodes zu minimieren. Das funktioniert allerdings nur, wenn es genug Nodes gibt, sodass alle Experts im VRAM Platz finden und gleichzeitig Overhead wie der KV-Cache getragen werden kann. Letztlich wächst die Batch-Größe dadurch zwangsläufig, und nur so können die einzelnen GPUs effizient arbeiten.
  • Es wird vorgeschlagen, verschiedene „Experts“ im Round-Robin-Verfahren auf einen Node zu verteilen und nur dann opportunistisch zu batchen, wenn mehrere Requests denselben Expert verwenden. Das entspräche einer Queue statt eines klassischen Batches, erhöht also die Latenz, wäre aber in Umgebungen wie Deep-Research-Workflows wohl noch gut tragbar.
  • Es gibt reale Beispiele, bei denen Inferenz auch dann möglich ist, wenn ein Modell nicht auf eine einzelne GPU passt, indem man es schichtweise aufteilt und kleine Vektoren an die GPU sendet, die jeweils die nächste Schicht berechnet. Bei Cerebras wird dieses Verfahren eingesetzt, um mit Llama 4 Maverick 2500 Billionen Token pro Sekunde zu erzeugen. Die Vektorübertragung über das Fabric ist so schnell, dass es praktisch kaum Idle Time gibt.
  • Es wird darüber spekuliert, ob ein deutlich schnellerer Betrieb möglich wäre, wenn alle Nodes und Weights in analogen Schaltungen angeordnet wären.
  • Eine Begründung für ein Investment in AMD sei, dass das gesamte Modell in ein einzelnes Chassis passt, was Vorteile von Map/Reduce sowie geringere Kosten für Netzwerkhardware mit sich bringt. Gegenargumente oder zusätzliche Einsichten dazu seien willkommen.
• Eine Ein-Satz-Zusammenfassung für alle, die Zeit sparen wollen: Die Antwort ist Batch-Inferenz. Dabei werden die Prompts mehrerer Personen gleichzeitig in dieselbe Modellinstanz gegeben, was in der Praxis weit effizienter ist als bloß dichtes Time-Slicing. Dadurch kann es auch bei fest eingestellter Temperatur und festem Seed vorkommen, dass Service-Antworten von Mal zu Mal unterschiedlich ausfallen, weil man nicht kontrollieren kann, mit welchen anderen Prompts der eigene zusammen gebatcht wird. Man kann sich vorstellen, dass dieses Phänomen zu einem Angriffsvektor für Datenabfluss werden könnte.
  • Einer der Vorteile von Batching ist, dass man bei der wiederholten Bewertung desselben Inhalts zum Prüfen auf tatsächliche „hallucinations“ einfach gleich batch-size-mal testen kann. Das Konzept des Batchings gab es bei LLMs eigentlich von Anfang an, aber seinen wirklichen Wert erkennt man oft erst mit der Zeit.
  • Ich bin bislang naiv davon ausgegangen, dass Anbieter bei allen Modellen immer batchen. Ich frage mich, ob das nur für bestimmte Modellfamilien gilt.
  • Ich frage mich, warum Antworten des Modells variieren, nur weil ein Prompt zusammen mit anderen Prompts gebatcht wird.
  • Wenn Prompts gemeinsam mit denen anderer Nutzer gebündelt werden können, wäre das ein äußerst wirksamer Angriffsvektor.
• Kurz zusammengefasst:<br>- Modelle mit hoher Sparsity benötigen große Batches (viele gleichzeitige Requests), damit eine einzelne Matrixmultiplikation ausreichend rechenintensiv wird<br>- Um Batches dieser Größe zu verarbeiten, braucht man etwa 8–16 GPUs, damit Modell-Weights und MLA/KV-Cache in den HBM passen. Mit 8–16 GPUs ist der Gesamtdurchsatz jedoch niedrig, sodass die Antwortgeschwindigkeit für einzelne Nutzer sehr schlecht wird. Für ein wirklich angenehmes Nutzungserlebnis wären eher rund 256 GPUs nötig.
  • Ich betreibe einen DeepSeek-Service auf 16 H100s (2 Nodes). Pro Request erreiche ich 50–80 Token/Sekunde, insgesamt stabilen Durchsatz bis in den Bereich mehrerer tausend Token. Auch die Zeit bis zum ersten Token ist stabil, und die Erfahrung ist schneller als bei jedem Cloud-Service, den wir nutzen können.
  • Es wird gesagt, hohe Sparsity bedeute, dass große Batches nötig seien, aber mir ist der Zusammenhang nicht ganz klar. Spöttisch gesagt erscheint sparse matmul doch letztlich nur wie matmul mit vielen Nullen.
• Es wird als hervorragende Erklärung aus LLM-Perspektive gelobt. Es wird vermutet, dass Hyperscale-LLM-Unternehmen ihre tatsächlichen Compute-Traces im Detail analysieren, Flaschenhälse finden und Workloads mit Load Balancern, Pipeline-Architekturen und Schedulern konsequent optimieren. Die „Batch-Voraussetzung“ für Effizienz kann für sicherheitskritische Anwendungen jedoch nachteilig sein, weil Query-Isolation extrem teuer wird. nVidias vGPU-Virtualisierung teilt den GPU-Speicher zeitlich auf, erfordert aber vermutlich bei jedem Context Switch ein Unload/Reload ohne Deduplizierung. Auch MIG teilt den Speicher fest pro Nutzer auf, und für eine Neukonfiguration muss die GPU neu gestartet werden; gut nachvollziehbar, dass man eine 96-GB-GPU nicht gern in 4x24 GB aufteilen möchte. Es wird darüber spekuliert, ob man durch zusätzlichen Sekundärspeicher (DRAM) auf dem GPU-Board verschiedene Matrixdaten schneller als über PCIe laden könnte, wobei HBM als Cache fungieren würde.<br>Die offene Schreibweise in Software Engineering survival guide wird ebenfalls gelobt.
• Es wird die Meinung geäußert, dass es für DeepSeek noch viel Spielraum für Software-Optimierung gibt. In der Praxis sind bisher vor allem zwei auf Zugänglichkeit ausgerichtete Systemtypen optimiert: kleine GPUs mit viel RAM (ktransformers) oder Systeme mit enorm viel VRAM. Eine Struktur mit 192 GB VRAM plus normalem Hauptspeicher für den Rest (DGX Station, 2xRTX Pro 6000 usw.) könnte dank der MoE-Eigenschaften selbst DeepSeek 4bit ziemlich schnell ausführen. Bei DeepSeek werden ohne chinesische Prompts die meisten Experts gar nicht aktiviert. Dadurch wird auch Pruning einfacher. Zukünftige Enthusiast-Systeme könnten gut zu solchen Software-Optimierungen passen. Auf Reddit gibt es außerdem Beispiele für ein 16x3090-System (PCIe 3.0 x4), das in llama.cpp rund 7 Token pro Sekunde erreicht, und selbst eine einzelne 3090 kann ihren gesamten VRAM 39-mal pro Sekunde scannen, weshalb es offenbar noch andere Performance-Flaschenhälse gibt.
  • Ein 16x3090-System verbraucht ganze 5 kW. Rechnet man die Stromkosten ein, ist eine API wahrscheinlich günstiger. Wenn bei DeepSeek ohne chinesische Prompts viele Experts ohnehin nicht aktiviert werden, liegt die Vorstellung nahe, das Modell zu verschlanken und Tokens gezielter an naheliegendere Experts zu routen.
  • Eine einzelne MI300x kann 192 GB VRAM bereitstellen.
• Vorweg: Ich bin weder ML-Forscher noch Ingenieur, also bitte entsprechend einordnen. DeepSeek V3/R1 ist im Vergleich zu bisherigen lokalen Modellen so groß, dass lokaler Betrieb tatsächlich teuer ist. Die aktivierten Parameter sind zwar weniger als die Gesamtgröße, aber das reduziert nur den Rechenbedarf, nicht den Speicherbedarf. In der Praxis ist sinnvolle Nutzung ohne riesige GPUs für die meisten daher kaum möglich. Ein direkter Vergleich mit führenden proprietären Modellen ist ebenfalls nicht möglich, weil Informationen wie ihre Größe nicht veröffentlicht werden. Es gibt auch keinen klaren Grund für die Annahme, dass diese Modelle lokal günstiger laufen würden. Im Gegenteil: Für lokale oder Single-User-Szenarien bietet MoE passendere Trade-offs, weil die Ineffizienz von Batching dort weniger ins Gewicht fällt. Vergrößert man den Batch, steigt zwar die Wartezeit pro Token auf bis zu 200 ms, aber dafür wird die Feed-Forward-Berechnung (GEMM) größer und damit effizienter. Ich frage mich, ob mit größerem Batch tatsächlich die Matrix selbst größer wird. Mein mentales Modell ist eher, dass Batching nicht dazu dient, die „Eingabematrix zu vergrößern“, sondern die Begrenzung von Speicherbandbreite hin zu einem Compute-Flaschenhals zu verschieben. Die Weights werden ja ohnehin schichtweise in Stücke zerlegt und von HBM nach SRAM geladen, dann stückweise multipliziert und am Ende zusammengeführt. Der Vorteil des Batchings wäre also, mit denselben Weights mehrere Berechnungen gleichzeitig auszuführen und so die FLOPS effizient auszulasten. Ich bin außerdem nicht ganz überzeugt, dass große Modelle von OpenAI, Anthropic usw. tatsächlich so schnell antworten, da dem Blogbeitrag konkrete Werte zur Time to First Token fehlen.
  • Ich bin der Autor des Originalposts. Ich bin kein ML-Forscher, sondern ein interessierter Ingenieur. Im lokalen Single-User-Szenario mit MoE fehlt der Vorteil von Multi-User-Batching, weshalb der Durchsatz pro GPU drastisch sinkt. So ist es jedenfalls, solange man nicht eine enorme Zahl paralleler Inferenzanfragen hat. Wenn man durch Batching die Eingabematrix vergrößert, hat man bei Batch 1 eine 1xdim-Matrix; bei größerem Batch wird daraus batch-size x dim, und die GPU-Auslastung steigt stark an, sodass sich der Flaschenhals in Richtung Compute verschiebt. Und ja, dass DeepSeek im Vergleich zu anderen Modellen langsamer ist, merkt man deutlich, wenn man es viel verwendet.
• Für Mixture of Experts braucht man große Batches, aber auf Apple Silicon scheint es auch mit Batch-Größe 1 noch brauchbar zu sein. Dank Unified Memory lassen sich große Modelle lokal ausführen, allerdings bei geringerer Bandbreite und weniger FLOPS, sodass die Ausführung relativ langsam bleibt. MoE hat die Eigenschaft, dass bei jedem Schritt weniger Parameter verarbeitet werden müssen, wodurch der Rechenaufwand sinkt. Es gibt etliche Erfahrungsberichte von Leuten, die DeepSeek auf dem Mac mit Single-Batch-Inferenz in brauchbarer Geschwindigkeit betreiben. Natürlich bleibt der Anschaffungspreis hoch, wenn man genügend Speicher verbauen will. Wenn künftig mehr Maschinen wie der Mac oder mit ähnlicher Architektur erscheinen, könnten sie hervorragend zu MoE-Modellen passen. Im Vergleich dazu ist das Ausführen dichter Modelle auf einem Mac mit großem RAM-Upgrade deutlich schmerzhafter.
• Nach Gesprächen mit Kollegen kam ich zu dem Schluss, dass sich LLMs für Programmierunterstützung womöglich in eine Richtung entwickeln, die von den eigentlichen Optimierungszielen wegführt. Aufgrund interner Richtlinien vergleiche ich bei fast allen Aufgaben lokale 4–30B-Modelle mit mehreren GPT-Serien. Vor allem GPT-4o liefert im Durchschnitt hervorragende Ergebnisse, neigt aber auch dazu, „Teile der Antwort zu erfinden“, was viel Zeit für Verifikation und Iteration kostet. Am Ende habe ich den Eindruck, dass der Unterschied zu lokalen Modellen mit wenigen Parametern gemessen am Aufwand kleiner ist als erwartet. Das Problem ist, dass beide wirklich langsam sind und dadurch schnelle Iteration unmöglich wird. Für mich wäre ein großes Kontextmodell mit etwas geringerer Qualität, aber blitzschnellen, sofortigen Antworten deutlich angenehmer. Wichtiger als reine Verbesserungen bei Qualitätsmetriken wäre ein höheres „gefühltes Iterationstempo“.
• Ich widerspreche der Aussage „langsam und teuer“. Selbst auf älteren Workstations mit DDR4-Speicher und mit llama.cpp kann ein System für etwa 1000 Dollar noch 3 Token pro Sekunde liefern.
  • Möglicherweise verwechselst du das mit einer destillierten Version und nicht mit dem eigentlichen DeepSeek-Modell. Ohne mindestens 192 GB RAM lässt sich das echte Modell nicht ausführen.