Baidu, 수백 쪽 문서를 한 번에 읽는 오픈소스 OCR 공개

Baidu가 수백 쪽짜리 책과 보고서, 공시 문서를 요청 한 번으로 구조화된 텍스트로 바꾸는 오픈소스 광학 문자 인식(OCR) 모델 Unlimited OCR 2를 공개했다. 매개변수는 3.34B이며, 가중치는 MIT 라이선스로 풀렸고 코드는 GitHub에 올라 있다.

모델은 BF16 정밀도로 CUDA GPU 한 장에서 돌아가고, BF16 가중치 크기는 약 6.7GB다. Baidu는 NVIDIA A800-80GB에서 시험했다. 최대 위치 길이는 131,072 토큰이다. 활성 매개변수 수는 공개하지 않았다.

작동 방식

Unlimited OCR 2는 순서대로 넣은 쪽 이미지를 본문, 표, 수식, 그림, 제목, 읽는 순서를 담은 구조화 텍스트로 바꾸는 비전-언어 모델이다. 2026년 6월 나온 전작 Unlimited-OCR는 DeepSeek-OCR를 더 밀어붙이려는 모델이었고, 이번 모델의 구성도 DeepSeek-OCR 스타일을 유지한다. SAM ViT-B와 CLIP-L 인코더가 12층 전문가 혼합 디코더에 입력을 넘기고, 토큰마다 64개 전문가 가운데 6개와 공유 전문가 2개를 거친다. DeepSeek-OCR 논문은 이 디코더를 DeepSeek3B-MoE-A570M으로 설명하지만, Baidu는 버전 2의 활성 수를 밝히지 않았다. 여러 쪽을 처리하는 모드에서는 쪽당 이미지 토큰이 273개다.

핵심 변경은 SR-SWA(Sparse Reference Sliding Window Attention)다. 어텐션 비용은 시퀀스 길이에 따라 제곱으로 늘고, 디코딩 때 새 토큰마다 더 긴 KV 캐시를 훑어야 한다. 100쪽이면 출력 전에 입력만 2만 7,300토큰이 된다. SR-SWA는 텍스트와 시각 정보 사이의 어텐션을 고정된 수의 작업용 참조 토큰으로 압축한다. 모델 카드의 예시 크기는 512토큰이다. 설정에는 128토큰 국소 창(슬라이딩 윈도 어텐션)과 32토큰 블록 상위 16개 선택이 함께 들어 있고, 32토큰 블록 16개가 512토큰 예산에 해당한다.

Baidu는 문서가 길어져도 단계별 지연 시간과 메모리가 거의 일정하다고 밝히고, 이를 한정된 컨텍스트 창 안에서의 무제한 범위 파싱이라 부른다. 다만 이미지 인코딩과 전체 실행 시간은 쪽수에 따라 계속 늘어난다.

벤치마크 결과

Baidu 차트 기준 MPDocBench 종합 점수는 84.6이고, Qwen3.8-Max가 78.3, Qwen-3.8-Flash-Next가 77.4로 뒤를 이었다. 수백 쪽 문서를 다루는 MarathonDocBench에서는 77.1로, 2위 Kimi-K3의 33.7과 3위 Gemini-3.8-Flash의 28.6을 앞섰다. 비교 대상은 9개 모델이며 수치는 모두 Baidu가 직접 낸 것이고, 차트 이미지로만 제시됐다.

벤치마크가 바뀔 때의 하락 폭이 눈에 띈다. Qwen3.8-Max는 78.3에서 22.9로 떨어졌고, Unlimited OCR 2는 MPDocBench 84.6에서 MarathonDocBench 77.1로 7.5점 내려갔다. 전작 Unlimited-OCR는 MarathonDocBench에서 0.0점이었다. MPDocBench-Parse는 문서 433건, 3,246쪽으로 이뤄진 공개 벤치마크이고, MarathonDocBench의 공개본은 매체가 찾지 못했다.

제목 계층은 두 벤치마크 모두에서 가장 낮은 항목이며, 수백 쪽 문서를 다루는 MarathonDocBench의 48.2가 Baidu가 꼽은 최저 세부 점수다. MPDocBench에서는 항목 하나만 놓고 보면 격차가 얇다. Qwen3.8-Max는 본문 94.3, 수식 89.2로, Unlimited OCR 2의 본문 94.8, 수식 89.4에 근접했다.

실행 방법과 주의점

모델 카드는 간단한 시험에는 Transformers를, 서비스 운영에는 SGLang을 안내한다. Transformers에서 infer는 동적 타일링(gundam 모드)으로 한 쪽을 처리하고, infer_multi는 문서 전체를 한 번에 파싱해 쪽 사이 맥락을 유지한다. 불러올 때 trust_remote_code=True가 필요하며, 저장소의 파이썬 코드가 실행된다.

SGLang 서빙에는 정식 버전이 아닌 Baidu의 수정 wheel이 필요하다. 예시는 창당 10쪽을 처리하며 앞선 창의 KV 꼬리를 재사용한다. 창을 작게 잡으면 최대 메모리는 줄지만 쪽 사이 병합 품질이 떨어진다. Baidu는 기본 편향 설정 때문에 462MiB 할당이 일어나 메모리가 부족할 수 있다고 경고했다.