Benchmark de latence OCR
p50/p95, débit et pics extrêmes (2026)

Trois mesures, une page : p50, p95 et pages/min

Cette page présente trois mesures des mêmes exécutions, qui répondent à des questions différentes. p50 (la médiane) est le temps d'inférence par page en régime stable en mode warm_then_scored — un passage de chauffe fixe précède le passage mesuré, et le chargement du modèle est exclu — il répond donc à la question « à quelle vitesse cet moteur traite-t-il une page une fois qu'il est déjà en marche ? ». p95 est la même mesure au 95e percentile : 5 % des pages ont pris plus de temps. Pages par minute est le débit en temps réel, incluant l'initialisation du modèle — le chiffre qui détermine les travaux par lots et les heures GPU facturées.

Les trois mesures ne sont pas interchangeables et ne sont pas censées concorder. Le p50 en régime stable exclut le chargement du modèle ; les pages/min en temps réel l'incluent ; le p95 capture les effets de la première page/du préremplissage et le comportement de l'ordonnancement par lots que le p50 ignore. Chaque graphique et tableau de cette page indique quelle mesure il présente — considérez « 108,7 ms » (p50, sans chargement) et « 449 pages/min » (temps réel, avec chargement) comme deux faits différents sur docTR, pas une contradiction.

Trois termes utilisés tout au long : la latence de queue est le comportement des quelques pour cent de pages les plus lentes (p50 et au-delà) — pour un utilisateur attendant une seule page, c'est la queue, et non la médiane, qui détermine l'expérience. L'effet de première page/préremplissage est le coût unique de préparation d'un modèle ou d'un pipeline avant l'inférence en régime stable, qui se manifeste par des échantillons initiaux lents dans une exécution. Le débit en temps réel compte chaque milliseconde de l'exécution, y compris l'initialisation. Sur le protocole de ce benchmark, p50/p95 sont des mesures en régime stable et pages/min est en temps réel — l'écart entre eux est l'initialisation plus la surcharge d'ordonnancement.

SROIE 2019 : Classement de la latence médiane par page

Sur 361 reçus en anglais, les moteurs OCR traditionnels à deux étapes se situent à l'extrémité rapide et les VLM d'analyse de documents à l'extrémité lente — mais l'écart au sein de chaque famille est la surprise. docTR (108,7 ms) est 2,7× plus rapide que le moteur traditionnel suivant (PaddleOCR, 297,0 ms), et les deux moteurs les plus lents sont des VLM (Unlimited-OCR 1 600,7 ms, Surya2 2 668,0 ms). Pourtant, le VLM le plus rapide, PaddleOCR-VL à 694,3 ms, est toujours plus lent que tous les moteurs traditionnels.

Source : summary_metrics.csv — colonne latency_p50_ms, lignes sroie_2019. docTR 108,7, PaddleOCR 297,0, EasyOCR 413,6, Tesseract 670,9 (CPU uniquement), PaddleOCR-VL 694,3, Docling 732,0, Unlimited-OCR 1600,7, Surya2 2668,0. Latence en régime permanent, mode de mesure chauffage puis notation (exclut le chargement du modèle).

Tableau : summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute, lignes sroie_2019 (361 échantillons chacune, error_rate 0.0 pour les 8). Rapports p95/p50 calculés par division des valeurs du CSV (ex. 3331.3505 / 296.9897 = 11.22). Tesseract exécuté en CPU uniquement (compute_type=cpu) ; tous les autres sur GPU. La latence à l'état stable exclut le chargement du modèle ; pages/min est le temps réel incluant l'initialisation.

Le schéma architectural est clair au niveau des familles — les moteurs traditionnels occupent les rangs 1 à 4, les VLM les rangs 5, 7, 8, avec Docling (un analyseur en pipeline, ni un pur moteur OCR ni un VLM) au milieu — mais l'écart au sein de chaque famille est important. Le groupe des VLM s'étend sur 3,8× (694,3 à 2 668,0 ms) et le groupe traditionnel sur 6,2× (108,7 à 670,9 ms), ce qui signifie que « VLM » et « traditionnel » ne sont pas des catégories de latence — la conception individuelle du moteur compte bien plus que l'appartenance à une famille.

