LocalAI einrichten: 12 Schritte, 49.223 Stars [2026]

Wer heute eine KI-Anwendung baut, landet fast automatisch bei der OpenAI-API. Das Problem: Jede Anfrage verlässt das eigene Netz, kostet pro Token und hängt von der Verfügbarkeit eines fremden Rechenzentrums ab. LocalAI löst genau dieses Problem. Das Open-Source-Projekt von Ettore Di Giacinto stellt exakt dieselbe API-Signatur bereit wie OpenAI und Anthropic, läuft aber komplett auf eigener Hardware, ohne GPU-Zwang und ohne Cloud-Vertrag. Am 17. September 2026 erschien Version 4.10.0, und das Projekt steht laut GitHub-API vom 22. September 2026 bei 49.223 Sternen und 4.460 Forks, bei einer MIT-Lizenz, die kommerzielle Nutzung ohne Einschränkung erlaubt. Dieser Guide zeigt in zwölf Schritten, wie Sie LocalAI unter Docker installieren, Modelle laden, die vier großen Endpunkt-Kategorien (Chat, Embeddings, Bilder, Audio) nutzen und die Instanz für den Produktivbetrieb absichern. Am Ende steht ein lauffähiges Setup, das sich in bestehende Python- oder Node-Projekte einklinken lässt, ohne dass Kundendaten je einen fremden Server erreichen.

Was ist LocalAI und warum lohnt sich der Umstieg von der Cloud-API?

LocalAI ist laut der offiziellen GitHub-Beschreibung eine Open-Source-KI-Engine, die Sprachmodelle, Bildmodelle, Sprachausgabe und Video auf beliebiger Hardware ausführt, ausdrücklich ohne GPU-Pflicht. Das Projekt ist in Go geschrieben, steht seit März 2023 in aktiver Entwicklung und wird unter der MIT-Lizenz vertrieben, also ohne Einschränkungen für kommerzielle Nutzung. Der entscheidende Unterschied zu Tools wie Ollama oder LM Studio: LocalAI ist von Grund auf als Server-Ersatz für die OpenAI-API gedacht, nicht als Desktop-Chat-Programm. Die Dokumentation beschreibt das Projekt als komponierbaren KI-Stack mit einem schlanken Kern, der die OpenAI- und Anthropic-Schnittstellen spricht, während jedes Modell-Backend erst bei Bedarf nachgeladen wird.

Das bedeutet in der Praxis: Eine Anwendung, die bereits gegen die OpenAI-API programmiert wurde, muss oft nur die Basis-URL austauschen und zeigt danach auf die eigene LocalAI-Instanz. Genau diese Kompatibilität nennt das Projekt selbst als Kernversprechen, jede bestehende Anwendung lässt sich einfach umbiegen, indem man den Endpunkt auf LocalAI zeigen lässt. Für Unternehmen im DACH-Raum ist das relevant, weil personenbezogene Daten oder Geschäftsgeheimnisse dann nie das eigene Netzwerk verlassen, ein Argument, das bei DSGVO-Prüfungen zunehmend Gewicht bekommt.

Backend-Architektur: Wie LocalAI Modelle lädt und verwaltet

Der Kern von LocalAI ist bewusst schlank gehalten. Das Kernbinary, wahlweise als einzelne Datei oder als Container, stellt die OpenAI-kompatible API, das Request-Routing, eine Web-Oberfläche und einfache Agenten bereit. Alles, was darüber hinausgeht, etwa Bildgenerierung mit Diffusers oder Spracherkennung mit Whisper, kommt als eigenständiger Backend-Container hinzu, der erst beim ersten Bedarf geladen wird. Diese Trennung hält das Basis-Image klein und verhindert, dass ein reiner Text-Server plötzlich mehrere Gigabyte an Python-Abhängigkeiten für Bildmodelle mitschleppen muss, die nie benutzt werden.

Beim Installieren eines Modells über die Galerie oder eine YAML-Datei prüft LocalAI automatisch, welche Backend-Fähigkeiten das System bietet, und lädt das passende Container-Image nach, etwa die CUDA-Variante auf einem Server mit NVIDIA-GPU oder die reine CPU-Variante auf einem Laptop ohne dedizierte Grafikkarte. Die folgende Tabelle zeigt, welche Endpunkt-Kategorie zu welchem Backend gehört und welchen Zweck sie im Alltag erfüllt.

Endpunkt	Zugehöriges Backend	Typischer Einsatzzweck
/v1/chat/completions	llama-cpp (GGUF-Modelle)	Chatbots, interne Assistenten, Textgenerierung
/v1/embeddings	BERT / Sentence-Transformers	Vektorsuche, RAG-Pipelines, Ähnlichkeitssuche
/v1/images/generations	Diffusers (Stable Diffusion, Flux)	Marketing-Grafiken, Prototyping, interne Bildtools
/v1/audio/transcriptions	Whisper	Meeting-Protokolle, Untertitel, Sprachsuche
/v1/audio/speech	TTS-Modelle (u.a. Bark)	Sprachausgabe für Voicebots, Barrierefreiheit

Diese Modularität hat einen praktischen Nebeneffekt: Ein reiner Chat-Server, der nur den ersten Endpunkt aus der Tabelle nutzt, bleibt schlank und startet in Sekunden. Ein Team, das dieselbe Instanz später um Bildgenerierung oder Transkription erweitern will, muss den bestehenden Betrieb nicht neu aufsetzen, sondern lädt einfach das passende Backend nach und ergänzt eine weitere YAML-Datei im Modellordner. Genau diese Erweiterbarkeit ohne Neuinstallation unterscheidet LocalAI von reinen Einzelzweck-Tools, die für jede neue Modalität eine komplett neue Anwendung erfordern würden.

Datenschutz und Compliance: Warum Self-Hosting in Deutschland an Bedeutung gewinnt

