Die ultimative lokale KI-Schaltzentrale: DeepSeek-R1, Open WebUI und LiteLLM

In einer Welt, in der Daten das neue Gold sind, wird die Abhängigkeit von Cloud-basierten KI-Anbietern zunehmend kritisch. Ob aus Datenschutzgründen, zur Kostenkontrolle oder einfach für maximale Autonomie – der Trend zum Self-Hosting von Large Language Models (LLMs) ist ungebrochen.

Doch wie baut man eine Infrastruktur, die nicht nur aus einem simplen Chat-Interface besteht, sondern als echte Enterprise-Schaltzentrale fungiert? Die Antwort liegt in der Kombination von DeepSeek-R1, Open WebUI und dem mächtigen LiteLLM.

Warum LiteLLM der Gamechanger ist

Die meisten Nutzer installieren Ollama und hängen ein Webinterface davor. Das funktioniert, ist aber starr. LiteLLM fungiert als Abstraktionsschicht (Proxy), die:

Einheitliche API: Lokale Modelle und externe APIs (Claude, GPT-4) unter einem einzigen OpenAI-kompatiblen Endpoint vereint.
Load Balancing: Anfragen intelligent zwischen mehreren Instanzen verteilt.
Caching: Redundante Anfragen lokal zwischenspeichert (Redis-Integration).

Das Setup: Der Docker-Verbund

Hier ist das docker-compose.yaml, das wir bei Eckelsoft als Standard-Workbench nutzen:

# eckelsoft@servebox: ~/ai-workbench/docker-compose.yaml
services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    volumes:
      - ollama_data:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

  litellm:
    image: ghcr.io/berriai/litellm:main-latest
    container_name: litellm-proxy
    ports:
      - "4000:4000"
    volumes:
      - ./litellm_config.yaml:/app/config.yaml
    command: [ "--config", "/app/config.yaml" ]

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "8080:8080"
    environment:
      - 'OPENAI_API_BASE_URL=http://litellm:4000/v1'
      - 'OPENAI_API_KEY=sk-anything'
    volumes:
      - webui_data:/app/data

volumes:
  ollama_data:
  webui_data:

Die LiteLLM Konfiguration

Damit LiteLLM weiß, wohin es routen soll, benötigen wir eine litellm_config.yaml:

# eckelsoft@servebox: ~/ai-workbench/litellm_config.yaml
model_list:
  - model_name: local-deepseek
    litellm_params:
      model: ollama/deepseek-r1:14b
      api_base: http://ollama:11434

  - model_name: cloud-claude
    litellm_params:
      model: anthropic/claude-3-5-sonnet-20241022
      api_key: os.environ/ANTHROPIC_API_KEY

Praxis-Beispiel: Die "Eckelsoft AI-Gateway" Strategie

Stell dir vor, dein Entwickler-Team arbeitet an einer sensiblen Applikation. Anstatt jedem Entwickler einen eigenen API-Key für Claude oder OpenAI zu geben, greifen alle auf das zentrale LiteLLM-Gateway zu.

Der Workflow in der Praxis:

Entwicklung & Debugging: Der Entwickler nutzt local-deepseek direkt in seiner IDE (z.B. via Continue.dev). Das kostet nichts und die Daten verlassen niemals den Server.
Finaler Schliff: Sobald der Code komplexer wird, switcht der Entwickler im Open WebUI einfach auf cloud-claude. LiteLLM regelt die Authentifizierung und das Logging zentral.

# eckelsoft@servebox: Starten der Workbench
docker compose up -d

# sandbox@my-sandbox1: Testen des Gateways
curl http://localhost:4000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "local-deepseek",
    "messages": [{"role": "user", "content": "Erkläre mir LiteLLM in einem Satz."}]
  }'

Fazit: Souveränität durch Abstraktion

Mit diesem Setup bist du nicht mehr Sklave eines einzelnen Anbieters. Du kannst lokale Modelle für 90% deiner Aufgaben nutzen und nur bei Bedarf auf teure Cloud-Modelle umschalten – alles über ein einziges, stabiles Gateway.

Eckelsoft Tipp: Nutze DeepSeek-R1 (14b oder höher) für logische Aufgaben und kombiniere es mit einem Redis-Cache in LiteLLM, um die Antwortzeiten bei wiederkehrenden Fragen auf nahezu Null zu senken.

Viel Spaß beim Experimentieren in deiner eigenen Sandbox!