p50 masque la queue : rapports p95/p50 par moteur

La médiane est un mauvais prédicteur du pire cas. Le p95 de PaddleOCR sur SROIE (3 331,4 ms) est 11,2× sa p50 (297,0 ms) — 5 % des pages ont pris plus de 3,3 secondes alors que la page médiane a pris moins de 300 ms. Pour les charges de travail interactives, c'est ce ratio, et non la p50, qui détermine si un utilisateur attend 0,3 seconde ou 3,3. Le p95 de docTR (281,4 ms) reste serré à 2,6× sa p50.

Le mécanisme est l'effet de première page/remplissage préalable : les moteurs GPU paient un coût d'amorçage unique avant l'inférence en régime stable, et l'ordonnancement par lots peut séquencer les échantillons lents. Il s'agit d'un comportement spécifique au protocole — ces valeurs de p95 reflètent le schéma d'exécution de ce benchmark (partition de test fixe, préchauffage puis notation), et non une propriété universelle des moteurs. Ce que les données montrent, c'est la forme de la queue de chaque moteur sous ce protocole : PaddleOCR et Docling ont des queues longues et lourdes sur SROIE ; docTR, EasyOCR et Unlimited-OCR maintiennent les leurs proches de la médiane.

Source : calculé à partir de summary_metrics.csv — latency_p95_ms ÷ latency_p50_ms, lignes sroie_2019 (ratio dérivé par division des valeurs publiées, par ex. 3331,3505 / 296,9897 = 11,22). PaddleOCR 11,2×, Docling 4,4×, docTR 2,6×, EasyOCR 2,3×, Tesseract 2,2×, Surya2 2,2×, PaddleOCR-VL 1,7×, Unlimited-OCR 1,6×.

Remarquez ce que le ratio ne dit pas : un rapport p95/p50 serré n'est pas une affirmation de vitesse. Unlimited-OCR a la queue la plus serrée du benchmark (1,6×) — mais sa p50 (1 600,7 ms) et son p95 (2 521,9 ms) sont tous deux bien plus lents que le p95 de docTR (281,4 ms). Le ratio mesure la forme de la distribution, pas la position de la distribution. Lisez les deux chiffres ensemble : une queue serrée autour d'une médiane lente reste lente.

Le débit raconte une autre histoire : pages/min vs p50

Classe les moteurs par pages par minute et l'ordre change. Les 449,3 pages/min de docTR’s par rapport aux 12,1 de Surya2’s représentent un écart de 37× — plus large que l'écart de 24,5× en p50. Mais PaddleOCR, avec une queue p95 de 11,2×, maintient toujours 79,7 pages/min : proche des 124,5 d'EasyOCR, devant les 68,2 de PaddleOCR-VL et les 56,7 de Docling. Une médiane lente et une queue lourde n'empêchent pas un débit par lots respectable.

La réconciliation réside dans la base de mesure : pages/min est le débit temps réel incluant l'initialisation du modèle et la planification, tandis que p50 est l'inférence sur une page en régime stable, hors chargement. Le tableau ci-dessous convertit les pages/min en le temps réel moyen par page qu'elles impliquent (60 000 ÷ pages/min — une estimation dérivée, non une mesure) et montre l'écart par rapport au p50. Le temps réel implicite par page de PaddleOCR (752,7 ms) est 2,5× son p50 en régime stable (297,0 ms) ; celui de Surya2 (4 940,0 ms) est 1,9× son p50 (2 668,0 ms). La surcharge — initialisation, planification, coûts du pipeline par appel — est invisible dans le seul p50, c'est pourquoi un p50 bas ne signifie pas automatiquement un débit élevé.

