KI-Qualitätskontrolle auf Kubernetes mit YOLO

TL;DR

• Automatisierte Qualitaetskontrolle mit Computer Vision ersetzt manuelle Sichtpruefung: Kameras erfassen Teile auf dem Foerderband, ein YOLO-Modell erkennt Defekte in unter 20ms pro Bild.
• Triton Inference Server auf Kubernetes entkoppelt Modell-Serving vom Applikationscode und bringt Batching, Multi-Model-Support und Metriken out-of-the-box mit.
• Edge-Deployment mit K3s und NVIDIA Jetson ermoeglicht Inference direkt an der Fertigungslinie mit Latenzen unter 50ms End-to-End.
• Modell-Versionierung und A/B-Testing ueber separate Kubernetes Deployments erlauben risikoarme Modell-Updates ohne Produktionsunterbrechung.
• Der ROI liegt typischerweise bei 12-18 Monaten: weniger Ausschuss, weniger Reklamationen und Entlastung des Pruefpersonals.

Ausgangslage: Warum KI-Qualitaetspruefung

In der Fertigung ist Qualitaetskontrolle ein Engpass. Manuelle Sichtpruefung ist langsam (2-5 Sekunden pro Teil), fehleranfaellig (Ermuedung nach 2-3 Stunden) und schwer skalierbar. Ein erfahrener Pruefer erkennt grobe Defekte zuverlaessig, aber feine Kratzer, Farb-Abweichungen oder Mikrorisse werden regelmaessig uebersehen.

Computer Vision mit Deep Learning loest diese Probleme. Ein trainiertes YOLO-Modell prueft jedes Teil in unter 20ms, arbeitet 24 Stunden am Tag ohne Ermuedung und erkennt Defekte mit einer Genauigkeit von ueber 95 Prozent, wenn das Modell sauber trainiert wurde.

Kubernetes ist die Plattform, die diesen Ansatz produktionstauglich macht. Es orchestriert die gesamte Pipeline: Kamera-Anbindung, Bildvorverarbeitung, GPU-Inference, Ergebnis-Speicherung und MES-Integration. Und es liefert Hochverfuegbarkeit, Autoscaling und reproduzierbare Deployments, die in der Fertigung Pflicht sind.

Pipeline-Architektur: Von der Kamera zur Entscheidung

Die Qualitaetskontroll-Pipeline besteht aus fuenf Stufen, die als separate Kubernetes-Workloads laufen:

Stufe 1: Bilderfassung. Industriekameras (GigE Vision oder USB3) erfassen Bilder, getriggert durch einen Sensor am Foerderband. Ein DaemonSet auf dem Edge-Node empfaengt die Bilder und publiziert sie als MQTT-Message oder schreibt sie in einen lokalen Buffer.

Stufe 2: Vorverarbeitung. Bildgroesse normalisieren (640x640 fuer YOLO), Belichtungskorrektur, optional Cropping auf den relevanten Bildbereich. Laeuft als CPU-Pod, da keine GPU benoetigt wird.

Stufe 3: Inference. Das YOLO-Modell analysiert das vorverarbeitete Bild und liefert Bounding Boxes mit Klasse (Kratzer, Riss, Fehlstelle, Verfaerbung) und Confidence Score. Laeuft auf GPU-Pods mit Triton Inference Server.

Stufe 4: Entscheidung. Ein Business-Logic-Service wertet die Inference-Ergebnisse aus: Ist der Defekt kritisch? Liegt der Confidence Score ueber dem Schwellwert? Wird das Teil aussortiert oder weiterverarbeitet?

Stufe 5: Dokumentation. Ergebnisse (Bild, Bounding Boxes, Entscheidung) werden in PostgreSQL und MinIO gespeichert fuer Audit-Trails, Retraining und Qualitaetsberichte.

Einen tieferen Einstieg in YOLO-Inference auf Kubernetes bietet der Artikel YOLO Detection auf Kubernetes.

Triton Inference Server: Deployment auf Kubernetes

