Zen: MoE-Architektur mit 1T+ Parametern

Zen ist die Flaggschiff-Familie der Sprachmodelle von Hanzo. Das größte Modell, zen4-ultra, ist eine Mixture-of-Experts-Architektur (MoE) mit 1.04T Parametern, die pro Vorwärtslauf 140B Parameter aktiviert. Es ist der Abschluss von drei Jahren Modellentwicklung, von zen-nano (600M) bis zur heutigen zen4-Familie.

Dieser Beitrag beschreibt die Architektur, die Trainingsmethode und das On-Chain-Prüfsystem, das Zen-Modelle auditierbar macht.

Architektur

Zen4-ultra nutzt eine spärliche Mixture-of-Experts-Architektur. Der Kernentwurf:

• Parameter gesamt: 1.04T
• Aktive Parameter pro Token: ~140B (Aktivierungsquote 13.5%)
• Experten: 128 Experten pro MoE-Schicht, Top-8-Routing
• Schichten: 96 Transformer-Schichten, jede zweite Schicht ist MoE (48 MoE-Schichten, 48 dicht)
• Kontextfenster: 256K Tokens (YaRN-Positionsinterpolation)
• Vokabular: 152K Tokens (multilinguales BPE)

Das MoE-Routing nutzt ein gelerntes Gating-Netz mit einem zusätzlichen Lastausgleichsverlust, damit Experten nicht kollabieren. Jeder Experte ist ein Standard-FFN (Feed-Forward-Netz) mit SwiGLU-Aktivierung. Der Router wählt 8 von 128 Experten pro Token — genug Vielfalt für komplexe Schlussmuster, bei beherrschbarem Rechenaufwand.

Warum MoE

Dichte Modelle skalieren linear: 2x Parameter = 2x Rechnen pro Token. MoE bricht diese Beziehung. Zen4-ultra hat 7.4x die Gesamtparameter eines dichten 140B-Modells, bei denselben Inferenzkosten pro Token. Die zusätzlichen Parameter geben Kapazität — das Modell speichert mehr Wissen und trägt vielfältigere Aufgaben — ohne proportional mehr Rechnen.

Der Preis ist Speicher. Alle 1.04T Parameter müssen geladen sein, auch wenn nur 140B aktiv sind. Das verlangt verteilte Inferenz über mehrere Knoten, und genau dort wird das ACI-Netz unverzichtbar.

Die Zen4-Familie

Modell	Parameter gesamt	Aktive Parameter	Architektur
zen4-mini	4B	4B	Dicht
zen4-base	8B	8B	Dicht
zen4-pro	14B	14B	Dicht
zen4-max	30B	8B	MoE (32 Experten, Top-2)
zen4-coder	80B	20B	MoE (64 Experten, Top-4)
zen4-ultra	1.04T	140B	MoE (128 Experten, Top-8)

Jedes Modell der Familie teilt denselben Tokenizer, dieselbe Attention-Implementierung und dieselbe Trainingsdaten-Pipeline. Die dichten Modelle (mini bis pro) werden aus ultra destilliert, nicht getrennt trainiert. So bleibt das Verhalten in der Familie konsistent.

Modellfusion

Zen-Modelle werden nicht von einer Zufallsinitialisierung aus von Grund auf trainiert. Sie werden aus leistungsstarken Modellen mit offenen Gewichten verschmolzen, nach einer Methode, die wir strukturierten Wissenstransfer nennen.

Die Basisarchitektur ist Qwen3. Jedes Zen-Modell startet von einem Qwen3-Checkpoint — das ist eine harte Governance-Vorgabe unter der Politik der Zoo Foundation (nur Qwen3+). Der Fusionsablauf:

1. Architekturangleich: Die Architekturen der Quellmodelle werden auf die Zen-Zielarchitektur abgebildet. Bei MoE-Modellen gehört dazu die Initialisierung der Experten aus Schichten eines dichten Modells mit der DROP-Upcycling-Technik (beschrieben in unserem Text Drop-Upcycling: MoE-Modelle in 13B-Qualität zu 1/4 der Kosten).

2. Wissensdestillation: Das Zen-Modell trainiert auf einer Mischung aus (a) rohen Pretraining-Daten und (b) Lehrerausgaben der Quellmodelle. Das Lehrer-Ensemble umfasst Checkpoints von Qwen3, DeepSeek und Mistral, gewählt nach der Benchmark-Leistung auf den Ziel-Fähigkeiten.

3. Expertenspezialisierung: Nach der ersten Fusion werden einzelne Experten auf domänenspezifischen Daten feinjustiert — Mathematik, Code, wissenschaftliches Schließen, mehrsprachiger Text —, damit sich Experten spezialisieren. Der Router lernt, domänenspezifische Tokens an die passenden Experten zu schicken.

