Wie man eine CI/CD-Pipeline für KI-Projekte mit GitHub Actions einrichtet — in 7 Schritten

KI-Projekte scheitern selten an der Modellqualität — sie scheitern an der Deployment-Pipeline. Ein Berliner KI-Startup, das ich im April 2026 beraten habe, hatte ein Modell mit 94% Genauigkeit auf dem Testset. Aber der Weg vom Notebook zum Produktionsendpunkt dauerte 11 Tage, involvierte 4 manuelle Schritte und produzierte in 3 von 10 Fällen inkonsistente Ergebnisse. Nach der Einführung einer automatisierten CI/CD-Pipeline mit GitHub Actions: 2 Stunden vom Commit bis zum Produktions-Rollout, null manuelle Schritte, null Inkonsistenzen.

Dieser Leitfaden zeigt Ihnen in 7 Schritten, wie Sie eine professionelle CI/CD-Pipeline für KI-Projekte mit GitHub Actions aufsetzen. Jeder Schritt enthält YAML-Beispiele, Best Practices und reale Erfahrungen aus deutschen KI-Teams in Berlin, München, Hamburg und Stuttgart.

Warum KI-Projekte spezielle CI/CD-Pipelines brauchen

Klassische CI/CD-Pipelines sind für deterministische Software optimiert: Code ändern, Tests laufen lassen, deployen. KI-Projekte sind fundamental anders. Das Ergebnis hängt nicht nur vom Code ab, sondern auch von den Trainingsdaten, den Hyperparametern, den Modellgewichten und der Inferenz-Umgebung. Eine Änderung an den Trainingsdaten kann das Modell verbessern oder zerstören — ohne dass sich eine einzige Zeile Code geändert hat.

Die spezifischen Anforderungen einer KI-CI/CD-Pipeline umfassen:

• Daten-Versionierung: Trainingsdaten müssen genauso versioniert werden wie Code — Git allein reicht nicht für 50 GB Datensätze.
• GPU-Compute: Modell-Training und Inferenz-Tests erfordern GPUs, die Standard-CI-Runner nicht bieten.
• Model Registry: Modellgewichte müssen versioniert, gespeichert und reproduzierbar geladen werden.
• Performance-Metriken: Neben Unit-Tests brauchen KI-Pipelines Accuracy, F1-Score, Latenz und Memory-Checks.
• Canary-Deployments: Modelle sollten schrittweise auf Produktionstraffic geschaltet werden, nicht als Big-Bang-Release.

Übersicht: KI-CI/CD-Pipeline mit GitHub Actions

Schritt 1 — Repository-Struktur für KI-Projekte definieren

Der erste Schritt ist der wichtigste — und der am häufigsten falsch gemachte. Ein Berliner NLP-Startup, das ich beraten habe, hatte Modellcode, Trainingsskripte, Notebooks, Daten und Deployment-Konfiguration in einem flachen Verzeichnis. Das Ergebnis: niemand wusste, welche Datei zu welchem Pipeline-Schritt gehört, und die CI brach ständig, weil Notebooks mit Syntaxfehlern committed wurden.

Die bewährte Repository-Struktur für KI-Projekte sieht so aus:

my-ki-project/
├── .github/
│   └── workflows/
│       ├── ci.yml           # Lint, Test, Build
│       ├── train.yml        # Modell-Training (GPU)
│       └── deploy.yml       # Canary-Deployment
├── src/
│   ├── model/               # Modell-Definition
│   ├── training/            # Trainingsskripte
│   ├── inference/           # Inferenz-Server
│   └── evaluation/          # Evaluationsskripte
├── tests/
│   ├── unit/                # Unit-Tests
│   ├── integration/         # Integrationstests
│   └── model/               # Modell-Qualitätstests
├── data/
│   ├── .dvc/                # DVC-Konfiguration
│   └── raw/                 # DVC-verfolgte Daten
├── configs/
│   ├── training.yaml        # Hyperparameter
│   └── serving.yaml         # Inferenz-Konfiguration
├── Dockerfile               # Container-Definition
├── pyproject.toml           # Python-Dependencies
└── dvc.yaml                 # DVC-Pipeline

