Baidu ouvre Unlimited OCR 2 : des centaines de pages par requête, ce qu'il faut vérifier dans SR-SWA et la pile d'inférence
Selon MarkTechPost du 26 octobre 2026, Baidu a publié Unlimited OCR 2, un modèle de 3,34 milliards de paramètres dont les poids sont diffusés sous licence MIT ; il utiliserait SR-SWA pour ramener l'attention à un ensemble de référence fixe afin de traiter des centaines de pages par requête, avec un score auto-déclaré de 77,1 sur MarathonDocBench.
Ce qui change
Selon MarkTechPost du 26 octobre 2026, Baidu a publié Unlimited OCR 2, un modèle vision-langage d'OCR pour documents très longs, dont les poids sont diffusés sous licence MIT sur Hugging Face et le code hébergé sur GitHub, en remplacement d'Unlimited-OCR de juin 2026. Le rapport indique une taille de 3,34 milliards de paramètres, sans préciser le nombre de paramètres activés, et une longueur de position maximale de 131 072 tokens ; les poids BF16 feraient environ 6,7 Go, testés par Baidu sur une seule NVIDIA A800-80GB. L'architecture suit le style DeepSeek-OCR : un encodeur SAM ViT-B plus CLIP-L relié à un décodeur à mélange d'experts de 12 couches, chaque token étant routé vers 6 experts sur 64, plus 2 experts partagés. Le changement central est SR-SWA (attention à fenêtre glissante à référence éparse), qui comprime l'attention texte-vision sur un ensemble de référence de travail fixe ; l'exemple de la fiche modèle cité par le rapport porte sur 512 tokens, avec une fenêtre locale de 128 tokens combinée à une sélection top-16 sur des blocs de 32 tokens. Le rapport affirme que la latence par étape de décodage et l'occupation mémoire deviennent presque constantes avec la croissance du document, mais que l'encodage d'image et le temps d'exécution total augmentent toujours avec le nombre de pages ; en mode multi-page, chaque page consomme 273 tokens d'image. Côté benchmarks, le rapport indique que Baidu a testé sur MPDocBench-Parse public (433 documents, 3 246 pages) et MarathonDocBench (plusieurs centaines de pages), et qu'aucune version publique de MarathonDocBench n'a été trouvée ; selon le graphique du classement de Baidu, Unlimited OCR 2 obtient 84,6 sur MPDocBench et 77,1 sur MarathonDocBench, le meilleur modèle comparé atteignant 33,7 sur ce dernier, tandis que la génération précédente Unlimited-OCR y obtient 0,0. Tous les chiffres sont auto-déclarés par Baidu et le rapport précise qu'ils ne sont présentés que sous forme d'une image de graphique. La sous-catégorie la plus faible est la hiérarchie des titres (TEDS), à 48,2 sur MarathonDocBench ; les tableaux passent de 87,8 sur MPDocBench à 74,8. Côté exécution, la fiche modèle liste Transformers pour les tests rapides (infer pour une page, infer_multi pour toutes les pages en une requête), tandis que le service utilise SGLang via un wheel personnalisé de Baidu, et non le SGLang amont comme l'écrit le rapport ; le chargement exige trust_remote_code=True, ce qui exécute du code Python du dépôt. Le rapport mentionne aussi que l'exemple de Baidu planifie 10 pages par fenêtre et réutilise la queue de KV de la fenêtre précédente, qu'une fenêtre plus petite réduit la mémoire de pointe mais affaiblit la fusion entre pages, et que le réglage de biais par défaut peut déclencher une allocation de 462 MiB et provoquer un avertissement de mémoire insuffisante. Le rapport ne précise pas sous quelle licence le code du dépôt GitHub est distribué.
Conséquences pour les développeurs
Les implications pour les développeurs se répartissent en plusieurs niveaux, dont la plupart restent à vérifier soi-même. Premier niveau : l'estimation de la mémoire GPU et du nombre de pages maximum change. Selon le rapport, SR-SWA fait que le coût de décodage par étape n'augmente plus linéairement avec le nombre de pages ; à budget mémoire fixe, le facteur limitant du nombre de pages par requête se déplace donc plus probablement vers le coût d'encodage d'image, l'occupation de la queue de KV et la planification des fenêtres, plutôt que vers la croissance quadratique de l'attention ; c'est concret pour le traitement hors ligne de documents à fort volume et faible interaction, comme des livres, des dossiers de déclaration ou des rapports annuels. Mais le rapport précise aussi que le temps total augmente avec le nombre de pages, donc le gain reste limité pour les scénarios en ligne exigeant un retour rapide page par page. Deuxième niveau : le risque de verrouillage sur la pile d'inférence. Le service passe par un SGLang sous forme de wheel personnalisé de Baidu, que le rapport décrit comme distinct du SGLang amont, ce qui en fait une branche fournisseur à maintenir séparément ; si les images, le gel de versions et les procédures de retour arrière de l'équipe reposent sur un framework d'inférence générique, l'adoption ajoute une dépendance à suivre. La fiche modèle mentionne aussi la voie Transformers, utilisable pour la validation fonctionnelle, mais ce n'est pas une solution de service en production. Troisième niveau : distinguer licence et sécurité. Les poids sont diffusés sous licence MIT, une autorisation permissive au niveau de la licence, à ne pas confondre avec une simple ouverture de poids ; toutefois le rapport ne couvre que la licence des poids et ne précise pas celle du code GitHub, dont la réutilisation ne devrait donc pas être traitée d'emblée comme du MIT. En outre, le MIT couvre le périmètre d'autorisation, pas une garantie de sécurité du code chargé via trust_remote_code=True, qui exécute du Python du dépôt dans le processus ; dans un environnement soumis à audit, il faut généralement une revue de code et une exécution isolée au préalable. Quatrième niveau : la méthode d'évaluation. Le rapport montre que les écarts par sous-catégorie sur MPDocBench sont faibles, par exemple 94,8 contre 94,3 en texte et 89,4 contre 89,2 en formules, l'écart se concentrant sur MarathonDocBench à plusieurs centaines de pages ; le choix devrait donc reposer sur la distribution de pages de ses propres documents, pas sur le classement par score total. Les faiblesses de 48,2 en hiérarchie des titres et de 74,8 en tableaux sur documents longs touchent directement la qualité en aval de l'arbre de chapitres et de l'ingestion des tableaux, et doivent être mesurées séparément sur ses propres échantillons.
Intégration et évaluation
Les recommandations ci-dessous sont conditionnelles et ne constituent pas des faits rapportés. Décision 1 : faut-il utiliser SR-SWA pour gagner en débit sur documents longs. Le déclencheur est une taille de tâche atteignant souvent la centaine de pages ; si les documents font généralement moins de dix pages, les écarts par sous-catégorie sur MPDocBench étant faibles selon le rapport, le changement manque de justification. Concrètement, répartir son corpus en deux tranches (moins de vingt pages et plus de cent pages), exécuter infer_multi sur la même machine pour chaque tranche et relever la mémoire de pointe par requête, le temps total et la courbe du temps par page ; si le temps par page de la tranche à cent pages augmente nettement avec le nombre de pages, le goulot est passé à l'encodage d'image et il faut ajuster le nombre de pages par fenêtre plutôt que d'augmenter encore les pages par requête. Décision 2 : commencer par Transformers ou par le SGLang personnalisé. La condition préalable est la compatibilité de la pile d'inférence existante avec le wheel fournisseur ; si les images et les procédures de retour arrière ne peuvent pas intégrer le SGLang personnalisé, valider d'abord fonction et précision avec Transformers, en prenant comme seuil la capacité du nombre de pages traitables par unité de temps sur une carte à remplir la fenêtre de traitement par lots ; si le wheel personnalisé est acceptable, tester les points de risque cités : partir des 10 pages de l'exemple, réduire progressivement la fenêtre en observant la mémoire de pointe, et vérifier si l'allocation de 462 MiB déclenchée par le biais par défaut provoque une insuffisance de mémoire, en faisant de l'absence d'échec par insuffisance de mémoire une condition impérative. Décision 3 : définir des critères d'acceptation distincts pour les sorties structurées. Le rapport indique une hiérarchie des titres à seulement 48,2 sur documents longs et des tableaux à 74,8 ; si l'aval dépend de l'arbre de chapitres ou de l'ingestion des tableaux, préparer des échantillons propres annotés en hiérarchie de titres et en tableaux, mesurer ces deux points par tranche de pages, puis décider d'ajouter ou non une relecture humaine ou des règles de post-traitement. Décision 4 : intégrer trust_remote_code=True aux contrôles préalables à la mise en production, exécuter et auditer d'abord le code du dépôt dans un environnement isolé, et confirmer auprès de Baidu les conditions de licence du code du dépôt avant de décider d'une mise en production. Toutes ces évaluations devraient se fonder sur l'erreur mesurée sur son propre jeu annoté, et non sur le score total du fournisseur.
Limites et points à confirmer
Les chiffres de performance du rapport proviennent presque tous de Baidu lui-même, et le rapport précise qu'ils ne sont présentés que sous forme d'une image de graphique de classement, sans détails d'évaluation reproductibles indépendamment ; MarathonDocBench est décrit comme un benchmark de plusieurs centaines de pages, mais le rapport indique explicitement qu'aucune version publique n'a été trouvée, si bien que le 77,1 et les comparaisons avec d'autres modèles ne peuvent être vérifiés en externe. Le nombre de paramètres activés n'est pas divulgué, ce qui empêche d'en déduire la puissance de calcul ou le débit réels à l'inférence. Le rapport ne mentionne qu'une exécution sur une seule carte en BF16 avec des poids d'environ 6,7 Go, sans version quantifiée ; la possibilité de déployer sur des appareils à mémoire plus faible ne peut être jugée à partir des informations disponibles. À la date de cette vérification du catalogue, la version Unlimited OCR 2 n'apparaît pas dans le catalogue de modèles de KimiSeek ; les voies Transformers et SGLang personnalisé mentionnées par le rapport renvoient à un déploiement autonome à partir du dépôt du modèle et des documents du fournisseur, et n'indiquent pas que le modèle est disponible sur KimiSeek ; le rapport ne mentionne aucun service hébergé par un fournisseur ni aucune tarification. Si un service hébergé apparaît ultérieurement, sa disponibilité et son prix devraient être vérifiés dans sa documentation et sa page tarifaire officielles, le prix pouvant changer. Les indications du rapport sur trust_remote_code=True, sur l'insuffisance de mémoire possible due au biais par défaut et sur le SGLang personnalisé proviennent de documents du fournisseur et n'ont pas été vérifiées par un tiers ; la licence du code du dépôt GitHub n'est pas précisée. Les noms des modèles comparés et les versions de benchmarks cités sont récents ; cet article ne fait que relayer leurs données auto-déclarées et n'implique aucun test indépendant.