KI Modelle lokal ausführen vs. API: Was ist die beste Wahl?

TL;DR

Lokale KI läuft auf Ihrer Hardware, kostet pro Anfrage nichts und hält Daten privat. API-basierte KI ist schneller einsatzbereit, leistungsfähiger und skaliert ohne Infrastruktur. Die meisten Teams benötigen beides. Dieser Leitfaden behandelt, wann welcher Ansatz überlegen ist, mit konkreten Zahlen.

Einleitung

Gemma 4 läuft nativ auf einem iPhone. Eine Browser-Erweiterung, die ein vollständiges Sprachmodell ohne API-Schlüssel einbettet. Das war vor 18 Monaten noch nicht möglich. Heute erscheinen solche Dinge auf HackerNews.

Früher war die Entscheidung einfach: Spitzenmodelle gab es nur über APIs, alles andere war zu schwach, um relevant zu sein. Das hat sich geändert. Lokale Modelle wie Qwen2.5-72B, Gemma 4 und DeepSeek-V3 konkurrieren nun auf echten Benchmarks. Entwickler, die zuvor standardmäßig auf die OpenAI-API setzten, überdenken dies, insbesondere bei datenschutzsensiblen Anwendungen oder Aufgaben mit hohem Volumen, bei denen die Kosten pro Token schnell ansteigen.

Dieser Artikel durchschaut das Marketing. Sie erhalten konkrete Zahlen zu Kosten, Latenz und Fähigkeiten, damit Sie die richtige Entscheidung für Ihren Anwendungsfall treffen können.

Was "lokale KI ausführen" wirklich bedeutet

Lokale KI ist nicht einheitlich. Es gibt drei verschiedene Setups:

Inferenz auf dem Gerät: Das Modell läuft vollständig auf dem Gerät, ohne Server. Gemma Gem in einem Browser-Tab, Gemma 4 auf der Neural Engine eines iPhones oder ein Ollama-Modell auf Ihrem MacBook. Nach dem Download ist kein Internet erforderlich.

Selbstgehosteter Server: Sie betreiben ein Modell auf Ihrer eigenen Hardware (einer Workstation, einer von Ihnen kontrollierten Cloud-VM oder einem On-Premise-Server) und stellen eine API bereit. Das Modell läuft nicht auf dem Gerät des Endbenutzers, befindet sich aber auch nicht bei OpenAI. Tools wie Llama-Server, Ollama und vLLM übernehmen dies.

Private Cloud: Sie stellen ein Modell in Ihrer eigenen Cloud-Infrastruktur bereit (benutzerdefinierte AWS Bedrock-Modelle, private Azure-Endpunkte, benutzerdefinierte GCP Vertex AI-Modelle). Mehr Kontrolle als bei einer öffentlichen API, weniger Aufwand als bei vollständig selbstgehosteten Lösungen.

Der Vergleich in diesem Artikel konzentriert sich auf selbstgehostete vs. öffentliche API, da dies die Entscheidung ist, vor der die meisten Entwickler stehen.

Kostenvergleich

Hier punktet lokale KI bei Arbeitslasten mit hohem Volumen eindeutig.

Preise für öffentliche APIs (April 2026):

Kostenabschätzung für selbstgehostete Lösungen (Qwen2.5-72B auf einer einzelnen A100 80GB):

Eine A100 80GB von Lambda Labs kostet On-Demand etwa 1,99 $/Stunde. Qwen2.5-72B mit INT4-Quantisierung passt auf eine A100 und verarbeitet etwa 200 Tokens/Sekunde.

Bei 200 Tokens/Sekunde und 100% Auslastung sind das 720K Tokens/Stunde, oder etwa 0,0028 $ pro 1K Tokens insgesamt (Eingabe + Ausgabe). Zum Vergleich: GPT-4o berechnet allein 0,01 $ pro 1K Tokens Ausgabe.

Gewinnschwelle: Wenn Sie dauerhaft mehr als ca. 70.000 Ausgabetokens pro Tag verarbeiten, ist die selbstgehostete Lösung kostengünstiger als GPT-4o. Darunter gewinnt die API, da Sie keine Leerlaufzeit der GPU bezahlen.

