Betelgeuse: 68-GB-MoE-Modell mit 22 tok/s auf RTX 3060 und 16 GB RAM

Worum es geht

Ein Nutzer (u/zyxciss) stellt auf Reddit in r/LocalLLaMA Betelgeuse vor, eine Laufzeitumgebung als Fork von llama.cpp. Ziel: das sehr große Mixture-of-Experts-Modell (MoE – ein Modell, das aus vielen „Experten“-Teilnetzen besteht, von denen pro Token nur einige aktiv sind) Qwen 3.8 Flash Next in einer 68 GB großen Quantisierung (GSQ-RCO-IQ2_XS) auf einem normalen Gaming-PC nutzbar zu machen. Alle Zahlen stammen vom Autor selbst und sind nicht unabhängig überprüft.

Der Autor distanziert sich zugleich von einem früheren Prototyp: Dieser habe durch „Gate Pruning“ (selten genutzte Experten weglassen) hohe Geschwindigkeiten erzielt, aber die Qualität verschlechtert. Das habe er verworfen. Betelgeuse lasse dagegen keinen einzigen Experten aus.

Testsystem

• GPU: RTX 3060 mit 12 GB VRAM
• RAM: 16 GB DDR4, Single-Channel (ca. 19 GB/s); getestet in einer cgroup mit MemoryMax=12G
• Betriebssystem: CachyOS / Arch Linux
• Speicher: Consumer-NVMe-SSD mit rund 2,1 GB/s

In stock llama.cpp lädt das Modell per mmap (Datei wird in den Speicher eingeblendet), der Seitencache des Betriebssystems „thrasht“: etwa 1.500 große Page Faults pro Token, nur 1,47 tok/s. Die Alternative Strata erreiche 40+ tok/s, brauche dafür aber 48–64 GB RAM; auf 16 GB falle sie mit --low-ram mmap auf 8,11 tok/s zurück.

Wie Betelgeuse arbeitet

• Arrival-Slack VRAM Slot Pool: Alle 49 dichten Layer samt GDN, QSA und LM-Head belegen etwa 3,2 GB VRAM. Der Rest hält rund 5.000 Experten-Slots, ungleich verteilt: 240 pro Layer in den frühen Layern 0–4 (dort gibt es keinen Rechenspielraum), 92 in der Mitte, 60 am Ende.
• In-Stream GPU Doorbell + CUDA-Graph-Replay: Statt den Graphen pro Token 48-mal aufzuteilen und die CPU zu fragen (laut Autor rund 360 ms pro Token durch cudaStreamSynchronize), prüft ein eigener CUDA-Kernel in ca. 2 µs, ob ein Experte im VRAM liegt, und „klingelt“ nur bei einem Fehlzugriff den Host an. So läuft der gesamte Decode-Durchgang als ein einziger CUDA-Graph-Replay.
• RAM Victim Cache + io_uring Pager: Aus dem VRAM verdrängte Experten wandern in einen RAM-Cache, VRAM und RAM halten sich exklusiv, ohne Duplikate im Seitencache. Die SSD-Lesemenge sinkt auf 12,43 MB pro Token.
• Kein doppelter Speicher: Das Modell wird aufgeteilt in Dense.gguf (3,2 GB), experts.bin (35,3 GB, 4-KB-ausgerichtet) und PLE.gguf (26,8 GB).

Messwerte

Bei langen Coding-Prompts halte es 21,8–22,03 tok/s. Auch die riesige Q8_K_XL-Variante (~190 GB) laufe auf derselben Maschine mit 8 tok/s kalt und 12 tok/s warm (Spitzen 21), während stock llama.cpp abstürze oder unter 0,1 tok/s liege. Auffällig: Die Prompt-Verarbeitung ist langsamer als bei Strata.

Was du zum Ausprobieren brauchst

Laut Autor reicht eine Nvidia-GPU mit 12 GB VRAM (RTX 3060), 16 GB RAM und eine NVMe-SSD mit genug Platz (das Paket umfasst gut 65 GB; die größte Variante ca. 190 GB). Getestet wurde nur unter Linux mit CUDA. Es gibt einen vorgepackten Bundle auf Hugging Face (Alpha-Orionis-XS), Code auf GitHub und einen Upstream-PR für llama.cpp.

Einordnung

Das Projekt zeigt, dass bei großen MoE-Modellen nicht nur die Rechenleistung, sondern vor allem Speichermanagement und Synchronisation den Ausschlag geben. Besonders relevant: Es ist kein Qualitätsverlust durch Weglassen von Experten im Spiel. Kritisch: Alle Benchmarks stammen vom Autor, nur auf einer Hardware-Konfiguration; die Byte-Genauigkeit wurde an 576 Tokens belegt. Die Prompt-Verarbeitung ist nicht schneller als bei Alternativen, und der Upstream-PR hat laut Autor selbst geringe Merge-Chancen. Die DeepSeek-V4.1-Portierung ist noch frühe Entwicklung.