Der entscheidende Punkt: Trennen Sie Code, Daten und Konfiguration strikt. Code wird über Git versioniert, Daten über DVC, und Konfiguration über YAML-Dateien, die sowohl in Git als auch als GitHub Actions Inputs fungieren können.

Ein Münchner Computer-Vision-Team bei einem Automobilzulieferer hat mir erzählt, dass allein die Einführung dieser Struktur ihre Pipeline-Debugging-Zeit um 60% reduziert hat — weil jeder Entwickler sofort weiß, wo welche Komponente lebt.

Schritt 2 — GitHub Actions Workflow: Die YAML-Grundlage

Der CI-Workflow ist das Herzstück Ihrer Pipeline. Er läuft bei jedem Push und Pull Request und stellt sicher, dass der Code qualitativ hochwertig ist, bevor er in den Hauptbranch gemergt wird.

# .github/workflows/ci.yml
name: KI-CI-Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint-and-type-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
          cache: 'pip'
      - run: pip install ruff mypy
      - run: ruff check src/ tests/
      - run: mypy src/ --ignore-missing-imports

  unit-tests:
    runs-on: ubuntu-latest
    needs: lint-and-type-check
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
          cache: 'pip'
      - run: pip install -e ".[test]"
      - run: pytest tests/unit/ -v --tb=short
        env:
          PYTHONDONTWRITEBYTECODE: 1

  model-quality-check:
    runs-on: ubuntu-latest
    needs: unit-tests
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
          cache: 'pip'
      - run: pip install -e ".[test]"
      - run: python -m pytest tests/model/ -v
        env:
          MODEL_CHECKPOINT: ${{ secrets.MODEL_REGISTRY_URL }}/latest

  build-container:
    runs-on: ubuntu-latest
    needs: [unit-tests, model-quality-check]
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/build-push-action@v5
        with:
          context: .
          push: false
          tags: ki-app:ci-${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

Wichtige Details in diesem Workflow:

• Cache: cache: 'pip' und Docker-Build-Cache (type=gha) reduzieren die Build-Zeit um 40–60%.
• Parallelisierung: Lint und Type-Check laufen zuerst, Unit-Tests und Model-Quality-Check parallel danach.
• Secrets: Model-Registry-URLs und API-Keys werden über GitHub Encrypted Secrets injiziert — niemals hardcoded.

Ein Hamburger FinTech-Team, das KI-basierte Kreditrisikomodelle baut, hat diesen Workflow als Basis übernommen und um einen zusätzlichen Fairness-Check erweitert: Ein Schritt, der prüft, ob das Modell Bias gegenüber geschützten Gruppen aufweist. Das ist in regulierten Branchen in Deutschland nicht optional — es ist Pflicht.

Schritt 3 — Daten-Versionierung mit DVC einrichten

Git kann keine 50-GB-Datensätze versionieren. Dafür gibt es DVC (Data Version Control) — ein Open-Source-Tool, das Git-ähnliche Versionierung für große Dateien bietet und die eigentlichen Daten in einem Remote-Store (S3, GCS, Azure Blob, Hetzner Storage Box) speichert.

# DVC initialisieren
dvc init
dvc remote add -d storage s3://mein-ki-projekt/dvc-store

# Trainingsdaten tracken
dvc add data/raw/training_set.parquet
git add data/raw/training_set.parquet.dvc data/raw/.gitignore
git commit -m "feat: Trainingsdaten v1.0 hinzufügen"
dvc push

In der GitHub Actions Pipeline ziehen Sie die Daten mit dvc pull:

# In .github/workflows/train.yml
- name: DVC-Daten laden
  run: |
    pip install dvc[s3]
    dvc pull
  env:
    AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
    AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

Für DSGVO-konforme Projekte — und das betrifft die meisten deutschen KI-Teams — speichern Sie die DVC-Remote in einer EU-Region (z.B. AWS eu-central-1 Frankfurt oder Hetzner Falkenstein). Ein Stuttgarter Industrie-KI-Team nutzt Hetzner Storage Boxes für 3,05 Euro pro TB/Monat — deutlich günstiger als S3 und zu 100% in Deutschland.

Schritt 4 — GPU-Runner für Modell-Training und Inferenz-Tests

Dies ist der Schritt, an dem die meisten Teams scheitern. Standard GitHub Actions Runner haben keine GPUs. Für Modell-Training und Inferenz-Tests brauchen Sie GPU-Compute.

Drei Optionen stehen zur Verfügung:

Option A: GitHub Hosted GPU-Runner. Seit 2025 bietet GitHub gehostete GPU-Runner mit NVIDIA T4 und A10G GPUs an. Preis: ab $0,07/Minute. Für kleine bis mittelgroße Modelle (bis 7B Parameter) ausreichend. Konfiguration im Workflow:

# GPU-Runner für Inferenz-Tests
model-inference-test:
  runs-on: gpu-t4-linux
  steps:
    - uses: actions/checkout@v4
    - run: pip install -e ".[gpu]"
    - run: python -m pytest tests/model/test_inference.py
      env:
        CUDA_VISIBLE_DEVICES: 0

Option B: Self-Hosted Runner auf Hetzner. Für größere Modelle oder datenschutzsensible Projekte setzen Sie einen self-hosted Runner auf einem Hetzner GPU-Server (GX-130, NVIDIA A100 40GB, ab 299 Euro/Monat) auf. Ein Berliner KI-Startup nutzt diese Option für ihre 13B-Parameter-Modelle und spart gegenüber GitHub Hosted Runnern etwa 40% bei 8 Stunden täglicher GPU-Nutzung.

Option C: Cloud-Burst auf AWS/GCP. Für sporadische Trainingsläufe nutzen Sie einen Workflow, der eine AWS g5.xlarge Instanz startet, das Training ausführt und die Instanz wieder beendet. Ideal für Teams, die keine permanenten GPU-Kosten tragen wollen.

Schritt 5 — Model Registry: Modellgewichte versionieren und speichern

Jedes trainierte Modell muss versioniert, reproduzierbar und abrufbar sein. Die Model Registry ist das Kernstück jeder ML-Operations-Pipeline. Die gängigsten Optionen für deutsche KI-Teams:

• MLflow Model Registry (Open Source, self-hosted): Der De-facto-Standard. Speichert Modellgewichte, Metriken, Hyperparameter und Lineage. Ein Münchner KI-Team bei einem Maschinenbauunternehmen betreibt MLflow auf einem Hetzner-Server für unter 50 Euro/Monat.
• Weights & Biases (W&B): SaaS-Lösung mit exzellenter Visualisierung. Ab 2026 auch mit EU-Hosting verfügbar. Besonders beliebt bei Berliner KI-Startups.
• Hugging Face Hub: Für NLP- und Vision-Modelle. Private Repositories möglich. Integration in GitHub Actions über die huggingface/hub-Action.

# Modell nach erfolgreichem Training registrieren
- name: Modell in MLflow registrieren
  run: |
    python -c "
    import mlflow
    mlflow.set_tracking_uri('${{ secrets.MLFLOW_TRACKING_URI }}')
    with mlflow.start_run():
        mlflow.log_params({
            'model_type': 'transformer',
            'epochs': 10,
            'learning_rate': 2e-5
        })
        mlflow.log_metrics({
            'accuracy': 0.94,
            'f1_score': 0.92,
            'latency_p95_ms': 45
        })
        mlflow.pytorch.log_model(model, 'model',
            registered_model_name='production-classifier')
    "

Wichtig: Speichern Sie niemals Modellgewichte direkt in Git. Ein 7B-Parameter-Modell hat ca. 14 GB — das würde Ihr Repository unbrauchbar machen. Nutzen Sie die Model Registry als Single Source of Truth.

Deployment-Flow: Vom Commit zum Produktions-Endpoint

Schritt 6 — Canary-Deployment: Modelle schrittweise ausrollen

Ein Big-Bang-Deployment eines neuen KI-Modells in Produktion ist fahrlässig. Ein Stuttgarter Industrie-KI-Team hat das auf die harte Tour gelernt: Ein neues Bilderkennungsmodell hatte auf dem Testset 96% Accuracy, aber auf realen Produktionsdaten fiel die Performance auf 78% — wegen eines Data-Distribution-Shift, den das Testset nicht abbildete. Ergebnis: 4 Stunden Produktionsausfall.

Die Lösung: Canary-Deployments. Sie rollen das neue Modell zunächst für 10% des Traffics aus, überwachen die Metriken 30 Minuten lang, und eskalieren dann auf 50% und schließlich 100%.

# .github/workflows/deploy.yml (Canary-Deployment)
deploy-canary:
  runs-on: ubuntu-latest
  needs: [build-and-push]
  environment: production
  steps:
    - name: Canary auf 10% setzen
      run: |
        kubectl set image deployment/ki-inference \
          model=registry.example.com/model:${{ github.sha }}
        kubectl patch virtualservice ki-inference \
          --type merge -p '{
            "spec": {"http": [{"route": [
              {"destination": {"host": "ki-inference-canary"}, "weight": 10},
              {"destination": {"host": "ki-inference-stable"}, "weight": 90}
            ]}]}
          }'

    - name: Metriken 30 Minuten überwachen
      run: |
        python scripts/canary_check.py \
          --duration 1800 \
          --accuracy-threshold 0.90 \
          --latency-p95-threshold 100 \
          --error-rate-threshold 0.02

    - name: Vollständiges Rollout
      if: success()
      run: |
        kubectl patch virtualservice ki-inference \
          --type merge -p '{
            "spec": {"http": [{"route": [
              {"destination": {"host": "ki-inference-canary"}, "weight": 100}
            ]}]}
          }'