Selbstgehostete KI-Server sind kein reines Bastelprojekt mehr, sondern zunehmend eine Antwort auf konkrete regulatorische Fragen. Sobald ein Unternehmen personenbezogene Daten, Vertragsentwürfe oder interne Support-Tickets an eine Cloud-KI schickt, muss geklärt sein, wo diese Daten verarbeitet werden, wie lange sie gespeichert bleiben und ob ein Auftragsverarbeitungsvertrag nach Artikel 28 DSGVO greift. Mit einer selbst betriebenen LocalAI-Instanz entfällt diese Prüfung in der Regel komplett, weil die Anfrage das eigene Rechenzentrum oder den eigenen Server im Büro nie verlässt.

Für IT-Abteilungen, die sich ohnehin mit dem BSI-Grundschutz oder mit branchenspezifischen Auflagen auseinandersetzen, ist das ein praktischer Vorteil: Ein internes KI-System lässt sich in eine bestehende Netzwerksegmentierung einbetten, hinter Firewall und VPN, ohne zusätzliche Datenschutz-Folgenabschätzung für jeden neuen Cloud-Anbieter. Der Preis dafür ist Eigenverantwortung bei Wartung, Patches und Kapazitätsplanung, ein Tausch, den viele Sicherheitsteams inzwischen bewusst eingehen.

Ein weiterer Aspekt betrifft die Kostenkontrolle. Cloud-APIs rechnen pro Token ab, und die Kosten steigen mit jedem zusätzlichen Nutzer, jeder zusätzlichen Anfrage und jedem längeren Prompt praktisch linear mit. Eine selbst betriebene LocalAI-Instanz verursacht dagegen weitgehend fixe Kosten für Hardware und Strom, unabhängig davon, ob täglich zehn oder zehntausend Anfragen laufen. Für Anwendungsfälle mit hohem, planbarem Volumen, etwa einem internen Such-Chatbot mit fester Nutzerzahl, kippt die Kostenrechnung dadurch oft zugunsten des Self-Hostings, sobald ein gewisses Anfragevolumen pro Monat überschritten wird.

Voraussetzungen: Hardware, Software und Accounts

Bevor der erste Container startet, sollten folgende Punkte erfüllt sein. Die Liste ist bewusst konservativ gehalten, damit die Installation auch auf einem Mittelklasse-Server oder einem gut ausgestatteten Laptop funktioniert, nicht nur auf einer teuren GPU-Workstation. Wer bereits Docker für andere Projekte nutzt, hat die meisten Punkte ohnehin schon erledigt und kann direkt zu Schritt 1 springen.

• Docker Engine ab Version 24.0 oder Docker Desktop (Windows/macOS) in aktueller Version, inklusive Docker Compose Plugin
• Mindestens 20 GB freier Festplattenspeicher für Container-Image plus zwei bis drei quantisierte Modelle
• 8 GB RAM als Untergrenze für kleine, stark quantisierte Modelle (Q4-Format), 16 GB oder mehr empfohlen für 7B-Modelle in gängiger Quantisierung
• Für GPU-Beschleunigung: NVIDIA-Treiber mit CUDA 12 oder 13, alternativ ROCm für AMD-Karten oder Metal auf Apple Silicon
• Ein Terminal mit curl, sowie optional Python 3.10 oder neuer für den Beispiel-Client weiter unten
• Ein Hugging-Face-Account ist nicht zwingend nötig, beschleunigt aber den Modell-Download bei Rate-Limits

Ein Hinweis zur Hardware: LocalAI erkennt beim Start automatisch, welche Backend-Fähigkeiten das System bietet, und lädt passende Container-Images nach. Wer die automatische Erkennung überschreiben will, etwa weil zwei GPU-Typen im selben Server stecken, kann das über die Umgebungsvariable LOCALAI_FORCE_META_BACKEND_CAPABILITY erzwingen, mit den Werten nvidia oder amd.

Zum Hugging-Face-Account: Ohne Anmeldung erlaubt Hugging Face nur eine begrenzte Zahl an Downloads pro Zeitfenster, bevor ein Rate-Limit greift. Bei einem einzelnen Modell fällt das selten auf, wer aber mehrere Modelle in Serie testet oder ein Team mit derselben IP-Adresse arbeitet, bekommt mit einem kostenlosen Account und einem Zugriffstoken deutlich zuverlässigere Downloads.

Schritt 1 und 2: Docker vorbereiten und Arbeitsverzeichnis anlegen

Legen Sie zunächst ein Projektverzeichnis an, das später Modelle, Konfigurationsdateien und persistente Daten aufnimmt. Getrennte Unterordner für Modelle und Konfiguration ersparen später Kopfschmerzen bei Updates.

mkdir -p ~/localai-projekt/models ~/localai-projekt/config
cd ~/localai-projekt
docker --version
docker compose version

Beide Befehle sollten eine Versionsnummer zurückgeben. Erscheint stattdessen “command not found”, fehlt entweder Docker selbst oder das Compose-Plugin, dann lohnt ein Blick in die offizielle Docker-Installationsanleitung. Prüfen Sie außerdem, ob der aktuell angemeldete Benutzer der Docker-Gruppe angehört, sonst müssen alle folgenden Befehle mit sudo ausgeführt werden.

Der Unterordner models wird später per Volume in den Container eingebunden, sodass Modelle einen Neustart oder ein Update des Containers überleben. Ohne dieses Volume würde jeder neue Container ohne Modelle starten, und der komplette Download müsste erneut laufen, ein unnötiger Zeitverlust bei Modellen im zweistelligen Gigabyte-Bereich.

Schritt 3 und 4: LocalAI-Container starten und Health-Check durchführen

Für den ersten Test reicht ein einzelner docker run-Befehl, der das CPU-Image lädt und Port 8080 freigibt, den LocalAI standardmäßig für die API verwendet.