Tableau : summary_metrics.csv — latency_p50_ms / pages_per_minute, lignes sroie_2019. Le ms/page horloge est une estimation calculée (60,000 ÷ pages_per_minute, par ex. 60,000 / 79.7130 = 752.7) — un calcul sur le débit mesuré, pas une mesure séparée. Surcharge = ms/page horloge calculé ÷ p50 mesuré. Pages/min est le temps horloge incluant l'initialisation du modèle ; p50 est l'état stable hors chargement.

Une seconde note de réconciliation sur les extrêmes : Tesseract, le seul moteur CPU, maintient 78.6 pages/min sur SROIE — soit essentiellement l'équivalent des 79.7 de PaddleOCR sur GPU — avec son p50 (670.9 ms, CPU) et son temps horloge (763.0 ms) quasi identiques, car un moteur CPU mono-thread a peu de surcharge d'initialisation à masquer. Son p95 (1,507.0 ms) est 2.2× son p50 — l'une des queues les plus serrées du benchmark. La parité de débit CPU-vs-GPU est analysée en détail dans Tesseract vs PaddleOCR.

Interactif vs par lots : la lecture du seuil de 1 000 ms

Pour un utilisateur attendant une seule page, 1 000 ms est une limite utile — à peu près la frontière de ce qui semble réactif. Lu au p50, six moteurs sur huit restent en dessous sur SROIE : docTR (108,7 ms), PaddleOCR (297,0 ms), EasyOCR (413,6 ms), Tesseract (670,9 ms, CPU), PaddleOCR-VL (694,3 ms), Docling (732,0 ms). Seuls Unlimited-OCR (1 600,7 ms) et Surya2 (2 668,0 ms) le dépassent à la médiane.

Lu au p95, l'image s'inverse : seuls deux moteurs tiennent encore sous la seconde — docTR (281,4 ms) et EasyOCR (960,4 ms). La queue de tous les autres la dépasse : PaddleOCR 3 331,4 ms, Docling 3 239,8 ms, Unlimited-OCR 2 521,9 ms, Tesseract 1 507,0 ms, PaddleOCR-VL 1 154,3 ms, Surya2 5 872,2 ms (summary_metrics.csv latency_p95_ms, lignes sroie_2019). Si « interactif » signifie que le pire cas doit sembler réactif, c'est la queue — et non la médiane — qui est le critère de sélection, et seuls deux moteurs sont qualifiés.

Le traitement par lots est l'autre régime, et il change l'économie en faveur des moteurs. L'initialisation du modèle est payée une seule fois par processus/lots, donc le traitement séquentiel ou par lots amortit le coût d'initialisation sur plus de pages — la latence par page et le coût par page diminuent tous deux à mesure que la taille du lot augmente. C'est un argument dérivé de la base de mesure (pages/min inclut l'init ; p50 l'exclut), pas un nouveau benchmark — le même raisonnement et son calcul détaillé apparaissent dans la méthode de la page coût.

CORD (reçus indonésiens) : même scénario, queues différentes

Changez le jeu de données et les classements restent à peu près les mêmes — docTR reste le plus rapide et Surya2 le plus lent — mais le changement de langue remodèle les queues. Sur CORD v2, la p95 de Surya2 explose à 26 976,9 ms (≈27 s), soit 18,2× sa propre p50 (1 485,3 ms) et l'événement extrême de queue du benchmark — tandis que son rapport de queue sur SROIE était modeste (2,2×). Le contenu linguistique modifie le comportement des queues ; un VLM stable sur des reçus en anglais peut atteindre des attentes de demi-minute sur des reçus indonésiens.

CORD v2 est un jeu de données en indonésien avec des champs imbriqués (menu, sub_total, total) ; aucun des 8 moteurs n'a été principalement entraîné sur de l'indonésien, ce qui en fait aussi un test de stress multilingue. Ses reçus sont plus courts et moins denses en texte que ceux de SROIE, ce qui explique pourquoi la plupart des moteurs sont plus rapides ici — docTR descend à 100,4 ms p50 (500,4 pages/min), PaddleOCR à 108,2 ms p50 (141,0 pages/min). CORD est volontairement séparé du classement SROIE dans ce benchmark (langue différente, structure de vérité terrain différente) ; l'intérêt de ce tableau est de montrer que la latence évolue avec le jeu de données et que les queues peuvent se déplacer de manière spectaculaire.