Für leichtere Modelle: Ein 4-Bit quantisiertes Gemma 4 (12B) läuft auf einer einzelnen RTX 4090 (gebraucht 600-800 $). Bei 0,40 $/Stunde für äquivalente Cloud-GPU-Zeit rechnet sich das Self-Hosting gegenüber GPT-4o mini bei etwa 15.000 Ausgabetokens/Tag.

Latenzvergleich

Hier wird es nuancierter.

Zeit bis zum ersten Token (TTFT): Auf einer dedizierten A100 beträgt die TTFT für einen 1K-Token-Prompt mit einem 72B-Modell etwa 800 ms bis 1,5 s. Die OpenAI-API liefert das erste Token typischerweise in 300-800 ms für ähnliche Eingaben unter normaler Last.

Für die Inferenz auf dem Gerät (iPhone Neural Engine, Apple Silicon) beträgt die TTFT für Gemma 4 200-400 ms, da es keinen Netzwerk-Overhead gibt. Hier ist die Inferenz auf dem Gerät eindeutig im Vorteil.

Durchsatz: Eine einzelne A100, die ein 72B-Modell mit INT4 ausführt, bedient einen Benutzer gut, verschlechtert sich aber unter gleichzeitiger Last ohne Batching. Öffentliche APIs handhaben Parallelität transparent.

Streaming: Beide Ansätze unterstützen Streaming. Bei On-Device-Modellen erfolgt die gesamte Generierung lokal, sodass es keinen Netzwerk-Jitter gibt. Bei API-Modellen sind Sie den Netzwerkbedingungen ausgeliefert.

Zusammenfassung: On-Device gewinnt bei niedrigster Latenz (kein Netzwerk). Self-Hosted gewinnt bei Durchsatz in großem Maßstab (mit ordentlichem Batching über vLLM). Die öffentliche API gewinnt bei Burst-Kapazität und Einfachheit.

Fähigkeitsvergleich

Hier haben öffentliche APIs bei den anspruchsvollsten Aufgaben immer noch die Nase vorn.

Argumentation und komplexe Aufgaben: GPT-4o und Claude 3.5 Sonnet bleiben den Open-Weight-Modellen bei MMLU, HumanEval und komplexer mehrstufiger Argumentation überlegen. Der Abstand hat sich mit Qwen2.5-72B und DeepSeek-V3 erheblich verringert, ist aber immer noch vorhanden.

Code-Generierung: eng. DeepSeek-Coder-V2 und Qwen2.5-Coder-32B erreichen bei vielen Code-Benchmarks die Leistung von GPT-4o. Für codespezifische Aufgaben in einem selbstgehosteten Setup können Sie ein spezialisiertes Code-Modell anstelle eines Allzweckmodells verwenden.

Kontextlänge: Frontier-API-Modelle unterstützen Kontextlängen von 128K-1M Tokens. Die meisten selbstgehosteten Modelle erreichen in der Praxis maximal 32K-128K (längere Kontexte erfordern proportional mehr Speicher).

Multimodal: GPT-4o und Gemini 1.5 Pro verarbeiten Bild-, Audio- und Videoeingaben. Open-Weight-Multimodal-Modelle existieren (LLaVA, Qwen-VL), hinken aber hinterher.

Funktionsaufruf / Werkzeugnutzung: OpenAI und Anthropic bieten die zuverlässigste Unterstützung für die Werkzeugnutzung. Open-Weight-Modelle mit Werkzeugnutzung funktionieren, sind aber bei komplexen Werkzeugketten weniger konsistent. Siehe [internal: how-ai-agent-memory-works], wie dies Agentenarchitekturen beeinflusst.

Datenschutz und Datenkontrolle

Hier ist die lokale Lösung konkurrenzlos im Vorteil.

Bei einer öffentlichen API: - Ihre Prompts verlassen Ihr Netzwerk - Es gelten die Datenaufbewahrungsrichtlinien des Anbieters (OpenAI speichert Eingaben standardmäßig 30 Tage lang, es sei denn, Sie widersprechen über die API) - Sie unterliegen den Nutzungsbedingungen des Anbieters bezüglich sensibler Inhalte - In regulierten Branchen (Gesundheitswesen, Finanzen, Recht) kann dies ein Compliance-Blocker sein

Bei einem selbstgehosteten Modell: - Prompts bleiben in Ihrer Infrastruktur - Keine Datenspeicherung durch Dritte - Volle Kontrolle darüber, was das Modell verarbeiten darf und was nicht - GDPR/HIPAA-Konformität ist einfacher zu gewährleisten

