VLM in der Fertigung: Vision Language Models vs Azure Document Intelligence

VLM in der Fertigung: Wann gewinnt ein Vision Language Model gegen Azure Document Intelligence? Decision Tree für sieben Manufacturing-Use-Cases, On-Device-VLMs wie Granite Vision und Shakti-VLM, plus Hybrid-Routing-Code.

30 Juni. 2026 | Dokumenten-KI / OCR

Inhaltsverzeichnis

TL;DR

VLM in der Fertigung lohnt sich überall dort, wo Bilder Reasoning verlangen — Defekterkennung am Band, Bauteil-Identifikation, technische Zeichnungen, Materialzeugnisse. Azure Document Intelligence bleibt die bessere Wahl für strukturierte Standard-Formulare wie Lieferscheine und Rechnungen. Die wirtschaftliche Architektur ist fast immer hybrid: Azure DI als Default, VLM bei Layout-Varianz oder echten Produktionsbildern.

Warum die Frage VLM oder Azure DI in der Fertigung gerade jetzt entscheidend ist

In den letzten zwölf Monaten haben wir bei Pexon mehr als ein Dutzend Fertigungsprojekte gesehen, in denen die gleiche Diskussion aufgepoppt ist: Setzen wir Azure Document Intelligence ein, oder gleich ein Vision Language Model? Die Versuchung, ein VLM auf alles zu werfen, ist groß — Granite Vision, Qwen 2.5-VL, Shakti-VLM, dazu GPT-4o Vision und Gemini 2.5 Pro Vision in der Cloud. Die Realität nach Go-Live ist nüchterner. Wer das falsche Modell auf den falschen Use Case wirft, zahlt zu viel pro Seite oder bekommt halluzinierte Tabellen zurück.

Der Markt drückt zusätzlich. Astute Analytica prognostiziert für den VLM-Markt einen Sprung von 3,84 Mrd USD 2025 auf 41,75 Mrd USD 2035 — CAGR 26,95%. Gleichzeitig schrumpfen die Modelle. Granite Vision läuft in 3B-Größe auf einem Edge-Server am Produktionsband, Llama 3.2 Vision gibt es als 1B- und 3B-Variante für Tablets. Der On-Device-Trend macht VLM Fertigung erst wirklich praktikabel, weil Bilddaten nicht mehr zwingend in die Cloud müssen.

Unsere Erfahrung: Die Entscheidung VLM vs Azure DI ist keine Glaubensfrage, sondern eine Routing-Entscheidung pro Dokumenten- oder Bildtyp. Wer das einmal sauber baut, hat eine Architektur, die zehn Jahre trägt.

Die sieben wichtigsten Use Cases für VLM in der Fertigung

Wir sehen in unseren Projekten immer wieder die gleichen Cluster für VLM Fertigung. Nicht alle davon sind klassische „Dokumenten-Cases“ — und genau hier trennt sich VLM von Azure Document Intelligence.

# Use Case VLM oder Azure DI Reife in 2026
1 Optische Qualitätskontrolle am Band (Kratzer, Coating, Label-Mismatch) VLM (on-device) Hoch
2 Wareneingang: Lieferschein-Abgleich gegen ERP/SAP Azure DI + VLM-Eskalation Hoch
3 Materialzeugnis-Prüfung (technische Zeichnungen, Zertifikate) VLM Mittel
4 Werkzeug-Identifikation (Wechsel, Wartung) VLM (on-device) Mittel
5 Visuelle Maschinen-Inspektion (Wartungsfotos klassifizieren) VLM Mittel
6 Versandetiketten + Stückliste-Abgleich Azure DI + VLM Hoch
7 Anlagen-Dokumentation (Schaltschrank-Fotos zu Tickets mappen) VLM Niedrig-Mittel

Die spannenden Cases sind 1, 3, 5 und 7. Hier schlägt ein VLM jeden klassischen OCR-Stack, weil das Modell Reasoning auf den Bildinhalt braucht. Defekterkennung am Band ist wirtschaftlich der härteste Case: Sysgenpro berichtet 97-99,5% Defekt-Detection, 20-25% Throughput-Gewinn und ROI zwischen 6 und 12 Monaten — eine Hausnummer, die in vielen mittelständischen Fertigern den ganzen KI-Business-Case rechtfertigt.

