Ce que fait le modèle

LightOnOCR-3 est un OCR de bout en bout : une image de page en entrée, du markdown en sortie, sans pipeline de détection séparé. Le 4 B passe sur l'architecture vision-langage Qwen3.5 ; le 0,8 B est affiné depuis Qwen3.5-0.8B-Base. Deux prompts seulement sont dans la distribution d'entraînement. Le prompt vide donne la transcription markdown. Le prompt grounding ajoute, devant chaque bloc, un label parmi 16 types (texte, titre, tableau, graphique, formule, etc.), un suffixe « + » pour les blocs qui continuent une colonne, et une boîte en coordonnées normalisées de 0 à 1000. Dans ce mode, les images reçoivent une courte description et les graphiques sont convertis en tableaux HTML de données. La fiche prévient que toute autre instruction est hors distribution, et que le modèle tourne avec le mode de réflexion désactivé.

Ce que la fiche annonce, et ce qu'il faut vérifier

Les scores du 4 B sont olmOCR-bench 86,3 (Arxiv Math 91,1, Old Scans Math 89,1) et ParseBench 75,1 en moyenne ; les autres colonnes ne sont pas lisibles dans le texte de la page, et aucun tableau comparatif avec d'autres OCR n'y figure. Ces chiffres sont auto-déclarés. Le 0,8 B n'a aucun score publié : il est présenté comme « rapide et efficace », sans mesure de débit chiffrée, ni pour lui ni pour le 4 B. Hugging Face affiche 5 B de paramètres pour le modèle nommé 4 B, et 0,9 B pour le 0,8 B, sans explication. Aucune langue n'est listée pour le 4 B ; les métadonnées du 0,8 B ne mentionnent que l'anglais. Pour un éditeur français, c'est le point à tester en premier. Le mode grounding coûte environ 25 % de tokens en plus (1 433 contre 1 158 par page en moyenne). La fiche référence 13 quantisations pour llama.cpp, Ollama, LM Studio et Jan, sans nommer le format. D'après la page de liste, le 4 B cumule 3,2 k téléchargements et 76 likes depuis le 6 octobre.

Face à Youtu-Parsing-Omni et TeleOCR

Les trois ne sont pas mesurés sur le même banc : olmOCR-bench d'un côté, OmniDocBench de l'autre. Ce que LightOn apporte, c'est la licence Apache 2.0 et une sortie markdown avec boîtes, plus simple à relire qu'un JSON complet ; ce que Tencent apporte, c'est la structure (OTSL, Mermaid) et l'audio. TeleOCR reste le plus petit des trois à proposer des GGUF.

Comment l'essayer

1. Sans rien installer : déposer un PDF ou une image sur le Space LightOnOCR-3-Demo et comparer les sorties des deux prompts.
2. En local : prendre une quantisation du 4 B dans LM Studio ou Ollama. Rendre les PDF à 400 DPI, côté le plus long à 2048 px, en gardant les proportions, comme le recommande la fiche.
3. Avec un GPU : vllm serve lightonai/LightOnOCR-3-4B --trust-remote-code, réflexion désactivée, puis envoyer l'image seule (prompt vide) ou avec grounding.
4. Constituer un lot de 20 pages en français (procédures scannées, tableaux à cellules fusionnées, en-têtes avec logos) et passer le même lot à Youtu-Parsing-Omni, vu le 12 octobre : compter les accents perdus, les cellules décalées et le temps par page.

À surveiller : un résultat chiffré en français, des quantisations pour le 0,8 B, et une reproduction indépendante du 86,3.

Ce que fait le modèle

Les outils de parsing documentaire produisent en général du Markdown. Youtu-Parsing-Omni renvoie du JSON : chaque élément de la page arrive avec son type, son ordre de lecture et sa boîte englobante sur une grille de 0 à 1 000. Les tableaux sont décrits en OTSL, un format compact convertible en HTML ; les formules en LaTeX ; les graphiques en Markdown ; les organigrammes en Mermaid. Pour l'audio et la vidéo, le même JSON contient la transcription et des horodatages au format HH:MM:SS.

Le modèle repose sur un encodeur unique, Youtu-Omni-Encoder, et un décodeur Youtu-LLM. La fiche décrit trois étapes de post-entraînement : affinage supervisé, apprentissage par renforcement guidé par le schéma de sortie, puis distillation. Huit tâches sont exposées par un paramètre --task : document, image naturelle, graphique, organigramme, figure géométrique, audio, vidéo naturelle, vidéo riche en texte.

Ce que la fiche annonce, et ce qu'il faut vérifier