docker run -d --name localai \
  -p 8080:8080 \
  -v $(pwd)/models:/models \
  -e MODELS_PATH=/models \
  localai/localai:latest

Der erste Start dauert je nach Internetverbindung ein bis drei Minuten, weil das Basis-Image inklusive Laufzeitbibliotheken mehrere Gigabyte umfasst. Sobald der Container läuft, prüft ein einfacher Health-Check, ob die API antwortet.

curl http://localhost:8080/readyz

Eine leere Antwort mit HTTP-Status 200 bedeutet: Die Engine ist bereit, aber noch ohne geladenes Modell. Wer sofort mit GPU arbeiten will, tauscht das Image gegen eine der spezialisierten Varianten aus, etwa localai/localai:latest-gpu-nvidia-cuda-12 für CUDA 12 oder das entsprechende Pendant für CUDA 13. Für AMD-Grafikkarten existiert eine ROCm-Variante, für Apple Silicon steht die native Metal-Beschleunigung zur Verfügung, für Jetson-Geräte gibt es eigene L4T-Images.

Wer den Fortschritt beim Laden des Basis-Images live verfolgen will, lässt sich die Logs direkt ausgeben, statt blind auf den Health-Check zu warten:

docker logs -f localai

Taucht in den Logs eine Zeile mit “listening on :8080” auf, ist die API-Schicht startklar, auch wenn noch kein Modell geladen wurde. Das Laden eines Modells passiert erst beim ersten Aufruf oder explizit über die Galerie, wie im nächsten Abschnitt gezeigt.

Schritt 5 und 6: Modelle über die Galerie installieren

LocalAI bringt eine eingebaute Modell-Galerie mit, über die sich fertig konfigurierte Modelle per API-Aufruf installieren lassen, ohne dass man selbst eine YAML-Datei schreiben muss. Der folgende Befehl listet verfügbare Modelle auf.

curl http://localhost:8080/models/available | head -50

Die Installation eines konkreten Modells, hier ein kompaktes Beispiel für schnelle Antworten, läuft über den Galerie-Endpunkt:

curl http://localhost:8080/models/apply -X POST \
  -H "Content-Type: application/json" \
  -d '{"id": "[email protected]"}'

Wer stattdessen ein eigenes GGUF-Modell aus dem Hugging-Face-Ökosystem einbinden will, legt eine YAML-Datei im Modellordner ab. LocalAI liest beim Start jede Datei im Verzeichnis models/ automatisch ein.

# models/mein-modell.yaml
name: mein-modell
backend: llama-cpp
parameters:
  model: mein-modell.Q4_K_M.gguf
context_size: 4096
threads: 8

Alternativ lässt sich die gesamte Modellkonfiguration auch in einer einzigen Datei bündeln, ausgewählt über --models-config-file oder die gleichnamige Umgebungsvariable, praktisch für Teams, die eine Konfiguration versionieren wollen. Ein Vorteil dieses Ansatzes: Die komplette Modell-Flotte lässt sich in Git versionieren und über eine Pull-Request-Review absichern, bevor sie auf dem Produktions-Server landet, was klassische YAML-Einzeldateien im Modellordner nicht ohne zusätzliches Tooling bieten.

Nach der Installation zeigt ein Blick auf die Modell-Liste, ob der Vorgang erfolgreich war und wie das Modell für Anfragen heißen muss:

curl http://localhost:8080/v1/models

Die Antwort listet alle geladenen Modelle mit ihrem internen Namen auf, exakt dem Wert, der später im Feld model jeder Chat- oder Embeddings-Anfrage stehen muss.

Schritt 7: Erste Chat-Completion über die OpenAI-kompatible API

Sobald ein Modell geladen ist, verhält sich LocalAI exakt wie die OpenAI-API. Jeder Client, der bereits gegen api.openai.com programmiert wurde, muss lediglich die Basis-URL auf die eigene Instanz ändern.

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mein-modell",
    "messages": [{"role": "user", "content": "Erkläre RAG in zwei Sätzen."}]
  }'

Die Antwort kommt im gewohnten OpenAI-Format zurück, inklusive choices-Array und Token-Zählung:

{
  "id": "chatcmpl-123",
  "object": "chat.completion",
  "model": "mein-modell",
  "choices": [{
    "index": 0,
    "message": {"role": "assistant", "content": "RAG kombiniert eine Suche in eigenen Dokumenten mit der Textgenerierung eines Sprachmodells, damit Antworten auf aktuellem, firmeneigenem Wissen basieren."},
    "finish_reason": "stop"
  }],
  "usage": {"prompt_tokens": 12, "completion_tokens": 34, "total_tokens": 46}
}

Wenn die Standard-URL ohne /v1-Präfix aufgerufen wird, ergänzt LocalAI den Pfad automatisch. Für Streaming-Antworten reicht das Feld "stream": true im JSON-Body, die Antwort kommt dann als Server-Sent-Events, Token für Token. Dieses Verhalten ist bewusst identisch zur OpenAI-API gehalten, weil viele Frontend-Bibliotheken, etwa für Chat-Widgets, exakt dieses Streaming-Format erwarten und sonst angepasst werden müssten.

Wer stattdessen eine reine Text-Completion ohne Chat-Rollen braucht, etwa für Autovervollständigung in einem internen Tool, findet unter /v1/completions das ältere, einfachere Gegenstück. Für neue Projekte empfiehlt sich trotzdem der Chat-Endpunkt, weil er von den aktuellen Modell-Familien konsequent bevorzugt wird und bessere Ergebnisse liefert.

Zwei weitere Parameter lohnen einen Blick, bevor die erste Anwendung produktiv geht: temperature steuert, wie kreativ oder wie deterministisch die Ausgabe ausfällt, ein Wert nahe null liefert bei gleicher Eingabe fast immer dieselbe Antwort, ein Wert um eins erzeugt mehr Variation. max_tokens begrenzt die Länge der Antwort und verhindert, dass ein Modell bei einer offenen Frage endlos weiterschreibt und dabei unnötig Rechenzeit verbraucht.

