Ein einzelnes Basismodell plus mehrere LoRA-Adapter spart Speicher — verschärft aber Wechselkosten und Kontextdruck auf dem gemeinsamen Unified-Memory-Bus. Wer 2026 Agenten lokal fährt, braucht eine klare Matrix: wann lohnt Hot-Swap, wann ein zweites Modell-Tag, und wie ihr Remote-Stunden gegen messbare Token-SLAs abnehmt.

Diese Matrix richtet sich an Teams, die auf Apple Silicon mit Ollama arbeiten und zwischen Fach-Adaptern (Code, Support, interne Terminologie) wechseln. Grundlagen zu Kontext, Batch und Metal: M4-Inferenz-Matrix (llama.cpp vs. Ollama). Remote-Gateway und Stundenbudget: Multi-Modell-Routing- und Kostenmatrix. Retrieval- und Chat-Parallelität ohne Speicher-Kollision: lokale RAG-Matrix (Chunks, Embeddings, Kontingente).

Warum „Hot-Swap“ auf dem Mac kein Marketingwort ist

Hot-Swap bedeutet hier: minimale Unterbrechung beim Wechsel des Adapters auf derselben Basis-GGUF, ohne dass Desktop-Apps und der KV-Cache das System in den Kompressionsmodus treiben. Praktisch bleibt die Basis geladen; der Adapterwechsel kostet aber weiterhin Planungszeit, weil Ollama pro definiertem Modell einen konsistenten Graphen materialisiert. Zu großzügige Parallelität (OLLAMA_NUM_PARALLEL) multipliziert Worst-Case-KV — genau dort scheitern viele „es lokal schnell“-Demos.

Die Entscheidung ein Basismodell / mehrere Adapter vs. mehrere vollständige Tags hängt vom Unified-Memory-Budget ab: Adapter sind klein, aber Basis plus mehrere geladene Slots können schneller die Komfortzone verlassen als eine einzelne große GGUF-Datei mit einem Adapter zur Zeit.

Ollama Modelfile: Basis fixieren, Adapter einhängen

Ein typisches Modelfile verankert die Basis über FROM und den LoRA über ADAPTER (Pfade an eure Blob-Struktur anpassen). Parameter wie PARAMETER num_ctx und num_batch sollten pro Adapter-Tier identisch sein, damit Benchmarks vergleichbar bleiben — sonst mischt ihr Qualitäts- mit Scheduling-Effekten.

# Modelfile.beispiel — Pfade/Modellnamen anpassen FROM ./models/basis.Q4_K_M.gguf ADAPTER ./adapters/fachbereich-a.gguf PARAMETER num_ctx 8192 PARAMETER num_batch 512 TEMPLATE """{{ .System }} ...""" # Modell bauen und prüfen ollama create fach-a -f ./Modelfile.fach-a ollama show fach-a --modelfile

Nach einem Wechsel immer ollama ps lesen: residente Modelle, VRAM-/RAM-Signale und unerwartete Doppel-Loads sind die ersten Hinweise auf ein Konfigurations- oder Client-Problem.

Kontext-„Defragmentierung“: weniger KV-Wildwuchs

Unter Kontext-Defragmentierung fassen wir alles, was lange Chats ohne Neu-Ladevorgang erträglich hält: harte Caps für System- und Tool-Texte, periodische Zusammenfassung in einen kompakten Turn, gleitende Fenster für Nebenkanäle und strikte Trennung von „Archiv-JSON“ vs. „aktuelle Aufgabe“. Das ist keine Festplatten-Defragmentierung, sondern eine Budgetierung der aktiven Token, damit der KV-Cache nicht mit irrelevanten Vorspannungen vollläuft.

Agenten-Pipelines sollten Retrieval und Chat nicht blind parallel fahren; sonst konkurriert eure Indexierung mit dem Adapterwechsel um Bandbreite — mit zusätzlicher Adapter-Latenz beim ersten Token nach dem Swap.

Durchsatz, Latenz und der erste Token nach dem Swap

Durchsatz (Tokens pro Sekunde im Decode) und Latenz (Zeit bis zum ersten sichtbaren Token nach Prompt oder Rollenwechsel) ziehen an unterschiedlichen Hebeln. Höhere num_batch-Werte können das Prefill beschleunigen und den Durchsatz in kurzen Turns schönrechnen — bis der Speichercontroller am Unified-Memory-Knie ankommt und das System komprimiert oder thermisch drosselt. Nach einem Adapterwechsel dominiert häufig nicht der mittlere Decode, sondern die p95-Latenz zum ersten Token, weil Graph und Cache neu verdichtet werden müssen.

