GPT durch ein selbst gehostetes Open-Source-Modell ersetzen: Erfahrungsbericht zur Dokumentenextraktion

Kurz gesagt: tatsächliche Migration eines Dokumentenextraktions-Stacks vonAzure (Document Intelligence + GPT-4o) zu einem selbst gehosteten Open-Source SLM auf einer einzigen GPU. Ergebnis : Cloud-äquivalente Qualität, schnellere Verarbeitung, und bis zu 20× günstiger im grossen Massstab - ohne dass sensible Daten die Infrastruktur verlassen. Relevant ab einigen tausend Seiten/Monat, unter der Auflage von Souveränität oder rate limits.

Die Dokumentenextraktion gehört zu den Aufgaben der generativen KI, die sich leicht mit proprietären API-Modellen wie GPT, Claude und Gemini bearbeiten lassen. Diese Modelle sind schnell zu integrieren, leistungsstark und einfach zu betreiben. Ihre Nutzung stösst jedoch schnell an die Grenzen mehrerer Einschränkungen : die Datensouveränität, die Kosten pro Token die mit dem Volumen steigen, rate limits die den Durchsatz begrenzen, die Moderation die manchmal legitime Anfragen blockiert, und die Abhängigkeit von einem Anbieter.

Die Leistung der SLM open-source (Small Language Models) erreichen heute das Niveau grosser proprietärer Modelle bei klassischen Aufgaben (OCR, Segmentierung, strukturierte Extraktion). Bei Galadrim, einer französischen Tech- & KI-Agentur, haben wir diese Migration für einen Kunden durchgeführt, der strengen Souveränitätsbeschränkungen unterliegt. Dieser Artikel beschreibt den Erfahrungsbericht Schritt für Schritt im Detail: Modellauswahl und GPU, Inbetriebnahme, Schutzmechanismen und Bewertungsmethode, um sicherzustellen, dass keine Qualitätseinbussen entstehen.

Der Kontext: Warum eine proprietäre API nicht mehr tragbar war

Das Projekt ist eine massgeschneiderte Business-Applikation für ein medizinisches Gutachterbüro, dessen Kunden Krankenversicherungen in der Schweiz sind. Ein Benutzer lädt dort ein zusammengesetztes PDF-Dossier, oft 50 bis 500 Seiten, das heterogene Unterlagen wie Berichte, Formulare, Korrespondenz, Rezepte und Rechnungen zusammenführt. Die Applikation teilt dieses PDF in separate Unterdokumente auf, extrahiert Datum und Titel, erstellt eine Zusammenfassung und wählt die nützlichen Unterlagen für die Verarbeitung aus.

Intern durchläuft dieser Pipeline 7 Schritte :

Seitenrendering in Bildern,
OCR,
Segmentierung (Grenzen zwischen Unterdokumenten festlegen),
Zusammenführung der Blöcke,
Extraktion der Daten,
Extraktion des Inhalts (Titel + Zusammenfassung + Auswahl),
und Deduplizierung.

Die Segmentierung ist der Dreh- und Angelpunkt. Wenn falsch geschnitten wird, ist der Rest verzerrt: Ein in mehrere Teile aufgeteilter Bericht lässt die extrahierten Daten explodieren und verfälscht die Auswahl. Daher haben wir unsere Tests zuerst auf diese Phase konzentriert.

Die Schutz privater Daten stand im Mittelpunkt der Entwicklungsbeschränkungen des Projekts aufgrund der sensiblen Daten, die durch das LPD schweizerische (Bundesgesetz über den Datenschutz), dem Äquivalent der europäischen Datenschutzverordnung. Mehrere Kunden der Lösung wünschten sich, über die von Azure in der Schweiz angebotenen vertraglichen Garantien hinsichtlich der Datenhoheit hinauszugehen.

Zu dieser regulatorischen Auflage gesellten sich bereits ein Kosten pro Token verrechnet, die mit dem Volumen steigen, und eine Abhängigkeit von Lieferanten ausserhalb unserer Kontrolle. Der Kunde forderte daher im Vorfeld eine Infrastruktur, 100 % schweizerisch, ohne aussereuropäische Dritte im Kreislauf. Dies ist der Auslöser für die Migration.

Das passende SLM wählen: Multimodalität und VRAM-Budget

Die Migration zu einem selbstgehosteten GPU-System bringt Infrastrukturkosten und operative Komplexität mit sich und wirft hauptsächlich folgende Fragen auf: Welche Infrastruktur ist für die Inferenz zu wählen, insbesondere der GPU-Arbeitsspeicher (VRAM), und welches Modell ist für jede Aufgabe zu wählen (Anzahl Parameter, Quantisierung usw.)?

