Docker Compose AI-Fullstack-Bereitstellung: Ein-Klick-Orchestrierung vom LLM zur Vektordatenbank

DevOps

Einrichtung einer AI-Entwicklungsumgebung dauert immer noch drei Tage?

Im Jahr 2026 bleibt die Einrichtung der AI-Entwicklungsumgebung ein Albtraum für Entwickler. Sie müssen Ollama für LLM-Serving installieren, Qdrant für Vektorspeicherung konfigurieren, Embedding-Dienste einrichten, ein API-Gateway für Authentifizierung erstellen und GPU-Treiber, CUDA-Versionen und Modell-Downloads verwalten... Drei Tage vorbei, und Sie haben keine einzige Zeile Code geschrieben.

Die Docker Compose AI-Fullstack-Bereitstellung orchestriert alles in einer einzigen Datei. docker compose up -d startet den gesamten AI-Stack in Minuten. Dieser Artikel ist eine vollständige praktische Anleitung, die 7 Kernmuster, 5 häufige Fallstricke, 10 Fehlerbehebungsmaßnahmen und Produktionshärtungsstrategien abdeckt.

Kernpunkte

  • Docker Compose AI-Fullstack-Bereitstellung = LLM + Vektordatenbank + Embedding + API-Gateway + Monitoring, eine Datei, sie alle zu beherrschen
  • Ollama + OpenWebUI ist die ausgereifteste lokale LLM-Serving-Lösung
  • Qdrant/Milvus sind die bevorzugten Vektordatenbanken mit kinderleichter Docker-Bereitstellung
  • GPU-Passthrough ist entscheidend für AI-Bereitstellung — konfigurieren über deploy.resources.reservations.devices
  • Produktion erfordert Authentifizierung, Ratenbegrenzung, Monitoring und Backup-Härtung

Inhaltsverzeichnis

  • Übersicht der AI-Fullstack-Architektur
  • Muster 1: Ollama + OpenWebUI LLM-Serving
  • Muster 2: Qdrant/Milvus Vektordatenbanken
  • Muster 3: Embedding-Dienste und Modellverwaltung
  • Muster 4: API-Gateway und Authentifizierung
  • Muster 5: GPU-Passthrough und Ressourcenlimits
  • Muster 6: Monitoring und Observability
  • Muster 7: Produktionshärtung und Sicherheit
  • 5 häufige Fallstricke und Lösungen
  • 10 häufige Fehlerbehebungen
  • Erweiterte Optimierungstipps
  • Vergleich: Docker Compose vs K8s vs Docker Swarm
  • Empfohlene Online-Tools
  • Zusammenfassung

Übersicht der AI-Fullstack-Architektur

Die Docker Compose AI-Fullstack-Bereitstellung basiert auf einer 7-schichtigen Architektur, von der GPU ganz unten bis zum API-Gateway ganz oben:

┌─────────────────────────────────────────────────────┐
│                   API Gateway                        │
│              (Traefik / Nginx)                       │
│         Auth · Rate Limit · Routing · TLS            │
├──────────┬──────────┬──────────┬────────────────────┤
│ OpenWebUI│  RAG App │  Agent   │  Admin Panel       │
│  (Chat)  │ (Search) │  (Proxy) │  (Management)      │
├──────────┴──────────┴──────────┴────────────────────┤
│              Embedding Service                       │
│       (TEI / Infinity / FastEmbed)                  │
├──────────────────┬──────────────────────────────────┤
│   Ollama LLM     │    vLLM / TGI                    │
│  (Model Serving) │  (High-Perf Inference)           │
├──────────────────┴──────────────────────────────────┤
│           Vector Database                            │
│     (Qdrant / Milvus / Weaviate)                    │
├─────────────────────────────────────────────────────┤
│              Infrastructure                          │
│   Redis · PostgreSQL · MinIO · Prometheus            │
├─────────────────────────────────────────────────────┤
│              GPU / CPU Runtime                       │
│     NVIDIA CUDA · ROCm · CPU Fallback               │
└─────────────────────────────────────────────────────┘

Projektverzeichnisstruktur für die Docker Compose AI-Fullstack-Bereitstellung:

