바이두 Unlimited OCR 2 공개: 수백 쪽 문서를 통째로 읽는 OCR

300쪽짜리 사업보고서 PDF를 AI로 마크다운 문서로 바꿔 본 적이 있다면, 쪽이 넘어가며 끊긴 표가 두 개로 나뉘어 나오거나 뒤쪽으로 갈수록 처리가 느려지는 경험을 했을 수 있습니다. 바이두가 10월 27일 공개한 Unlimited OCR 2는 이 문제를 겨냥한 모델입니다. 책 한 권 분량의 문서를 쪽마다 나누지 않고 한 번의 요청으로 읽고, 문서가 길어져도 글자 하나를 만드는 속도가 거의 떨어지지 않게 만들었습니다.

OCR은 이미지 속 글자를 텍스트로 옮기는 기술입니다. Unlimited OCR 2는 여기서 더 나아가 표, 수식, 그림 위치, 읽는 순서, 제목 단계까지 구조를 갖춘 마크다운으로 옮깁니다. 이런 작업을 문서 파싱이라고 부르고, PDF 자료를 RAG(검색 증강 생성)에 넣기 전 단계에서 많이 씁니다.

모델은 바이두의 ERNIE 팀이 만들었고, 가중치와 코드를 MIT 라이선스로 허깅페이스와 깃허브에 올렸습니다. MIT 라이선스는 상업적 이용과 수정을 허용하는 오픈소스 라이선스입니다. 이 글은 허깅페이스 모델 카드, 깃허브 저장소, 함께 공개된 기술 보고서를 2026년 10월 28일에 확인해 작성했습니다.

1편과 무엇이 달라졌나

2026년 6월에 나온 1편 Unlimited OCR은 딥시크의 DeepSeek-OCR을 바탕으로 수십 쪽 문서를 한 번에 읽게 만든 모델입니다. 1편은 지금까지 쓴 글자 가운데 최근 부분만 보도록 텍스트 쪽 기억을 고정했지만, 문서의 모든 쪽 이미지는 계속 봤습니다. 쪽 수가 수백 개로 늘면 글자 하나를 쓸 때마다 살펴야 할 이미지 정보가 함께 늘어 느려졌습니다.

2편은 이미지 쪽도 보는 양을 고정했습니다. 바이두는 사람이 책을 베껴 쓰는 방식에서 착안했다고 설명합니다. 사람은 지금 베끼는 쪽에 집중하고, 앞쪽에서 이어지는 표나 문장이 있을 때만 잠깐 돌아봅니다. 이 방식을 바이두는 SR-SWA(Sparse Reference Sliding Window Attention)라고 이름 붙였습니다.

바이두는 1단계를 페이지 게이트(Page Gate), 2단계를 토큰 시브(Token Sieve)라고 부릅니다. 모델 설정 파일에는 최근 텍스트 128토큰과 32토큰 크기 블록 16개를 함께 보는 값이 들어 있습니다. 문서가 10쪽이든 300쪽이든 글자 하나를 만들 때 참고하는 양이 같기 때문에, 단계당 지연과 메모리가 거의 일정하게 유지됩니다.

긴 문서에서 줄어든 메모리와 시간

SR-SWA만으로는 모든 쪽의 이미지 정보를 처음에 한꺼번에 GPU 메모리에 올리는 문제가 남습니다. 그래서 2편은 문서를 몇 쪽씩 묶어 차례로 처리하고, 앞 묶음의 마지막 쪽을 다음 묶음과 겹쳐 이어지는 표와 문장을 놓치지 않게 합니다. 처리가 끝난 묶음의 메모리는 바로 비웁니다.

기술 보고서에 실린 측정값은 다음과 같습니다. 모두 바이두가 100~300쪽 문서로 측정한 결과입니다.

KV 캐시는 모델이 앞에서 읽은 내용을 다시 계산하지 않으려고 저장해 두는 메모리입니다. 이 값이 47GB에서 1.77GB로 줄었으므로, 수백 쪽 문서를 처리할 때 필요한 GPU 메모리도 그만큼 줄어듭니다. 다만 쪽마다 이미지를 읽는 시간은 쪽 수만큼 늘기 때문에, 문서 전체 처리 시간이 쪽 수와 무관한 것은 아닙니다.

바이두가 공개한 점수

바이두는 두 벤치마크로 성능을 비교했습니다. MPDocBench는 최대 30쪽, 중간값 6쪽인 여러 쪽 문서 벤치마크입니다. MarathonDocBench는 바이두가 이번에 함께 만든 벤치마크로, 103~300쪽 문서 100개에 표시된 요소 20만 5천 개가 들어 있습니다. 두 벤치마크 모두 점수가 높을수록 좋습니다.