Schritt 8: Embeddings für Vektorsuche und RAG einrichten

Für Retrieval-Augmented-Generation-Anwendungen braucht es einen Embeddings-Endpunkt, der Text in Vektoren umwandelt. LocalAI bietet diesen Endpunkt unter derselben Basis-URL an, sodass Vektordatenbanken wie Qdrant oder Weaviate ohne Anpassung angebunden werden können.

curl http://localhost:8080/v1/embeddings \
  -H "Content-Type: application/json" \
  -d '{
    "model": "bert-embeddings",
    "input": "Cyberresilienz-Anforderungen für Unternehmen in der EU"
  }'

Wichtig ist hier: Das Embeddings-Modell muss separat installiert werden, ein Chat-Modell wie im vorherigen Schritt erzeugt keine Vektoren. In der Galerie finden sich dafür eigene Einträge, meist auf Basis von BERT-Varianten oder spezialisierten Sentence-Transformer-Modellen. Die zurückgegebenen Vektoren lassen sich anschließend in einer Vektordatenbank ablegen und über eine Cosinus-Ähnlichkeit durchsuchen, der technische Grundbaustein für jede unternehmensinterne Wissenssuche, die auf eigenen Dokumenten statt auf dem allgemeinen Trainingswissen eines Modells basiert.

Schritt 9: Bildgenerierung mit dem Diffusers-Backend

Neben Text verarbeitet LocalAI auch Bildmodelle über ein Python-Backend namens Diffusers, das Stable-Diffusion- und Flux-Familien unterstützt. Weil dieses Backend zusätzliche Python-Abhängigkeiten braucht, wird es über die Variable EXTRA_BACKENDS beim Container-Start nachgeladen oder separat über die Galerie installiert.

curl http://localhost:8080/v1/images/generations \
  -H "Content-Type: application/json" \
  -d '{
    "model": "sd-1.5",
    "prompt": "Ein minimalistisches Server-Rack in einem dunklen Rechenzentrum, fotorealistisch",
    "size": "512x512"
  }'

Die Antwort enthält je nach Konfiguration entweder eine Base64-kodierte Bilddatei oder eine temporäre URL. Bildgenerierung ist der rechenintensivste Endpunkt in diesem Guide, ohne GPU dauert eine 512×512-Generierung schnell über eine Minute. Mit einer aktuellen NVIDIA-Karte sinkt diese Zeit auf wenige Sekunden, ein Grund, warum Bildgenerierung in der Praxis fast ausschließlich mit GPU-Beschleunigung sinnvoll betrieben wird.

Schritt 10: Audio-Transkription und Text-to-Speech

Der Audio-Bereich deckt zwei Richtungen ab: Sprache zu Text und Text zu Sprache. Beide laufen über eigene Endpunkte, die sich an der OpenAI-Audio-API orientieren.

curl http://localhost:8080/v1/audio/transcriptions \
  -H "Content-Type: multipart/form-data" \
  -F file="@meeting-aufnahme.wav" \
  -F model="whisper-1"

Für die umgekehrte Richtung, also Text-to-Speech, genügt ein JSON-Aufruf gegen den entsprechenden TTS-Endpunkt mit gewünschtem Stimmen-Modell. Beide Funktionen eignen sich für interne Transkriptionsdienste, etwa für Meeting-Protokolle, die aus Compliance-Gründen nicht über einen externen Cloud-Dienst laufen sollen. Gerade Transkription ist ein Bereich, in dem Datenschutzbeauftragte in DACH-Unternehmen regelmäßig nachfragen, weil Aufnahmen von Kundengesprächen oder internen Meetings besonders sensible Daten enthalten können.

Schritt 11: GPU-Beschleunigung aktivieren, NVIDIA, AMD und Apple Silicon

Ohne GPU läuft LocalAI zuverlässig, aber deutlich langsamer als mit Beschleunigung. Die folgende Tabelle zeigt, welches Docker-Image zu welcher Hardware passt.

Hardware	Docker-Image-Tag	Voraussetzung
CPU (jede Architektur)	localai/localai:latest	Keine, läuft überall
NVIDIA GPU (aktuelle Generation)	localai/localai:latest-gpu-nvidia-cuda-13	Treiber mit CUDA 13
NVIDIA GPU (ältere Generation)	localai/localai:latest-gpu-nvidia-cuda-12	Treiber mit CUDA 12
AMD GPU	ROCm-Variante laut Container-Registry	ROCm/HIP-Treiber
Apple Silicon (M-Serie)	Native Metal-Beschleunigung	macOS mit M1 oder neuer
Intel-GPU	SYCL/oneAPI-Variante	Intel-Grafiktreiber mit oneAPI
Jetson-Geräte	L4T-Image	NVIDIA Jetson mit passendem JetPack

Für NVIDIA-Karten unter Linux muss zusätzlich das NVIDIA Container Toolkit installiert sein, damit Docker die GPU an den Container durchreichen kann. Der Start-Befehl erhält dann das Flag --gpus all.

docker run -d --name localai-gpu \
  --gpus all \
  -p 8080:8080 \
  -v $(pwd)/models:/models \
  localai/localai:latest-gpu-nvidia-cuda-13

Schritt 12: Docker Compose, Reverse Proxy und Zugriffsschutz

Für den Dauerbetrieb ist ein einzelner docker run-Befehl zu fragil, ein Neustart des Hosts würde den Container sonst nicht automatisch wiederherstellen. Docker Compose löst das über eine deklarative Konfigurationsdatei.

# docker-compose.yml
services:
  localai:
    image: localai/localai:latest-gpu-nvidia-cuda-13
    container_name: localai
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - ./models:/models
      - ./config:/config
    environment:
      - MODELS_PATH=/models
      - LOCALAI_API_KEY=aendere-dieses-geheimnis
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