ai-stack/
├── docker-compose.yml
├── docker-compose.gpu.yml
├── docker-compose.prod.yml
├── .env
├── ollama/
│   └── Modelfile
├── qdrant/
│   └── config.yaml
├── traefik/
│   ├── traefik.yml
│   └── acme.json
├── monitoring/
│   ├── prometheus.yml
│   └── grafana/
│       └── dashboards/
└── scripts/
    ├── init-models.sh
    └── backup-vectors.sh

Muster 1: Ollama + OpenWebUI LLM-Serving

Ollama ist die ausgereifteste lokale LLM-Serving-Lösung im Jahr 2026 und unterstützt Llama 4, Qwen 3, DeepSeek V3 und andere Mainstream-Modelle. OpenWebUI bietet eine ChatGPT-ähnliche Weboberfläche.

Grundkonfiguration

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    ports:
      - "11434:11434"
    volumes:
      - ollama_data:/root/.ollama
    environment:
      OLLAMA_KEEP_ALIVE: "24h"
      OLLAMA_NUM_PARALLEL: "4"
      OLLAMA_MAX_LOADED_MODELS: "3"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:11434/api/tags"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 60s
    restart: unless-stopped

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "3000:8080"
    volumes:
      - open_webui_data:/app/backend/data
    environment:
      OLLAMA_BASE_URL: "http://ollama:11434"
      WEBUI_SECRET_KEY: "${WEBUI_SECRET_KEY}"
      ENABLE_SIGNUP: "false"
      DEFAULT_USER_ROLE: "user"
    depends_on:
      ollama:
        condition: service_healthy
    restart: unless-stopped

volumes:
  ollama_data:
  open_webui_data:

Automatischer Modell-Pull

Nach dem Start von Ollama müssen Sie Modelle manuell herunterladen. Automatisieren Sie dies mit einem Init-Skript:

#!/bin/bash
# scripts/init-models.sh

MODELS=(
  "qwen3:8b"
  "llama4:8b"
  "deepseek-v3:8b"
  "nomic-embed-text"
)

for model in "${MODELS[@]}"; do
  echo "Pulling model: $model"
  until curl -s http://localhost:11434/api/pull -d "{\"name\":\"$model\"}" | grep -q "success"; do
    echo "  Retrying $model..."
    sleep 5
  done
  echo "  ✓ $model ready"
done

echo "All models pulled successfully!"

Fügen Sie den Init-Dienst zu Docker Compose hinzu:

  model-init:
    image: curlimages/curl:latest
    container_name: model-init
    depends_on:
      ollama:
        condition: service_healthy
    volumes:
      - ./scripts/init-models.sh:/init-models.sh:ro
    entrypoint: ["/bin/sh", "/init-models.sh"]
    restart: "no"

Benutzerdefinierte Modelfile

# ollama/Modelfile
FROM qwen3:8b

PARAMETER temperature 0.7
PARAMETER top_p 0.9
PARAMETER num_ctx 8192
PARAMETER stop "<|im_end|>"

SYSTEM """
You are a professional AI assistant. When answering questions:
1. Give a concise conclusion first
2. Then provide detailed explanation
3. If uncertain, say so explicitly
"""

Erstellen Sie ein benutzerdefiniertes Modell:

docker exec ollama ollama create my-assistant -f /root/.ollama/Modelfile

Muster 2: Qdrant/Milvus Vektordatenbanken

Vektordatenbanken sind der Kern der RAG-Architektur. Die Docker Compose AI-Fullstack-Bereitstellung verwendet typischerweise Qdrant (leichtgewichtig) oder Milvus (großskalig).

Qdrant-Konfiguration (Empfohlen für kleine bis mittlere Projekte)

  qdrant:
    image: qdrant/qdrant:latest
    container_name: qdrant
    ports:
      - "6333:6333"
      - "6334:6334"
    volumes:
      - qdrant_data:/qdrant/storage
      - ./qdrant/config.yaml:/qdrant/config/production.yaml:ro
    environment:
      QDRANT__SERVICE__GRPC_PORT: "6334"
      QDRANT__LOG_LEVEL: "INFO"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:6333/healthz"]
      interval: 10s
      timeout: 5s
      retries: 3
    restart: unless-stopped

Qdrant-Konfigurationsdatei:

# qdrant/config.yaml
storage:
  performance:
    max_search_threads: 4
  wal:
    wal_capacity_mb: 32
    wal_segments_ahead: 0
  optimizers:
    indexing_threshold: 20000
    memmap_threshold: 50000
service:
  max_request_size_mb: 64
  enable_cors: true
telemetry_disabled: true

