Baidu Unlimited OCR 해설: 긴 문서 OCR은 모델 크기보다 KV 캐시·해상도·회귀 검증 경계를 먼저 설계해야 하는 이유

OCR은 오래된 기술처럼 보이지만, 실제 업무에서는 여전히 까다롭습니다. 계약서, 논문, 매뉴얼, 스캔 PDF처럼 긴 문서를 처리하면 페이지 분할, 표/수식 복원, 작은 글씨, GPU 메모리, 처리 시간 문제가 한꺼번에 터집니다. 바이두가 공개한 Unlimited OCR은 이 문제를 “더 큰 모델”이 아니라 긴 출력에서 KV 캐시가 계속 커지는 구조를 바꾸는 방식으로 접근합니다.

1. 한 줄 문제 정의

핵심 한 줄: 긴 문서 OCR의 병목은 인식 모델 하나가 아니라 출력이 길어질수록 커지는 메모리와 느려지는 생성 루프입니다.

초보 개발자 기준으로 KV 캐시는 모델이 방금까지 생성한 내용을 다시 참고하기 위해 들고 있는 작업 메모리입니다. 일반적인 LLM 디코더는 출력 토큰이 길어질수록 이 메모리가 계속 늘어납니다. OCR에서 수십 페이지 문서를 한 번에 텍스트로 뽑으려 하면 바로 이 부분이 GPU 메모리와 속도 병목이 됩니다.

이 글은 PDF OCR 파이프라인을 만들거나, 사내 문서 검색용 텍스트 추출기를 운영하거나, VLM 기반 문서 파싱 모델을 검토하는 개발자를 대상으로 합니다. 범위는 Unlimited OCR의 R-SWA 구조, 실행 방법, 도입 판단입니다. 단순 영수증 한 장이나 정형 양식 몇 개만 처리한다면 이 모델은 과할 수 있습니다.

2. 먼저 결론

핵심 한 줄: Unlimited OCR은 “OCR 정확도 신기록”보다 “긴 출력에서도 메모리 사용량을 일정하게 묶는 설계”로 봐야 합니다.

바이두 연구진은 2026년 6월 22일 arXiv에 Unlimited OCR을 공개했습니다. DeepSeek OCR을 기반으로 디코더의 모든 어텐션을 Reference Sliding Window Attention, 줄여서 R-SWA로 교체했고, 표준 최대 길이 32K 안에서 수십 페이지 문서를 단일 forward pass로 전사할 수 있다고 설명했습니다.

AI타임스는 2026년 6월 27일 기사에서 OmniDocBench v1.5 93.23점, v1.6 93.92점, 기본 모드 5580 TPS, 6000토큰 생성 시 기존 대비 약 35% 높은 처리 성능, 40페이지 이상 문서에서 편집 거리 0.11 이하라는 수치를 소개했습니다. 이 수치는 관심을 끌 만하지만, 제품 도입에서는 자체 문서 50~100개로 재검증해야 합니다.

3. 핵심 구조 분해

핵심 한 줄: Unlimited OCR은 이미지 압축, R-SWA 디코더, 반복 억제, PDF 전처리 흐름이 함께 맞물려 동작합니다.

첫 번째 층은 이미지 인코더입니다. Unlimited OCR은 DeepSeek OCR의 DeepEncoder 계열 구조를 활용해 문서 이미지를 적은 수의 비전 토큰으로 압축합니다. 입력 단계에서 토큰이 줄어야 여러 페이지를 한 번에 넣을 여지가 생깁니다.

두 번째 층은 R-SWA입니다. R-SWA는 이미지와 입력 프롬프트 같은 참조 토큰은 유지하되, 이미 생성한 모든 출력 토큰을 계속 들고 있지 않습니다. 최근 출력 일부만 창처럼 유지합니다. 사람이 책을 베껴 쓸 때 원본과 방금 쓴 몇 줄만 확인하는 방식에 가깝습니다.

세 번째 층은 반복 억제입니다. GitHub와 Hugging Face 예시는 no_repeat_ngram_size=35, 단일 이미지 ngram_window=128, 다중 페이지 ngram_window=1024 같은 값을 사용합니다. 긴 문서 생성에서 반복 문구가 생기면 OCR 결과가 망가지므로, 메모리 최적화와 반복 억제가 같이 필요합니다.

