Technische Referenz
Architektur, Verarbeitungspipeline, Systemanforderungen und Leistungs-Benchmarks für Transkribus On-Prem.
Verarbeitungspipeline
Stufen werden als Streaming-Pipeline ausgeführt. Während eine Seite erkannt wird, wird die nächste bereits layoutanalysiert. Das bedeutet, dass der Stapeldurchsatz deutlich höher ist, als die Einzelseitenlatenz vermuten lässt.
Erkennungsmotoren
Standard HTR
Encoder-Decoder-Neuronales-Netz für handgeschriebenen und gedruckten Text. Für Durchsatz optimiert. Unterstützt benutzerdefiniertes Modelltraining auf eigenen Daten und arbeitet mit dem vollständigen Katalog öffentlicher und privater Transkribus-Modelle. Sprachmodell-Unterstützung verbessert die Genauigkeit bei domänenspezifischen Inhalten.
- Schriften
- Lateinisch, Deutsch (Kurrent, Fraktur), wichtige europäische Schriften
- Genauigkeit
- CER 2–5% bei sauberen Dokumenten, 5–10% bei anspruchsvollem Material
- Durchsatz
- ~2–3 s/Seite pro GPU (warm, ~20 Zeilen/Seite)
- VRAM
- ~4 GB pro gleichzeitigem Modell
Best for: Groß angelegte Stapelverarbeitung, gut unterstützte Schriften, benutzerdefiniert trainierte Modelle
Super Models
Größere Architektur mit breiterer Schriftenabdeckung und höherer Genauigkeit bei schwierigem Material. Zugang zum vollständigen Transkribus-Super-Models-Katalog – Dutzende von Schriften und Sprachen, darunter historisches Deutsch, Latein, Griechisch, Kyrillisch, Hebräisch, Arabisch und ostasiatische Schriften.
- Schriften
- 70+ Schriften darunter Lateinisch, Griechisch, Kyrillisch, Hebräisch, Arabisch, Ostasiatisch
- Genauigkeit
- CER 1–3% bei gängigen Schriften, 3–7% bei seltenem Material
- Durchsatz
- ~4–5 s/Seite pro GPU (warm, ~20 Zeilen/Seite)
- VRAM
- ~8 GB pro gleichzeitigem Modell
Best for: Seltene Schriften, mehrsprachige Dokumente, höchste Genauigkeitsanforderungen
Beide Engines können auf derselben Installation gleichzeitig verfügbar sein. Der Nutzer wählt pro Auftrag. Standard HTR für Hochvolumen-Stapelverarbeitung gut unterstützter Schriften verwenden. Super Models einsetzen, wenn mit seltenen Schriften, mehrsprachigen Dokumenten oder wenn die Minimierung des CER oberste Priorität hat.
Layoutanalyse
Automatische Erkennung der Seitenstruktur vor der Erkennung. Das Layoutmodell identifiziert, wo sich Text, Tabellen, Kopfzeilen und andere Inhaltsbereiche befinden, legt Grundlinien innerhalb von Textbereichen fest und bestimmt die Leserichtung. Mehrere Layoutmodelle für verschiedene Dokumenttypen und historische Epochen sind verfügbar.
- Textregionen
- Grundlinien
- Leserichtung
- Tabellen
- Kopf- und Fußzeilen
- Marginalien
- Illustrationen
- Lombarden
Tabellen & Felder
Dedizierte Modelltypen für die strukturierte Datenextraktion. Tabellenmodelle erkennen Zeilen- und Spaltenstruktur innerhalb von Tabellenbereichen, die bei der Layoutanalyse identifiziert wurden. Feldmodelle extrahieren Werte aus Formularen und standardisierten Dokumenten mit bekannten Layouts. Beide erzeugen strukturierte Ausgabe, die für die Datenbankeinspeisung oder nachgelagerte Verarbeitung bereit ist.
- Tabellenextraktion mit Zeilen- und Spaltenstruktur
- Zellinhalterkennung innerhalb erkannter Tabellen
- Feldextraktion aus Formularen und standardisierten Dokumenttypen
- Strukturierte Ausgabe als Teil von PageXML oder separater Export
- Benutzerdefinierte Feldmodelle für domänenspezifische Dokumentlayouts
Ausgabeformate
| Format | What's included | Typical use |
|---|---|---|
| PageXML | Grundlinien, Polygone, Text, zeichenbasierte Konfidenz, Metadaten | Round-Trip mit Transkribus, wissenschaftliche Edition, Archivierung |
| ALTO XML | OCR-Struktur nach Bibliotheksstandard | METS-Container, institutionelle Repositorys, Europeana |
| Durchsuchbares PDF | Unsichtbare Wortebene über dem Originalscan | Benutzerzugang, Volltextsuche, Zitierung |
| Reiner Text | UTF-8-Text, eine Datei pro Seite | Volltextindizierung, NLP-Pipelines, Korpusaufbau |
Modelltraining
Benutzerdefinierte Erkennungsmodelle auf eigenen Dokumenten trainieren. Das gesamte Training läuft lokal auf Ihrer GPU – keine Daten verlassen Ihre Infrastruktur.
- Ground Truth vorbereiten
Transkribieren Sie eine Auswahl Ihrer Dokumente – in der Regel 50–100 Seiten für das Fine-Tuning eines bestehenden Basismodells. Das Web-Dashboard enthält Ground-Truth-Bearbeitungswerkzeuge.
- Trainieren
Wählen Sie ein Basismodell und starten Sie das Training auf Ihrer GPU. Die Trainingszeit beträgt in der Regel 2–6 Stunden für einen Fine-Tuning-Lauf, abhängig von Datensatzgröße und Hardware.
- Auswerten
Das System berichtet die CER (Zeichenfehlerrate) auf einem zurückgehaltenen Validierungsset. Mit dem Basismodell vergleichen, um die Verbesserung zu messen.
- Deployen
Das trainierte Modell in Ihre lokale Modellregistrierung veröffentlichen. Es steht sofort für Erkennungsaufträge zur Verfügung – kein Neustart nötig.
Erweiterbare Architektur
Die Verarbeitungspipeline ist als Framework konzipiert, nicht als feste Abfolge. Neue Modellarchitekturen und Erkennungsaufgaben können im Laufe der Zeit integriert werden, sobald sie verfügbar werden – das System ist nicht auf den aktuellen Satz von HTR-, Layout-, Tabellen- und Feldmodellen beschränkt. Die containerisierte Architektur ermöglicht das Hinzufügen neuer Verarbeitungsstufen ohne Unterbrechung bestehender Workflows.
Architektur
Workstation
Einzelserver-Deployment mit Docker Compose. Alle Dienste laufen auf einem Rechner – Web-Dashboard, Erkennungsmotor, Training, Datenbank und lokaler Speicher. Nachmittags eingerichtet. Kein Kubernetes, keine Cluster-Infrastruktur. Modelle bleiben über Aufträge hinweg auf der GPU geladen, was Sub-Sekunden-Start für nachfolgende Seiten ermöglicht.
Enterprise (Kubernetes / OpenShift)
Kubernetes-natives Deployment mit horizontaler Skalierung. Jede Pipeline-Stufe skaliert unabhängig via HPA. GPU-Inferenz verwendet eine Server/Client-Architektur – eine einzelne GPU bedient mehrere Client-Watcher. Unterstützt vollständige NVIDIA-GPUs und MIG-Partitionen. Event-Koordination via Redis Pub/Sub. Speicherung via S3-kompatibler Objektspeicher (MinIO, Ceph, AWS S3). Deployment via Helm mit empfohlenem ArgoCD für GitOps. Rolling Updates ohne Ausfallzeit.
Systemanforderungen
Workstation
| Komponente | Minimum | Empfohlen |
|---|---|---|
| OS | Ubuntu 22.04+ / Windows Server 2022 | Ubuntu 22.04 LTS |
| CPU | 8 cores | 16+ cores |
| RAM | 32 GB | 64 GB |
| GPU | NVIDIA, 12 GB VRAM (RTX 3060+) | RTX 4090 / A6000 (24 GB VRAM) |
| Storage | 500 GB SSD | 1 TB+ NVMe |
| NVIDIA Driver | 565.57+ | Latest stable |
| CUDA | 12.4+ | 12.4+ |
| Docker | 24.0+ | Latest stable |
Enterprise
| Komponente | Anforderung |
|---|---|
| Orchestration | Kubernetes 1.27+ or OpenShift 4.x |
| GPU Operator | NVIDIA GPU Operator with MIG support |
| Storage | S3-compatible object storage (MinIO, Ceph, AWS S3) |
| GPU per worker | NVIDIA A100 or H100 recommended (MIG partitioning supported) |
| Event coordination | Redis (pub/sub for job coordination) |
| Monitoring | Prometheus + Grafana (metrics exported natively) |
| Deployment | Helm chart provided, ArgoCD recommended |
| NVIDIA Driver | 565.57+ / CUDA 12.4+ |
Leistung
Durchsatz-Benchmarks bei ~20 Zeilen pro Seite. Tatsächliche Ergebnisse hängen von der Dokumentkomplexität, den Seitenabmessungen und den Zeilen pro Seite ab. Seiten mit wenig Text laufen schneller, dichte Seiten langsamer – annähernd linear mit der Zeilenanzahl.
Workstation (einzelne GPU, RTX 3090)
| Workload | Standard HTR | Super Models |
|---|---|---|
| Single page (cold start) | ~10 s | ~13 s |
| Per page (warm, amortized) | ~3 s | ~5 s |
| Archive box (100 pages) | ~5 min | ~8 min |
| Archival run (500 pages) | ~25 min | ~42 min |
| Daily throughput (24 h) | ~27,000 pages | ~16,500 pages |
Enterprise (pro A100)
| Workload | Standard HTR | Super Models |
|---|---|---|
| Per page (warm, amortized) | ~2 s | ~4 s |
| Archive box (100 pages) | ~3.5 min | ~7 min |
| Archival run (500 pages) | ~17 min | ~33 min |
| Daily per GPU (24 h) | ~42,000 pages | ~21,000 pages |
| 8× A100 cluster (24 h) | ~300,000 pages | ~168,000 pages |
Cold-Start erhöht die Zeit um 5–10 Sekunden für das Laden des Modells. Nachfolgende Seiten im selben Stapel verwenden den oben genannten Warm-Durchsatz. Durchsatz skaliert linear mit der GPU-Anzahl – Inferenz-Server-Replicas mit dedizierten GPUs oder MIG-Partitionen hinzufügen, um die Kapazität zu multiplizieren.
API & Integration
Transkribus On-Prem bietet Integrationspunkte, um die Erkennung in Ihre bestehenden Workflows, Archivierungssysteme und nachgelagerten Pipelines einzubetten.
REST API
Aufträge einreichen, Status abfragen und Ergebnisse per HTTP abrufen. OpenAPI-Spezifikation unter /openapi.json und /openapi.yaml bereitgestellt – Clients in jeder Sprache generieren. Verfügbar in der Enterprise-Edition.
S3-Einspeisung
Dateien in einen bestimmten S3/MinIO-Bucket ablegen und Jobs starten automatisch. Ergebnisse erscheinen als PageXML, ALTO, TXT oder PDF zurück in S3. Enterprise-Edition.
Streaming-API
Offene Live-Streaming-Schnittstelle für Echtzeitergebnisse. Ergebnisse fließen zeilenweise aus, während Seiten verarbeitet werden – in eigene Dashboards oder nachgelagerte Workflows einbetten.
Transkribus-Kompatibilität
Dateinamen, Metadaten und PageXML-Ausgabe lassen sich verlustfrei zurück in Transkribus importieren. Kompatibel mit bestehenden Transkribus-Integrationen – keine Workflow-Umschreibungen nötig.