OpenMythos-Einstieg: Open-Source-Implementierung der Claude-Mythos-Loop-Reasoning-Architektur auf Basis von Claude Mythos

Projektüberblick

Im April 2026 stellte Anthropic Claude Mythos vor – das nächste Modell der Claude-Serie für Inferenz und Reasoning. In Aufgaben wie Software Engineering und Cybersicherheit (insbesondere das Finden und Ausnutzen von Zero-Days) zeigt es bisher unerreichte Fähigkeiten. Mythos ist jedoch aktuell nur im Rahmen von „Project Glasswing“ begrenzt für ausgewählte Kooperationspartner aus dem defensiven Security-Bereich verfügbar und wurde noch nicht umfassend veröffentlicht.

OpenMythos ist die Open-Source-Antwort der Community auf diese geschlossene Architektur: Der unabhängige Entwickler Kye Gomez rekonstruiert die Kernarchitektur von Mythos ausgehend von öffentlich verfügbaren Paper(s) und Forschungsarbeiten nach dem Prinzip „First Principles“. Es ist keine offizielle Version, keine Gewichts-Leakage, sondern eine theoretische Rekonstruktion – mit dem Ziel, dass Forschende und Entwickler ähnliche Ideen experimentell verifizieren können.

Der zentrale Durchbruch ist Recurrent-Depth Transformer (RDT): Dieselben Transformer-Gewichte werden in einem einzelnen Forward-Pass bis zu 16-mal (konfigurierbar) zyklisch ausgeführt. So wird „Denken“ iterativ im kontinuierlichen latenten Raum erledigt – nicht, indem man wie bei klassischen Modellen hunderte unabhängige Layer mit unterschiedlichen Gewichten stapelt. Das rekurrente Modell mit 770M Parametern erreicht etwa die Qualität eines Standard-Transformers mit ca. 1,3B Parametern – bei gleicher Fähigkeit also mit rund der halben Parameteranzahl.

---

Schwierigkeit / Dauer / Nutzen

Einstiegsniveau, ca. 30 Minuten: Du bringst deinen ersten OpenMythos-Forward-Pass zum Laufen, verstehst das Wesen des rekurrenten Reasonings, die Prinzipien des LTI-stabilen Injections sowie wie ein MoE-FFN die Modellbreite erweitern kann, ohne die Aktivierungs-Parameter zu erhöhen.

---

Zielgruppe

Entwickler mit grundlegender Erfahrung in LLM-Architekturen, die die Mechanik und die technische Umsetzung von „rekursivem Reasoning“ (1–5 Jahre) tiefer verstehen möchten. Wenn dich die folgenden Fragen interessieren, ist OpenMythos ein guter Startpunkt:

• Warum „mehr Loops = tieferes Reasoning“ selbst theoretisch untermauert ist
• Wie LTI-dynamische Nebenbedingungen sicherstellen, dass rekurrentes Training nicht ausgast
• Wie MoE plus rekurrentes Weight-Sharing eine neue Balance zwischen Parameteranzahl und Rechenaufwand findet

---

Zentrale Abhängigkeiten & Umgebung

• Python 3.10+
• PyTorch 2.0+ (CUDA-Unterstützung beschleunigt die Inferenz)
• Optional: flash-attn >= 2.8.3 (beschleunigt GQA-Attention, IO optimal)
• Mindesthardware: CPU kann ein toy demo laufen lassen, GPU kann das volle Training durchführen

# Nur CPU
pip install open-mythos

# mit Flash Attention 2 (benötigt CUDA + Build-Tools)
pip install "open-mythos[flash]"

---

Vollständige Projektstruktur