Wählt daher eine Kennzahl pro Anwendungsfall: interaktive Assistenten optimieren p95 und Worst-Case; Batch-Exporter und Nachtjobs optimieren nachhaltige Tokens/Stunde über 10–30 Minuten Soak. Mischt ihr beides auf einem Rechner, trennt Zeitfenster oder Knoten — sonst „gewinnt“ der Batch-Modus im Benchmark und verliert die Produkt-UI zur Hauptgeschäftszeit.

Strategie Ein Basismodell, Adapterwechsel VRAM / Unified Memory Durchsatz vs. Latenz
Ein Tag pro Adapter Klare Trennung; Wechsel = neues ollama run-Ziel Basis einmal; Adapter klein — aber jeder Slot mit Kontext multipliziert KV Nach Wechsel oft höhere erste Token-Latenz; stabiler Decode, wenn Parallelität passt
Wenige Tags, viele Rollen per Prompt Weniger Reloads, mehr Prompt-Disziplin Günstiger Peak, riskanter bei langen Systemblöcken Besserer Durchsatz bei kurzen Turns; schlechtere Worst-Case-Latenz bei Riesenprompts
Zweiter physischer Knoten Remote-Mac nur für Schwergewichts-Adapter oder Nachtjobs Lokaler Komfort vs. Mietkosten; keine Desktop-Konkurrenz Netz-Latenz hinzu; planbare Tokens/Stunde oft wertvoller als lokale Spitzen

Checkliste: Budget, Last, Abnahme

  • Einheitliches Kontext-Limit pro Adapter-Tier in Clients und Gateway erzwingen; kein „mal 32k probieren“ neben Produktionspfad.
  • Parallelität: OLLAMA_NUM_PARALLEL nur so hoch wie eure Unified-Memory-Reserve trägt; Queue in der App statt Daemon-Überfütterung.
  • Swap-Messung: p95 Zeit bis zum ersten Token nach Adapterwechsel, nicht nur mittlere Decode-Rate über gemischte Sessions.
  • Manifest: Basis-GGUF-Hash, Adapter-Version, Ollama-Release, num_ctx/num_batch im Runbook — dieselben Felder wie in der oben verlinkten Inferenz-Matrix.
  • Remote-Kostenabnahme: Stundenbudget × erwartete Tokens/Stunde gegen Tarif und SLA; Fallback auf zweiten Knoten nur mit dokumentiertem Gewinn — Abgleich mit der Routing-/Kostenmatrix.

Ausführbare CLI-Snippets und Kurz-Abnahme

# Parallelität für lokale Experimente deckeln (Shell-Session) export OLLAMA_NUM_PARALLEL=1 # Laufende Last und Modellnamen ollama ps # Kurz-Benchmark: erster Token nach Wechsel (manuell oder Skript) ollama run fach-a "Kurzantwort: Zwei Bulletpoints zu Latenz." ollama run fach-b "Kurzantwort: Zwei Bulletpoints zu Durchsatz."

Abnahmeschritte (lokal): (1) Kaltstart und Warmstart mit identischem Prompt messen. (2) Zwei Adapterwechsel im selben Prozess bzw. zwei Tags — p95 erste Token notieren. (3) Zehnminütigen Soak mit erwarteter Parallelität; Swap- und Kompressionsaktivität in der Aktivitätsanzeige beobachten. (4) Abweichung > vereinbarte Schwelle: num_batch senken oder Kontext kappen, nicht blind aktualisieren.

Abnahmeschritte (Remote-Knoten): dieselben Kennzahlen, plus Netz-Roundtrip und Stundenlimit im Konsole-/Tarifmodell. Wenn Remote nur Entlastung ist, dokumentiert die Kostenmatrix die Entscheidungspflicht vor dem zweiten Knoten.

Kurz: Multi-LoRA spart Gewichte, nicht Disziplin. Modelfile und Manifeste pinnen, Kontext aktiv verkürzen, Parallelität begrenzen — und Remote-Stunden nur kaufen, wenn die Token-SLA gegenüber dem lokalen Unified-Memory-Konflikt rechnerisch gewinnt.