바이두가 긴 문서를 페이지별로 나눠 보내지 않고 한 요청에서 파싱하는 문서 인식 모델 Unlimited OCR 2를 공개했다. 여러 쪽에 걸친 표와 문장의 연결을 처리하려는 개발자는 문서 전체를 입력하고 페이지 간 문맥을 활용할 수 있다.
1. 필요한 부분만 참조하고 페이지 묶음을 재사용한다
기존 Unlimited OCR은 텍스트 작업 메모리를 일정하게 유지하도록 설계됐지만, 문서가 길어질수록 매 생성 단계에서 모든 페이지의 시각 정보를 다시 참고해야 했다. 새 모델은 관련 정보만 골라 참고하는 희소 참조 슬라이딩 윈도 어텐션(SR-SWA)으로 이 부담을 줄인다. 문서의 모든 내용을 같은 강도로 되짚는 대신, 현재 페이지와 관련된 일부 참조 정보에 집중하는 방식이다.
전체 문서를 GPU 메모리에 계속 올려 두는 부담은 별도의 순차 처리 방식으로 줄인다. 문서를 경계 페이지가 겹치는 묶음으로 나눠 처리하면서 경계의 이전 계산 결과를 저장한 KV 캐시를 재사용하고, 현재 묶음 밖의 캐시는 해제한다. 한 요청을 받되 내부에서는 책장을 넘기듯 필요한 묶음만 메모리에 남기는 방식이다.
2. 페이지 이미지를 순서대로 한 번에 전달한다
개발자는 Transformers로 빠르게 시험하거나, 서비스 운영에는 바이두가 권장하는 SGLang을 사용할 수 있다. 여러 페이지 이미지 파일을 순서대로 전달하면 한 요청에서 전체 문서를 파싱하고 페이지 사이 문맥도 활용한다.
저장소의 다중 페이지 예시다.
pages = [f"your_doc/page_{i}.jpg" for i in range(1, 8)]
text, num_tokens = model.infer_multi(tokenizer, image_files=pages,
output_path="output/multi", save_results=True)바이두는 Python 3.10과 PyTorch 2.13.0에서 시험했다.
시험에 쓴 모델 라이브러리는 Transformers 4.52.1이며 GPU는 NVIDIA A800 80GB다.
모델의 원시 출력은 마크다운이 아닌 문서 요소를 구분해 담은 구조화 블록 문자열이다. 저장소의 후처리 도구로 페이지 표식과 제목 단계, 표, 좌표를 정리해 평가용 마크다운으로 변환한다.
3. 백 쪽 평가에서 비교 모델보다 높은 점수를 냈다
바이두가 공개한 MarathonDocBench는 103~300쪽짜리 문서 100개와 약 20만 개의 위치와 종류를 표시한 주석 레이아웃 요소를 포함한다. 종합 점수는 글자 인식뿐 아니라 표와 수식, 읽기 순서, 페이지를 넘는 구조 등을 함께 평가한다. 회사 발표 기준 Unlimited OCR 2는 77.06으로, 비교 모델 중 최고인 Kimi-K3의 33.74보다 높았다.
표: MarathonDocBench 종합 점수
조건: MarathonDocBench 100개 문서(103~300쪽), 기술 보고서 표 2의 모델별 평가 결과, 회사 발표 기준
단위: 점수(%)
| 모델 | 종합 점수(%) |
|---|---|
| Unlimited-OCR 2 | 77.06 |
| Kimi-K3 | 33.74 |
| Gemini-3.8-Flash | 28.61 |
| Qwen-3.8-Flash-Next | 27.83 |
| Gemini-3.1-Pro Preview | 26.97 |
| Qwen3.8-Max | 22.93 |
| Minimax-M3 | 17.97 |
| DeepSeek-4.1-Flash | 12.34 |
| GLM-5.3-Flash | 7.51 |
페이지를 넘나드는 문장과 표가 풍부한 평가에서 거둔 결과라는 점이 핵심이다. 회사 발표 기준으로 최대 30쪽을 다루는 별도 평가 MPDocBench에서도 종합 점수 84.59를 기록했다.
4. 메모리는 페이지 묶음으로, 운영 부담은 설정과 변환으로 옮긴다
회사 발표 기준 백 쪽 규모의 한 단계씩 결과를 생성하는 디코딩 속도는 전체 어텐션보다 7.0배, 이전 참조 방식인 R-SWA보다 5.6배 빨랐다. 페이지 이미지를 여러 이미지를 나눠 처리하는 작은 조각인 타일로 나누는 건담 모드에서 한 번에 처리하는 입력 수인 배치 크기 3, 페이지당 생성 1,024토큰으로 측정한 결과다.
같은 보고서의 MarathonDocBench 측정에서 단일 요청에서 순간적으로 가장 많이 쓰는 KV 캐시 메모리는 표준 디코딩의 47.00GB에서 순차 묶음 처리의 1.77GB로 줄었다. 동시 요청 16개 조건에서는 처리량이 초당 360토큰에서 1,315토큰으로 늘었다는 것이 회사 발표다.
개발자는 긴 문서를 한 요청으로 넘기고 GPU 메모리 부담을 낮출 수 있다. 대신 서비스 통합에서는 페이지 묶음 크기와 출력 예산을 문서에 맞춰 조정하고, 구조화 출력을 필요한 형식으로 변환하는 작업을 맡게 된다.
5. 단일 페이지 최고 점수보다 장문 처리에 초점을 뒀다
단일 페이지 평가에서는 회사 발표 기준 아래 두 비교 모델의 점수가 더 높았다. 장문 문서 처리와는 다른 선택 기준을 보여준다.
표: 단일 페이지 종합 점수
조건: 기술 보고서 표 3의 OmniDocBench v1.6 평가 결과, 회사 발표 기준
단위: 점수(%)
| 모델 | 종합 점수(%) |
|---|---|
| Unlimited-OCR 2 | 94.02 |
| OvisOCR2 | 96.47 |
| TeleOCR | 96.91 |
작은 페이지 묶음은 피크 메모리를 낮추지만 경계를 넘는 블록의 문맥이 끊겨 병합 품질에 영향을 줄 수 있다. 보고서는 희소 어텐션이 문서 전체 정보를 보존하지 못해 제목 계층 같은 문서 수준 구조 이해에도 한계가 있다고 설명한다.
Unlimited OCR 2는 문서 길이에 따른 단계별 연산 부담을 억제해, 다중 페이지 파싱을 단일 요청 기반 서비스로 옮기는 데 초점을 맞춘 모델이다.
