Unlimited OCR — Baidu의 원샷 장문 파싱 모델

 (github.com/baidu)
5P by GN⁺ | ★ favorite | 댓글 1개
  • DeepSeek OCR를 기반으로 디코더의 모든 어텐션을 교체해, 수십 페이지 문서를 한 번의 순전파(forward pass) 로 전사하는 E2E OCR 모델
  • 핵심은 참조 슬라이딩 윈도우 어텐션(R-SWA) 으로, 디코딩 길이가 늘어도 KV 캐시를 상수로 유지해 메모리·연산 비용 증가를 차단
  • 책을 베껴 쓰는 인간의 작업 기억(working memory) 을 모사해, 멀리 떨어진 출력은 부드럽게 잊고 인접 문맥만 참조하는 방식 채택
  • OmniDocBench v1.5에서 93% 로 DeepSeek OCR 대비 6% 우위, v1.6에서 93.92%로 end-to-end SOTA 달성
  • R-SWA는 OCR을 넘어 ASR·번역 등 참조 기반 장문 작업에도 적용 가능한 범용 파싱 어텐션 메커니즘

배경과 문제 정의

  • 인간은 수백 페이지 전사, 수 시간 음성 번역 같은 장문 작업에서 효율 저하 없이 수행하지만, 기존 OCR 모델은 단일 순전파로 10페이지조차 파싱 불가
    • 현재 모델들은 페이지별 처리(for-loop) 방식으로, 매 단계마다 메모리를 초기화함
    • 이 방식은 일관된 장문 과정을 고립된 단기 작업들로 분절하는 엔지니어링 우회책일 뿐, AGI 지향 지능으로의 진전은 아님
  • LLM을 디코더로 쓰면 언어의 사전 분포를 활용해 성능이 향상되나, 출력이 길어질수록 누적된 KV 캐시가 메모리 소비를 키우고 생성 속도를 점진적으로 저하시킴
  • 인간의 전사 행동은 표준 full attention도 linear attention도 아님
    • 이미 쓴 전체 텍스트를 다시 훑지 않고 인접 문맥만 참조해 방향을 유지
    • 시각/참조 토큰은 순환적 상태 갱신을 받지 않음 — 갱신 시 시각 특징이 점진적으로 흐려져 인식 정확도 저하

Reference Sliding Window Attention (R-SWA)

  • 각 토큰은 모든 참조 토큰(시각 토큰 + 프롬프트)에 접근하면서, 출력 어텐션은 직전 n개 토큰(기본값 128)으로만 제한
    • 이를 통해 각 토큰이 전체 이미지를 인지하면서 인과적 슬라이딩 윈도우 내 상태 전이로 OCR 진행 상황을 자율 추적
    • 추론 중 KV 캐시를 상수로 유지해 메모리 압박 완화 및 연산 비용 절감
  • 어텐션을 크기 m+n의 2구간 윈도우로 제한
    • m은 시각 토큰·프롬프트를 포함하는 prefix 윈도우로, 단일 추론 동안 고정이며 페이지 수·해상도에만 의존하고 디코딩 길이와 무관
    • n은 디코드 영역의 윈도우로, 크기 고정 상태로 인과적으로 슬라이딩

  • KV 캐시 관리

    • DeepSeek OCR 베이스라인은 표준 MHA를 사용해 KV 캐시 크기가 Lm + T로 무한히 증가
    • R-SWA는 전체 prefix 캐시 Lm은 유지하되 생성분은 최근 n개만 보관, 캐시 크기 Lm + min(n,T) ≤ Lm + n으로 상수 상한
    • 출력 길이가 충분히 길면 캐시 비율 ρ(T)가 0으로 수렴 → 선형 증가를 상수로 감축

  • 커널 분석

    • Flash Attention v3 커널 측정에서 DeepSeek OCR의 표준 MHA는 디코딩 단계마다 지연 시간 증가, Unlimited OCR은 R-SWA 덕분에 지속 시간 일정 유지
    • DeepSeek OCR은 KV 캐시 길이가 특정 정렬 경계를 넘을 때 데이터 전송 효율 급락으로 스파이크 발생, R-SWA에서는 미발생
    • 추론 시 GPU 메모리도 원래 모델은 선형 증가, Unlimited OCR은 고정 유지 — 연산·메모리 동시 안정성이 장문 파싱을 가능케 함