Source : summary_metrics.csv — colonne latency_p50_ms, lignes cord_v2. docTR 100,4, PaddleOCR 108,2, EasyOCR 192,8, PaddleOCR-VL 249,3, Docling 338,0, Tesseract 474,6 (CPU uniquement), Unlimited-OCR 608,2, Surya2 1485,3. Latence en régime permanent, warm-then-scored (exclut le chargement du modèle).

Tableau : summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute, lignes cord_v2 (100 échantillons chacune). Les rapports p95/p50 sont calculés par division des valeurs du CSV (ex. 26976.9306 / 1485.3493 = 18.16). Tesseract a fonctionné en CPU uniquement. La latence à l'état stable exclut le chargement du modèle ; pages/min est le temps réel incluant l'initialisation.

Le p95 de Surya2 sur CORD de 26 976,9 ms est le plus grand événement de queue du benchmark — une page sur vingt a pris environ 27 secondes sur un jeu de données où sa médiane était de 1,5 seconde. À titre de comparaison, c'est 114× le p95 de docTR sur CORD (235,9 ms). Deux moteurs quasi identiques sur SROIE (ratios de queue de 2,2× pour Surya2 et 1,6× pour Unlimited-OCR) divergent fortement sur CORD (18,2× contre 2,4×) — un rappel que le comportement de queue est une propriété de la combinaison moteur × document, pas du moteur seul.

Latence et coût tournent sur la même horloge

Comme les GPU loués sont facturés à l'heure réelle, la latence et le coût sont la même mesure vue deux fois : docTR est à la fois le moteur le plus rapide (p50 de 108,7 ms) et le moins cher (coût pour 1 000 pages de 0,0479 sur SROIE) ; Surya2 est à la fois le plus lent (p50 de 2 668,0 ms) et le plus cher (1,0609) — même répartition, même tarif. Les lourds VLMs sont lents et chers ensemble ; les moteurs traditionnels légers sont rapides et bon marché ensemble.

La corrélation n'est pas exacte, car le coût suit le débit en pages par minute (qui inclut l'initialisation) tandis que le p50 l'exclut — le p50 de PaddleOCR (297,0 ms) est plus rapide que celui d'EasyOCR (413,6 ms), pourtant le coût pour 1 000 pages de PaddleOCR (0,2214) est environ le double de celui d'EasyOCR (0,1098) car son débit réel est bien plus faible (79,7 contre 124,5 pages/min ; summary_metrics.csv cost_per_1000_pages / pages_per_minute, lignes sroie_2019). Le classement complet des coûts, la formule de calcul et l'arithmétique derrière se trouvent sur la page sœur Coût OCR pour 1 000 Pages — cette page se concentre sur la latence et n'emprunte que la corrélation.

Foire aux questions

Quel est le moteur OCR le plus rapide par page ?

docTR était le plus rapide dans ce benchmark : 108,7 ms p50 et 281,4 ms p95 par page sur SROIE 2019 (summary_metrics.csv latency_p50_ms / latency_p95_ms, ligne doctr/sroie_2019), atteignant 449,3 pages/min. Le plus lent mesuré, Surya2, était 24,5× plus lent en p50 (2 668,0 ms) et 37× plus lent en débit (12,1 pages/min).

Quelle est la latence OCR typique par page sur un GPU ?

Entre 108,7 ms (docTR) et 2 668,0 ms (Surya2) p50 par page sur 8 moteurs open-source sur un RTX 4090, reçus SROIE 2019 (summary_metrics.csv latency_p50_ms, lignes sroie_2019) — un écart de 24,5× sur du matériel identique. État stationnaire, après chauffe puis mesure, hors chargement de modèle. Les mêmes moteurs sur CORD v2 s'étalent de 100,4 à 1 485,3 ms p50.