네 번째 층은 실행 모드입니다. 단일 이미지는 gundam 또는 base 모드를 쓸 수 있고, 다중 페이지/PDF는 base 모드만 사용한다고 문서에 적혀 있습니다. 즉 “긴 문서가 된다”는 말은 원본 PDF를 적절한 해상도의 이미지 페이지로 바꾸고, 페이지 수와 32K 출력 한계를 함께 관리한다는 뜻입니다.

4. 설계 의도 해설

핵심 한 줄: 설계 의도는 문서 전체를 페이지별로 쪼개지 않고도 긴 복사 작업을 안정적으로 이어가게 만드는 것입니다.

기존 OCR 파이프라인은 문서 감지, 레이아웃 분석, 글자 인식, 후처리를 나눠 구성하는 경우가 많았습니다. 최신 VLM 기반 OCR은 문서 이미지를 보고 바로 텍스트를 생성하므로 구조가 단순해집니다. 대신 LLM 디코더가 긴 출력을 만들면서 KV 캐시가 계속 커지는 비용을 떠안습니다.

Unlimited OCR의 선택은 여기서 갈립니다. 모델 전체를 새로 키우기보다, DeepSeek OCR 기반 체크포인트를 활용하고 디코더 어텐션 구조를 바꿉니다. 연구진은 200만개 문서 데이터로 4000단계 continual training을 수행했고, 90%는 단일 페이지, 10%는 여러 페이지 연결 문서였다고 설명합니다.

이 접근의 이득은 분명합니다. 긴 문서에서 메모리 사용량과 토큰 생성 시간이 출력 길이에 비례해 계속 증가하는 문제를 줄일 수 있습니다. 포기하는 것도 있습니다. 전체 과거 출력에 대한 직접 참조를 줄이므로, 멀리 떨어진 문맥을 엄밀히 맞춰야 하는 작업에서는 별도 검증이 필요합니다.

5. 근거 및 비교

핵심 한 줄: Unlimited OCR은 전통 OCR, 페이지별 VLM OCR, 긴 컨텍스트 LLM OCR 사이의 운영 비용 문제를 겨냥합니다.

접근	핵심 방식	장점	한계	적합한 상황
전통 OCR 파이프라인	레이아웃 분석과 문자 인식을 단계별 처리	운영이 예측 가능하고 CPU/경량 GPU에서도 가능	복잡한 표, 수식, 비정형 문서 복원 품질이 낮을 수 있음	정형 서식, 대량 스캔, 비용 민감 업무
페이지별 VLM OCR	각 페이지 이미지를 따로 넣고 텍스트 생성	도입이 쉽고 실패 페이지를 분리하기 좋음	페이지 사이 문맥과 표 이어짐을 놓치기 쉬움	페이지 독립성이 높은 문서
긴 컨텍스트 LLM OCR	긴 입력과 긴 출력을 한 번에 처리	문서 전체 흐름을 유지하기 쉬움	KV 캐시와 생성 시간이 출력 길이에 따라 커짐	문서 수가 적고 정확도 우선인 고가치 작업
Unlimited OCR	R-SWA로 참조 토큰과 최근 출력만 유지	긴 출력에서 메모리 증가를 억제하고 단일 추론 문서 파싱을 노림	저해상도 작은 글씨, 32K 길이, GPU 환경, 재현 검증 부담이 있음	긴 PDF, 표/수식 포함 문서, VLM OCR 비용 병목 개선

arXiv 초록은 R-SWA가 전체 디코딩 과정에서 KV 캐시를 일정하게 유지한다고 설명합니다. GitHub와 Hugging Face에는 transformers 실행 예시와 SGLang 서버 실행 예시가 공개되어 있습니다. 이는 단순 발표가 아니라 개발자가 실제로 내려받아 검증할 수 있는 형태라는 점에서 의미가 있습니다.

다만 AI타임스 기사에 나온 벤치마크 수치는 그대로 제품 SLA가 되지 않습니다. OmniDocBench 점수, TPS, 편집 거리는 특정 데이터셋과 실행 조건의 결과입니다. 사내 문서가 저해상도 스캔, 도장/서명, 양면 스캔, 손글씨, 복잡한 표를 포함한다면 별도 기준을 잡아야 합니다.

6. 실제 동작 흐름 / 단계별 실행 방법

핵심 한 줄: 먼저 작은 PDF 세트로 설치, 변환, 추론, 품질 채점, 비용 측정을 한 번에 기록해야 합니다.

