Drei sehr unterschiedliche Agent-Workloads – ein interaktives kognitives Cockpit, eine agile Software-Engineering-Umgebung und eine autonome Long-Horizon-Fabrik – jeweils gepaart mit dem Framework und dem Open-Weight-Modell, dessen Architektur zum Kostenmodell des Workloads passt. Weil schon das kleinste tragfähige Modellpaar die 32 GB-Obergrenze überschreitet, baut das Design auf strikter Single-Residency: genau ein Modell resident, ein Tier-Wechsel tauscht es aus.
Design & Operator-SetupArchitektur und Fit gemessen · Durchsatz und Swap-Kosten als falsifizierbare Kriterien formuliert
Eine Karte. Drei Workloads.
Ein Modell für alles ist die falsche Optimierung.
Reasoning, Coding im Repository-Maßstab und unbeaufsichtigte Automatisierung belohnen drei verschiedene Architektureigenschaften – und bei Q4 passen keine zwei der relevanten Modelle zusammen in 32 GB.
Die Versuchung bei einer leistungsfähigen lokalen Karte ist, ein großes Modell für alles laufen zu lassen. Das ist die falsche Optimierung: Reasoning-lastige Recherche, Software-Engineering im Repository-Maßstab und unbeaufsichtigte Long-Horizon-Automatisierung belohnen drei verschiedene Architektureigenschaften – und alle zugleich zu bezahlen verschwendet VRAM wie Latenz. Die prägende Beschränkung ist der Speicher: Bei Q4 belegen die relevanten Open-Weight-Modelle je 15–24 GB, keine zwei passen also zusammen auf 32 GB. Das Design ko-lokiert deshalb keine Modelle; es time-multiplext ein einzelnes residentes Modell über drei Tiers – und investiert sein Engineering-Budget darin, das richtige Modell je Tier zu wählen und den Wechsel dazwischen günstig und sicher zu machen.
Das Setup arbeitet vor dem Hintergrund dreier Stränge der Systems-Literatur: lokalem Paged-Attention-Serving und der Memory-Bandwidth-Wall, Modell-Routing (jede Anfrage an das günstigste Modell schicken, das sie beantworten kann – hier über die Zeit auf einer Karte geroutet statt über eine Flotte) und dem Cold-Start-Problem des Serverless-LLM-Servings, dessen Checkpoint-Ladelatenz dieses Design nicht allgemein löst, sondern ehrlich budgetiert. Der Beitrag ist kein neues Serving-System: Es ist eine disziplinierte Operator-Komposition, die ein Solo-Operator auf Commodity-Hardware tatsächlich betreiben und durchdringen kann.
Drei Tiers, dem Workload zugeordnet.
Jedes Tier paart einen Workload mit dem Agent-Framework und der Open-Weight-Modellklasse, deren Architektur zu ihm passt. Nur ein Modell ist zu jedem Zeitpunkt resident; ein Tier-Wechsel tauscht es.
Wähle die Architektur, deren Kostenmodell der Workload bezahlen kann – und gib VRAM oder Latenz nie für eine Eigenschaft aus, die das Tier nicht nutzt.
Jedes einzelne Modell passt.
Keine zwei zusammen.
Der Fit-Envelope, der das Design erzwingt – und die Swap-Kosten, die es sich dafür einhandelt: ehrlich benannt statt weggelassen.
Zwei ehrliche Einschränkungen bleiben. Es gibt keine echte Tier-übergreifende Parallelität: Ein unbeaufsichtigter Tier-3-Job hält die Karte, interaktive Arbeit wartet also, sofern der Operator nicht darum herum plant. Und CUDA-Speicherfragmentierung akkumuliert über wiederholte Load/Unload-Zyklen – freier zusammenhängender VRAM muss überwacht und der Server periodisch neu gestartet werden.
Die Gewichte setzen die Untergrenze.
Der Rest ist Kontext-Budget.
Zwei Zahlen entscheiden, ob ein Tier nutzbar ist: wie schnell es generiert und wie viel Kontext es halten kann – und die zweite beschränkt das Design stärker, als die Modellgröße vermuten lässt.
Zwei Konsequenzen folgen. Die Generierung ist bandbreitenlimitiert: Ein MoE, das pro Token nur ~3B aktive Gewichte liest, hält 2–4× die Token-Rate eines dichten Modells ähnlicher Gesamtgröße – exakt der Grund, warum Coding- und Allrounder-Tier MoE nutzen und das dichte Reasoning-Modell pro Token am langsamsten ist. Und das frühere „passt mit Reserve“ wird präzisiert: Jedes Modell passt, aber der nutzbare Kontext je Tier unterscheidet sich deutlich.
Fünf Abnahmekriterien, A1–A5.
Ein Design- & Operator-Setup, keine vermessene Benchmark-Studie – die zentralen Aussagen sind deshalb als falsifizierbare Abnahmekriterien mit Instrumenten und Schwellen formuliert, in derselben Measured/Predicted-Disziplin wie die Schwester-Papers. Mit [vorgeschlagen] markierte Schwellen sind Defaults zur Bestätigung.
Die Workstream-Hypothese: Single-Residency-Time-Multiplexing bedient drei Modell-Tiers in 32 GB ohne VRAM-Kollision, zu begrenzten, planbaren Swap-Kosten. Alle fünf Kriterien laufen auf demselben Single-GPU-Setup, air-gapped, plus dem Evaluierungs-Harness, den das Programm bereits enthält.
Sicherheit wird verifiziert, nicht angenommen.
Das risikoreichste Tier ist Tier 3: ein unbeaufsichtigter, langlaufender, hochprivilegierter autonomer Agent – und für das gewählte Tooling ist das Risiko nicht hypothetisch. OpenClaws rasanter Aufstieg kam mit einer gravierenden, dokumentierten Sicherheitsbilanz: eine kritische Remote-Code-Execution-Lücke über einen unvalidierten lokalen WebSocket, eine verkettete Reihe von Sandbox-Escape- und Privilege-Escalation-Schwachstellen („Claw Chain“, Allowlist-Bypass mit CVSS 8,8) und ein Supply-Chain-Problem des Marketplace – ein unabhängiges Audit fand 341 bösartige Einträge unter 2.857 Skills. Sicherheit ist deshalb eine Querschnittsanforderung – am strengsten angewandt, wo Autonomie und Privilegien am höchsten sind, und durch Kriterium A5 verifiziert, nicht angenommen.
Das Drei-Tier-Design ist nur in dem Maße sicher zu betreiben, wie die Isolationsschicht real ist – die Bequemlichkeit eines autonomen Hintergrund-Agenten ist exakt proportional zur Disziplin der Sandbox um ihn herum.
Drei Workloads, eine Karte, souverän.
- Situation. Ein unabhängiger ML-Operator braucht einen interaktiven Recherche-Assistenten, einen Coding-Agenten im Repository-Maßstab und einen unbeaufsichtigten Overnight-Automatisierungsagenten – mit einer 32 GB-Karte, einer Datensouveränitäts-Auflage und ohne Budget für ein Multi-GPU-Rig oder Cloud-Abos je Workload.
- Aufgabe. Alle drei auf der einen Karte betreiben, jedes mit einem Modell, dessen Architektur zu seinen Kosten passt – ohne VRAM-Kollisionen, mit planbarer Wechsel-Latenz und mit sicher eingehegtem unbeaufsichtigtem Agenten.
- Vorgehen. Strikte Single-Residency konfigurieren; DeepSeek-R1/Gemma4 dem Tier 1, qwen3-coder dem Tier 2, Devstral dem Tier 3 zuweisen; das meistgenutzte Tier warmhalten; Kontext je Tier unter q8_0-KV-Cache budgetieren; jede modellgesteuerte Aktion in der gehärteten, netzlosen Sandbox ausführen.
- Ergebnis. Drei leistungsfähige Agent-Workloads aus einer Commodity-Karte – getauscht statt ko-geladen, zu Wechselkosten, um die der Operator planen kann, mit einem Automatisierungs-Tier, dessen Sicherheit auf einer verifizierten Isolationsschicht ruht. Voll souverän, re-derivierbar aus der fixierten Konfiguration.
Limitationen – vorab benannt.
- Keine echte Nebenläufigkeit. Strikte Single-Residency heißt: Ein unbeaufsichtigter Tier-3-Job blockiert interaktive Tier-1-Arbeit; Operatoren mit nahezu ständiger interaktiver Nutzung sollten die Variante „kleines Modell dauerhaft resident, großes getauscht“ bevorzugen – zum Preis im Fit-Budget.
- Externe Performance-Zahlen. Die Envelope-Zahlen sind publizierte Benchmarks für diese Modellklassen, keine eigenen Deployment-Messungen – die operativen Aussagen gelten als prognostiziert, bis A2–A4 gelaufen sind.
- Modellverfügbarkeit und Drift. Die konkreten Open-Weight-Modelle sind ein Schnappschuss von 2026; das Design ist ein Mapping von Workload auf Architekturklasse, das jeden einzelnen Checkpoint überlebt – aber exakte Footprints und Raten werden sich bewegen.
- Sicherheit ist nur so real wie die Sandbox. Das Tier-3-Bedrohungsmodell wird durch Container-Isolation verteidigt, deren Wirksamkeit behauptet bleibt, bis A5 gegen die konkreten OpenClaw-Angriffsklassen gelaufen ist – ein Containment-Versagen dort würde die Aussage „sicher unbeaufsichtigt zu betreiben“ entwerten; deshalb ist A5 tragend und keine Formalie.