GLM-OCR bereitstellen: Umfassende Anleitung für Dokumentenanalyse

Ashley Goolam

Ashley Goolam

5 February 2026

GLM-OCR bereitstellen: Umfassende Anleitung für Dokumentenanalyse

Was wäre, wenn Sie Text aus komplexen PDFs, Tabellen und Formeln mit einem Modell extrahieren könnten, das kleiner ist als die meisten Smartphone-Apps? GLM-OCR erreicht mit nur 0,9 Milliarden Parametern ein hochmodernes Dokumentenverständnis. Es ist leicht genug, um auf bescheidener Hardware zu laufen, und dennoch präzise genug, um die OmniDocBench V1.5-Bestenliste mit 94,62 Punkten anzuführen.

Herkömmliche OCR-Tools kämpfen mit der Dokumentstruktur. Sie verlieren Tabellenformatierungen, lesen mathematische Formeln falsch und scheitern bei mehrspaltigen Layouts. Cloud-APIs lösen diese Probleme, berechnen jedoch pro Anfrage und senden Ihre sensiblen Dokumente an Drittanbieter-Server. GLM-OCR eliminiert beide Probleme: Es verarbeitet komplexe Layouts lokal mit produktionsreifer Genauigkeit, alles unter einer MIT-Lizenz, die die kommerzielle Nutzung ohne Lizenzgebühren erlaubt.

💡
Beim Aufbau von Dokumentenverarbeitungspipelines, die zuverlässiges API-Testing erfordern – sei es das Extrahieren von Daten aus Rechnungen, das Parsen technischer Dokumentation oder das Automatisieren der Formularverarbeitung – optimiert Apidog den gesamten Workflow. Es bietet visuelle Anforderungserstellung, automatisierte Dokumentationsgenerierung und kollaborative Debugging-Tools, die nahtlos mit Ihrer GLM-OCR-Bereitstellung zusammenarbeiten.
button

Die GLM-OCR-Architektur verstehen

GLM-OCR verwendet eine dreiteilige Encoder-Decoder-Architektur, die für das Dokumentenverständnis optimiert ist. Der visuelle CogViT-Encoder verarbeitet Dokumentbilder unter Verwendung von Gewichten, die auf Milliarden von Bild-Text-Paaren vortrainiert wurden. Er extrahiert visuelle Merkmale und bewahrt dabei räumliche Beziehungen, die für das Verständnis des Layouts entscheidend sind.

Ein leichter kreuzmodaler Konnektor befindet sich zwischen Encoder und Decoder. Diese Komponente reduziert visuelle Token effizient, wodurch der Rechenaufwand gesenkt wird, ohne die Genauigkeit zu beeinträchtigen. Der GLM-0.5B Sprach-Decoder generiert dann strukturierte Textausgaben, die alles von einfachen Absätzen bis hin zu komplexen verschachtelten Tabellen verarbeiten können.

Das Modell verwendet eine zweistufige Inferenzpipeline. Zuerst analysiert PP-DocLayout-V3 die Dokumentstruktur – es identifiziert Überschriften, Absätze, Tabellen und Abbildungen. Zweitens verarbeitet die parallele Erkennung jede Region gleichzeitig. Dieser Ansatz bewahrt die Dokumenthierarchie, wo herkömmliche OCR alles in unstrukturierten Text umwandelt.

Trainingsinnovationen steigern die Leistung zusätzlich. Der Multi-Token-Vorhersageverlust verbessert die Trainingseffizienz, indem mehrere Token gleichzeitig vorhergesagt werden. Stabiles Reinforcement Learning für die gesamte Aufgabe verbessert die Generalisierung über verschiedene Dokumenttypen hinweg. Das Ergebnis: 96,5 % Genauigkeit bei der Formelerkennung, 86,0 % bei der Tabellenerkennung und eine führende Leistung bei Informationsextraktionsaufgaben.

Bei der Inferenz verarbeitet GLM-OCR 1,86 PDF-Seiten pro Sekunde auf einer einzelnen GPU – deutlich schneller als vergleichbare Modelle. Die Parameteranzahl von 0,9 Milliarden bedeutet, dass Sie auf Consumer-Hardware statt auf Enterprise-Clustern bereitstellen können.

GLM-OCR Modell

Modellspezifikationen

