Lokales LLM einrichten: Runtime, Endpunkt und Werkzeuge sauber trennen

Kurz gesagt

• Ein lokales LLM besteht aus drei Teilen: der Runtime, die das Modell lädt, dem Endpunkt, über den es erreichbar ist, und den Werkzeugen, die es nutzen.
• Die Wahl der Runtime entscheidet über die Geschwindigkeit. Auf derselben Hardware kann eine Runtime ein Vielfaches schneller sein als eine andere.
• Ein Endpunkt gehört nie offen ins Internet. Zugriff von außen nur über ein VPN.

Die drei Bausteine

Ein hilfreiches Bild: Das Modell ist wie Wasser aus der Leitung. Die Runtime ist das Wasserwerk, der Endpunkt der Wasserhahn, und an den Hahn lassen sich verschiedene Geräte anschließen, vom Duschkopf bis zum Rasensprenger.

Weil fast alle Runtimes einen Endpunkt im verbreiteten OpenAI-Format anbieten, lassen sich die Teile frei kombinieren. Dasselbe Modell kann gleichzeitig eine Chat-Oberfläche im Browser und ein Coding-Werkzeug auf der Kommandozeile bedienen. Und wenn ein besseres Modell erscheint, tauschen Sie nur die Modelldatei, die Werkzeuge bleiben.

Es gibt auch Komplettpakete, die alles in einer Anwendung bündeln, etwa LM Studio mit eingebauter Chat-Oberfläche. Das ist bequem für den Einstieg. Für den dauerhaften Betrieb ist die Trennung meist die bessere Wahl, weil Sie flexibel bleiben. Prüfen Sie bei Komplettpaketen außerdem, ob einzelne Funktionen ein Konto beim Hersteller verlangen. Das widerspricht dem Gedanken, unabhängig zu sein.

Die Runtime entscheidet über das Tempo

Runtimes unterscheiden sich stark. Ollama und LM Studio sind leicht zu installieren und laufen auf fast jedem Rechner. Für Server mit leistungsstarken Grafikkarten sind spezialisierte Runtimes wie vLLM oft deutlich schneller.

In einem Test von c't 3003 auf einem Server mit Nvidia RTX Pro 6000 erreichte Ollama mit dem Modell Qwen 3.8-27B rund 21 Tokens pro Sekunde, vLLM auf derselben Hardware etwa das Vierfache. Der Unterschied ist auf einem einzelnen Arbeitsplatzrechner in der Regel kleiner, aber auch dort lohnt ein Vergleich.

Faustregel:

• Einzelplatz, Ausprobieren, Mac: Ollama oder LM Studio
• Server mit Nvidia-GPU, mehrere Nutzer gleichzeitig: vLLM
• Maximale Kontrolle über Quantisierung und Speicher: llama.cpp direkt

Werkzeuge: erst damit wird es nützlich

Ein lokales Modell, das nur Fragen beantwortet, bleibt hinter seinen Möglichkeiten. Erst wenn es Werkzeuge nutzen darf, etwa eine Websuche, eine Kommandozeile oder die eigenen Dokumente, spielt es seine Stärken aus. Warum das so ist, erklärt der Beitrag Lokale KI: Was kleine Sprachmodelle heute können.

Zwei typische Arten von Werkzeugen:

• Chat-Oberflächen wie Open WebUI bieten eine Bedienung ähnlich wie ChatGPT im Browser, auf Wunsch mit Websuche und Dokumenten-Upload.
• Coding- und Agenten-Werkzeuge wie OpenCode arbeiten auf der Kommandozeile. Sie nehmen Aufgaben in normaler Sprache entgegen und führen sie auf dem Rechner aus, etwa „sortiere die Bilder in diesem Ordner“ oder „finde heraus, warum dieser Dienst nicht startet“.

Je mehr ein Werkzeug darf, desto sorgfältiger sollten Sie die Rechte festlegen. Ein Agent mit Zugriff auf die Kommandozeile kann auch Dateien löschen.

Einrichtung in fünf Schritten

1. Modell auswählen: Nach Speicher Ihrer Hardware, siehe Hardware für lokale KI. Nehmen Sie eine 4- oder 5-Bit-Variante (Quantisierung).
2. Runtime installieren und das Modell laden. Bei Ollama genügt dafür ein einziger Befehl.
3. Endpunkt prüfen: Antwortet das Modell lokal auf eine Testanfrage? Ollama lauscht in der Voreinstellung nur auf dem eigenen Rechner (127.0.0.1, Port 11434). Das ist gut so.
4. Werkzeuge anschließen: Open WebUI, OpenCode oder andere auf die Adresse des Endpunkts einstellen.
5. Geschwindigkeit messen: Bei langsamen Antworten eine andere Runtime oder Quantisierung ausprobieren.

Abkürzung: Die KI richtet sich selbst ein

Ein pragmatischer Weg aus dem c't-Test: Ein Coding-Agent, etwa mit einem bestehenden Cloud-Abo, bekommt auf dem Zielrechner den Auftrag, ein bestimmtes Modell einzurichten, verschiedene Runtimes und Quantisierungen zu testen und die schnellste Kombination zu wählen. Das funktioniert erstaunlich gut. Zwei Hinweise dazu: Nennen Sie das gewünschte Modell konkret, statt den Agenten selbst suchen zu lassen, denn dabei greift er oft daneben. Und lassen Sie keine vertraulichen Daten auf dem Rechner, solange ein Cloud-Agent dort arbeitet. Ist alles eingerichtet, übernimmt das lokale Modell die weiteren Aufgaben, und der Cloud-Zugang kann wieder weg.

Sicherheit: den Endpunkt nie offen ins Netz

Die meisten Runtimes haben keine eingebaute Anmeldung. Wer die Adresse kennt, kann das Modell benutzen, Rechenleistung verbrauchen und bei angeschlossenen Werkzeugen womöglich mehr tun als nur Fragen stellen. Deshalb:

• Lassen Sie den Endpunkt auf dem eigenen Rechner oder im internen Netz.
• Brauchen Sie Zugriff von unterwegs oder von einem anderen Standort, verbinden Sie die Rechner über ein VPN wie WireGuard oder Tailscale, statt einen Port freizugeben.
• Wenn mehrere Personen das Modell nutzen, schalten Sie eine Oberfläche mit Benutzerkonten davor, etwa Open WebUI.
• Geben Sie Agenten nur die Rechte, die sie für ihre Aufgabe brauchen.

Wie schnell eine gut gemeinte KI-Schnittstelle zum Einfallstor werden kann, haben wir am eigenen Beispiel beschrieben: WebMCP: Wie unser eigener KI-Zugang zum Einfallstor für Spam wurde.

Grenzen

• Die genannten Programme entwickeln sich schnell weiter. Funktionen und Bedienung können sich ändern.
• Geschwindigkeitsvergleiche gelten nur für die getestete Hardware. Messen Sie auf Ihrem eigenen System.
• Lokaler Betrieb ersetzt kein Datenschutzkonzept. Protokolle, Zugriffsrechte und Löschfristen müssen Sie trotzdem regeln.

Quellen

• c't 3003: Was ich über lokale KI gelernt habe, YouTube, September 2026 – https://www.youtube.com/watch?v=M1j_uRqKMKI
• Ollama FAQ (Netzwerk-Voreinstellung) – https://docs.ollama.com/faq
• vLLM: OpenAI-kompatibler Server – https://docs.vllm.ai/en/latest/serving/openai_compatible_server.html
• Open WebUI Dokumentation – https://docs.openwebui.com/