Hugging Face 예시는 Python 3.12.3, CUDA 12.9, PyTorch 2.10.0, transformers 4.57.1, PyMuPDF 1.27.2.2 환경을 기준으로 제시되어 있습니다. 운영 서버에 바로 올리기보다 별도 GPU 실험 환경에서 시작하는 편이 안전합니다.

import os
import tempfile
import fitz
import torch
from transformers import AutoModel, AutoTokenizer

model_name = "baidu/Unlimited-OCR"
tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True)
model = AutoModel.from_pretrained(
    model_name,
    trust_remote_code=True,
    use_safetensors=True,
    torch_dtype=torch.bfloat16,
).eval().cuda()

def pdf_to_images(pdf_path, dpi=300):
    doc = fitz.open(pdf_path)
    tmp_dir = tempfile.mkdtemp(prefix="pdf_ocr_")
    mat = fitz.Matrix(dpi / 72, dpi / 72)
    paths = for i, page in enumerate(doc):
        out = os.path.join(tmp_dir, f"page_{i+1:04d}.png")
        page.get_pixmap(matrix=mat).save(out)
        paths.append(out)
    doc.close()
    return paths

model.infer_multi(
    tokenizer,
    prompt="<image>Multi page parsing.",
    image_files=pdf_to_images("sample.pdf", dpi=300),
    output_path="./outputs",
    image_size=1024,
    max_length=32768,
    no_repeat_ngram_size=35,
    ngram_window=1024,
    save_results=True,
)

실험 로그는 아래처럼 남기는 것을 추천합니다.

{
  "doc_id": "contract-001",
  "pages": 18,
  "dpi": 300,
  "image_size": 1024,
  "max_length": 32768,
  "ngram_window": 1024,
  "gpu": "A100-80GB",
  "latency_sec": 0,
  "peak_vram_gb": 0,
  "edit_distance_sample": 0,
  "table_reconstruction_pass": false
}

이 값이 있어야 기존 OCR, 페이지별 VLM OCR, Unlimited OCR을 같은 기준으로 비교할 수 있습니다. 특히 max_length=32768은 무한 문서라는 뜻이 아닙니다. 결과가 잘리거나 표가 무너지는 지점을 반드시 찾아야 합니다.

7. 실수/함정(Pitfalls)

핵심 한 줄: 긴 문서 OCR은 모델 설치보다 입력 품질과 검증 루프에서 더 많이 실패합니다.

1. 함정: PDF를 낮은 DPI로 이미지화한다.
   예방: 300 DPI를 기준으로 시작하고 작은 글씨 문서는 샘플별로 해상도를 올려 비교합니다.
   복구: 오류 페이지를 원본 이미지와 함께 저장해 저해상도 문제인지 모델 문제인지 분리합니다.
2. 함정: 32K 길이를 사실상 무제한으로 오해한다.
   예방: 페이지 수, 평균 토큰 수, 표/수식 비중을 기준으로 문서 길이 상한을 정합니다.
   복구: 잘림이 발생하면 장/섹션 단위 분할과 페이지별 후처리 병합으로 fallback합니다.
3. 함정: 벤치마크 점수만 보고 기존 OCR을 대체한다.
   예방: 내부 문서 50~100개로 편집 거리, 표 복원, 수식 복원, 처리 시간, VRAM을 동시에 측정합니다.
   복구: 정형 문서는 기존 OCR, 복잡 문서는 VLM OCR처럼 라우팅 정책을 둡니다.
4. 함정: 반복 억제 파라미터를 기록하지 않는다.
   예방: no_repeat_ngram_size와 ngram_window를 결과와 함께 저장합니다.
   복구: 반복 문구가 생긴 문서는 같은 이미지로 파라미터를 바꿔 재실험합니다.
5. 함정: trust_remote_code를 운영 서버에서 무심코 켠다.
   예방: 모델 코드를 고정 커밋으로 검토하고, 격리된 컨테이너에서 실행합니다.
   복구: 운영 반영 전 SBOM, 네트워크 차단, 읽기 전용 볼륨, 권한 최소화를 적용합니다.

8. 강점과 한계

핵심 한 줄: 강점은 긴 출력의 비용 구조를 바꾼 것이고, 한계는 실제 문서 품질과 운영 검증을 대신해 주지 않는다는 점입니다.