Pourquoi la latence p95 OCR est-elle si supérieure à la p50 ?

À cause de l'effet de la première page/prefill et du comportement de planification par lots : les moteurs GPU paient des coûts d'amorçage uniques et les échantillons lents peuvent être sérialisés, donc les 5% de pages les plus lentes — par définition du 95e percentile — s'éloignent de la médiane. Le p95 de PaddleOCR sur SROIE (3 331,4 ms) est 11,2× son p50 (297,0 ms) ; le p95 de docTR (281,4 ms) n'est que 2,6× son p50 (summary_metrics.csv latency_p95_ms / latency_p50_ms, lignes sroie_2019). Les valeurs p95 sont spécifiques au protocole — elles reflètent le mode d'exécution de ce benchmark, pas une propriété universelle du moteur.

Pourquoi la latence OCR et les pages par minute ne correspondent-elles pas ?

Parce que ce sont des mesures différentes. Pages/min est le débit en temps réel incluant l'initialisation du modèle et la planification ; p50 est l'inférence par page en état stationnaire hors chargement de modèle. Sur SROIE, le p50 de PaddleOCR (297,0 ms) implique environ 200 pages/min en état stationnaire pur, mais le débit mesuré est de 79,7 pages/min — un temps réel dérivé de 752,7 ms par page, 2,5× son p50 (summary_metrics.csv latency_p50_ms / pages_per_minute, ligne paddleocr/sroie_2019). Pour les tâches par lots, se baser sur pages/min ; pour les attentes interactives, sur p50 et p95.

Quelle est une bonne latence OCR pour une utilisation interactive ?

Moins de 1 000 ms en p95 est le seuil pratique. Sur SROIE, six moteurs sur huit restent sous 1 seconde au p50 (docTR 108,7, PaddleOCR 297,0, EasyOCR 413,6, Tesseract 670,9, PaddleOCR-VL 694,3, Docling 732,0 ms), mais seul docTR (281,4 ms) et EasyOCR (960,4 ms) maintiennent leur p95 sous 1 seconde (summary_metrics.csv latency_p50_ms / latency_p95_ms, lignes sroie_2019). Si le pire cas doit sembler réactif, c'est le p95 qui décide ; si le cas typique suffit, c'est le p50.

Pourquoi un moteur OCR a-t-il mis 27 secondes sur un reçu ?

Le p95 de Surya2 sur CORD v2 était de 26 976,9 ms (≈27 s) — 18,2× son propre p50 (1 485,3 ms) et le plus grand écart extrême du benchmark (summary_metrics.csv latency_p95_ms / latency_p50_ms, ligne surya2/cord_v2). Son écart sur SROIE était modeste (2,2×), donc le pic est spécifique à la combinaison moteur × CORD — le contenu linguistique et l'ordonnancement ont modifié le comportement des extrêmes, pas seulement la médiane.

Tesseract OCR est-il assez rapide sans GPU ?

Sur CPU, Tesseract a maintenu 78,6 pages/min sur SROIE 2019 avec un p50 de 670,9 ms — plus lent que les moteurs traditionnels sur GPU mais plus rapide que les trois VLM en débit (PaddleOCR-VL 68,2, Docling 56,7, Unlimited-OCR 34,4, Surya2 12,1 pages/min) et avec un écart serré (2,2×). Il est en CPU uniquement dans ce benchmark (summary_metrics.csv ligne tesseract/sroie_2019) ; s'il est « assez rapide » dépend de votre volume et si vous avez besoin de champs plutôt que de texte — voir le profil de coût CPU dans Tesseract vs PaddleOCR.

L'OCR devient-il plus rapide par page à mesure que l'on traite plus de pages ?