Das LLM für Extraktions- und Syntheseaufgaben

Die Eingabe der Segmentierungsphase besteht ausBildern von Seiten. Es ist also ein multimodales, mit grossem Kontextfenster, das auf einer einzigen GPU läuft.

Modell	Aktive Parameter	VRAM Q5	Multimodal	Wahl
Llama 3.1 70B	70B	~50 GB	✗	✗keine Vision
Mistral Large 2 123B	123B	> 80 GB	✗	✗nicht machbar single-GPU
Qwen2.5-VL 32B	32B	~22 GB	✓	▲korrekt, aber langsam
Qwen3.6-35B-A3B (MoE)	3B aktiv / 35B	~28 GB	✓	✓ausgewählt
Pixtral 12B	12B	~10 GB	✓	✗Qualitätsunterschied

Tabelle 1 - Wahl des multimodalen Modells (Splitter): Eine einzige GPU 48 Go, Vision zur Seitenlesung erforderlich.

Wir haben ein Mixture-of-Experts (Qwen3.6-35B-A3B) ausgewählt: Es aktiviert nur 3 Milliarden Parameter pro generiertem Token, verfügt aber über das Wissen eines Modells mit 35 Milliarden Parametern. Wir erhalten somit den Durchsatz eines kleinen Modells mit der Qualität eines grossen.. Bei unserer Aufgabe ist er auf dem Niveau von GPT-4o bei der Segmentierung und Datumsextraktion.

Die OCR

GLM-OCR ist spezialisiertes OCR (nicht generalistisch) und liest die Handschriften. Dies ist ein kritischer Punkt bei Formularen, wo die nützliche Information oft eine handschriftliche Notiz ist.

Modell	Qualität kleiner Text	Geschwindigkeit	Wahl
Azure Document Intelligence	Referenz	1-2 s/p	✗cloud
Tesseract / PaddleOCR	auf Stempeln/Schrift verschlechtert	< 1 s/p	✗unzureichend
Qwen2.5-VL OCR-mode	gut	8-10 s/p	▲langsam
GLM-OCR (THUDM)	≈ Azure DI	1-2 s/p	✓ausgewählt

Tabelle 2 - Wahl der OCR-Engine: Qualität nahe an Azure, ohne die Cloud.

Quantization : ist vor allem eine Frage des VRAM-Budgets

Zwei Modelle auf 48 GB koexistieren zu lassen, ist vor allem ein Problem desSpeicherbedarfs. Wir haben mehrere Stufen der quantization verglichen und gewählt, für unseren Fall und unser VRAM, den Q5_K_M für den LLM und den Q8_0 für die OCR: Dies ist der Punkt, an dem die Qualität auf unseren Aufgaben vom FP16 nicht zu unterscheiden ist, während genügend Spielraum bleibt, um mehrere konkurrierende LLM-Anfragen. Das richtige Niveau hängt vom Modell, der Aufgabe und der GPU ab. Der Q4 verschlechterte die strukturierte Extraktion und die OCR kleiner Ziffern; der FP16 passte einfach nicht hinein.

Abbildung 1 - Die beiden Modelle koexistieren auf einer einzigen 48 GB GPU: ~38 GB zugewiesen, ~10 GB als Marge reserviert, um Kontextspitzen abzufangen.

Zwei Lehren aus der Inbetriebnahme der SLM

« Thinking Mode » abschalten: die Aufgabe strukturieren, anstatt das Modell denken zu lassen

Standardmässig gibt das Modell mehrere Tausend Reasoning-Tokens (…) aus, bevor es sein JSON produziert. Bei einer Aufgabe mit strukturierter Ausgabe, ist dieses Reasoning verlorene Zeit: Bei einem Batch von 10 Seiten reduziert sich die Zeit von ~20 s auf ~3 s, wenn es deaktiviert wird – ein gain × 5 à × 10.

Jenseits des Flags: Bei strukturierten Aufgaben hängt die Qualität weniger vom freien Reasoning ab als davon, die Aufgabe im System-Prompt gut zu definieren und zu strukturieren im System-Prompt. Und wenn die Ausgabequalität kritisch ist, ersetzen wir das implizite Reasoning durch einen expliziten und kontrollierten Mechanismus, typischerweise mehrere Durchläufe in einem adversarialen Netzwerk von LLM-as-a-judge um das Prompt-System zu härten und zu validieren. Wir behalten das Reasoning nur dort bei, wo es wirklich hilft (hier, die Deduplizierung).

Immer die Schutzmassnahmen testen: Open-Source-Modelle halluzinieren