Die Variable LOCALAI_API_KEY ist entscheidend, sobald der Dienst über das Netzwerk erreichbar ist. Ohne diesen Schlüssel akzeptiert LocalAI standardmäßig jede Anfrage, auch von außen, wenn Port 8080 versehentlich nach außen offen liegt. Für den produktiven Einsatz empfiehlt sich zusätzlich ein Reverse Proxy mit TLS-Terminierung, etwa Nginx oder Caddy, davor. Damit lässt sich der Dienst über eine eigene Subdomain mit gültigem Zertifikat erreichen, statt Port 8080 direkt ins Internet zu hängen.

Vollständiges Projekt: Python-Client mit Streaming und Function Calling

Weil LocalAI die OpenAI-Signatur nachbildet, lässt sich das offizielle OpenAI-Python-SDK unverändert weiterverwenden, es muss nur die base_url umgebogen werden. Das folgende Beispiel zeigt einen Chat-Client mit Streaming und einem einfachen Function-Call.

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8080/v1",
    api_key="aendere-dieses-geheimnis"
)

# Streaming-Antwort Token für Token ausgeben
stream = client.chat.completions.create(
    model="mein-modell",
    messages=[{"role": "user", "content": "Fasse die NIS2-Pflichten in drei Punkten zusammen."}],
    stream=True
)
for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

# Function Calling: Modell entscheidet, ob ein Tool aufgerufen wird
tools = [{
    "type": "function",
    "function": {
        "name": "wetter_abfragen",
        "description": "Liefert das aktuelle Wetter für eine Stadt",
        "parameters": {
            "type": "object",
            "properties": {"stadt": {"type": "string"}},
            "required": ["stadt"]
        }
    }
}]

antwort = client.chat.completions.create(
    model="mein-modell",
    messages=[{"role": "user", "content": "Wie ist das Wetter in München?"}],
    tools=tools
)
print(antwort.choices[0].message.tool_calls)

Dieses Setup, Docker-Compose-Datei plus Python-Client, ist bereits ein vollständiges Projekt: ein Server, der dauerhaft läuft, per API-Schlüssel geschützt ist und über Standard-SDKs angesprochen werden kann. Von hier aus lässt sich jede bestehende OpenAI-Integration, ob Chatbot, RAG-Pipeline oder Automatisierungsskript, ohne Codeänderung auf die eigene Infrastruktur umziehen.

Wer das Beispiel um eine echte Tool-Ausführung ergänzen will, prüft im Code nach einem Antwort-Objekt mit gefüllten tool_calls, ruft die entsprechende eigene Funktion (hier wetter_abfragen) mit den vom Modell gelieferten Parametern auf und schickt das Ergebnis als weitere Nachricht mit der Rolle tool zurück an den Chat-Verlauf. Das Modell verarbeitet das Ergebnis dann in seiner nächsten Antwort weiter, exakt nach demselben Function-Calling-Muster, das auch bei der OpenAI-API verwendet wird. Diese Kompatibilität ist der Grund, warum sich bestehende Agenten-Frameworks meist ohne Anpassung gegen LocalAI betreiben lassen.

LocalAI im Vergleich zu Ollama, LM Studio und der OpenAI-API

Keines der drei Tools ersetzt die anderen vollständig, die Zielgruppen unterscheiden sich deutlich. Ollama punktet mit einem extrem einfachen Einzeiler-Setup und eignet sich für schnelle lokale Experimente, das Projekt zählt laut aktuellen GitHub-Daten rund 181.486 Sterne und ist damit deutlich größer als LocalAI. LM Studio bietet eine grafische Desktop-Oberfläche für Einsteiger ohne Terminal-Erfahrung, ist aber Closed-Source-Freeware ohne öffentlichen Quellcode und daher für Server-Deployments ungeeignet. LocalAI positioniert sich dazwischen als Server-Baustein für Teams, die eine echte API-Drop-in-Lösung brauchen, inklusive Multi-Modell-Routing und Endpunkten für Bild und Audio in einer einzigen Instanz. Auch llama.cpp, das technische Fundament vieler dieser Tools, ist mit 129.214 Sternen (Stand September 2026) inzwischen größer als LocalAI, dient aber als reine Inferenz-Bibliothek ohne fertige API-Schicht und Modell-Galerie.

Kriterium	LocalAI	Ollama	LM Studio
GitHub-Stars (Sept. 2026)	49.223	181.486	Closed Source, kein öffentliches Repo
Lizenz	MIT	MIT	Proprietär, kostenlos nutzbar
API-Kompatibilität	OpenAI und Anthropic nativ	Eigenes API-Format plus OpenAI-Kompatibilitätsschicht	OpenAI-kompatibler lokaler Server als Zusatzfunktion
Bild- und Audio-Endpunkte	Ja, Diffusers und Whisper/TTS integriert	Nein, reiner Text-Fokus	Nein, reiner Text-Fokus
Zielgruppe	Server-Betrieb, Teams, produktive Deployments	Einzelentwickler, schnelle lokale Tests	Einsteiger mit grafischer Oberfläche
Betriebsart	Docker-Container, headless	Systemdienst, CLI	Desktop-Anwendung mit GUI

Für Teams, die bereits Ollama zum Testen nutzen, aber eine belastbare, mehrbenutzerfähige API-Schicht mit Authentifizierung suchen, ist der Wechsel zu LocalAI meist der logische nächste Schritt. Wer nur schnell ein Modell auf dem eigenen Laptop ausprobieren will, bleibt mit Ollama oder LM Studio besser bedient, weil der Einstieg dort in unter fünf Minuten erledigt ist.

Performance-Tuning: Threads, Kontextgröße und Quantisierung richtig wählen

