Lokale KI einrichten heißt: ein offenes Sprachmodell auf eigener Hardware installieren und über eine lokale Schnittstelle ansprechbar machen. Der schnellste Einstieg ist Ollama auf dem Mac, in ein paar Minuten fertig. Wer mehr Kontrolle will, geht über LM Studio, und wer ein Modell im Dauerbetrieb mit paralleler Last laufen lassen will, landet bei einem eigenen Server mit vLLM oder SGLang.
Ich betreibe mein eigenes Modell inzwischen auf einem Server mit SGLang, nachdem ich denselben Weg über Ollama und LM Studio gegangen bin, den dieser Beitrag beschreibt. Mehr zu meinem Setup und wann sich der Aufwand überhaupt lohnt, steht auf der Seite KI und im Überblick Lokale KI: was 2026 wirklich geht.
Die drei Stufen bauen aufeinander auf: Jede folgende Stufe kostet mehr Einrichtungszeit, bringt dafür aber mehr Kontrolle über Geschwindigkeit, parallele Anfragen und Ressourcen. Du musst nicht bei Stufe drei landen. Für viele Aufgaben reicht Ollama völlig, und der Wechsel auf einen eigenen Server lohnt sich erst, wenn ein Modell wirklich dauerhaft und für mehrere Anfragen gleichzeitig laufen soll.
Vorwissen in Systemadministration braucht keine der drei Stufen. Alle vier Werkzeuge bringen eine dokumentierte Kommandozeile mit, und die Befehle unten stehen so in den jeweiligen offiziellen Dokumentationen. Was sich zwischen den Stufen unterscheidet, ist weniger die Schwierigkeit einzelner Befehle als der Aufwand für Betrieb, Überwachung und Absicherung, sobald ein Modell dauerhaft erreichbar sein soll statt nur für ein einzelnes Gespräch.
Lokale KI einrichten, Stufe 1: Ollama auf dem Mac
Ollama installierst du laut offizieller Doku mit einem Install-Skript, danach lädst du ein Modell und startest es direkt im Terminal:
curl -fsSL https://ollama.com/install.sh | sh
ollama pull gemma4
ollama run gemma4
Ein Hinweis zu den Befehlen: gemma4 steht hier nur als Beispielmodell, weil es klein genug für den ersten Versuch ist. Mein eigenes Setup läuft nicht über Ollama, sondern über SGLang mit Qwen 3.8, das weiter unten in dieser Anleitung kommt. Die Ollama-Befehle taugen für den Einstieg und für schnelle Tests, nicht als Abbild meiner Produktionsumgebung.
ollama pull lädt das Modell einmal herunter, ollama run startet ein Gespräch im Terminal und lädt das Modell dabei automatisch, falls es noch fehlt. Läuft mehr im Hintergrund, hilft ollama ps, um zu sehen, was gerade geladen ist, ollama stop gemma4, um es wieder freizugeben, und ollama rm gemma4, um es ganz von der Platte zu entfernen. Wer ein Modell mit eigenen Standardeinstellungen speichern will, baut sich mit ollama create -f Modelfile eine eigene Variante.
Für den Einstieg reicht das völlig: kleine bis mittelgroße offene Modelle laufen auf einem aktuellen Mac mit Apple-Silicon-Chip auch ohne dedizierte Grafikkarte, weil der Arbeitsspeicher dort direkt mitgenutzt wird. Ollama ist dabei bewusst schlank gehalten, ein einziger Befehl reicht vom Download bis zum ersten Gespräch, das macht es zum naheliegenden ersten Schritt, wenn du lokale KI einrichten willst, ohne dich vorher mit Quantisierungsformaten oder Serving-Frameworks zu beschäftigen. Details zu allen Befehlen stehen in der Ollama-Dokumentation.
Lokale KI einrichten, Stufe 2: LM Studio für mehr Kontrolle
LM Studio bringt neben der grafischen Oberfläche ein eigenes Kommandozeilenwerkzeug namens lms mit. Damit lädst du ein Modell gezielt mit bestimmten Einstellungen und startest bei Bedarf einen lokalen Server für andere Programme:
lms get
lms load --gpu=max --context-length=32768
lms server start
lms get öffnet die Modellsuche, lms load lädt ein bereits heruntergeladenes Modell mit den gewünschten Grafikkarten- und Kontexteinstellungen, lms ps zeigt, was gerade im Speicher liegt, und lms server start öffnet eine lokale Programmierschnittstelle, mit der sich andere Werkzeuge verbinden. Der Unterschied zu Ollama liegt vor allem in der Kontrolle: Du siehst in der Oberfläche direkt, wie viel Arbeitsspeicher ein Modell belegt, kannst Kontextlänge und Grafikkartennutzung pro Modell einstellen und mehrere Varianten desselben Modells parallel vorhalten.
Ich selbst nutze LM Studio auf einem MacBook Pro M3 Max, um ein 27 Milliarden Parameter großes Modell mit 8-Bit-Quantisierung und rund 27,5 GiB Arbeitsspeicher laufen zu lassen, dort komme ich auf 11 Tokens pro Sekunde. Für gelegentliche Aufgaben und zum Testen, ob ein Modell für einen bestimmten Zweck überhaupt taugt, reicht das völlig, für Dauerbetrieb mit mehreren gleichzeitigen Anfragen wird es eng. Die vollständige Befehlsliste steht in der LM-Studio-CLI-Doku.
Lokale KI einrichten, Stufe 3: vom Mac auf den Server
Sobald mehrere Anfragen gleichzeitig bedient werden sollen oder ein größeres Modell dauerhaft laufen soll, lohnt sich ein eigener Server mit einer dedizierten Grafikkarte statt eines Mac im Dauerbetrieb. Der Grund liegt in der Architektur: Ollama und LM Studio sind für den Einzelplatz gebaut, ein Nutzer, eine Anfrage nach der anderen. vLLM und SGLang sind Serving-Frameworks, gebaut dafür, viele Anfragen gleichzeitig effizient über dieselbe Grafikkarte laufen zu lassen, mit eigenem Speicher-Management für den Kontext jeder Anfrage.
vLLM installierst und startest du laut Quickstart so:
uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto
vllm serve Qwen/Qwen2.5-1.5B-Instruct
Der Server läuft danach standardmäßig unter http://localhost:8000 und lässt sich über --host und --port anpassen. SGLang installierst und startest du so:
pip install uv
uv pip install --prerelease=allow sglang
python3 -m sglang.launch_server --model-path meta-llama/Llama-3.1-8B-Instruct --host 0.0.0.0 --port 30000
Ich selbst betreibe mein Modell unter SGLang, weil es bei mir das offizielle Cookbook-Rezept für den Checkpoint war, den ich einsetze, inklusive Speculative Decoding mit einem eigenen Draft-Modell. vLLM habe ich als Alternative getestet und kam auf 24 bis 26 Tokens pro Sekunde. Beide Frameworks sind für Dauerbetrieb gebaut, beide brauchen deutlich mehr Einarbeitung als Ollama oder LM Studio, dafür bekommst du eine Programmierschnittstelle, die sich von mehreren Programmen gleichzeitig nutzen lässt, statt eines einzelnen lokalen Chatfensters. Die Messwerte im Detail stehen in Qwen 3.8 lokal: Erfahrung mit DGX Spark. Offizielle Quellen: vLLM-Quickstart und SGLang-Installationsanleitung.
Ollama, LM Studio, vLLM und SGLang im Überblick
Hinter den vier Namen stecken vier verschiedene Schichten: Ollama und LM Studio sind Wrapper um eine Inferenz-Engine, gebaut für den Einzelplatz mit möglichst wenig Einrichtungsaufwand. vLLM und SGLang sind Serving-Frameworks, gebaut dafür, dieselbe Grafikkarte für viele gleichzeitige Anfragen effizient auszunutzen, mit eigenem Speicher-Management für Kontext und Zwischenergebnisse jeder einzelnen Anfrage. LM Studio unterscheidet sich von Ollama vor allem durch die grafische Oberfläche und die feinere Kontrolle über Grafikkarten- und Speichereinstellungen pro Modell, technisch bleiben beide aber Werkzeuge für einen Nutzer zur selben Zeit.
| Werkzeug |
Schicht |
Am besten für |
Einrichtungszeit |
| Ollama |
Wrapper mit Kommandozeile |
Schneller Einstieg, ein Nutzer |
Minuten |
| LM Studio |
Oberfläche plus Kommandozeile |
Modelle testen und vergleichen |
Minuten |
| vLLM |
Serving-Framework |
Parallele Anfragen auf einer Server-Grafikkarte |
Stunden |
| SGLang |
Serving-Framework |
Dauerbetrieb mit Speculative Decoding |
Stunden |
Die Faustregel, die ich selbst anwende: Solange ein Modell nur ich befrage, reichen Ollama oder LM Studio. Sobald ein Agent, ein Skript und ich gleichzeitig auf dasselbe Modell zugreifen wollen, oder sobald ein Modell rund um die Uhr erreichbar sein soll, wechsle ich zu einem Serving-Framework auf einem eigenen Server. Zwischen vLLM und SGLang selbst entscheidet bei mir vor allem, für welchen Checkpoint gerade das offizielle Setup-Rezept vorliegt, beide Frameworks decken den Dauerbetrieb ähnlich gut ab.
Woran du merkst, dass die Einrichtung passt
Bevor du ein Modell produktiv nutzt, teste drei Dinge: eine kurze Zusammenfassung eines eigenen Textes, eine einfache Coding-Aufgabe mit bekanntem richtigen Ergebnis und dieselbe Frage einmal mit hoher und einmal mit niedriger Denktiefe. Viele Modelle liefern mit maximaler Denktiefe zwar bessere Antworten, brauchen dafür auf normaler Hardware aber ein Vielfaches der Zeit, bei manchen Aufgaben mehrere Minuten für eine einzige Antwort. Ich schalte die Denktiefe deshalb standardmäßig herunter und erhöhe sie nur für Aufgaben, bei denen es wirklich nötig ist. Ein zweiter Test lohnt sich für das Kontextfenster: Gib dem Modell einen längeren eigenen Text und prüfe, ob es am Ende noch zuverlässig auf Details vom Anfang zugreift, viele offene Modelle werden gegen Ende ihres angegebenen Kontextfensters spürbar unzuverlässiger. Und ein dritter Test lohnt sich für die Werkzeugnutzung, falls du das Modell später an einen Agenten anbinden willst: Lass es eine einfache Aufgabe mit einem einzelnen Werkzeug lösen, etwa eine Datei lesen und zusammenfassen, bevor du ihm etwas Komplexeres mit mehreren Werkzeugen gibst.
Fehler, die mir dabei passiert sind
Der Fehler, der mich am meisten Zeit gekostet hat, betrifft den Speicheranteil für das Modell: Auf Hardware, bei der CPU und GPU sich denselben Arbeitsspeicher teilen, sollte --mem-fraction-static bei SGLang nie über 0,50 liegen, sonst kann der ganze Host einfrieren, weil für das Betriebssystem nichts mehr übrig bleibt. Warum das gerade bei Unified Memory so heikel ist, beschreibe ich in DGX Spark im Test: lohnt sich der Kauf? Weil ich auf meinem Server kein passwortloses Systemverwalter-Recht habe, läuft der Dienst als systemd-Nutzereinheit mit aktiviertem Linger, damit er auch ohne offene Sitzung weiterläuft. Und die Internetleitung an meinem Standort schafft nur rund 2 MB pro Sekunde, der Download eines 70-GB-Modells dauert damit mehrere Stunden, das solltest du beim Zeitplan einrechnen, bevor du am Abend noch schnell ein neues Modell laden willst. Die übrigen Stolperfallen aus meinem eigenen Aufbau, von der Startzeit bis zum Speicherlimit von Docker, stehen in Qwen 3.8 lokal: Erfahrung mit DGX Spark.
Terminal-Agent anbinden statt nur chatten
Sowohl Ollama als auch LM Studio, vLLM und SGLang stellen eine Programmierschnittstelle bereit, die sich wie die von OpenAI oder Anthropic ansprechen lässt. Damit kannst du einen Terminal-Coding-Agenten wie Pi gegen dein lokales Modell laufen lassen, statt es nur über den Chat zu nutzen: Der Agent schickt seine Anfragen an die lokale Adresse statt an einen Cloud-Endpunkt, alles andere bleibt gleich. Ich mache genau das, um mein lokales Setup gegen Claude Code zu vergleichen, mit dem meine KI-Belegschaft läuft. Gedacht ist das für Kunden, bei denen Cloud vertraglich ausgeschlossen ist, nicht als Ersatz meiner Belegschaft. In der Praxis heißt das: derselbe Agent, dasselbe Kommandozeilenwerkzeug, dieselben Aufgaben, nur mit einer anderen Adresse in der Konfiguration und ohne API-Kosten pro Anfrage.
Häufige Fragen
Ollama oder SGLang: was passt für den Einstieg?
Für den Einstieg und gelegentliche Nutzung reicht Ollama völlig, es ist in Minuten eingerichtet und braucht keine Server-Vorkenntnisse. SGLang lohnt sich erst, wenn ein Modell dauerhaft läuft und mehrere Anfragen gleichzeitig bedienen soll, dafür brauchst du dann auch mehr Zeit für die Einrichtung.
Brauchst du zwingend eine Grafikkarte?
Für kleinere Modelle nicht, aktuelle Mac-Hardware mit viel Arbeitsspeicher reicht über Ollama oder LM Studio völlig aus. Für größere Modelle im Dauerbetrieb brauchst du auf einem Server entweder eine dedizierte Grafikkarte oder eine vergleichbare Unified-Memory-Architektur, wie ich sie selbst einsetze.
Läuft vLLM auch auf einem Mac?
Laut offizieller Doku ist vLLM in erster Linie für Server mit Nvidia-Grafikkarten ausgelegt. Für den Mac sind Ollama und LM Studio der praktischere Weg, vLLM und SGLang gehören auf einen eigenen Server mit entsprechender Hardware.
Wie deaktivierst du Cloud-Funktionen in Ollama?
Ollama läuft standardmäßig lokal und schickt Anfragen nur an dein eigenes Modell auf deiner eigenen Hardware. Zusätzliche Integrationen, die auf fremde Dienste zugreifen, sind optional und lassen sich einfach ungenutzt lassen, wenn du ausschließlich lokal arbeiten willst.
Wie bindest du einen Terminal-Agenten an das lokale Modell an?
Du zeigst dem Agenten die lokale Adresse des Servers, zum Beispiel http://localhost:11434 bei Ollama oder http://localhost:30000 bei SGLang, statt eines Cloud-Endpunkts. Die meisten Terminal-Agenten, die mit der OpenAI- oder Anthropic-Schnittstelle sprechen, lassen sich so ohne größere Umbauten umbiegen.
Wie viel Speicherplatz brauchen die Modelle auf der Platte?
Das hängt von Größe und Quantisierung ab: Ein Modell mit rund 27 Milliarden Parametern liegt je nach Kompression zwischen etwa 17 und knapp 56 GB. Rechne zusätzlich Puffer für weitere Modelle ein, die du zum Vergleichen herunterlädst, und für Container-Images, falls du vLLM oder SGLang über Docker betreibst.
Wie du weitermachst
Wenn du erst prüfen willst, ob sich der Aufwand für dich lohnt, lies zuerst Lokale KI: was 2026 wirklich geht mit der Entscheidungshilfe Cloud gegen lokal. Für die Kostenseite von Hardware und Strom im Dauerbetrieb steht Eigener KI-Server: Hardware und Kosten bereit.
Mein Rat aus der eigenen Einrichtung: Fang mit Ollama auf einem vorhandenen Mac an, bevor du in Serverhardware investierst. Erst wenn du an die Grenzen von Stufe eins oder zwei stößt, weil eine Aufgabe dauerhaft und parallel laufen soll, lohnt sich der Sprung zu vLLM oder SGLang.