GLM-OCR verarbeitet Dokumente bis zu einer Auflösung von 8K (7680×4320 Pixel). Es erkennt 8 Sprachen, darunter Englisch, Chinesisch, Japanisch und Koreanisch. Das Modell verarbeitet sowohl Rasterbilder (PNG, JPEG) als auch Vektoreingaben. Die typische Inferenz verbraucht 4-6 GB VRAM bei FP16-Präzision und passt auf Consumer-GPUs wie die RTX 3060 oder Cloud-Instanzen wie AWS g4dn.xlarge.

> | Hardware        | Benötigter VRAM | Seiten/Sek. | Anwendungsfall   |
 --------------------------------------------------------------------
> | RTX 3060        | 4-6GB         | ~1.5        | Entwicklung      |
> | RTX 4090        | 4-6GB         | ~2.5        | Produktion       |
> | AWS g4dn.xlarge | 16GB          | ~1.8        | Cloud-Bereitstellung |
> | 4x A100 (TPS=4) | 80GB          | ~7.0        | Unternehmen      |

Lokale Bereitstellungsoptionen

GLM-OCR unterstützt vier Bereitstellungsmethoden, abhängig von Ihrer Infrastruktur und Leistungsanforderungen. Jede verwendet die gleichen zugrunde liegenden Modellgewichte von Hugging Face, ist aber für verschiedene Szenarien optimiert.

  1. vLLM bietet die beste Balance aus Durchsatz und Latenz für Produktions-Workloads. Es implementiert PagedAttention für effizientes Speichermanagement und unterstützt kontinuierliches Batching für Szenarien mit hoher Parallelität.
  2. SGLang bietet maximale Leistung durch seine Laufzeitoptimierung. Es zeichnet sich durch spekulatives Decoding und strukturierte Generierung aus und ist ideal, wenn Sie die schnellstmögliche Inferenz benötigen.
  3. Ollama bietet die einfachste Einrichtung. Ein Befehl lädt das Modell herunter und führt es lokal aus – keine Python-Abhängigkeiten oder Konfigurationsdateien. Perfekt für Prototyping und den persönlichen Gebrauch.
  4. Transformers ermöglicht die direkte Python-Integration. Verwenden Sie dies für die Entwicklung, das Debugging oder wenn Sie eine detaillierte Kontrolle über die Inferenzpipeline benötigen.

Alle Methoden erfordern die GLM-OCR-Gewichte von Hugging Face (zai-org/GLM-OCR). Das Modell läuft auf NVIDIA-GPUs mit CUDA-Unterstützung. Eine reine CPU-Inferenz funktioniert, jedoch mit deutlich reduzierter Geschwindigkeit.

vLLM für die Produktion einrichten

vLLM bietet produktionsreife Inferenz mit OpenAI-kompatiblen API-Endpunkten. Dies ermöglicht es Ihnen, GLM-OCR in bestehende Anwendungen zu integrieren, die derzeit die Vision-Modelle von OpenAI verwenden.

Installation

Installieren Sie vLLM mit CUDA-Unterstützung:

pip install -U vllm --extra-index-url https://wheels.vllm.ai/nightly

Für die containerisierte Bereitstellung verwenden Sie das offizielle Docker-Image:

docker pull vllm/vllm-openai:nightly

Installieren Sie kompatible Transformers – vLLM erfordert die neueste Entwicklungsversion für GLM-OCR-Unterstützung:

pip install git+https://github.com/huggingface/transformers.git

Dienst starten

Starten Sie den vLLM-Server mit GLM-OCR:

vllm serve zai-org/GLM-OCR \
  --allowed-local-media-path / \
  --port 8080 \
  --speculative-config '{"method": "mtp", "num_speculative_tokens": 1}'

Das Flag --allowed-local-media-path ermöglicht dem Modell den Zugriff auf lokale Bilddateien. Setzen Sie dies auf Ihr Dokumentenverzeichnis oder / für uneingeschränkten Zugriff (in der Produktion mit Vorsicht verwenden).

Die --speculative-config aktiviert die Multi-Token-Vorhersage, eine GLM-OCR-Funktion, die die Inferenz beschleunigt, indem mehrere Token gleichzeitig vorhergesagt werden.

Client-Integration

Nach dem Start können Sie mit GLM-OCR über Standard-HTTP-Anfragen interagieren:

curl --location --request POST 'http://localhost:8080/v1/chat/completions' \
  --header 'Content-Type: application/json' \
  --data-raw '{
    "model": "zai-org/GLM-OCR",
    "messages": [
      {
        "role": "user",
        "content": [
          {"type": "image_url", "image_url": {"url": "file:///path/to/document.png"}},
          {"type": "text", "text": "Extract all text from this document"}
        ]
      }
    ]
  }'

Das OpenAI-kompatible Antwortformat bedeutet, dass bestehende SDKs ohne Änderungen funktionieren. Richten Sie Ihren OpenAI-Client auf http://localhost:8080 und verwenden Sie zai-org/GLM-OCR als Modellnamen.

Produktionskonfiguration

Für Bereitstellungen mit hohem Durchsatz fügen Sie Tensor-Parallelität über mehrere GPUs hinzu:

vllm serve zai-org/GLM-OCR \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.95 \
  --max-model-len 8192 \
  --allowed-local-media-path / \
  --port 8080

Passen Sie --tensor-parallel-size an die Anzahl Ihrer GPUs an. Überwachen Sie die GPU-Auslastung und erhöhen Sie die Batch-Größen, um den Durchsatz zu maximieren.

Überwachung und Skalierung

Verfolgen Sie die vLLM-Leistung über den integrierten Metrik-Endpunkt unter /metrics. Prometheus-kompatible Daten umfassen Anfragelatenz, Warteschlangentiefe und GPU-Auslastung. Richten Sie Alarme ein, wenn die Warteschlangentiefe 10 Anfragen überschreitet oder der GPU-Speicher 90 % erreicht. Für die horizontale Skalierung implementieren Sie mehrere vLLM-Instanzen hinter einem Load Balancer mit Sticky Sessions, um den Kontext über Anfragen hinweg aufrechtzuerhalten.

Erwägen Sie die Verwendung der API-Überwachungsfunktionen von Apidog, um Produktionsmetriken zusammen mit Ihrer Modellleistung zu verfolgen.

SGLang Hochleistungs-Inferenz

SGLang bietet fortschrittliche Laufzeitoptimierungen für maximale Inferenzgeschwindigkeit. Es zeichnet sich durch spekulatives Decoding und strukturierte Generierung aus und ist daher ideal für latenzempfindliche Anwendungen.

Installation

Installieren Sie SGLang über Docker (empfohlen zur Abhängigkeitsisolierung):

docker pull lmsysorg/sglang:dev

Oder installieren Sie es aus dem Quellcode:

pip install git+https://github.com/sgl-project/sglang.git#subdirectory=python

Installieren Sie kompatible Transformers:

pip install git+https://github.com/huggingface/transformers.git

Dienst starten

Starten Sie SGLang mit optimiertem spekulativen Decoding:

python -m sglang.launch_server \
  --model zai-org/GLM-OCR \
  --port 8080 \
  --speculative-algorithm NEXTN \
  --speculative-num-steps 3 \
  --speculative-eagle-topk 1 \
  --speculative-num-draft-tokens 4

Die Parameter für das spekulative Decoding beschleunigen die Inferenz, indem sie mehrere Token gleichzeitig entwerfen und diese parallel verifizieren. Passen Sie --speculative-num-steps an Ihre Hardware an – höhere Werte erhöhen die Geschwindigkeit, erfordern aber mehr Speicher.

Strukturierte Ausgabe

Die strukturierte Generierung von SGLang stellt sicher, dass GLM-OCR gültiges JSON oder andere Schemata ausgibt:

import sglang as sgl

@sgl.function
def extract_invoice(s, image_path):
    s += sgl.user(sgl.image(image_path) + "Extract invoice data as JSON")
    s += sgl.assistant(sgl.gen("json_output", json_schema={
        "type": "object",
        "properties": {
            "invoice_number": {"type": "string"},
            "date": {"type": "string"},
            "total": {"type": "number"},
            "items": {
                "type": "array",
                "items": {
                    "type": "object",
                    "properties": {
                        "description": {"type": "string"},
                        "quantity": {"type": "integer"},
                        "price": {"type": "number"}
                    }
                }
            }
        }
    }))

result = extract_invoice.run(image_path="invoice.png")
print(result["json_output"])

Dies garantiert eine maschinenlesbare Ausgabe ohne Nachbearbeitung oder Wiederholungslogik. Für API-Endpunkte, die strukturierte Antworten liefern, kann die Schema-Validierung von Apidog automatisch überprüfen, ob Ihre Ausgabeformate den erwarteten JSON-Strukturen entsprechen.