Milvus-Konfiguration (Empfohlen für großskalige Projekte)

  etcd:
    image: quay.io/coreos/etcd:v3.5.16
    container_name: milvus-etcd
    environment:
      ETCD_AUTO_COMPACTION_MODE: "revision"
      ETCD_AUTO_COMPACTION_RETENTION: "1000"
      ETCD_QUOTA_BACKEND_BYTES: "4294967296"
    volumes:
      - etcd_data:/etcd
    command: etcd -advertise-client-urls=http://127.0.0.1:2379 -listen-client-urls http://0.0.0.0:2379
    restart: unless-stopped

  minio:
    image: minio/minio:latest
    container_name: milvus-minio
    environment:
      MINIO_ACCESS_KEY: "${MINIO_ACCESS_KEY}"
      MINIO_SECRET_KEY: "${MINIO_SECRET_KEY}"
    ports:
      - "9001:9001"
      - "9000:9000"
    volumes:
      - minio_data:/minio_data
    command: minio server /minio_data --console-address ":9001"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"]
      interval: 30s
      timeout: 20s
      retries: 3
    restart: unless-stopped

  milvus:
    image: milvusdb/milvus:v2.5-latest
    container_name: milvus
    ports:
      - "19530:19530"
      - "9091:9091"
    volumes:
      - milvus_data:/var/lib/milvus
    environment:
      ETCD_ENDPOINTS: "etcd:2379"
      MINIO_ADDRESS: "minio:9000"
    depends_on:
      - etcd
      - minio
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9091/healthz"]
      interval: 30s
      timeout: 20s
      retries: 3
      start_period: 90s
    restart: unless-stopped

Vergleich der Vektordatenbanken

Funktion Qdrant Milvus Weaviate ChromaDB
Bereitstellungskomplexität Sehr niedrig (1 Container) Hoch (3+ Container) Niedrig (1 Container) Sehr niedrig (1 Container)
Leistung (Millionen) Ausgezeichnet Ausgezeichnet Gut Befriedigend
Leistung (Milliarden) Gut Ausgezeichnet Befriedigend N/A
Gefilterte Suche ✅ Leistungsstark ✅ Leistungsstark ✅ Gut ⚠️ Basis
Persistenz ✅ ✅ ✅ ⚠️ Standardmäßig im Speicher
Multi-Replika ✅ ✅ ✅ ❌
gRPC-Unterstützung ✅ ✅ ❌ ❌
Docker Compose-Eignung ✅ Am besten ⚠️ Schwer ✅ Gut ✅ Nur Entwicklung
Produktionsbereit ✅ ✅ ✅ ❌ Nur Entwicklung

Empfehlung: Für die Docker Compose AI-Fullstack-Bereitstellung ist Qdrant die erste Wahl — einfache Bereitstellung, hervorragende Leistung. Erwägen Sie Milvus, wenn die Vektoranzahl 100 Millionen übersteigt. ChromaDB eignet sich nur für die Prototypenerstellung.

Muster 3: Embedding-Dienste und Modellverwaltung

Embedding-Dienste wandeln Text in Vektoren um, ein kritischer Schritt in der RAG-Pipeline. Die Docker Compose AI-Containerorchestrierung bietet drei Mainstream-Lösungen.

Hugging Face TEI (Empfohlen)

  tei:
    image: ghcr.io/huggingface/text-embeddings-inference:latest
    container_name: tei
    ports:
      - "8080:80"
    volumes:
      - tei_cache:/data
    environment:
      MODEL_ID: "BAAI/bge-m3"
      REVISION: "main"
      MAX_BATCH_TOKENS: "16384"
      MAX_CLIENT_BATCH_SIZE: "32"
      HF_TOKEN: "${HF_TOKEN}"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:80/health"]
      interval: 10s
      timeout: 5s
      retries: 3
      start_period: 120s
    restart: unless-stopped

Infinity Embedding-Dienst

  infinity:
    image: michaelf34/infinity:latest
    container_name: infinity
    ports:
      - "7997:7997"
    volumes:
      - infinity_cache:/app/.cache
    environment:
      MODEL_ID: "BAAI/bge-m3"
      ENGINE: "optimum"
      BATCH_SIZE: "32"
    command: >
      --model-id BAAI/bge-m3
      --engine optimum
      --port 7997
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:7997/health"]
      interval: 10s
      timeout: 5s
      retries: 3
    restart: unless-stopped

