Beam und DeepSeek-V4.1-Flash im eigenen Rack: was die 500B-Klasse an Speicher wirklich kostet

/01Was im Oktober erschienen ist

Ein offenes Modell der 500-Milliarden-Klasse passt in keinen Server, der heute in einem mittelständischen Serverraum steht. Reflection Beam braucht in der kleinsten offiziellen Fassung 293,65 GB, DeepSeek-V4.1-Flash-1017 im veröffentlichten Format 510,31 GB — beides vor dem ersten Token Kontext. Was das für die Beschaffung heißt, steht in diesem Artikel; zuerst die Nachricht.

Innerhalb von zwei Wochen sind zwei Mixture-of-Experts-Modelle dieser Größe mit offenen Gewichten erschienen:

• 5. Oktober 2026: Reflection kündigt Beam an, ein Sprachmodell mit 501 Milliarden Parametern gesamt und 23 Milliarden aktiv, Gewichte unter Apache 2.0 „later this month". Das Repository auf Hugging Face ist auf den 7. Oktober datiert, die FP8- und NVFP4-Fassungen auf den 10. Oktober, der Beitrag „Beam is now available" auf den 16. Oktober.
• 10. September 2026: DeepSeek veröffentlicht V4.1-Flash unter MIT-Lizenz, mit Bild- und Texteingabe und einem Kontextfenster von einer Million Token.
• 17. Oktober 2026: DeepSeek legt mit V4.1-Flash-1017 ein „minor update" nach, laut Modellkarte mit deutlichen Zuwächsen bei Reasoning, Coding und Agentenaufgaben bei kürzeren Ausgaben.

Beide Modelle stehen damit unter Lizenzen ohne Nutzerschwelle, ohne Umsatzgrenze und ohne Namenspflicht. Das unterscheidet sie von Modellen mit Hauslizenz, deren Fallen wir im Lizenzvergleich für Open-Weight-Modelle durchgegangen sind. Hier ist die Lizenz der einfache Teil. Der schwierige Teil ist der Speicher, und um ihn geht es ab Abschnitt /03. Die Grundlagen aus dem Frühjahr — was V4 ausmacht und warum die MIT-Lizenz zählt — stehen in DeepSeek V4 On-Premise; dieser Artikel setzt dort an, wo das neue Modellpaar die Rechnung verschiebt.

/02Die Modellkarten und ihre Widersprüche

Wer eine Beschaffung auf eine Modellkarte stützt, sollte wissen, an welchen Stellen sie sich selbst oder den Metadaten widerspricht. Bei diesem Paar gibt es zwei solche Stellen und eine Lücke.

Beam: vollständige Architektur, keine Hardwareangabe

Die Karte von Beam ist in der Architektur präzise: 501,3 Milliarden Parameter, 23,4 Milliarden aktiv, 52 Schichten (3 dicht, 49 MoE), 256 Experten, davon 8 je Token, Gated GQA mit Attention über ein Fenster von 512 Token in den meisten Schichten, 1M Kontext, Wissensstand 30. Juni 2026. Die Konfigurationsdatei ergänzt, was die Karte weglässt: 48 Abfrage- und 8 Schlüssel-/Wert-Köpfe mit Kopfdimension 128, davon 9 Schichten mit voller und 43 mit Fenster-Attention. Was fehlt, ist jede Aussage zur Hardware. Weder Karte noch Blog nennen GPU-Typ oder -Zahl; der Beitrag vom 16. Oktober sagt nur, Reflection selbst betreibe die Inferenz mit SGLang auf Blackwell. Als Engines nennt er Transformers, vLLM, SGLang, TokenSpeed und Dynamo — ohne Versionsnummern.

Eine zweite Lücke betrifft die Sprache. Die Karte schreibt wörtlich, Beam sei „developed predominantly for English". Für ein Haus, dessen Dokumente, Tickets und Verträge deutsch sind, ist das kein Ausschlusskriterium, aber eine Prüfpflicht vor jeder Beschaffung.

DeepSeek: 552 oder 763 Milliarden?