4. Verhaltensangleich: DSO-Erfahrungseinträge (dezentralisierte semantische Optimierung) aus dem Ledger der Zoo Foundation dienen der letzten Verhaltensabstimmung. Das ist die Governance-Schicht der Gemeinschaft — das Verhalten von Zen bestimmen die Einträge, die die Gemeinschaft in das Ledger gewählt hat.

Verteiltes Training

Das Training von zen4-ultra läuft auf Compute-Clustern von Hanzo Network — Bare-Metal-Knoten mit je 8x H100, verbunden über InfiniBand. Die Trainingsinfrastruktur:

• Framework: PyTorch mit FSDP (vollständig geshardetes Datenparallel) für dichte Schichten, eigenes Experten-Parallel-Sharding für MoE-Schichten
• Knoten: 512 Knoten (4096 H100-GPUs) für den vollen Ultra-Lauf
• Trainingszeit: 14 Tage für die letzte Fusions- und Spezialisierungsphase
• Daten: 15T Tokens, dedupliziert, qualitätsgefiltert, mehrsprachig (97 Sprachen)
• Checkpoints: alle 1000 Schritte, nach Hanzo Storage geladen, mit inhaltsadressiertem Hash

Die Experten-Parallel-Strategie legt jeden Experten auf eine einzelne GPU und nutzt All-to-All-Kommunikation für das Token-Routing. Das kommuniziert mehr als Datenparallelität, vermeidet aber den Speicheraufwand, alle Experten auf jeder GPU zu replizieren.

On-Chain-Modellattestierung

Jeder Zen-Modell-Checkpoint hat eine On-Chain-Attestierung auf Hanzo Network. Die Attestierung umfasst:

• Modell-Hash: SHA-256 des vollständigen Gewichtstensors, deterministisch aus der kanonischen safetensors-Serialisierung berechnet
• Hash der Trainingskonfiguration: SHA-256 der vollständigen Trainingskonfiguration (Hyperparameter, Datenmischung, Compute-Zuteilung)
• Benchmark-Ergebnisse: standardisierte Benchmark-Werte (MMLU, HumanEval, MATH usw.), berechnet von unabhängigen Auswertern des Evaluationskomitees der Zoo Foundation
• TEE-Attestierung: Intel-TDX- oder AMD-SEV-Attestierung der Trainingsknoten, die belegt, dass das Training auf der genannten Hardware mit dem genannten Code lief

Der Attestierungsvertrag liegt auf Hanzo Network an einer bekannten Adresse. Jeder kann prüfen, dass ein Gewichtssatz zum attestierten Hash passt und dass die Benchmark-Ergebnisse vom Evaluationskomitee stammen und nicht selbst gemeldet sind.

Das verhindert nicht jede Form von Spiel — Benchmark-Kontamination in den Trainingsdaten bleibt schwer zu erkennen —, aber es gibt eine prüfbare Kette von der Trainings-Hardware über die veröffentlichten Gewichte bis zur behaupteten Leistung. Wenn der Hash nicht passt, wurden die Gewichte verändert. Wenn die TEE-Attestierung ungültig ist, war die Trainingsumgebung eine andere als behauptet.

Inferenz auf ACI

Zen4-ultra braucht ungefähr 2TB Speicher, um alle Parameter in FP16 zu laden. Kein einzelner Knoten hat so viel GPU-Speicher. Die Inferenz verteilt sich über ACI-Compute-Knoten mit Tensor-Parallelität:

• 8-Wege-Tensor-Parallel über H100-GPUs auf einem Knoten für die dichten Schichten
• Experten-Parallel über Knoten für MoE-Schichten — jeder Knoten hält eine Teilmenge der Experten
• Spekulatives Decoding mit zen4-mini als Entwurfsmodell, mit 3.2x mehr Durchsatz bei langer Generierung

Ende-zu-Ende-Latenz für eine Generierung von 256 Tokens: 1.8 Sekunden bis zum ersten Token, danach 45 Tokens/Sekunde. Wettbewerbsfähig mit dichten Modellen bei derselben Zahl aktiver Parameter, trotz des verteilten Aufwands.

Offene Gewichte

Alle Zen-Modelle erscheinen unter Apache 2.0 auf HuggingFace und im Repository hanzoai/zen. Gewichte, Tokenizer, Trainingskonfigurationen und Evaluationsskripte sind dabei. Das Gebot offener Gewichte ist eine strukturelle Vorgabe der Governance der Zoo Foundation — es steht in der Satzung der Organisation, es ist keine Ermessensrichtlinie.

Links

• Modelle: huggingface.co/zenlm
• Quelle: github.com/hanzoai/zen
• Attestierungen: explore.hanzo.network — On-Chain-Attestierungsdatensätze des Modells
• Benchmarks: zenlm.org/benchmarks

---

Hanzo AI ist Techstars '17. Zen-Modelle: zenlm.org. Hanzo: hanzo.ai.