Die drei wichtigsten Stellschrauben für Geschwindigkeit und Speicherbedarf stehen direkt in der YAML-Datei eines Modells: threads, context_size und die Quantisierungsstufe des GGUF-Modells selbst. Der Parameter threads sollte in etwa der Zahl der physischen CPU-Kerne entsprechen, nicht der Zahl der logischen Threads inklusive Hyperthreading, weil zu viele parallele Threads bei llama.cpp-Backends häufig zu mehr Overhead statt zu mehr Durchsatz führen. Wer die Werkseinstellung übernimmt, verschenkt auf einem modernen Achtkern-Server oft die Hälfte der möglichen Geschwindigkeit.

context_size bestimmt, wie viel Text (in Token) das Modell gleichzeitig im Blick behält, inklusive Systemprompt, Verlauf und aktueller Anfrage. Ein höherer Wert erlaubt längere Unterhaltungen und größere Dokumente in einer RAG-Anfrage, kostet aber quadratisch mehr Arbeitsspeicher und Rechenzeit. Für die meisten Chat-Anwendungen reichen 4096 bis 8192 Token, für Dokumentenanalyse mit langen PDF-Auszügen sind 16384 Token oder mehr sinnvoll, allerdings nur, wenn genug RAM oder VRAM zur Verfügung steht.

Die Quantisierungsstufe schließlich entscheidet über die Balance zwischen Antwortqualität und Ressourcenbedarf. Die folgende Tabelle zeigt gängige Stufen für ein Modell mit 7 Milliarden Parametern als Orientierung.

Quantisierung	Ungefährer RAM-Bedarf (7B-Modell)	Empfehlung
Q4_K_M	Rund 4,5 bis 5 GB	Bester Kompromiss für die meisten Anwendungsfälle
Q5_K_M	Rund 5,5 bis 6 GB	Etwas höhere Qualität, moderat mehr Speicherbedarf
Q8_0	Rund 8 bis 9 GB	Nahezu volle Qualität, deutlich höherer Speicherbedarf
F16 (unquantisiert)	Rund 14 bis 15 GB	Nur sinnvoll mit ausreichend VRAM auf dedizierter GPU

Als Faustregel gilt: Wer unsicher ist, startet mit Q4_K_M. Die Qualitätsunterschiede zu höheren Stufen sind bei den meisten Alltagsaufgaben, etwa Zusammenfassungen oder einfachen Chatbots, kaum wahrnehmbar, während der Speicherbedarf deutlich sinkt und mehr Modelle gleichzeitig auf derselben Maschine laufen können.

Der Geschwindigkeitsunterschied zwischen CPU- und GPU-Betrieb fällt bei Textgenerierung besonders deutlich aus. Auf reiner CPU-Basis liegen typische Werte für ein 7B-Modell in Q4-Quantisierung bei wenigen Token pro Sekunde, ausreichend für einen internen Chatbot mit wenigen gleichzeitigen Nutzern, aber spürbar langsamer als ein Cloud-Dienst. Mit einer aktuellen NVIDIA-Karte und ausreichend VRAM steigt der Durchsatz auf ein Vielfaches, weshalb Teams mit mehreren gleichzeitigen Nutzern GPU-Beschleunigung kaum umgehen können, sobald der Chatbot über den reinen Testbetrieb hinausgeht.

Migration einer bestehenden OpenAI-Integration auf LocalAI

Für Teams, die bereits eine Anwendung gegen die OpenAI-API betreiben, läuft die Migration in der Praxis meist auf drei Änderungen hinaus. Erstens die Basis-URL im SDK oder in der Konfigurationsdatei, die von api.openai.com auf die eigene LocalAI-Adresse wechselt. Zweitens der API-Key, der nicht mehr gegen OpenAI, sondern gegen den selbst gesetzten LOCALAI_API_KEY geprüft wird. Drittens der Modellname im Request-Body, der beim Cloud-Anbieter etwa “gpt-4o-mini” lautet und bei LocalAI durch den Namen des lokal installierten Modells ersetzt wird.

Schwieriger wird es bei Funktionen, die stark an ein bestimmtes Cloud-Modell gebunden sind, etwa sehr spezifisches Function-Calling-Verhalten oder bestimmte Vision-Fähigkeiten. Hier lohnt sich ein Testlauf mit echten Produktionsanfragen gegen die neue LocalAI-Instanz, bevor der Cloud-Zugang komplett abgeschaltet wird. Ein paralleler Betrieb über einige Wochen, bei dem ein kleiner Anteil des Traffics auf LocalAI umgeleitet wird, deckt Abweichungen im Antwortverhalten zuverlässiger auf als ein einmaliger Testlauf im Staging-System.

Ein praktischer Vorteil bei der Migration: Frameworks wie LangChain oder Proxy-Schichten wie LiteLLM erkennen LocalAI in der Regel automatisch als OpenAI-kompatiblen Provider, wenn nur die Basis-URL angepasst wird. Wer bereits eine solche Abstraktionsschicht zwischen Anwendung und Modell-Anbieter eingezogen hat, kann zwischen Cloud-Modell und LocalAI-Instanz sogar dynamisch umschalten, etwa nach Datenklassifizierung der jeweiligen Anfrage: unkritische Anfragen laufen über die Cloud, sensible Anfragen bleiben lokal.

Fünf typische Anfängerfehler bei der LocalAI-Installation

Die folgenden fünf Fehler tauchen in Support-Foren und GitHub-Issues immer wieder auf, meist bei der ersten Installation, wenn Dokumentation und Praxis noch nicht zusammenpassen.

