Das Werkzeug auf die Arbeitslast abstimmen, nicht umgekehrt
Ein einziges Modell und ein einziger Agent können Recherche, Coding und Hintergrund-Automatisierung technisch abdecken – aber nicht gut. Ein Reasoning-Modell verbraucht Tokens für interne Deliberation, die ein Bulk-Refactoring nicht braucht; ein Coding-Harness, das das Arbeitsverzeichnis liest, ist für das Verfassen einer E-Mail verschwendet; das Checkpointing eines Long-Horizon-Orchestrators ist in einer interaktiven Sitzung Overhead. Dieses Setup weist stattdessen jede Arbeitslast dem dafür gebauten Agenten und Modell zu und behandelt die 32-GB-Karte als geteilte Ressource, die zeitlich gemultiplext statt partitioniert wird.
Was folgt, ist ein Konzept, kein Benchmark. Die VRAM-Werte sind Modell-Footprints und Budgets; die Ebenen-Zuordnung ist eine architektonische Einschätzung. Die Single-Stream-Disziplin, auf der das Setup beruht, ist dieselbe wie in der Evaluierungsarbeit – hier auf einen Alltags-Operator-Kontext angewandt.
Cockpit, Engineering, Hintergrund
Hermes Agent – Alltag & Recherche
Ein selbst gehosteter Agent mit persistentem, SQLite-gestütztem Gedächtnis und Volltext-Recall über vergangene Sitzungen, autonomer Skill-Erzeugung und isolierten Subagenten für parallele Workstreams; ein temporaler Knowledge-Graph als Gedächtnis ist optional per Plugin verfügbar. Reasoning-lastige Recherche läuft auf DeepSeek-R1 32B – einem per RL trainierten Reasoning-Modell, das Thinking-Tokens für eine autoregressive Chain-of-Thought aufwendet und sich vor der Antwort selbst korrigiert (kein Tree-Search zur Inferenz) – während Gemma 4-31B oder Qwen3.6-35B-A3B Berichte und Korrespondenz verfassen.
Weil das Cockpit nicht vertrauenswürdige, unstrukturierte Daten aufnimmt – eingehende E-Mails, Web-Inhalte – erfordern sensible Aktionen eine explizite [Y/n]-Freigabe und laufen unter Container-Isolierung mit Dropped Linux Capabilities, der Standard-Gegenmaßnahme gegen Indirect Prompt Injection.
OpenCode – Softwareentwicklung
Ein terminal-natives agentisches Coding-Tool, das das Arbeitsverzeichnis liest und über das Repository operiert – aus der Klasse terminal-nativer Coding-Agenten, kein leichtgewichtiger Syntax-Checker. Es läuft mit qwen3-coder:30b, einem Mixture-of-Experts-Modell mit ~3,3B aktiven Parametern pro Token: Sparse-Routing liefert die Tiefe eines Schwergewichts bei der Latenz eines Leichtgewichts, und das 256K-Kontextfenster hält einen Arbeitssatz der Codebase, sodass lange Reviews und automatisierte Testläufe den KV-Cache nicht überlaufen lassen.
OpenClaw – autonome Long-Horizon-Jobs
Ein persistenter Agent für unbeaufsichtigte Mehrstunden-Arbeit, mit Checkpointing, damit ein fehlgeschlagener Sub-Task fortsetzt statt bei null neu zu starten. Er läuft mit Qwen3.6-35B-A3B als Allrounder oder Devstral 24B als Agentic-Coding-Spezialist und übernimmt die Arbeitslasten, bei denen fehlertolerante Orchestrierung wichtiger ist als Latenz – Daten-Ingestion, Hintergrundskripte, Dokument-Assemblierung.
Ein Modell zur Zeit – bewusst, nicht als Kompromiss
Auf einer einzelnen 32-GB-Karte ist nur das Modell einer Ebene zur Zeit resident. Ollama erzwingt das mit OLLAMA_NUM_PARALLEL=1 und OLLAMA_MAX_LOADED_MODELS=1: eingehende Arbeit wird gequeued statt ein zweites Modell zu laden, und ein Ebenen-Wechsel tauscht die residenten Gewichte. Weil jedes Modell mit Reserve passt, aber keine zwei zusammen, ist Single-Residency das Design, kein umgangenes Limit – dieselbe Disziplin, die die Latenzmessungen der Evaluierungs-Pipeline sauber hält.
Der Swap kostet etwas – und wie er bezahlt wird
Time-Multiplexing ist nicht gratis: ein Ebenen-Wechsel entlädt die residenten Gewichte und lädt das nächste Modell ins VRAM. Kalt ist das ein Mehr-Sekunden-Read; warm deutlich weniger, weil die Datei des vorigen Modells noch im OS-Page-Cache im System-RAM liegt – was der Ryzen 7 9850X3D und reichlich RAM zum Normalfall machen. Ollamas keep_alive steuert, wie lange ein Modell resident bleibt, bevor es verdrängt wird. Der Swap wird einmal pro Ebenen-Wechsel bezahlt, nicht pro Request, also amortisieren sich gelegentliche Kontextwechsel sauber; was man nicht tut, ist ihn mitten in einer Arbeitsschleife zu zahlen.
Das Kontext-Budget setzt die eigentliche Grenze
Gewichte sind nur die halbe Miete. Der KV-Cache wächst mit der Kontextlänge, und zwei Ebenen belasten ihn am stärksten: die Coding-Ebene trägt ein 256K-Fenster, und Background-Jobs sammeln lange Historien an. Unkontrolliert ist es dieser Cache – nicht die Gewichte – der die 32 GB sprengen würde. Es gilt dieselbe Disziplin wie in der Evaluierungs-Pipeline: ein q8_0-KV-Cache halbiert ihn grob, und ein begrenzter Working-Set hält ihn in der Reserve. Das ist der konkrete Grund, warum Single-Residency gewinnt – ein Modell mit Platz für seinen vollen Kontext schlägt drei Modelle, die jeweils am Cache verhungern.
Präzision ist ein Hebel je Ebene
Das Footprint-Diagramm nimmt Q4_K_M (~4,5 bpw) an, die Basis, die jedes Modell mit Reserve fasst. Doch Präzision ist ein Hebel je Ebene, keine globale Konstante: die Reasoning-Ebene kann etwas Reserve gegen einen Q5/Q6-Quant tauschen, wenn Fidelity zählt, während Background-Bulk-Jobs bei Q4 für Durchsatz bleiben. Weil nur ein Modell resident ist, ist diese Reserve für die Ebene ausgebbar, die sie braucht – eine weitere Dividende des Nicht-Co-Ladens.
Ein Tag über die drei Ebenen
Ein einzelner Operator bewegt sich zwischen Recherche, Coding und langlaufenden Hintergrund-Jobs auf einer 32-GB-Workstation, wobei keine Cloud-Abhängigkeit erlaubt ist – proprietäres Material und Souveränitäts-Auflagen halten alles lokal.
Jede Arbeitslast dem Agenten und Modell zuweisen, dessen Architektur dazu passt – ohne je die VRAM-Decke zu überschreiten oder ein zweites Modell halb geladen zu lassen.
Alltags-Reasoning und -Schreiben an Hermes (DeepSeek-R1 / Gemma 4), Engineering an OpenCode (qwen3-coder MoE) und unbeaufsichtigte Mehrstunden-Jobs an OpenClaw (Qwen3.6 / Devstral) routen; Ollama tauscht bei jedem Ebenen-Wechsel das einzelne residente Modell.
Jede Aufgabe läuft auf dem dafür passenden Werkzeug, in voller lokaler Geschwindigkeit, ohne VRAM-Kollision und ohne dass Daten die Maschine verlassen – ein kohärentes Single-GPU-Operator-Setup statt dreier Runtimes, die um dieselbe Karte konkurrieren. Das ist das Ziel, auf das das Design ausgelegt ist; die End-to-End-Ergonomie des täglichen Ebenen-Wechsels bleibt zu messen.
Was entworfen ist – und was noch zu belegen bleibt
Der Wert des Setups ist Kohärenz unter einer harten Restriktion: drei Arbeitslasten, drei passende Werkzeuge, eine Karte und eine explizite Regel – ein Modell resident – die ein Speicherlimit in eine saubere Betriebsdisziplin verwandelt.
Entworfen unter CTC AI Operations, auf derselben Single-GPU-Disziplin wie die Evaluierungs-Pipeline.