Beispiel für die Nutzung des Embedding-Dienstes

import httpx
import numpy as np

async def get_embeddings(texts: list[str]) -> list[list[float]]:
    async with httpx.AsyncClient(timeout=30.0) as client:
        response = await client.post(
            "http://tei:80/embed",
            json={"inputs": texts}
        )
        response.raise_for_status()
        return response.json()

async def search_similar(query: str, top_k: int = 5) -> list[dict]:
    query_embedding = await get_embeddings([query])
    async with httpx.AsyncClient(timeout=30.0) as client:
        response = await client.post(
            "http://qdrant:6333/collections/documents/points/search",
            json={
                "vector": query_embedding[0],
                "limit": top_k,
                "with_payload": True
            }
        )
        response.raise_for_status()
        return response.json()["result"]

Vergleich der Embedding-Dienste

Funktion TEI Infinity FastEmbed
GPU-Beschleunigung ✅ Nativ ✅ Nativ ❌ Nur CPU
Batch-Inferenz ✅ Effizient ✅ Effizient ⚠️ Befriedigend
Multi-Modell ✅ ✅ ✅
Docker-Image-Größe ~2GB ~4GB ~500MB
Produktionsbereit ✅ ✅ ⚠️ Nur Entwicklung
OpenAI-kompatible API ✅ ✅ ❌

Muster 4: API-Gateway und Authentifizierung

Die produktive Docker Compose AI-Fullstack-Bereitstellung erfordert ein API-Gateway für einheitliche Authentifizierung, Ratenbegrenzung und Routing.

Traefik-Konfiguration

  traefik:
    image: traefik:v3.2
    container_name: traefik
    ports:
      - "80:80"
      - "443:443"
      - "8080:8080"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./traefik/traefik.yml:/etc/traefik/traefik.yml:ro
      - traefik_certs:/etc/traefik/certs
      - ./traefik/dynamic:/etc/traefik/dynamic:ro
    command:
      - "--api.dashboard=true"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--providers.file.directory=/etc/traefik/dynamic"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--entrypoints.web.http.redirections.entrypoint.to=websecure"
    labels:
      traefik.enable: "true"
      traefik.http.routers.traefik.rule: "Host(`traefik.ai-stack.local`)"
      traefik.http.routers.traefik.entrypoints: "websecure"
      traefik.http.routers.traefik.tls: "true"
      traefik.http.services.traefik.loadbalancer.server.port: "8080"
    restart: unless-stopped

OpenWebUI mit Traefik

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    volumes:
      - open_webui_data:/app/backend/data
    environment:
      OLLAMA_BASE_URL: "http://ollama:11434"
    labels:
      traefik.enable: "true"
      traefik.http.routers.webui.rule: "Host(`chat.ai-stack.local`)"
      traefik.http.routers.webui.entrypoints: "websecure"
      traefik.http.routers.webui.tls: "true"
      traefik.http.services.webui.loadbalancer.server.port: "8080"
    depends_on:
      ollama:
        condition: service_healthy
    restart: unless-stopped

Authentifizierungs-Middleware

# traefik/dynamic/auth.yml
http:
  middlewares:
    auth-middleware:
      forwardAuth:
        address: "http://auth-service:8000/verify"
        trustForwardHeader: true
        authResponseHeaders:
          - "X-User-Id"
          - "X-User-Role"

    rate-limit:
      rateLimit:
        average: 30
        burst: 60
        period: 1m

  routers:
    api-router:
      rule: "Host(`api.ai-stack.local`)"
      entrypoints:
        - "websecure"
      tls: true
      middlewares:
        - "auth-middleware"
        - "rate-limit"
      service: "ollama-api"

Muster 5: GPU-Passthrough und Ressourcenlimits

Die GPU ist der Kern der AI-Bereitstellung. Die Docker Compose AI-Fullstack-Bereitstellung aktiviert GPU-Passthrough über deploy.resources.reservations.devices.

NVIDIA GPU-Passthrough

  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    volumes:
      - ollama_data:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
        limits:
          memory: 16G
          cpus: "8.0"
    environment:
      NVIDIA_VISIBLE_DEVICES: "all"
      NVIDIA_DRIVER_CAPABILITIES: "compute,utility"
      OLLAMA_KEEP_ALIVE: "24h"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:11434/api/tags"]
      interval: 30s
      timeout: 10s
      retries: 3
    restart: unless-stopped

