Kimi K3 und andere große Modelle lokal betreiben: fünf offene Repos

Frontier-Modelle auf dem Schreibtisch statt im Rechenzentrum

Gehostete Modelle der großen Labs sind beeindruckend und teuer. Wer etwas Ernsthaftes darauf aufbaut, sieht die Rechnung schnell steigen. Modelle mit offenen Gewichten, die nah an die kostenpflichtigen herankommen, gibt es schon eine Weile, doch mit einem normalen Rechner kauften die meisten Inferenz am Ende trotzdem bei jemand anderem ein. Eine Handvoll Open-Source-Projekte ändert das gerade. Und es geht dabei nicht um Spielzeugmodelle. Sie zielen auf Modelle der Frontier-Klasse, deren Training Millionen gekostet hat, und lassen sie offline auf Ihrer eigenen Hardware laufen, ohne Kosten pro Token.

Die fünf Repos unten gehen alle dasselbe Problem an: Wie schrumpft man etwas, das für ein Rechenzentrum gebaut ist, bis es auf einen Schreibtisch passt? Ihre Antworten fallen sehr unterschiedlich aus.

Was diese Projekte gemeinsam haben

Die Lücke ist riesig. Ein Modell wie Kimi K3 braucht allein für seine Gewichte 1,56 TB, ein Laptop hat typischerweise 16 oder 32 GB RAM. Jedes Tool hier umgeht dieses Missverhältnis, und die Ansätze lassen sich in drei Familien einteilen:

• Die Gewichte von der Festplatte streamen, statt alle in den Speicher zu laden.
• Das Modell so stark komprimieren, dass nur noch ein Bruchteil der ursprünglichen Größe übrig bleibt.
• Neuronen überspringen, die zum aktuellen Prompt nichts beitragen – das sind die meisten, also gibt es keinen Grund, sie zu laden.

Auch sonst unterscheiden sie sich. Manche sind allgemeine Inferenz-Engines für Hunderte Modelle, andere sind genau um eine Architektur herum gebaut. Manche brauchen eine GPU, andere verzichten bewusst darauf. Einige sind Forschungsexperimente an der Grenze des Machbaren, andere sind schon heute einsatzbereit.

1. Kimi K3 in C

Kimi K3 ist ein Mixture-of-Experts-Modell von Moonshot AI mit 2,78 Billionen Parametern und schlägt Claude in mehreren Benchmarks. Bis vor Kurzem hätte man angenommen, die Eintrittskarte sei eine Serverfarm in Lagerhallengröße.

Dieses Repo sieht das anders. Es ist eine Inferenz-Engine in portablem C99, 176 KB Code, ganz ohne Abhängigkeiten: kein BLAS, kein PyTorch, keine GPU. Der Autor hat damit das vollständige Modell auf einem Laptop mit gerade einmal 8 GB RAM zum Laufen gebracht.

Die Ausgabe ist auf einem 8-GB-Laptop und einer 128-GB-Workstation byteidentisch, nur die Geschwindigkeit ändert sich. Mit 8 GB warten Sie etwa 26 Sekunden pro Token – quälend, aber es funktioniert. Geben Sie ihr genug RAM, damit das ganze Modell im Speicher bleibt, sinkt die Wartezeit auf 5,6 Sekunden pro Token.

Der Trick ist Disk-Streaming. Da K3 ein Mixture-of-Experts-Modell ist, sind pro Token nur rund 4 % der Parameter aktiv. Die Engine liest nur die benötigten Experten von der Platte, direkt in die Berechnung, und versucht nie, das ganze Modell im Speicher zu halten. Die gesamte Engine ist eine einzige C-Datei ohne Abhängigkeiten.

Zum Ausprobieren:

# Clone the repo
git clone https://github.com/FareedKhan-dev/kimi-k3-in-c.git
cd kimi-k3-in-c

# Build
make

# Run with a preset matching your hardware
./bin/k3 ~/k3model --trunk ~/k3trunk --preset laptop \
  --tok ~/k3model --prompt "The capital of France is" --gen 8

2. WARP

Ist die C-Engine oben der minimale Machbarkeitsnachweis, dann ist WARP die ingenieurlastige Version. Sie stammt vom SQLiteAI-Team und ist eine einbettbare Inferenz-Engine in C, die dieselbe Idee des Streamings von der Platte beibehält und echte Optimierung obendrauf packt.

Der gemeinsame Stamm des Modells bleibt im Speicher, und nur die für das aktuelle Token ausgewählten Experten kommen von der Platte. Was an RAM übrig bleibt, wird zu einem begrenzten Experten-Cache, sodass häufig gewählte Experten im Speicher bleiben. Ein vorausschauender Router geht noch einen Schritt weiter: Er sagt voraus, welche Experten die nächste Schicht brauchen wird, und beginnt früh damit, sie zu lesen.

Ergebnis: Der K3-Container schrumpft von 1,56 TB auf 982 GB, und ein MacBook Pro mit 64 GB kann ihn ausführen, allerdings nur mit etwa 0,6 Token pro Sekunde.

