개요: ATH-MaaS/OvisOCR2 - Qwen3.5-0.8B를 기반으로 사후 학습(post-trained)된 0.8B 규모의 문서 파싱 VLM (SFT + RL + OPD)입니다. Apache 2.0 라이선스이며, vLLM 0.22.1에서 실행됩니다. 페이지 이미지당 하나의 프롬프트(prompt)를 사용하여 완전한 마크다운(HTML 표, LaTeX 수식, 그림을 위한 bbox 스텁 포함)을 생성합니다. OmniDocBench v1.6에서 96.58점을 기록했으며, 해당 리더보드에서 1위를 차지한 최초의 엔드투엔드 (end-to-end) 모델입니다. 지금까지 그보다 높은 점수를 기록했던 모든 모델은 파이프라인 (pipeline) 방식이었습니다.

이것이 중요한 이유: 파이프라인 (pipeline) OCR (레이아웃 탐지기(layout detector) -> 영역 크롭(crop regions) -> 각 영역 OCR -> 재조립)은 레이아웃 단계에서 실패합니다. 탐지기가 영역을 놓치면 해당 텍스트는 소리 없이 사라집니다. 엔드투엔드 (end-to-end) 방식은 실패할 레이아웃 단계가 없습니다. 또한 이는 하나의 모델, 하나의 서빙 스택(serving stack)을 의미하며, 별도의 결합 설정(glue config)이 필요 없음을 뜻합니다.

나의 테스트: 827개의 실제 스캔된 문서 vs 비교 대상인 파이프라인 (pipeline) OCR. 827개의 실제 의료 서신(빽빽한 인쇄물, 표, 팩스, 품질이 매우 낮은 스캔본)에 대해 GLM-OCR (0.9B 파이프라인) 배포 모델과 비교했습니다. Gemini 3.5 Flash의 전사(transcription)를 유사 정답(pseudo-ground-truth)으로 사용하여 두 모델을 평가했습니다 (단어 수준 F1, 참조 데이터가 포함된 약 780개 문서 기준):

핵심은 하위 성능(the tail)에 있습니다: Ovis의 10백분위수(10th percentile)가 파이프라인의 중앙값(median)과 비슷합니다. 파이프라인이 크게 패배한 모든 문서는 레이아웃 탐지기(layout-detector)의 누락 때문이었습니다.

단일 RTX 5090 (vLLM 0.22.1)에서의 처리량 (150 DPI 렌더링, temperature 0, max_tokens 4096):

임계점(elbow)은 cc=32 (~0.10 GPU-s/page)입니다. 이 지점을 넘어서면 처리량(throughput)은 감소하고 지연 시간(latency)은 큐 깊이(queue depth)에 따라 증가합니다.

한계점: 단일 요청 지연 시간(single-request latency)은 디코드 제한(decode-bound) 상태입니다 (페이지 시간의 약 76%; 단일 스트림에서 약 570 tok/s - 전형적인 소형 모델의 가중치 읽기 병목 현상). 하지만 포화된 처리량(saturated throughput)은 프리필 제한(prefill-bound) 상태입니다. 한 페이지는 약 2.3k의 이미지 토큰(image tokens)과 약 600개의 출력 토큰(output tokens)으로 구성되므로, GPU가 처리하는 토큰 5개 중 약 4개가 프리필(prefill)에 해당합니다.

KV cache는 ~11%를 넘지 않았습니다 - 이 모델에 있어 VRAM은 완전히 무관합니다. 16 GB 카드로도 충분히 구동 가능하며, 단지 비례적으로 느려질 뿐입니다 (메모리 대역폭 제한(memory bound)이 아닌 연산 및 대역폭 제한(compute + bandwidth bound) 문제임). DPI 관련 결과: 200 $\rightarrow$ 150 DPI로 변경 시 처리량(throughput)은 +50% 증가하지만, F1 점수 변화는 전혀 없었습니다 (150 DPI는 공짜나 다름없습니다). 100 DPI는 처리량을 추가로 +30% 늘려주지만, 품질의 꼬리(quality tail) 부분이 끔찍하게 무너집니다: 표의 셀들이 합쳐집니다 (날짜가 주소와 병합되거나 rowspan 혼동 발생). 만약 문서에 중요한 표가 포함되어 있다면, 150 DPI 미만으로 내려가지 마세요.

