Benchmark von LLM-Servern für Qwen 3.5 auf Mac — Ergebnisse 2026

# Benchmark von 8 lokalen LLM-Servern für Qwen 3.5 auf Mac: Überraschende Ergebnisse im Jahr 2026

Ein detaillierter Benchmark von acht lokalen LLM-Servern zum Ausführen von Qwen 3.5 35B MoE wurde auf einem MacBook Pro mit M2 Max durchgeführt. Bei einem einzelnen Nutzer betrug der Geschwindigkeitsunterschied nur 2 %, aber bei zwei parallelen Anfragen lieferte ein Framework eine 2,17-fache Beschleunigung, während ein anderes auf 0,85x absackte. Die Analyse deckte kritische Nuancen bei kontinuierlichem Batching, Phantom-Geschwindigkeitsmetriken und Problemen beim Speichermanagement auf.

Warum LLMs lokal ausführen: Drei technische Gründe

Für Entwickler und Ingenieure löst das lokale Ausführen von Modellen drei zentrale Herausforderungen:

• Datenschutz. Verträge, Spezifikationen und Kundenchats verarbeiten, ohne sie an Cloud-APIs zu senden. Ein lokales Modell anonymisiert personenbezogene Daten (Namen, Zugangsdaten) in Echtzeit.
• Autonome Coding-Agents. Tools wie OpenCode und Aider benötigen einen OpenAI-kompatiblen Endpunkt. Mit base_url: http://mac.local:8000/v1 lassen sich Agents ohne Telemetrie oder Ratenlimits ausführen und Cloud-Token sparen.
• Keine Netzwerk-Latenz. Ein 35B-Modell in 4-Bit-Quantisierung auf M2 Max erzeugt Antworten schneller als Cloud-APIs dank null Rundreisezeit. Auf 64 GB einheitlichem Speicher benötigt das Modell ~20 GB und lässt Platz für den KV-Cache.

Diese Faktoren machen einen lokalen Server auf Mac zu einer brauchbaren Alternative für den professionellen Einsatz, besonders bei sensiblen Daten.

Warum MLX llama.cpp auf Apple Silicon schlägt

Die Wahl von MLX vor llama.cpp ergibt sich aus der Architektur von Apple Silicon:

• Einheitlicher Speicher. Auf M-Serien teilen CPU und GPU einen einzigen Speicherpool. Das 35B-Modell residiert in 20 GB ohne Kopieren zwischen RAM und VRAM (im Gegensatz zu NVIDIA).
• Leistung. MLX ist durch native Metal-Kompilierung konsequent 10–30 % schneller als llama.cpp. M2 Max bietet ~400 GB/s Speicherbandbreite und ermöglicht 50–80 Tokens/Sek. in Echtzeit.
• Natives kontinuierliches Batching. Das MLX-Ökosystem unterstützt parallele Anfragen von Haus aus, während llama.cpp zusätzliche Konfiguration erfordert.

Wichtig: Metal unterstützt kein GPU-Kontext-Sharing zwischen Prozessen. Alle Tests nutzten einen einzelnen Server, um Ressourcenkonflikte zu vermeiden.

Verglichene Frameworks: Auswahl und Kriterien

Der Benchmark umfasste sechs Server aus dem MLX-Ökosystem (zwei fielen wegen Inkompatibilität mit Qwen 3.5 35B MoE aus):

• mlx-openai-server (Python 3.11) — Unterstützung für kontinuierliches Batching, Multi-Model via YAML, strukturierte Ausgabe.
• mlx-omni-server (Python 3.11+) — Dual-API (OpenAI + Anthropic), TTS/STT.
• Rapid-MLX (Python 3.10+) — Einfache Bereitstellung, 1900+ Tests, Cursor/Aider-Integration.
• vllm-mlx (Python 3.10+) — Gepagter KV-Cache, Multimodalität, aber mit kritischem SSE-Parser-Bug.
• omlx (Python) — Gestufter KV-Cache (RAM + SSD), Web-Dashboard, aber harte 32768-Token-Grenze.
• mlx-vlm (Python 3.10+) — 40+ Architektur-Support, aber pathologischer Verlangsamung bei langen Prompts.