Multi-GPU-Zuweisung

  ollama:
    image: ollama/ollama:latest
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              device_ids: ["0"]
              capabilities: [gpu]
    environment:
      CUDA_VISIBLE_DEVICES: "0"

  tei:
    image: ghcr.io/huggingface/text-embeddings-inference:latest
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              device_ids: ["1"]
              capabilities: [gpu]
    environment:
      CUDA_VISIBLE_DEVICES: "1"

CPU-Fallback-Konfiguration

  ollama-cpu:
    image: ollama/ollama:latest
    profiles: ["cpu-only"]
    container_name: ollama
    volumes:
      - ollama_data:/root/.ollama
    environment:
      OLLAMA_NUM_PARALLEL: "2"
      OLLAMA_MAX_LOADED_MODELS: "1"
    deploy:
      resources:
        limits:
          memory: 8G
          cpus: "4.0"

  ollama-gpu:
    image: ollama/ollama:latest
    profiles: ["gpu"]
    container_name: ollama
    volumes:
      - ollama_data:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
        limits:
          memory: 16G

Startbefehle:

# GPU-Modus
docker compose --profile gpu up -d

# CPU-Modus
docker compose --profile cpu-only up -d

GPU-Ressourcen-Monitoring-Skript

import subprocess
import json
import time

def monitor_gpu_usage(interval: int = 60):
    while True:
        result = subprocess.run(
            ["nvidia-smi", "--query-gpu=index,name,memory.used,memory.total,utilization.gpu",
             "--format=csv,noheader,nounits"],
            capture_output=True, text=True
        )
        for line in result.stdout.strip().split("\n"):
            idx, name, mem_used, mem_total, util = line.split(", ")
            print(f"GPU {idx} ({name}): {mem_used}/{mem_total}MB, Util: {util}%")
        time.sleep(interval)

if __name__ == "__main__":
    monitor_gpu_usage()

Muster 6: Monitoring und Observability

Das Monitoring der Docker Compose AI-Fullstack-Bereitstellung muss GPU-Auslastung, Inferenzlatenz, Vektordatenbankleistung und andere AI-spezifische Metriken abdecken.

Prometheus + Grafana

  prometheus:
    image: prom/prometheus:v3.2.0
    container_name: prometheus
    volumes:
      - ./monitoring/prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prometheus_data:/prometheus
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
      - "--storage.tsdb.retention.time=30d"
      - "--storage.tsdb.retention.size=10GB"
    ports:
      - "9090:9090"
    restart: unless-stopped

  grafana:
    image: grafana/grafana:11.5.0
    container_name: grafana
    volumes:
      - grafana_data:/var/lib/grafana
      - ./monitoring/grafana/dashboards:/etc/grafana/provisioning/dashboards:ro
      - ./monitoring/grafana/datasources:/etc/grafana/provisioning/datasources:ro
    environment:
      GF_SECURITY_ADMIN_USER: "${GRAFANA_USER}"
      GF_SECURITY_ADMIN_PASSWORD: "${GRAFANA_PASSWORD}"
      GF_USERS_ALLOW_SIGN_UP: "false"
    ports:
      - "3001:3000"
    depends_on:
      - prometheus
    restart: unless-stopped

  dcgm-exporter:
    image: nvidia/dcgm-exporter:latest
    container_name: dcgm-exporter
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    ports:
      - "9400:9400"
    restart: unless-stopped

Prometheus-Konfiguration

# monitoring/prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "ollama"
    static_configs:
      - targets: ["ollama:11434"]
    metrics_path: "/metrics"
    scrape_interval: 30s

  - job_name: "qdrant"
    static_configs:
      - targets: ["qdrant:6333"]
    metrics_path: "/metrics"
    scrape_interval: 30s

  - job_name: "dcgm"
    static_configs:
      - targets: ["dcgm-exporter:9400"]
    scrape_interval: 10s

  - job_name: "node-exporter"
    static_configs:
      - targets: ["node-exporter:9100"]

  - job_name: "traefik"
    static_configs:
      - targets: ["traefik:8080"]

Wichtige Alarmregeln