모델 아키텍처

  • DeepSeek OCR을 베이스라인으로, DeepEncoder와 MoE 디코더(총 3B, 활성 500M 파라미터) 결합
    • 기존 MHA를 R-SWA로 교체, 참조 KV 캐시 m에 고정 용량 출력 KV 버퍼 n을 더해 장문 파싱 구현
    • KV 캐시는 m+n 용량의 큐로 구현, 새 토큰 생성 시마다 (m+1)번째 토큰의 KV를 축출해 비용·메모리 비증가 보장

  • DeepEncoder

    • SAM-ViT와 CLIP-ViT를 캐스케이드, 브리지에서 16배 토큰 압축 적용 — 전반부는 윈도우 어텐션으로 원본 이미지 토큰 처리, 글로벌 어텐션은 압축 토큰 전용
    • 고해상도 이미지 인코딩 시 활성값을 낮게 유지해 GPU 메모리 절약, 1024×1024 PDF 이미지를 단 256 토큰으로 압축
    • 멀티페이지용 "Base"(1024×1024)와 단일 페이지용 "Gundam"(동적 해상도) 두 모드 채택
    • 시각 토큰은 출력과 함께 상태 전이를 겪지 않고 한 번 인코딩되어 전 과정에서 정적 유지

학습 설정

  • 약 200만 건의 문서 OCR 데이터로 학습, 단일 페이지 대 멀티페이지 비율 9:1
    • 단일 페이지 PDF는 Paddle OCR로 주석, 각 블록 좌표·내용을 연결해 ground truth 구성, 좌표는 0–1000 범위로 정규화
    • 멀티페이지는 단일 페이지 연결로 합성, 약 20만 샘플(2~50페이지)에 <page> 구분자 사용, 전체 32K 토큰 시퀀스로 패킹
  • DeepSeek OCR 체크포인트에서 4,000 스텝 추가 학습, 글로벌 배치 256, 최대 시퀀스 32K, 8×16 A800 GPU 사용
    • 학습 중 DeepEncoder는 동결하고 LLM 파라미터만 학습
    • AdamW 옵티마이저, 코사인 어닐링 스케줄러, 초기 학습률 1e-4, DeepEP(EP=4), Megatron-LM 프레임워크 기반
    • 추론은 Transformers 라이브러리에 R-SWA용 KV 캐시 관리 구현, SGLang 엔진에 최적화 지원 — 두 프레임워크 모두 상수 TPS·GPU 메모리로 동작

평가 결과

  • 주 벤치마크는 OmniDocBench(v1.5/v1.6)로, 텍스트·수식·표 구조·읽기 순서 등 다차원 파싱 능력 평가
    • v1.6은 v1.5보다 테스트 이미지 296장 추가된 최신 버전, v1.5는 DeepSeek OCR 포함 고전 모델과의 비교 제공
    • 장문 OCR 평가용 자체 테스트셋 구축, 소설·문서·논문을 2/5/10/20/40+ 페이지로 구분(각 범주 10권 이상)

  • 주요 성능

    • 단 2M 데이터 추가 학습만으로 end-to-end SOTA 달성, v1.5에서 텍스트 편집 거리 0.035 감소, 표 TEDS 5.96% 향상
    • v1.6 종합 지표 93.92% 로 end-to-end SOTA — 너비 128 R-SWA로 표준 어텐션을 전면 교체해도 효과적이며 무손실임을 입증
    • MoE 활성 0.5B 파라미터로 고효율 추론, "Base" 모드에서 5580 TPS(DeepSeek OCR 4951 TPS 대비 12.7% 속도 향상)

  • 하위 범주 분석

    • DeepSeek OCR 대비 모든 지표에서 일관된 향상으로 "공짜 점심(free lunch)" 수준의 개선 시현
    • DeepSeek OCR 2 대비 텍스트 편집 거리·읽기 순서 모두 9개 중 7개에서 우위
    • PPT·신문·잡지·노트 등 복잡한 레이아웃에서도 열세 없음

  • 장문 파싱

    • R-SWA 탑재로 수십~수백 페이지를 단일 패스로 prefill, 첫 페이지부터 끝까지 연속 파싱하며 KV 캐시 고정으로 출력 지연 일정 유지
    • 20페이지 동시 입력에서도 강건한 결과, 40+ 페이지에서 편집 거리 0.11 미만, Distinct-35 97% 유지
    • 반복 오류는 멀티페이지 "Base" 모드(1024×1024)에서 작은 글자 식별 곤란에 기인하며, R-SWA의 방향 상실 때문은 아님

효율성 분석

  • 이상적 동시성 조건에서 출력 TPS 비교(prefill 길이 10 고정)
    • 256 토큰에서는 두 모델 추론 속도 거의 동일
    • 출력 길이 증가 시 DeepSeek OCR의 TPS는 꾸준히 하락, 6,000 토큰에서 Unlimited OCR보다 35% 뒤처짐
    • 일관된 생성 속도가 장문 OCR 작업의 핵심 요구사항임을 재확인

