Benchmark de latence OCR
p50/p95, débit et pics de queue (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 permanent en mode warm_then_scored — un passage de préchauffage fixe précède le passage noté, et le chargement du modèle est exclu — elle répond donc à la question « quelle est la vitesse de ce moteur par page une fois qu'il tourne ? ». 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 régit les traitements 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 permanent exclut le chargement du modèle ; les pages/min en temps réel l'incluent ; le p95 capture les effets de première page/préremplissage et le comportement d'ordonnancement des lots, que le p50 ignore. Chaque graphique et tableau de cette page indique la mesure qu'il affiche — considérez « 108,7 ms » (p50, sans chargement) et « 449 pages/min » (temps réel, avec chargement) comme deux faits distincts concernant docTR, et non une contradiction.

Trois termes utilisés tout au long : latence de queue désigne le comportement des quelques pour cent de pages les plus lentes (p95 et au-delà) — pour un utilisateur qui attend une seule page, c'est la queue, et non la médiane, qui détermine l'expérience. Effet de première page/préremplissage est le coût ponctuel d'amorçage d'un modèle ou d'un pipeline avant l'inférence en régime permanent, qui se manifeste par des échantillons lents au début d'une exécution. Débit en temps réel compte chaque milliseconde de l'exécution, y compris l'initialisation. Selon le protocole de ce benchmark, p50/p95 sont des mesures en régime permanent et pages/min est en temps réel — l'écart entre eux correspond à l'initialisation plus les frais d'ordonnancement.

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

Sur 361 reçus en anglais, les moteurs OCR traditionnels en deux étapes occupent 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 tous deux des VLM (Unlimited-OCR 1 600,7 ms, Surya2 2 668,0 ms). Pourtant, le VLM le plus rapide, PaddleOCR-VL à 694,3 ms, reste 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 à chaud puis évaluation (hors 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 a tourné en CPU uniquement (compute_type=cpu) ; tous les autres sur GPU. La latence en régime permanent exclut le chargement du modèle ; pages/min est le temps réel incluant l'initialisation.

Le motif d'architecture est clair au niveau de la famille — les moteurs traditionnels occupent les rangs 1–4, les VLM les rangs 5, 7, 8, avec Docling (un analyseur de pipeline, ni un moteur OCR pur ni un VLM) au milieu — mais l'écart au sein de chaque famille est important. Le cluster VLM s'étend sur 3,8× (694,3 à 2 668,0 ms) et le cluster 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 décide bien plus que l'appartenance à une famille.

Le p50 masque la queue : rapports p95/p50 selon les moteurs

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

Le mécanisme est l'effet première-page/préremplissage : les moteurs GPU paient un coût d'initialisation unique avant l'inférence stable, et l'ordonnancement par lots peut sérialiser les échantillons lents. C'est un comportement spécifique au protocole — ces valeurs p95 reflètent le modèle d'exécution de ce benchmark (division de test fixe, échauffement puis évaluation), pas une propriété universelle des moteurs. Ce que montrent les données, 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 gardent la leur proche de la médiane.

Source : calculé à partir de summary_metrics.csv — latency_p95_ms ÷ latency_p50_ms, lignes sroie_2019 (rapport dérivé par division des valeurs publiées, 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×.

Notez ce que le rapport 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 son 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 rapport mesure la forme de la distribution, pas sa position. Lisez les deux nombres ensemble : une queue serrée autour d'une médiane lente reste lente.

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

Classez les moteurs par pages par minute et l'ordre change. Le 449,3 pages/min de docTR contre 12,1 pour Surya2 représente un écart de 37× — plus large que l'écart p50 de 24,5×. Mais PaddleOCR, avec une traîne p95 de 11,2×, maintient tout de même 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 traîne lourde n'empêchent pas un débit de traitement par lots respectable.

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

Tableau : summary_metrics.csv — latency_p50_ms / pages_per_minute, lignes sroie_2019. Le ms/page en temps réel est une estimation dérivée (60 000 ÷ pages_per_minute, p. ex., 60 000 / 79,7130 = 752,7) — un calcul arithmétique sur le débit mesuré, pas une mesure distincte. Surcoût = temps réel dérivé ÷ p50 mesuré. Pages/min est le temps réel incluant l'initialisation du modèle ; p50 est le régime permanent hors chargement.

Une seconde note de rapprochement concernant les extrêmes : Tesseract, le seul moteur CPU, maintient 78,6 pages/min sur SROIE — presque égal au 79,7 de PaddleOCR sur GPU — avec son p50 (670,9 ms, CPU) et son temps réel (763,0 ms) quasi identiques, car un moteur CPU monothread a peu de surcoût d'initialisation à masquer. Son p95 (1 507,0 ms) est 2,2× son p50 — l'une des queues les plus resserrées du benchmark. La parité de débit CPU-vs-GPU est analysée en détail dans Tesseract vs PaddleOCR.

Interactif ou par lot : la lecture du seuil de 1 000 ms

Pour un utilisateur qui attend une seule page, 1 000 ms est une limite utile — à peu près la frontière de ce qui semble réactif. Lu à la 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 à la p95, le tableau 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 moteurs 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 — pas la médiane — qui est le critère de sélection, et seuls deux moteurs sont retenus.

Le traitement par lots est l'autre régime, et il change la donne en faveur des moteurs. L'initialisation du modèle est payée une fois par processus/lot, donc un 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é figurent dans la méthode de la page des coûts.

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

Changez le jeu de documents et les classements tiennent à peu près — docTR reste le plus rapide et Surya2 le plus lent — mais le changement de langue redessine les queues. Sur CORD v2, le p95 de Surya2 explose à 26 976,9 ms (≈27 s), soit 18,2× son propre p50 (1 485,3 ms) et l'événement de queue extrême du benchmark — alors que son ratio de queue SROIE était modeste, à 2,2×. Le contenu linguistique modifie le comportement des queues ; un VLM stable sur des reçus anglais peut grimper à des attentes d'une 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é entraîné principalement sur l'indonésien, ce qui en fait un test de résistance interlangues. Ses reçus sont plus courts et moins denses en texte que ceux de SROIE, c'est pourquoi la plupart des moteurs sont plus rapides ici — docTR descend à 100,4 ms en p50 (500,4 pages/min), PaddleOCR à 108,2 ms en p50 (141,0 pages/min). CORD est délibérément 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 que la latence évolue avec le jeu de documents et que la queue peut bouger de façon 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 état stable, échauffement puis mesure (hors chargement du modèle).

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

Le p95 de Surya2 sur CORD, à 26 976,9 ms, est le plus grand événement de queue de tout le 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. Pour contexte, cela représente 114× le p95 de docTR sur CORD (235,9 ms). Deux moteurs quasi identiques sur SROIE (ratios de queue de 2,2× pour Surya2, 1,6× pour Unlimited-OCR) divergent nettement 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 facturent à l’heure d’horloge murale, la latence et le coût sont la même mesure vue deux fois : docTR est à la fois le moteur le plus rapide (108,7 ms en p50) et le moins cher (cost_per_1000_pages de 0,0479 sur SROIE) ; Surya2 est à la fois le plus lent (2 668,0 ms en p50) et le plus cher (1,0609) — même écart, même taux. Les VLMs lourds 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 les pages/min en temps d’horloge murale (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), et pourtant le coût par 1 000 pages de PaddleOCR (0,2214) est environ le double de celui d’EasyOCR (0,1098), car son débit en temps d’horloge murale est bien inférieur (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 coût et l’arithmétique qui la sous-tend se trouvent sur la page frère OCR Cost per 1,000 Pages — cette page se concentre sur la latence et n’emprunte que la corrélation.

Questions fréquentes

Quel est le moteur OCR le plus rapide par page ?

docTR a été le plus rapide dans ce benchmark : 108,7 ms en p50 et 281,4 ms en p95 par page sur SROIE 2019 (summary_metrics.csv latency_p50_ms / latency_p95_ms, ligne doctr/sroie_2019), soit 449,3 pages/min soutenues. Le plus lent mesuré, Surya2, était 24,5× plus lent au 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) en p50 par page sur 8 moteurs open source sur une 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. En régime permanent, après échauffement et mesure, hors chargement du modèle. Les mêmes moteurs sur CORD v2 s'échelonnent de 100,4 à 1 485,3 ms en p50.

Pourquoi la latence p95 de l'OCR est-elle tellement plus élevée que la p50 ?

À cause de l'effet première page/préremplissage et du comportement d'ordonnancement par lots : les moteurs GPU paient des coûts d'initialisation ponctuels et les échantillons lents peuvent être sérialisés ; les 5 % de pages les plus lentes — par définition du 95e percentile — se situent donc loin 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 schéma 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 l'ordonnancement ; p50 est l'inférence par page en régime permanent hors chargement du modèle. Sur SROIE, le p50 de PaddleOCR (297,0 ms) implique environ 200 pages/min en pur régime permanent, mais le débit mesuré est de 79,7 pages/min — un temps réel dérivé de 752,7 ms par page, soit 2,5× son p50 (summary_metrics.csv latency_p50_ms / pages_per_minute, ligne paddleocr/sroie_2019). Pour les traitements par lots, planifiez autour de pages/min ; pour les attentes interactives, autour de p50 et p95.

Quelle est une bonne latence OCR pour un usage interactif ?

Sous 1 000 ms en queue est le seuil pratique. Sur SROIE, six des huit moteurs restent sous 1 seconde en p50 (docTR 108,7, PaddleOCR 297,0, EasyOCR 413,6, Tesseract 670,9, PaddleOCR-VL 694,3, Docling 732,0 ms), mais seuls docTR (281,4 ms) et EasyOCR (960,4 ms) gardent 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) — soit 18,2× son propre p50 (1 485,3 ms) et le plus grand événement de queue du benchmark (ligne surya2/cord_v2 de summary_metrics.csv latency_p95_ms / latency_p50_ms). Sa queue 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 de queue, 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 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), avec une queue serrée (2,2×). Il est CPU uniquement dans ce benchmark (ligne tesseract/sroie_2019 de summary_metrics.csv) ; pour savoir s'il est « assez rapide », cela dépend de votre volume et de votre besoin en champs plutôt qu'en texte — voir le profil de coût CPU dans Tesseract vs PaddleOCR.

L'OCR devient-il plus rapide par page quand on traite plus de pages ?

Oui, jusqu'à un plancher à l'état stationnaire — comme effet dérivé de la base de mesure, pas d'un nouveau run. 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 : à volume élevé, le temps mural par page approche le p50 à l'état stationnaire plus l'ordonnancement. Les chiffres de docTR sur SROIE sont déjà proches de ce plancher (p50 108,7 ms vs temps mural dérivé de 133,5 ms par page) ; ceux de Surya2 (p50 2 668,0 vs 4 940,0 ms) montrent plus de surcoût d'initialisation à amortir.

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

Chaque valeur est une ligne du results/summary_metrics.csv publié du benchmark propriétaire (latency_p50_ms, latency_p95_ms, pages_per_minute) hébergé sur ImageToTableai/benchmark-ocr, avec un manifest.json expurgé par run qui enregistre le mode de mesure (warm_then_scored), les versions de modèles et les empreintes d'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 de latence d'un benchmark indépendant et reproductible (niveau officiel) — et non une synthèse de revendications tierces. Uniquement des splits de test fixes : test SROIE 2019 (361 reçus anglais, champs simples company/date/address/total) et test CORD v2 (100 reçus indonésiens, champs imbriqués menu/sub_total/total) ; les splits d'entraînement n'ont jamais été évalués. Chaque paire (moteur × jeu de données) a utilisé les mêmes images, la même vérité terrain et le même protocole de mesure (warm_then_scored : un passage de préchauffage fixe précède le passage noté). Les 16 exécutions se sont toutes terminées avec error_rate 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 une seule NVIDIA RTX 4090 (24 Go). Tesseract a fonctionné en CPU uniquement (compute_type=cpu) et est étiqueté comme tel sur chaque tableau. Un seul niveau GPU, un seul lieu/moment — c'est la portée indiquée sur cette page.
• Moteurs : tous les modèles fonctionnent tels quels, sans fine-tuning. 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 servi via vLLM, PaddleOCR-VL 1.6.
• Mode de mesure : warm_then_scored — les chiffres de latence correspondent à l'inférence en régime permanent par page, hors chargement du modèle ; pages/min est le temps réel incluant l'initialisation du modèle (selon le performance.run_wall_time_ms de chaque exécution dans les manifests expurgé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 d'inférence médian par page en régime permanent — 50 % des pages ont été plus rapides. Exclut le chargement du modèle (échauffement puis mesure).
• p95 (latence de queue) : 95e percentile du temps d'inférence par page — 5 % des pages ont pris plus de temps. Reflète les effets de première page/préremplissage et le comportement d'ordonnancement des 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 (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. Vue des travaux par lots et de la facturation.
• ms/page en temps réel (dérivé) : 60 000 ÷ pages/min — calcul arithmétique sur le débit mesuré, indiqué comme estimation dérivée, pas comme valeur mesurée.

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. Chaque chiffre de latence et de débit de cette page provient 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 des jeux de données (splits de test fixes) pour la reproduction.
3. results/manifests/ (GitHub). Un 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 en 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 des tâches 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 de champs imbriqués et licence (CC-BY-4.0).

Limitations

• Un seul niveau de GPU, un seul lieu/moment : tous les chiffres GPU proviennent d'un seul RTX 4090 sur un seul site, collectés en août 2026. D'autres GPU, le service multi-GPU et des ordonnancements différents 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 les 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 première page/prefill et l'ordonnancement par lots selon le schéma d'exécution de ce benchmark (répartitions fixes 361/100 pages, échauffement puis notation). Elles donnent une lecture de la forme de cette exécution, pas une garantie universelle de pire cas.
• p50/p95 excluent le chargement du modèle, pages/min l'inclut : les deux bases sont délibérément différentes (inférence en régime permanent vs débit horloge) et ne sont jamais présentées comme le même nombre. La dérivation du temps horloge par page (60 000 ÷ pages/min) est un calcul arithmétique sur le débit mesuré, pas une mesure distincte.
• 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 signalé sur 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, comptage par appel, mise à l'échelle automatique) diffèrent fondamentalement des moteurs locaux mesurés ici.
• Pas de balayage de taille de lot : l'amortissement de l'initialisation est dérivé de la base de mesure (pages/min inclut l'init, p50 l'exclut) et recoupé avec la méthode de la page des coûts — aucune expérience de taille de lot n'a été menée, donc la mise à l'échelle par lot est une estimation, pas une mesure.
• Taille d'échantillon et épinglage de version : 361 + 100 échantillons ; les résultats valent pour les versions de modèles d'août 2026 listées ci-dessus. Les nouvelles versions de moteurs peuvent modifier la latence ; les différences de quelques pourcents doivent être traitées comme du bruit.

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

Lectures complémentaires : ce que mesure réellement la précision de l'OCR IA · extraction IA depuis des images versus pipelines OCR traditionnels · Tarification de l'extraction de documents IA (2026)