# monitoring/alerts.yml
groups:
  - name: ai-stack
    rules:
      - alert: OllamaHighLatency
        expr: histogram_quantile(0.95, rate(ollama_request_duration_seconds_bucket[5m])) > 30
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Ollama-Inferenzlatenz zu hoch"

      - alert: GPUMemoryHigh
        expr: DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_TOTAL > 0.9
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "GPU-Speichernutzung übersteigt 90%"

      - alert: QdrantHighLatency
        expr: histogram_quantile(0.95, rate(qdrant_request_duration_seconds_bucket[5m])) > 5
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Qdrant-Abfragelatenz zu hoch"

      - alert: OllamaContainerDown
        expr: up{job="ollama"} == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Ollama-Dienst nicht verfügbar"

Muster 7: Produktionshärtung und Sicherheit

Sicherheit ist die Grundvoraussetzung für die produktive Docker Compose AI-Fullstack-Bereitstellung.

Secrets-Verwaltung

services:
  ollama:
    image: ollama/ollama:latest
    secrets:
      - hf_token
    environment:
      HF_TOKEN_FILE: /run/secrets/hf_token

  qdrant:
    image: qdrant/qdrant:latest
    secrets:
      - qdrant_api_key
    environment:
      QDRANT__SERVICE__API_KEY_FILE: /run/secrets/qdrant_api_key

secrets:
  hf_token:
    file: ./secrets/hf_token.txt
  qdrant_api_key:
    file: ./secrets/qdrant_api_key.txt
  db_password:
    file: ./secrets/db_password.txt

Netzwerkisolation

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge
    internal: true
  monitoring:
    driver: bridge
    internal: true

services:
  traefik:
    networks:
      - frontend
      - backend

  open-webui:
    networks:
      - frontend
      - backend

  ollama:
    networks:
      - backend

  qdrant:
    networks:
      - backend

  tei:
    networks:
      - backend

  prometheus:
    networks:
      - monitoring
      - backend

  grafana:
    networks:
      - frontend
      - monitoring

Backup-Strategie

#!/bin/bash
# scripts/backup-vectors.sh

BACKUP_DIR="/backups/$(date +%Y%m%d_%H%M%S)"
mkdir -p "$BACKUP_DIR"

echo "Backing up Qdrant..."
curl -s -X POST "http://localhost:6333/snapshots" | jq .

echo "Backing up Ollama models list..."
curl -s "http://localhost:11434/api/tags" | jq . > "$BACKUP_DIR/ollama_models.json"

echo "Backing up environment config..."
cp .env "$BACKUP_DIR/.env.backup"
cp docker-compose.yml "$BACKUP_DIR/docker-compose.yml.backup"

echo "Backup completed: $BACKUP_DIR"

Vollständige Produktionskonfiguration

# docker-compose.prod.yml
services:
  ollama:
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
        limits:
          memory: 16G
          cpus: "8.0"
      restart_policy:
        condition: on-failure
        delay: 10s
        max_attempts: 5
        window: 120s
    logging:
      driver: json-file
      options:
        max-size: "100m"
        max-file: "5"
    read_only: true
    tmpfs:
      - /tmp

  qdrant:
    deploy:
      resources:
        limits:
          memory: 4G
          cpus: "2.0"
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3
    logging:
      driver: json-file
      options:
        max-size: "50m"
        max-file: "3"

5 häufige Fallstricke und Lösungen

Fallstrick 1: Ollama Modell-Pull-Timeout

Symptom: Nach docker compose up bleibt Ollama beim Herunterladen von Modellen hängen. Große Modelle (z.B. Llama 4 70B) können über eine Stunde zum Herunterladen benötigen.

Lösung: Verwenden Sie den model-init-Dienst für asynchronen Pull. Der Ollama-Dienst selbst muss nicht auf die Modelle warten.

  model-init:
    image: curlimages/curl:latest
    depends_on:
      ollama:
        condition: service_healthy
    volumes:
      - ./scripts/init-models.sh:/init-models.sh:ro
    entrypoint: ["/bin/sh", "/init-models.sh"]
    restart: "no"
    deploy:
      resources:
        limits:
          memory: 256M

Fallstrick 2: Qdrant-Container OOM

Symptom: Wenn Vektordaten wachsen, wird der Qdrant-Container OOM Killed.

Lösung: Setzen Sie Speicherlimits und aktivieren Sie Memory-Mapping.

  qdrant:
    image: qdrant/qdrant:latest
    deploy:
      resources:
        limits:
          memory: 8G
    environment:
      QDRANT__STORAGE__PERFORMANCE__MAX_SEARCH_THREADS: "4"
      QDRANT__STORAGE__WAL__WAL_CAPACITY_MB: "64"

