Baidu lance Unlimited OCR, un modèle 3B qui stabilise le cache KV pour l'analyse de longs documents

L'équipe Qianfan de Baidu publie Qianfan-OCR : un modèle unifié d'intelligence documentaire à 4 milliards de paramètres

L'équipe Qianfan de Baidu vient de dévoiler Qianfan-OCR, un modèle de 4 milliards de paramètres capable de traiter intégralement la reconnaissance documentaire, parsing, analyse de mise en page et compréhension, au sein d'une architecture vision-langage unifiée. Contrairement aux pipelines OCR traditionnels qui enchaînent des modules séparés, le modèle effectue une conversion directe image-vers-Markdown et prend en charge des tâches pilotées par prompts, comme l'extraction de tableaux ou les questions-réponses sur documents. L'enjeu est considérable pour le secteur de l'intelligence documentaire, où les approches multi-étapes souffrent d'un défaut structurel : chaque étape introduit des pertes d'information, en particulier le contexte visuel spatial. Les systèmes en deux temps, extraction de texte puis LLM, échouent notamment sur les tâches nécessitant un raisonnement spatial : tous les systèmes pipeline testés ont obtenu un score de 0,0 sur les benchmarks CharXiv, incapables d'interpréter des graphiques dont les axes et positions de données ont été effacés lors de l'extraction. Sur le plan technique, Qianfan-OCR s'appuie sur un encodeur visuel Qianfan-ViT acceptant des images jusqu'en 4K (jusqu'à 4 096 tokens visuels par image), un adaptateur cross-modal léger, et le modèle de langage Qwen3-4B avec une fenêtre de contexte native de 32 000 tokens. Sa fonctionnalité phare, le mécanisme "Layout-as-Thought", déclenche une phase de réflexion structurée via des tokens `` pour reconstruire explicitement la mise en page avant de générer la réponse finale. Les résultats sont probants : 93,12 sur OmniDocBench v1.5 (devant DeepSeek-OCR-v2 à 91,09 et Gemini-3 Pro à 90,33), 880 sur OCRBench (premier toutes catégories), et une moyenne de 87,9 en extraction d'informations clés, surpassant des modèles bien plus grands comme Qwen3-VL-235B (84,2) ou Gemini-3.1-Pro (79,2). Côté déploiement, le modèle tourne sur un seul GPU NVIDIA A100 et atteint 1,024 pages par seconde avec quantification W8A8 (AWQ), soit un gain de vitesse de 2x par rapport à la baseline float16 sans perte significative de précision. Son architecture entièrement GPU-centrique élimine les goulots d'étranglement CPU propres aux pipelines hybrides, ce qui le rend particulièrement adapté à des inférences en large volume. Le modèle et le code sont disponibles en accès ouvert sur HuggingFace et arXiv.

Pipeline complet d'OCR de bout en bout avec Unlimited-OCR de Baidu pour images haute résolution et PDF multipages