Ein selbst gehostetes SLM hat kein Sicherheitsnetz eines Anbieters. Sie müssen Ihre eigenen Schutzmassnahmen aufbauen und sie unter realen Bedingungen testen um die richtigen Lösungen zu finden.

Schutzmassnahme	Auslösung	Effekt
OCR-Schleifenerkennung	Anormal lange Ausgabe oder Wiederholung auf Satzebene	Speicherung des gültigen Präfixes, retry, fallback
Fallback pro Seite	Das Parsing eines OCR-Batches schlägt fehl	Re-OCR Seite für Seite
Fallback LLM bei OCR-Schleife	OCR-Schleife + fehlgeschlagenes retry	Wechselt zum LLM vision für diese Seite
Exponentielles Retry	HTTP-Fehler / Timeout	Behebt Netzwerktransienten oder Überlastung
Boundary resolver	Der Splitter zögert zwischen 2 Grenzen	Reinjiziert den angrenzenden Kontext, um zu entscheiden

Tabelle 3 - Schutzmechanismen der selbst gehosteten Pipeline: Ohne Lieferantennetz wird alles auf Seiten der Pipeline verwaltet.

In der Praxis beheben diese Schutzmechanismen fast alle Vorfälle: Bei unseren Batches gelangen etwa 1 % der Seiten in eine Halluzinationsschleife, und 100 % werden wiederhergestellt via Speicherung des gültigen Präfixes + fallback. Das Ziel ist, diese zu erkennen und einen systematischen Plan B zu haben.

Messen, um zu entscheiden: wie wir validiert haben, dass wir nichts verlieren

Das grösste Risiko einer Migration wie dieser ist es, die Qualität stillschweigend zu verschlechtern. Wir haben daher ein harness Evaluierungsharness, das jeden Output des lokalen Modells mit einer Referenz, auf einem Satz von annotierten, repräsentativen Dossiers (mehrere hundert Unterdokumente).

Welche Referenz? Das Ziel ist dieExtraktion, die im Vorfeld durch GPT-4o erfolgte (der historischen Produktions-Stack), konsolidiert durch Annotation. Wichtiger Punkt: Diese Referenz ist keine absolute Wahrheit. Es bestehen geschäftliche Unsicherheiten und es kommt vor, dass der LLM-as-a-judge schätzt, dass das Aufteilen oder die Extraktion des lokalen Modells sind besser als die Referenz. Anders ausgedrückt, ein Teil der gemessenen «Abweichungen» sind keine Regressionen, sondern legitime Uneinigkeiten, was die Rohwerte mechanisch nach unten begrenzt.

Das Mechanische vom Semantischen trennen. Alles, was mechanisch vergleichbar ist (Grenzen, Daten, Auswahl, Halluzinationen), wird in reinem Python, Ausrichtung durch Seitenüberlappung, F1, was diese KPIs Bit-für-Bit reproduzierbar zwischen zwei Runs. Aber bestimmte Kriterien reduzieren sich nicht auf einen exact-match : «Medizinischer Bericht Dr. Martin» und «Erster Bericht – Jean MARTIN» bezeichnen dasselbe Dokument. Für diese Fälle gibt ein LLM-as-a-judge ein strukturiertes Urteil ab: ok | partial | ko + einen kurzen Grund. Nur diese Schicht hängt von einem LLM ab, daher bleibt sie unabhängig auditierbar.

KPI	Definition	Ziel
Cut F1 (Tol. ±1)	Präzision/Recall der Schnittgrenzen	≥ 90 %
Date exact rate	% exakt vorhergesagter Daten	≥ 80 %
is_selected F1	Auswahl nützlicher Teile	≥ 90 %
Hallucination rate	% der vorhergesagten Dokumente ohne Übereinstimmung	≤ 2 %
Title verdict	Titelqualität, beurteilt durch LLM	≥ 95 % ok

Tabelle 4 - KPIs und Geschäftsziele: Das Mechanische vom Semantischen trennen.

Tipp: der LLM-as-a-judge als Annotator, wenn man keinen golden set hat. Eine ground truth von Hand aufzubauen ist teuer. Mit den heutigen Modellen (nutzen wir heute Claude Code mit Opus 4.8, oder Codex mit GPT-5.5), ist ein LLM-as-a-judge ein überraschend zuverlässiger Start-Annotator: er prä-annotiert, wir lesen Korrektur und iterieren. Das ist ein hervorragender Weg, um ein kostengünstiges Evaluationsset zu starten.