open_mythos/
├── main.py              # Kern: OpenMythos-Klasse, MythosConfig, alle Architekturbausteine
├── moda.py              # MoE / LoRA u. ä. Module
├── tokenizer.py         # MythosTokenizer (Wrapper um openai/gpt-oss-20b)
├── variants.py          # vordefinierte Größen: mythos_1b ~ mythos_1t
├── docs/
│   ├── open_mythos.md   # vollständige API-Referenzdokumentation
│   └── datasets.md      # Empfehlungen zur Auswahl von Trainingsdatensätzen
training/
└── 3b_fine_web_edu.py   # 3B Modell Training-Skript für Single-Card / Multi-Card
examples/
├── moda_example.py          # MoE-FFN + LoRA-Adapter-Demo
└── variants_example.py     # Parametervarianten über mehrere Größen hinweg im Vergleich
tests/
├── test_main.py             # Unit-Tests für die Kernmodule
├── bench_vs_transformer.py  # Benchmark-Vergleich mit Standard-Transformer
└── small_benchmark.py       # Small-Scale-Performance-Benchmark

---

Schritt-für-Schritt

Schritt 1 — Installation

pip install open-mythos

Schritt 2 — Konfiguration bauen

Alle Hyperparameter werden über MythosConfig übergeben. Um ein paar zentrale Felder zu verstehen:

from open_mythos.main import MythosConfig

cfg = MythosConfig(
    vocab_size=1000,        # Wortschatzgröße; Demo mit kleinem Vokabular
    dim=256,                # Dimension der latenten Repräsentation
    n_heads=8,              # Anzahl der Query-Head(s)
    n_kv_heads=2,          # Anzahl der KV-Head(s) (GQA: weniger als Q-Heads spart VRAM)
    max_seq_len=128,        # maximale Sequenzlänge (RoPE-Precompute-Limit)
    max_loop_iters=4,       # Loop-Tiefe T; Inferenz kann höher gesetzt werden
    prelude_layers=1,       # Standard-Transformer-Layer für den Prelude-Abschnitt
    coda_layers=1,          # Standard-Transformer-Layer für den Coda-Abschnitt
    attn_type="mla",        # "mla" oder "gqa"; siehe Schritt 5
    n_experts=8,            # Gesamtzahl der MoE-Router-Expert(s)
    n_shared_experts=1,     # Anzahl der dauerhaft aktivierten Expert(s) (pro Token wird jeder aktiviert)
    n_experts_per_tok=2,    # Wie viele Top-K Expert(s) pro Token aktiviert werden
    expert_dim=64,          # Versteckte Dimension pro Expert
    lora_rank=8,            # Rang der Depth-LoRA-Adapter
)

MythosConfig besitzt einen Default-Konstruktor. Ein simples MythosConfig() verwendet eine Reihe vordefinierter Werte mittlerer Größe.

Schritt 3 — Modell initialisieren und Forward-Pass ausführen

import torch
from open_mythos.main import OpenMythos, MythosConfig

cfg = MythosConfig()
model = OpenMythos(cfg)

# Parameteranzahl ausgeben
total = sum(p.numel() for p in model.parameters())
print(f"Parameters: {total:,}")

# Forward-Pass: input_ids shape (B, T), logits shape (B, T, vocab_size)
ids = torch.randint(0, cfg.vocab_size, (2, 16))   # batch=2, seq=16
logits = model(ids, n_loops=4)                    # 4-mal rekursive Inferenz
print(f"Logits shape: {logits.shape}")            # torch.Size([2, 16, 32000])

n_loops steuert die Loop-Tiefe. Der Default kommt aus cfg.max_loop_iters. In der Inferenz kannst du ihn erhöhen – das ist eine Schlüssel-Eigenschaft von RDT: Depth Extrapolation. Das heißt: Man trainiert mit N Loops, nutzt in der Inferenz N+k Loops, um auch komplexere Probleme zu lösen.

Schritt 4 — Autoregressives Generieren

# neue Tokens erzeugen; maximal 8, Loop-Tiefe 8
out = model.generate(ids, max_new_tokens=8, n_loops=8)
print(f"Generated shape: {out.shape}")  # torch.Size([2, 24])

Die generate-Methode verwaltet intern einen KV-Cache. Beim ersten Aufruf wird das komplette Prompt verarbeitet; danach wird bei jedem Schritt jeweils nur ein Token dekodiert. temperature steuert die Zufälligkeit beim Sampling, top_k begrenzt den Sampling-Bereich:

