Lokale LLMs als APIs nutzen

Ihr Laptop kann ein Modell mit 70 Milliarden Parametern hinter einem OpenAI-kompatiblen Endpunkt bereitstellen. Wenn Ihr Client bereits base_url unterstützt, ändern Sie nur die Basis-URL und testen denselben Code lokal: offline, ohne Token-Kosten und mit einem privaten Pfad für regulierte Daten. Dieser Leitfaden zeigt, wie Sie Ollama, vLLM oder llama.cpp starten, den Endpunkt verifizieren, Ihren OpenAI-Client umstellen und den Workflow mit Apidog gegen lokale und gehostete Modelle testen.

Probieren Sie Apidog noch heute aus

TL;DR

Sie können eine lokale LLM-API mit Ollama, vLLM oder llama.cpp ausführen. Alle drei stellen einen OpenAI-kompatiblen REST-Endpunkt bereit. Für Ollama setzen Sie im OpenAI-Client zum Beispiel:

base_url = "http://localhost:11434/v1"

Danach läuft derselbe Client-Code gegen ein lokales Modell wie Llama 3.3, DeepSeek V4 oder Qwen 3.6. In Apidog halten Sie dafür zwei Umgebungen vor: Local und Production.

Einführung

Der lokale LLM-API-Stack ist vom Forschungsprojekt zum Entwicklungswerkzeug geworden. Die wichtigste Änderung für API-Entwickler: Viele Laufzeitumgebungen sprechen inzwischen die OpenAI-Form unter /v1/chat/completions.

Das bedeutet:

• ein SDK
• ein Request-Schema
• ein Test-Setup
• nur unterschiedliche Umgebungsvariablen

Ihre Requests in Apidog können auf https://api.openai.com/v1/chat/completions oder auf http://localhost:11434/v1/chat/completions zeigen. Sie wechseln nur die Umgebung. Wenn Sie bereits API-Ausgaben pro Funktion verfolgen, können Sie lokale und gehostete Modelle A/B-testen und Kosten, Latenz und Antwortqualität vergleichen.

Dieser Leitfaden behandelt:

1. Laufzeitumgebung auswählen
2. lokalen Server starten
3. OpenAI-kompatiblen Endpunkt prüfen
4. Client-Code umstellen
5. Apidog-Szenariotests für lokal und gehostet bauen
6. Quantisierung, GPU-Offloading und typische Fehler verstehen

Für einen breiteren Überblick siehe Beste lokale LLMs 2026.

Warum lokale LLMs für API-Entwickler sinnvoll sind

Lokale LLMs sind besonders nützlich, wenn Sie Code entwickeln, der später ein gehostetes Modell aufruft. Sie können auch dann debuggen, wenn:

• Sie offline arbeiten
• Kundennetzwerke ausgehenden Traffic blockieren
• Prompts sensible Daten enthalten
• gehostete APIs gerade nicht verfügbar sind
• Token-Kosten während der Entwicklung vermieden werden sollen

Datenschutz ist dabei der wichtigste Punkt. Prompts können Patientennotizen, Verträge, Kontodaten oder biometrische Kennungen enthalten. Sobald diese Daten an einen gehosteten Dienst gesendet werden, entsteht eine Datenverarbeitungsbeziehung, die dokumentiert und geprüft werden muss. Ein lokales Modell vermeidet diesen Transfer.

Kosten sind der zweite Faktor. Ein Team, das täglich 50 Millionen Prompt-Tokens durch ein gehostetes Modell schickt, zahlt schnell mehrere Hundert Dollar pro Tag. Bei lokaler Inferenz fallen diese Token-Kosten nicht an. Eine Beispielrechnung finden Sie in Wie man GPT-5.5 Instant verwendet.