Sur OmniDocBench v1.6, la fiche donne 96,96 au global, avec un TEDS tableaux de 96,79 et une distance d'édition texte de 0,027. Dans le même tableau, PaddleOCR-VL-1.6 (0,9 B) obtient 96,34, MinerU2.5-Pro (1,2 B) 95,75 et Gemini-3-Pro 92,91. À titre de comparaison, TeleOCR (1,2 B) annonce de son côté 96,87 : un écart de 0,1 point, chacun mesuré par ses auteurs. Sur OmniParsingBench, le benchmark multimodal créé pour l'occasion, le modèle fait 75,08, derrière Gemini-3-Pro (77,44), et se présente comme le meilleur à poids ouverts. Sur la chimie (ChemOCR) et les partitions musicales, il fait jeu égal ou légèrement moins bien que les spécialistes.

Plusieurs réserves. Le rapport technique est annoncé « à venir » dans l'en-tête alors que la rubrique actualités le dit publié ; le code d'évaluation est marqué « TBD ». Les langues couvertes ne sont pas précisées : rien n'indique le niveau en français. La licence « youtu-parsing » est un texte propre dont nous n'avons pas lu les clauses ; il faut le faire avant tout usage en entreprise. Le format PDF n'est pas cité : la fiche travaille sur des images de pages. Enfin, l'inférence exige un GPU CUDA et trust_remote_code=True, c'est-à-dire l'exécution de code livré avec le modèle ; la fiche recommande d'épingler une révision précise. Aucune VRAM minimale n'est donnée ; la configuration vLLM publiée fixe un contexte de 65 536 tokens et 70 % de la mémoire GPU.

Face à TeleOCR et aux OCR légers

Le choix est clair pour un PC de bureau : TeleOCR tourne en GGUF et sa licence est permissive. Youtu-Parsing-Omni vise une station ou un serveur, et apporte en échange la sortie JSON unifiée et les modalités audio et vidéo. Pour tester sur des documents réels, le jeu bharat-government-documents repéré ce matin ne conviendra pas : d'après sa fiche, il contient 65 k textes déjà extraits de sites administratifs indiens (40 Go, droits par source), pas de scans.

Comment l'essayer

1. Sur une station avec GPU : installer vLLM 0.19 et le plugin vllm-plugin-vita-omni indiqués par la fiche, puis lancer le serveur compatible OpenAI avec --max-model-len 65536.
2. Convertir dix PDF représentatifs en PNG (une page par image, 200 dpi) : factures, formulaires scannés, comptes rendus avec tableaux.
3. Appeler la tâche document, enregistrer le JSON, convertir les tableaux OTSL en HTML et compter les cellules fausses sur deux tableaux par page.
4. Passer les mêmes pages à TeleOCR en GGUF sur le PC et comparer : qualité des tableaux, respect de l'ordre de lecture, temps par page.
5. Lire la licence et noter la révision du dépôt utilisée avant toute intégration.

À surveiller : la publication du rapport technique et du code d'évaluation, le texte de la licence, et une éventuelle quantisation qui ramènerait le modèle sous 16 Go de VRAM.

Ce que fait le modèle

GLiNER2.5-Decide est un fine-tune de gliner2-large de 340 millions de paramètres, sous licence Apache 2.0. On lui donne un passage de texte et une ou plusieurs questions : une question fermée, un choix multiple, une échelle ordinale, une étiquette multi-label. Il répond à toutes en un seul appel, sans raisonnement intermédiaire ni texte libre. La fiche annonce 60,2 % de précision moyenne sur le benchmark maison « fast-decisions », évalué en anglais. Le modèle tourne sur CPU via la bibliothèque gliner2, ce qui le place dans la même catégorie d'usage que Laya.

Pour les textes non anglais, Fastino renvoie vers GLiNER2.5-multi-Decide (287 M), étiqueté multilingue. Le français n'y est pas évalué explicitement : c'est le premier point à vérifier.

Pourquoi c'est intéressant pour le traitement documentaire

Le tri de courriers, de procès-verbaux ou de fiches de non-conformité se résume souvent à quelques décisions : à traiter ou à archiver, urgent ou non, quel service, quelle criticité. Un LLM génératif sait le faire, mais il est lent, coûteux et difficile à calibrer. Un modèle de décision répond en quelques millisecondes, sur une machine sans GPU, et fournit une confiance exploitable pour router les cas douteux vers un humain.

La communauté s'est d'ailleurs dotée d'un premier jeu d'évaluation neutre : typed-decisions, 1 600 décisions réparties en quatre domaines, dont un sous-ensemble invoice_processing (traitement de factures). C'est le terrain idéal pour comparer GLiNER2.5-Decide, Laya, d1-3B et Clef-Flash sur des cas proches du réel.

Comment l'essayer

• Installer gliner2, charger la variante multi-Decide, et lui soumettre une vingtaine de documents déjà classés à la main avec deux questions : « À traiter ? » (oui/non) et « Urgence » (0 à 5).
• Comparer les réponses et les scores de confiance avec Laya sur le même lot.
• Fixer un seuil de confiance en dessous duquel le document part en revue humaine.

Le point de vigilance reste la langue : si la variante multilingue décroche sur le français, d1-3B (multimodal, 3 B) ou Clef-Flash (9 B) restent les options locales les plus solides, au prix d'un GPU.