- Le projet part de l’idée suivante : « représenter le texte sous forme d’image permet de contenir la même information avec bien moins de tokens »
- Il propose un nouveau modèle qui compresse l’information textuelle en représentation visuelle 2D, et valide expérimentalement le concept de compression fondée sur la vision (Optical Compression) pour traiter efficacement les contextes longs
- Le modèle est composé de DeepEncoder (encodeur) et de DeepSeek3B-MoE-A570M (décodeur), et atteint une faible mémoire active même avec des entrées haute résolution, ainsi qu’un taux de compression des tokens de l’ordre de 10 à 20×
- Il conserve 97 % de précision OCR avec une compression par 10 et plus de 60 % de précision avec une compression par 20, ce qui montre un potentiel concret pour la recherche sur la compression de contexte long et les mécanismes d’oubli de la mémoire
- Sur OmniDocBench, il surpasse GOT-OCR2.0 (256 tokens/page) avec seulement 100 vision tokens, et dépasse MinerU2.0 (plus de 6000 tokens/page en moyenne) avec moins de 800 tokens
- Avec un seul GPU A100-40G, il est possible de générer plus de 200 000 pages de données par jour, ce qui lui confère une forte valeur pratique comme moteur de données pour l’entraînement à grande échelle de LLM/VLM
1. Contexte de la recherche
- Les LLM existants ont une limite structurelle : le coût de calcul augmente quadratiquement avec la longueur de la séquence
- L’article part de l’intuition suivante : « représenter le texte sous forme d’image permet de contenir la même information avec bien moins de tokens »
- Il définit cela comme une compression de contexte long basée sur des tokens visuels (Context Optical Compression), et utilise l’OCR comme terrain d’expérimentation
- Le résultat montre une nouvelle voie par laquelle la représentation visuelle peut améliorer l’efficacité du traitement du contexte par les LLM
2. Architecture du modèle
- DeepSeek-OCR = décodeur DeepEncoder + DeepSeek3B-MoE
- DeepEncoder : SAM (Window Attention) + CLIP (Global Attention) + compresseur de tokens ×16
- DeepSeek3B-MoE : 6 experts activés sur 64, pour un total de 570M de paramètres actifs
- Prise en charge de modes multi-résolution (Tiny~Gundam)
- Prend en charge des entrées de résolution 512~1280, avec composition jusqu’à 9 tuiles
- Le mode Gundam cible les documents ultra-haute résolution (journaux, etc.) et utilise jusqu’à 800 vision tokens
3. Moteur de données
- Ensemble de données composé de 3 grands types :
- Données OCR 1.0 : 30M pages issues de documents en 100 langues, avec annotations fines de mise en page et de texte
- Données OCR 2.0 : 16M d’exemples pour la reconnaissance complexe, incluant graphiques, formules chimiques (SMILES) et figures géométriques
- Données de vision générale : pour maintenir la compréhension visuelle basée sur CLIP, soit 20 % du total
- Données texte uniquement : 10 % pour renforcer les capacités linguistiques
- Répartition globale des données d’entraînement
- OCR 70 % / vision 20 % / texte 10 %
4. Pipeline d’entraînement
- Entraînement en deux étapes : DeepEncoder → DeepSeek-OCR
- Sur un total de 20 nœuds (8×A100 GPU), avec parallélisme de données DP=40 et batch global de 640
- Vitesse d’entraînement : 90B tokens/jour pour les données texte, 70B tokens/jour pour les données multimodales
5. Résultats d’évaluation
(1) Expériences de compression (benchmark Fox)
- 97 % de précision avec une compression ×10, et plus de 60 % maintenus même à ×20
- Les performances baissent lorsque les documents deviennent plus longs ou complexes, mais cela est interprété comme une possible simulation d’un “mécanisme d’oubli”
- Avec un taux de compression inférieur ou égal à 10×, une reconstruction du contexte quasiment sans perte est possible
(2) Reconnaissance de documents réels (OmniDocBench)
- Comparaison des modes Tiny (64 tokens) à Gundam (800 tokens)
- Supérieur à GOT-OCR2.0 (256 tokens) avec le mode Small (100 tokens)
- Supérieur à MinerU2.0 (7 000 tokens) avec Gundam (800 tokens)
- Le nombre de tokens requis varie selon le type de document
- Slides, rapports : 64 à 100 tokens suffisent
- Journaux, articles scientifiques : 400 à 800 tokens nécessaires
6. Analyse qualitative (Qualitative Study)
- Mode Deep Parsing
- Extraction structurée possible via un prompt unique, y compris pour graphiques, figures, formules chimiques et images naturelles
- Reconnaissance multilingue
- Prise en charge de PDF dans environ 100 langues, y compris des langues moins répandues comme l’arabe ou le cingalais
- Compréhension visuelle générale
- Réalise aussi la description d’images, la détection d’objets et le grounding
- Couplé à un LLM, peut servir de modèle de base pour le raisonnement vision-langage complexe
7. Discussion et implications
- DeepSeek-OCR est la première expérimentation explorant les limites de la compression de longs contextes fondée sur des vision tokens,
et quantifie l’idée selon laquelle « une image vaut mille mots »
- Une reconstruction presque sans perte est possible même avec une compression ×10 → extension possible à la compression d’historique de conversation et à l’optimisation de la mémoire long terme
- Il propose aussi une simulation d’atténuation des tokens proche de la courbe biologique de l’oubli, en réduisant progressivement la résolution des images au fil du temps
8. Conclusion
- DeepSeek-OCR est un modèle démonstratif de compression 10 à 20× entre texte et visuel,
qui propose un nouveau paradigme pour dépasser les limites des LLM dans le traitement de contextes longs
- Au-delà de l’OCR, il pourrait évoluer vers un préentraînement hybride numérique-optique ainsi que vers des modèles à très long contexte fondés sur l’“Optical Context Memory”
- Le code est public et peut être exploité à la fois pour la recherche et comme moteur de données commercial
- DeepSeek-OCR attire l’attention, face aux solutions OCR open source existantes, par son architecture fondée sur un grand modèle de langage (LLM) capable d’encoder efficacement l’information visuelle
- Il prend en charge diverses résolutions (512×512~1280×1280), ainsi qu’un mode Gundam à résolution dynamique, ce qui lui permet de bien s’adapter à des environnements variés
- Grâce à une conception de prompts claire, il prend en charge plusieurs modes de travail : description d’image générale, conversion Markdown, OCR ignorant la mise en page, parsing de tableaux et graphiques, etc.
- Les performances sont vérifiées via des benchmarks du secteur comme Fox, OminiDocBench, ainsi que par des expériences sur le traitement réel de documents
- Il implémente et reprend les atouts et idées d’autres projets populaires comme GOT-OCR2.0 et PaddleOCR
- Résolutions prises en charge
- Tiny: 512×512 (64 vision tokens)
- Small: 640×640 (100 vision tokens)
- Base: 1024×1024 (256 vision tokens)
- Large: 1280×1280 (400 vision tokens)
- Dynamic mode(=Gundam): résolution libre (n×640×640 + 1×1024×1024)
- Inférence parallèle sur PDF et images, avec vitesse de traitement élevée
- Sur GPU A100, traitement PDF possible à ~2 500 tokens/s
- Contexte technique et intégration à l’écosystème
- Implémenté à 100 % en Python
- Compatible avec les deux principaux environnements d’inférence : vLLM et Transformers
- Utilise des benchmarks et frameworks d’évaluation majeurs comme OpenChart, Fox, OminiDocBench
- S’appuie sur des modèles antérieurs comme GOT-OCR2.0, PaddleOCR et Vary, en reprenant certaines idées et en renforçant les performances
1 commentaires
Avis Hacker News
Cet article ne se limite pas à un autre VLM pour l’OCR, il ouvre aussi sur des sujets plus intéressants comme la compression
Par exemple, on y trouve cette citation : « Nous menons une étude préliminaire sur les limites de la compression vision-texte, en examinant combien de tokens de vision sont nécessaires pour décoder des tokens de texte. Les premiers résultats montrent que DeepSeek-OCR atteint une compression OCR quasi sans perte avec un ratio d’environ 10x, et conserve 60 % de précision même à 20x de compression »
Intuitivement, cela voudrait dire qu’un token de vision contient autant d’information qu’une dizaine de tokens de texte
J’aimerais qu’on m’explique, d’une manière accessible à un débutant, pourquoi ce résultat apparaît du point de vue de la théorie de l’information
Je me demande si c’est parce que les tokens de texte sont encore trop fragmentés (ou redondants) et restent loin d’un codage entropique, ou si le passage aux tokens de vision permet de sortir de la limite du « mot comme unité » et de se rapprocher de l’entropie réelle (un peu comme la différence entre l’encodage arithmétique et le code de Huffman)
L’article discute aussi du fait que, pour gérer de très grands contextes, ils réduisent réellement la taille des images, et donc du lien entre la perte d’information dans le domaine texte et dans le domaine image
Les tokens de texte sont des sous-unités quantifiées (subwords), alors que les tokens de vision n’existent que dans l’espace d’embedding
Dans un LLM, la tokenisation du texte repose sur une structure de table de correspondance entre des ID de tokens (petits) et des embeddings vectoriels (grands)
Quand on envoie du texte à un LLM, la chaîne est découpée selon des frontières de tokens, convertie en ID de tokens, puis on récupère les vecteurs dans une table pour former une matrice de contexte (
context matrix)Le transfert de la séquence réelle de tokens de texte est efficace, car il suffit d’envoyer un tableau de nombres (des ID), avec en général environ 100 000 tokens uniques
À l’inverse, transmettre directement la matrice d’embeddings serait inefficace, car un embedding est constitué de milliers de nombres flottants
Les images sont encodées différemment. Les données d’image sont prétraitées puis injectées directement dans un encodeur d’image neuronal, qui les transforme en vecteurs ajoutés au contexte
Autrement dit, les tokens d’image n’ont ni ID de token, ni table de lookup, et passent directement des données à l’embedding
Au final, transmettre des tokens d’image est inefficace, puisqu’il faut transmettre l’embedding lui-même
Même si une image est encodée avec moins de tokens, chaque token occupe beaucoup plus d’espace
En résumé, les tokens de texte sont des entiers (0~n) mappés de manière déterministe vers des vecteurs, avec donc « n » choix possibles
En revanche, les tokens d’image sont des tableaux de flottants de dimension m (des vecteurs), donc ils occupent un espace de tokens beaucoup plus vaste
Côté motifs aussi, les tokens de texte correspondent directement à des octets UTF-8 contigus et ne dépassent généralement pas les frontières de mots ; de ce fait, des motifs globaux (« cette réplique vient de Hamlet », « ce passage est en espagnol ») ne peuvent pas être exprimés par un seul token
Je ne sais pas exactement comment les entrées image sont embarquées dans les LLM multimodaux, mais j’imagine en gros qu’on découpe l’image en grille puis qu’on encode chaque région
Dans l’expérience de DeepSeek, il me semble que l’enjeu n’est pas tant une propriété de théorie de l’information que la question de savoir jusqu’où on peut réduire la résolution ou grossir la taille de la grille (patches) tout en conservant assez de détails pour faire un OCR correct
J’aimerais bien que Karpathy partage son savoir-faire sur ce processus d’encodage en étendant NanoChat au multimodal
Le bon ratio de compression dépend forcément de la taille relative entre la résolution d’un caractère et la taille d’un patch de token de vision
C’est seulement ainsi que le nombre de tokens de texte extraits par OCR peut au final rester indépendant de la résolution de l’image
Chaque token de texte correspond le plus souvent à une subword, alors que les tokens de vision d’un VLM vivent dans un espace sémantique
Cet espace sémantique peut compresser l’information bien plus efficacement qu’un découpage en subwords
Remarque : je ne suis pas expert, c’est juste une réflexion à chaud
Les LLM ont un coût de calcul qui croît au carré avec le nombre de tokens
C’est pourquoi les VLM cherchent à compresser les tokens de texte en tokens de vision
J’imagine qu’ils essaient de réduire le coût de calcul en rendant d’abord le texte sous forme d’image avant de le tokeniser
Sur NVIDIA Spark (ARM64), PyTorch est un peu pénible à faire tourner, mais j’ai réussi à le lancer en exécutant Claude Code avec les droits root dans un nouveau conteneur Docker
On peut voir mes notes détaillées ici
Le résultat concret est visible à ce lien, testé à partir de l’image OCR d’origine (ici)
Le résultat OCR est globalement très solide
En revanche, il y a une hallucination avec du contenu inutile ajouté dans le paragraphe juste sous la citation, puis fusionné avec la colonne suivante
Merci d’avoir lancé ce test aussi vite
Je comprends qu’il ait raté le « A » au début du texte (le dataset contenait peut-être peu d’articles de presse)
Mais je trouve plus intéressant qu’il ait complètement raté tout « Hallucination is a risk and... », le sujet (« theme ») à côté de l’auteur, ainsi que l’adresse e-mail finale
Rien que cette expérimentation mériterait selon moi un billet séparé
« Exécuter Claude Code en root dans un nouveau conteneur Docker »
J’aimerais savoir concrètement comment le configurer pour qu’il tourne avec les droits root
(si c’est déjà expliqué, j’irai voir dans l’article)
L’article ne mentionne pas Anna’s Archive
Je pense que DeepSeek a peut-être réellement exploité l’offre d’Anna, qui proposait aux chercheurs en OCR l’accès à une collection de 7,5 millions de livres de non-fiction en chinois (350 To)
C’est même plus volumineux que Library Genesis
Billet de blog de référence
Dans un précédent article de DeepSeek, Anna’s Archive est cité explicitement
« 860 000 livres électroniques en anglais, 180 000 en chinois, ainsi que des millions de questions d’examen K-12 ont été nettoyés depuis Anna’s Archive »
Voir l’article DeepSeek-VL
Je me demande pourquoi il faudrait absolument obtenir une autorisation d’accès, simplement parce qu’ils hébergent les livres de quelqu’un d’autre
Moi aussi j’ai tout de suite pensé à Anna’s Archive, et je me demande quand un dataset passé par OCR sera rendu public
Cela signifie aussi que le dataset pourrait ne jamais être publié
Dans ce genre de situation, je crains qu’Anna’s Archive finisse elle aussi par disparaître à cause des abus des entreprises LLM
Comme si le fait que META ait déjà aspiré 70 To de Library Genesis via torrent ne suffisait pas
Retour d’expérience sur le niveau réel de certains benchmarks par rapport à aujourd’hui
Le benchmark OmniAI n’est pas terrible
À la place, je recommande OmniDocBench
Mistral OCR est nettement en dessous des modèles OCR open source, et de Gemini
L’OCR de bout en bout reste très difficile
Une approche pipeline (détection de layout → détermination de l’ordre de lecture → OCR de chaque élément) fonctionne mieux
Le parsing de tableaux complexes reste un énorme défi
Je serais curieux de voir des comparaisons de benchmark avec Apple Vision Framework
C’est intégré à presque tous les appareils Apple, et en pratique ça produit un OCR rapide et de bonne qualité (surtout pour la conversion de PDF), mais peu de gens semblent le savoir
J’aimerais beaucoup savoir où il se situe dans les benchmarks
D’après le benchmark OmniAI, c’est Omni OCR qui obtient les meilleurs résultats
J’ai l’impression que personne ne remettra ça en question
Je me demande quels sont les avantages et différences entre l’OCR basé sur LLM et des services comme Azure AI Document Intelligence(lien) ou Google Vision API(lien)
OmniAI compare ses propres LLM et de l’OCR cloud dans ses benchmarks
Benchmark du blog OmniAI (février 2025)
Depuis, les LLM ont progressé très vite
Les meilleurs résultats récents semblent venir de la famille Qwen3-VL, en particulier Qwen3-VL-235B-A22B-Instruct
À mon avis, les modèles OCR commerciaux/propriétaires resteront meilleurs sur les documents réels
Grâce à l’existence de grands jeux de données privés de très haute qualité
Les LLM publics sont entraînés surtout sur Arxiv, des ebooks, etc., donc sur des données orientées articles/papiers ; ils sont inévitablement moins bons sur les documents de travail du monde réel
L’approche LLM réduit les erreurs de substitution de caractères (fautes, variantes), mais la cohérence à l’échelle d’une page entière est plutôt moins bonne
Comme les LLM non spécialisés OCR, ils peuvent aussi produire des résultats complètement absurdes
Pour les caractères CJK, l’OCR classique produit encore beaucoup de substitutions inadéquates
Il existe trop de caractères très similaires, parfois distinguables seulement au microscope ou au niveau binaire
Les LLM imposent davantage de contraintes sur les séquences plausibles de caractères, donc on peut espérer des résultats plus précis
Au minimum, c’est une vraie motivation pour adopter l’OCR basé sur LLM
Je ne connais pas les autres modèles, mais dans notre entreprise nous faisons tourner un système de parsing de CV avec Azure AI Document Intelligence, et nous en sommes plutôt satisfaits
Il faut juste soigner un peu le réglage au départ, puis depuis un an il demande presque zéro maintenance
J’ai testé plusieurs VLM, de petits modèles jusqu’à de gros modèles (Granite, Qwen, etc.), et ma conclusion est qu’ils restent décevants comme remplacement complet d’un OCR classique
Notre système prend des documents client et renvoie des documents standardisés balisés comme demandé (des bitmaps raster multipages)
Chez nous, la précision des coordonnées jusqu’au niveau du caractère ou du mot individuel est importante, mais en pratique les informations de position produites par les VLM sont beaucoup trop irrégulières, complètement hallucinées, ou trop vagues pour garantir le niveau de précision et de granularité voulu
Pour l’instant, nous restons sur une base Tesseract avec des routines de nettoyage des résultats, et nous n’utilisons qu’occasionnellement la sortie texte des VLM comme appoint quand il n’existe pas de dataset structuré
J’imagine que notre besoin est très spécifique et que, pour la plupart des gens, un simple dump texte ou une conversion en Markdown/HTML suffit
Mais j’ai le sentiment qu’il existe un vrai écart entre l’affirmation selon laquelle ces modèles auraient « complètement résolu l’OCR » et l’expérience réelle
As-tu essayé le modèle moondream 3 preview ?
Le billet de blog affirme qu’il surpasse plusieurs VLM tout en restant léger
Voir la page principale, le modèle et le blog
Je me demande si les documents clients contiennent du texte manuscrit
On pourrait aussi imaginer détecter d’abord les boîtes englobantes du texte avec un CNN, puis lancer un VLM sur chaque boîte
Mon impression personnelle était que l’OCR était plus ou moins un problème déjà résolu
Le benchmark OmniAI n’a pas été mis à jour avec les modèles récents, et je pense que c’est parce que des LLM généralistes ont déjà dépassé l’OCR propre au benchmark
En pratique, si on envoie chaque image de page à Gemini 2.5 Flash Lite pour en extraire du Markdown, le coût tourne autour de 20 centimes pour environ 1000 pages, avec des résultats très bons
Je me demande donc où se situent encore les vraies difficultés de l’OCR aujourd’hui
Même la plupart des OCR/LLM (surtout Gemini Pro 2.5) ont encore beaucoup de mal avec la conversion de tableaux complexes en Markdown/HTML
Les en-têtes multiples, les cellules fusionnées, les colonnes avec cases à cocher posent souvent problème, et ils comprennent mal les tableaux qui s’étendent sur plusieurs pages
Llamaindex échoue aussi lourdement là-dessus
Je me demande quel OCR/LLM s’en sort mieux sur ce genre de cas
Exemple de tableaux complexes, Exemple complet de checklist OACI
En réalité, ce n’est pas l’OCR mais le HTR (reconnaissance/transcription manuscrite) qui reste difficile
Les LLM ont nettement amélioré la précision, mais leurs erreurs sont devenues bien plus difficiles à repérer pour un humain (ils inventent complètement ce qu’ils n’arrivent pas à lire)
Si l’on accepte des résultats qui, au lieu de signaler « je ne sais pas », remplissent les zones illisibles en inventant du contenu, alors oui, le problème est résolu
(Je ne dis pas ça de façon sarcastique : dans certains cas, cela peut réellement convenir)
Je suis l’auteur du benchmark OmniAI
S’il n’y a pas de mise à jour avec les modèles récents, c’est parce que nous avons réduit la place de l’API OCR dans le produit
Nous l’utilisons encore en interne, et le benchmark n’est simplement pas maintenu à jour par paresse
Gemini est le meilleur en OCR
En revanche, lorsqu’il produit quelque chose de trop proche des données d’entraînement, il subit souvent une erreur de « recitation » où la sortie s’interrompt brutalement sur environ 10 % du contenu
Sur des mélanges de PDF, la présence d’une page blanche peut aussi déclencher d’amusantes hallucinations où il invente complètement autre chose
OpenAI n’est pas mauvais non plus, mais GPT5 ne fait pas mieux que GPT-4o ou 4.1
Certains éléments comme les en-têtes/pieds de page disparaissent souvent, et dès qu’une page est tournée de côté il perd complètement les pédales
Il arrive aussi fréquemment qu’il refuse de traiter des pièces d’identité, documents médicaux, ou tout contenu à fort risque PII
Je ne pense absolument pas que ce soit un problème résolu
Essayez donc de faire de l’OCR sur des magazines à mise en page inhabituelle : c’est impossible
Je collectionne des magazines vintage et j’essaie régulièrement de les OCRiser avec les technologies les plus récentes, mais cela demande toujours énormément de travail humain
Je me demande s’il n’existe pas de petit « modèle OCR »
J’ai juste besoin d’extraire des numéros de série depuis des photos prises sur une chaîne de production, pas de parser des documents complets
Utiliser un modèle de 3 milliards de paramètres pour ça me paraît excessif
Je me demande comment DeepSeek-OCR se compare à Tesseract(lien)
J’utilise souvent ocrmypdf(lien) et ça fonctionne extrêmement bien chez moi en local
Mais si, dans la réalité, Tesseract atteint 80 % de performance et les derniers modèles montent à 95 %, tout en exigeant en contrepartie 100 fois plus de disque, du Kubernetes/Docker, un GPU avec 16 Go de VRAM, etc., alors cela mérite évidemment d’être pris en compte
Je ne suis pas l’actualité de la recherche, alors j’aimerais bien une explication ELI5 de ce que c’est et pourquoi c’est important
Le titre sur GitHub ou dans l’article parle d’OCR, mais le résumé et le
readme.mdparlent de compression de contexte LLM, ce qui est déroutantJe cherche quelqu’un qui puisse expliquer comment les deux sont reliés, dans une perspective plus large
L’image contient donc l’équivalent de « 1000 tokens » d’information
En pratique, il faut décoder l’image en features/embeddings
Si l’image est traitée sous forme de 100 « tokens d’image », et que ces tokens d’image sont convertis en 1000 « tokens de texte »
Alors, du point de vue du décodage pur, on a transmis la même information de sortie sous une forme 10 fois plus compressée
Pour un LLM, cela signifie que si l’on peut compresser à l’avance dans une représentation latente 10 fois plus petite, on peut produire un résultat équivalent ou meilleur sans avoir besoin de 1000 tokens/embeddings