Fallstrick 3: GPU-Treiber-Versionsinkompatibilität

Symptom: docker compose up zeigt den Fehler CUDA driver version is insufficient.

Lösung: Stellen Sie sicher, dass der Host-NVIDIA-Treiber ≥ 535 ist, installieren Sie nvidia-container-toolkit.

# Treiberversion prüfen
nvidia-smi | head -3

# nvidia-container-toolkit installieren (Ubuntu)
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \
  sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Fallstrick 4: Embedding-Dienst und LLM konkurrieren um GPU

Symptom: GPU-Speicher unzureichend, wenn TEI und Ollama gleichzeitig laufen; Modellladen schlägt fehl.

Lösung: Verwenden Sie device_ids für präzise GPU-Zuweisung oder betreiben Sie den Embedding-Dienst auf der CPU.

  ollama:
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              device_ids: ["0"]
              capabilities: [gpu]

  tei:
    # Embedding-Dienst im CPU-Modus betreiben
    environment:
      MODEL_ID: "BAAI/bge-m3"
      # Keine GPU-Zuweisung, verwendet CPU

Fallstrick 5: DNS-Auflösungsfehler zwischen Containern

Symptom: OpenWebUI meldet ollama: Name or service not known.

Lösung: Stellen Sie sicher, dass alle Dienste im selben Netzwerk sind, verwenden Sie container_name oder den Dienstnamen als Hostname.

networks:
  ai-network:
    driver: bridge

services:
  ollama:
    container_name: ollama
    networks:
      - ai-network

  open-webui:
    container_name: open-webui
    networks:
      - ai-network
    environment:
      OLLAMA_BASE_URL: "http://ollama:11434"

10 häufige Fehlerbehebungen

1. could not select device driver — NVIDIA-Runtime nicht installiert

# nvidia-container-toolkit installieren und Docker neu starten
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker
docker info | grep -i runtime
# Sollte nvidia-Runtime anzeigen

2. OOM Killed — GPU-Speicher unzureichend

# GPU-Speicher prüfen
nvidia-smi
# Kleinere oder quantisierte Modelle verwenden
docker exec ollama ollama run qwen3:4b

3. Connection refused zu Ollama — Dienst nicht bereit

# Ollama-Gesundheitsstatus prüfen
docker compose ps
docker compose logs ollama
# Auf bestandenen Healthcheck warten, bevor verbunden wird

4. permission denied auf Docker-Socket

sudo usermod -aG docker $USER
newgrp docker

5. Qdrant collection not found — Collection nicht erstellt

curl -X PUT "http://localhost:6333/collections/documents" \
  -H "Content-Type: application/json" \
  -d '{"vectors": {"size": 1024, "distance": "Cosine"}}'

6. model not found — Ollama-Modell nicht heruntergeladen

docker exec ollama ollama pull qwen3:8b

7. CUDA out of memory — GPU-Speicherüberlauf während Inferenz

# Parallele Anfragen reduzieren
# In docker-compose.yml festlegen
environment:
  OLLAMA_NUM_PARALLEL: "1"
  OLLAMA_MAX_LOADED_MODELS: "1"

8. TLS handshake error — Traefik-Zertifikatsproblem

# Zertifikatsdateiberechtigungen prüfen
chmod 600 traefik/acme.json
# Traefik-Logs prüfen
docker compose logs traefik

9. too many open files — Dateideskriptor-Limit

# Limit temporär erhöhen
ulimit -n 65536
# Permanente Einstellung (/etc/security/limits.conf)
# * soft nofile 65536
# * hard nofile 65536

10. vector dimension mismatch — Embedding-Dimensionsinkonsistenz

# Sicherstellen, dass die Qdrant-Collection-Dimension mit der Embedding-Modellausgabe übereinstimmt
# bge-m3: 1024 Dimensionen
# nomic-embed-text: 768 Dimensionen
curl -X PUT "http://localhost:6333/collections/documents" \
  -d '{"vectors": {"size": 1024, "distance": "Cosine"}}'

Erweiterte Optimierungstipps