• Falsches Image für die Hardware gewählt: Wer das CPU-Image auf einer Maschine mit NVIDIA-GPU startet, verschenkt die gesamte Beschleunigung, ohne dass eine Fehlermeldung erscheint, die Inferenz läuft einfach nur langsam.
• API-Key vergessen: Ohne LOCALAI_API_KEY ist der Endpunkt offen für jeden, der die IP-Adresse und den Port kennt, ein Problem, sobald der Server nicht ausschließlich im eigenen LAN steht.
• Falsche Context-Size im YAML: Wird context_size größer gewählt als das Modell unterstützt, quittiert LocalAI das oft mit stark verlangsamter oder fehlerhafter Ausgabe statt mit einer klaren Fehlermeldung.
• Modellname stimmt nicht mit der YAML-Datei überein: Der Wert im Feld model muss exakt dem Dateinamen im Modellordner entsprechen, sonst schlägt die Anfrage mit einem 404-Fehler fehl.
• Zu wenig RAM für die gewählte Quantisierung: Ein 7B-Modell in Q8-Quantisierung braucht deutlich mehr Arbeitsspeicher als dieselbe Modellgröße in Q4, was auf Systemen mit 8 GB RAM schnell zu Out-of-Memory-Abstürzen führt, oft ohne aussagekräftige Fehlermeldung im Log.

Alle fünf Punkte lassen sich vermeiden, wenn vor dem ersten Produktionsversuch eine kurze Checkliste durchgegangen wird: passendes Image für die Hardware, gesetzter API-Key, realistische Context-Size, korrekter Modellname und ausreichend Arbeitsspeicher für die gewählte Quantisierung.

Fehlerbehebung: Acht Probleme und ihre Lösung

Auch nach einer erfolgreichen Erstinstallation tauchen im laufenden Betrieb typische Probleme auf. Die folgende Liste deckt die acht häufigsten Fälle ab, sortiert von der Installation bis zum Dauerbetrieb.

• Container startet, aber /readyz antwortet nicht: Meist ein Zeichen dafür, dass das Basis-Image noch lädt. Logs mit docker logs localai prüfen, statt den Container vorzeitig neu zu starten.
• “model not found” bei jeder Anfrage: Prüfen, ob die YAML-Datei tatsächlich im gemounteten Modellordner liegt und ob MODELS_PATH korrekt auf diesen Pfad zeigt.
• GPU wird nicht erkannt: Unter Linux fehlt häufig das NVIDIA Container Toolkit. Ein Test mit docker run --gpus all nvidia/cuda:12.0-base nvidia-smi zeigt, ob Docker generell auf die GPU zugreifen kann.
• Sehr langsame Antworten trotz GPU: Oft liegt es an zu wenig VRAM für das gewählte Modell, wodurch Schichten auf die CPU ausweichen. Kleinere Quantisierung oder ein kompakteres Modell schafft Abhilfe.
• Bildgenerierung schlägt mit Backend-Fehler fehl: Das Diffusers-Backend muss separat über EXTRA_BACKENDS oder die Galerie installiert sein, es ist im Basis-Image nicht enthalten.
• Verbindung von außen wird abgelehnt: Firewall-Regeln oder ein fehlendes Port-Mapping in der Compose-Datei sind die häufigsten Ursachen, ein Test mit curl direkt auf dem Host schließt Netzwerkprobleme aus.
• Speicherverbrauch wächst über Stunden immer weiter: Mehrere gleichzeitig geladene große Modelle ohne Entladen belegen weiterhin RAM, besonders wenn viele unterschiedliche Modelle im Testbetrieb ausprobiert wurden. Ein Neustart des Containers oder ein explizites Entladen über die Modell-API hilft kurzfristig, dauerhaft hilft ein Monitoring-Alarm bei Überschreiten eines RAM-Schwellwerts.
• Embeddings-Endpunkt liefert 400-Fehler: Häufig wurde versehentlich ein Chat-Modell statt eines dedizierten Embeddings-Modells im model-Feld angegeben. Ein Blick in /v1/models zeigt schnell, welche Modelle tatsächlich für Embeddings konfiguriert sind.

Fortgeschrittene Tipps für den Produktivbetrieb

Wer LocalAI über den Testbetrieb hinaus einsetzt, sollte drei Punkte früh einplanen. Erstens: Monitoring über den integrierten, Prometheus-kompatiblen Metriken-Endpunkt, damit Auslastung und Antwortzeiten sichtbar werden, bevor Nutzer sich beschweren. Zweitens: Für Teams mit mehreren Standorten unterstützt LocalAI einen P2P-Modus, der mehrere Instanzen föderiert verbindet und Last verteilt, ohne einen zentralen Load Balancer zu benötigen. Drittens: Wer viele kleine Anfragen erwartet, etwa aus einer Chat-Widget-Integration, profitiert von einem vorgeschalteten Cache für wiederkehrende Prompts, weil LocalAI selbst keinen persistenten Antwort-Cache mitbringt.

Ein weiterer Punkt betrifft Updates: Da LocalAI aktiv weiterentwickelt wird und im September 2026 mit v4.10.0 einen neuen Stand erreicht hat, lohnt sich ein Blick auf die Release Notes auf GitHub vor jedem Image-Update, insbesondere wenn eigene YAML-Konfigurationen im Einsatz sind. Backend-Formate ändern sich zwischen Hauptversionen gelegentlich, ein Test in einer Staging-Umgebung vor dem Produktions-Update erspart böse Überraschungen.

Für Teams mit mehreren Modellen empfiehlt sich außerdem eine klare Namenskonvention in den YAML-Dateien, etwa mit Präfix für Umgebung und Zweck, etwa prod-chat-7b statt schlicht modell1. Das erleichtert die spätere Fehlersuche in Logs erheblich, gerade wenn mehrere Anwendungen gegen dieselbe LocalAI-Instanz sprechen und ein Vorfall genau einem Modell und einem Anwendungsfall zugeordnet werden muss. Wer zusätzlich Kosten sparen will, kann inaktive Modelle über die API gezielt entladen, statt dauerhaft RAM für selten genutzte Backends zu reservieren.

