DeepSeek-OCR

Trait distinctif : un modèle OCR qui traite la vision comme un problème de compression, pas de perception. 97 % de précision avec 10× moins de tokens que les pipelines classiques.

Architecture DeepEncoder

Trois étages avec un goulot explicite entre le traitement local et global.

# Flux conceptuel
DeepEncoder = KnowledgeHead(Compressor(PerceptionHead(Image)))

Étage	Rôle	Coût attention
Perception Head	Attention par fenêtres 8×8 (détails locaux)	O(N·M²), M=64
Conv2D 16×	kernel=4, stride=4 : 4096 → 256 tokens	-
Knowledge Head	Attention globale (structure document)	O(256²) au lieu de O(4096²)

Résultat : ~250× de réduction du coût d'attention globale.

Modes de résolution

Le budget de tokens est un paramètre de design de premier ordre.

Modes natifs (vue unique)

Mode	Résolution	Tokens	Cas d'usage
Tiny	512×512	64	Tickets, formulaires simples
Small	640×640	100	Documents standards
Base	1024×1024	256	Documents denses
Large	1280×1280	400	Layouts complexes

Modes dynamiques (tuiles + vue globale)

# Gundam : n tuiles à 640 (100 tokens/tuile) + 1 global à 1024 (256 tokens)
tokens_total = n * 100 + 256  # n ∈ [2,9]

# Gundam-Master : n tuiles à 1024 (256 tokens/tuile) + 1 global à 1280 (400 tokens)
tokens_total = n * 256 + 400

Tokens valides après padding (documents non carrés)

# Exemple page A4 (2480×3508, ratio ≈ 0.707)
N_valid = floor(N_actual * (min(w,h) / max(w,h)))

# Base mode : floor(256 * 0.707) = 181 tokens valides
# Large mode : floor(400 * 0.707) = 282 tokens valides

Métriques de performance

Comparaison avec les pipelines classiques.

Système	Tokens/page	Précision OCR	Throughput (1×A100-40G)
DeepSeek-OCR (Small)	~100	~97 %	200k pages/jour
DeepSeek-OCR (Base)	~256	~97 %	200k pages/jour
GOT-OCR2.0	256	-	-
MinerU 2.0	~6000	-	-
Qwen-VL	4000-6000	-	-

Compromis compression/précision

• 9-10× compression : ~97 % précision
• 20× compression : ~60 % précision

DeepSeek-OCR vs Qwen-VL

Objectifs différents, architectures différentes.

Aspect	Qwen-VL	DeepSeek-OCR
Philosophie	Comprendre tout	Compresser intelligemment
Tokens/image	4k-16k	64-400
Compression	Aucune (encodeur unique)	Goulot 16× explicite
Meilleur pour	Raisonnement multimodal, vidéo	Archives documents, OCR
Usage contexte LLM	Lourd	Léger

Quand choisir quoi

• Qwen-VL : compréhension multimodale générale, UI, vidéo longue (1M tokens)
• DeepSeek-OCR : extraction de texte à partir de documents, compression pour LLM

Entraînement et fonction de perte

Le décodeur est un petit MoE autorégressif.

# Teacher forcing : à chaque pas t, on donne les vrais tokens précédents
L = -Σ(t=1..T) log p_θ(y_t | y_<t, T_vision)

# Gradient pour logit z_tk
∂L/∂z_tk = p_tk - 1[k == y_t]

# Token correct : (probabilité - 1) → pousse vers le haut si p < 1
# Tokens incorrects : probabilité → pousse vers le bas

Le gradient remonte à travers :

1. Projection de sortie
2. Couches du décodeur (self-attention + MLP)
3. Cross-attention vers les tokens vision
4. Tous les poids de DeepEncoder

Rôle de CLIP dans DeepEncoder

On réutilise uniquement l'encodeur image de CLIP (ViT), pas l'encodeur texte ni la perte contrastive.

# Flux après compression
[256 tokens compressés]
  ↓ Adaptateur linéaire (→ d_clip)
  ↓ + Embeddings positionnels 2D
  ↓ ViT CLIP (attention globale)
  ↓ Adaptateur linéaire (→ d_decoder)
[256 tokens vision pour décodeur]

Initialisation forte, architecture éprouvée, fine-tuné par cross-entropie OCR.

Vision-as-compression pour LLM

Utiliser des tokens visuels pour compresser l'information textuelle.

Workflow

1. Renderer : Convertir texte/PDF long → images 2D (préserve layout)
2. DeepEncoder : Compresser en K tokens vision (100-800 par page)
3. LLM : Cross-attend aux tokens compressés au lieu du texte complet

Quand ça gagne

• PDFs longs avec tableaux, colonnes multiples
• 100-800 tokens vision au lieu de 2000-10000 tokens texte
• Préserve la structure 2D que le texte linéaire perd

Compression hiérarchique pour texte pur (direction future)

# Architecture proposée
1. Attention complète sur fenêtre glissante (W = 4-8k tokens)
2. Conv1D stride-2 sur tokens anciens (KV seulement, pas Q)
3. Keep-gate apprise : préserver tokens importants (entités, nombres)
4. Goulot latent : petit ensemble de latents cross-attend au passé lointain
5. Tokens globaux : quelques-uns par couche pour chemins longue portée

# Entraînement
- Distillation depuis teacher full-attention (perte KL)
- Supervision de gate depuis attention maps du teacher
- Perte de reconstruction sur tokens anciens masqués

Comparaison avec d'autres pipelines

Pour une page 1024×1024.

