Question 1

왜 olmOCR 0.4.4가 OCR 완료 후 무기한 멈추고 종료되지 않나요?

Accepted Answer

이는 세마포어 정리가 누락되어 발생한 olmOCR 0.4.4의 회귀(regression)이며, 일반적으로 외부 vLLM/서버 기반 프로바이더를 사용할 때 발생합니다. 수정된 릴리스로 업그레이드하십시오:

```bash
pip install --upgrade olmocr==0.4.5
```

처리 후 CLI가 정상적으로 반환되고 모든 워커가 종료되는지 확인하십시오. 즉시 업그레이드할 수 없는 경우, 마지막으로 정상 작동했던 릴리스로 다운그레이드하십시오:

```bash
pip install olmocr==0.4.3
```

부모 프로세스가 SIGTERM/SIGKILL로 수동 종료될 때까지 계속 살아 있을 수 있으므로, 스크립트 또는 자동화된 워크플로우에서는 olmOCR 0.4.4를 사용하지 마십시오.

Question 2

--pdfs가 절대 경로일 때 olmOCR의 --markdown 출력을 워크스페이스 내부에 유지하려면 어떻게 해야 하나요?

Accepted Answer

이전 olmOCR 버전에서는 Markdown 출력 경로를 생성할 때 PDF의 절대 경로를 그대로 사용했기 때문에, 이를 workspace와 결합하면 PDF의 원래 디렉터리로 해석되었습니다. 이 문제는 PR #400에서 수정되었습니다. 수정 사항이 포함된 릴리스 또는 최신 main 브랜치로 업그레이드하세요:

```bash
pip install -U git+https://github.com/allenai/olmocr.git
```

그런 다음 다시 실행하세요:

```bash
python -m olmocr.pipeline ./localworkspace --markdown \
  --pdfs /my/path/to/my/personal/pdf.pdf \
  --model allenai/olmOCR-2-7B-1025-FP8
```

이제 출력은 파일 이름 충돌을 방지하기 위해 절대 경로가 유지된 상태로 workspace 아래에 저장됩니다:

```text
./localworkspace/markdown/absolute/my/path/to/my/personal/pdf.md
```

이전 버전에서의 해결 방법: PDF의 디렉터리에서 명령을 실행하고 파일 이름만 전달하세요:

```bash
cd /my/path/to/my/personal
python -m olmocr.pipeline /path/to/localworkspace --markdown \
  --pdfs pdf.pdf \
  --model allenai/olmOCR-2-7B-1025-FP8
```

이렇게 하면 `localworkspace/markdown/pdf.md`가 생성됩니다.

Question 3

12 GB Blackwell GPU에서 olmOCR FP8이 약 0.5 tokens/s로 실행되고 공유 메모리로 스필되는 문제를 어떻게 해결하나요?

Accepted Answer

속도 저하는 Transformers 추론 경로가 FP8 가중치를 FP16으로 업캐스트하기 때문에 발생하며, 이로 인해 메모리 사용량이 약 7 GB에서 대략 20 GB로 증가합니다. 대신 vLLM 백엔드를 사용하세요. olmOCR은 기본적으로 vLLM을 사용하며, 설치된 GPU 스택이 지원하는 경우 vLLM은 네이티브 FP8을 실행할 수 있습니다. CUDA 12.8, Blackwell sm_120 호환 PyTorch 빌드와 함께 WSL2/Linux를 사용한 다음, Blackwell FP8을 지원하는 vLLM 빌드를 설치하거나 업그레이드하세요. `python -c "import torch; print(torch.cuda.get_device_capability())"`(Blackwell은 12.x capability를 보고해야 함)와 `python -c "import vllm; print(vllm.__version__)"`로 설정을 확인하세요. 모델이 실제로 vLLM을 통해 로드되는지 확인하세요. Transformers로 로드하면 여전히 FP16으로 업캐스트됩니다. `olmocr/check.py`의 별도 하드코딩된 15 GB 검사는 네이티브 FP8 vLLM 추론이 확인된 후에만 일시적으로 낮추거나 제거할 수 있습니다. 네이티브 FP8 지원 없이 해당 검사를 변경해도 FP16 업캐스트나 공유 메모리 스필을 방지할 수 없습니다.

olmocr

개요

README 미리보기

FAQ (3)

同类型项目

hermes-agent

firecrawl

go

markitdown