Ausgeschlossen:

• higgs (Rust) — Unterstützt kein qwen3_5_moe.
• mlx-serve (Zig) — Erfordert macOS 15 (Sequoia).

Schlüsselkriterium: Native MLX-Format-Kompatibilität mit Qwen 3.5 35B MoE, keine Konvertierung nötig.

Benchmark-Methodik: Wie die Leistung gemessen wurde

Tests liefen auf einem 16" MacBook Pro M2 Max (64 GB einheitlicher Speicher) mit mlx-community/Qwen3.5-35B-A3B-4bit. Der Python-Benchmark-Harness umfasste:

• Ladenszenarien:

* run_single — Sequenzielle Verarbeitung von 8 Prompts (100 bis 53000 Tokens).

* run_double_batch — Zwei parallele Anfragen via asyncio-Barriere:

gate = asyncio.Event()
task_a = create_task(chat_stream(..., start_gate=gate))
task_b = create_task(chat_stream(..., start_gate=gate))
await asyncio.sleep(0.05)
gate.set()
res_a, res_b = await gather(task_a, task_b)

• Metriken:

* wall_tps_p50 — Median Tokens/Sek. nach Wanduhrzeit (primäre Metrik).

* ttft_p50 — Time to First Token (TTFT).

* speedup — Batching-Effizienz (Wall-TPS-Verhältnis für zwei vs. eine Anfrage).

Median statt Mittelwert, um Ausreißer durch Promptlängen-Varianz zu vermeiden. Jeder Test 5-mal wiederholt.

Ergebnisse: Einzelnutzer vs. Parallele Verarbeitung

Einzelnutzer-Leistung war über Server hinweg ähnlich (innerhalb 2 %). Lücken zeigten sich bei zwei parallelen Anfragen:

• mlx-openai-server erreichte 2,17× Beschleunigung — das einzige Framework mit effektivem kontinuierlichem Batching.
• vllm-mlx zeigte Phantom-14000 Tokens/Sek. durch SSE-Parser-Fehler, der gen_tps verzerrt.
• Rapid-MLX fehlt Streaming-Generation, daher entspricht TTFT der Gesamtantwortzeit.
• mlx-omni-server sackte ohne --workers 2 auf 0,85× Beschleunigung ab.
• omlx gab bei Prompts >32768 Tokens HTTP 400 zurück.
• mlx-vlm hatte zyklische Geschwindigkeitsabstürze (790 → 3,5 tok/s) durch GC-Probleme.

Bemerkenswert: Quadratische Attention-Komplexität in manchen Implementierungen ließ 52k-Token-Prefills 31 Minuten statt 2–3 dauern.

Wichtige Erkenntnisse für Entwickler

• Kontinuierliches Batching ist für Multi-Nutzer-Szenarien entscheidend. Nur mlx-openai-server lieferte echte Beschleunigung bei parallelen Anfragen. Andere verarbeiteten sie nicht parallel oder brauchten manuelle Worker-Anpassungen.
• Metriken mit realen Daten validieren. vllm-mlx' Phantom-14000 tok/s stammte von SSE-Stream-Handling-Bugs, was gen_tps unzuverlässig macht.
• Einheitlicher Speicher ist ein Vorteil, aber kein Allheilmittel. Trotz geteilter Pools zählt gestufter KV-Cache (wie bei omlx) bei sehr langen Kontexten.
• Lange Prompts testen. mlx-vlms pathologische Verlangsamung bei >30k-Token-Prompts macht es für Large-Context-Aufgaben unbrauchbar.
• Python-Version beeinflusst Stabilität. Rapid-MLX mit 1900+ Tests war am robustesten, verlor aber bei Batching-Geschwindigkeit.

— Editorial Team