Der dritte Faktor ist Stabilität. Gehostete Modelle können Snapshots austauschen oder ältere Versionen abkündigen. Ein lokales Modell ist eine Datei auf Ihrer Festplatte. Für Regressionstests ist das wertvoll, weil sich das Modell nicht ohne Ihr Zutun ändert.

Drei Laufzeitumgebungen mit OpenAI-kompatiblen Endpunkten

Wählen Sie die Laufzeitumgebung nach Arbeitslast:

Laufzeit	Gut für	Standard-Port
Ollama	lokale Entwicklung, Demos, CI-Runner	11434
vLLM	hohe Parallelität, GPU-Server, Dev-Cluster	8000
llama.cpp	maximale Kontrolle, knapper Speicher, exotische Hardware	frei wählbar

Ollama

Ollama ist der einfachste Einstieg. Es übernimmt Modelldownloads, GGUF-Quantisierung und Prompt-Templating.

Installation und Start unter macOS:

brew install ollama

ollama serve &
ollama pull llama3.3:70b-instruct-q4_K_M
ollama run llama3.3:70b-instruct-q4_K_M

Der OpenAI-kompatible Endpunkt läuft danach unter:

http://localhost:11434/v1

Ein Chat-Request geht an:

http://localhost:11434/v1/chat/completions

Ollama eignet sich für Einzelplatzentwicklung, Demos und lokale Smoke-Tests.

vLLM

vLLM ist für Durchsatz optimiert. Es verwendet PagedAttention und kontinuierliches Batching, um viele parallele Requests effizient auf der GPU auszuführen.

Startbeispiel:

pip install vllm

vllm serve meta-llama/Llama-3.3-70B-Instruct \
  --port 8000 \
  --gpu-memory-utilization 0.9 \
  --max-model-len 8192

Der Endpunkt ist dann:

http://localhost:8000/v1

vLLM ist sinnvoll, wenn Sie auf CUDA- oder ROCm-Hardware entwickeln und mehrere Requests parallel testen möchten. Für Apple-Silicon-Laptops ist Ollama oder llama.cpp meist praktischer.

llama.cpp

llama.cpp ist die C++-Laufzeitumgebung hinter dem GGUF-Ökosystem. Sie läuft auf sehr vielen Plattformen und gibt Ihnen viel Kontrolle über Speicher, Quantisierung und GPU-Offloading.

Beispiel mit Metal-Unterstützung:

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp && make -j LLAMA_METAL=1

./llama-server -m models/llama-3.3-70b-q4_k_m.gguf \
  --port 8080 \
  --host 0.0.0.0 \
  -c 8192 \
  -ngl 99

Der OpenAI-kompatible Chat-Endpunkt ist:

http://localhost:8080/v1/chat/completions

Das Flag -ngl 99 versucht, möglichst viele Transformer-Schichten auf die GPU auszulagern.

LM Studio und Jan verpacken llama.cpp in einer GUI und stellen ebenfalls einen OpenAI-kompatiblen Endpunkt bereit. Das ist hilfreich, wenn Teammitglieder Prompts testen sollen, ohne ein Terminal zu verwenden.

Endpunkt mit Python prüfen

Bevor Sie Apidog oder Ihre Anwendung konfigurieren, prüfen Sie den lokalen Endpunkt mit dem OpenAI SDK:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama",
)

resp = client.chat.completions.create(
    model="llama3.3:70b-instruct-q4_K_M",
    messages=[
        {"role": "user", "content": "Reply with the word OK only."}
    ],
)

print(resp.choices[0].message.content)

Wenn OK erscheint, stimmen Laufzeitumgebung, Port, Modellname und SDK-Vertrag.

Lokale LLM mit Apidog testen

Eine lokale LLM-API ist nur dann nützlich, wenn Ihre Tests sie genauso erreichen wie die Produktion. In Apidog lösen Sie das mit Umgebungen und Variablen.

Schritt 1: Lokale Umgebung anlegen

Erstellen Sie in Ihrem Apidog-Projekt eine Umgebung Local:

