바이두, Unlimited OCR 2 공개: 요청당 수백 페이지 문서 파싱, SR-SWA와 맞춤 추론 스택에서 먼저 검증할 것
MarkTechPost가 2026년 10월 26일 보도한 바에 따르면, 바이두는 3.34B 파라미터의 Unlimited OCR 2를 MIT 라이선스로 가중치를 공개했으며, SR-SWA로 어텐션을 고정 참조 집합으로 압축해 단일 요청에서 수백 페이지 파싱을 지원한다고 밝혔다. 자체 보고 기준 MarathonDocBench 77.1점이다.
주요 변화
MarkTechPost가 2026년 10월 26일 보도한 바에 따르면, 바이두는 초장문 문서용 OCR 비전 언어 모델인 Unlimited OCR 2를 공개했으며, 가중치는 MIT 라이선스로 Hugging Face에, 코드는 GitHub에 게시됐고 2026년 6월의 Unlimited-OCR을 잇는다. 보도에 따르면 규모는 3.34B 파라미터이고 활성 파라미터 수는 공개되지 않았으며, 최대 위치 길이는 131,072 토큰이다. BF16 가중치는 약 6.7GB이고, 바이두는 NVIDIA A800-80GB 한 장에서 테스트했다. 구조는 DeepSeek-OCR 스타일을 따르며, SAM ViT-B와 CLIP-L 인코더가 12층 전문가 혼합 디코더에 연결되고 각 토큰은 64개 전문가 중 6개로 라우팅되며 공유 전문가 2개가 추가된다. 핵심 변화는 SR-SWA(희소 참조 슬라이딩 윈도우 어텐션)로, 텍스트-비전 어텐션을 고정된 작업 참조 집합으로 압축한다. 보도는 모델 카드 예시 규모를 512 토큰으로 인용하며, 설정은 128 토큰 로컬 윈도우와 32 토큰 블록에서의 top-16 선택을 결합한다. 보도에 따르면 이로 인해 단계별 디코딩 지연과 메모리 점유가 문서 증가에 거의 일정하게 유지되지만, 이미지 인코딩과 총 실행 시간은 여전히 페이지 수에 따라 증가한다. 다중 페이지 모드에서는 페이지당 273개의 이미지 토큰을 소비한다. 벤치마크와 관련해 보도는 바이두가 공개된 MPDocBench-Parse(433개 문서, 3,246페이지)와 MarathonDocBench(수백 페이지)에서 테스트했다고 전하며, MarathonDocBench의 공개 배포 버전은 찾지 못했다고 밝혔다. 바이두 리더보드 차트에 따르면 Unlimited OCR 2는 MPDocBench에서 84.6, MarathonDocBench에서 77.1을 기록했고, 비교 모델은 후자에서 최고 33.7, 전작 Unlimited-OCR은 MarathonDocBench에서 0.0이었다. 모든 수치는 바이두 자체 보고이며, 보도는 이를 차트 이미지 한 장으로만 제시했다고 전한다. 하위 항목 중 가장 낮은 것은 제목 계층(TEDS)으로 MarathonDocBench에서 48.2이며, 표 항목은 MPDocBench의 87.8에서 74.8로 떨어졌다. 실행 방식과 관련해 모델 카드는 빠른 테스트용으로 Transformers를 나열하며(infer는 단일 페이지, infer_multi는 한 요청에서 전체 페이지 파싱), 서버 측은 보도에서 말한 업스트림 SGLang이 아니라 바이두 맞춤 wheel의 SGLang을 사용한다. 로딩에는 trust_remote_code=True가 필요하며 저장소의 Python 코드가 실행된다. 보도는 또한 바이두 예시가 윈도우당 10페이지를 스케줄링하고 이전 윈도우의 KV 꼬리를 재사용하며, 윈도우가 작을수록 최대 메모리는 낮아지지만 페이지 간 병합이 약해진다는 점, 그리고 기본 bias 설정이 462MiB 할당을 유발해 메모리 부족을 일으킬 수 있다는 경고를 언급했다. 보도는 GitHub 저장소 코드의 라이선스는 밝히지 않았다.
개발자에게 미치는 영향
개발자에게 주는 의미는 여러 층으로 나뉘며, 대부분은 직접 검증이 필요하다. 첫째, VRAM과 페이지 수 상한을 추정하는 방식이 달라진다. 보도 설명대로 SR-SWA가 단계별 디코딩 비용의 페이지 수 비례 증가를 없앤다면, 고정 VRAM 예산에서 단일 요청 페이지 수를 제한하는 주된 요인은 이차적 증가하는 어텐션이 아니라 이미지 인코딩 비용, KV 꼬리 점유, 윈도우 스케줄링으로 옮겨갈 가능성이 크다. 이는 서적, 신고 서류, 연차 보고서처럼 페이지 수가 많고 상호작용이 적은 오프라인 배치 처리에 실질적 의미가 있다. 그러나 보도는 총 실행 시간이 여전히 페이지 수에 따라 증가한다고 분명히 밝히므로, 페이지별 빠른 응답이 필요한 온라인 시나리오에서의 이점은 제한적이다. 둘째는 추론 스택 종속 위험이다. 서비스 경로는 바이두 맞춤 wheel의 SGLang이며, 보도는 이를 "업스트림 SGLang이 아니라"라고 표현해 별도 유지가 필요한 벤더 분기임을 보여준다. 팀의 기존 이미지, 버전 고정, 롤백 절차가 범용 추론 프레임워크를 중심으로 구축돼 있다면, 도입은 추적해야 할 의존성 라인이 하나 늘어나는 것을 뜻한다. 모델 카드는 Transformers 경로도 제시하는데, 이는 기능 검증의 진입점으로 쓸 수 있지만 프로덕션 서비스 방안은 아니다. 셋째는 라이선스와 보안의 구분이다. 가중치는 MIT 라이선스로 공개됐는데, 이는 라이선스 차원의 관대한 허가이며 "가중치만 공개"와 혼동해서는 안 된다. 다만 보도는 가중치 라이선스만 밝혔고 GitHub 저장소 코드의 라이선스는 밝히지 않았으므로, 코드 재사용을 곧바로 MIT로 처리해서는 안 된다. 또한 MIT가 다루는 것은 허가 범위이지 trust_remote_code=True로 로드되는 코드에 대한 보안 보증이 아니다. 후자는 저장소의 Python 코드를 프로세스에서 실행하므로, 감사 요구가 있는 환경에서는 보통 코드 검토와 격리 실행을 먼저 해야 한다. 넷째는 평가 기준이다. 보도에 따르면 MPDocBench에서는 각 모델의 항목별 차이가 작다. 예로 텍스트 항목 94.8 대 94.3, 수식 항목 89.4 대 89.2이며, 차이는 주로 수백 페이지의 MarathonDocBench에 집중된다. 따라서 모델 선택 판단은 총점 순위가 아니라 자체 문서의 페이지 수 분포에 기반해야 한다. 제목 계층 48.2와 장문 문서 표 74.8이라는 두 약점은 챕터 트리와 표 적재의 하위 품질과 직결되므로 자체 샘플에서 별도로 측정해야 한다.
연동 및 평가 제안
아래는 조건부 권고이며 보도된 사실이 아니다. 결정 1: SR-SWA로 장문 문서 처리량을 얻을지 여부. 발동 조건은 한 번의 작업이 흔히 백 페이지 이상에 이르는 경우다. 문서가 대개 열 페이지 이내라면 보도의 MPDocBench 항목별 차이가 작아 전환 이유가 부족하다. 실행 가능한 판단은 자체 코퍼스를 페이지 수 두 구간(20페이지 이내와 100페이지 이상)으로 나눠 같은 VRAM 장비에서 infer_multi로 각각 실행하고, 단일 요청 최대 VRAM, 총 소요 시간, 페이지당 소요 시간 곡선을 기록하는 것이다. 100페이지 구간에서 페이지당 시간이 페이지 수에 따라 뚜렷이 증가한다면 병목이 이미 이미지 인코딩으로 옮겨간 것이므로, 단일 요청 페이지 수를 더 늘리지 말고 윈도우 페이지 수를 조정해야 한다. 결정 2: 추론 스택을 먼저 Transformers로 갈지 맞춤 SGLang으로 갈지. 전제는 팀의 기존 추론 서비스 스택이 벤더 wheel과 호환되는지다. 이미지와 롤백 절차가 맞춤 SGLang을 수용할 수 없다면 먼저 Transformers로 기능과 정확도를 검증하고, 단일 카드 단위 시간당 파싱 가능 페이지 수가 배치 윈도우를 채울 수 있는지를 기준선으로 삼는다. 맞춤 wheel을 수용할 수 있다면 보도가 언급한 위험 지점을 부하 테스트한다. 예시의 10페이지를 시작점으로 윈도우를 점차 줄여 최대 메모리를 관찰하고, 기본 bias가 유발하는 462MiB 할당이 메모리 부족을 일으키는지 확인하며, "메모리 부족 실패 없음"을 통과 필수 조건으로 삼는다. 결정 3: 구조화 출력의 합격 기준은 따로 설정해야 한다. 보도에 따르면 제목 계층은 장문 문서에서 48.2에 그치고 표 항목은 74.8로 떨어진다. 하위 시스템이 챕터 트리나 표 적재에 의존한다면, 제목 계층과 표 주석이 붙은 자체 샘플을 먼저 준비해 페이지 수 구간별로 이 두 항목을 측정한 뒤, 수동 검수나 후처리 규칙을 덧붙일지 결정해야 한다. 결정 4: trust_remote_code=True를 배포 전 점검 항목에 넣고, 격리 환경에서 먼저 실행해 저장소 코드를 검토하며, 바이두에 저장소 코드의 라이선스 조항을 확인한 뒤 프로덕션 진입 여부를 정한다. 이상의 판단은 모두 벤더 총점이 아니라 자체 라벨링 데이터셋의 오차를 기준으로 해야 한다.
제한과 확인할 사항
보도의 성능 수치는 거의 전부 바이두 자체 보고에서 나왔고, 리더보드 차트 이미지 한 장으로만 제시됐으며 독립 재현 가능한 평가 세부 사항이 없다. MarathonDocBench는 수백 페이지 기준으로 설명되지만 보도는 공개 배포 버전을 찾지 못했다고 분명히 밝혔으므로, 77.1과 다른 모델과의 비교 모두 외부에서 검증할 수 없다. 활성 파라미터 수가 공개되지 않아 실제 추론 연산량이나 처리량을 추산할 수 없다. 보도는 BF16 기준 단일 카드 실행, 가중치 약 6.7GB만 밝혔고 양자화 버전은 언급하지 않아, 더 작은 VRAM 장비에서 배포 가능한지는 현 정보로 판단할 수 없다. 이번 카탈로그 확인 시점 기준으로 Unlimited OCR 2 버전은 KimiSeek 모델 카탈로그에 나타나지 않았다. 보도가 언급한 Transformers와 맞춤 SGLang은 모델 저장소와 벤더 자료의 자체 배포 경로를 뜻하며, 해당 모델이 KimiSeek에 출시됐다는 의미가 아니다. 보도는 어떤 벤더 호스팅 서비스나 과금 방식도 언급하지 않았다. 이후 호스팅 서비스가 등장하더라도 가용성과 가격은 공식 문서와 가격 페이지를 기준으로 해야 하며, 가격은 변동될 수 있다. 보도에서 trust_remote_code=True, 기본 bias의 메모리 부족 가능성, 맞춤 SGLang에 관한 언급은 모두 벤더 자료에서 나온 것으로 제3자 검증이 없으며, GitHub 저장소 코드의 라이선스도 설명되지 않았다. 보도가 인용한 비교 모델 이름과 벤치마크 버전은 비교적 최신이며, 이 글은 자체 보고 데이터를 전달할 뿐 독립 테스트를 수행했음을 의미하지 않는다.