8GB VRAMで最新OCRモデルを動かしたい——DeepSeek-OCRとの格闘記
3行まとめ
- 挑戦: リソース制約下でのAI活用を体験するため、8GB VRAMでDeepSeek-OCRを動かしてみました
- 結果: 9つの問題を乗り越え動作したものの、61ページ中26ページで限界に
- 学び: 「制約下での精度低下」を身をもって体験。そして自分のPCにはもう1つGPUがあった
きっかけ
とある大学の講義で、医療業界におけるAI活用の話を聞きました。
印象的だったのは、ガイドライン制約による精度の問題。医療分野ではAIの出力に厳格な制約が課されることがあり、それが精度低下につながる場合があるという話でした。
一方で、激しい競争の中で性能が飛躍的に向上したモデルを私たちは既に体験してしまっています。Claude、GPT-4、そしてDeepSeek——これらの高精度な出力に慣れた目で見ると、制約下での低精度出力は「なぜこんなに使いにくいのか」と感じてしまう。この認識のギャップが、社会実装における摩擦を生む可能性がある。
講義の中で質問者が挙げていた現場の課題感を、自分でも体験してみたくなりました。
「DeepSeek-OCR、試してみよう」
ちょうど手元にあるPCのGPUはNVIDIA RTX PRO 2000 Blackwell——最新世代とはいえ、VRAMはたったの8GB。DeepSeek-OCRの公式ドキュメントには「16GB以上推奨」とあります。
リソース制約の中でAIを動かす。まさに現場が直面している課題そのものです。
「まあ、なんとかなるだろう」
この楽観が、9つの問題との格闘の始まりでした。
構想
やりたかったことは単純です。
┌─────────────────────────────────────────────────────┐
│ 理想の世界 │
└─────────────────────────────────────────────────────┘
↓
┌──────────┐ ┌──────────┐ ┌──────────┐
│ PDF │ → │ DeepSeek │ → │ テキスト │
│ 61ページ │ │ OCR │ │ 出力 │
└──────────┘ └──────────┘ └──────────┘
↓
「簡単でしょ？」
8GBしかないVRAMでも、4bit量子化を使えば動くはず。WSL2上のUbuntuで環境を構築すれば、きっとうまくいく——そう思っていました。
実装
環境構築
選んだ環境は以下の通りです。
| 項目 | 選択 | 理由 |
|---|---|---|
| OS | WSL2 Ubuntu | ML系ライブラリとの相性が良い |
| GPU | NVIDIA RTX PRO 2000 | 手持ちの唯一のGPU（と思っていた） |
| 量子化 | 4bit (bitsandbytes) | 8GB VRAMに収めるため |
4bit量子化の設定
quantization_config = BitsAndBytesConfig(
load_in_4bit=True,
bnb_4bit_use_double_quant=True,
bnb_4bit_quant_type="nf4",
bnb_4bit_compute_dtype=torch.bfloat16
)
これで8GBに収まるはず。さあ、実行——
結果：9つの壁にぶつかりました
┌─────────────────────────────────────────────────────┐
│ 現実の世界 │
└─────────────────────────────────────────────────────┘
↓
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│ 壁1 │→│ 壁2 │→│ 壁3 │→│ ... │→│ 壁9 │
│ │ │ │ │ │ │ │ │ │
│ GPU │ │ API │ │dtype │ │ │ │メモリ│
│非対応│ │変更 │ │不一致│ │ │ │不足 │
└──────┘ └──────┘ └──────┘ └──────┘ └──────┘
↓
「えっ...」
🧱 壁1: Blackwell GPUが動かない
RuntimeError: CUDA error: no kernel image is available for execution on the device
最新GPUを買ったのに、最新すぎてPyTorch安定版でサポートされていないという皮肉な状況。nightly版への切り替えで解決しました。
🧱 壁2: クラスが消えている
ImportError: cannot import name 'LlamaFlashAttention2'
transformers 4.47以降で削除されたクラスを、DeepSeek-OCRがまだ使っていました。4.45.2へのダウングレードで解決。
🧱 壁3: 型が合わない
RuntimeError: expected self and source to have same dtypes but got Half and Float
Vision encoderがfloat32、Language modelがfloat16を期待。HuggingFaceキャッシュのモデルコードを直接パッチするという力技で解決しました。
🧱 壁4〜9: その他いろいろ
| 壁 | 問題 | 解決策 |
|---|---|---|
| 4 | matplotlib不足 | pip install |
| 5 | resolution引数エラー | パラメータ削除 |
| 6 | output_path必須 | tempfile使用 |
| 7 | PDF非対応 | pdf2image変換 |
| 8 | 2ページ目でクラッシュ | モデル使い回し |
| 9 | ログ記録失敗 | mkdir -p追加 |
ようやく動いた！...けど
9つの壁を乗り越え、61ページのPDFを処理し始めました。
1ページ目 ... ✅ 成功
5ページ目 ... ✅ 成功
10ページ目 ... ✅ 成功
19ページ目 ... ✅ 成功
順調！コーヒーを淹れながら、処理の進行を眺めます。
20ページ目 ... ⚠️ あれ？
出力: Col1 Col2 Col3 ... Col2206
「2206列...？」
大きなテーブルでトークン上限（8192）を超過。まあ、これは仕方ない。次へ進みます。
21ページ目 ... ✅ 成功
26ページ目 ... ✅ 成功
27ページ目 ... ❌ ？？？
出力:
https://www.example1.com
https://www.example2.com
https://www.example3.com
...（延々と続く）
ハルシネーション。存在しないURLを無限に生成し始めました。手動で止めるしかありませんでした。
┌─────────────────────────────────────────────────────┐
│ 最終結果 │
├─────────────────────────────────────────────────────┤
│ 処理成功: 26ページ / 61ページ │
│ 達成率: 約43% │
│ 中断理由: モデルのハルシネーション │
└─────────────────────────────────────────────────────┘
なぜうまくいかなかったのか
原因を整理してみました。
┌─────────────────────────────────────────────────────┐
│ 8GB VRAMの限界 │
└─────────────────────────────────────────────────────┘
│
┌──────────────┼──────────────┐
↓ ↓ ↓
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 量子化の │ │ メモリ │ │ モデルの │
│ 精度低下 │ │ プレッシャ│ │ 不安定化 │
└──────────┘ └──────────┘ └──────────┘
│ │ │
└──────────────┼──────────────┘
↓
┌──────────────────┐
│ ハルシネーション │
│ 発生リスク上昇 │
└──────────────────┘
16GB以上推奨のモデルを8GBで動かしているのだから、当然といえば当然です。4bit量子化は「動く」ことを保証しても、「安定して動く」ことは保証しない。
見つけた解決策
処理を中断し、Task Managerを開いた時でした。
GPUが2つある。
┌─────────────────────────────────────────────────────┐
│ 私のPC（知らなかった） │
└─────────────────────────────────────────────────────┘
│
┌──────────────┴──────────────┐
↓ ↓
┌──────────────┐ ┌──────────────┐
│ GPU 0 │ │ GPU 1 │
│ NVIDIA │ │ Intel Arc │
│ 8GB VRAM │ │ 共有メモリ │ ← ？
│ （使用中） │ │ （未使用） │
└──────────────┘ └──────────────┘
Intel Arc Pro 140T。Task Managerには「48GB」と表示されていましたが、これは共有システムメモリ——専用VRAMではありません。
それでも、Intel Arc GPUはPyTorch XPUやIPEX-LLMでサポートされています。もしかしたら、NVIDIAとは違うアプローチで動かせるかもしれません。
学んだこと
1. 🎓 最新は必ずしも最良ではない
| コンポーネント | 最新版 | 動作した版 |
|---|---|---|
| PyTorch | 安定版 2.5 | ❌ → nightly |
| transformers | 4.47+ | ❌ → 4.45.2 |
「とりあえず最新」は、機械学習の世界では通用しないことがありました。
2. 🎓 8GB VRAMは「動く」が「安定」ではない
- 単純なページ → ✅ 問題なし
- 複雑なテーブル → ⚠️ トークン超過
- 特定のページ → ❌ ハルシネーション
3. 🎓 エラーメッセージは宝の山
9つの問題すべて、エラーメッセージを丁寧に読むことで解決できました。GitHubのIssueも大いに参考になりました。
4. 🎓 自分のPCを知る（そして正しく理解する）
Intel Arc GPUが搭載されていることに気づかなかったのは、正直恥ずかしいです。さらに恥ずかしいのは、Task Managerの「48GB」を専用VRAMだと勘違いしたこと。実際は共有システムメモリでした。
でも、この発見と修正がなければ、次のステップは見えませんでした。
今後どうするか
┌─────────────────────────────────────────────────────┐
│ 次の挑戦 │
└─────────────────────────────────────────────────────┘
│
┌────────────────────┴────────────────────┐
↓ ↓
┌──────────────────┐ ┌──────────────────┐
│ Intel Arc GPU │ │ 同じPDFを再テスト │
│ セットアップ検証 │ │ 61ページ全部 │
└──────────────────┘ └──────────────────┘
│ │
│ PyTorch XPU or IPEX-LLM │
│ のインストール │
└────────────────────┬────────────────────┘
↓
┌──────────────────┐
│ 共有メモリで │
│ どこまでいける？ │
└──────────────────┘
共有メモリがどこまで使えるのか、まだわかりません。でも試してみる価値はある。
……たぶん。
関連リンク
実行環境
GPU 0: NVIDIA RTX PRO 2000 Blackwell Generation Laptop GPU
VRAM: 8151 MiB (専用)
GPU 1: Intel(R) Arc(TM) Pro 140T GPU (48GB)
VRAM: 共有システムメモリ
OS: Windows 11 + WSL2 Ubuntu
PyTorch: Nightly (cu128) - Blackwell対応
transformers: 4.45.2
量子化: 4bit (BitsAndBytes nf4)
失敗は成功のもと。次はIntel Arcで試してみます。
Discussion