Un tutoriel détaille la construction d'un pipeline complet d'OCR de bout en bout à partir du modèle Unlimited-OCR de Baidu, conçu pour traiter des images de documents haute résolution ainsi que des PDF multi-pages. La démarche configure d'abord un environnement GPU sous Google Colab, installe les dépendances nécessaires (transformers 4.57.1, Pillow, PyMuPDF, accelerate, entre autres) puis charge un modèle vision-langage de 3 milliards de paramètres depuis Hugging Face, avec sélection automatique du format bfloat16 ou float16 selon le matériel disponible, pour un poids d'environ 6 Go en BF16. Le tutoriel génère ensuite des documents d'exemple structurés, imitant des rapports trimestriels avec titres, paragraphes et tableaux de données financières régionales, afin de tester le modèle dans des conditions proches du réel. Deux modes d'inférence sont comparés pour l'OCR sur page unique : le mode Gundam, qui découpe l'image en tuiles pour une analyse plus fine, et le mode Base, plus rapide mais moins détaillé. Le pipeline est ensuite étendu au traitement de PDF multi-pages grâce à la bibliothèque PyMuPDF et à la fonction infer_multi(), qui gère le contenu réparti sur plusieurs pages en conservant des paramètres de génération à long contexte et des contrôles de répétition. L'intérêt de cette approche réside dans sa capacité à traiter des mises en page denses, des tableaux et du texte continu en une seule passe de décodage, sans recourir à une étape séparée d'analyse de mise en page comme le font les pipelines OCR classiques. Pour les entreprises et développeurs qui doivent extraire des données structurées de documents administratifs, financiers ou de rapports scannés, cela simplifie considérablement l'architecture technique tout en réduisant la latence de traitement. La possibilité de traiter des PDF entiers, page par page, avec une sortie textuelle cohérente ouvre la voie à des applications d'automatisation documentaire plus robustes, notamment pour les secteurs juridique, comptable ou administratif où la fidélité aux tableaux et aux chiffres est critique. Ce tutoriel s'inscrit dans une tendance plus large de remplacement des pipelines OCR traditionnels, souvent composés de plusieurs modules spécialisés, par des modèles vision-langage uniques capables de comprendre directement la structure visuelle d'un document. Baidu rejoint ainsi d'autres acteurs qui misent sur des modèles de quelques milliards de paramètres, suffisamment légers pour tourner sur un GPU grand public tout en conservant des performances élevées sur des tâches complexes. La reproductibilité du pipeline via Colab et son intégration à l'écosystème Hugging Face facilitent l'adoption par les développeurs, qui peuvent adapter rapidement l'outil à leurs propres corpus de documents professionnels.

Zhipu AI présente GLM-OCR : un modèle multimodal OCR de 0,9 milliard pour le traitement de documents et l'extraction d'informations clés (KIE)

Zhipu AI et l'université Tsinghua présentent GLM-OCR, un modèle multimodal compact de 0,9 milliard de paramètres conçu pour la reconnaissance de documents complexes et l'extraction d'informations structurées. Face aux limites des systèmes OCR traditionnels, efficaces sur du texte simple mais en difficulté dès qu'apparaissent tableaux, formules mathématiques, blocs de code ou sceaux, ce modèle propose une alternative légère aux grands modèles de vision-langage, trop coûteux pour un déploiement en production ou en environnement edge. L'enjeu dépasse la simple reconnaissance de caractères : dans l'industrie, les documents réels mêlent mises en page complexes, données structurées et champs à extraire automatiquement. Les grands modèles multimodaux actuels améliorent la compréhension documentaire, mais leur taille et leur mode de décodage autorégressif classique les rendent prohibitifs à grande échelle. GLM-OCR s'impose donc comme une réponse d'ingénierie pragmatique, pensée dès le départ pour des contraintes de déploiement réelles plutôt qu'adaptée à l'OCR en second plan. Architecturalement, le modèle combine un encodeur visuel CogViT de 0,4 milliard de paramètres, un connecteur cross-modal léger et un décodeur de langage GLM de 0,5 milliard de paramètres. Sa principale innovation technique est l'adoption de la prédiction multi-tokens (MTP) : au lieu de prédire un token à la fois, le modèle est entraîné à en prédire 10 par étape, et génère en pratique 5,2 tokens par étape à l'inférence, soit un gain de débit d'environ 50%. Le pipeline repose sur deux étages distincts : une analyse de mise en page via PP-DocLayout-V3, puis une reconnaissance parallèle des régions détectées. Pour le parsing, les sorties sont en Markdown ou JSON ; pour l'extraction d'informations clés (KIE), l'image complète est soumise au modèle avec un prompt de tâche, produisant directement un JSON structuré. L'entraînement suit quatre étapes successives, allant du préentraînement vision-langage jusqu'à un affinage par apprentissage par renforcement via GRPO. Les récompenses sont adaptées à chaque sous-tâche : distance d'édition normalisée pour la reconnaissance de texte, score CDM pour les formules, score TEDS pour les tableaux, et F1 au niveau des champs pour la KIE. Cette approche modulaire et spécialisée distingue GLM-OCR des modèles généralistes et le positionne comme un outil de production sérieux pour les entreprises traitant de grands volumes de documents.

