FreeToken AI im Test: Frontier-MoE auf Consumer-GPUs?

FreeToken ist eine neue Open-Source Inference Engine, die große Mixture-of-Experts-Modelle über die Hardware eines einzelnen PCs verteilt. GPU-VRAM dient als schneller Expert-Cache, der vollständige Expert-Pool liegt im Arbeitsspeicher. Verbleibende Arbeit wird zwischen PCIe-Transfers und CPU-Ausführung aufgeteilt. Dadurch können ausgewählte NVIDIA-Systeme Modelle, die nicht in den VRAM passen, mit interaktiver Geschwindigkeit ausführen.

Dieser Artikel behandelt das FlashML-Projekt unter FlashML-org/FreeToken, nicht ähnlich benannte Token-Dienste oder SDKs. Wir haben ihn am 25. August 2026 geprüft. Der klare Such-Intent ist ein entscheidungsorientierter FreeToken AI Test zu Hardware, Installation, Benchmarks der Autoren, Grenzen und kommerzieller Eignung. Wenn du allgemein herausfinden willst, welches Modell zu einem Rechner passt, nutze unseren Hardware-Guide für lokale LLMs.

Was ist FreeToken AI?

FreeToken ist eine Edge-native Serving Runtime von FlashML. Das offizielle FreeToken GitHub Repository nennt Consumer-Laptops, Gaming-Desktops und Workstation-GPUs als Zielhardware. OpenAI- und Anthropic-kompatible Endpoints binden Coding Agents und Tool-Using Agents an. Der Code steht unter Apache 2.0.

Das Projekt ist für Sparse-MoE-Modelle gebaut. Ein MoE-Checkpoint enthält viele Expertennetze, sein Router aktiviert pro Token aber nur einen kleinen Teil. Die Berechnung eines Tokens kann deshalb deutlich kleiner als die volle Parameterzahl sein. Das Speicherproblem bleibt: Alle Experten müssen irgendwo liegen, auch wenn die meisten gerade inaktiv sind.

FreeToken behandelt den gesamten Rechner als ein Inferenzsystem. Non-Expert-Weights und häufig genutzte Experten bleiben auf der GPU. Der vollständige Expert-Pool liegt im Host-RAM. Cache Misses werden entweder über PCIe verschoben und auf der GPU ausgeführt oder direkt auf der CPU berechnet.

Wie führt FreeToken ein Modell aus, das größer als der GPU-VRAM ist?

Das FreeToken Research Paper beschreibt fünf zusammenwirkende Mechanismen:

1. Gemeinsamer GPU-Expert-Cache: Eine LRU-Strategie verfolgt zuletzt genutzte Layer-Expert-Paare, statt jede Platzierung beim Start festzuschreiben.
2. Bandbreitenadaptive Ausführung: Eine gemessene Policy teilt Cache Misses zwischen PCIe-Transfer plus GPU-Compute und direktem CPU-Compute. Die Aufteilung wird auf dem echten Rechner kalibriert.
3. Pipelined Prefill: Zwei Layer-Buffer überlappen Expert-Transfers mit GPU-Berechnung, damit lange Prompts nicht jeden Transfer als Wartezeit offenlegen.
4. Semantische State Anchors: Checkpoints an Tool Calls, Thinking Blocks und Gesprächsgrenzen helfen Agents, nach einer bearbeiteten History mehr Kontext wiederzuverwenden.
5. Elastische Memory Pools: Die Runtime kann VRAM zwischen Expert Cache und KV Cache verschieben, wenn der Kontext wächst, ohne den Expert-Pool im Host-RAM neu zu laden.

Das bedeutet nicht, dass ein 284B- oder 753B-Checkpoint in eine kleine GPU passt. Der vollständige Pool braucht weiterhin Host-RAM oder Storage. FreeToken versucht, den aktiven Pfad schnell zu halten, indem jede Phase passende Arbeit auf GPU, CPU und Verbindung verteilt.

Welche Hardware-Anforderungen hat FreeToken?

Die aktuellen FreeToken Installationsanforderungen nennen Linux x86_64, eine NVIDIA-GPU, Treiber r580 oder neuer, CUDA 13 und Python 3.10 oder neuer. CUDA-Kernels werden beim ersten Einsatz kompiliert. Deshalb müssen das CUDA-13-Toolkit und nvcc verfügbar sein.

Das sind Software-Mindestwerte, keine Zusage, dass ein gewähltes Modell passt. Zur Kapazitätsplanung gehören außerdem:

• Arbeitsspeicher: genug für den vollständigen Expert-Pool, Runtime-Allokationen und das Betriebssystem.
• VRAM: genug für Non-Expert-Weights, KV Cache, Ausführungsbuffer und einen sinnvollen Expert Cache.
• Schneller Storage: genug für Modell-Checkpoint, optional konvertierte FTW-Weights, Caches und Rollback-Platz.
• Host-Bandbreite: RAM- und PCIe-Bandbreite beeinflussen direkt, wie Cache Misses verteilt werden.
• Strom und Kühlung: Ein dauerhaft lokaler Agent kann CPU, GPU und Speicher lange auslasten.

Die Tabelle belegt getestete Konfigurationen, ist aber keine Einkaufsliste. Der Laptop nutzte ein offizielles NVFP4-Modell, während mehrere Vergleiche auf größeren Systemen andere Formate nutzten. Architektur, Quantisierung, Kontext, Agent-Trajektorie, RAM, CPU-Bandbreite und PCIe-Generation verändern das Ergebnis.

Welche Modelle und Backends unterstützt FreeToken?

Die offizielle Liste unterstützter Modelle enthält derzeit ausgewählte DeepSeek-V4-Flash-, GLM-5.2-, GLM-4.7-, Qwen3.6-, Qwen3.5-, Qwen3-MoE-, gpt-oss-, Gemma-4-, MiniMax-M2.5- und Muse-Glimmer-Checkpoints. Support hängt von Architektur und Format ab. Multimodale Checkpoints werden aktuell nur als Text bedient.

Das MoE Backend kann fused, offload, cpu, hybrid oder auto sein. Fused verlangt, dass Experten in den VRAM passen. Offload streamt Misses aus dem Host-RAM. CPU berechnet Misses dort. Hybrid überlappt beide Wege. Auto beginnt mit Offload und kann nach einem Bandbreiten-Benchmark Hybrid wählen.

Diese Liste wird sich schnell ändern. Halte in jedem Eval FreeToken-Version, Modell-Repository, exakte Revision, Quantisierung und Lizenz fest. Die Apache-Lizenz der Engine ersetzt weder Modelllizenz noch Acceptable-Use-Bedingungen.

Wie belastbar sind die FreeToken Benchmarks?

Das Paper evaluiert sechs Systeme, zwei zentrale MoE-Modelle, vier agentische Workloads und vier Baseline Engines. Die Autoren berichten auf einer RTX 5090 77 bis 83 Token/s für Qwen3.6-35B-A3B und 22 bis 25 Token/s für DeepSeek-V4-Flash. Über fünf Consumer-Systeme soll FreeToken die stärkste unterstützte Baseline um den Faktor 1,3 bis 2,1 übertroffen haben. Die schlechteste Time to First Token blieb in den Testzellen unter 44 Sekunden, während jede Baseline irgendwo 150 Sekunden überschritt.

Die Evaluation ist hilfreicher als ein kurzer Tokens-pro-Sekunde-Screenshot, weil sie Coding Agents, Tool Calls, lange Kontexte und Tail Latency einbezieht. Wo möglich, stimmen die Modellformate zwischen Engines überein. Trotzdem ist es ein ArXiv-Preprint in Version eins und die Messungen stammen von den Projekt-Autoren. Wavect hat die GPU-Ergebnisse für diesen Artikel nicht reproduziert. Sie sind ein guter Grund für einen Benchmark, aber keine SLA-Garantie.

FreeToken versus Ollama, AirLLM und ein kleineres residentes Modell

FreeToken ist besonders relevant, wenn das gewählte Modell sparse ist und agentische Kontexte wiederholten Prefill erzeugen. Es ist weniger attraktiv, wenn ein kleineres quantisiertes Dense-Modell Qualität und Latenz bereits im VRAM erreicht. Auch der Modellvergleich bleibt Pflicht. Für ein konkretes Beispiel behandelt unser Guide zur lokalen Bereitstellung von DeepSeek V4 Flash Speicher, Quantisierung und Hardware-Fit.

Wie installierst und testest du FreeToken?

Der offizielle FreeToken Quick Start beschreibt OpenAI- und Anthropic-kompatible Endpoints. Ein minimaler Eval-Pfad:

uv venv
source .venv/bin/activate
uv pip install "freetoken[accel]"
ft bench bw
ft serve --model Qwen/Qwen3.6-35B-A3B

Prüfe danach /v1/models, sende eine kurze Completion und verbinde erst dann einen Agent. Die CLI kann Codex, Claude Code, OpenCode, OpenClaw und weitere unterstützte Harnesses gegen den lokalen Server starten. Nutze zuerst ft launch ... --dry-run, damit Konfigurationsänderungen vor der Ausführung sichtbar sind.

Starte nicht mit dem größtmöglichen Checkpoint. Nimm zuerst das kleinste unterstützte Artefakt, das den Ziel-Workload abbildet. Erfasse Download-Größe, Cold Start, Time to First Token, Prompt-Durchsatz, Decode-Speed, Peak-VRAM, Peak-RAM, Kontextkapazität, Stromverbrauch und Fehlerverhalten.

