Question 1

olmOCR 0.4.4 が OCR 完了後に無期限にハングし、終了しないのはなぜですか？

Accepted Answer

これは、セマフォのクリーンアップが欠落していることが原因で発生する olmOCR 0.4.4 のリグレッションです。外部の 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 の絶対パスをそのまま使用していたため、それをワークスペースと結合すると 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
```

これで、出力はワークスペース内に保持されるようになり、ファイル名の衝突を避けるために絶対パスが保持されます：

```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を使用しており、vLLMはインストールされているGPUスタックがサポートしていればネイティブFP8を実行できます。WSL2/Linux上でCUDA 12.8、Blackwell sm_120互換のPyTorchビルドを使用し、その後、Blackwell FP8をサポートするvLLMビルドをインストールまたはアップグレードしてください。`python -c "import torch; print(torch.cuda.get_device_capability())"`（Blackwellは12.xのケイパビリティを報告するはずです）と`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