Fireworks AI lance Nexus, une couche de routage qui bascule le code de routine vers des modèles ouverts pour réduire les coûts

Fireworks AI a lancé Fireworks Nexus, une plateforme de gestion et de routage d'intelligence artificielle destinée aux équipes d'ingénierie, qui relie les outils de développement déjà utilisés par les développeurs à une couche gérée de modèles à poids ouverts. L'initiative répond à un problème documenté par Forbes: Uber a épuisé tout son budget IA 2026 en seulement quatre mois, tandis que Claude Code comptait environ 5 000 ingénieurs après son déploiement de décembre, l'adoption des usages agentiques passant d'un tiers à plus de quatre cinquièmes des ingénieurs en deux mois. Nexus repose sur trois piliers: des contrôles d'entreprise avec budgets, suivi du retour sur investissement et hébergement aux États-Unis sans rétention de données sur 20 centres de données mondiaux; FireConnect, une installation en une ligne sous licence Apache 2.0 qui connecte des outils comme Claude Code, Codex ou OpenCode sans modification, via des API compatibles Anthropic et OpenAI; et un routeur intelligent qui évalue la difficulté de chaque requête pour envoyer les tâches routinières vers un modèle ouvert économique et les tâches complexes vers le fournisseur habituel, via la clé API du client jamais stockée côté serveur. Fireworks annonce une réduction de coûts de 3 à 5 fois grâce à ce mécanisme, actuellement en préversion et routant entre Claude Opus 5 et GLM 5.2, ou entre Kimi K3 et GLM 5.2 pour une configuration entièrement ouverte. Cette approche s'attaque directement à un enjeu financier critique pour les entreprises qui généralisent l'usage d'assistants de code: la facturation au tarif des modèles de pointe pour des tâches qui ne le justifient pas. Des tests menés avec Notion et Doximity montrent une baisse d'un tiers du coût par pull request fusionnée et un tarif de jetons environ quatre fois inférieur à celui des grands laboratoires fermés, même si ces chiffres proviennent du fournisseur lui-même. Deux évaluations indépendantes citées par Fireworks apportent des preuves plus solides. Faros AI, sur 211 tâches réelles réparties sur 12 dépôts, a mesuré un score de 0,568 pour Claude Code couplé à GLM 5.2 contre 0,521 pour Opus 4.8, à un coût de 0,92 dollar contre 1,76 dollar par tâche, avec des taux de cache comparables écartant tout biais lié à la mise en cache. L'étude conjointe d'Arize et Fireworks, portant sur 2 400 exécutions couvrant 10 modèles et 40 tâches Terminal Bench pour 626 dollars de dépenses API, confirme la logique du routage. Sur les tâches faciles, la prime des modèles de pointe n'apporte rien: Kimi K2.6 réussit 73% des cas contre 69% pour GPT 5.5. Sur les tâches difficiles en revanche, seuls les modèles les plus performants s'en sortent, GPT 5.5 atteignant 51% de réussite contre 32% pour Kimi K3. Une stratégie d'escalade progressive entre modèles a atteint 0,525 dollar par tâche réussie en résolvant 32,3 tâches sur 40, battant GPT 5.5 utilisé seul (0,636 dollar, 25 tâches) et l'escalade brute à travers les dix modèles, plus coûteuse à 1,319 dollar. Ces résultats alimentent un débat plus large sur la manière dont les entreprises doivent arbitrer entre performance et coût dans le déploiement massif d'agents de codage, alors que la pression budgétaire s'intensifie face à l'explosion des usages.

💬 Le vrai chiffre qui compte ici, c'est pas le -3x sur les coûts, c'est Uber qui a cramé tout son budget IA 2026 en quatre mois: à ce rythme personne ne peut se permettre de payer le tarif Opus pour corriger une virgule. Router les tâches routinières vers un modèle ouvert et garder les gros modèles pour les cas chauds, c'est exactement ce qu'on attendait depuis que les assistants de code se sont généralisés en boîte, et les tests d'Arize le confirment noir sur blanc. Le signal de fond: le coût par tâche devient le vrai critère d'arbitrage des entreprises sur l'IA de code, plus la marque du modèle.