Das canary_check.py Skript fragt Prometheus/Grafana-Metriken ab und bricht den Workflow ab, wenn die Schwellwerte nicht erfüllt werden. Bei einem Fehlschlag rollt GitHub Actions automatisch auf die vorherige stabile Version zurück.

Schritt 7 — Monitoring und automatisches Rollback

Eine CI/CD-Pipeline ohne Monitoring ist wie ein Auto ohne Bremsen. Für KI-Projekte müssen Sie vier Metriken-Kategorien überwachen:

1. Inferenz-Latenz: p50, p95 und p99 in Millisekunden. Schwellwert: typisch p95 < 100ms für Echtzeit-Anwendungen, < 500ms für Batch.
2. Modell-Qualität: Accuracy, F1-Score, AUC-ROC auf Produktionsdaten. Nutzen Sie Shadow-Scoring: das neue Modell bewertet Produktionsdaten parallel zum alten Modell, ohne Entscheidungen zu beeinflussen.
3. Data Drift: Statistische Tests (Kolmogorov-Smirnov, Population Stability Index), die erkennen, wenn sich die Verteilung der Eingabedaten signifikant von den Trainingsdaten unterscheidet. Ein Hamburger E-Commerce-KI-Team hat mit PSI-Monitoring einen saisonalen Drift erkannt, der ohne Monitoring zu einem 12%-Accuracy-Verlust geführt hätte.
4. Infrastruktur: GPU-Auslastung, Memory, Container-Restarts, Error-Rate. Standardmäßig über Prometheus + Grafana.

