DeepSeek-OCR en local : lire ses PDF scannés
DeepSeek-OCR est un modèle de vision d'environ 3 milliards de paramètres, publié sous licence MIT, conçu pour transformer l'image d'une page en texte structuré, Markdown compris. Ce guide montre comment faire tourner deepseek ocr en local avec Ollama : quelle version du runtime, combien de mémoire prévoir, comment découper un PDF scanné en pages et récupérer un Markdown exploitable par un RAG. Il se termine par les cas où un outil plus simple fait mieux l'affaire.
#Pourquoi DeepSeek-OCR plutôt qu'un OCR classique
Un PDF scanné ne contient pas de texte, seulement des images de texte. Un moteur d'OCR classique comme Tesseract en tire des lignes brutes : il ne sait pas qu'un bloc est un titre, il casse les tableaux et il perd l'ordre de lecture d'une page en deux colonnes. DeepSeek-OCR prend le problème autrement. C'est un modèle de vision-langage : il regarde la page entière, puis génère directement du Markdown avec ses titres, ses listes, ses tableaux et ses formules.
Le modèle a été publié par DeepSeek à l'automne 2025 avec un article intitulé « Contexts Optical Compression ». L'idée centrale est de représenter une page par un petit nombre de jetons visuels, entre 64 et 400 selon le mode de résolution, au lieu des milliers de jetons de texte qu'elle contiendrait. L'éditeur annonce une précision de décodage d'environ 97 % quand le ratio de compression reste inférieur à dix. C'est son chiffre, mesuré sur ses propres jeux de données, pas le nôtre : retenez surtout que le modèle est léger et rapide pour ce qu'il fait.
Pour un usage local, trois choses comptent. Le modèle tient sur une carte graphique d'entrée de gamme. Il sort du Markdown que l'on peut indexer tel quel dans une chaîne de RAG. Et il est disponible dans la bibliothèque Ollama, ce qui évite d'installer PyTorch, Flash Attention et vLLM comme l'exige le dépôt officiel. Les spécifications complètes sont sur la fiche modèle : https://quelllm.fr/modele/deepseek-ocr
#Prérequis et mémoire à prévoir
Tes documents, ton IA : un RAG local fiable sur tes PDF, notes et mails — sans rien envoyer dans le cloud.
- Espace en ligne à vie
- PDF + fichiers
- Mises à jour à vie
La fiche modèle du site donne les repères de VRAM par précision : environ 2 Go en Q4, 4 Go en Q8 et 6 Go en FP16, pour un contexte de 8 192 jetons. Le poids réel à télécharger dépend de ce qu'Ollama a empaqueté dans le tag ; la page des tags de la bibliothèque affiche la taille du fichier, et c'est elle qui fait foi. Ajoutez à cela la mémoire du contexte : une page dense convertie en Markdown peut produire plusieurs milliers de jetons de sortie.
- GPU NVIDIA
- Toute carte de 8 Go ou plus est confortable. Une RTX 3060 12 Go ou une RTX 4070 12 Go font tourner le modèle en FP16 avec de la marge pour le contexte.
- Mac Apple Silicon
- Ollama utilise la mémoire unifiée. Un Mac avec 16 Go suffit pour le modèle seul ; comptez 24 Go si vous voulez garder un modèle de chat chargé à côté pour le RAG.
- Sans GPU
- Possible, mais l'encodage de l'image et la génération du Markdown se font sur le processeur. Pour quelques pages c'est tolérable ; pour un lot de cent pages, attendez-vous à des minutes par page selon la machine.
- Logiciels
- Ollama à jour, poppler-utils pour découper les PDF, et Python 3 avec la bibliothèque ollama si vous voulez automatiser le traitement par lot.
#Étape 1 : vérifier Ollama et récupérer le bon tag
DeepSeek-OCR est arrivé dans la bibliothèque Ollama fin 2025, après la sortie du modèle. Il repose sur un encodeur visuel particulier, DeepEncoder, qui combine un module de fenêtres locales et un module d'attention globale. Ollama a dû ajouter la prise en charge de cette architecture dans son moteur : un runtime antérieur télécharge les poids mais refuse de les charger, avec un message indiquant que le modèle nécessite une version plus récente. La page de la bibliothèque affiche la version minimale requise quand elle s'applique.
La commande show est la seule source fiable pour savoir ce que vous venez de télécharger : elle indique la famille du modèle, le nombre de paramètres, la longueur de contexte et le niveau de quantification. Si le tag latest et le tag 3b pointent vers le même condensat, peu importe celui que vous utilisez ; le guide emploie 3b pour rester explicite.
#Étape 2 : préparer les pages du PDF
Ollama n'ouvre pas de PDF. Il accepte des images, PNG ou JPEG, une par requête. La première opération consiste donc à rastériser le document, page par page. L'outil le plus simple est pdftoppm, fourni avec poppler-utils, disponible sur toutes les distributions Linux et via Homebrew sur macOS.
La résolution mérite une minute de réflexion. DeepSeek-OCR travaille à des résolutions fixes : 512, 640, 1024 ou 1280 pixels de côté selon le mode, plus un mode dynamique appelé Gundam qui découpe la page en tuiles de 640 pixels autour d'une vue globale de 1024. Une page A4 rastérisée à 200 points par pouce mesure environ 1 650 par 2 340 pixels ; Ollama la redimensionne avant de l'envoyer à l'encodeur. Monter à 300 points par pouce n'apporte rien au modèle, et grossit inutilement les fichiers. Descendre à 100 fait perdre les petits caractères des notes de bas de page avant même que le modèle les voie.
Si le scan est de travers ou très contrasté, le modèle s'en sort généralement mieux qu'un OCR ligne par ligne, mais un redressement préalable reste bénéfique. Le guide Tesseract du site détaille les prétraitements utiles, qui s'appliquent ici aussi : https://quelllm.fr/guide/tesseract-ocr-guide-local
#Étape 3 : obtenir du Markdown avec deepseek ocr
Le dépôt officiel documente plusieurs consignes, chacune déclenchant un comportement différent du modèle. Les deux principales sont « Convert the document to markdown. » pour une conversion structurée, et « Free OCR. » pour une transcription brute sans mise en forme. Les consignes sont en anglais dans l'entraînement ; gardez-les telles quelles, le texte reconnu sort dans la langue du document. Avec le client en ligne de commande, le chemin de l'image se place directement dans le prompt.
La même opération via l'API locale, qui écoute par défaut sur http://localhost:11434, encode l'image en base64 dans le champ images. C'est la voie à privilégier dès que vous enchaînez des pages ou que vous appelez le modèle depuis un autre programme.
Deux options méritent d'être fixées. La température à zéro rend la sortie reproductible, ce qui est ce que l'on attend d'un OCR. Le contexte à 8 192 jetons correspond à la limite du modèle ; en dessous, une page dense peut être tronquée en pleine cellule de tableau. Le dépôt officiel mentionne aussi des consignes dédiées pour décrire une figure ou localiser du texte avec des coordonnées ; elles servent peu pour un simple PDF à indexer.
#Étape 4 : traiter un PDF entier
Pour un document de plusieurs dizaines de pages, un script Python de quelques lignes suffit. Il parcourt les images dans l'ordre numérique, appelle Ollama page après page, retire les balises de localisation que le modèle peut insérer, et concatène le tout dans un seul fichier Markdown avec un marqueur par page. Le marqueur est utile ensuite pour retrouver la page source d'un passage cité par votre RAG.
Chaque appel est indépendant : le modèle ne garde aucune mémoire de la page précédente. C'est une limite pour les tableaux qui s'étalent sur deux pages, et un avantage pour la robustesse, puisqu'une page ratée n'en contamine pas une autre. Ollama charge le modèle une fois et le garde en mémoire entre les appels, selon la valeur de la variable OLLAMA_KEEP_ALIVE ; vous ne payez le temps de chargement qu'au début du lot.
Si vous disposez d'une carte avec de la marge, l'option OLLAMA_NUM_PARALLEL permet de traiter plusieurs pages en même temps, au prix d'une VRAM supplémentaire pour chaque contexte. Sur une carte de 12 Go, deux requêtes parallèles restent raisonnables avec un modèle de cette taille ; vérifiez avec nvidia-smi que vous ne débordez pas en mémoire système, car le ralentissement est alors brutal.
#Étape 5 : nettoyer et contrôler la sortie
Le Markdown produit est bon à lire, pas forcément bon à indexer tel quel. Avant de l'envoyer dans une base vectorielle, passez en revue trois points.
- 01Les balises résiduellesAvec la consigne de conversion, le modèle est entraîné avec un jeton de localisation et peut renvoyer des coordonnées entre balises ref et det. Le script ci-dessus les retire. Vérifiez qu'il ne reste pas non plus de balise image ou de fragment de consigne en tête de fichier.
- 02Les chiffres et les tableauxUn modèle de vision-langage génère du texte ; il peut donc inventer une valeur plausible dans une cellule illisible, là où un OCR classique aurait laissé un caractère aberrant. Ouvrez les tableaux financiers ou techniques côte à côte avec le scan et comparez une ligne sur dix. Pour des factures, le guide dédié du site explique comment croiser avec des totaux : https://quelllm.fr/guide/extraction-factures-ocr-llm
- 03Les en-têtes et pieds de pageNuméros de page, nom du document, mentions légales répétées : ils sortent sur chaque page et polluent le découpage en segments. Une expression régulière sur les lignes identiques présentes dans plus de la moitié des pages suffit en général à les retirer.
- 04Les accents et la typographie françaiseL'éditeur annonce un entraînement sur une centaine de langues. Contrôlez tout de même les lettres accentuées, les guillemets français et les espaces insécables avant les signes doubles sur un échantillon : c'est là que se logent les erreurs discrètes qui faussent ensuite une recherche lexicale.
Une fois le fichier propre, il entre dans une chaîne de RAG comme n'importe quel Markdown : découpage par titres, embeddings, base vectorielle. L'introduction au RAG local du site reprend ces étapes : https://quelllm.fr/guide/rag-local-introduction
#Limites et dépannage
- Le modèle répond sans regarder l'image
- Soit Ollama est trop ancien pour cette architecture, soit l'image n'a pas été transmise. En ligne de commande, le chemin doit être absolu ou relatif au répertoire courant, sans guillemets autour du chemin lui-même. Par l'API, vérifiez que le champ images contient bien du base64 sans retour à la ligne.
- Sortie coupée au milieu d'un tableau
- Le contexte est trop court pour la page. Passez num_ctx à 8192 si ce n'était pas fait. Si la page dépasse encore, scindez-la en deux images, haut et bas, avec un recouvrement de quelques lignes.
- Page lue dans le désordre
- Sur une mise en page à trois colonnes ou un formulaire à cases, le modèle peut mélanger les blocs. Essayez la consigne Free OCR, qui suit l'ordre spatial plus simplement, ou passez par Docling, dont l'analyse de mise en page est explicite.
- Lenteur anormale
- Vérifiez avec ollama ps que le modèle est bien chargé sur le GPU et non partiellement sur le processeur. Un contexte trop grand ou un second modèle chargé peuvent le faire déborder en mémoire système.
- Texte manuscrit
- DeepSeek-OCR est entraîné sur des documents imprimés et des rendus de pages. Sur une écriture manuscrite, les résultats varient fortement ; ne comptez pas dessus sans essai préalable.
- Documents longs et contexte entre pages
- Chaque page est traitée isolément. Un tableau qui continue sur la page suivante perd ses en-têtes ; il faut les réinjecter à la main ou avec une règle de post-traitement.
#Quand PaddleOCR, Docling ou Tesseract suffisent
DeepSeek-OCR n'est pas la réponse à tous les scans. Il brille quand la page a une structure à conserver et que vous voulez du Markdown sans assembler un pipeline. Dans beaucoup de cas courants, un outil plus simple ou plus spécialisé fait aussi bien, pour moins de ressources et avec moins de risque d'invention.
- Tesseract
- Du texte propre, imprimé, sur fond blanc, en grande quantité, et vous n'avez besoin que du texte. Il tourne sur le processeur, ne génère rien et donc n'invente rien. Guide : https://quelllm.fr/guide/tesseract-ocr-guide-local
- PaddleOCR
- Du texte placé n'importe où sur la page, des scans inclinés, des tableaux à reconstituer avec une étape de détection explicite avant la lecture. Sa variante VL est elle aussi un modèle de vision, plus petit que DeepSeek-OCR. Guide : https://quelllm.fr/guide/paddleocr-vl-ocr-local
- Docling
- Des PDF natifs, des DOCX, des présentations : des documents qui contiennent déjà du texte et dont il faut surtout récupérer la mise en page et les tableaux. Docling peut appeler un moteur d'OCR pour les pages image, mais son cœur est l'analyse de structure. Guide : https://quelllm.fr/guide/docling-conversion-documents-ia
- DeepSeek-OCR
- Des scans ou des photos de pages avec titres, listes, tableaux ou formules, et le besoin d'un Markdown prêt à indexer en une seule passe, sur une carte graphique modeste.
Un critère tranche souvent : si une erreur dans un chiffre a des conséquences, préférez un outil qui reconnaît sans générer, ou doublez la lecture avec un second moteur et comparez les sorties. Si la priorité est de rendre lisible et interrogeable un fonds de documents hétérogènes, le Markdown de DeepSeek-OCR fait gagner du temps à chaque étape suivante.
#Pour aller plus loin
- Fiche modèle DeepSeek-OCR
- Paramètres, VRAM par précision, licence et commande d'installation. https://quelllm.fr/modele/deepseek-ocr
- Installer Ollama
- L'installation sur Windows, macOS et Linux, les commandes de base et le dépannage. https://quelllm.fr/guide/installer-ollama
- RAG local sans coder
- Brancher le Markdown obtenu sur Open WebUI ou AnythingLLM pour interroger ses documents. https://quelllm.fr/guide/rag-local-ollama-sans-coder
- Sources officielles
- Dépôt GitHub deepseek-ai/DeepSeek-OCR (code, consignes, scripts vLLM pour PDF), page Hugging Face deepseek-ai/DeepSeek-OCR (poids et licence MIT), page Ollama ollama.com/library/deepseek-ocr (tags, taille et version minimale).
Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.