BASE_URL = http://localhost:11434/v1
API_KEY  = ollama
MODEL    = llama3.3:70b-instruct-q4_K_M

Schritt 2: Produktionsumgebung klonen

Legen Sie zusätzlich Production an:

BASE_URL = https://api.openai.com/v1
API_KEY  = Ihr gehosteter API-Key
MODEL    = Ihr Produktionsmodell

Schritt 3: Request variabel machen

Statt einer hart codierten URL verwenden Sie:

{{BASE_URL}}/chat/completions

Header:

Authorization: Bearer {{API_KEY}}
Content-Type: application/json

Body:

{
  "model": "{{MODEL}}",
  "messages": [
    {
      "role": "system",
      "content": "You are a JSON-only assistant."
    },
    {
      "role": "user",
      "content": "Return {\"status\":\"ok\"}."
    }
  ],
  "response_format": {
    "type": "json_object"
  }
}

Schritt 4: Assertions hinzufügen

Erstellen Sie einen Szenariotest mit Assertions wie:

choices[0].message.role == "assistant"
choices[0].message.content ist nicht leer
usage.total_tokens > 0

Wenn Ihr lokaler Server keine vollständigen usage-Daten zurückgibt, testen Sie mindestens Struktur und Inhalt der Antwort.

Schritt 5: Gegen beide Umgebungen ausführen

Führen Sie dasselbe Szenario aus gegen:

1. Local
2. Production

Das Ziel: Ihr API-Vertrag bleibt gleich, obwohl sich der Modellanbieter ändert.

Dieses Muster funktioniert auch für KI-Agenten, die mehrstufige APIs aufrufen.

Client-Code zwischen lokal und gehostet umschalten

Python

import os
from openai import OpenAI

def get_client():
    if os.getenv("ENV") == "local":
        return OpenAI(
            base_url="http://localhost:11434/v1",
            api_key="ollama",
        )

    return OpenAI(
        api_key=os.environ["OPENAI_API_KEY"]
    )

client = get_client()

response = client.chat.completions.create(
    model=os.getenv("MODEL", "llama3.3:70b-instruct-q4_K_M"),
    messages=[
        {"role": "system", "content": "You are a JSON-only assistant."},
        {"role": "user", "content": "Return {\"status\": \"ok\"}."},
    ],
    response_format={"type": "json_object"},
)

print(response.choices[0].message.content)

Start lokal:

ENV=local MODEL=llama3.3:70b-instruct-q4_K_M python app.py

Start gehostet:

ENV=production OPENAI_API_KEY=sk-... MODEL=gpt-... python app.py

JavaScript

import OpenAI from "openai";

const isLocal = process.env.ENV === "local";

const client = new OpenAI({
  baseURL: isLocal
    ? "http://localhost:11434/v1"
    : "https://api.openai.com/v1",
  apiKey: isLocal
    ? "ollama"
    : process.env.OPENAI_API_KEY,
});

const resp = await client.chat.completions.create({
  model: process.env.MODEL || "llama3.3:70b-instruct-q4_K_M",
  messages: [
    { role: "user", content: "Say hi." }
  ],
});

console.log(resp.choices[0].message.content);

Apidog-Szenarien in CI ausführen

Sie können Apidogs Szenario-Runner in Ihre CI integrieren, indem Sie das Projekt als apidog-cli-Sammlung exportieren und apidog run in GitHub Actions ausführen.

Beispielstruktur:

name: API contract tests

on:
  pull_request:
  push:
    branches: [main]

jobs:
  test-llm-api:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Run Apidog scenarios
        run: |
          apidog run ./apidog-collection.json --env Local

Der Runner gibt einen Exit-Code ungleich Null zurück, wenn Assertions fehlschlagen. Damit bricht der Build ab, sobald lokaler oder gehosteter Vertrag abweichen. QA-Teams können dasselbe Muster in bestehende API-Test-Pipelines einbauen.