Wann SGLang gegenüber vLLM wählen

Wählen Sie SGLang, wenn Sie strukturierte Ausgaben oder spekulatives Decoding benötigen. Seine regex-eingeschränkte Generierung garantiert gültige JSON-Schemas und eliminiert die Wiederholungslogik. Der spekulative Algorithmus beschleunigt die Token-Generierung auf GPUs mit ausreichend Speicher um 30-40 %.

> | Funktion          | vLLM            | SGLang              |
 ---------------------------------------------------------------
> | Durchsatz         | Hoch            | Sehr Hoch           |
> | Latenz            | Gut             | Exzellent           |
> | OpenAI-Kompatibel | Ja              | Nein                |
> | Strukturierte Ausgabe | Manuell       | Integriert          |
> | Community-Support | Exzellent       | Wachsend            |
> | Einrichtungs-Komplexität | Mittel   | Hoch                |
> | Ideal für         | Produktions-APIs | Geschwindigkeitskritische Apps |

Für Standard-OCR ohne strenge Latenzanforderungen bietet vLLM eine ausreichende Leistung mit einfacherer Konfiguration und besserem Community-Support.

Transformers Direkte Integration

Für Entwicklung, Debugging oder benutzerdefinierte Pipelines verwenden Sie die Transformers-Bibliothek direkt. Dies bietet maximale Flexibilität auf Kosten eines geringeren Durchsatzes im Vergleich zu vLLM oder SGLang.

Installation

Installieren Sie die neuesten Transformers aus dem Quellcode:

pip install git+https://github.com/huggingface/transformers.git

Grundlegende Inferenz

Laden Sie GLM-OCR in Python und führen Sie es aus:

from transformers import AutoProcessor, AutoModelForImageTextToText
import torch

MODEL_PATH = "zai-org/GLM-OCR"

# Prepare input
messages = [
    {
        "role": "user",
        "content": [
            {"type": "image", "url": "document.png"},
            {"type": "text", "text": "Text Recognition:"}
        ],
    }
]

# Load model and processor
processor = AutoProcessor.from_pretrained(MODEL_PATH)
model = AutoModelForImageTextToText.from_pretrained(
    MODEL_PATH,
    torch_dtype="auto",
    device_map="auto",
)

# Process input
inputs = processor.apply_chat_template(
    messages,
    tokenize=True,
    add_generation_prompt=True,
    return_dict=True,
    return_tensors="pt"
).to(model.device)

inputs.pop("token_type_ids", None)

# Generate output
generated_ids = model.generate(**inputs, max_new_tokens=8192)
output_text = processor.decode(
    generated_ids[0][inputs["input_ids"].shape[1]:],
    skip_special_tokens=False
)

print(output_text)

Das device_map="auto" verteilt Modellsichten automatisch auf verfügbare GPUs. Für die Bereitstellung auf einer einzelnen GPU lädt dies das vollständige Modell auf ein Gerät. Für eine reine CPU-Inferenz ändern Sie dies auf device_map="cpu" – rechnen Sie mit einer deutlich langsameren Leistung.

Stapelverarbeitung

Verarbeiten Sie mehrere Dokumente effizient:

import os
from pathlib import Path

def batch_process(directory, output_file):
    documents = list(Path(directory).glob("*.png")) + \
                list(Path(directory).glob("*.pdf"))
    
    results = []
    for doc_path in documents:
        # Convert PDF to images if needed
        if doc_path.suffix == ".pdf":
            images = convert_pdf_to_images(doc_path)
        else:
            images = [doc_path]
        
        for image in images:
            text = extract_text(image)  # Your extraction function
            results.append({
                "file": str(doc_path),
                "page": image.page_num if hasattr(image, 'page_num') else 1,
                "text": text
            })
    
    # Save results
    with open(output_file, 'w') as f:
        json.dump(results, f, indent=2)

# Usage
batch_process("./invoices/", "extracted_data.json")

Bei der Verarbeitung von Dokumenten in der Produktion hilft die Arbeitsbereichsverwaltung von Apidog dabei, mehrere Dokumentenverarbeitungs-Endpunkte in logische Gruppen zu organisieren, was das Testen und Überwachen verschiedener Workflows erleichtert.

Speicheroptimierung

Für GPUs mit begrenztem VRAM verwenden Sie Quantisierung:

from transformers import BitsAndBytesConfig

quantization_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_compute_dtype=torch.float16
)