out = model.generate(
    ids,
    max_new_tokens=64,
    n_loops=16,
    temperature=0.8,   # je niedriger, desto deterministischer
    top_k=40,          # 0 = aus
)

Schritt 5 — Attention-Machanismus wählen: MLA vs. GQA

# Multi-Latent Attention (Default; empfohlen für große Kontextfenster)
cfg_mla = MythosConfig(
    attn_type="mla",
    kv_lora_rank=512,      # latente KV-Dimension im Cache (kleiner = spart VRAM)
    q_lora_rank=1536,      # Kompressionsdimension für Q
    qk_rope_head_dim=64,   # pro Head-Dimension mit RoPE
    qk_nope_head_dim=128,  # pro Head-Dimension ohne RoPE
    v_head_dim=128,
)

# Grouped Query Attention (VRAM-freundlich; mit flash-attn oft effizient)
cfg_gqa = MythosConfig(
    attn_type="gqa",
    n_kv_heads=4,         # weniger als n_heads; KV-Cache wird um den Faktor n_heads/n_kv_heads verkleinert
)

Die Abwägung: MLA komprimiert KV in einen Low-Rank-latenten Vektor-Cache – das spart etwa 10–20× Speicher, erfordert aber pro Schritt das Rekonstruieren von K/V (eine lineare Projektion). GQA cached direkt vollständige KV-Heads; in Kombination mit Flash Attention 2 ist IO ideal. Für Produktions-Skalen ist MLA meist speichersparender, während GQA in der Entwicklungsphase einfacher zu debuggen ist.

Schritt 6 — Rekurrente Stabilität prüfen: Spektralradius-Check

Das häufigste Problem beim RDT-Training ist rekurrentes Auseinanderlaufen: Der Hidden State wird in jeder Loop exponentiell verstärkt. OpenMythos stellt die Stabilität konstruktiv durch LTI-stabile Injection sicher. Die Validierung erfolgt über die Überprüfung des Spektralradius ρ(A):

# diskretisiertes Zustands-Matrix A_discrete holen
A = model.recurrent.injection.get_A()           # shape (dim,)
rho = torch.linalg.eigvals(A).abs().max().item()

print(f"Spectral radius ρ(A) = {rho:.4f}")
assert rho < 1.0, f"Unstable: ρ(A) = {rho:.4f} >= 1"

Schritt 7 — Vordefinierte Größen-Varianten nutzen

Wenn du MythosConfig nicht selbst zusammenstellen willst: variants.py bietet vordefinierte Konfigurationen von 1B bis 1T:

from open_mythos import mythos_1b, mythos_3b, mythos_10b, mythos_50b, mythos_100b

# mythos_7b() liefert MythosConfig
cfg = mythos_3b()
model = OpenMythos(cfg)
print(f"Variant 3B: {sum(p.numel() for p in model.parameters()):,} params")

Schritt 8 — Trainingsskript ausführen

Das Projekt enthält ein Trainingsskript für das 3B-Modell auf dem FineWeb-Edu-Datensatz:

# Single GPU
python training/3b_fine_web_edu.py

# Multi GPU (erkennt automatisch die Anzahl der GPUs)
torchrun --nproc_per_node=$(python -c "import torch; print(torch.cuda.device_count())") \
    training/3b_fine_web_edu.py

Wichtige Trainingskonfiguration:

# training/3b_fine_web_edu.py (kritische Parameter)
optimizer = torch.optim.AdamW(model.parameters(), lr=3e-4, weight_decay=0.1)
# Präzision: H100/A100 nutzen bfloat16; ältere Karten float16 + GradScaler
# Scheduler: 2000 Steps Warmup → dann Kosinus-Abklingen
# Tokenizer: openai/gpt-oss-20b via MythosTokenizer

---

Häufige Probleme & Troubleshooting

1. VRAM explodiert: Loop-Anzahl × Batch-Größe als Kombinationsfalle

Die Loop-Phasen von RDT sind nicht so unabhängig zwischen Layern wie beim Standard-Transformer: Jeder Loop-Schritt sammelt die KV-Zustände aller Tokens in den Cache. Wenn du 16 Loops × Sequenzlänge 4096 × Batch 8 kombinierst, ist der Speicherbedarf ein Vielfaches eines Standardmodells.

