Vision Encoders

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