Oui, jusqu'à un plancher en régime permanent — comme effet dérivé de la base de mesure, pas d'une nouvelle exécution. L'initialisation du modèle est payée une fois par processus/lot (elle est incluse dans pages/min mais en dehors du p50), donc le traitement par lots ou séquentiel l'amortit : à haut volume, le temps réel par page se rapproche du p50 en régime permanent plus l'ordonnancement. Les chiffres de docTR sur SROIE sont déjà proches de ce plancher (p50 108,7 ms vs temps réel dérivé 133,5 ms par page) ; ceux de Surya2 (p50 2 668,0 vs 4 940,0 ms) montrent plus de surcharge d'initialisation à amortir.

D'où viennent les chiffres de latence sur cette page ?

Chaque chiffre est une ligne du fichier results/summary_metrics.csv (latency_p50_ms, latency_p95_ms, pages_per_minute) publié par le benchmark interne, hébergé sur ImageToTableai/benchmark-ocr, avec un manifest.json masqué par exécution enregistrant le mode de mesure (warm_then_scored), les versions des modèles et les empreintes de l'environnement. Les définitions des jeux de données proviennent des articles SROIE 2019 et CORD cités ci-dessous.

Méthodologie & Sources

Protocole

Cette page présente la dimension latence d'une exécution de benchmark indépendante et reproductible (niveau officiel) — pas un recueil d'affirmations de tiers. Uniquement des partitions de test fixes : SROIE 2019 test (361 reçus anglais, champs plats entreprise/date/adresse/total) et CORD v2 test (100 reçus indonésiens, champs imbriqués menu/sous_total/total) ; les partitions d'entraînement n'ont jamais été évaluées. Chaque paire (moteur × jeu de données) a réutilisé les mêmes images, la même vérité terrain et le même protocole de mesure (warm_then_scored : un passage de chauffage fixe précède le passage mesuré). Les 16 exécutions se sont terminées avec un error_rate de 0.0 (colonne error_rate de summary_metrics.csv). Les données ont été collectées en août 2026.

Environnement d'exécution

• Matériel : toutes les exécutions GPU sur un seul NVIDIA RTX 4090 (24 Go). Tesseract a fonctionné en CPU uniquement (compute_type=cpu) et est étiqueté comme tel dans chaque tableau. Un seul niveau GPU, un seul emplacement/heure — l'énoncé de portée de cette page.
• Moteurs : tous les modèles exécutés tels quels, sans affinage. Versions verrouillées selon les manifests d'exécution : Tesseract 5.3.4, PaddleOCR 3.7.0, EasyOCR 1.7.2, docTR v1.0.1, Docling 2.119.0, Surya2 0.22.1, Unlimited-OCR vLLM-served, PaddleOCR-VL 1.6.
• Mode de mesure : warm_then_scored — les chiffres de latence sont l'inférence par page à l'état stable, hors chargement du modèle ; pages/min est le temps réel incluant l'initialisation du modèle (d'après performance.run_wall_time_ms de chaque exécution dans les manifests masqués).
• Niveau d'exécution : les 16 exécutions sont official ; seules les exécutions officielles sont éligibles à la publication selon le protocole du benchmark (reports/receipt_v1_official_protocol.md).

Définitions des métriques

• p50 (latence médiane) : temps médian d'inférence par page à l'état stable — 50 % des pages étaient plus rapides. Exclut le chargement du modèle (warm-then-scored).
• p95 (latence de queue) : temps d'inférence par page au 95e percentile — 5 % des pages ont pris plus de temps. Reflète les effets de la première page/remplissage et le comportement de planification par lots selon le protocole de cette exécution ; spécifique au protocole, pas une constante universelle du moteur.
• Rapport p95/p50 : obtenu par division des deux colonnes CSV (par ex., 3331.3505 / 296.9897 = 11.22). Indicateur de forme de la queue, pas une affirmation de vitesse.
• Pages par minute : débit en temps réel incluant l'initialisation du modèle. La vue des tâches par lots et de la facturation.
• ms/page en temps réel (calculé) : 60 000 ÷ pages/min — calcul basé sur le débit mesuré, étiqueté comme estimation calculée, pas une mesure directe.

Liste des sources