Use Case 2 und 6 sehen wir meist als Azure-DI-Land mit gezielter VLM-Eskalation. Standard-Lieferscheine haben drei bis fünf Layout-Varianten, die Azure DI mit einem Custom Model in unter zwei Wochen abdeckt. Erst bei handgeschriebenen Mengen, Stempeln oder Foto-Annotations lohnt das VLM als zweite Stufe.

Was VLM in der Fertigung kann, was klassisches OCR nicht kann

Klassisches OCR und Azure DI sind brillant in strukturierter Extraktion: Felder aus festen Positionen, Tabellen, Confidence-Scores. Was sie nicht können: Bedeutung interpretieren. Ein VLM antwortet auf „Ist auf diesem Bauteilfoto ein Riss in der Schweißnaht erkennbar, und wenn ja, welche Position?“ mit strukturierter JSON-Antwort. Azure DI würde diese Frage nicht einmal verstehen.

Die Modell-Landschaft Mai 2026 — was lohnt sich wirklich

Wir haben in den letzten sechs Monaten alle relevanten VLMs gegen Pexon-Kunden-Daten gebenchmarkt. Die Wahl hängt an drei Achsen: Cloud vs On-Device, Lizenz, Document-vs-Real-Image-Stärke.

Modell Größe Lizenz Stärke Cloud / Self-Host
GPT-4o Vision proprietär API only Top-Quality, Reasoning Cloud
Claude Sonnet 4 Vision proprietär API only Top-Quality, technische Zeichnungen Cloud
Gemini 2.5 Pro Vision proprietär API only Günstigster Cloud-Tier, EU-Region Vertex Cloud
Qwen 2.5-VL 7B 7B Apache-2.0 DocVQA 95,7 — Top Open-Source Self-Host
Qwen 2.5-VL 72B 72B Apache-2.0 Cloud-Niveau, GPU-hungrig Self-Host
IBM Granite Vision 3B 3B Apache-2.0 Top in 2-4B-Klasse, Edge-fähig Self-Host / On-Device
Shakti-VLM klein Enterprise Structured Business Documents, kleiner Footprint Self-Host / On-Device
Llama 3.2 Vision 1B/3B 1B/3B Llama-Lizenz On-Device-tauglich On-Device
Llama 3.2 Vision 90B 90B Llama-Lizenz Stark, aber langsam Self-Host
InternVL divers Apache-2.0 Industrial Benchmarks Self-Host

Zwei Modelle stechen für die Fertigung heraus. IBM Granite Vision in der 3B-Variante schlägt in der 2-4B-Klasse fast alle Wettbewerber und läuft auf einem einzelnen Edge-Server mit 16 GB VRAM. Wir setzen es regelmäßig für On-Device-Qualitätskontrolle ein. Shakti-VLM, vorgestellt 2026 von Sandeep Reddy, ist gezielt auf strukturierte Business-Dokumente trainiert und hat einen Footprint, der in Hallen ohne dicke Cloud-Anbindung Sinn ergibt.

Qwen 2.5-VL 7B bleibt unser Default für Self-Hosted-Setups mit DSGVO-Anforderung. Der DocVQA-Score von 95,7 ist die Hausnummer, an der sich alle anderen messen müssen — Llama 3.2 Vision 90B liegt bei 90,1, obwohl es das zehnfache an Parametern hat.

Der On-Device-Trend ist 2026 echt geworden

Bis Mitte 2025 war „VLM on the edge“ ein Versprechen. 2026 ist es Realität. Granite Vision 3B mit 4-bit Quantisierung läuft auf einer NVIDIA Jetson Orin am Band mit unter 800 ms Latenz pro Bild. Shakti-VLM und Llama 3.2 Vision 3B schaffen vergleichbare Werte. Bilddaten verlassen das Werk nicht mehr, der Datenschutzbeauftragte unterschreibt schneller, Netzwerk-Bandbreite ist kein Bottleneck mehr.

VLM vs Azure Document Intelligence — die ehrliche Entscheidungstabelle

Wir bekommen diese Frage in jedem zweiten Discovery-Workshop. Hier die nüchterne Tabelle aus unserer Projekt-Erfahrung:

Kriterium Azure Document Intelligence VLM
Strukturierte Standard-Formulare 95%+ Accuracy, ca. 0,01 EUR/Seite überlegen, aber nicht nötig
Layout-Varianz, Handschrift, Stempel scheitert zwischen 60-75% Felder-Coverage 90-95%
Echte Bilder (Produktionsfotos, Defekte) nicht designed dafür Kernkompetenz VLM
Reasoning auf Inhalte nein ja
Kosten pro 1.000 Seiten ca. 10 EUR 1-20 EUR je Modell
Custom Model Training mit 50+ Samples meist Zero-Shot
DSGVO-Pfad Azure EU mit AVV Self-hosted on-prem möglich
Latency 1-3 Sek/Seite (Cloud) 0,5-5 Sek je Modell
Tabellen-Extraktion strukturiert sehr gut Halluzinations-Risiko
Confidence pro Feld nativ vorhanden muss separat modelliert werden

