
In this article
8개 오픈 OCR 시스템을 5개 언어와 6개 문서 유형으로 구성된 900페이지에서 엄격한 GPU 전용 조건으로 평가하고 CER, 지연 시간, 처리량, VRAM, 에너지, 출력 잘림, 구조화 출력을 비교합니다.
모델과 참고 자료:
- PaddleOCR PP-OCRv5 — 선택한 언어 인식기에 따라 활성 파라미터 310만~530만 개. 폴리곤과 신뢰도를 반환하는 모바일 검출·인식 OCR.
- EasyOCR — 언어 리더에 따라 활성 파라미터 2,460만~7,460만 개. CRAFT 검출과 PyTorch 인식을 결합해 영역과 신뢰도를 반환.
- docTR — 평가한 사전 학습 predictor에 2,640만 파라미터. 구조화된 영역과 신뢰도를 반환하는 2단계 PyTorch 문서 OCR.
- GLM-OCR — 13억 3천만 파라미터. 일반 텍스트와 Markdown 추출을 위해 Transformers 생성 방식으로 평가한 비전-언어 OCR.
- Granite Docling 258M — 2억 5,750만 파라미터. 레이아웃 위치를 포함한 DocTags를 생성하는 소형 Transformers 문서 변환 모델.
- HunyuanOCR — 11억 2천만 파라미터. 텍스트 스포팅, 문서 파싱, 의미 기반 문서 작업을 지원하는 OCR 전용 비전-언어 생성 모델.
- Qwen3-VL-8B-Instruct — 87억 7천만 파라미터. 다국어 OCR과 Markdown 추출에 사용한 범용 비전-언어 생성 모델.
- Surya OCR 2 — 6억 8,620만 파라미터. 영역 좌표가 있는 텍스트 또는 HTML을 생성하는 레이아웃 인식 Transformers 모델.
파라미터 수는 다운로드 크기가 아니라 평가 시 활성화된 체크포인트 가중치를 의미합니다. 전통적 OCR의 합계는 해당 페이지에 로드한 검출기와 언어별 인식기를 합산했으며, 생성 모델은 공개 체크포인트 텐서를 기준으로 했습니다.
요약
동일한 900페이지에서 8개 오픈 OCR 시스템을 평가했습니다. 데이터는 5개 언어, 6개 이미지 유형으로 구성되며 각 언어×유형 셀에 30페이지가 있습니다. 모든 시스템은 NVIDIA RTX PRO 6000 Blackwell Max-Q GPU 한 대에서 실행했고 CPU 자동 대체를 엄격하게 금지했습니다.
모든 조건에서 우승하는 모델은 없습니다. HunyuanOCR은 평균 문자 오류율(CER) 0.1637로 관측상 가장 낮았고, QwenOCR은 0.1651로 사실상 동률이었습니다. PaddleOCR은 0.145초의 워밍 추론 p50, 실측 268 wall pages/min, 폴리곤과 신뢰도 출력으로 가장 강력한 저지연 좌표 기반 프로필을 보였습니다.
이 표본에서 정확도 선두 간 차이는 통계적으로 결정적이지 않습니다. 반면 배포 비용과 출력 계약의 차이는 더 분명합니다. Hunyuan의 최대 VRAM은 96,358 MiB, Qwen은 21,010 MiB였지만 Paddle은 4 GiB 미만에서 유용한 좌표를 반환했습니다. 따라서 단일 종합 승자를 만들지 않고 정확도, 지연 시간, 자원, 출력 잘림, 출력 기능을 각각 보고합니다.
평가 방법
이 벤치마크는 균형 잡힌 페이지 그리드를 사용하고 텍스트 정확도와 운영 측정값을 분리합니다.
페이지 세트
| 항목 | 범위 |
|---|---|
| 언어 | 영어, 일본어, 한국어, 중국어, 힌디어. 언어별 180페이지 |
| 이미지 유형 | 단순 인쇄, 복잡한 레이아웃, 표·양식, 스크린샷·UI, 필기, 카메라 촬영·열화. 유형별 150페이지 |
| 난이도 | 각 언어/유형 셀에 쉬움 10, 보통 10, 어려움 10페이지 |
| 런타임 세트 | 900페이지 |
소스 구성은 제어 렌더링 548페이지, 제어 열화 50페이지, MDPBench 원본 공개 실데이터 195페이지, Wikimedia Commons의 라이선스된 웹 실데이터 107페이지입니다. 900페이지 전체가 운영 지표에 포함됩니다. 텍스트 정확도는 독립된 참조 텍스트가 있는 페이지만 사용했으며 평가 모델의 출력을 정답으로 재사용하지 않았습니다.
추론 프롬프트 세트
검출·인식 시스템은 자연어 지시를 받지 않으므로 PaddleOCR, EasyOCR, docTR에는 이미지와 설정된 언어 리더를 입력했습니다. 생성 시스템에는 요약하지 않고 보이는 모든 텍스트를 읽기 순서대로 전사한다는 동일한 목표를 주되, 각 모델의 기본 출력 형식을 사용했습니다.
| 모델 경로 | 평가 지시문 |
|---|---|
| PaddleOCR, EasyOCR, docTR | 텍스트 프롬프트 없음. 설정된 검출기와 인식기를 실행하고 출력 순서대로 영역을 반환. |
| GLM-OCR | Extract all visible text from this page in reading order. Preserve headings, lists, and tables as Markdown. |
| Granite Docling | Convert this page to DocTags. Preserve all text, reading order, and layout. |
| HunyuanOCR | 提取页面中的所有文字,按阅读顺序输出,并使用 Markdown 保留标题、列表和表格结构。 (페이지의 모든 텍스트를 읽기 순서대로 추출하고 제목, 목록, 표를 Markdown으로 보존.) |
| QwenOCR | Perform OCR on this document page. Transcribe every visible character in reading order. Preserve headings, paragraphs, lists, and tables as Markdown. Do not summarize, translate, explain, or omit text. Return only the transcription. |
| SuryaOCR | 공식 고정밀 프롬프트: OCR this image to HTML. Each block is a div with data-label and data-bbox (x0 y0 x1 y1, normalized 0-1000). |
실행 조건
- 시스템마다 잠긴 uv 환경 하나와 고정된 모델 리비전 하나를 사용.
- 각 모델의 기본 CUDA 경로로 추론. PaddleOCR는 PaddlePaddle GPU를 통한
PaddleOCR.predict(), EasyOCR는EasyOCR.Reader.readtext(), docTR는 PyTorch 기반ocr_predictor(), GLM-OCR, Granite Docling, HunyuanOCR, QwenOCR, Surya OCR 2는 Hugging Face Transformers 기반 자기회귀generate()를 사용. - 고정 Python ML 스택은 PaddleOCR 3.6.0 및 PaddlePaddle GPU 3.3.1, EasyOCR 1.7.2, python-doctr 1.0.1, Surya OCR 0.21.1, PyTorch 2.11.0 및 torchvision 0.26.0, Transformers 5.10.2
5.12.1(Hunyuan 호환 고정 리비전 포함), Accelerate 1.13.01.14.0, Pillow 10.4.0~12.2.0. - 실행당 영구 프로세스 하나를 사용. 모델 로드는 한 번 기록하고 워밍 추론 백분위수에서 제외.
- 배치나 동시 처리 없이 한 페이지씩 순차 추론.
- CUDA를 필수로 하고 자동 CPU 대체를 금지.
- 생성 디코딩은 결정적으로 수행하고 새 토큰을 1,024개로 제한. EOS 토큰 없이 상한에 도달하면 잘림으로 집계.
- 각 페이지 전후로 GPU와 프로세스 자원을 샘플링.
지표
- 완료와 잘림: 성공 페이지, 실패, 타임아웃, 생성 상한에 도달한 출력. ↑ 완료 ↓ 실패·잘림
- CER: Unicode NFKC와 언어별 정규화 후 문자 편집 거리를 참조 길이로 나눈 값. ↓ 낮을수록 좋음
- NormED와 텍스트 유사도: 예측과 참조 중 긴 쪽으로 나눈 편집 거리와
1 − NormED형태의 유사도. ↓ NormED ↑ 유사도 - 지연 시간: 콜드 로드, 워밍 추론 p50/p95, 엔드투엔드 p50/p95. ↓ 낮을수록 좋음
- 처리량: 측정된 페이지별 오케스트레이션 오버헤드를 포함한 성공 페이지의 wall pages/min. ↑ 높을수록 좋음
- 자원: 최대 VRAM과 프로세스 트리 RAM, 평균·최대 GPU 사용률 및 보드 전력. ↓ 최대 메모리
- 에너지: 프로세스 시작 전 유휴 샘플을 뺀 페이지당 활성 GPU 보드 Wh. ↓ 낮을수록 좋음
- 출력 계약: 일반 텍스트, Markdown·HTML·DocTags, 박스, 신뢰도, 오버레이, 출력 읽기 순서.
- 공식 구조 지표: 소스 충실도가 유지된 195페이지 하위 집합의 MDPBench 텍스트 편집 거리, 수식 CDM, 표 TEDS, 읽기 순서 편집 거리. ↓ 텍스트·순서 편집 거리 ↑ CDM·TEDS
결과
전체 정확도-속도 절충에서 시작해 언어, 이미지 유형, 도메인 이동, 잘림, 공식 구조 점수, GPU 비용 순으로 결과를 살펴봅니다. CER가 낮다고 해서 지연 시간이 짧거나, 좌표가 제공되거나, 문서 구조가 안정적인 것은 아니므로 이 차원들을 분리했습니다.
전체 정확도, 완료율, 속도
첫 번째 그림은 페이지별 평균 CER와 워밍 추론 p50을 함께 보여줍니다. 왼쪽 아래가 가장 유리합니다. 이어지는 표는 2축 차트가 보여주지 못하는 완료 수, 정규화 편집 거리, 생성 상한 도달 수를 추가합니다.
| 모델 | 완료 ↑ | CER ↓ | NormED ↓ | 상한 도달 ↓ |
|---|---|---|---|---|
| HunyuanOCR | 900/900 | 0.1637 | 0.1499 | 184 |
| QwenOCR | 900/900 | 0.1651 | 0.1476 | 222 |
| GLM-OCR | 900/900 | 0.2299 | 0.2185 | 263 |
| PaddleOCR | 900/900 | 0.2509 | 0.2372 | 0 |
| SuryaOCR | 900/900 | 0.2847 | 0.2781 | 507 |
| EasyOCR | 900/900 | 0.3134 | 0.3020 | 0 |
| Granite Docling 258M | 900/900 | 0.5590 | 0.5131 | 468 |
| docTR | 900/900 | 0.7608 | 0.7121 | 0 |
CER는 페이지별 문자 편집 거리를 참조 길이로 나눈 값의 평균입니다. 삽입 문자가 참조 문자보다 많으면 한 페이지의 값이 1.0을 넘을 수 있습니다. 정규화 편집 거리(NormED)는 예측과 참조 중 긴 쪽으로 나누므로 0과 1 사이에 머뭅니다.
docTR는 속도만으로 판단할 수 없는 이유를 보여줍니다. 기본 인식기는 매우 빨랐지만 라틴 문자 중심 어휘를 사용해 CJK와 데바나가리 문자의 대부분을 표현할 수 없었습니다.
언어별 정확도
이 분할은 언어와 문자 체계가 달라져도 전체 순위가 유지되는지 확인합니다. 각 언어는 6개 이미지 유형 전체의 180페이지를 집계합니다.
Hunyuan은 영어(0.1457), 한국어(0.0889), 힌디어(0.2264)에서 관측상 가장 낮은 CER를 기록했습니다. 일본어는 Qwen(0.1425), 중국어는 GLM(0.1264)이 선두였습니다. 다만 상위 모델과 차상위 모델의 쌍별 95% 부트스트랩 구간은 모두 0을 포함했습니다. 따라서 이는 방향성을 보여주는 선두 결과입니다.
모델 크기만큼 설정도 중요합니다. Paddle과 EasyOCR는 언어별 리더를 바꿨지만 평가한 docTR 체크포인트는 라틴 문자 중심이었습니다. Hunyuan은 130개 이상의 언어 학습을 보고했고 Qwen3-VL은 광범위한 다국어 문서 사전 학습을 보고했습니다. GLM의 공개 다국어 평가에는 힌디어가 명시되지 않았으며 이번 실행에서는 힌디어 180페이지 중 136페이지가 상한에 도달했습니다.
이미지 유형별 정확도
언어 구성을 일정하게 유지하고 문서 형태별로 페이지를 묶었습니다. 각 범주는 150페이지로, 깨끗한 텍스트 인식과 레이아웃, 필기, 스크린샷, 열화 이미지 성능을 분리해 볼 수 있습니다.
단순 인쇄는 Paddle(0.1650), 복잡한 레이아웃(0.2716), 표·양식(0.1650), 제어 필기(0.0095)는 Hunyuan이 선두였습니다. 스크린샷·UI(0.0423)와 카메라 촬영·열화 페이지(0.3014)는 Qwen이 선두였습니다. 복잡한 레이아웃과 열화 페이지에서 Hunyuan과 Qwen은 거의 동률이었으며 6개 범주 모두 상위 모델과 차상위 모델의 부트스트랩 구간이 0을 포함했습니다.
아키텍처 차이는 실용적인 의미가 있습니다. 전통적인 검출·인식 OCR은 깨끗하게 위치가 잡힌 텍스트에서 강하고, 페이지 단위 VLM 문맥은 레이아웃과 직렬화에 도움이 됩니다. 필기 결과는 제어 데이터 비중이 높으므로 여러 필자의 자연스러운 필기 전체로 일반화하면 안 됩니다.
제어 데이터와 실데이터의 도메인 이동
벤치마크의 낙관성을 드러내기 위해 제어 렌더링 페이지와 MDPBench 원본 공개 실데이터 페이지를 비교합니다. 두 그룹은 동일 페이지의 짝이 아니라 소스별로 층화되어 있으므로, 이 차트는 인과적 성능 저하량이 아니라 배포 관련 도메인 격차를 측정합니다.
195개 MDPBench 원본 공개 실데이터 페이지에서 모든 시스템의 성능이 크게 낮아졌습니다. Hunyuan은 CER 0.057에서 0.477, Qwen은 0.051에서 0.523, GLM은 0.141에서 0.519, Paddle은 0.152에서 0.587로 증가했습니다. 동일 페이지 쌍 실험이 아니라 소스 층화 비교이지만 렌더링 페이지가 실제 배포 정확도를 과대평가한다는 점은 분명합니다.
토큰 상한 효과
생성 OCR에서 1,024토큰 상한에 도달한 응답은 완성된 페이지가 아니라 부분 전사일 수 있습니다. 이 차트는 완료 출력과 상한 도달 출력을 분리해 디코딩 제한이 집계 CER 안에 숨지 않도록 합니다.
생성 시스템은 결정적 디코딩을 사용했습니다. 모든 모델에서 상한 도달 페이지의 CER는 완료 페이지보다 약 0.40 높았습니다. Surya는 507페이지, Granite는 468페이지에서 상한에 도달했으며 순위를 안정적으로 판단하려면 공식 고상한 재실행이 필요합니다. Qwen은 222페이지, Hunyuan은 184페이지, GLM은 263페이지에서 상한에 도달했습니다.
실제 페이지와 추론 결과
아래 예시는 MDPBench 원본 페이지 ocr900v2_en_tables_forms_10입니다. 이미지를 클릭하면 전체 해상도로 확인할 수 있습니다.
원본 페이지
PaddleOCR 좌표 오버레이
빨간 영역은 PaddleOCR 추론 JSON에서 직접 가져왔으며 수작업으로 다시 만들지 않았습니다.
| 모델 | 페이지 CER ↓ | 추론(초) ↓ | 결과 |
|---|---|---|---|
| GLM-OCR | 0.42% | 4.94 | Markdown |
| HunyuanOCR | 1.05% | 6.04 | Markdown |
| QwenOCR | 1.15% | 5.38 | Markdown |
| SuryaOCR | 32.46% | 15.85 | HTML·상한 도달 |
| PaddleOCR | 41.26% | 0.16 | 텍스트, 폴리곤, 신뢰도 |
Paddle은 유용한 좌표를 검출했지만 표를 하나의 읽기 순서로 평탄화하면서 셀 관계를 잃었습니다. 생성 모델은 표 구조를 더 충실하게 재구성했지만 신뢰도나 좌표 영역을 출력하지 않았습니다. 일반 CER와 문서 구조는 별도의 지표로 유지해야 합니다.
공식 MDPBench 평가기를 통한 교차 확인
MDPBench 원본 195페이지 하위 집합을 고정된 공식 평가기에 입력했습니다. 이는 하위 집합 결과이며 리더보드 제출 결과가 아닙니다. 표 머리글의 화살표는 각 공식 지표를 읽는 방향을 나타냅니다.
| 모델 | 텍스트 편집 거리 ↓ | 수식 CDM ↑ | 표 TEDS ↑ | 순서 편집 거리 ↓ |
|---|---|---|---|---|
| PaddleOCR | 0.5172 | 0.0288 | 0.0000 | 0.3737 |
| EasyOCR | 0.5771 | 0.0000 | 0.0043 | 0.4302 |
| docTR | 0.8194 | 0.0131 | 0.0000 | 0.5042 |
| GLM-OCR | 0.4371 | 0.6636 | 0.2306 | 0.3842 |
| Granite Docling | 0.7344 | 0.0087 | 0.0000 | 0.5823 |
| HunyuanOCR | 0.3631 | 0.6319 | 0.4120 | 0.3422 |
| QwenOCR | 0.3710 | 0.4784 | 0.3729 | 0.3527 |
| SuryaOCR | 0.6717 | 0.0000 | 0.2457 | 0.5354 |
이 하위 집합에서 Hunyuan은 텍스트 편집 거리, 표 TEDS, 읽기 순서에서 선두였고 GLM은 수식 CDM에서 선두였습니다. Qwen은 텍스트와 표에서 Hunyuan에 근접했습니다.
지연 시간과 처리량
이 시각화는 OCR 정확도와 별개로 운영 속도를 비교합니다. 추론 백분위수는 일회성 모델 로드를 제외하고 wall throughput은 순차 실행에서 측정한 페이지별 엔드투엔드 오버헤드를 포함합니다. 채운 점은 p50, 테두리 점은 p95이며 모든 값이 표시 옆에 인쇄되어 있습니다.
메모리와 GPU 보드 에너지
최대 VRAM은 모델이 대상 GPU에 들어가는지를 결정하고, 활성 에너지는 추론 중 페이지당 GPU 보드 작업량을 보여줍니다. 이 값은 단일 페이지, 비배치 구성에서 측정했으며 데이터센터 전력 추정치로 해석하면 안 됩니다.
에너지는 각 추론 구간에서 샘플링한 GPU 보드 전력을 사다리꼴 적분해 계산했습니다. 콜드 로드, CPU와 호스트 전력, 냉각, 배치 효과를 제외하며 벽면 콘센트 비용 추정치가 아닙니다.
출력 계약
정확도 지표는 전사를 평가하지만 프로덕션 시스템은 결과를 렌더링하거나 원본 페이지에 다시 연결할 수 있는지도 알아야 합니다. 이 기능 매트릭스는 평가한 모델 경로에서 일반·구조화 텍스트와 좌표·신뢰도 출력을 구분합니다.
텍스트 전용 RAG 수집 시스템과 클릭 위치를 강조하는 문서 뷰어는 CER가 같더라도 서로 다른 모델이 최적일 수 있습니다. 좌표와 신뢰도는 부가적인 표시 기능이 아니라 핵심 배포 요구사항입니다.
배포 관점의 해석
- 좌표와 신뢰도가 있는 빠른 다국어 텍스트: 평가한 기준에서는 PaddleOCR가 가장 강력합니다. p50 0.145초, 268 wall pages/min, 낮은 VRAM, CER 0.2509를 결합합니다.
- 관측상 가장 낮은 일반 텍스트 오류: HunyuanOCR와 QwenOCR가 선두 그룹입니다. Hunyuan은 평균 CER가 더 낮고 Qwen은 NormED와 스크린샷·열화 이미지 관측 결과가 더 좋습니다.
- 소형 생성 OCR: GLM-OCR은 최대 VRAM 6.4 GiB에서 CER 0.2299를 기록했고 중국어 관측 결과가 가장 좋았습니다. 시험한 기본 모델 경로에서는 박스를 반환하지 않습니다.
- 구조화 HTML OCR: SuryaOCR는 생성 예산을 예상 출력 길이에 맞추기 전까지 대표 CER만으로 판단할 수 없습니다.
- 최고 속도: docTR는 필요한 문자 체계에 맞는 인식기를 설정했을 때만 매력적입니다. 이번 실행의 기본 체크포인트는 5개 언어 솔루션이 아닙니다.
실제 프로덕션에서는 좌표 기반 PaddleOCR를 먼저 실행한 뒤 신뢰도, 언어, 레이아웃, 표 신호가 줄 단위 OCR이 부족하다고 판단한 페이지만 페이지 단위 VLM으로 보내는 캐스케이드 구성을 고려할 수 있습니다.
한계
- 데이터의 66.4%는 제어 콘텐츠이며 모든 시스템이 공개 실데이터에서 더 나빴습니다.
- 독립 참조 텍스트가 없는 페이지는 런타임 데이터에는 포함되지만 텍스트 정확도에는 포함되지 않습니다.
- 언어/유형 셀당 30페이지는 큰 효과를 드러낼 수 있지만 작은 순위 차이를 증명할 수 없습니다.
- 1,024토큰 상한은 Surya와 Granite에 불균형하게 불리합니다.
- CER는 구조나 좌표를 완전히 평가하지 못하며 런타임 프로필은 GPU 한 대에서의 순차 단일 페이지 추론만 포함합니다.
다음 연구 방향
결론
이 벤치마크는 하나의 OCR 점수로는 가려지는 세 가지 배포 선택을 분리했습니다.
PaddleOCR는 가장 강력한 저지연 좌표 기반 기준선입니다. HunyuanOCR와 QwenOCR는 페이지 단위 추론이 중요한 조건에서 관측상 가장 낮은 텍스트 오류를 제공하지만 계산량과 메모리 비용이 훨씬 큽니다. GLM-OCR은 특히 중국어에서 강한 소형 생성 대안입니다. Surya, Granite, docTR의 현재 행을 최종 역량 순위로 읽으려면 생성 상한, 어휘, 파이프라인 설정을 먼저 수정해야 합니다.
핵심 결과는 한 시스템이 모든 페이지에서 이긴다는 것이 아닙니다. 언어, 문서 구조, 출력 계약, GPU 예산에 따라 올바른 모델이 달라지며 제어 환경의 OCR 정확도는 공개 실데이터 평가를 대신할 수 없습니다.




