Cheatsheets — vue longue

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

Le vrai défi des vision encoders pour LLM n'est pas la perception mais la compression : un document de 50 pages à 4000 tokens/page sature un contexte de 256k avant toute analyse.

Le problème de budget de tokens

Les encoders classiques (CLIP, SigLIP) produisent des représentations coûteuses :

Résolution	Tokens (classique)	Budget consommé (50 pages)
1024×1024	4,096	204,800
1280×1280	6,400	320,000

Une image devient un texte de plusieurs milliers de mots. Pour les tâches long-contexte (analyse de documents, archives, vidéos), cette inefficience bloque des classes entières d'applications.

Architecture à deux étages

La clé : comprimer avant l'attention globale, pas après.

# Ordre conventionnel (inefficace)
patches = patchify(image)           # 4096 tokens
features = global_attention(patches) # O(4096²) mémoire
compressed = project(features)       # 256 tokens

# Ordre optimisé (DeepSeek-OCR)
patches = patchify(image)            # 4096 tokens
local = window_attention(patches)    # O(4096 × window²)
compressed = conv_4x4_stride4(local) # 256 tokens (16× compression)
features = global_attention(compressed) # O(256²) — 256× moins de mémoire

La compression spatiale (stride convolution) réduit la grille de 64×64 à 16×16 avant que l'attention quadratique ne s'applique.

Modes de fonctionnement explicites

Traiter les tokens comme un budget de première classe :

Mode	Tokens/page	Résolution	Précision OCR	Cas d'usage
Tiny	64	512×512	~85%	Screening haute-volume
Small	100	640×640	~92%	Documents standards
Base	256	1024×1024	~97%	Articles techniques
Large	400	1280×1280	~98.5%	Détails fins

Pour les grandes pages, stratégie « Gundam » : n_tiles × 100 + 256 (vue globale).

Entraînement bout-en-bout

Le CLIP-style transformer sert de backbone mais sans contrastive learning.

# Gradient depuis la reconstruction de texte
loss = cross_entropy(decoder_output, ground_truth_text)
loss.backward()  # Flow : text loss → cross-attention → vision encoder

# Le goulot de compression force la sélection de features
# Seules les features prédictives du texte survivent

Le bottleneck de 16× agit comme un filtre d'information : l'encoder apprend à garder ce qui prédit les caractères, écarter le reste (texture, style).

Résultats empiriques

• Fox benchmark : 97% de précision OCR à 9-10× compression
• Throughput : 200,000 pages/jour sur A100
• Mémoire : 256× moins pour l'attention globale (256² vs 4096²)

Compression vs perception

Le choix n'est pas binaire mais dépend de la tâche :

Approche	Tokens/image	Quand l'utiliser
Compressée (DeepSeek-OCR)	64-400	Documents longs, OCR, archivage, génération de données
Généraliste (Qwen2.5-VL)	1024-4096	Raisonnement visuel complexe, diagrammes, agents
Haute fidélité (Qwen3-VL)	4096-16384	Vidéos longues, spatial reasoning, détails géométriques

La compression sacrifie la richesse du raisonnement visuel au profit de l'efficience contextuelle.

Placement de la compression

Principe de design : identifier où réduire la dimensionnalité.

# Anti-pattern : opérations quadratiques sur haute résolution
expensive = global_attention(high_res_tokens)  # Puis compresser

# Pattern optimal : comprimer avant scaling quadratique
compressed = spatial_downsample(high_res_tokens)
cheap = global_attention(compressed)

La position du compresseur dans le pipeline détermine les caractéristiques d'efficience du système.

Questions ouvertes

Limite de compression : Le régime 20× montre ~60% de précision. Où se situe l'effondrement sémantique ?

Préservation géométrique : Les RoPE multi-résolution (Qwen3-VL) maintiennent les relations spatiales. La compression agressive casse-t-elle les priors géométriques pour les tables/diagrammes ?

Budgeting adaptatif : Allouer plus de tokens aux régions denses (équations, tableaux) et moins au texte courant ?

Frontière de Pareto : Quelle est la surface d'échange compression/taille/précision ?

Compress before global attention

Le placement de la compression dans le pipeline change radicalement l'efficacité mémoire.

Architecture DeepEncoder :

1. Perception head : window attention locale (64×64 patches → 4,096 tokens, pas de réduction)
2. Compression : convolution 4×4 stride 4 (4,096 → 256 tokens, 16× reduction)
3. Knowledge head : CLIP ViT avec global self-attention sur les 256 tokens compressés

Gain mémoire : O(256²) vs O(4,096²) = 256× moins de mémoire pour l'attention globale.

# Principe architectural
local_features = window_attention(patches)      # 4096 tokens
compressed = conv_4x4_stride4(local_features)  # 256 tokens (16×)
global_features = global_attention(compressed)  # attention quadratique ici

Le point critique : compresser avant les opérations quadratiques, pas après.

Modes de résolution comme paramètres budgétaires

Token budget explicite au lieu de propriété émergente.

Mode	Tokens/page	Résolution	OCR Precision	Use case
Tiny	64	512×512	~85%	High-volume screening
Small	100	640×640	~92%	Standard documents
Base	256	1024×1024	~97%	Technical papers
Large	400	1280×1280	~98.5%	Fine detail preservation

Tiling "Gundam" pour documents larges : n × 100 + 256 tokens (n tuiles locales + 1 vue globale).

Le budget devient prévisible et schedulable.

Entraînement end-to-end sur reconstruction de texte

Pas de contrastive learning CLIP, malgré l'architecture CLIP.

• Loss : cross-entropy du décodeur sur les tokens de texte ground-truth
• Gradient : ∂L/∂logits = p(predicted) − 𝟙_ground_truth remonte jusqu'au vision encoder
• Effet du bottleneck : la compression 16× force l'encoder à ne garder que les features pertinentes pour reconstruire le texte (caractères, mise en page), pas la texture

Training insight : le ratio de compression agit comme information bottleneck, sélectionnant automatiquement les features OCR-relevant.

Résultats empiriques DeepSeek-OCR

• 97% OCR precision à 9-10× compression (Fox benchmark)
• SOTA accuracy/token sur OmniDocBench
• Throughput : ~200,000 pages/jour sur 1× A100

Dégradation : à 20× compression, précision ~60% (encore utile pour certaines tâches).

Trade-off : compression vs perception breadth

Compression-focused (DeepSeek-OCR) :

• Document processing à grande échelle
• Data generation
• Archival applications
• Token efficiency prime

Generalist VLM (Qwen2.5-VL, Qwen3-VL) :

• Visual reasoning complexe
• Long-form video understanding
• Diagram parsing fin
• Préservent plus de tokens pour reasoning riche

Le choix dépend du contexte d'usage, pas d'une supériorité absolue.

Questions ouvertes

• Compression limits : à quel ratio la semantic collapse survient-elle ?
• Geometric preservation : l'aggressive compression sacrifie-t-elle les priors spatiaux (tables, diagrammes) ?
• Adaptive budgeting : allouer plus de tokens aux régions denses (formules, tables) ?
• Cross-modal compression : le principe s'étend-il à video, audio, 3D point clouds ?
• Architecture search : frontière de Pareto compression/qualité/coût ?

See also

numpy pour la manipulation de patches et grilles spatiales
pytorch pour implémenter les architectures de compression
langchain pour intégrer les encoders dans des pipelines multimodaux
keras-tensorflow pour les stratégies de training bout-en-bout