Das ernüchternde Fazit: Lokale KI-Inferenz auf dem M4 Max

Du hast dir ein MacBook Pro mit M4 Max und 128 GB Unified Memory zugelegt. Klar, der Gedanke liegt nahe: Endlich mal schnell einen lokalen KI-Coding-Assistenten laufen lassen, ohne ins Schwitzen zu kommen. Schließlich sollte diese Speichermenge doch genug Power für große Sprachmodelle bieten.

Pustekuchen. Zumindest wenn man der Erfahrung eines Entwicklers glaubt, der sich durch diverse Metal-Inference-Engines, Optimierungsrunden und verschiedene Modellarchitekturen gearbeitet hat. Heraus kam eine ernüchternde Erkenntnis: Sobald du mit brauchbaren Modellgrößen arbeitest, stößt du bei etwa 80 bis 150 Tokens pro Sekunde an eine Decke.

Was versprochen wurde vs. was ankommt

Apple Silicon hat mit der Unified Memory Architecture wirklich etwas Innovatives auf den Tisch gebracht. Kein Herumschieben von Daten zwischen CPU und GPU mehr – alles lebt beisammen und sollte theoretisch für schnellere KI-Verarbeitung sorgen. Für viele Aufgaben stimmt das auch.

Aber wenn es um das Serving großer Sprachmodelle für Coding-Assistenz geht, sieht die Realität anders aus. Selbst mit aggressiv für Metal optimierten Inference Engines:

• Llama.cpp Q4_0: Rund 70,9 Tokens/Sekunde
• MLX 4-bit: Ungefähr 80,6 Tokens/Sekunde
• Custom optimiertes Qwen3-Coder-Next: Etwa 120 Tokens/Sekunde
• Custom optimiertes Qwen3.6-35B bei 4-bit: Rund 85 Tokens/Sekunde

Das Muster wird schnell klar: Sobald du bei „brauchbaren" Parameterzahlen landest – meist 7B+ für Coding-Aufgaben – triffst du auf eine Mauer. Egal wie viel du optimierst.

Warum ist das so?

Der Entwickler hinter den Benchmarks vermutet: Die Memory Bandwidth, nicht die reine Rechenleistung, ist das Nadelöhr. Und das ergibt durchaus Sinn, wenn man drüber nachdenkt, wie Transformer-Modelle arbeiten.

Für jede Token-Generierung müssen substantiale Teile der Modellgewichte aus dem Speicher gelesen werden. Selbst mit dem beeindruckenden Bandwidth des M4 Max bist du ultimately begrenzt, wie schnell du Daten bewegen kannst. Matrix-Multiplikationen mögen schnell sein – aber nur so schnell wie die Daten, die sie füttern.

Das erklärt auch, warum kleinere Modelle dramatisch besser performen. Es gibt schlicht weniger Daten zu bewegen. Ein 0,1B-Parameter-Modell schafft vielleicht 1.000 Tokens/Sekunde, aber wechsle zu 1,5B und du fällst auf etwa 140 Tokens/Sekunde. Der Skalierungseffekt ist nicht linear – er ist brutal.

Was bleiben einem für Optionen?

Wenn du Coding-Assistenz mit 200+ Tokens/Sekunde suchst und dabei Reasoning- sowie Tool-Calling-Fähigkeiten behalten willst, wird die Landschaft schnell übersichtlich:

Cloud-Lösungen

Gehostete Modelle von Anbietern wie Anthropic, OpenAI oder DeepSeek liefern ordentliche Rechenpower. Dafür kassieren sie aber auch monatliche Subscriptions zwischen 20 und 200+ Dollar bei ernsthaftem Einsatz. Zuverlässig und schnell – aber abhängig von externen Diensten und deren Verfügbarkeit.

Spezialisierte Hardware

Cerebras bietet tatsächlich beeindruckende Inferenzgeschwindigkeiten (ihr GPT-oss-120b Modell läuft mit über 1.000 Tokens/Sekunde). Allerdings dürfte das Pricing für die meisten Einzelentwickler und viele Teams unerreichbar sein.

Lokale Modelle mit angepassten Erwartungen

Falls du lokale Inferenz brauchst, überlege, ob du mit etwas weniger Speed leben kannst. Modelle wie Qwen3.5-32B oder ähnliche Architekturen bei 4- bis 8-bit Quantisierung liefern brauchbare Coding-Assistenz bei 80 bis 120 Tokens/Sekunde. Für produktive Arbeit ausreichend, wenn dein Workflow etwas mehr Latenz verträgt.

Die eigentliche Frage: Lokal oder Cloud?

Diese Debatte hängt schlussendlich von deinen konkreten Bedürfnissen ab:

• Lokal wählen, wenn du strikte Datenschutzanforderungen hast, nur intermittent Internet-Zugang, oder ohne laufende Kosten experimentieren willst.
• Cloud wählen, wenn konsistente Geschwindigkeit wichtiger als Besitz ist, du die absolut besten Modellfähigkeiten brauchst, oder dein Compute-Budget Subscriptions stemmen kann.

Für viele Entwickler macht ein Hybrid-Ansatz am meisten Sinn: Lokale Modelle für Experimente und schnelle Aufgaben, Cloud für Production-Workloads, wo Speed und Fähigkeiten entscheidend sind.

Das Fazit

Apple Silicon ist für viele KI-Aufgaben wirklich beeindruckend. Aber schnelle lokale Inferenz mit leistungsfähigen Coding-Modellen bleibt herausfordernd. Die Hardware wurde schlicht nicht für diese spezifische Workload designt, und keine Metal-Optimierung der Welt kann fundamentale architektonische Grenzen überwinden.

Wenn du einen KI-gestützten Development-Workflow aufbaust, ist deine beste Strategie, die Infrastruktur an deine tatsächlichen Bedürfnisse anzupassen – und ehrlich zu sein, ob der „Local First"-Ansatz dir wirklich dient oder dich eher ausbremst.

Was ist deine Erfahrung mit lokaler KI-Inferenz? Hast du Konfigurationen gefunden, die diese Performance-Grenzen durchbrechen?