강점은 분명합니다. 긴 문서를 페이지별로 쪼개지 않고 처리할 가능성을 열어 줍니다. 표, 수식, 복잡 레이아웃을 포함한 엔드투엔드 OCR에서 기존 방식보다 좋은 결과를 낼 수 있습니다. 코드와 가중치가 공개되어 있어 내부 문서로 직접 검증할 수 있다는 점도 큽니다.

한계도 현실적입니다. 첫째, 단일 추론 문서 파싱은 GPU 메모리와 모델 로딩 비용을 요구합니다. 둘째, 작은 글씨나 저해상도 스캔은 R-SWA가 해결할 문제가 아닙니다. 셋째, 긴 문서 전체를 한 번에 처리하면 실패했을 때 어느 페이지에서 틀렸는지 추적하기 더 어려울 수 있습니다.

제가 보는 도입 판단은 보수적입니다. 기존 OCR이 잘 되는 정형 문서에는 굳이 바꿀 이유가 적습니다. 반대로 페이지별 처리 때문에 표가 끊기거나, 긴 논문/보고서의 구조 복원이 중요한 팀이라면 별도 실험 큐를 만들 가치가 있습니다.

9. 더 깊게 공부할 포인트

핵심 한 줄: R-SWA만 보지 말고 문서 이미지 전처리, 반복 억제, 벤치마크 기준, 보안 실행까지 같이 봐야 합니다.

• arXiv - Unlimited OCR Works (제출일: 2026-06-22, 확인일: 2026-06-27): R-SWA의 문제 정의와 공개 정보의 1차 출처입니다.
• arXiv HTML - Unlimited OCR Works (확인일: 2026-06-27): 초록과 구조 설명을 브라우저에서 확인하기 좋습니다.
• GitHub - baidu/Unlimited-OCR (공개일 공지: 2026-06-22, 확인일: 2026-06-27): transformers, SGLang, PDF 변환 예시를 확인할 수 있습니다.
• Hugging Face - baidu/Unlimited-OCR (확인일: 2026-06-27): 모델 카드, 실행 요구사항, 추론 예시를 볼 수 있습니다.
• AI타임스 - 바이두, '언리미티드 OCR' 공개 (발행일: 2026-06-27): 한국어로 주요 수치와 배경을 빠르게 확인할 수 있습니다.

추가 학습 순서는 이렇게 잡으면 좋습니다. 먼저 arXiv 초록에서 KV 캐시 문제와 R-SWA 의도를 확인합니다. 다음으로 GitHub의 infer_multi 예시를 읽고 입력 이미지 변환 과정을 봅니다. 마지막으로 내부 문서 샘플을 만들어 표/수식/작은 글씨/긴 페이지에서 어떤 실패가 나는지 기록합니다.

10. 실행 체크리스트 + 작성자 관점

핵심 한 줄: Unlimited OCR 도입의 완료 기준은 “돌아간다”가 아니라 “기존 파이프라인보다 어느 문서군에서 나은지 증명했다”입니다.

Definition of Done: 내부 검증 세트에서 Unlimited OCR이 기존 파이프라인 대비 목표 문서군의 오류율 또는 처리 비용을 명확히 낮추고, 실패 문서 fallback과 보안 실행 기준까지 통과하면 1차 도입이 완료된 것으로 봅니다.

작성자 관점에서 이 기술은 “모든 OCR을 대체할 모델”이라기보다 긴 문서 OCR 파이프라인의 병목을 다시 생각하게 만드는 사례입니다. 도입 추천 대상은 긴 PDF, 표/수식, 멀티페이지 문맥 때문에 기존 OCR 후처리가 무거운 팀입니다. 반대로 정형 문서 몇 종류만 안정적으로 처리하는 팀은 기존 OCR에 검증 자동화와 라우팅을 붙이는 편이 더 낫습니다.

11. 참고자료

• AI타임스 - 바이두, '언리미티드 OCR' 공개… "메모리 한계 깨고 수십 페이지 문서도 한 번에" (발행일: 2026-06-27, 확인일: 2026-06-27)
• arXiv - Unlimited OCR Works (제출일: 2026-06-22, 확인일: 2026-06-27)
• arXiv HTML - Unlimited OCR Works (확인일: 2026-06-27)
• GitHub - baidu/Unlimited-OCR (공개 공지: 2026-06-22, 확인일: 2026-06-27)
• Hugging Face - baidu/Unlimited-OCR (확인일: 2026-06-27)