NVIDIA Triton Inference Server ist der Standard fuer produktionsreifes Model-Serving. Er unterstuetzt ONNX, TensorRT, PyTorch und TensorFlow-Modelle, bringt dynamisches Batching mit und exponiert Prometheus-Metriken.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: triton-inference
  namespace: quality-control
  labels:
    app: triton-inference
    model: defect-detection-v3
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  selector:
    matchLabels:
      app: triton-inference
  template:
    metadata:
      labels:
        app: triton-inference
        model: defect-detection-v3
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "8002"
    spec:
      tolerations:
      - key: "gpu-only"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"
      nodeSelector:
        accelerator: nvidia-t4
      initContainers:
      - name: model-loader
        image: registry.internal/qc/model-loader:1.2.0
        command: ["python", "sync_models.py"]
        env:
        - name: S3_ENDPOINT
          value: "minio.storage.svc.cluster.local:9000"
        - name: MODEL_BUCKET
          value: "qc-models"
        - name: MODEL_REPOSITORY
          value: "/models"
        volumeMounts:
        - name: model-repo
          mountPath: /models
      containers:
      - name: triton
        image: nvcr.io/nvidia/tritonserver:24.01-py3
        args:
        - tritonserver
        ---model-repository=/models
        ---strict-model-config=false
        ---log-verbose=0
        ---exit-on-error=false
        ports:
        - containerPort: 8000
          name: http
        - containerPort: 8001
          name: grpc
        - containerPort: 8002
          name: metrics
        resources:
          requests:
            cpu: "2"
            memory: "4Gi"
            nvidia.com/gpu: 1
          limits:
            cpu: "4"
            memory: "8Gi"
            nvidia.com/gpu: 1
        readinessProbe:
          httpGet:
            path: /v2/health/ready
            port: 8000
          initialDelaySeconds: 30
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /v2/health/live
            port: 8000
          initialDelaySeconds: 60
          periodSeconds: 30
        volumeMounts:
        - name: model-repo
          mountPath: /models
          readOnly: true
      volumes:
      - name: model-repo
        emptyDir:
          sizeLimit: 5Gi
---
apiVersion: v1
kind: Service
metadata:
  name: triton-inference
  namespace: quality-control
spec:
  selector:
    app: triton-inference
  ports:
  - port: 8000
    targetPort: 8000
    name: http
  - port: 8001
    targetPort: 8001
    name: grpc
  - port: 8002
    targetPort: 8002
    name: metrics
  type: ClusterIP

Wichtige Design-Entscheidungen:

initContainer fuer Model Loading. Modelle werden aus MinIO geladen, nicht ins Container-Image eingebaut. Bei einem Modell-Update muss nur der initContainer ein neues Modell herunterladen, kein Image-Rebuild noetig.

gRPC-Port (8001). Fuer produktive Inference-Pipelines ist gRPC deutlich schneller als HTTP/REST, besonders bei grossen Bilddaten. Der Preprocessing-Service sendet Bilder ueber gRPC an Triton und erhaelt Ergebnisse mit minimaler Serialisierungs-Overhead.

strict-model-config=false. Triton leitet die Modellkonfiguration automatisch aus dem ONNX-Modell ab. Das spart eine manuelle config.pbtxt pro Modell.

Details zu Triton-Konfigurationen unter Triton Inference auf Kubernetes.

Preprocessing-Service: Bildvorbereitung fuer Inference

Zwischen Kamera und Inference liegt ein Preprocessing-Service, der Bilder normalisiert. Dieser Service laeuft als CPU-Deployment, weil Bildvorverarbeitung keine GPU braucht.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: image-preprocessor
  namespace: quality-control
  labels:
    app: image-preprocessor
spec:
  replicas: 3
  selector:
    matchLabels:
      app: image-preprocessor
  template:
    metadata:
      labels:
        app: image-preprocessor
    spec:
      containers:
      - name: preprocessor
        image: registry.internal/qc/preprocessor:2.0.0
        ports:
        - containerPort: 8080
          name: http
        env:
        - name: TRITON_GRPC_URL
          value: "triton-inference.quality-control.svc.cluster.local:8001"
        - name: INPUT_TOPIC
          value: "qc/images/raw"
        - name: OUTPUT_TOPIC
          value: "qc/results/detections"
        - name: MQTT_BROKER
          value: "tcp://emqx.messaging.svc.cluster.local:1883"
        - name: TARGET_SIZE
          value: "640"
        - name: CONFIDENCE_THRESHOLD
          value: "0.70"
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits:
            cpu: "2"
            memory: "1Gi"

Der Preprocessor empfaengt Rohbilder ueber MQTT, normalisiert sie auf 640x640 Pixel, sendet sie ueber gRPC an Triton, empfaengt die Detektionen und publiziert die Ergebnisse zurueck auf MQTT. Mit drei Replicas verarbeitet der Service problemlos 30-50 Bilder pro Sekunde.