Die Karte von V4.1-Flash nennt 552 Milliarden „backbone parameters", 8 Milliarden aktiv beim Einlesen (Prefill) und 16 Milliarden beim Erzeugen (Decode). Die Hugging-Face-Metadaten desselben Repositories zählen 763,2 Milliarden. Die Karte zum Update 1017 nennt gar keine Parameterzahl. DeepSeek klärt den Unterschied nicht auf. Unsere Lesart, ausdrücklich als solche gekennzeichnet: Die Karte beschreibt neben dem Backbone einen „Engram"-Speicher mit 196 Milliarden Parametern, der per Token-Nachschlag spärlich gelesen wird; dazu kommen Bild-Encoder und die Schichten des DSpark-Drafters. 552 plus 196 ergibt 748 — nahe an den 763 der Metadaten. Für die Hardware ist der Streit ohnehin zweitrangig. Maßgeblich ist, was auf der Platte liegt: 510,31 GB für V4.1-Flash-1017, mit FP8-Gewichten und FP4-Experten.

Ein weiterer Punkt, der im Betrieb Zeit kostet: DeepSeek liefert kein Jinja-Chat-Template mit. Die Prompt-Kodierung steht als Python-Referenz (encoding.py) und als Rust-Bibliothek „deepseek-recipe" bereit. Wer das Modell hinter einen OpenAI-kompatiblen Endpunkt stellen will, muss diese Kodierung in die Serving-Engine bringen — eine Aufgabe, die es bei Beam nicht gibt.

/03Die Speicherrechnung: Gewichte und KV-Cache

Der Grafikspeicher muss drei Posten tragen: die Gewichte, den KV-Cache für alle gleichzeitigen Sitzungen und einen Laufzeitpuffer. Bei der 500B-Klasse verschiebt sich das Verhältnis gegenüber kleinen Modellen deutlich: Die Gewichte dominieren, der Cache ist dank sparsamer Attention vergleichsweise klein.

Gewichte nach Präzision

Der Unterschied zwischen den Beam-Fassungen ist in den Herstellerzahlen klein. Reflection veröffentlicht Benchmarks für alle drei Präzisionen: SWE-bench Verified 81,6 % (BF16), 80,2 % (FP8) und 80,7 % (NVFP4), Terminal Bench v2.1 80,1 %, 78,9 % und 78,4 %. Das sind Herstellerangaben mit Herstellersampling. Sie zeigen trotzdem, warum die NVFP4-Fassung die naheliegende Betriebsfassung ist: rund 30 % der BF16-Größe bei einem Abstand von ein bis zwei Punkten. Wie 4-Bit-Formate auf Blackwell funktionieren, steht in NVFP4 auf Blackwell.

KV-Cache: unsere Rechnung für Beam

Beam speichert Schlüssel und Werte nur in den 9 Schichten mit voller Attention über den ganzen Kontext; die 43 Fensterschichten halten je Sitzung höchstens 512 Token. Daraus folgt eine einfache Rechnung — unsere eigene, aus der Konfigurationsdatei abgeleitet, nicht vom Hersteller:

# Beam, KV-Cache in BF16 (2 Byte), eigene Rechnung aus config.json
# volle Schichten x KV-Köpfe x Kopfdimension x (K+V) x Byte
9 x 8 x 128 x 2 x 2            =  36.864 Byte je Token

  32.768 Token  x 36.864 Byte  ≈   1,2 GB je Sitzung
 131.072 Token  x 36.864 Byte  ≈   4,8 GB je Sitzung
1.048.576 Token x 36.864 Byte  ≈  38,7 GB je Sitzung

# Fensterschichten, fest je Sitzung:
43 x 512 x 8 x 128 x 2 x 2     ≈  90 MB

# mit --kv-cache-dtype fp8 halbieren sich alle Werte

Acht parallele Sitzungen mit je 128.000 Token kosten damit rund 39 GB in BF16 — weniger als ein Achtel der NVFP4-Gewichte. Bei einem dichten Modell derselben Größe sähe das anders aus. Die Methode dahinter erklärt KV-Cache verstehen.

KV-Cache bei DeepSeek: eine Herstellerzahl

