Jina AI
Alejandro Barón García
우리는 토큰당 약 570M 개의 활성 디코더 파라미터를 사용하는 3.4B 파라미터 문서 파서인 jina-ocr-v1을 공개합니다. 이 모델은 OmniDocBench v1.6에서 91.14점, olmOCR-Bench에서 83.4점을 기록했으며, 초당 2.57페이지의 속도로 우리가 측정한 14개의 시스템 중 가장 높은 페이지 처리량을 보입니다. NVIDIA L4 환경에서 추측 디코딩 헤드는 디코딩 손실 없이 디코딩 속도를 거의 두 배로 높입니다.
이 모델은 DeepSeek-OCR의 압축 비전 인코더와 Mixture-of-Experts 디코더를 기반으로 두 가지를 추가했습니다. FastMTP 초안 헤드는 하나의 블록을 재귀적으로 3개의 예측 단계에 적용하므로, 초안 파라미터가 깊이에 따라 증가하지 않습니다. 사후 학습은 밀도 높은 검증 가능 보상하에 실행되며, 모든 확인은 참조 데이터와 대조하는 결정론적 코드이며 각각 등급이 매겨집니다. 이러한 백본을 바탕으로 사후 학습은 olmOCR-Bench에서 7.4점을 추가하고 모든 OmniDocBench 열의 성능을 개선했습니다.
词元당 픽셀 수, 로그 스케일. DeepEncoder는 1024x1024 뷰를 4,096개 패치에서 256개 词元으로 매핑하여 28~32px 패치를 사용하는 인코더의 783~1,022픽셀 대비 词元당 3,887픽셀을 제공합니다. (b) olmOCR-Bench에서의 페이지 처리량, A100 1개, 동시성 32. (c) 활성 파라미터 대비 벤치마크 총점, 로그 스케일, 실선은 파레토 최적 시스템을 연결합니다. jina-ocr-v1은 570M 활성 파라미터에서 두 경계선 모두에 위치합니다.
词元 수, (b) 페이지당 출력 词元 수, (c) 초당 페이지 수(앞의 두 비율). Surya OCR 2는 3,760으로 초당 词元 수에서 앞서지만 페이지당 3,568 词元을 생성하며 초당 1.05페이지를 완료합니다. jina-ocr-v1은 초당 2,792 词元과 페이지당 1,085 词元을 결합하여 2.57을 달성합니다.tag모델 및 학습
긴 출력물은 문서 파싱의 디코딩 비용을 높이는 주원인입니다. DeepSeek-OCR은 압축 비전 인코더와 소형 Mixture-of-Experts 디코더로 해당 비용의 대부분을 제거했으며, jina-ocr-v1은 이를 상속받아 잔존하는 자기회귀 병목 현상을 타겟팅합니다.
词元으로 구성된 1024x1024 글로벌 뷰와 각 100개의 词元으로 구성된 n개의 로컬 타일을 생성합니다. 주황색으로 표시된 FastMTP 헤드는 디코더가 검증할 수 있도록 하나의 공유 초안 블록에서 K = 3개의 词元을 제안합니다.OCR 출력은 거의 결정론적이며 국소적인 구조를 가지고 있어, 추측 디코딩에 유리한 작업입니다. 일반적인 구성은 예측 깊이마다 하나의 초안 헤드를 부착하므로 모델이 앞을 내다볼수록 초안 파라미터가 증가합니다. FastMTP는 K = 3 단계에 대해 재귀적으로 적용되는 단일 밀도 블록을 사용합니다. 검증기는 각 제안을 탐욕적으로 확인하고 초안과 검증기가 일치하는 가장 긴 접두사를 수락하므로, 확정된 시퀀스는 검증기의 탐욕적 시퀀스와 동일하며 추측은 출력 시간에만 영향을 미칩니다.
| 구성 요소 | 사양 |
|---|---|
| 비전 인코더 | DeepEncoder (~380M): SAM (80M) → 16x conv → CLIP-L (300M) |
비전 词元 | 256 @ 1024x1024 (Base); 256+100n, n ≤ 9 (Gundam, ≤ 1,156/page) |
| 디코더 | DeepSeek-3B-MoE: 12 레이어, d = 1280, 64 routed + 2 shared, top-6 |
| 활성 / 전체 파라미터 | ~570M / ~3B (디코더); < 1B / ~3.4B (전체 모델) |
| 어휘 | 129,280 |
| 위치 제한 | 32,768 (RoPE, θ = 106) |
| MTP 헤드 | 1 공유 밀도 블록, 재귀적 K = 3 단계 (FastMTP) |
모델 사양. 디코더는 마크다운(Markdown)을 생성하며, 표는 HTML, 수식은 LaTeX 형식입니다.
학습 데이터는 olmOCR-mix, FinePDFs, LightOnOCR, MMTab, UniMER를 포함한 공개 OCR 코퍼스와 Europeana 신문, 의회 도서관 필사본, NARA 연금 기록과 같이 의도적으로 난도가 높은 소스를 활용합니다. 규칙 기반 필터는 퇴화 루프와 중복을 제거하며, 비전-언어 패스는 어려운 소스에 다시 레이블을 지정합니다. 또한 특정 이유로 페이지를 합성하는데, 자연 페이지에서는 수식 및 표 보상 항목이 매우 적은 샘플에만 적용되어 대부분의 롤아웃이 구조적 신호를 전달하지 못하기 때문입니다. JinaOCRSynth는 각 페이지에 점수를 매길 수 있는 수식과 표를 포함하고 단위 테스트를 함께 제공합니다.
사후 학습은 지도 정렬, 손상된 페이지에 대한 강건성 미세 조정, 그리고 외부 루프의 반복 단계에 걸쳐 GRPO를 실행합니다. GRPO 보상은 참조 필사본과 대조되는 결정론적 코드로 계산된 검증 가능한 항목들의 곱입니다.
| 구성 요소 | 신호 | 역할 |
|---|---|---|
| 콘텐츠 | 혼합 LaTeX/HTML에 대한 정규화된 편집 거리 | 텍스트 충실도 |
| 수식 | 수식 문자열 매칭 | 수식 정확성 |
| 표 | TEDS, TEDS-S, 표 편집 거리 | 구조 복구 |
| 구조적 유효성 | 괄호 균형, 태그 닫기, 표 무결성 | 형식의 완전성 |
| 단위 테스트 | olmOCR 스타일의 존재 여부, 순서, 수학 및 표 테스트 통과 비율 | 밀도 높은 피드백 |
| 반복 및 형식 | 반복 페널티, HTML 적합성 | 퇴화 제어 |
곱셈 기반 보상 구성. 곱셈 방식에서는 하나의 실패한 확인이 그렇지 않은 올바른 페이지로부터 그래디언트를 제거할 수 있기 때문에 대부분의 항목에는 하한값이 설정되어 있습니다. 반복 항목은 퇴화 루프가 콘텐츠 점수를 부풀리는 가장 쉬운 실패 모드이므로 하한값이 없습니다.
각 라운드는 후보 체크포인트 풀을 남깁니다. 에이전트는 고정된 평가 예산하에 병합 구성을 탐색하고 단위 테스트와 편집 거리 확인을 통해 점수를 매기며, 선택된 병합에서의 오류가 다음 수집 라운드를 구동합니다. 초안 헤드는 루프가 선택한 검증기를 대상으로 마지막에 피팅됩니다.
tag결과
| 모델 | 파라미터 | ArXiv | OldScans-Math | Tables | OldScans | Multi-col | LongTiny | Hdr/Ftr | Base | 전체 |
|---|---|---|---|---|---|---|---|---|---|---|
| Gemini 3 Flash | – | 80.1 | 73.6 | 64.6 | 45.8 | 75.3 | 90.3 | 27.4 | – | – |
| Qwen3-VL-235B | 235B/22B | 88.4 | 81.2 | 86.7 | 49.6 | 85.9 | 88.9 | 33.6 | – | – |
| DeepSeek-OCR | 3B/570M | 77.5 | 74.5 | 77.3 | 33.1 | 67.3 | 83.0 | 96.1 | 99.3 | 76.0 |
| dots.mocr | 3B | 85.9 | 85.5 | 90.7 | 48.2 | 85.3 | 81.6 | 94.0 | 99.7 | 83.9 |
| olmOCR-2 | 8B | 82.9 | 82.1 | 84.3 | 48.3 | 84.3 | 81.4 | – | 99.7 | 82.4 |
| LightOnOCR-2 | 1B | 89.6 | 85.6 | 89.0 | 42.2 | 84.8 | 91.4 | 19.7 | 99.6 | 83.2 |
| chandra-ocr-2 | 4B | 86.9 | 89.1 | 92.1 | 51.1 | 82.1 | 93.7 | 91.4 | 99.9 | 85.8 |
| jina-ocr-v1 | 3B/570M | 86.1 | 82.3 | 88.8 | 42.6 | 85.5 | 93.2 | 88.7 | 99.9 | 83.4 |
olmOCR-Bench 결과입니다. jina-ocr-v1은 전체 점수 83.4점을 기록하여, 후속 학습(post-training) 기반인 DeepSeek-OCR보다 7.4점 높고 8B 규모의 olmOCR-2보다 앞섰습니다. Hdr/Ftr 열은 텍스트 부재를 테스트하며 헤더와 푸터를 생략할 경우 높은 점수를 부여하므로, 전체 페이지를 충실하게 전사하는 방식은 해당 항목에서 낮은 점수를 받습니다.
| 방법 | 파라미터 | 전체 ↑ | TextEdit ↓ | FormulaCDM ↑ | TableTEDS ↑ | TableTEDS-S ↑ | ROEdit ↓ |
|---|---|---|---|---|---|---|---|
| Gemini 3 Flash | – | 92.62 | 0.066 | 95.16 | 89.29 | 93.51 | 0.172 |
| Qwen3-VL-235B | 235B/22B | 89.78 | 0.063 | 92.55 | 83.07 | 86.75 | 0.166 |
| DeepSeek-OCR-2 | 3B/570M | 90.25 | 0.050 | 91.84 | 83.89 | 87.75 | 0.144 |
| HunyuanOCR-1.5 | 1B | 94.74 | 0.039 | 94.50 | 93.67 | 94.71 | 0.129 |
| PaddleOCR-VL-1.6 | 0.9B | 96.34 | 0.033 | 97.53 | 94.76 | 97.10 | 0.128 |
| jina-ocr-v1 | 3B/570M | 91.14 | 0.046 | 93.28 | 84.68 | 89.01 | 0.142 |
OmniDocBench v1.6 결과입니다. jina-ocr-v1은 570M 활성 파라미터로 91.14점을 기록하여, 모든 항목에서 DeepSeek-OCR-2를 앞섰으며 훨씬 큰 규모인 Qwen3-VL-235B보다도 우수한 성능을 보였습니다.
tagL4 GPU에서의 추측적 디코딩 (Speculative decoding)
| 모드 | k | 출력 词元/s ↑ | 가속도 S ↑ | 수락률 | τ | c ↓ |
|---|---|---|---|---|---|---|
| Eager | 0 | 42.7 | 1.00x | – | – | 1.00 |
| Eager | 1 | 64.0 | 1.50x | 82.6% | 1.83 | 1.22 |
| Eager | 2 | 77.9 | 1.82x | 69.1% | 2.38 | 1.30 |
| Eager | 3 | 83.1 | 1.95x | 57.6% | 2.73 | 1.40 |
| Graph | 0 | 158.3 | 1.00x | – | – | 1.00 |
| Graph | 1 | 185.6 | 1.17x | 82.9% | 1.83 | 1.56 |
| Graph | 2 | 183.8 | 1.16x | 69.3% | 2.38 | 2.05 |
| Graph | 3 | 172.9 | 1.09x | 57.9% | 2.74 | 2.51 |
olmOCR-Bench, NVIDIA L4, vLLM 0.20.1, 배치 사이즈 1 환경에서의 FastMTP 측정값입니다. τ는 보너스 词元을 포함하여 추측 단계당 커밋된 평균 词元 수이며, c = τ/S는 자동 회귀(autoregressive) 단계 단위로 계산된 추측 단계의 비용입니다. 위 수치들과는 다른 장비에서 측정되었습니다.
k = 3일 때 Eager 모드에서 τ가 2.73, CUDA 그래프 환경에서 2.74로 나타나듯, 드래프트 품질은 실행 모드에 의존하지 않습니다. 하지만 베이스라인은 모드에 따라 달라집니다. CUDA 그래프를 사용하면 자동 회귀 디코딩 속도가 초당 42.7 词元에서 158.3 词元으로 상승하지만, 추측 단계의 오버헤드가 약 9ms로 유지되므로 해당 비용은 1.40에서 2.51 자동 회귀 단계로 증가합니다. 이 성능 향상은 대체되는 검증 단계의 비용을 따르므로, Eager 모드에서는 k = 3, 그래프 모드에서는 k = 1일 때 최적의 성능을 보입니다.
tag시작하기
가장 빠르게 실행하는 방법은 Jina Reader를 사용하는 것입니다. r.jina.ai 주소 뒤에 URL을 붙이고 헤더 하나를 추가하면, Reader가 페이지나 PDF를 가져와 렌더링하고 그 결과에 jina-ocr-v1을 실행한 뒤 마크다운 형식으로 반환합니다. 배포할 필요도 없고 이미지 파이프라인을 직접 구현할 필요도 없으며, 플랫폼의 다른 서비스와 동일한 API 키를 사용합니다.
curl "https://r.jina.ai/https://example.com/document.pdf" \
-H "Authorization: Bearer $JINA_API_KEY" \
-H "X-Respond-With: jina-ocr-v1"여러 페이지 문서 중 한 페이지만 전사하려면 X-Page를 추가하세요. 두 매개변수 모두 Reader API 편집기에서 제공되며, 토글을 켜면 자동으로 헤더가 작성됩니다.
모델에 직접 액세스하려면 OpenAI와 호환되는 호스팅 엔드포인트를 사용하세요. jina.ai에서 발급받은 API 키만 있으면 됩니다.
curl https://api.jina.ai/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer ***" \
-d '{
"model": "jina-ocr-v1",
"messages": [{
"role": "user",
"content": [
{"type": "text", "text": "Transcribe the provided document image into a clean Markdown format, preserving the natural reading order."},
{"type": "image_url", "image_url": {"url": "https://example.com/document.png"}}
]
}]
}'
직접 모델을 서빙하려면 trust_remote_code=True를 설정하여 Hugging Face 저장소에서 가중치와 커스텀 모델링 코드를 불러오면 됩니다. FastMTP를 사용하려면 vLLM 0.21 이상이 필요하며, 엔진 시작 전 1회 아키텍처 등록 과정이 필요합니다.
import sys
from huggingface_hub import snapshot_download
from PIL import Image
from vllm import LLM
sys.path.insert(0, snapshot_download('jinaai/jina-ocr-v1'))
from deepseek_ocr_mtp import DEFAULT_OCR_PROMPT, register, vllm_llm_kwargs, vllm_sampling_params
register()
llm = LLM(**vllm_llm_kwargs('jinaai/jina-ocr-v1',
num_speculative_tokens=3,
mtp_heads=1,
mtp_recursive=True))
image = Image.open('document.png').convert('RGB')
outputs = llm.chat(
[{'role': 'user', 'content': [{'type': 'image_pil', 'image_pil': image},
{'type': 'text', 'text': DEFAULT_OCR_PROMPT}]}],
sampling_params=vllm_sampling_params(max_tokens=4096),
)
print(outputs[0].outputs[0].text)
속도 향상 여부를 결정짓는 세부 사항이 하나 있습니다. FastMTP는 재귀적 은닉 상태 피드백을 사용하여 학습되었고 기본 method="mtp"는 모든 드래프트 단계를 대상 모델에 재검증하기 때문에, 헬퍼를 등록할 때 반드시 method="eagle"로 설정해야 합니다. Transformers 경로는 MoE 디코더만 실행하며 MTP 가중치는 무시합니다.
이 모델은 영어와 중국어에 대해 표 및 수식의 요소 단위 전사, 캡션 생성, 문서 VQA 및 주요 정보 추출을 지원합니다. 가중치는 CC BY-NC 4.0 라이선스로 배포됩니다.
tag결론
jina-ocr-v1은 570M 활성 파라미터로 두 벤치마크 모두에서 정확도 대비 효율성의 한계를 보여주며, 측정된 시스템 중 가장 높은 페이지 처리량을 기록했습니다. 모델의 크기를 키우지 않고도 두 가지 핵심 요소, 즉 모든 검증 가능한 단계에 대한 등급별 보상(graded reward)과 최종 검증자에 맞춰 학습된 드래프트 헤드를 통해 이러한 성능을 달성했습니다.
출력 길이는 주의 깊게 살펴볼 가치가 있습니다. 词元 처리량과 페이지 처리량은 시스템 순위를 다르게 평가하며, 출력 길이는 파싱 품질과는 무관하므로 간결성 자체를 최적화할 수 있습니다. jina-ocr-v1은 83점 이상의 점수를 기록한 모든 시스템 중 가장 짧은 출력을 생성합니다.