주의사항 (어렵게 배운 교훈)
반복 루프 (페이지의 약 0.5%): 탐욕적 디코딩 (greedy decode)이 가끔 1111111... / O O O O / 이모지 스팸이 토큰 제한에 도달할 때까지 이어지는 현상으로 무너집니다. 이는 결정론적(deterministic)이며 재현 가능합니다. 실패한 페이지들에 대해 완화 조치(mitigations)를 테스트했습니다: frequency_penalty 0.3은 5/5개를 해결했고, presence_penalty 1.0은 4/5개, repetition_penalty 1.05-1.1은 단 2/5개만 해결했습니다 (!). temp 0.2는 도움이 되지 않았습니다. 권장 레시피: 첫 번째 패스는 greedy로 진행하고, (finish_reason=length 이거나 퇴보한 꼬리(degenerate tail)가 감지되면) frequency_penalty 0.3을 적용하여 한 번 재시도하십시오. 첫 번째 패스에 페널티를 적용하지 마세요. 정당하게 반복되는 콘텐츠(표의 열 등)를 왜곡할 수 있습니다. max_tokens를 제한하십시오. 루프가 발생한 페이지 하나가 배치(batch) 끝에서 혼자 16k 토큰을 디코딩하면, 약 30초의 지연(straggler tail)이 발생합니다. max_tokens를 4096으로 제한하기 전까지, 이 지연 발생 위치에 따라 제 벤치마크 수치는 383 $\rightarrow$ 895 p/min 사이를 요동쳤습니다 (일반적인 페이지는 출력 토큰이 약 800개 정도에서 끝납니다. 제한 없이 재시도하는 것은 꼬리 부분이 깨끗한 텍스트일 때, 즉 정말로 긴 페이지인 경우에만 수행하십시오).

OCR 워크로드에는 --mm-processor-cache-gb 0을 사용하세요. 실제 페이지는 고유하기 때문에 (hit rate 0%), 반복되는 이미지로 벤치마크를 수행하면 캐시가 예열되어 영광스러운 가짜 수치를 보여줍니다 (저는 MM 캐시 적중률이 100%인 것을 발견하기 전까지 1,000+ p/min을 "측정"했습니다). ninja가 반드시 설치되어 있어야 합니다. 그렇지 않으면 --gdn-prefill-backend triton 경로가 시작 시점에 아무런 설명 없는 FileNotFoundError와 함께 종료됩니다 (GDN 선형 어텐션(linear-attention) 커널이 JIT 컴파일되기 때문입니다).

위의 모든 문제를 해결하고 실행 가능한 런칭 명령(Launch command)은 다음과 같습니다: vllm serve ATH-MaaS/OvisOCR2 --gpu-memory-utilization 0.9 \ --max-model-len 32768 --gdn-prefill-backend triton \ --mm-processor-cache-gb 0 --disable-uvicorn-access-log 결론: 제가 가진 코퍼스(corpus)에서 이 0.8B 엔드투엔드 (end-to-end) 모델은 훨씬 더 단순한 스택을 사용하면서도, 튜닝된 파이프라인 (pipeline)보다 정확도(특히 최악의 경우) 면에서 앞섰으며, GPU당 효율성은 약 2~4배 더 높았습니다. 반복 루프(repetition loops)가 유일한 실제 결함이지만, 탐지 및 재시도(detect-and-retry) 가드(guard)를 통해 이를 완전히 제어할 수 있습니다. 이제 파이프라인 OCR (Pipeline OCR)을 사용할 명분이 매우 희박해졌습니다. submitted by /u/Littlepharaoh [link] [comments]