Azure DI ist nach wie vor das wirtschaftlich richtige Werkzeug für 80% aller Standard-Dokumente in der Fertigung. Lieferscheine, Rechnungen, Bestellbestätigungen, Konformitätserklärungen mit festem Layout — wer hier ein VLM einsetzt, verschenkt Geld und nimmt halluzinierte Felder in Kauf, ohne dafür einen Gegenwert zu bekommen.

VLM Fertigung gewinnt überall dort, wo das Eingangsbild kein „Dokument“ im klassischen Sinn ist: Defekt-Fotos, Werkzeugbilder, technische Zeichnungen mit Bemaßung, Schaltschrank-Inspektionen. Hier scheitert Azure DI nicht weil es schlecht wäre, sondern weil es für diese Aufgabe nicht gebaut wurde.

Decision Tree für VLM Fertigung in der Praxis

Wir nutzen in Discovery-Workshops diesen einfachen Baum als Routing-Logik:

  • Lieferschein/Rechnung mit Standardlayout? → Azure DI Custom Model
  • Wareneingang mit Variation und semantischem ERP-Matching? → Azure DI als Foundation, VLM als Eskalation
  • Defekterkennung am Band, Bauteilbilder, Werkzeug-Identifikation? → VLM, idealerweise on-device
  • Technische Zeichnungen mit Annotations, Reasoning nötig? → VLM (Claude Sonnet 4 Vision oder Granite Vision)
  • On-Device-Anforderung am Band, niedrige Latenz? → Granite Vision 3B oder Shakti-VLM
  • Hochvolumig (>100k Bilder/Tag), DSGVO-strikt? → Self-hosted Qwen 2.5-VL 7B im EU-Rechenzentrum

Der Decision Tree ist kein Dogma. Er ist der Startpunkt für eine Architektur-Diskussion, in der wir gemeinsam mit dem Kunden die Kosten, die Latenz-Anforderungen und die Compliance-Pfade durchrechnen.

Drei Code-Beispiele aus unseren Fertigungs-Projekten

Theorie hilft begrenzt, wenn am Ende ein Engineering-Team etwas bauen muss. Hier sind drei Bausteine, die wir in nahezu jedem VLM-Manufacturing-Projekt verwenden.

Azure DI Custom Model für Lieferschein-Extraktion

Der Klassiker für den Wareneingang. Azure Document Intelligence mit einem Custom Model auf 50 bis 100 echten Lieferscheinen trainiert. Aufwand: zwei Wochen, danach 95%+ Accuracy auf den trainierten Lieferanten.

from azure.ai.documentintelligence import DocumentIntelligenceClient
from azure.core.credentials import AzureKeyCredential

client = DocumentIntelligenceClient(
    endpoint="https://pexon-di.cognitiveservices.azure.com/",
    credential=AzureKeyCredential(KEY),
)
with open("lieferschein.pdf", "rb") as f:
    poller = client.begin_analyze_document("lieferschein-custom-v3", body=f.read())
result = poller.result()

for doc in result.documents:
    for name, field in doc.fields.items():
        if field.confidence < 0.85:
            eskalation_an_vlm = True

Der Confidence-Check am Ende ist der Trick. Felder unter 0,85 gehen in unseren Projekten in eine zweite Stufe — entweder ins VLM oder in eine menschliche Review-Queue.

Granite Vision On-Device für optische Qualitätskontrolle

Diesen Baustein nutzen wir für die Defekt-Detection am Band. Granite Vision 3B läuft via Ollama auf einem Edge-Server in der Produktionshalle. Die Bilder verlassen das Werk nie. Achtung: Die Prompts sind auf Deutsch, mit korrekten Umlauten, weil das Modell auf deutschsprachigen Output reagiert.

import base64
import requests

with open("bauteil_15823.jpg", "rb") as f:
    base64_image = base64.b64encode(f.read()).decode("utf-8")