model = AutoModelForImageTextToText.from_pretrained(
    MODEL_PATH,
    quantization_config=quantization_config,
    device_map="auto",
)

Die 4-Bit-Quantisierung reduziert den Speicherverbrauch um 75 % mit minimalen Auswirkungen auf die Genauigkeit bei Aufgaben des Dokumentenverständnisses.

Umgang mit Grenzbereichen

Dokumente mit starker Handschrift oder extremen Schräglagen reduzieren die Genauigkeit. Verarbeiten Sie Bilder mit Entzerrungsalgorithmen vor, bevor Sie sie an GLM-OCR senden. Bei mehrseitigen PDFs extrahieren Sie die Seiten als separate Bilder, anstatt die gesamte Datei zu übergeben. Dies ermöglicht die parallele Verarbeitung und vereinfacht die Fehlerbehandlung, wenn einzelne Seiten fehlschlagen. Wasserzeichen-Dokumente lösen gelegentlich Fehlalarme in Textbereichen aus – experimentieren Sie mit Kontrasteinstellungen, wenn Sie in bestimmten Bereichen eine unleserliche Ausgabe sehen.

Praxisbeispiele für GLM-OCR

GLM-OCR zeichnet sich in mehreren Produktionsszenarien aus:

Rechnungsverarbeitung

Finanzteams extrahieren Posten, Daten und Gesamtsummen aus gescannten Rechnungen. Das Modell bewahrt die Tabellenstruktur und gewährleistet eine genaue Berechnung der Gesamtsummen ohne manuelle Überprüfung. Verarbeiten Sie Tausende von Rechnungen pro Tag mit lokaler Bereitstellung und ohne API-Kosten.

Technische Dokumentation

Ingenieurteams wandeln PDF-Handbücher und Spezifikationen in durchsuchbaren Text um. Die Formelerkennung bewahrt mathematische Gleichungen und macht technische Inhalte maschinenlesbar. Ideal für Modernisierungsprojekte von Legacy-Dokumentationen.

GLM-OCR Beispiel

Analyse juristischer Dokumente

Juristen überprüfen Verträge und Vereinbarungen mit OCR, die die Dokumentenhierarchie respektiert. Die Verarbeitung mehrspaltiger Layouts stellt sicher, dass Absätze nicht falsch zusammengeführt werden. Ein datenschutzorientierter Ansatz hält sensible Daten vor Ort.

Gesundheitsakten

Arztpraxen digitalisieren Patientenformulare und Rezepte. Erkennt 8 Sprachen, nützlich für mehrsprachige Gesundheitsumgebungen. Die lokale Bereitstellung erfüllt die HIPAA-Konformitätsanforderungen, indem Daten intern gehalten werden.

Fazit

GLM-OCR bietet ein produktionsreifes Dokumentenverständnis in einem 0,9 Milliarden Parameter umfassenden Paket. Sie stellen es lokal bereit, wahren den Datenschutz und erreichen Durchsatzraten, die Cloud-APIs Konkurrenz machen – alles ohne Preise pro Anfrage. Die Architektur verarbeitet komplexe Layouts, Tabellen und Formeln, die herkömmliche OCR übersieht, während die MIT-Lizenz eine uneingeschränkte kommerzielle Nutzung erlaubt.

Wählen Sie vLLM für Produktionsbereitstellungen, die hohen Durchsatz und OpenAI-Kompatibilität erfordern. Verwenden Sie SGLang, wenn maximale Inferenzgeschwindigkeit wichtig ist. Wählen Sie Transformers für Entwicklung und benutzerdefinierte Pipelines. Jede Option verwendet dasselbe zugrunde liegende Modell, sodass Sie die Bereitstellungsmethoden wechseln können, ohne neu trainieren oder feinabstimmen zu müssen.

Beim Aufbau von Dokumentenverarbeitungspipelines – sei es das Extrahieren von Daten aus Rechnungen, das Parsen technischer Dokumentation oder das Automatisieren der Formularverarbeitung – optimieren Sie Ihr API-Testing mit Apidog. Es bietet visuelle Anforderungserstellung, automatisierte Dokumentationsgenerierung und kollaborative Debugging-Tools, die Ihren GLM-OCR-Bereitstellungs-Workflow ergänzen.

button

Praktizieren Sie API Design-First in Apidog

Entdecken Sie eine einfachere Möglichkeit, APIs zu erstellen und zu nutzen