Fortgeschrittene Techniken

Quantisierung wählen

Quantisierung entscheidet, ob ein großes Modell in Ihren Speicher passt.

Quantisierung	Vorteil	Nachteil	Typischer Einsatz
Q8	nahe an FP16	hoher RAM-/VRAM-Bedarf	Codegenerierung, hohe Qualität
Q5_K_M	guter Qualitäts-/Speicher-Kompromiss	größer als Q4	Chat mit Reserve
Q4_K_M	Standard für lokale 70B-Modelle	Qualitätsverlust gegenüber FP16	lokale Entwicklung
Q2_K	sehr klein	sichtbarer Qualitätsverlust	Experimente, knapper Speicher

Praktische Regel:

• Chat: Q4_K_M
• Code: Q8, wenn Speicher reicht
• ausgewogener Betrieb: Q5_K_M

GPU-Offloading einstellen

Bei llama.cpp steuert -ngl, wie viele Schichten auf die GPU ausgelagert werden:

./llama-server -m model.gguf -ngl 40

Bei Ollama können Sie GPU-Parameter über Modelfiles und Laufzeitkonfigurationen steuern.

Grundregel: Lagern Sie so viele Schichten wie möglich auf die GPU aus. Jede Schicht auf der CPU senkt den Durchsatz.

mmap aktiviert lassen

mmap ist in llama.cpp und Ollama standardmäßig aktiviert. Das Betriebssystem lädt Modellgewichte bei Bedarf, statt das komplette Modell beim Start zu reservieren.

Lassen Sie mmap aktiviert, außer Sie arbeiten in Containern mit sehr engen Speicherlimits.

Batching mit vLLM nutzen

vLLM ist stark bei parallelen Requests. Für lokale oder gemeinsam genutzte Testumgebungen können Sie die maximale Anzahl paralleler Sequenzen begrenzen:

vllm serve meta-llama/Llama-3.3-70B-Instruct \
  --max-num-seqs 64

Für große GPU-Server kann der Wert höher sein:

vllm serve meta-llama/Llama-3.3-70B-Instruct \
  --max-num-seqs 256

Streaming aktivieren

Streaming reduziert die wahrgenommene Latenz, weil Tokens sofort zurückgegeben werden.

Python:

stream = client.chat.completions.create(
    model="llama3.3:70b-instruct-q4_K_M",
    messages=[{"role": "user", "content": "Explain local LLM APIs."}],
    stream=True,
)

for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="")

System-Prompts in Ollama-Modelfiles kapseln

Mit einem Ollama-Modelfile können Sie System-Prompt, Temperatur und Stop-Sequenzen zentral definieren.

FROM llama3.3:70b-instruct-q4_K_M

SYSTEM """
You are a JSON-only assistant.
Always return valid JSON.
"""

PARAMETER temperature 0.2
PARAMETER stop "<|eot_id|>"

Modell erstellen:

ollama create my-assistant -f Modelfile

Client-Code:

response = client.chat.completions.create(
    model="my-assistant",
    messages=[
        {"role": "user", "content": "Return status ok."}
    ],
)

Häufige Fehler

• http://localhost:11434 im Produktionscode hardcodieren
  
  → Verwenden Sie BASE_URL.

• Authorization-Header weglassen
  
  → Ollama ignoriert ihn häufig, vLLM mit --api-key nicht.

• falschen Modellnamen verwenden
  
  → Der Modellname muss zur Laufzeit passen, z. B. llama3.3:70b-instruct-q4_K_M.

• lokale und gehostete Antwortform nicht testen
  
  → Nutzen Sie dieselben Apidog-Assertions für beide Ziele.

• zu hohe max_tokens setzen
  
  → Lokale Modelle generieren sonst unnötig lange Antworten.

• GPT-Qualität von stark quantisierten Modellen erwarten
  
  → Q4 ist praktisch, aber nicht identisch mit FP16 oder gehosteten Frontier-Modellen.