⚠️ Bei sensiblen Daten, anonymisieren Sie zuerst. Sobald Inhalte an einen LLM-as-a-judge oder ein Annotationsmodell gesendet werden - erst recht via eine externe API - muss man vorab anonymisieren (Schwärzung von Identitäten, Identifikatoren). Sonst führt man durch die Hintertür genau das Datenleck wieder ein, das man zu eliminieren versuchte, indem man on-premise migrierte. Daher die Bedeutung eines anonymisierten Basis-Sets.

(Querverweis) Um schnell zu iterieren, ist es ein Code-Agent, der die Evaluationskette steuert, : er startet die Pipelines, löst die Bewertungsdurchläufe aus, aggregiert die Übersichten und generiert einen Cross-Runs-Vergleich neu – ohne manuelles Eingreifen. Ein gutes Beispiel für den Einsatz von Code-Agenten zur Beschleunigung einer F&E-Schleife.

Ergebnisse: Qualität, Geschwindigkeit, Kosten

Die Qualität stimmt

KPI	Score (lokal)	Verdict
Cut F1 (Tol. ±1)	89,8 %	✓auf Zielniveau
Date exact rate	81,3 %	✓
is_selected F1	85,1 %	✓
Hallucination rate	0,4 %	✓nahezu null
Titel-Verdict ok	68 % ok / 25 % teilweise / 6 % ko	✓

Tabelle 5 - Resultate des lokalen SLM im Vergleich zu den Zielen: alle Indikatoren auf dem erwarteten Niveau.

Abbildung 2 - Das lokale SLM erreicht oder nähert sich den Geschäfts-Zielen bei allen KPIs, mit einer Halluzinationsrate von nahezu null (0,4 %).

Bei einem repräsentativen Dossier erreicht die Segmentierung einen Cut F1 von 98 %, : die vorhergesagten Grenzen stimmen fast alle mit den Referenzgrenzen überein, mit nur zwei geringfügigen Über-Segmentierungen bei 48.

Abbildung 3 - Referenz- und vorhergesagte Grenzen bei einem Dossier von 79 Seiten. 46 der 48 vorhergesagten Grenzen sind exakt; die beiden eingekreisten Über-Cuts sind die einzigen Abweichungen.

Die Geschwindigkeit: schneller als die Cloud

Direkte Messung bei einem gleichen Dossier von 530 Seiten :

	Azure (DI + GPT-4o)	Lokal (GPU L40S)	Ratio
Wall-Clock-Zeit	45 min	30 min	× 1,5 schneller
Kosten des Runs	$8.70	~$0.45 (geschätzt auf Basis der Stundenkosten)	× ~20 günstiger

Tabelle 6 - Azure vs lokal bei einem gleichen Dossier von 530 Seiten.

Die lokalen Kosten sind nicht null: sie werden geschätzt, indem die Maschinenzeit auf die Stundenkosten der GPU (~$0.90/h). Ein 30-minütiger Run kostet somit ~$0.45 an Rechenleistung, gegenüber $8.70, die von der Cloud für das gleiche Dossier verrechnet werden.

Abbildung 4 - DATES und SPLIT konzentrieren 92 % der Verarbeitungszeit: das sind die beiden Posten, die prioritär parallelisiert werden müssen.

Zu beachten ist eine Grenze: eine einzelne GPU kann keine enorme parallele Last bewältigen: man erreicht ein Maximum von etwa ~15 Seiten/min bei maximaler Last. Das ist perfekt für die Verarbeitung asynchron mit moderatem Volumen,weniger geeignet für einen massiven Echtzeit-Peak.

Die Kosten: das wahre Argument für die Skalierung

Bei den Kosten ist der Gewinn am deutlichsten. Die GPU kostet einen fixen Betrag (~$0.90/h, das sind ~$650/Monat im 24/24-Betrieb), unabhängig vom Volumen,. Die Cloud hingegen verrechnet jede Seite.

Metrik	Azure	Lokal (GPU 24/24)
Grenzkosten / Dossier (530 p)	$8.70	~$0.45 (on-demand)
Fixkosten / Monat	0 (pay-as-you-go)	~$650
Rentabilitätsschwelle	-	ab ~75 grossen Dossiers / Monat

Tabelle 7 - Kosten - Azure vs GPU lokal 24/24.

Im 24/24-Modus tendieren die Grenzkosten eines zusätzlichen Dossiers gegen null (die Maschine läuft sowieso). Jenseits der Schwelle, jedes zusätzliche Volumen wird zu quasi null Grenzkosten verarbeitet seitens der KI-Infrastruktur, und die Kluft vergrössert sich linear.

Abbildung 5 - Die Cloud-Kosten steigen mit dem Volumen; die On-Premise-GPU bleibt fix. Ab ~75 grossen Dossiers/Monat, vergrössert sich die Kluft zugunsten der On-Premise-Lösung.