Edge-Deployment fuer die Fertigungslinie

Nicht jede Fertigung hat ein Rechenzentrum mit GPU-Servern in der Naehe. Fuer Linien mit harten Latenzanforderungen (unter 50ms End-to-End) laeuft die Inference direkt am Hallenboden auf einem NVIDIA Jetson Orin mit K3s.

# K3s auf NVIDIA Jetson Orin installieren
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server \
  --disable traefik \
  --disable servicelb \
  --write-kubeconfig-mode 644" sh -

# NVIDIA Container Runtime fuer K3s konfigurieren
sudo nvidia-ctk runtime configure --runtime=containerd
sudo systemctl restart k3s

# GPU-Verfuegbarkeit pruefen
sudo k3s kubectl describe node | grep nvidia.com/gpu

# NVIDIA Device Plugin installieren
sudo k3s kubectl apply -f \
  https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.14.5/nvidia-device-plugin.yml

Auf dem Jetson laeuft ein kompaktes Setup: der Preprocessor und ein TensorRT-optimiertes Modell direkt in einem Pod (kein separater Triton-Server noetig fuer einen einzelnen Edge-Node). Das TensorRT-Modell ist auf die spezifische GPU-Architektur (Orin) optimiert und erreicht Inferenzzeiten von 8-12ms.

Mehr zu Edge-Deployments in der Fertigung unter Kubernetes Edge Manufacturing.

Modell-Versionierung und A/B-Testing

In der Qualitaetskontrolle aendert sich das Modell regelmaessig: neue Defekttypen, verbesserte Erkennung, angepasste Schwellwerte. Ein Modell-Update ohne Validierung in der Produktion ist riskant. A/B-Testing mit zwei parallelen Deployments minimiert das Risiko.

Der Ansatz: Ein zweites Triton-Deployment (Canary) mit dem Kandidaten-Modell laeuft parallel zum Production-Deployment. Der Preprocessor sendet jedes Bild an beide Instanzen. Die Produktionsentscheidung basiert ausschliesslich auf dem Production-Modell. Die Canary-Ergebnisse werden parallel gespeichert und nach einer Testphase (typisch 1-2 Wochen) ausgewertet.

Verglichen werden:

Wenn das Canary-Modell in allen Metriken gleich gut oder besser ist, wird es zum Production-Modell befoerdert. Wenn nicht, wird es verworfen und das Training angepasst.

MES-Integration: Ergebnisse in die Produktionssteuerung

Die Qualitaetskontrolle muss in die bestehende Produktionssteuerung integriert werden. Das MES muss wissen, welche Teile aussortiert wurden, warum, und ob die Ausschussrate einen Schwellwert ueberschreitet.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: qc-mes-bridge
  namespace: quality-control
  labels:
    app: qc-mes-bridge
spec:
  replicas: 2
  selector:
    matchLabels:
      app: qc-mes-bridge
  template:
    metadata:
      labels:
        app: qc-mes-bridge
    spec:
      containers:
      - name: mes-bridge
        image: registry.internal/qc/mes-bridge:1.4.0
        env:
        - name: MQTT_BROKER
          value: "tcp://emqx.messaging.svc.cluster.local:1883"
        - name: MQTT_SUBSCRIBE_TOPIC
          value: "qc/results/detections"
        - name: MES_API_URL
          value: "http://mes-gateway.production.svc.cluster.local:8080/api/v2"
        - name: REJECT_THRESHOLD
          value: "0.70"
        - name: ALERT_SCRAP_RATE
          value: "0.05"
        - name: DB_URL
          value: "postgresql://postgres.databases.svc.cluster.local:5432/quality"
        resources:
          requests:
            cpu: "200m"
            memory: "256Mi"
          limits:
            cpu: "1"
            memory: "512Mi"

Der MES-Bridge-Service empfaengt Detektionsergebnisse, trifft die Aussortierentscheidung und meldet das Ergebnis an das MES. Wenn die Ausschussrate ueber 5 Prozent steigt (ALERT_SCRAP_RATE), wird ein Alert ausgeloest, der auf ein Maschinenproblem hinweist.

ROI-Berechnung: Wann sich die Investition rechnet

