Teams, die zwischen Apple-nativen Pfaden und dem Hugging-Face-Ökosystem wählen, finden Grundlagen zu GGUF, Parallelität und llama.cpp vs. Ollama in der M4-Inferenz-Matrix. Gateway-seitige Kosten und Routing stehen in der Multi-Modell-Routing-Matrix; Telemetrie-Felder und Sampling in der OpenTelemetry-GenAI-Matrix; RAG-Chunking und Embedding-Batches in lokalem RAG auf dem Mac.
Einsatzszenarien · Batch und Speicher · Abnahme und Monitoring · FAQ
Die häufigsten Brüche sind dreifach: 1) identische Modelle werden mit unterschiedlicher Quantisierung oder Tokenizer-Revision verglichen und liefern falsche Batch-Kurven. 2) lange Kontexte und hohe Parallelität multiplizieren den KV-Cache im gemeinsamen RAM und triggern Kompression oder Swap. 3) interaktive und Batch-Exporte teilen sich eine Queue ohne Deckel — der eine Modus gewinnt im Benchmark und bricht die UI-Latenzen. Ergänzend solltet ihr Thermik und Hintergrund-Indexer im Messfenster still halten, damit Speicher- und Latenzspitzen kausal bleiben.
Einsatzszenarien und Auswahlregeln
MLX-LM priorisieren, wenn ihr Gewichte im MLX-Ökosystem fahren, Apple-Silicon-Kernel voll ausreizen und möglichst wenig PyTorch-Overhead im Hot-Path wollt. Transformers bleiben die erste Wahl, wenn Fine-Tuning, umfangreiche Eval-Pipelines und Hub-Integration bereits auf PyTorch aufbauen und ihr MPS als pragmatischen Laufzeitpfad nutzt. In beiden Fällen gilt: ein Manifest aus Checkpoint-Hash, Quantisierung, maximaler Kontextlänge und Batch-Profil ist Pflicht.
| Kriterium | MLX-LM (Apple-Pfad) | Transformers + MPS |
|---|---|---|
| Primärziel | Hohe Effizienz auf Metal/MLX, schlanke Apple-Silicon-Inferenz | Maximale HF-Kompatibilität, Training und Eval nahe am Hub |
| Batch-Strategie | Kleine effektive Batches für Chat; größere Batches nur im Offline-Profil | Oft Batch eins für interaktive Pfade; Batch > 1 nur mit Profil und Soak |
| KV und Kontext | Strikte Fenster pro Rolle; Cache-Wiederverwendung explizit dokumentieren | Achtung auf Prefill-Sync und Speicherfragmentierung bei langen Prompts |
| Risiko | Tooling außerhalb MLX neu denken | MPS-Kantenfälle und Versionsdrift bei Torch und HF |
Batchgröße und Unified-Memory-Vergleich
Die folgende Tabelle ist bewusst ordinal: absolute Zahlen hängen von Modellfamilie, Quantisierung und Kontext ab. Nutzt sie als Startpunkt und ersetzt Platzhalter durch eure Messreihen. Unified Memory bedeutet: Gewichte, Aktivierungen und KV konkurrieren um denselben Pool — Batch erhöht nicht nur den Durchsatz, sondern auch den gleichzeitigen Speicherdruck.
| Profil | Effektive Batch / Parallelität | Kontext / KV-Fokus | Speicher-Leitplanken |
|---|---|---|---|
| Interaktiv | 1–2 kurze Streams; keine unbounded Queue | 4k–8k effektiv; Zusammenfassung statt endloser Historie | Peak beobachten; Swap vermeiden |
| Assistenz mit Tools | Serielle Phasen; Tool-JSON vor LLM kappen | Kontext nach Tool-Rücklauf neu verdichten | Zwei Peaks: nach Prefill und nach Tool |
| Offline / Export | Höherer Batch nur mit Soak > 10 Minuten | Lange Ausgaben erhöhen Decode-KV linear | Thermik und Speicherdruck im gleichen Fenster messen |
Ausführbare Parameter (Platzhalter): Pfade und Modellnamen anpassen; nie Produktions- und Experimentier-Profile mischen.
# MLX-LM — interaktiver Pfad (Beispiel)
python -m mlx_lm.generate \
--model mlx-community/MODEL-NAME \
--prompt "Kurze Antwort in drei Stichpunkten." \
--max-tokens 512 --temp 0.2
# MLX-LM — Batch/Offline separat messen (eigene Shell-Session)
export MLX_DEFAULT_BATCH_SIZE=1
# falls euer Skript Batch unterstützt: nur im Offline-Profil erhöhen
# Transformers + PyTorch MPS
export PYTORCH_ENABLE_MPS_FALLBACK=1
python infer.py --device mps --batch-size 1 --max-new-tokens 512 \
--attn-implementation sdpa- Zitierbar 1: trennt immer Prefill-Tokens und Decode-Tokens in Logs — sonst verschwinden KV-Effekte in einem Mittelwert.
- Zitierbar 2: dokumentiert Quantisierung und Tokenizer-Revision im Manifest neben dem Checkpoint-Namen.
- Zitierbar 3: definiert p95/p99 für Zeit bis zum ersten Token getrennt für Chat und Batch.
Abnahmeschritte und Monitoring-Kennzahlen
1) Baseline: Kalt- und Warmstart mit identischem Prompt; drei Wiederholungen, Median und Tail notieren. 2) Kontext: Fenster schrittweise erhöhen und KV-Wachstum gegen Speicherpeak legen. 3) Batch: nur im Offline-Profil steigern; bei Swap oder Kompression zurück. 4) Parallelität: gleichzeitige Clients deckeln; Queue in der App statt unbounded im Worker. 5) Fernspiegel: dasselbe Skript auf einem dedizierten Remote-Mac mit dokumentiertem Stundenbudget — Abgleich mit der Routing-Matrix.
Monitoring: tokens_prefill, tokens_decode, batch, device, error_class, latency_first_token und memory_pressure_flag pro Request; Sampling und Kardinalität nach der GenAI-Observability-Matrix begrenzen. Grenzwerte gelten erst nach mindestens zehn Minuten Soak, nicht nach einem Einzelrun.
FAQ
Ist MLX immer schneller als MPS? Nicht pauschal — es hängt von Modell, Quantisierung und eurem Messprotokoll ab. Vergleicht mit fixiertem Checkpoint und getrennten Profilen.
Wann lohnt ein zweiter Knoten? Wenn Batch-Exports und interaktive Nutzer sich Speicher und Thermik teilen und die p95-Latenzen trotz Kontextdisziplin kippen — rechnerisch über Tokens pro Stunde und Tarif gegenrechnen.
Was ist mit RAG? Retrieval und Generator belasten Unified Memory additiv; Chunk- und Embedding-Parameter siehe lokales RAG; Gateway-Kosten siehe Routing-Matrix.
Kurz: MLX-LM und Transformers sind keine Glaubensfrage, sondern eine Budget- und Profilfrage. Gleiche Gewichte, getrennte Messungen, dokumentierte KV- und Batch-Leitplanken — dann sind Apple-Silicon-Entscheide auf dem M4 reproduzierbar und einsatzfähig.