Approche	Tokens	Avantages	Inconvénients
Two-stage (détecteur → reconnaisseur)	5k-50k	-	Pipeline complexe, difficile à déployer
Multi-crop low-res (InternVL)	~9800	-	Explosion de tokens, vue globale faible
Qwen-VL (NaViT + MRoPE)	4k-6k	Excellent pour multimodal général	Coût activation élevé, gros contexte LLM
DeepSeek-OCR	256	Budget prévisible, rapide, faible mémoire	Compression lourde peut manquer micro-détails

Implications pratiques

Quand utiliser DeepSeek-OCR

• Archives documentaires à grande échelle
• Pipelines avec budget de tokens strict
• Besoin de throughput prévisible (200k pages/jour sur 1 GPU)

Pattern architectural réutilisable

1. Traitement local (détails fins)
2. Compression agressive (goulot explicite)
3. Raisonnement global (sur tokens compressés)

Ce pattern s'applique au-delà de l'OCR : tout domaine nécessitant un résumé efficace d'informations spatiales denses.

Systèmes hybrides futurs

Input Router
├─ Documents denses → DeepEncoder path (compression-first)
├─ Images/vidéo générales → Qwen-VL path (perception-first)
└─ Texte pur → Hierarchical text compression

Architecture détaillée de DeepEncoder

Le flux complet pour une image 1024×1024 :

Étape 1 : Patch embedding

# 1024×1024 divisé en patches 16×16
patches = (1024/16)² = 4096 patches
X₀ ∈ ℝ^(4096 × 768)  # projection linéaire

Étape 2 : Perception Head (window attention)

• Fenêtres locales de 8×8 patches (64 tokens chacune)
• Coût : O(4096 × 64) au lieu de O(4096²)
• Capture les détails locaux : traits de caractères, géométrie des fontes

Étape 3 : Compresseur convolutif 16×

Conv2D(kernel=4, stride=4)
# 64×64 grid → 16×16 grid
# 4096 tokens → 256 tokens

# Agrégation par région 4×4
Y[c,i,j] = Σ W[c,d,u,v] · X[d, 4i+u, 4j+v] + b[c]

Fusionne les tokens caractères en tokens régions (mots, lignes).

Étape 4 : Knowledge Head (attention globale)

• Attention sur 256 tokens seulement
• Coût : O(256²) vs O(4096²) → économie de ~256×
• Apprend la structure documentaire : colonnes, tables, hiérarchies

Étape 5 : Projection finale

T_vision ∈ ℝ^(256 × d_decoder)

Entraînement détaillé

Fonction de perte (cross-entropy autorégressif)

L = -Σ(t=1 to T) log p_θ(y_t | y_<t, T_vision)

Teacher forcing : on donne toujours les vrais tokens précédents (y_{<t}), jamais les prédictions du modèle.

Gradient du softmax

∂L/∂z_tk = p_tk - 1[k = y_t]
# Token correct : pousse vers 1
# Tokens incorrects : pousse vers 0

Le gradient remonte à travers :

1. Projection de sortie
2. Décodeur MoE (self-attention + MLP)
3. Cross-attention vers tokens vision
4. Tout DeepEncoder (y compris la conv 16×)

Rôle de CLIP : seul l'encodeur image ViT est réutilisé (pas le contrastif), comme backbone global préentraîné pour le Knowledge Head. Fine-tuné end-to-end avec la perte OCR.

Tokens valides après padding

Pour documents non carrés (ex: A4 2480×3508, ratio R ≈ 0.707) :

N_valid = ⌊N_actual × (min(w,h) / max(w,h))⌋

# Exemples A4
Base (256 tokens)  → ⌊256 × 0.707⌋ = 181 valides
Large (400 tokens) → ⌊400 × 0.707⌋ = 282 valides

Comparaison pipelines documentaires

Approche	Tokens (1024×1024)	Avantages	Limites
Détecteur + reconnaisseur	5k-50k	-	Pipeline complexe, déploiement lourd
Multi-crop 384×384 (InternVL)	~9.8k	-	Explosion tokens, vue globale faible
Qwen-VL (NaViT + MRoPE)	4k-6k	Excellente compréhension multimodale	Coût activation élevé
DeepSeek-OCR	256	Budget prévisible, rapide	Compression agressive perd micro-détails

Vision-as-compression pour LLM

Utiliser les tokens visuels pour compresser du texte long :

# Workflow
renderer(long_text) → image_2D
DeepEncoder(image) → 100-800 vision tokens
LLM.cross_attend(vision_tokens)  # au lieu de 2k-10k text tokens

Quand utiliser :

• PDFs longs avec tables, multi-colonnes
• Préserver la structure 2D perdue en linéaire
• Économiser 5-10× sur le contexte LLM

Compression hiérarchique pour texte pur

Pattern transposable au texte :

# Architecture proposée
attention_locale(fenêtre W=4-8k tokens)
conv1d_stride2(tokens anciens, KV seulement)
keep_gate(préserver entités, nombres importants)
latent_bottleneck(quelques latents cross-attendent le passé lointain)

Entraînement :

• Distillation depuis teacher full-attention (KL loss)
• Supervision gate depuis attention maps du teacher
• Perte reconstruction sur tokens masqués

Objectif : 40-70% du coût attention pour QA long document.

Systèmes hybrides

Router vers spécialistes :

if dense_document:
    path = DeepEncoder  # compression-first
elif image_or_video:
    path = Qwen_VL      # perception-first
else:
    path = hierarchical_text_compression

Questions ouvertes

• Fallback haute résolution : rajouter des tokens pour régions ambiguës ?
• Budget appris : réseau de politique choisit K par page selon entropie ?
• Fusion multimodale : mixer optimalement tokens vision compressés et texte ?
• Zero-shot compression : appliquer à audio, code, données structurées ?

See also

keras-tensorflow pytorch langchain numpy