response = requests.post(
    "http://edge-device.pexon.local:11434/api/generate",
    json={
        "model": "granite-vision:3b",
        "prompt": (
            "Prüfe das Bauteilbild auf sichtbare Defekte. "
            "Antworte als JSON mit defekt_art, position, "
            "schweregrad 1-10, beschreibung."
        ),
        "images": [base64_image],
        "format": "json",
        "options": {"temperature": 0.0},
    },
)
ergebnis = response.json()

Temperatur 0,0 ist Pflicht. Wir wollen reproduzierbare Klassifikationen, keine kreativen Defekt-Beschreibungen. Die JSON-Struktur schreiben wir streng vor, weil das Output direkt in die Wartungs-Datenbank fließt.

Hybrid-Routing zwischen Azure DI und VLM

Die wichtigste Architektur-Komponente. Eine simple Routing-Funktion, die entscheidet, welches Modell ein Eingangs-Asset bekommt. In unseren Projekten ist diese Funktion fast immer ein paar hundert Zeilen Python — hier die Essenz:

def classify_and_route(image, doc_type):
    if doc_type in ["lieferschein_standard", "rechnung", "auftragsbestaetigung"]:
        ergebnis = azure_di_extract(image)
        if ergebnis["min_confidence"] < 0.85:
            return granite_vision_on_device(image)
        return ergebnis
    elif doc_type in ["bauteil_qk", "werkzeug_id", "schaltschrank_foto"]:
        return granite_vision_on_device(image)
    elif doc_type == "technische_zeichnung":
        return claude_sonnet_vision_eu(image)
    else:
        return qwen_vlm_self_hosted(image)

Drei Regeln aus unserer Praxis. Erstens: Confidence-Routing ist Pflicht, sonst halluziniert das System unbemerkt. Zweitens: Pro Dokumententyp eine explizite Modell-Wahl, kein „wir nehmen immer das Beste“. Drittens: Logging und Eval auf jedem Pfad, sonst weiß niemand, ob das Routing nach drei Monaten noch passt.

Was VLM in der Fertigung kostet — eine ehrliche Rechnung

Kostenfragen kommen in unserem Discovery-Workshop spätestens nach 30 Minuten. Hier die Hausnummern, die wir aktuell rechnen:

Cloud-VLM (GPT-4o Vision, Claude Sonnet 4 Vision, Gemini 2.5 Pro Vision): 5-20 EUR pro 1.000 Bilder, je nach Resolution und Output-Länge. Skaliert linear, kein Setup. Geeignet bis ca. 50.000 Bilder/Monat oder wenn DSGVO über AVV mit EU-Region abgedeckt ist.

Self-hosted Qwen 2.5-VL 7B: GPU-Server (1x A100 oder 2x L40S) mietweise ab 2.500 EUR/Monat, On-Premise ab 25.000 EUR Investition. Lohnt sich ab ca. 30.000 Bildern/Monat oder bei strikter DSGVO. Plus 15-25% Operationskosten.

On-Device Granite Vision 3B / Shakti-VLM: Edge-Server mit RTX 4090 oder Jetson Orin: 3.000-8.000 EUR Hardware pro Standort. Keine laufenden API-Kosten. Wirtschaftlich ab dem zweiten Produktionsstandort oder bei Latenz-Anforderung unter 1 Sekunde.

Azure Document Intelligence: Ca. 0,01 EUR pro Seite Standardmodell, ca. 0,05 EUR pro Seite Custom Model. Für 100.000 Seiten/Monat: 1.000-5.000 EUR. Setup Custom Model: 5-15 Personentage.

Unsere Erfahrung: In 80% aller Projekte zu VLM Fertigung ist die Gesamtarchitektur hybrid und bewegt sich zwischen 4.000 und 15.000 EUR/Monat Run-Kosten, plus einmaligen Setup zwischen 30.000 und 120.000 EUR. Wer nur VLM oder nur Azure DI fährt, zahlt 30-50% mehr für schlechteres Ergebnis.

Anti-Patterns — was wir in Manufacturing-Projekten regelmäßig sehen

Aus den letzten zwölf Monaten sieben Anti-Patterns, die wir bei mindestens einem Discovery-Workshop pro Monat aufräumen:

  • VLM für reine Standard-Rechnungen einsetzen — Azure DI ist 10x günstiger und genauer.
  • Cloud-VLM für DSGVO-kritische Produktionsbilder ohne EU-Region oder ohne AVV.
  • On-Device-VLM ohne Eval-Setup deployen — niemand merkt, wenn die Genauigkeit über die Zeit abfällt.
  • Reines VLM auf große Tabellen mit 50+ Zeilen — strukturelle Halluzinationen, sichtbare Schäden.
  • Confidence-Routing weglassen, weil „VLMs eh gut genug sind“. Sind sie nicht, in 5-10% der Fälle.
  • VLM-Modell-Wahl ohne Benchmark auf eigenen Daten. Das Modell-Ranking aus dem Internet stimmt selten für den eigenen Use Case.
  • Den menschlichen Review-Loop nach Go-Live abschalten. Die ersten drei Monate Produktion ohne Review sind blind.

