Lokale Coding-Modelle auf einer RTX 3060 mit 12 GB und einem Modell-Scheduler

Mehrere lokale Modelle auf einer 12-GB-GPU

Ein einzelnes LLM lokal zum Laufen zu bringen, ist heute einfach. Spannend wird es, wenn auf einer einzigen 12-GB-Karte mehrere spezialisierte Modelle für Code, Reasoning und Agentenarbeit bereitstehen sollen.

Man stelle sich einen ganz gewöhnlichen Entwicklerrechner vor: eine RTX 3060 mit 12 GB VRAM, ein Ryzen 7 5800, 64 GB RAM und Ubuntu. Das Ziel ist kein lokales Chatfenster. Gesucht sind lokale Modelle, mit denen Coding-Agenten wie OpenCode und andere OpenAI-kompatible Tools wirklich arbeiten können. Damit stehen Programmierfähigkeit, Tool Calling, Kontextgröße und Latenz auf der Liste, dazu noch etwas: zwischen Modellen wechseln, ohne den GPU-Speicher von Hand zu überwachen.

Was 12 GB wirklich leisten

Moderne Modelle mit 7 bis 12 Milliarden Parametern, besonders gut quantisierte, sind auf einer 12-GB-Karte fürs Programmieren echt brauchbar. Die Falle ist, auf das größte Modell zu optimieren, das sich gerade noch laden lässt. Nicht nur die Gewichte belegen VRAM. Kontext, KV-Cache, Laufzeitpuffer und andere Prozesse auf der GPU wollen ebenfalls ihren Anteil.

Coding-Agenten verschärfen das, denn eine einzige Anfrage kann Systemprompt, Tool-Definitionen, Repository-Kontext, Quelldateien und den bisherigen Gesprächsverlauf enthalten, alles übereinandergestapelt.

Die bessere Regel lautet: Betreiben Sie das stärkste Modell, das bequem hineinpasst, nicht das größte, das sich technisch gerade so laden lässt.

Auf begrenzter Hardware ist GGUF mit llama.cpp meist die bessere Wahl, weil Quantisierung und Auslagerung auf CPU und RAM viel Spielraum geben. Auf größeren GPU-Systemen, wo der Durchsatz zählt, wird SafeTensors mit vLLM attraktiv. Und genau daraus entsteht das nächste Problem, denn vielleicht will man beides.

Das eigentliche Problem ist der Wechsel

Ein realistischer Workflow braucht mehr als ein Modell: eines für Code, eines für Reasoning, eines mit geprüftem Tool Calling, ein Embedding-Modell und ein paar experimentelle in der Evaluierung. Eine 3060 kann nicht alle im VRAM halten. Das muss sie auch nicht, solange beim Eintreffen einer Anfrage das richtige geladen ist. Das gewünschte Verhalten sieht ungefähr so aus:

Request → Model B

Und dahinter ein Entscheidungsablauf in dieser Art:

Model B running?
      │
      No
      ↓
Drain Model A
      ↓
Unload Model A
      ↓
Free VRAM
      ↓
Load Model B
      ↓
Health check
      ↓
Serve request

Mit anderen Worten: Die Anfrage entscheidet, welches Modell auf der GPU liegt. An diesem Punkt geht es nicht mehr um Inferenz, sondern um Scheduling.

Warum Ollama oder LM Studio das nicht abdecken

Beide sind sehr gut. Ollama ist einer der einfachsten Wege, ein Modell herunterzuladen und loszulegen, und LM Studio eignet sich hervorragend, um lokale Modelle zu finden, zu konfigurieren und mit ihnen zu experimentieren. Beide bringen auch eine zunehmend leistungsfähige Modellverwaltung mit.

Die Anforderung ist hier etwas anders: Mehrere Anwendungen sollen die gesamte Sammlung lokaler Modelle als gemeinsame Infrastruktur nutzen. Ohne das landet man bei einem Haufen einzelner Ports:

Coding model       → localhost:8081
Reasoning model    → localhost:8082
Experimental model → localhost:8083
vLLM               → localhost:8000

Lieber hätte man, dass alle Clients mit einem einzigen Endpoint sprechen:

OpenCode ────┐
AI Agents ───┤
Python SDK ──┼──→ One OpenAI-compatible API
Node SDK ────┤
Apps ────────┘
                    │
                    ▼
              Model Scheduler
                /        \
               /          \
          llama.cpp       vLLM
              │             │
             GGUF      SafeTensors

Clients sollten nicht wissen müssen, welche Runtime sie bedient. Sie fragen nach einem Modell, und die Infrastruktur klärt, wie es ausgeführt wird.

GGUF Switchboard

Aus dieser Idee wurde GGUF Switchboard, ein Open-Source-Modell-Scheduler für lokale KI-Setups. Er stellt einen OpenAI-kompatiblen Endpoint bereit und kümmert sich darunter um den Lebenszyklus der Modelle. Das Motto ist kurz: ein Endpoint, mehrere lokale Modelle, und die Infrastruktur verwaltet die GPU.

Derzeit konzentriert er sich auf vier Dinge.

Hardwarebewusste Modellsuche. Eine Suche wie diese sollte nicht einfach jedes Qwen-Modell auflisten:

ggs models search "qwen"

Sie sollte zeigen, welche Varianten für den RAM und VRAM, den die Maschine tatsächlich hat, sinnvoll sind.

Wechsel per Anfrage. Braucht eine Anfrage ein anderes Modell, lässt Switchboard die laufende Last auslaufen, entlädt das geladene Modell, lädt das angeforderte und leitet den Traffic dorthin.

Mehrere Inferenz-Backends. Jedes Modellformat ist einer eigenen Runtime zugeordnet:

GGUF → llama.cpp
SafeTensors → vLLM

Clients brauchen keine eigene Konfiguration pro Runtime.

Tests der Tool-Konformität. Ein Modell, das guten Code schreibt, ist innerhalb eines Agenten nicht automatisch zuverlässig. Tool-Auswahl, strukturierte Argumente und Laufzeitverhalten sollten geprüft werden, bevor man einem Modell agentische Workflows anvertraut.

Der Unterschied in einem Satz

Ollama und LM Studio machen es einfach, ein lokales Modell zu betreiben. GGUF Switchboard will den Betrieb eines ganzen Satzes lokaler Modelle langweilig machen. Auf einer 12-GB-GPU ist langweilige Infrastruktur genau das Ziel.

Wo es zu finden ist

Das Projekt ist Open Source und wird auf Consumer-Rechnern und Maschinen mit mehreren GPUs getestet. Das Repository liegt unter https://github.com/pradeepgudipati/gguf-switchboard.

Wer Consumer-Karten mit 8 bis 16 GB betreibt, für den sind die spannenden offenen Fragen: Wie gehen Sie heute mit mehreren Modellen um (ein Modell für alles, manueller Wechsel, Modellverwaltung in Ollama, llama.cpp direkt, ein anderer Scheduler), und welche Modelle haben sich beim Tool Calling in OpenCode, Cline, Cursor oder ähnlichen Agenten als verlässlich erwiesen? Wenn eine Kombination aus Hardware und Modell Probleme macht, ist ein Issue im Repository mit allen Details der nützlichste Bericht, denn echte Konfigurationen treiben die Verbesserungen des Projekts voran.