Ist lokale Inferenz wirklich kostenlos?

Lokale Requests erzeugen keine nutzungsabhängige Token-Gebühr bei einem Hosted Provider. Das ist nicht gleichbedeutend mit null Kosten. Zu den vollständigen Kosten pro akzeptierter Aufgabe gehören Hardware-Abschreibung, RAM, NVMe, Strom, Kühlung, Engineering, Monitoring, Modellupdates, Security Controls, Downtime, Leerlauf und ein Fallback.

Für einen Entwickler mit vorhandener Workstation können sich die Grenzkosten fast wie null anfühlen. Bei einem kundenorientierten Produkt dominieren oft Redundanz und Auslastung. Vergleiche das echte FreeToken-System mit der API, die es ersetzen soll, und nutze identische Prompts, Tool Calls, Erfolgskriterien und Parallelität. Ein schneller kostenloser Token hilft nicht, wenn das Modell die Aufgabe verfehlt oder der Server sein Latenzziel reißt.

Wann ist ein FreeToken-Pilot kommerziell sinnvoll?

• Dauerhafte Agent-Workloads: Wiederholte Coding- oder Tool Calls erzeugen genug Volumen für eigene Infrastruktur.
• Lokale Kontrolle: Datenstandort, Offline-Betrieb oder vorhersehbarer Zugriff sind wichtiger als sofortiger Modellwechsel.
• Vorhandene Hardware: Das Unternehmen besitzt geeignete NVIDIA-Hardware, genug Host-RAM und schnellen Storage.
• Qualität eines unterstützten MoE: Ein kompatibles Modell besteht den aufgabenspezifischen Eval gegen die aktuelle API.
• Engineering Ownership: Jemand verantwortet Patches, Modellrevisionen, Observability, Authentifizierung und Recovery.

Nutze eine Managed API oder ein kleineres residentes Modell, wenn die Nachfrage niedrig oder sprunghaft ist, das Produkt immer die neueste Frontier-Fähigkeit braucht, Apple- oder AMD-Hardware feststeht, multimodales Serving Pflicht ist oder das Team keinen lokalen Inferenzdienst betreiben kann. Eine Hybrid-Architektur ist oft der sicherste kommerzielle Standard: lokale Inferenz für vorhersehbare private Aufgaben und ein kontrollierter Cloud-Fallback für schwierige oder überlastete Requests.

Checkliste für Production Readiness

1. Alle Artefakte pinnen: FreeToken Commit oder Release, Modell-ID, Revision, Quantisierung, CUDA, Treiber und Dependencies.
2. Task-Evals ausführen: Vergleiche die Rate akzeptierter Aufgaben, nicht Parameterzahl oder generische Leaderboards.
3. Agent-Traces messen: Lange Kontexte, Tool Calls, gleichzeitige Requests, Retries und History Compaction einbeziehen.
4. Endpoint absichern: Das standardmäßige Loopback-Binding beibehalten, solange kein geschützter Netzwerkdienst geplant ist. Vor Remote-Zugriff Authentifizierung, Autorisierung, Rate Limits und Audit Logs ergänzen.
5. Alle Bottlenecks beobachten: Queue-Zeit, Prefill, Time to First Token, Decode, Cache Hits, RAM, VRAM, Storage und Strom erfassen.
6. Speicherdruck testen: Verhalten prüfen, wenn eine andere Anwendung VRAM nimmt oder der KV Cache wächst.
7. Fehler und Fallback planen: Für Model-Load-Fehler, Timeout, geringe Qualität, Überlast und Host-Ausfall klare Wege definieren.
8. Gesamtkosten neu rechnen: Gemessene Auslastung und erfolgreiche Aufgaben vor einem Hardwarekauf verwenden.

Für das kontextspezifische Performance-Problem siehe unsere Analyse zu Shared-KV-Cache-Latenz bei Multi-Turn-LLM-Inferenz. FreeToken ergänzt semantische Anchors und elastische Cache-Aufteilung. Das Produkt braucht trotzdem End-to-End-Messungen rund um den Agent Harness.

Quellenabgrenzung

Features, Lizenz und breite Hardware-Unterstützung stammen aus dem offiziellen FreeToken Repository. Architektur und Benchmark-Zahlen kommen aus dem ArXiv-Paper der Autoren. Softwarevoraussetzungen stehen im Installationsguide. Modell- und Backend-Kompatibilität stammen aus der Modelldokumentation. Commands und API-Kompatibilität kommen aus dem Quick Start. Wavect hat die Hardware-Benchmarks des Papers nicht reproduziert und beansprucht keine unabhängige Validierung. Support, Modelle und Anforderungen können sich nach dem Review-Datum ändern.