표에서 볼 점은 수십 쪽에서 수백 쪽으로 넘어갈 때 점수가 얼마나 떨어지느냐입니다. Qwen3.8-Max는 78.3에서 22.9로 떨어지고, Gemini 3.8 Flash도 76.2에서 28.6으로 떨어집니다. Unlimited OCR 2는 84.6에서 77.1로 7.5점 떨어지는 데 그쳤습니다. 1편은 수백 쪽 문서에서 0점을 받았습니다.

한 쪽짜리 문서 성능도 유지됐습니다. 단일 쪽 문서 파싱 벤치마크인 OmniDocBench v1.6에서 2편은 94.02점으로, 1편의 93.92점보다 0.1점 높습니다.

약점은 제목 단계

항목별 점수를 보면 차이가 뚜렷합니다. 글자, 수식, 읽는 순서는 수백 쪽 문서에서도 85점 넘게 유지되지만, 표와 제목 단계는 낮아집니다.

바이두는 기술 보고서의 한계 절에서 이유를 밝혔습니다. 지금의 SR-SWA는 문서 전체 정보를 유지하지 않기 때문에, 제목 단계처럼 문서 전체를 봐야 알 수 있는 구조를 잘 파악하지 못합니다. 1장 아래 1.1절, 그 아래 소제목으로 이어지는 단계를 맞히려면 앞에서 어떤 제목이 나왔는지 기억해야 하는데, 고정된 양만 참고하는 방식과 맞지 않습니다. 바이두는 학습 데이터의 다양성도 부족하다고 적었습니다.

직접 돌려 보려면

모델 크기는 파라미터 약 33억 4천만 개이고, BF16 형식 가중치 파일은 두 개를 합쳐 약 6.7GB입니다. 전문가 혼합(MoE) 구조라서 글자 하나를 만들 때 실제로 계산에 쓰는 파라미터는 약 5억 개입니다. 바이두는 엔비디아 A800 80GB GPU 한 장에서 시험했고, 공식 예제 코드는 엔비디아 GPU(CUDA)를 기준으로 작성돼 있습니다.

빠르게 시험할 때는 허깅페이스 Transformers 라이브러리로 모델을 불러 쪽 이미지 목록을 넘깁니다.

infer_multi는 여러 쪽을 한 번의 요청으로 처리해서 쪽을 넘나드는 내용을 함께 봅니다. 한 쪽만 넣을 때는 infer를 쓰고, 이때는 쪽을 여러 조각으로 나눠 더 자세히 읽습니다.

여러 문서를 계속 처리하는 서버로 쓸 때 바이두는 저장소에 함께 올린 SGLang 수정판을 권합니다. SGLang은 언어 모델을 빠르게 서비스하기 위한 오픈소스 추론 서버입니다. 모델 카드의 예시 설정은 10쪽씩 묶어 처리합니다. 바이두는 묶음을 작게 할수록 메모리는 덜 쓰지만, 묶음 경계를 넘는 표와 문장을 이어 붙이는 정확도가 떨어진다고 적었습니다.

설치 없이 결과만 보고 싶다면 허깅페이스 Spaces의 공개 데모에서 쪽 이미지를 올려 확인할 수 있습니다. 모델은 중국 모델 공유 사이트인 ModelScope와 바이두 클라우드에도 올라가 있습니다.

어떤 문서에 맞을까

Unlimited OCR 2가 가장 잘 맞는 문서는 쪽이 많고 쪽을 넘어가는 표가 많은 문서입니다. 사업보고서, 감사보고서, 기술 매뉴얼, 연구 보고서처럼 표가 다음 쪽으로 이어지는 자료를 RAG에 넣기 전에 마크다운으로 바꾸는 작업이 여기에 해당합니다. 쪽마다 따로 읽는 OCR을 쓰면 다음 쪽으로 넘어간 표가 두 개로 나뉘어, 사람이 다시 이어 붙여야 했습니다.

목차 구조가 중요한 문서라면 결과의 제목 단계를 따로 확인해야 합니다. 마크다운의 #, ## 단계를 기준으로 문서를 잘라 검색 단위로 쓰는 경우, 제목 단계가 틀리면 엉뚱한 절끼리 묶입니다. 원문 PDF에 책갈피 목차가 있다면 그 목차로 제목 단계를 바로잡는 후처리를 붙이는 편이 안전합니다.

점수는 모두 바이두가 직접 측정한 값이고, 수백 쪽 벤치마크도 바이두가 만든 것입니다. 도입을 검토한다면 회사에서 실제로 다루는 문서 몇 개, 특히 쪽을 넘어가는 표가 있는 문서로 결과를 먼저 비교해 보면 판단이 빠릅니다.

참고 자료

• baidu/Unlimited-OCR-2, Hugging Face 모델 카드
• Unlimited OCR Works 2 기술 보고서(PDF), Baidu ERNIE Team, 2026년 10월
• baidu/Unlimited-OCR, GitHub 저장소
• Unlimited OCR Works: Welcome the Era of One-shot Long-horizon Parsing, arXiv, 2026년 6월