1. summary_metrics.csv (GitHub raw). 16 lignes = 8 moteurs × 2 jeux de données de reçus (sroie_2019, cord_v2). Les colonnes incluent latency_p50_ms, latency_p95_ms, pages_per_minute, compute_type, error_rate. Toutes les valeurs de latence et de débit de cette page proviennent d'une ligne ici.
2. Dépôt ImageToTableai/benchmark-ocr. Dépôt public hébergeant les CSV de résultats, les manifestes d'exécution expurgés, le protocole figé (reports/receipt_v1_official_protocol.md), et les listes d'échantillons de jeux de données (partitions de test fixes) pour la reproduction.
3. results/manifests/ (GitHub). Un manifeste manifest.json expurgé par exécution publiée (16 exécutions) avec l'empreinte de l'environnement, les versions des modèles, le mode de mesure (warm_then_scored), le temps réel, et les hachages des artefacts.
4. Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019). Définition du jeu de données SROIE 2019, structure de la tâche, et licence (CC-BY-4.0).
5. Park et al., "CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2020). Définition du jeu de données CORD v2, schéma des champs imbriqués, et licence (CC-BY-4.0).

Limitations

• Un seul type de GPU, un seul emplacement/une seule période : toutes les données GPU proviennent d'un seul RTX 4090 sur un seul site, collectées en août 2026. D'autres GPU, le service multi-GPU et des planifications différentes modifient la latence et le débit ; mesurez sur votre propre matériel avant de vous engager.
• Reçus uniquement : reçus SROIE (anglais) et CORD (indonésien). La latence sur des factures, formulaires, contrats ou documents longs n'est pas mesurée ; les classements ci-dessus ne sont pas généralisables au-delà des reçus — et les résultats de CORD ne sont pas fusionnés dans le classement SROIE.
• Le p95 est spécifique au protocole : les valeurs p95 reflètent les effets de la première page/préremplissage et la planification par lots selon le schéma d'exécution de ce benchmark (répartition fixe de 361/100 pages, phase de chauffe puis mesure). Ce sont des lectures de forme de cette exécution, pas une garantie du pire cas universelle.
• p50/p95 excluent le chargement du modèle, pages/min l'inclut : les deux bases sont volontairement différentes (inférence en régime permanent vs débit horloge) et ne sont jamais présentées comme le même chiffre. Le temps horloge dérivé par page (60 000 ÷ pages/min) est un calcul arithmétique sur le débit mesuré, pas une mesure séparée.
• Asymétrie CPU/GPU : Tesseract (CPU) est comparé à des moteurs accélérés par GPU ; sa latence reflète le matériel CPU. Il est indiqué dans chaque tableau, mais l'asymétrie est inhérente à la comparaison.
• Pas de modèles cloud/API : AWS Textract, Google Document AI, Azure AI Document Intelligence et les API OCR/VLM hébergées ne sont pas inclus ; leurs modèles de latence (réseau, facturation à l'appel, autoscaling) diffèrent fondamentalement des moteurs locaux mesurés ici.
• Pas de balayage de taille de lot : l'amortissement d'initialisation est déduit de la base de mesure (pages/min inclut l'init, p50 l'exclut) et recoupé avec la méthode de la page de coût — aucune expérience de taille de lot n'a été menée, donc le passage à l'échelle par lot est une estimation, pas une mesure.
• Taille de l'échantillon et verrouillage des versions : 361 + 100 échantillons ; les résultats valent pour les versions de modèles d'août 2026 listées ci-dessus. De nouvelles versions de moteurs peuvent modifier la latence ; des différences de quelques pourcents doivent être traitées comme du bruit.

Références associées : Coût OCR pour 1 000 pages · OCR traditionnel vs VLM d'analyse de documents · docTR vs Surya2 : CER égal, écart de coût · docTR vs Docling : passage unique vs pipeline · Tesseract vs PaddleOCR : CPU ancien vs GPU moderne

Lectures associées : Précision de l'OCR IA vs OCR traditionnel · Extraction IA de données d'image vs OCR traditionnel · Tarification de l'extraction IA de documents (2026)