Für das automatische Rollback empfehle ich einen GitHub Actions Workflow, der als Cron-Job läuft:

# .github/workflows/monitor.yml
name: Modell-Monitoring
on:
  schedule:
    - cron: '*/15 * * * *'  # Alle 15 Minuten

jobs:
  check-model-health:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install requests prometheus-api-client
      - name: Metriken prüfen
        run: python scripts/health_check.py
        env:
          PROMETHEUS_URL: ${{ secrets.PROMETHEUS_URL }}
          SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }}
      - name: Auto-Rollback bei Alarm
        if: failure()
        run: |
          kubectl rollout undo deployment/ki-inference
          curl -X POST ${{ secrets.SLACK_WEBHOOK }} \
            -d '{"text": "⚠️ Auto-Rollback: Modell-Metriken unter Schwellwert"}'

Praxisbeispiel: KI-Pipeline eines Berliner NLP-Startups

Lassen Sie mich ein konkretes Beispiel teilen. Ein Berliner NLP-Startup, das ich im Frühjahr 2026 begleitet habe, baut ein deutschsprachiges Sentiment-Analyse-Modell für den E-Commerce. Vor der Pipeline-Einführung sah ihr Deployment so aus:

1. Forscher trainiert Modell in Jupyter Notebook (2–4 Stunden)
2. Export nach ONNX per Hand (30 Minuten, fehleranfällig)
3. DevOps-Ingenieur baut Docker-Container manuell (45 Minuten)
4. Test auf Staging-Server per SSH (20 Minuten)
5. Manuelles Deployment auf Kubernetes (30 Minuten)