Für Anwendungen, die persönliche Gesundheitsdaten, juristische Dokumente oder proprietären Code verarbeiten, ist Self-Hosting oft nicht optional.

So testen Sie KI-Integrationen, unabhängig davon, wo das Modell läuft

Ob Sie https://api.openai.com/v1/chat/completions oder http://localhost:11434/api/chat (Ollama) oder http://localhost:8080/v1/chat/completions (llama-server) ansprechen, die API-Oberfläche ist OpenAI-kompatibel. Dies ist wichtig, da Apidog-Testszenarien mit jedem HTTP-Endpunkt funktionieren.

Ein einziges Testszenario kann für beide ausgeführt werden:

{
  "scenario": "Chat completion smoke test",
  "environments": {
    "local": {"base_url": "http://localhost:11434"},
    "production": {"base_url": "https://api.openai.com"}
  },
  "steps": [
    {
      "name": "Basic completion",
      "method": "POST",
      "url": "{{base_url}}/v1/chat/completions",
      "body": {
        "model": "{{model_name}}",
        "messages": [{"role": "user", "content": "Say 'test passed' and nothing else"}],
        "max_tokens": 20
      },
      "assertions": [
        {"field": "status", "operator": "equals", "value": 200},
        {"field": "response.choices[0].message.content", "operator": "contains", "value": "test passed"},
        {"field": "response.usage.total_tokens", "operator": "less_than", "value": 50}
      ]
    }
  ]
}

Führen Sie dieses Szenario während der Entwicklung gegen Ihre lokale Ollama-Instanz und in CI gegen die OpenAI-API aus. Wenn Ihr Code mit dem lokalen Modell funktioniert, sollte er auch mit der API funktionieren. Falls nicht, liegt der Unterschied normalerweise in: - Format des Modellnamens (Ollama verwendet qwen2.5:72b, OpenAI gpt-4o) - Antwortstruktur bei Funktionsaufrufen (feine Unterschiede zwischen Anbietern) - Streaming-Ereignisformat (Daten vs. Delta vs. vollständige Antwortobjekte)

Apidogs Smart Mock ist nützlich, um das Verhalten lokaler Modelle in CI zu simulieren, ohne dass die GPU online sein muss. Konfigurieren Sie einen Mock, der gültige OpenAI-kompatible Antworten zurückgibt, und führen Sie Ihre Testszenarien dagegen aus. Siehe [internal: how-to-build-tiny-llm-from-scratch] für Hintergrundinformationen, warum sich die Antwortstrukturen auf Modellebene unterscheiden.

Einen lokalen Modellserver in 10 Minuten einrichten

Wenn Sie Self-Hosted ausprobieren möchten, bevor Sie sich festlegen, ist Ollama der schnellste Weg:

# Install Ollama
curl -fsSL https://ollama.com/install.sh | sh

# Pull a model (Gemma 4 12B, fits in 10GB VRAM)
ollama pull gemma4:12b

# Start the server (OpenAI-compatible API on port 11434)
ollama serve

# Test it
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemma4:12b",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

Für das Self-Hosting in der Produktion mit Multi-User-Parallelität ist vLLM die bessere Wahl:

pip install vllm
python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-72B-Instruct-AWQ \
  --quantization awq \
  --max-model-len 32768

Dies stellt eine OpenAI-kompatible API auf Port 8000 bereit. Richten Sie Apidog auf http://your-server:8000 und führen Sie Ihre Testszenarien direkt aus.

Wann welcher Ansatz zu wählen ist

Die ehrliche Antwort für die meisten Teams: Nutzen Sie eine öffentliche API für die Produktion (Claude oder GPT-4o für Qualitätsaufgaben, Haiku oder 4o-mini für kostengünstigere Aufgaben mit hohem Volumen) und Ollama lokal für Entwicklung und Tests. Dies bietet Ihnen das Beste aus beiden Welten: Spitzenqualität in der Produktion, keine Kosten in der Entwicklung und eine durchgängig konsistente OpenAI-kompatible API-Oberfläche.

Siehe [internal: open-source-coding-assistants-2026], wie Open-Source-Code-Assistenten in das Bild der lokalen KI passen.

Fazit