Das Projekt beschreibt sich als von Menschen gesteuert und von LLMs geschrieben. Sein langfristiges Ziel ist etwas verrückt: WARP soll K3 so gut laufen lassen, dass das Modell an seiner eigenen Verbesserung arbeiten kann.

Einrichtung:

# Clone
git clone https://github.com/sqliteai/waste.git
cd waste

# Build (requires C compiler)
make

# Run with auto-detected memory budget
./waste run ~/models/k3.waste "What is the capital of Italy?"

# Or specify a memory budget manually
./waste run ~/models/k3.waste "Explain quantum computing" --budget 48GB

3. Deltafin

Deltafin beginnt mit einer Frage, auf die kaum jemand kommt. Was, wenn man das komplette K3 – alle 16 Experten bei jedem Token, nie beschnitten – auf Consumer-Hardware laufen lässt und das dann so schnell wie möglich macht?

Das ist ebenso Philosophie wie technische Entscheidung. Andere Projekte nehmen Abkürzungen: Experten beschneiden, Schichten überspringen oder mit einem Draft-Modell spekulieren. Deltafin nicht. Seine Qualitätsregel lautet sinngemäß: Allein K3 entscheidet über jedes Token. Kleine Draft-Modelle dürfen vorausraten, und daher kommt ein Großteil der Geschwindigkeit, aber K3 prüft jeden Tipp, und nichts erreicht Sie ohne seine Freigabe.

Die Zahlen sind bescheiden und werden offen genannt. Ein M1-Max-Laptop schafft derzeit etwa 0,29 Token pro Sekunde. Spannend ist aber das Fortschrittsdiagramm in der README. In rund einer Woche ging das Projekt von 0,014 auf 0,29 Token pro Sekunde – eine Verzwanzigfachung durch beharrliche Optimierungsarbeit. Das Leitbild formuliert die Haltung klar: Geschwindigkeit darf niemals auf Kosten der Modellqualität gehen.

Das Team wertet es als Fortschritt, wenn ein Frontier-Modell auf einem Heim-Setup für rund 15.000 Dollar läuft statt auf Infrastruktur im Wert von 2.000.000 Dollar.

Erste Schritte:

# Download the latest release from GitHub
# https://github.com/gavamedia/deltafin/releases

# Run with model path (auto-detects hardware)
./deltafin --model /path/to/k3-checkpoint


# The binary handles expert routing, memory management,
# and hardware acceleration automatically.

4. llama.cpp

Diesen Namen haben Sie höchstwahrscheinlich schon gehört. llama.cpp hat lokale Inferenz massentauglich gemacht.

Sein Schöpfer, Georgi Gerganov, begann mit einer einfachen Idee: LLaMA-Modelle in reinem C/C++ mit so wenigen Abhängigkeiten wie möglich laufen lassen. Kein PyTorch, keine Python-Laufzeit, nur direkte Leistung vom Metall bis zum Modell. Daraus wurde die am weitesten verbreitete lokale Inferenz-Engine überhaupt. Sie unterstützt Hunderte Modelle auf CPUs, GPUs (CUDA, Metal, Vulkan, SYCL) und auch auf mancher ungewöhnlichen Hardware.

Um sie herum ist ein ganzes Ökosystem entstanden. Ollama, LM Studio und GPT4All sowie viele andere „Modell einfach lokal laufen lassen“-Tools basieren unter der Haube auf llama.cpp. Man könnte es den Linux-Kernel der lokalen KI-Inferenz nennen.

Verwendung:

# Install via Homebrew (easiest)
brew install llama.cpp

# Download and run any GGUF model from Hugging Face
llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF

# Or launch an OpenAI-compatible API server
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

# Build from source
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp && cmake -B build && cmake --build build

5. FlexGen

FlexGen passt zu einer anderen Situation: Sie haben eine einzige handelsübliche GPU und wollen über Nacht Millionen Tokens durch ein Modell schicken.

Es ist eine Generierungs-Engine mit hohem Durchsatz vom FMInference-Team, um große Sprachmodelle mit begrenztem GPU-Speicher zu betreiben. Sie setzt auf IO-effizientes Offloading. Passen die Gewichte nicht in den GPU-Speicher, wandern sie in den CPU-RAM oder sogar auf die Platte, und das ganze Schema ist auf Durchsatz statt auf niedrige Latenz getrimmt.

So kann es etwa OPT-175B, das bei voller Präzision 350 GB GPU-Speicher braucht, auf einer einzelnen T4 mit 16 GB ausführen, indem es Gewichte auf die Platte auslagert. Die Latenz pro Token ist für Chats ungeeignet. Für nächtliche Batch-Jobs wie Benchmarking (es ist in Stanfords HELM-Framework integriert) oder Datenaufbereitung ist es genau das Richtige.

Alle fünf Repos verfolgen dasselbe Ziel, KI lokal auszuführen, jedes aus einem anderen Blickwinkel. Zusammen zeigen sie in eine Richtung: weg davon, Ihre Daten an eine Serverfarm zu schicken, hin zu den stärksten Modellen direkt auf Ihrem eigenen Gerät.