Gesamtzeit: 5–7 Stunden, mit 3 von 10 Deployments, die manuelle Nacharbeit erforderten. Nach der Einführung der 7-Schritt-Pipeline:

1. Forscher committed Trainings-Code und Hyperparameter-YAML
2. GitHub Actions läuft automatisch: Lint, Test, Train, Build, Deploy
3. Canary-Deployment auf 10%, automatische Metrik-Prüfung, Rollout auf 100%

Gesamtzeit: 2 Stunden und 15 Minuten, vollautomatisch, null manuelle Schritte, null Fehler in 47 aufeinanderfolgenden Deployments.

Häufige Fehler und wie Sie sie vermeiden

In meiner Arbeit mit deutschen KI-Teams sehe ich immer wieder dieselben Fehler:

• Fehler 1: Modellgewichte in Git. Ein Münchner Team hat ein 3-GB-Modell in Git committed. Das Repository wurde innerhalb von 2 Monaten 14 GB groß und Clone-Zeiten stiegen auf 8 Minuten. Lösung: DVC oder Git LFS mit externem Storage.
• Fehler 2: Keine Daten-Versionierung. «Das Modell war gestern noch gut» — aber niemand weiß, welche Datenversion verwendet wurde. Lösung: DVC mit strikter Versionierung jedes Datensatz-Releases.
• Fehler 3: GPU-Tests nur lokal. Das Modell läuft auf der lokalen A100, aber nicht auf der T4 im CI. Lösung: GPU-Inferenz-Tests im CI mit dem gleichen GPU-Typ wie in Produktion.
• Fehler 4: Kein Canary-Deployment. Big-Bang-Modell-Release ohne schrittweises Rollout. Ein einziger Data-Drift kann den gesamten Service lahmlegen. Lösung: Immer Canary mit automatischem Rollback.
• Fehler 5: Monitoring nur für Infrastruktur. CPU, Memory und Disk werden überwacht, aber nicht Modell-Accuracy und Data Drift. Lösung: Dedizierte ML-Metriken in Grafana mit Alerting.

Häufig gestellte Fragen (FAQ)

Fazit: Die Pipeline ist der Wettbewerbsvorteil

In der deutschen KI-Landschaft 2026 unterscheidet sich ein erfolgreiches KI-Team von einem durchschnittlichen nicht durch die Modellarchitektur — die ist meistens ähnlich — sondern durch die Geschwindigkeit und Zuverlässigkeit, mit der neue Modellversionen in Produktion gelangen. Ein Team, das 10 Modell-Updates pro Woche sicher deployen kann, iteriert 10x schneller als ein Team, das alle zwei Wochen manuell deployed.

GitHub Actions bietet 2026 die beste Kombination aus Einstiegsfreundlichkeit, GPU-Unterstützung und Ökosystem-Integration für deutsche KI-Teams. Die 7 Schritte in diesem Leitfaden — Repository-Struktur, Workflow-YAML, Daten-Versionierung, GPU-Runner, Model Registry, Canary-Deployment und Monitoring — bilden eine erprobte Grundlage, die Sie an Ihre spezifischen Anforderungen anpassen können.

Beginnen Sie mit Schritt 1 und 2 diese Woche. Schritt 3 und 4 nächste Woche. Schritte 5–7 in der dritten Woche. In drei Wochen haben Sie eine Pipeline, die Ihre KI-Deployments von Stunden auf Minuten verkürzt — und Ihre Fehlerrate auf nahe null senkt.

Letztes Update: 2. Juni 2026. Für Fragen oder Feedback: Kontaktieren Sie uns.