Wann auf ein On-Premise SLM umsteigen

Diese Migration ist kein Dogma. Hier ist der daraus abgeleitete Entscheidungsrahmen.

Wechseln Sie zu einem selbst gehosteten SLM, wenn:

Sie eine Souveränitäts-/Compliance-Anforderung starke (sensible Daten, regulierter Sektor);
Ihr Volumen die Rentabilitätsschwelle überschreitet (typischerweise einige Dutzend bis Hunderte von Dossiers/Monat);
Sie regelmässig auf Rate Limits der APIs : selbst hosten heisst, die Kontrolle über den eigenen Throughput zu übernehmen, anstatt die Quoten des Anbieters hinnehmen zu müssen;
Ihr Anwendungsfall ist «klassisch» (OCR, Segmentierung, strukturierte Extraktion, Klassifizierung), wo die SLM zu den grossen Modellen aufgeschlossen haben;
Ihre Last ist asynchron und eine Latenzzeit in der Grössenordnung einer Minute toleriert wird.

Was wir unterwegs gelernt haben

Die Quantisierung ist eine lokale Abwägung, keine Patentlösung: der richtige Grad hängt vom Modell, der Aufgabe und Ihrem VRAM ab.
MoE = Qualität eines grossen Modells bei der Durchsatzrate eines kleinen : ein ausgezeichnetes Profil für selbst gehostete Lösungen.
Strukturieren Sie die Aufgabe anstatt das Modell frei argumentieren zu lassen: sorgfältiger System-Prompt, und adversariale LLM-as-a-judge Durchläufe, wenn die Qualität kritisch ist.
Testen Sie Ihre Schutzmassnahmen unter realen Bedingungen : Open-Source-Modelle halluzinieren, es geht darum zu erkennen und zu korrigieren, nicht darum, den illusorischen Null-Fehler anzustreben.
Trennen Sie die mechanische (reproduzierbare) Bewertung vom semantischen Urteil (LLM) für KPIs Auditierbare Ergebnisse - und anonymisieren Sie vor jeder externen Begutachtung.

Fazit

Bei dieser Dokumentenverarbeitung hat ein Open-Source-SLM in MoE-Architektur, gepaart mit einem spezialisierten OCR, auf einer einzigen GPU für ~$650/Monat, erreicht die Cloud-Qualität, ist schneller, kostet im grossen Massstab bis zu 20-mal weniger, und hält sensible Daten im Rahmen. Open Source ersetzt nicht alles: es geht darum, das richtige Modell für den richtigen Einsatzzweck zu wählen. Für klassische Aufgaben, mit hohem Volumen, unter Souveränitäts- oder Rate-Limit-Beschränkungen, sind die SLM bereit.

Von Maceo Duriez, AI Engineer bei Galadrim. Erfahrungsbericht aus einem realen Kundenprojekt.

FAQ

Kann ein Open-Source-SLM GPT-4o bei der Dokumentenextraktion erreichen?

Ja, bei den klassischen Aufgaben (OCR, Segmentierung, strukturierter Extraktion). In diesem Projekt erreicht das Modell lokale MoE das Niveau von GPT-4o bei der Segmentierung und Datumsextraktion. Die proprietären APIs behalten den Vorteil bei fortgeschrittenem Reasoning und komplexen agentischen Aufgaben.

Ab welchem Volumen wird das Selbsthosting rentabel?

Typischerweise einige Dutzend bis Hunderte von Dossiers/Monat. Die GPU kostet einen fixen Betrag (~650 $/Monat im 24/24-Modus); jenseits der Rentabilitätsschwelle (~3000 Seiten/Monat hier), wird jedes zusätzliche Dossier zu quasi null Grenzkosten verarbeitet, während die Cloud jede Seite abrechnet.

Was kostet die Verarbeitung eines Dossiers lokal vs. Cloud?

Für ein Dossier mit 530 Seiten: ~0,45 $ Compute-Kosten lokal (30 Min. bei ~0,90 $/h GPU) gegenüber 8,70 $ (ca. 16cts/Seite), die von der Cloud berechnet werden.

Wann sollte man bei einer proprietären API bleiben, anstatt ein On-Premise-SLM zu nutzen?

Wenn das Volumen gering ist, wenn Sie die fortschrittlichste Argumentation benötigen, wenn Sie massive Lastspitzen ohne Infrastrukturprovisionierung bewältigen müssen, oder wenn die Daten keine Standortbeschränkungen haben.

Möchten Sie bei der Lancierung Ihres digitalen Projekts begleitet werden?

Reichen Sie Ihr Projekt jetzt ein