Lösung: Starte mit einem kleinen n_loops (z. B. 4) zur Validierung; nach Erreichen der Konvergenz schrittweise erhöhen. Außerdem den Batch nicht fix lassen, sondern linear skalieren.

2. Flash Attention fehlt, aber du willst beschleunigen

Wenn das Kompilieren von flash-attn fehlschlägt (häufig Windows + CUDA-Setup), degradiert OpenMythos automatisch auf die native PyTorch-Attention. Wichtig: Dieses Degrading beeinträchtigt nicht die Korrektheit, sondern nur die Geschwindigkeit – in Szenarien mit kleinen Batches ist der Unterschied meist nicht groß.

3. Spektralradius-Check schlägt fehl: Training läuft auseinander

Wenn du die Parametrisierung von LTIInjection verändert hast oder beim Fine-Tuning versehentlich die falschen Layer eingefroren hast, sodass die Injection-Parameter beschädigt werden, kann ρ(A) >= 1 auftreten. Clippe nicht einfach die Parameter – setze stattdessen zurück auf die Default-Initialisierung und starte neu. Die Stabilitätsgarantie der LTI-Bedingungen liegt in der parametrisierten Struktur, nicht in einem nachträglichen Fix.

4. ACT: Vorzeitiges Stoppen führt zu zu wenigen effektiven Loops

act_threshold=0.99 bedeutet: Sobald an jeder Position 99% Wahrscheinlichkeit akkumuliert sind, wird vorzeitig abgebrochen. Wenn du in manchen Aufgaben feststellst, dass die effektive Loop-Anzahl deutlich unter n_loops liegt, prüfe die Token-Schwierigkeit in deinen Daten: Zu einfache Tokens lösen das Halting zu früh aus, sodass komplexere Tokens nicht genug Tiefe bekommen.

5. MoE-Routing bricht zusammen: Einige Experten werden nie aktiviert

DeepSeekMoE-artige, auxiliary Loss-freie Load-Balancing-Mechanismen basieren auf einer dynamischen Anpassung des router_bias. Wenn du von Anfang an trainierst und diese Anpassungslogik nicht aufrufst, konvergiert der Router schnell dahin, nur wenige Experten zu aktivieren (typischerweise die ersten 1–2). In dem Projekt ist zwar MoEFFN.forward mit einem Platzhalter für das Bias-Adjustment versehen, aber in benutzerdefinierten Trainingsskripten muss die Bias-Update-Logik regelmäßig aufgerufen werden.

6. Schlechte Generierungsqualität: Temperatur und top_k richtig kombinieren

---

Weiterführende Lektüre / Advanced Directions

Zentrale Paper

Advanced Directions

1. LoRA-Adapter selbst anpassen: Aktuell ist lora_rank global einheitlich. Du kannst es auf eine Schicht-für-Schicht-Konfiguration umstellen, sodass unterschiedliche Loop-Tiefen unterschiedliche Adapter-Stärken verwenden.

2. ACT-Threshold-Scanning: Der Default 0.99 ist ein Erfahrungswert. Führe ein Grid-Search über 0.8–0.999 aus. Du wirst sehen, dass es bei manchen Aufgaben besser ist, 0.95 statt 0.99 zu verwenden (früheres Stoppen vermeidet „overthinking“).

3. Depth-Extrapolation-Experimente: Trainiere mit festem n_loops und skaliere dann in der Inferenz n_loops durch. Zeichne eine Kurve „Anzahl der Loops → Accuracy der Downstream-Aufgabe“. Theoretisch solltest du eine exponentiell abklingende Form sehen – das ist eine der wichtigsten nachweisbaren Eigenschaften von RDT.

4. Standard-Transformer vergleichen: Verwende das Skript bench_vs_transformer.py, um mit gleicher Parameteranzahl die Lücke zwischen rekurrenten Modellen und Standardmodellen in compositional / systematic generalization-Aufgaben zu vergleichen. Das ist der deutlichste Vorteil von RDT.