Unsere Empfehlung aus der Praxis: Jedes Projekt zu VLM Fertigung braucht ein Eval-Set von 200-500 echten Bildern mit Ground-Truth-Annotations, sonst lässt sich weder Modellwahl noch Drift-Monitoring belastbar machen.

FAQ

Wann lohnt sich VLM gegenüber Azure Document Intelligence in der Fertigung?

Sobald das Eingangs-Asset Reasoning verlangt oder das Layout stark variiert. Für Defekt-Fotos, technische Zeichnungen, Werkzeug-Identifikation und Schaltschrank-Inspektion ist VLM Pflicht. Für Standard-Lieferscheine und Rechnungen bleibt Azure DI 10x günstiger und genauer.

Welches VLM für On-Device-Einsatz am Produktionsband?

IBM Granite Vision 3B oder Shakti-VLM. Beide laufen auf einem Edge-Server mit 16 GB VRAM (Jetson Orin oder RTX 4090) mit unter 1 Sekunde Latenz pro Bild. Granite Vision liegt in der 2-4B-Klasse aktuell auf Platz 3 der VAREX-Benchmarks und ist Apache-2.0-lizenziert.

Wie hoch ist die Genauigkeit von VLM bei optischer Qualitätskontrolle?

Sysgenpro berichtet 97-99,5% Defekt-Detection-Genauigkeit bei gut trainierten Setups. In unseren Pexon-Projekten landen wir in den ersten drei Monaten typischerweise bei 92-96%, nach Eval-Loop und Prompt-Tuning bei 96-98%. Der ROI liegt erfahrungsgemäß bei 6-12 Monaten, bei einem Throughput-Gewinn von 20-25%.

Kann ich VLM für Materialzeugnis-Prüfung einsetzen?

Ja, das ist einer der Use Cases mit dem höchsten Hebel. Materialzeugnisse kombinieren Tabellen, Stempel, Unterschriften, oft auch handschriftliche Annotations. Azure DI scheitert hier regelmäßig an der Layout-Varianz. Unsere Empfehlung: Claude Sonnet 4 Vision in der EU-Region für Cloud, Qwen 2.5-VL 7B für Self-Host. Eval-Set mit 200+ Zeugnissen ist Pflicht.

Was kostet ein VLM-Setup für 100.000 Bilder pro Monat in der Fertigung?

Drei Pfade. Cloud-API (GPT-4o oder Gemini 2.5 Pro Vision): 500-2.000 EUR/Monat Run, 20.000-40.000 EUR Setup. Self-hosted Qwen 2.5-VL 7B im EU-Rechenzentrum: 2.500-4.000 EUR/Monat Infrastruktur, 40.000-80.000 EUR Setup. On-Device Granite Vision an mehreren Standorten: 3.000-8.000 EUR Hardware pro Standort, 50.000-120.000 EUR Setup, dafür keine laufenden API-Kosten.

So gehen Sie weiter

Unser Vorschlag für Fertiger zwischen VLM und Azure DI: Bringen Sie uns 200-500 echte Bilder aus drei bis fünf Use Cases. Wir bauen daraus einen reproduzierbaren Benchmark, vergleichen Cloud-VLMs, Self-hosted Modelle und Azure DI auf Ihren Daten und liefern Architektur-Empfehlung plus Kostenrechnung. Spart drei bis sechs Monate Eigenversuche.

VLM-Benchmark auf Ihren Fertigungsbildern — kostenfreie Vorab-Analyse

Verwandte Themen

Microsoft Fabric. Bilder Blogtemplate Whitepaper

Checkliste: Dokumentensuche mit KI in SharePoint & Confluence

  • Optimierte KI-gestützte Dokumentensuche für heterogene Unternehmensquellen

Beratungsgespräch

Sichern Sie sich Ihre kostenfreie Erstberatung

Analyse Ihres individuellen Cloud- oder KI-Bedarfs
Erste Empfehlungen zu Umsetzungsstrategien
Transparente Einblicke in unsere Methoden, Technologien & Referenzen