Backup und Update-Strategie für die Modell-Bibliothek

Modelle sind groß, aber die eigentliche Konfiguration ist klein. Für ein sinnvolles Backup reicht es meist, den config-Ordner mit allen YAML-Dateien sowie die docker-compose.yml zu sichern, statt die kompletten Modell-Binärdateien mehrfach zu duplizieren. Diese lassen sich im Ernstfall erneut aus der Galerie oder von Hugging Face herunterladen, solange die Konfiguration bekannt ist, welches Modell in welcher Version und Quantisierung verwendet wurde.

tar -czf localai-backup-$(date +%F).tar.gz config/ docker-compose.yml

Für Updates empfiehlt sich ein einfacher, aber disziplinierter Ablauf: zuerst die aktuelle Version dokumentieren, dann das neue Image in einer Staging-Umgebung testen, danach den Produktions-Container austauschen. Da LocalAI aktiv weiterentwickelt wird, mit v4.10.0 als jüngstem Stand vom 17. September 2026, ändern sich gelegentlich Standardwerte oder Umgebungsvariablen zwischen Hauptversionen. Ein kurzer Blick in das Changelog vor jedem Sprung über eine Hauptversion hinweg erspart im Zweifel eine längere Fehlersuche nach dem Update.

Sicherheits-Checkliste vor dem Produktivstart

Vor dem ersten produktiven Rollout lohnt sich ein kurzer Abgleich mit dieser Liste. Sie deckt die Punkte ab, die in diesem Guide erklärt wurden, gebündelt für die letzte Kontrolle.

• LOCALAI_API_KEY gesetzt und nicht der Standardwert aus einem Beispiel
• Port 8080 nicht direkt öffentlich erreichbar, sondern nur über Reverse Proxy mit TLS
• Firewall-Regeln beschränken den Zugriff auf bekannte Quell-IPs oder das interne Netz
• Modelle und Konfiguration liegen auf einem Volume, das regelmäßig gesichert wird
• Monitoring über den Metriken-Endpunkt ist eingerichtet, bevor der erste echte Nutzer zugreift
• Ressourcen-Limits in der Compose-Datei verhindern, dass ein einzelnes Modell den gesamten Host blockiert

Häufig gestellte Fragen zu LocalAI

Ist LocalAI komplett kostenlos?
Ja. Das Projekt steht unter der MIT-Lizenz, es fallen keine Lizenzgebühren an, egal ob privat oder kommerziell genutzt. Kosten entstehen nur für die eigene Hardware und den Stromverbrauch.

Brauche ich unbedingt eine GPU?
Nein. LocalAI läuft laut Projektbeschreibung ausdrücklich ohne GPU-Zwang auf CPU-Basis. Eine GPU beschleunigt die Inferenz deutlich, ist aber für kleinere, quantisierte Modelle keine Pflicht.

Kann ich mein bestehendes OpenAI-SDK weiterverwenden?
Ja, das ist der zentrale Zweck des Projekts. Es reicht, die base_url im SDK auf die eigene LocalAI-Instanz zu ändern, der restliche Code bleibt unverändert.

Welche Modellformate unterstützt LocalAI?
Über verschiedene Backends werden unter anderem GGUF-Modelle (via llama.cpp-Backend), Diffusers-Modelle für Bildgenerierung sowie Whisper-Modelle für Audio-Transkription unterstützt. Die Backend-Architektur ist modular, weitere Formate lassen sich über zusätzliche Backend-Container ergänzen, etwa für Reranking-Modelle oder spezialisierte Vision-Modelle wie LLaVA.

Wie unterscheidet sich LocalAI von Ollama?
Ollama ist auf einfache, schnelle lokale Nutzung mit eigenem CLI-Workflow ausgelegt. LocalAI zielt stärker auf Server-Betrieb mit vollständiger OpenAI- und Anthropic-API-Kompatibilität sowie zusätzlichen Endpunkten für Bild und Audio in einer einzigen Instanz.

Läuft LocalAI auch unter Windows?
Ja, über Docker Desktop für Windows. Für GPU-Beschleunigung unter Windows ist WSL2 mit installiertem NVIDIA-Treiber die gängige Voraussetzung. Reine CPU-Nutzung funktioniert dagegen ohne WSL2-Feinabstimmung, sobald Docker Desktop grundsätzlich läuft.

Wie sicher ist eine LocalAI-Instanz im Netzwerk?
Die Sicherheit hängt fast vollständig von der eigenen Konfiguration ab. Ohne gesetzten API-Key und ohne Reverse Proxy mit TLS ist die Instanz offen für jeden, der Port und IP-Adresse kennt. Ein API-Key plus Firewall-Regeln, die den Zugriff auf bekannte Quell-IPs beschränken, sind die Mindestausstattung für einen Betrieb außerhalb eines reinen Test-LANs. Zusätzlich empfiehlt sich, den Container regelmäßig auf die neueste Version zu aktualisieren, da wie bei jeder Server-Software auch bei LocalAI und seinen Backend-Abhängigkeiten gelegentlich Sicherheitslücken geschlossen werden.

Kann ich mehrere Modelle gleichzeitig laden?
Ja, LocalAI unterstützt mehrere geladene Modelle parallel, solange genug RAM oder VRAM zur Verfügung steht. Jedes Modell wird über seinen eigenen Namen im model-Feld der Anfrage angesprochen.

Eignet sich LocalAI für den produktiven Einsatz in Unternehmen?
Ja, dafür ist es primär gebaut. Mit gesetztem API-Key, einem Reverse Proxy für TLS und der Docker-Compose-Konfiguration aus diesem Guide lässt sich LocalAI dauerhaft und mehrbenutzerfähig betreiben. Für sehr hohe Lastspitzen empfiehlt sich zusätzlich horizontale Skalierung über mehrere Container-Instanzen hinter einem Load Balancer.