DeepSeek nennt für V4.1-Flash einen globalen KV-Cache von 890 Byte je Token, erreicht durch komprimierte, spärliche Attention und FP4-Cache. Hochgerechnet sind das rund 117 MB für 128.000 Token und rund 0,9 GB für eine volle Million — wieder unsere Rechnung auf Basis der Herstellerzahl. Nicht beziffert sind die Fensterzustände, die das Modell bei Bedarf nachrechnet, und der Indexer. Die Zahl taugt deshalb als Größenordnung, nicht als Budget. Für die Beschaffung heißt das: Bei DeepSeek-V4.1-Flash ist der Kontext praktisch kein Kostenfaktor mehr. Bei Beam ist er klein, aber spürbar. Bei beiden entscheiden die Gewichte.

/04Welche Hardwareklasse welches Modell trägt

Die folgende Tabelle legt die Dateigrößen aus /03 auf fünf Hardwareklassen. „Rechnerisch" heißt: Gewichte plus Cache für einige Sitzungen passen in den Speicher, ein Betrieb ist damit nicht nachgewiesen. Die Karten-Angaben stammen aus den Herstellerseiten, die Zuordnung ist unsere.

Drei Zeilen brauchen eine Erläuterung. Die Zeile mit vier RTX PRO 6000 ist die einzige unterhalb der Rechenzentrumsklasse, in der eine Herstellerfassung rechnerisch passt — und nur für Beam. NVIDIA nennt für die Karte 96 GB GDDR7 und 600 W, vier Karten sind also ein 2,4-kW-Server allein für die GPUs; was eine einzelne Karte leistet, beschreibt RTX PRO 6000 Blackwell. Die H200-Zeile ist „knapp", weil nach den Gewichten rund 50 bis 60 GB für Cache, Aktivierungen und Tensor-Parallelität bleiben; das reicht für wenige Sitzungen, nicht für eine Abteilung. Und die Mac-Zeile bleibt offen, weil für beide Modelle nur Community-Konvertierungen existieren, deren Größe und Qualität wir nicht geprüft haben. Apple liefert den 512-GB-Mac-Studio laut eigener Ankündigung ohnehin erst ab Ende Oktober aus.

/05Download und erster Start: Befehle mit Prüfpunkten

Bevor 300 bis 500 GB über die Leitung gehen, lohnt ein Blick auf die tatsächliche Größe. Die Hugging-Face-API liefert sie ohne Anmeldung. Danach folgen Download, Plattenprüfung und ein erster Start.

# 1. Größe vor dem Download prüfen (Dezimal-GB)
curl -s "https://huggingface.co/api/models/reflection/Beam-1.0-501B-A23B-NVFP4/tree/main?recursive=true" \
  | python3 -c 'import json,sys; d=json.load(sys.stdin); print(round(sum((f.get("lfs") or {}).get("size", f.get("size", 0)) for f in d)/1e9, 2), "GB")'
# erwartet am 22.10.2026: 293.65 GB  (DeepSeek-V4.1-Flash-1017: 510.31 GB)

# 2. Herunterladen
hf download reflection/Beam-1.0-501B-A23B-NVFP4 --local-dir /models/beam-nvfp4
hf download deepseek-ai/DeepSeek-V4.1-Flash-1017 --local-dir /models/dsv41-flash-1017

# 3. Platte prüfen: du zeigt binäre Einheiten
du -sh /models/beam-nvfp4        # rund 274G  (293,65 GB = 273,5 GiB)
du -sh /models/dsv41-flash-1017  # rund 476G  (510,31 GB = 475,3 GiB)

# 4. Beam NVFP4 auf vier Blackwell-Karten — UNSER AUSGANGSPUNKT,
#    vom Hersteller nicht dokumentiert; vLLM 0.32.0 braucht Python 3.11+
vllm serve /models/beam-nvfp4 \
  --served-model-name beam \
  --tensor-parallel-size 4 \
  --max-model-len 131072 \
  --max-num-seqs 8 \
  --kv-cache-dtype fp8 \
  --host 127.0.0.1 --port 8000

# 5. Speicher nach dem Laden ablesen
nvidia-smi --query-gpu=index,memory.used,memory.total --format=csv

