{"notes":[{"id":"deepseek/deepseek-ocr","category":"deepseek","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"DeepSeek-OCR","subtitle":"Une image vaut mille mots","author":"Z. Yuan","paperDate":"2025-10-21","publishedOn":"2026-03-09","world":"external/deepseek-ocr","paperTitle":"DeepSeek-OCR: Contexts Optical Compression","paperUrl":"https://arxiv.org/abs/2510.18234","bibliography":{"title":"DeepSeek-OCR: Contexts Optical Compression","authors":["Haoran Wei","Yaofeng Sun","Yukun Li"],"url":"https://arxiv.org/abs/2510.18234","pdfUrl":"https://arxiv.org/pdf/2510.18234v1","codeUrl":"https://github.com/deepseek-ai/DeepSeek-OCR","preprint":{"id":"2510.18234","submittedOn":"2025-10-21","url":"https://arxiv.org/abs/2510.18234"},"publication":null,"citation":"@misc{deepseekdeepseekocr2025,\n  title = {{DeepSeek-OCR: Contexts Optical Compression}},\n  author = {Haoran Wei and Yaofeng Sun and Yukun Li},\n  year = {2025},\n  eprint = {2510.18234},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2510.18234}\n}\n","citationPath":"/content/papers/citations/deepseek/deepseek-ocr.66e8e5a7db8d.bib"},"thumbnail":{"src":"/content/papers/assets/6f53ecfe63f39804454a69ef4468c93e8018fa1afbe08d1bb52b7e8d52d194c3.png","width":1288,"height":350},"locale":"fr","path":"/content/papers/fr/deepseek/deepseek-ocr.dfea002cdca7.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"architecture-densemble","text":"Architecture d'ensemble","depth":3},{"id":"suivons-une-page-de-10241024","text":"Suivons une page de 1024×1024","depth":3},{"id":"le-décodeur-restituer-le-texte-à-partir-dune-représentation-compressée","text":"Le décodeur : restituer le texte à partir d'une représentation compressée","depth":3},{"id":"données-et-entraînement","text":"Données et entraînement","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"expérience-de-taux-de-compression-100-pages-de-fox","text":"Expérience de taux de compression : 100 pages de Fox","depth":3},{"id":"documents-réels-omnidocbench","text":"Documents réels : OmniDocBench","depth":3},{"id":"compression-optique-et-oubli","text":"Compression optique et oubli","depth":3},{"id":"le-débat-après-la-publication","text":"Le débat après la publication","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"model-evaluation/linguistic-crutch","relation":"referenced","topic":""}]},{"id":"model-evaluation/linguistic-crutch","category":"model-evaluation","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"Linguistic Crutch","subtitle":"Broder a un prix","author":"Z. Yuan","paperDate":"2026-01-07","publishedOn":"2026-02-21","paperTitle":"Visual Merit or Linguistic Crutch? A Close Look at DeepSeek-OCR","paperUrl":"https://arxiv.org/abs/2601.03714","bibliography":{"title":"Visual Merit or Linguistic Crutch? A Close Look at DeepSeek-OCR","authors":["Yunhao Liang","Ruixuan Ying","Bo Li","Hong Li","Kai Yan","Qingwen Li","Min Yang","Okamoto Satoshi","Zhe Cui","Shiwen Ni"],"url":"https://arxiv.org/abs/2601.03714","pdfUrl":"https://arxiv.org/pdf/2601.03714v2","codeUrl":null,"preprint":{"id":"2601.03714","submittedOn":"2026-01-07","url":"https://arxiv.org/abs/2601.03714"},"publication":null,"citation":"@misc{modelevaluationlinguisticcrutch2026,\n  title = {{Visual Merit or Linguistic Crutch? A Close Look at DeepSeek-OCR}},\n  author = {Yunhao Liang and Ruixuan Ying and Bo Li and Hong Li and Kai Yan and Qingwen Li and Min Yang and Okamoto Satoshi and Zhe Cui and Shiwen Ni},\n  year = {2026},\n  eprint = {2601.03714},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2601.03714}\n}\n","citationPath":"/content/papers/citations/model-evaluation/linguistic-crutch.af1f73a098b5.bib"},"thumbnail":{"src":"/content/papers/assets/3dfc834dee089d76acab6a1ce767b06c592ef84c6b48c2a5f79a7723f9cc3f09.png","width":644,"height":300},"locale":"fr","path":"/content/papers/fr/model-evaluation/linguistic-crutch.3edd79fc08e7.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"garder-des-conditions-dimage-identiques","text":"Garder des conditions d'image identiques","depth":3},{"id":"trois-façons-de-casser-le-texte","text":"Trois façons de casser le texte","depth":3},{"id":"deux-autres-tests","text":"Deux autres tests","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"quand-la-phrase-perd-son-sens","text":"Quand la phrase perd son sens","depth":3},{"id":"quand-les-mots-ne-ressemblent-plus-à-des-mots","text":"Quand les mots ne ressemblent plus à des mots","depth":3},{"id":"et-les-autres-modèles","text":"Et les autres modèles ?","depth":3},{"id":"questions-réponses-et-long-contexte","text":"Questions-réponses et long contexte","depth":3},{"id":"à-garder-en-tête-en-lisant-cet-article","text":"À garder en tête en lisant cet article","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"deepseek/deepseek-ocr","relation":"citing","topic":""}]}],"text":"À en juger par son nom, c'est un modèle d'OCR. À la lecture du résumé, on découvre que la vraie question des auteurs est ailleurs.\n\nQuand un LLM traite un texte long, le coût de calcul de l'attention croît avec le carré de la longueur. Si une page contient mille tokens de texte, peut-on la prendre en photo, la transmettre au modèle sous forme de cent, voire soixante-quatre tokens visuels, puis lui faire relire le texte d'origine ?\n\nSi oui, l'image devient un moyen de compresser du texte. Les auteurs appellent cette idée la **compression optique du contexte** (*contexts optical compression*). L'OCR sert de salle d'examen pour la mettre à l'épreuve : l'entrée est une image, la réponse attendue est le texte d'origine, et une simple comparaison dit si c'est juste.\n\nIl s'agit d'un rapport technique déposé sur arXiv par DeepSeek-AI le 21 octobre 2025 ; cette note suit la v1. Les poids et le code ont été publiés en même temps.\n\n## Définir le problème\n\nDans la section sur les travaux connexes, les auteurs posent la question sans détour : combien de tokens visuels faut-il au minimum pour décoder un document de mille mots ?\n\nPour y répondre, il faut un encodeur capable de faire varier le nombre de tokens visuels. Les auteurs passent en revue trois approches courantes dans les VLM open source de l'époque, chacune avec ses défauts :\n\n1. **Architecture à deux tours**, comme Vary : un encodeur SAM supplémentaire, monté en parallèle, traite la haute résolution. Paramètres et mémoire restent maîtrisables, mais l'image subit deux prétraitements, et le parallélisme de pipeline se met mal en place à l'entraînement.\n2. **Découpage en tuiles**, comme InternVL2.0 : une grande image est découpée en petites tuiles encodées séparément. Cela permet de traiter de très hautes résolutions, mais la résolution native est généralement inférieure à 512×512 ; une grande image est donc morcelée, et le nombre de tokens visuels grimpe aussitôt.\n3. **Résolution adaptative**, comme Qwen2-VL : l'image d'origine est directement découpée en patchs. C'est souple, mais les grandes images demandent beaucoup de mémoire d'activation, et dès que la séquence de tokens visuels s'allonge, le prefill comme la génération ralentissent.\n\nL'encodeur que veulent les auteurs doit remplir cinq conditions : traiter la haute résolution, ne pas exploser en mémoire à haute résolution, produire peu de tokens visuels, accepter plusieurs résolutions et garder un nombre de paramètres modéré. Aucune solution existante ne coche toutes les cases ; ils construisent donc le leur, **DeepEncoder**.\n\n## Résoudre le problème\n\n### Architecture d'ensemble\n\n[![Schéma de l'architecture de DeepSeek-OCR : la page d'entrée est découpée en patchs de 16×16 et passe par DeepEncoder, composé de SAM (attention locale), d'une convolution de sous-échantillonnage par 16 et de CLIP (attention globale), puis est transmise avec le prompt au décodeur DeepSeek-3B MoE, qui produit le texte](/content/papers/assets/6f53ecfe63f39804454a69ef4468c93e8018fa1afbe08d1bb52b7e8d52d194c3.png)](/content/papers/assets/6f53ecfe63f39804454a69ef4468c93e8018fa1afbe08d1bb52b7e8d52d194c3.png)\n\n*Figure 3 de l'article, extraite de la [**page 5 du PDF v1**](https://arxiv.org/pdf/2510.18234v1#page=5), CC BY 4.0. Dans le cadre en pointillés de la moitié gauche, DeepEncoder ; à droite, le décodeur.*\n\nParcourons d'abord la figure de gauche à droite :\n\n- **SAM** (80 millions de paramètres, architecture ViTDet) se charge de la perception, surtout par une attention locale à fenêtres.\n- **Conv 16x** désigne deux couches de convolution qui divisent le nombre de tokens par seize.\n- **CLIP** (ViT, 300 millions de paramètres) assure l'attention globale ; sa couche de patch embedding d'origine est retirée, puisque son entrée est déjà constituée des tokens produits par l'étape précédente.\n- **DeepSeek-3B** est le décodeur, un MoE de 3 milliards de paramètres, dont environ 570 millions sont activés à chaque inférence.\n\nDeepEncoder compte au total environ 380 millions de paramètres. La logique de cet agencement : **tant que les tokens sont nombreux, se contenter d'une attention locale bon marché ; ne passer à l'attention globale, coûteuse, qu'après compression**.\n\n### Suivons une page de 1024×1024\n\nPrenons l'exemple de l'article lui-même, une page de 1024×1024 en mode Base :\n\n1. SAM découpe des blocs de 16×16 pixels et obtient 1024/16 × 1024/16 = 64×64 = **4 096** tokens de patchs. Cette étape repose surtout sur l'attention à fenêtres et ne compte que 80 millions de paramètres : la mémoire tient le coup.\n2. Le module de convolution comprend deux couches de noyau 3, de pas 2 et de padding 1, qui font passer les canaux de 256 à 1024. Chaque couche divise par deux la hauteur et la largeur : 64×64 → 32×32 → 16×16. Il reste 4 096 / 16 = **256** tokens.\n3. Ces 256 tokens entrent dans CLIP pour l'attention globale. Avec 256 tokens au lieu de 4 096, la table des scores d'attention par paires est 256 fois plus petite.\n4. Le décodeur reçoit ces 256 tokens visuels et le prompt, et produit le texte de manière autorégressive.\n\nLe nombre de tokens d'une page dépend donc entièrement de la résolution d'entrée :\n\n| Mode | Résolution | Tokens visuels | Traitement |\n| --- | --- | ---: | --- |\n| Tiny | 512×512 | 64 | Redimensionnement direct |\n| Small | 640×640 | 100 | Redimensionnement direct |\n| Base | 1024×1024 | 256 | Proportions conservées, avec remplissage |\n| Large | 1280×1280 | 400 | Proportions conservées, avec remplissage |\n| Gundam | n tuiles locales de 640×640 + vue globale de 1024×1024 | n×100 + 256 | Découpage en tuiles, n de 2 à 9 |\n\n*Tableau : d'après le §3.2.2 et la Figure 4 de l'article. Il existe aussi un mode Gundam-master (tuiles locales de 1024×1024 + vue globale de 1280×1280), obtenu en poursuivant l'entraînement du modèle déjà entraîné.*\n\n\n> [!TIP]\n> \n> **Combien de tokens utiles reste-t-il après le remplissage ?**\n> \n> Les modes Base et Large complètent l'image en carré pour conserver ses proportions ; les tokens des zones de remplissage n'ont aucun contenu. L'article donne la formule des tokens utiles :\n> \n> $$\n> N_{valid}=\\left\\lceil N_{actual}\\times\\left[1-\\frac{\\max(w,h)-\\min(w,h)}{\\max(w,h)}\\right]\\right\\rceil\n> $$\n> \n> Faisons le calcul pour une page A4 en portrait, dont le rapport largeur/hauteur est d'environ 1:1,414 : le terme entre crochets vaut $1-(1.414-1)/1.414\\approx0.707$. Le mode Base donne $\\lceil256\\times0.707\\rceil=182$, le mode Large 283.\n> \n> Dans le tableau OmniDocBench plus loin, Base est noté 256(182) et Large 400(285). Ces valeurs sont des moyennes sur tout le jeu de test, dont les pages ont des proportions variées ; le calcul A4 ne sert ici qu'à vérifier l'ordre de grandeur.\n\n\n### Le décodeur : restituer le texte à partir d'une représentation compressée\n\nLes auteurs décrivent le travail du décodeur comme une application : à partir de $n$ tokens visuels compressés $\\mathbf{Z}\\in\\mathbb{R}^{n\\times d_{latent}}$, reconstruire la représentation de $N$ tokens de texte.\n\nLe décodeur est un DeepSeekMoE : à l'inférence, il active 6 des 64 experts routés, plus 2 experts partagés. Selon les auteurs, il a l'expressivité d'un modèle de 3 milliards de paramètres pour un coût d'inférence proche de celui d'un petit modèle de 500 millions.\n\nArrêtons-nous un instant : quand $N$ dépasse $n$ d'un facteur dix ou plus, le décodeur ne peut pas se contenter de « traduire un à un » les tokens visuels. Il doit mobiliser les connaissances linguistiques qu'il a apprises pour déployer l'information compressée en phrases complètes. C'est ce qui fait fonctionner la méthode, et c'est aussi ce que des travaux ultérieurs mettront en question ; nous y reviendrons dans la discussion.\n\n### Données et entraînement\n\nLes données documentaires sont l'élément central. Les auteurs collectent sur le web environ 30 millions de pages PDF dans une centaine de langues, dont environ 25 millions en chinois et en anglais, avec deux types d'annotations :\n\n- **Annotations grossières** : le texte est extrait directement du PDF avec fitz, surtout pour apprendre au modèle à reconnaître les caractères de nombreuses langues.\n- **Annotations fines** : 2 millions de pages en chinois et autant en anglais, annotées par des modèles de mise en page comme PP-DocLayout et des modèles d'OCR comme MinerU ou GOT-OCR2.0, sous une forme qui entrelace « coordonnées + catégorie + texte ». Pour les langues minoritaires, fitz produit de petites images qui servent à entraîner un GOT-OCR2.0, lequel annote ensuite les données : 600 000 exemples au total.\n\nS'y ajoutent 3 millions de documents Word, 10 millions d'exemples de texte de scène en chinois et autant en anglais annotés avec PaddleOCR, et ce que les auteurs appellent les données « OCR 2.0 » : 10 millions de graphiques (annotés en tableaux HTML), 5 millions de formules chimiques (SMILES) et 1 million de figures de géométrie plane.\n\nLe mélange global : 70 % de données OCR, 20 % de données visuelles générales, 10 % de texte seul.\n\nL'entraînement se fait en deux temps. DeepEncoder est d'abord entraîné seul, avec un petit modèle de langage et un objectif de prédiction du token suivant ; puis SAM et le compresseur sont gelés, et le modèle complet est entraîné avec le décodeur. L'entraînement principal mobilise 20 nœuds de 8 A100-40G chacun, pour environ 70 milliards de tokens de données multimodales par jour.\n\n## Discussion\n\n### Expérience de taux de compression : 100 pages de Fox\n\n[![À gauche : précision et taux de compression sur le benchmark Fox avec 64 et 100 tokens visuels, selon la longueur du texte ; à droite : relation entre le nombre moyen de tokens visuels et la distance d'édition globale des modèles sur OmniDocBench](/content/papers/assets/45775893f2592575b0f63ed52ce871bcfdd8aacf7f1772a97ee461c2c1e86e52.png)](/content/papers/assets/45775893f2592575b0f63ed52ce871bcfdd8aacf7f1772a97ee461c2c1e86e52.png)\n\n*Figure 1 de l'article, extraite de la [**page 1 du PDF v1**](https://arxiv.org/pdf/2510.18234v1#page=1), CC BY 4.0. (a) Les barres indiquent la précision (axe de gauche), les lignes pointillées le taux de compression (axe de droite) ; (b) plus on va vers la droite, moins il y a de tokens visuels ; plus on monte, plus la distance d'édition est faible.*\n\nCommençons par la figure de gauche. L'axe horizontal donne le nombre de tokens de texte de la vérité terrain par page ; les barres violettes correspondent à 64 tokens visuels (Tiny), les bleues à 100 (Small), et les lignes pointillées aux taux de compression correspondants.\n\nLes auteurs retiennent toutes les pages anglaises du benchmark Fox qui comptent entre 600 et 1 300 tokens de texte, soit exactement 100 pages, et les testent avec le prompt « Free OCR », qui n'exige pas de mise en page. Quelques lignes de la Table 2 :\n\n| Tokens de texte | 64 tokens visuels | 100 tokens visuels | Pages |\n| --- | --- | --- | ---: |\n| 600–700 | 96,5 % (10,5×) | 98,5 % (6,7×) | 7 |\n| 800–900 | 83,8 % (13,2×) | 96,8 % (8,5×) | 28 |\n| 1000–1100 | 79,3 % (16,5×) | 91,5 % (10,6×) | 11 |\n| 1200–1300 | 59,1 % (19,7×) | 87,1 % (12,6×) | 4 |\n\n*Tableau : extrait de la Table 2 de l'article. Entre parenthèses, le taux de compression.*\n\nDeux points à surveiller en lisant ce tableau :\n\n1. **Les pages sont inégalement réparties.** Le chiffre « environ 60 % à une compression de 20× » du résumé vient de la dernière ligne, qui ne compte que 4 pages ; les tranches intermédiaires de 700 à 900 en comptent 28 chacune.\n2. **Les différences de format tirent les scores vers le bas.** Le format de sortie du modèle ne correspond pas exactement à la vérité terrain de Fox ; selon les auteurs, les performances réelles devraient être un peu supérieures à celles du tableau.\n\nPour expliquer la baisse au-delà d'une compression de 10×, les auteurs avancent deux causes possibles : la mise en page plus complexe des longs documents, et le flou des textes longs aux résolutions de 512×512 et 640×640. Ce flou, estiment-ils, peut être vu comme une sorte de « mécanisme d'oubli ».\n\n### Documents réels : OmniDocBench\n\nLa figure de droite et la Table 3 passent à un benchmark réel d'analyse de documents, OmniDocBench. L'article n'en précise pas la version ; le tableau note séparément l'anglais et le chinois, comme le faisait le format antérieur à la v1.5. Tous les indicateurs sont des distances d'édition : plus bas, c'est mieux. Les auteurs insistent sur l'efficacité en tokens :\n\n- Le **mode Small** n'utilise que 100 tokens visuels, pour une distance d'édition globale de 0,221 en anglais, inférieure à celle de GOT-OCR2.0 avec 256 tokens (0,287).\n- Le **mode Gundam**, avec 795 tokens en moyenne, obtient 0,127 en anglais et 0,181 en chinois, mieux que MinerU2.0 et ses 6 790 tokens en moyenne (0,133 et 0,238).\n\nLa Table 4 détaille les résultats par type de document et montre combien de tokens demande chaque type. Les diapositives n'ont qu'une distance d'édition de 0,116 dès le mode Tiny ; livres et rapports s'en sortent bien dès le mode Small. Les journaux sont une tout autre affaire : 0,94 en Tiny, et il faut attendre Gundam pour descendre à 0,122. Les auteurs l'expliquent par les quatre à cinq mille tokens de texte d'une page de journal, bien au-delà de la plage de compression d'environ 10× des autres modes.\n\n### Compression optique et oubli\n\nDans la discussion, les auteurs avancent une idée plus large : dans une conversation à plusieurs tours, les échanges anciens pourraient être rendus en images pour être compressés ; plus un échange est ancien, plus son image serait réduite, avec moins de tokens et un texte plus flou, comme un souvenir humain qui s'estompe.\n\nLes auteurs le reconnaissent eux-mêmes : c'est une exploration très préliminaire. La conclusion le dit clairement : **l'OCR seul ne suffit pas à valider pleinement une véritable compression optique du contexte** ; il faudra encore un préentraînement qui entrelace texte numérique et texte en image, des tests de type « aiguille dans une botte de foin », et d'autres évaluations.\n\n### Le débat après la publication\n\nLa publication a suscité de nombreuses discussions. Dans un message du 20 octobre 2025, Andrej Karpathy juge que c'est un bon modèle d'OCR, mais que ce qui l'intéresse davantage est une autre question : les pixels seraient-ils une meilleure entrée pour un LLM que le texte ? Parmi ses arguments : la compression de l'information, la possibilité de conserver la mise en forme comme le gras et la couleur, et la suppression du tokenizer. [Karpathy, 2025-10-20](https://x.com/karpathy/status/1980397031542989305)\n\nUne réponse venue d'une autre direction a consisté à vérifier quelle part de ces scores élevés venait réellement de l'image. En janvier 2026, « Visual Merit or Linguistic Crutch? » remplace les paragraphes de Fox par des lettres aléatoires : le mode Tiny tombe de 88 % à environ 20 % ; sur les mêmes données, PaddleOCR-v5, qui reconnaît le texte ligne par ligne, ne passe que de 94 % à 90 %.\n\nRevenons à l'application décrite plus haut : quand un token visuel doit correspondre en moyenne à une bonne dizaine de tokens de texte, les connaissances linguistiques du décodeur doivent combler beaucoup de choses. Si le contenu est de l'anglais normal, ces connaissances rendent la compression possible ; si le contenu n'obéit à aucune régularité, elles ne peuvent plus rien combler.\n\n\n> [!TIP]\n> \n> Pour le protocole complet des expériences de perturbation sémantique, voir :\n> \n> - **[[26.01] Linguistic Crutch : Broder a un prix](/blog/papers/model-evaluation/linguistic-crutch)**\n\n\n## Conclusion\n\nDeepSeek-OCR fait de « combien de tokens visuels faut-il pour une page ? » une question mesurable, et y apporte une réponse pratique :\n\n1. **L'agencement de DeepEncoder fonctionne.** Local d'abord, compression ensuite, global enfin : une page de 1024×1024 ne produit que 256 tokens visuels, et la mémoire tient.\n2. **Avec une compression d'environ 10×, les pages anglaises se relisent pour la plupart.** Sur Fox, jusqu'à 10×, la précision est d'environ 97 % ; au-delà, elle commence à baisser, et les chiffres autour de 20× ne reposent que sur quelques pages.\n3. **Comme outil d'OCR, il est très économe en tokens.** Le mode Small dépasse déjà GOT-OCR2.0, et le mode Gundam dépasse MinerU2.0 avec moins d'un huitième des tokens. Les auteurs ajoutent qu'une seule A100-40G peut produire plus de 200 000 pages de données d'entraînement par jour.\n\nQuant à « compresser le long contexte d'un LLM par l'image », l'article n'a fait que le premier pas. Les scores d'OCR prouvent que le décodeur sait restituer le texte, sans dire quelle part de ce texte restitué vient de l'image. Trois mois plus tard, d'autres s'emparaient de la question.\n","imageSizes":{"/content/papers/assets/6f53ecfe63f39804454a69ef4468c93e8018fa1afbe08d1bb52b7e8d52d194c3.png":{"width":1288,"height":350},"/content/papers/assets/45775893f2592575b0f63ed52ce871bcfdd8aacf7f1772a97ee461c2c1e86e52.png":{"width":1272,"height":558}}}