Et si vous pouviez extraire du texte de PDF complexes, de tableaux et de formules avec un modèle plus petit que la plupart des applications pour smartphone ? GLM-OCR réalise une compréhension de documents de pointe avec seulement 0,9 milliard de paramètres. Il est suffisamment léger pour fonctionner sur du matériel modeste et suffisamment précis pour se classer en tête du classement OmniDocBench V1.5 avec 94,62 points.
Les outils OCR traditionnels peinent avec la structure des documents. Ils perdent la mise en forme des tableaux, lisent mal les formules mathématiques et échouent sur les mises en page multi-colonnes. Les API cloud résolvent ces problèmes mais facturent par requête et envoient vos documents sensibles à des serveurs tiers. GLM-OCR élimine ces deux problèmes : il gère les mises en page complexes localement avec une précision de qualité production, le tout sous une licence MIT qui autorise l'utilisation commerciale sans frais de licence.
Comprendre l'architecture de GLM-OCR
GLM-OCR utilise une architecture encodeur-décodeur à trois composants optimisée pour la compréhension de documents. L'encodeur visuel CogViT traite les images de documents en utilisant des poids pré-entraînés sur des milliards de paires image-texte. Il extrait les caractéristiques visuelles tout en préservant les relations spatiales essentielles à la compréhension de la mise en page.
Un connecteur cross-modal léger se trouve entre l'encodeur et le décodeur. Ce composant sous-échantillonne efficacement les jetons visuels, réduisant la charge de calcul sans sacrifier la précision. Le décodeur de langage GLM-0.5B génère ensuite une sortie de texte structurée, gérant tout, des paragraphes simples aux tableaux imbriqués complexes.
Le modèle utilise un pipeline d'inférence en deux étapes. Premièrement, PP-DocLayout-V3 analyse la structure du document, identifiant les en-têtes, les paragraphes, les tableaux et les figures. Deuxièmement, la reconnaissance parallèle traite chaque région simultanément. Cette approche maintient la hiérarchie des documents là où l'OCR traditionnelle aplatit tout en texte non structuré.
Les innovations en matière de formation améliorent encore les performances. La perte de prédiction multi-jetons améliore l'efficacité de la formation en prédisant plusieurs jetons simultanément. L'apprentissage par renforcement stable à tâche complète améliore la généralisation à travers divers types de documents. Le résultat : 96,5 % de précision sur la reconnaissance de formules, 86,0 % sur la reconnaissance de tableaux et des performances de pointe sur les tâches d'extraction d'informations.
Lors de l'inférence, GLM-OCR traite 1,86 pages PDF par seconde sur un seul GPU, ce qui est significativement plus rapide que les modèles comparables. Le nombre de 0,9 milliard de paramètres signifie que vous déployez sur du matériel grand public plutôt que sur des clusters d'entreprise.
Spécifications du modèle
GLM-OCR gère des documents jusqu'à une résolution de 8K (7680×4320 pixels). Il reconnaît 8 langues, dont l'anglais, le chinois, le japonais et le coréen. Le modèle traite à la fois les images raster (PNG, JPEG) et les entrées vectorielles. L'inférence typique consomme 4 à 6 Go de VRAM en précision FP16, s'adaptant aux GPU grand public comme la RTX 3060 ou aux instances cloud comme AWS g4dn.xlarge.
> | Matériel | VRAM requise | Pages/sec | Cas d'utilisation |
--------------------------------------------------------------------
> | RTX 3060 | 4-6GB | ~1.5 | Développement |
> | RTX 4090 | 4-6GB | ~2.5 | Production |
> | AWS g4dn.xlarge | 16GB | ~1.8 | Déploiement Cloud|
> | 4x A100 (TPS=4) | 80GB | ~7.0 | Entreprise |Options de déploiement local
GLM-OCR prend en charge quatre méthodes de déploiement en fonction de votre infrastructure et de vos exigences de performance. Chacune utilise les mêmes poids de modèle sous-jacents de Hugging Face mais s'optimise pour différents scénarios.
- vLLM offre le meilleur équilibre entre débit et latence pour les charges de travail de production. Il implémente PagedAttention pour une gestion efficace de la mémoire et prend en charge le batching continu pour les scénarios à haute concurrence.
- SGLang offre des performances maximales grâce à son optimisation d'exécution. Il excelle dans le décodage spéculatif et la génération structurée, ce qui le rend idéal lorsque vous avez besoin de l'inférence la plus rapide possible.
- Ollama offre la configuration la plus simple. Une seule commande télécharge et exécute le modèle localement — pas de dépendances Python ni de fichiers de configuration. Parfait pour le prototypage et l'utilisation personnelle.
- Transformers permet une intégration Python directe. Utilisez-le pour le développement, le débogage ou lorsque vous avez besoin d'un contrôle précis sur le pipeline d'inférence.
Toutes les méthodes nécessitent les poids GLM-OCR de Hugging Face (zai-org/GLM-OCR). Le modèle fonctionne sur les GPU NVIDIA avec prise en charge CUDA. L'inférence CPU seule fonctionne mais à une vitesse significativement réduite.
Configuration de vLLM pour la production
vLLM fournit une inférence prête pour la production avec des points de terminaison d'API compatibles OpenAI. Cela vous permet d'intégrer GLM-OCR dans les applications existantes qui utilisent actuellement les modèles de vision d'OpenAI.
Installation
Installez vLLM avec le support CUDA :
pip install -U vllm --extra-index-url https://wheels.vllm.ai/nightly
Pour un déploiement conteneurisé, utilisez l'image Docker officielle :
docker pull vllm/vllm-openai:nightly
Installez les Transformers compatibles — vLLM nécessite la dernière version de développement pour la prise en charge de GLM-OCR :
pip install git+https://github.com/huggingface/transformers.git
Lancement du service
Démarrez le serveur vLLM avec GLM-OCR :
vllm serve zai-org/GLM-OCR \
--allowed-local-media-path / \
--port 8080 \
--speculative-config '{"method": "mtp", "num_speculative_tokens": 1}'
L'indicateur --allowed-local-media-path permet au modèle d'accéder aux fichiers image locaux. Définissez-le sur votre répertoire de documents ou sur / pour un accès illimité (à utiliser avec prudence en production).
La --speculative-config active la prédiction multi-jetons, une fonctionnalité de GLM-OCR qui accélère l'inférence en prédisant plusieurs jetons simultanément.
Intégration client
Une fois lancé, interagissez avec GLM-OCR via des requêtes HTTP standard :
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"}
]
}
]
}'
Le format de réponse compatible OpenAI signifie que les SDK existants fonctionnent sans modification. Pointez votre client OpenAI vers http://localhost:8080 et utilisez zai-org/GLM-OCR comme nom de modèle.
Configuration de production
Pour les déploiements à haut débit, ajoutez le parallélisme tensoriel sur plusieurs GPU :
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
Ajustez --tensor-parallel-size pour correspondre à votre nombre de GPU. Surveillez l'utilisation du GPU et augmentez la taille des lots pour maximiser le débit.
Surveillance et mise à l'échelle
Suivez les performances de vLLM via son point de terminaison de métriques intégré à /metrics. Les données compatibles Prometheus incluent la latence des requêtes, la profondeur de la file d'attente et l'utilisation du GPU. Configurez des alertes lorsque la profondeur de la file d'attente dépasse 10 requêtes ou que la mémoire GPU atteint 90 %. Pour la mise à l'échelle horizontale, déployez plusieurs instances vLLM derrière un équilibreur de charge avec des sessions persistantes pour maintenir le contexte entre les requêtes.
Envisagez d'utiliser les fonctionnalités de surveillance d'API d'Apidog pour suivre les métriques de production parallèlement aux performances de votre modèle.
Inférence haute performance SGLang
SGLang offre des optimisations d'exécution avancées pour une vitesse d'inférence maximale. Il excelle dans le décodage spéculatif et la génération structurée, ce qui le rend idéal pour les applications sensibles à la latence.
Installation
Installez SGLang via Docker (recommandé pour l'isolation des dépendances) :
docker pull lmsysorg/sglang:dev
Ou installez depuis la source :
pip install git+https://github.com/sgl-project/sglang.git#subdirectory=python
Installez les Transformers compatibles :
pip install git+https://github.com/huggingface/transformers.git
Lancement du service
Démarrez SGLang avec un décodage spéculatif optimisé :
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
Les paramètres de décodage spéculatif accélèrent l'inférence en rédigeant plusieurs jetons simultanément et en les vérifiant en parallèle. Ajustez --speculative-num-steps en fonction de votre matériel — des valeurs plus élevées augmentent la vitesse mais nécessitent plus de mémoire.
Sortie structurée
La génération structurée de SGLang garantit que GLM-OCR produit du JSON valide ou d'autres schémas :
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"])
Cela garantit une sortie lisible par machine sans post-traitement ni logique de réessai. Pour les points de terminaison d'API qui servent des réponses structurées, la validation de schéma d'Apidog peut vérifier automatiquement que vos formats de sortie correspondent aux structures JSON attendues.
Quand choisir SGLang plutôt que vLLM
Choisissez SGLang lorsque vous avez besoin de sorties structurées ou de décodage spéculatif. Sa génération contrainte par expressions régulières garantit des schémas JSON valides, éliminant la logique de réessai. L'algorithme spéculatif accélère la génération de jetons de 30 à 40 % sur les GPU avec une mémoire suffisante.
> | Caractéristique | vLLM | SGLang |
---------------------------------------------------------------
> | Débit | Élevé | Très Élevé |
> | Latence | Bonne | Excellente |
> | Compatible OpenAI | Oui | Non |
> | Sortie structurée | Manuelle | Intégrée |
> | Support communautaire | Excellent | En croissance |
> | Complexité d'installation | Moyenne | Élevée |
> | Idéal pour | API de production | Applications critiques en vitesse |Pour l'OCR standard sans exigences de latence strictes, vLLM offre des performances suffisantes avec une configuration plus simple et un meilleur support communautaire.
Intégration directe de Transformers
Pour le développement, le débogage ou les pipelines personnalisés, utilisez directement la bibliothèque Transformers. Cela offre une flexibilité maximale au détriment d'un débit inférieur par rapport à vLLM ou SGLang.
Installation
Installez la dernière version de Transformers depuis la source :
pip install git+https://github.com/huggingface/transformers.git
Inférence de base
Chargez et exécutez GLM-OCR en Python :
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)
Le device_map="auto" distribue automatiquement les couches du modèle sur les GPU disponibles. Pour un déploiement sur un seul GPU, cela charge le modèle complet sur un appareil. Pour l'inférence uniquement sur CPU, changez en device_map="cpu" — attendez-vous à des performances significativement plus lentes.
Traitement par lots
Traitez plusieurs documents efficacement :
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")
Lors du traitement de documents en production, la gestion des espaces de travail d'Apidog aide à organiser plusieurs points de terminaison de traitement de documents en groupes logiques, facilitant ainsi le test et la surveillance des différents flux de travail.
Optimisation de la mémoire
Pour les GPU avec une VRAM limitée, utilisez la quantification :
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",
)
La quantification sur 4 bits réduit l'utilisation de la mémoire de 75 % avec un impact minimal sur la précision pour les tâches de compréhension de documents.
Gestion des cas limites
Les documents avec beaucoup d'écriture manuscrite ou des angles d'inclinaison extrêmes réduisent la précision. Pré-traitez les images avec des algorithmes de redressement avant de les envoyer à GLM-OCR. Pour les PDF de plusieurs pages, extrayez les pages sous forme d'images séparées plutôt que de transmettre le fichier entier. Cela permet un traitement parallèle et simplifie la gestion des erreurs lorsque des pages individuelles échouent. Les documents filigranés déclenchent occasionnellement de faux positifs dans les régions de texte — expérimentez avec les ajustements de contraste si vous voyez une sortie brouillée dans des zones spécifiques.
Cas d'utilisation réels de GLM-OCR
GLM-OCR excelle dans plusieurs scénarios de production :
Traitement des factures
Les équipes financières extraient les articles, les dates et les totaux des factures numérisées. Le modèle maintient la structure des tableaux, garantissant un calcul précis des totaux sans révision manuelle. Traitez des milliers de factures par jour avec un déploiement local et sans frais d'API.
Documentation technique
Les équipes d'ingénierie convertissent les manuels et spécifications PDF en texte consultable. La reconnaissance des formules préserve les équations mathématiques, rendant le contenu technique lisible par machine. Idéal pour les projets de modernisation de documentation héritée.
Analyse de documents juridiques
Les professionnels du droit examinent les contrats et accords avec une OCR qui respecte la hiérarchie des documents. La gestion des mises en page multi-colonnes garantit que les paragraphes ne sont pas fusionnés incorrectement. L'approche axée sur la confidentialité maintient les données sensibles sur site.
Dossiers médicaux
Les cabinets médicaux numérisent les formulaires de patients et les ordonnances. Reconnaît 8 langues, utile pour les environnements de soins de santé multilingues. Le déploiement local répond aux exigences de conformité HIPAA en gardant les données en interne.
Conclusion
GLM-OCR offre une compréhension de documents de qualité production dans un package de 0,9 milliard de paramètres. Vous le déployez localement, maintenez la confidentialité des données et atteignez des débits qui rivalisent avec les API cloud — le tout sans tarification par requête. L'architecture gère les mises en page complexes, les tableaux et les formules que l'OCR traditionnelle manque, tandis que la licence MIT permet une utilisation commerciale illimitée.
Choisissez vLLM pour les déploiements de production nécessitant un débit élevé et une compatibilité OpenAI. Utilisez SGLang lorsque la vitesse d'inférence maximale est importante. Sélectionnez Transformers pour le développement et les pipelines personnalisés. Chaque option exécute le même modèle sous-jacent, vous permettant ainsi de changer de méthode de déploiement sans réentraînement ni réajustement.
Lors de la création de pipelines de traitement de documents — qu'il s'agisse d'extraire des données de factures, d'analyser de la documentation technique ou d'automatiser le traitement de formulaires — simplifiez vos tests d'API avec Apidog. Il fournit une construction visuelle des requêtes, une génération de documentation automatisée et des outils de débogage collaboratifs qui complètent votre flux de travail de déploiement GLM-OCR.