Lokal vs. gehostet: Kosten und Latenz

Die folgenden Zahlen gehen von einem M3 Max mit 128 GB Unified Memory für lokale Ausführung und öffentlichen Preisen für gehostete Endpunkte aus. Die Zeit bis zum ersten Token wird kalt, ohne Batching, bei einem 1.024-Token-Prompt gemessen.

Modell	Lokale TTFT	Lokaler Durchsatz	Gehostetes Äquivalent	Gehosteter Preis	Gehostete TTFT
Llama 3.3 70B Q4_K_M	1.2 s	12 tok/s	GPT-5.5 Instant	$5 / $30 per 1M	200 ms
DeepSeek V4 67B Q4_K_M	1.4 s	10 tok/s	DeepSeek-Chat hosted	$0.55 / $2.20 per 1M	280 ms
Qwen 3.6 32B Q5_K_M	0.7 s	28 tok/s	Qwen-Max hosted	$1.60 / $6.40 per 1M	240 ms
Gemma 4 27B Q4_K_M	0.5 s	35 tok/s	Gemini 3 Flash	$0.35 / $1.05 per 1M	180 ms

Gehostete Modelle gewinnen meist bei Latenz und operativem Komfort. Lokale Modelle gewinnen bei Datenschutz und Entwicklungskosten, besonders bei hohem Token-Volumen.

Ein praktikables Setup:

1. lokal im inneren Entwicklungszyklus
2. gehostet im Staging
3. beide Ziele in CI testen
4. Produktionsziel je nach Datenschutz, Kosten und Latenz wählen

Für weitere Benchmarks siehe Wie man DeepSeek V4 lokal ausführt und den DeepSeek V4 Benutzerleitfaden.

Anwendungsfälle aus der Praxis

Ein Fintech-Compliance-Team kann Ollama auf Entwickler-Laptops verwenden, um Prompts mit Kontonummern und Transaktionsmustern lokal zu testen. In Produktion wird derselbe Request gegen einen gehosteten Endpunkt geschickt, aber erst nachdem sensible Felder redigiert wurden. Apidog-Szenarien stellen sicher, dass der Redaktionsschritt immer läuft.

Ein Spielestudio kann Prompt Engineering mit einer lokalen Qwen-Instanz trainieren. Die Kosten bleiben niedrig, und unveröffentlichte Lore verlässt nicht das Gerät. Für Produktion kann dasselbe Projekt per Umgebungsvariable auf Gemini 3 Flash wechseln. Die Verdrahtung ist im Gemini 3 Flash API-Leitfaden beschrieben.

Ein Healthcare-Startup kann vLLM auf einem A100 innerhalb eines Krankenhausnetzwerks betreiben. Der Endpunkt ist nicht öffentlich erreichbar. Integrationstests laufen von einem Jenkins-Agenten im selben VLAN gegen dasselbe OpenAI SDK, das lokal verwendet wird.

Fazit

Lokale LLM-APIs sind inzwischen praktisch genug für den Entwicklungsalltag. Der Schlüssel ist nicht ein neues SDK, sondern ein stabiler OpenAI-kompatibler Vertrag.

Implementieren Sie den Workflow so:

1. Wählen Sie Ollama für Laptops, vLLM für GPU-Cluster und llama.cpp für maximale Kontrolle.
2. Starten Sie den OpenAI-kompatiblen Endpunkt.
3. Verifizieren Sie ihn mit Python oder curl.
4. Verschieben Sie base_url, api_key und model in Umgebungsvariablen.
5. Erstellen Sie in Apidog identische Szenariotests für Local und Production.

Wenn Sie noch kein Modell ausgewählt haben, starten Sie mit Beste lokale LLMs 2026. Wenn Sie agentische Workflows testen, lesen Sie Wie man KI-Agenten-APIs testet.