Die Entscheidung zwischen lokaler KI und API ist nicht binär. Die richtige Antwort hängt von Ihrem Volumen, Ihren Datenschutzanforderungen, Ihren Latenzbedürfnissen und dem benötigten Leistungsniveau ab.

Für die meisten Entwickler, die KI-gestützte Anwendungen erstellen: Beginnen Sie mit einer öffentlichen API, wechseln Sie zu einer selbstgehosteten Lösung, wenn Ihre monatliche Rechnung 200-300 $ übersteigt, und verwenden Sie Ollama von Anfang an in Ihrer lokalen Umgebung. Halten Sie Ihren Code anbieterunabhängig, indem Sie die OpenAI-kompatible API-Oberfläche überall verwenden.

Testen Sie beide Umgebungen konsistent mit Apidog, um die feinen Unterschiede zwischen dem Verhalten lokaler und Cloud-Modelle zu erkennen, bevor sie zu Produktionsfehlern werden.

FAQ

Was ist die minimale GPU, um ein nützliches lokales Modell auszuführen?Eine RTX 3060 (12 GB VRAM) führt Qwen2.5-7B oder Gemma 4 4B in voller Qualität aus. Eine RTX 4090 (24 GB VRAM) bewältigt die meisten 14B-20B-Modelle mit INT4-Quantisierung und 34B-Modelle mit INT2. Für 72B-Modelle benötigen Sie 2x 24GB GPUs oder eine einzelne A100/H100.

Kann ich lokale KI auf Apple Silicon ausführen?Ja. Ollama bietet native Unterstützung für Apple Silicon und nutzt die Neural Engine zur Beschleunigung. Ein M3 Pro (18 GB Unified Memory) führt Qwen2.5-14B problemlos aus. Ein M4 Max (128 GB) bewältigt 70B-Modelle.

Ist die Ausgabequalität lokaler Modelle gut genug für die Produktion?Das hängt von der Aufgabe ab. Für Codegenerierung, Zusammenfassungen und strukturierte Datenextraktion: ja, mit einem 32B+-Modell. Für komplexe Argumentation, nuanciertes Schreiben oder Aufgaben, die tiefes Weltwissen erfordern: Frontier-API-Modelle haben immer noch einen klaren Vorsprung.

Unterstützen lokale Modelle Funktionsaufrufe?Ja, aber inkonsistent. Llama 3.1, Qwen2.5 und Mistral unterstützen alle die Werkzeugnutzung. Die Zuverlässigkeit ist jedoch geringer als bei GPT-4o oder Claude 3.5 Sonnet bei komplexen Werkzeugketten. Testen Sie gründlich mit Apidog-Testszenarien, bevor Sie sich in der Produktion auf die lokale Modell-Werkzeugnutzung verlassen. Siehe [internal: claude-code] wie Frontier-Modelle die Werkzeugnutzung in Codierungskontexten handhaben.

Wie viel kostet es, ein 70B-Modell auf AWS selbst zu hosten?Eine p4d.24xlarge (8x A100 40GB) kostet On-Demand 32,77 $/Stunde. Führt ein 70B INT8-Modell mit hohem Durchsatz aus. Eine g5.2xlarge (1x A10G 24GB) für 1,21 $/Stunde führt ein 14B INT4-Modell für leichtere Workloads aus. Reservierte Instanzen reduzieren diese Kosten um 30-40%.

Was ist der Unterschied zwischen Ollama und llama.cpp?llama.cpp ist die zugrundeliegende Inferenz-Engine. Ollama umschließt llama.cpp mit einer REST-API, Modellverwaltung (Pull, List, Delete) und einem einfachen CLI. Verwenden Sie Ollama für die Entwicklung. Verwenden Sie llama.cpp direkt (über llama-server), wenn Sie mehr Kontrolle über Quantisierungsformate oder Hardwarekonfiguration benötigen.

Kann ich zwischen lokalen und API-Modellen wechseln, ohne meinen Code zu ändern?Ja, wenn Sie einen OpenAI-kompatiblen Client verwenden. In Python: openai.OpenAI(base_url='http://localhost:11434/v1', api_key='ollama') verbindet sich mit Ollama. Ändern Sie base_url auf https://api.openai.com/v1 und aktualisieren Sie api_key, um zur Cloud zu wechseln. Legen Sie diese über Umgebungsvariablen fest, und Ihr Code ändert sich nie.