Break-Even. Die Investition in Hardware und Setup (ca. 40.000-60.000 EUR) amortisiert sich typischerweise in 12-18 Monaten durch reduzierte Personalkosten, weniger Reklamationen und hoeheren Durchsatz.

Der groesste Hebel ist oft nicht die Personaleinsparung, sondern die Reduktion von Reklamationen und Rueckrufkosten. Ein uebersehener Defekt, der beim Endkunden auftaucht, kostet ein Vielfaches der Produktionskosten.

Monitoring und Alerting

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: qc-alerts
  namespace: quality-control
spec:
  groups:
  - name: quality-control
    interval: 15s
    rules:
    - alert: HighScrapRate
      expr: |
        rate(qc_parts_rejected_total[5m])
        / rate(qc_parts_inspected_total[5m]) > 0.05
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "Ausschussrate ueber 5 Prozent auf Linie {{ $labels.line }}"
    - alert: InferenceLatencyHigh
      expr: histogram_quantile(0.95, rate(qc_inference_duration_seconds_bucket[5m])) > 0.1
      for: 3m
      labels:
        severity: warning
      annotations:
        summary: "Inference-Latenz (p95) ueber 100ms"
    - alert: ModelConfidenceLow
      expr: avg_over_time(qc_model_confidence_avg[15m]) < 0.5
      for: 10m
      labels:
        severity: critical
      annotations:
        summary: "Durchschnittlicher Confidence Score unter 0.5 - moeglicherweise Model Drift"

Der Alert ModelConfidenceLow ist besonders wichtig. Wenn der durchschnittliche Confidence Score sinkt, bedeutet das, dass das Modell die aktuellen Bilder nicht mehr zuverlaessig klassifizieren kann. Ursachen koennen sein: veraenderte Beleuchtung, neues Material, verschmutzte Kameralinse oder ein tatsaechlich neuer Defekttyp. In jedem Fall ist menschliche Intervention noetig.

Haeufige Fehler bei KI-Qualitaetskontrolle

Zu wenig Trainingsdaten. Ein YOLO-Modell braucht mindestens 500-1000 annotierte Bilder pro Defektklasse fuer eine zuverlaessige Erkennung. Viele Projekte starten mit 50 Bildern und wundern sich ueber schlechte Ergebnisse. Investieren Sie Zeit in die Datensammlung und Annotation.

Keine Beleuchtungskonstanz. Computer-Vision-Modelle sind empfindlich gegenueber Beleuchtungsaenderungen. Eine Industriekamera mit kontrollierter LED-Beleuchtung (Ringlicht oder Dome-Licht) ist Pflicht. Tageslichteinfall fuehrt zu inkonsistenten Ergebnissen.

Kein Feedback-Loop. Wenn aussortierte Teile nicht von einem Menschen verifiziert werden, weiss niemand, ob das Modell korrekt entscheidet. Implementieren Sie eine Stichprobenpruefung: Jedes 100. aussortierte Teil wird manuell nachgeprueft. Diese Daten fliessen ins Retraining.

GPU-Ressourcen falsch dimensioniert. Eine NVIDIA T4 reicht fuer 50-100 Bilder pro Sekunde mit YOLOv8s. Wer nur 5 Bilder pro Sekunde braucht, verschwendet mit einer A100 Geld. Dimensionieren Sie die GPU nach dem tatsaechlichen Durchsatz.

Fazit und naechste Schritte

KI-gestuetzte Qualitaetskontrolle auf Kubernetes ist technisch ausgereift und wirtschaftlich sinnvoll fuer Fertigungsunternehmen mit hohem Pruefvolumen. Die Kombination aus YOLO fuer schnelle Defekterkennung, Triton fuer produktionsreifes Model-Serving und Kubernetes fuer Orchestrierung liefert eine skalierbare Loesung.

Der empfohlene Einstieg: Eine Kamera an einer Pruefstation, ein trainiertes YOLO-Modell fuer die 2-3 haeufigsten Defekttypen, Triton als Inference-Server auf einem GPU-Node. Wenn die Erkennungsrate stimmt, kommen weitere Kameras, Edge-Deployment und MES-Integration dazu.

Einen detaillierten Einstieg in GPU-Cluster fuer Inference-Workloads bietet der Artikel GPU-Workloads auf Kubernetes.

Fuer eine gemeinsame Evaluation Ihres Qualitaetskontroll-Use-Cases oder Unterstuetzung beim Aufbau der Inference-Pipeline erreichen Sie uns ueber die Kontaktseite.