# DeepSeek: offizieller Weg ist die Referenzimplementierung (8 Ränge)
python convert.py --hf-ckpt-path /models/dsv41-flash-1017 \
  --save-path /models/dsv41-tp8 --model-parallel 8 \
  --expert-dtype fp4 --tokenizer-path /models/dsv41-flash-1017
torchrun --nproc-per-node 8 generate.py --ckpt-path /models/dsv41-tp8 \
  --config config.json --interactive --temperature 0.6

Vier Hinweise dazu. Erstens: Schritt 4 ist eine Startkonfiguration, die wir aus den belegten Größen ableiten, kein Herstellerrezept. Reflection hat keinen Startbefehl veröffentlicht, und die Release-Notes von vLLM 0.32.0 vom 18. Oktober erwähnen Beam nicht. Wer vLLM einsetzt, prüft zuerst, ob die installierte Version die Architektur kennt. Zweitens: --host 127.0.0.1 ist Absicht. Ein Endpunkt ohne Authentifizierung gehört nicht ins Firmennetz; vLLM 0.32.0 hat zudem die Standard-CORS-Einstellung verschärft, was ältere Frontends brechen kann. Drittens: Die DeepSeek-Befehle stammen aus dem inference-Ordner des Repositories und sind laut DeepSeek „a readable reference implementation rather than a production serving engine". Sie zeigen, dass der offizielle Pfad acht Ränge annimmt. vLLM 0.32.0 nennt V4.1-Flash nur im Abschnitt für AMD MI355X. Viertens: Bei 500 GB Gewichten dauert schon das Laden von lokaler NVMe Minuten. Planen Sie Neustarts nach Updates entsprechend ein.

/06Drittanbieter-Pakete für 192 GB: was sie leisten und was nicht

Die Lücke zwischen 192 GB und 294 GB hat die Community innerhalb von Tagen gefüllt. Auf Hugging Face liegen zwei Pakete, die ausdrücklich für zwei RTX PRO 6000 Blackwell gebaut sind — zusammen 192 GB, also genau die Klasse, die im Mittelstand als Vollausbau realistisch ist.

• Beam, EXL3 3 Bit, 193,76 GB (diffbot): Experten in 3 Bit, Attention und dichte Schichten in 6 Bit, betrieben über vLLM mit ExLlamaV3-Erweiterung und dem DFlash2-Drafter von Reflection für spekulatives Decoding. Der Anbieter misst 117 Token je Sekunde bei einer Sitzung, 0,51 Sekunden Time-to-First-Token und eine KL-Divergenz von 0,0132 gegenüber BF16.
• DeepSeek-V4.1-Flash-1017, EXL3 3 Bit, 331,81 GB (diffbot-Layout): passt nicht in 192 GB und löst das, indem ein Drittel der Experten im Arbeitsspeicher des Hosts liegt — laut Karte rund 230 GiB RAM zusätzlich. Gemessen werden 105 Token je Sekunde bei einer Sitzung und 2K Kontext. Die Experten stammen aus einer unkalibrierten Quantisierung eines weiteren Anbieters.

Das ist technisch beachtlich, und für einen Test auf vorhandener Hardware ist es ein legitimer Weg. Für den Betrieb sprechen vier Punkte dagegen. Alle Zahlen stammen vom jeweiligen Paketautor, nicht vom Modellhersteller und nicht aus einer unabhängigen Messung. Beide Pakete hängen an gepatchten vLLM-Ständen mit eigenen Kerneln; jedes Update der Engine ist ein Projekt. Die Quantisierung auf 3 Bit ist eine Eigenleistung Dritter, deren Verhalten auf deutschen Fachtexten niemand dokumentiert hat. Und 193,76 GB Gewichte auf zwei Karten mit zusammen 192 GB lassen praktisch keinen Platz für Cache und Puffer; wie das Paket das löst, steht in seinem Rezept, nicht in einer Herstellerdokumentation. Ehrlich: Ein Modell, das nur mit einem Paket aus fremder Hand und ohne Puffer startet, ist ein Laborergebnis, kein Dienst, auf den sich eine Abteilung verlässt.

/07Wann die 500B-Klasse die falsche Wahl ist