한계와 향후 과제

  • 유한한 컨텍스트 길이(예: 32K)에서는 prefill 길이 제약으로 진정한 무제한 파싱 불가 — DeepEncoder의 높은 압축률에도 페이지 누적 시 prefill이 길어짐
  • 단기적으로 128K 등 더 긴 컨텍스트 모델 학습으로 더 많은 페이지 prefill 지원 예정
  • 장기적으로 prefill pool 구축, 모델이 prefill KV 청크를 자동 fetch하도록 학습해 인간이 페이지를 넘기는 효과를 모사함으로써 진정한 무제한 OCR 달성 목표
  • R-SWA를 ASR·번역 등 참조 기반 작업으로 이전 계획

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 꽤 흥미로움. 이해한 바로는 연구진이 긴 문서를 읽을 때 AI가 메모리를 계속 쌓아두지 않게 하는 아키텍처 해킹을 찾은 것 같음
    보통 AI가 100페이지 PDF를 전사할 때 이미 읽은 모든 단어를 기억하려고 하고, 이 단기 기억인 KV 캐시가 O(N)으로 선형 증가해서 VRAM이 바닥나거나 제한에 걸림. 그래서 개발자는 PDF를 페이지별로 쪼개 처리한 뒤 다시 붙이는 조잡한 코드를 만들게 됨
    Unlimited OCR은 Reference Sliding Window Attention(R-SWA)으로 초점을 두 경로로 나눔. 하나는 원본 문서 이미지를 온전히 보는 전역 참조이고, 다른 하나는 모델이 직접 생성한 텍스트 기억을 최근 128단어 같은 좁은 이동 창으로 제한하는 지역 생성임. 로컬 AI에 꽤 흥미로울 것 같고, 커뮤니티가 뭘 만들고 확장할지 기대됨

    • 대화에도 딱 맞는 지점이 있는 것 같음. 꽤 오래전부터 긴 대화 캡슐화를 실험해 왔는데, 잘 변하지 않는 상위 맥락과 사실이 있고, 참가자 이름이나 배경 같은 정보가 여기에 해당함
      반면 오늘 아침에 뭘 먹었는지 같은 아주 세밀한 사실은 지금은 유용할 수 있지만 장기적으로는 일반적인 경향 외에는 별 의미가 없음. 대화를 재구성하려면 지금까지 논의된 모든 것을 끌어오지 않으면서 적절한 균형을 찾아야 해서, 이 방식은 더 살펴볼 가치가 있어 보임
    • 논문 전체는 아직 안 읽었지만 지역 생성 창이 조금 작아 보임. 특히 이미지 입력은 토큰을 많이 쓰기 때문에, 지역 주의 층이 어디에 있느냐에 따라 최소 4096단어 정도로 더 크면 좋겠음
    • 이미지 OCR을 할 때 정확히 이렇게 함. 큰 이미지 하나를 여러 작은 이미지로 잘라서 LLM에 보내면 매번 완벽했지만, 전체 이미지를 넣으면 결과가 형편없었음
    • 주요 LLM 도구들은 이미 슬라이딩 윈도우 주의를 지원하는 줄 알았음
    • 이래서 LeetCode가 쓸모 있음. LeetCode를 계속 풀다 보니 이런 기법들이 왜 존재하고 실제로 어떻게 쓰이는지 보게 됨. 흥미로운 게 많음

  • 최근 악보용 태블릿을 샀는데, 주로 잼 세션에서 재즈 Real Book 묶음을 대체하려는 목적이었음. 휴대폰 카메라로 스캔한 것은 그럭저럭 괜찮지만 크기가 고정돼 있고 잡티가 많음
    Bb나 Eb 악기용으로 즉석 조옮김을 할 수 있으면 좋겠지만, 스캔본이라 당연히 불가능함. 광학 악보 인식 상태를 파보니 음악은 AI 관점에서 거의 미개척지에 가깝다는 결론이 나옴. 광학 악보 인식은 꽤 형편없고, AI의 음악 이론 이해도 실제 악보를 보는 영역에서는 형편없음. LLM은 온라인 텍스트가 학습에 들어갔을 법한 이론 개념의 텍스트 설명은 그럭저럭 잘함
    문제는 음악가가 읽는 종이 위 점들을 제대로 인코딩하는 디지털 형식이 아직 부족하다는 데 있는 것 같음. 악보 표기는 꽤 풍부함. MIDI는 주로 재생이나 연주에 필요한 측면을 담기 위해 만들어져서 상징적 이해에 필요한 모든 것을 담지 못함. MusicXML이 음악가가 원하는 정보를 담는 디지털 형식에 가장 가까워 보이지만, MusicXML 표현과 악보 이미지나 오디오를 연결하는 좋은 학습 말뭉치가 부족함. MusicXML만으로는 악보 조판에 필요한 정보가 충분하지 않기 때문인 듯함
    MuseScore 같은 도구는 MusicXML로 표현할 수 없는 레이아웃 정보를 많이 추적해야 함. LilyPond 형식은 MusicXML보다 덜 장황하고 악보 제작자에게 유용한 정보를 조금 더 담지만, 대부분은 LilyPond로 악보를 만들지 않음. 덧붙이면 재즈 글꼴 상태 때문에 LilyPond가 아쉬움. 재즈 맥락에서 “클래식식” 악보를 보는 게 싫음. OCR은 꽤 좋아 보이는 incremental 개선을 볼 때마다 OMR의 처참함이 떠오름

    • 음악학자와 음악 연구자가 쓰는 형식은 MEI임: https://music-encoding.org/ 그리고 기준 조판기는 verovio임: https://www.verovio.org/index.xhtml
      verovio는 원본 MEI 악보의 정보를 최대한 유지하면서 SVG 형식으로 조판할 수 있어서, 딥러닝 모델용 실제 탐지 데이터셋을 만들 만큼의 메타데이터를 추출할 수 있음. verovio로 조판한 악보 세트에서 COCO 데이터셋을 만드는 대충 해킹한 스크립트도 있음: https://github.com/kwon-young/music/blob/main/svg2pl.py
      여기서 만든 합성 악보 데이터셋도 공개했음: https://www.kaggle.com/datasets/kwonyoungchoi/trompa-coco/da... 위에 탐지기를 학습해보고 싶은 사람은 환영함. OMR이 이렇게 방치되는 이유는 대부분이 이 작업의 난도를 크게 과소평가하기 때문임. 극단적으로 다양한 형태와 매우 복잡한 그래픽 문법이 섞인 특수한 작업임
    • “음악은 AI가 볼 때 거의 어디나 미개척지”라는 말이 정말 맞음. 여자친구가 음악학을 공부하는데, 신체장애 때문에 가끔 필기가 어렵다 보니 AI 기반 TTS/OCR 같은 앱을 조금씩 만들어 도와주고 있음
      그러다 보면 음악이 어떤 AI 학습 데이터셋에서도 중요한 부분으로 고려된 적이 없다는 게 고통스러울 정도로 분명해짐. 요즘 Opus 4.8이 음악 이론을 이해하고 설명하는 능력은 꽤 놀랍지만, 악보를 전사하거나 OCR/OMR 하라고 하면 자신 있게 MusicXML/LilyPond 버전의 “2 + 2 = 말” 같은 결과를 내놓음. 이 무시된 영역도 커지는 AI 물결에 휩쓸리길 바라지만, 아직은 부당할 정도로 저평가되어 있음
    • 코드 분석만 필요하면 음을 모호하지 않게 표현하려는 Harte 표기법이 있음: https://ismir2005.ismir.net/proceedings/1080.pdf
      물론 조판이나 음악 전체 표현에 필요한 추가 정보까지 모두 주지는 않지만, https://github.com/smashub/choco 같은 연구 데이터셋이 있음. 분석 작업에는 https://github.com/MarkGotham/When-in-Rome 데이터셋도 써봤지만, 이것도 찾는 것과 100% 일치하진 않음. 태블릿에서 재즈 스탠더드 대체와 조옮김 용도라면 “iReal Pro” 앱이 마음에 들 수 있음. 카메라 스캔보다 그 사용 사례에는 꽤 좋음
    • https://abcnotation.com/ 같은 악보 조판 형식은 어떰?
    • 음악 OCR 영역을 지켜보면 지금까지 정말 괜찮은 해법은 soundslice뿐인 것 같음. 스캔한 뒤 일부 엣지 케이스만 검토하면 결과가 아주 좋음. 작은 회사의 유료 서비스인데 충분히 후원할 만함

  • “Deepseek-OCR, Deepseek-OCR-2, PaddleOCR의 가치 있는 모델과 아이디어에 감사한다”고 적은 건 품격 있는 태도임

    • 왜 비꼬는 건지 이해가 안 됨

  • 참고로 “Unlimited OCR Works”는 Fate/stay night의 Unlimited Blade Works 패러디임. 원래 Unlimited Blade Works는 다른 사람이 만든 무기를 복제하는 마법이라는 설정임

  • 논문은 https://arxiv.org/abs/2606.23050에 있음
    참고로 책에서 읽은 인용문을 위한 작은 RAG 용도로 로컬 OCR을 하고 있고, 나도 RAM을 아끼려고 입력을 청크로 나누는데, 이런 자연스러운 접근이 스트리밍 모델에서도 통한다는 점이 흥미로움

  • Mistral이 방금 출시한 것보다 더 유망해 보임. 우연이라고? 아닐 것 같음
    이 접근은 이미지 생성에도 어떤 조합으로 쓸 수 있을 듯함. 이미지를 읽거나 본 뒤 Illustrator/Inkscape 같은 도구나 SVG로 그리기 시작하고, 빠진 부분을 나중에 채우는 식으로 가능해 보임

  • 이게 다른 OCR 도구들을 압도하는 듯했던 infinty parser 2와 어떻게 비교되는지 궁금함: https://huggingface.co/datasets/allenai/olmOCR-bench
    공정하게 말하면 단일 승자 OCR 벤치마크는 없고, 이 도구는 아직 어디에도 올라와 있지 않음

  • 내가 세상 물정 모르는 사람처럼 들리겠지만, 회사들이 진짜 좋은 소프트웨어를 오픈소스로 공개하는 실제 이유가 뭘까?
    Baidu나 Google이라면 경쟁사가 따라 하지 못하게 혼자 보유해서 가치를 뽑아내야 하는 것 아닌가?

    • 대기업 안에도 오픈소스의 이상을 믿고 고용주를 설득해 프로젝트 공개를 허락받는 사람들이 있음
      회사는 명성을 얻고, 이는 채용 퍼널에 도움이 됨. 때로는 Meta가 Ollama를 공개한 것처럼 전략적으로 경쟁사를 흔들 수도 있음
    • 오픈소스 모델 공개는 미국 AI 연구소들의 매출을 빼앗을 수 있음. 그 연구소들이 장기 경쟁에서 이기기 위해 재투자할 돈을 줄이면 중국에 도움이 될 수 있음

  • AI로 OCR을 해본 시도는 항상 지어낸 결과물이 섞였고, 그래서 프로덕션에 쓰기 어려웠음. 이것도 그런 문제가 있는지 궁금함
    간단한 예로 다른 언어로 남아 있어야 할 단어들이 자동으로 영어로 번역되어 효과를 망치는 경우가 있음

    • 거의 단어보다 큰 수준의 기계학습, 즉 단어쌍·구·문장·문서·말뭉치 수준은 원하지 않게 됨
      전사에서는 거의 확실한 결과를 원하거나, 확실히 읽을 수 없었다는 표시를 원함. 문맥으로 추측할 수는 있지만, 어떤 OCR에서는 글자들이 순서대로 모여 단어를 이룬다는 사실 외의 근거로 추측한 것인지 알아야 함
      예를 들어 familysearch.com의 인구조사 문서에서 전사자가 이름을 Joseph으로 “교정”했는데, 손글씨 문서의 실제 글자는 Josepth였고, 실제로 그 지역 변형 철자였음. 다른 문서에서는 작성자가 “Joh”를 약어로 썼고, 아마 인간 전사자가 John으로 옮겼는데, 가장 그럴듯하긴 해도 실제로는 틀렸음. 어떤 때는 추측이라는 사실이 중요하고, 어떤 때는 그냥 최선의 추측이 필요함
    • 100% 인식 결과를 원한다면 이 방법에 원본 문서 재구성 이미지 모델을 결합하겠음. 전사 텍스트와 레이아웃을 맞춰 원본 문서를 다시 만들게 하는 방식임
      테스트하려는 페이지나 문단만 제외하고 나머지 문서를 사용하면, 이미지 아티팩트에서 시험 대상 구절을 그대로 재생성하는 걸 피할 수 있음. 재구성 뒤에는 어긋난 문자를 특정해 맞춰보는 광학 비교를 해서 오류를 찾고 반복하면 됨. 비싸겠지만 100% 인식을 보장할 수 있음
    • 4090에서 이 모델로 일본어 문법 PDF를 전사해보고 있음. 영어로 쓰였고 일본어 예문이 많은 문서인데, 내가 일부 대조해본 범위에서는 꽤 잘 작동함
      출력은 필요한 곳에 한자/히라가나와 영어를 적절히 유지하고, 번역하려고 하지 않음. 한 시간에 약 200페이지를 변환했음
    • 어떤 모델이나 도구를 써왔는지 궁금함

  • Reducto는 어떻게 됐는지 모르겠음. 12~15개월 전에는 꽤 유망해 보였음

답변달기