Mehrstufiges Modell-Aufwärmen

  model-warmer:
    image: curlimages/curl:latest
    container_name: model-warmer
    depends_on:
      ollama:
        condition: service_healthy
    entrypoint: >
      /bin/sh -c "
        echo 'Warming up models...' &&
        curl -s http://ollama:11434/api/generate -d '{\"model\":\"qwen3:8b\",\"prompt\":\"hi\",\"stream\":false}' > /dev/null &&
        curl -s http://ollama:11434/api/generate -d '{\"model\":\"nomic-embed-text\",\"prompt\":\"test\",\"stream\":false}' > /dev/null &&
        echo 'Models warmed up!'
      "
    restart: "no"

Intelligentes Modell-Entladen

  ollama:
    environment:
      OLLAMA_KEEP_ALIVE: "5m"
      OLLAMA_NUM_PARALLEL: "4"
      OLLAMA_MAX_LOADED_MODELS: "2"

OLLAMA_KEEP_ALIVE: "5m" entlädt automatisch Modelle, die 5 Minuten inaktiv sind, und gibt GPU-Speicher frei.

Verkettete Healthcheck-Abhängigkeiten

  tei:
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:80/health"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 120s

  qdrant:
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:6333/healthz"]
      interval: 10s
      timeout: 5s
      retries: 3

  rag-app:
    depends_on:
      ollama:
        condition: service_healthy
      tei:
        condition: service_healthy
      qdrant:
        condition: service_healthy

Docker Compose Watch für die Entwicklung

# docker-compose.yml
services:
  rag-app:
    build: .
    develop:
      watch:
        - action: rebuild
          path: ./app
          target: /app
        - action: sync
          path: ./app/static
          target: /app/static

Vergleich: Docker Compose vs K8s vs Docker Swarm

Dimension Docker Compose Kubernetes Docker Swarm
AI-Stack-Bereitstellungskomplexität ⭐ Sehr niedrig ⭐⭐⭐⭐⭐ Sehr hoch ⭐⭐ Niedrig
GPU-Scheduling ✅ Nativ ✅ Device Plugin ⚠️ Erfordert Konfiguration
Auto-Skalierung ❌ ✅ HPA ⚠️ Manuell
Service-Discovery ✅ DNS ✅ CoreDNS ✅ DNS
Rolling Updates ⚠️ Erfordert Skripte ✅ Nativ ✅ Nativ
Konfigurationsverwaltung ✅ .env ✅ ConfigMap ⚠️ Config
Secret-Verwaltung ✅ Docker Secret ✅ K8s Secret ⚠️ Basis
Monitoring-Ökosystem ✅ Prometheus ✅ Vollständig ⚠️ Begrenzt
Multi-Node-Orchestrierung ❌ Einzelner Knoten ✅ Kernkompetenz ✅ Nativ
Lernkurve Niedrig Hoch Niedrig
Community-Aktivität ✅ Aktiv ✅ Sehr aktiv ❌ Abnehmend
Geeignete AI-Projektskala 1-5 GPUs 10+ GPUs 2-5 GPUs

Empfehlung: Die Docker Compose AI-Fullstack-Bereitstellung ist ideal für Einzelmaschinen-Szenarien mit 1-5 GPUs — die beste Wahl für AI-Entwicklung und Kleinserienproduktion. Für 5+ GPUs oder Multi-Node-Anforderungen sollten Sie Kubernetes + KServe/vLLM in Betracht ziehen. Docker Swarm wird für AI-Bereitstellung nicht empfohlen.

Empfohlene Online-Tools

Zusammenfassung

Die Docker Compose AI-Fullstack-Bereitstellung transformiert AI-Entwicklungsumgebungen von „drei Tage Einrichtung" zu „ein Befehl zum Starten". Ollama + OpenWebUI übernimmt das LLM-Serving, Qdrant den Vektorspeicher, TEI die Embeddings, Traefik das Gateway, Prometheus + Grafana das Monitoring und GPU-Passthrough lässt die Inferenz fliegen. 7 Muster decken die gesamte Kette von der Entwicklung bis zur Produktion ab, 5 häufige Fallstricke und 10 Fehlerbehebungsmaßnahmen helfen Ihnen, Umwege zu vermeiden. Für AI-Projekte mit 1-5 GPUs ist Docker Compose die praktischste AI-Containerorchestrierungslösung im Jahr 2026.

Verwandte Beiträge

Externe Referenzen

Probiere diese browser-lokalen Tools aus — keine Registrierung erforderlich →

#Docker#Docker Compose#AI部署#LLM#向量数据库#Ollama#2026#DevOps