„Offen" heißt nicht „betreibbar", und bei diesem Modellpaar ist der Abstand zwischen beidem besonders groß. Die 500B-Klasse ist in fünf Fällen die falsche Wahl:

• Das Budget reicht nur für einen Server mit zwei Karten. Dann bleibt nur der Drittanbieterweg aus /06, mit allen Abhängigkeiten. Ein Modell, das in 192 GB mit Reserve läuft, ist die betriebssichere Alternative.
• Die Aufgabe ist Extraktion, Klassifikation oder Wissenssuche. Für RAG über Handbücher, Ticket-Vorsortierung oder das Auslesen von Rechnungen bringt ein Modell mit 500 Milliarden Parametern keinen Vorteil, der seine Hardware rechtfertigt. Hier entscheiden Retrieval und Datenaufbereitung.
• Deutsch ist die Arbeitssprache. Beam ist laut Karte überwiegend für Englisch entwickelt, DeepSeek nennt für V4.1-Flash keine Sprachliste. Wer deutsche Verträge prüfen lässt, braucht vor der Beschaffung ein eigenes Testset.
• Viele gleichzeitige Nutzer mit kurzen Anfragen. 23,4 Milliarden aktive Parameter je Token bei Beam sind gegenüber einem 30B-MoE mit 3 Milliarden aktiv ein Vielfaches an Rechenlast. Für Breite statt Tiefe ist ein kleineres Modell auf derselben Hardware schneller.
• Herkunftsauflagen. Wer Modelle aus bestimmten Ländern nicht einsetzen darf oder will, kann DeepSeek trotz MIT-Lizenz nicht nutzen; die Abwägung steht in DeepSeek V4 aus China.

Richtig ist die 500B-Klasse dort, wo ein Haus lange, mehrstufige Agentenaufgaben auf Code oder Fachdokumenten lösen lassen will, die ein 70B-Modell nachweislich nicht schafft — und wo Datenlage oder Regulierung eine API ausschließen. Das ist eine kleine Gruppe. Die meisten Mittelständler gehören nicht dazu, und das ist kein Mangel, sondern eine Ersparnis.

/08Entscheidung: welche Stufe für welches Haus

Die Entscheidung folgt einer Reihenfolge, nicht einer Wunschliste. Zuerst wird gemessen, ob ein kleineres Modell die Aufgabe löst; erst wenn nicht, wird die größere Hardware gerechnet.

1. Haus mit 24-GB-Karte oder ohne GPU: keine der beiden Optionen. Für die Vorauswahl reichen API-Tests mit unkritischen Daten oder ein Inferenz-Test auf geliehener Hardware.
2. Haus mit 192-GB-System: betreibt Modelle bis 70B+ Parameter mit Reserve. Zur Einordnung: Unsere Messung mit Qwen3 27B auf einem 192-GB-System ergab 3.900 Token je Sekunde als Summe vieler paralleler Anfragen. Beam oder DeepSeek nur als zeitlich begrenzter Test mit Drittanbieterpaket, nicht als Dienst.
3. Haus mit Bedarf an Beam in Herstellerqualität: vier Blackwell-Karten mit 96 GB und die NVFP4-Fassung sind der kleinste rechnerisch tragfähige Aufbau. Vorher ein deutsches Testset, danach die Messung aus /05.
4. Haus mit Bedarf an DeepSeek-V4.1-Flash in offizieller Fassung: beginnt praktisch bei acht Rechenzentrums-GPUs, wie es die Referenzimplementierung annimmt. Das ist die Klasse von HGX B300 und nicht die eines Serverraums.

Zur Wirtschaftlichkeit gilt unsere veröffentlichte Referenzrechnung für ein A100-System: rund 55.000 € über 36 Monate gegenüber rund 108.000 € Cloud-API bei 100.000 Anfragen im Monat, Break-even nach rund 18 Monaten. Für die 500B-Klasse liegt die Hardware um ein Mehrfaches darüber, und die Rechnung muss mit Ihrem Anfragevolumen neu aufgemacht werden — eine Übertragung der 18 Monate wäre unseriös. Eine Fortsetzung für das noch größere Kimi K3 steht in Kimi K3 selbst hosten.