ハクソク

世界を動かす技術を、日本語で。

DeepSeek OCRの翻訳は「DeepSeek OCR」となります。特定の製品名や技術用語はそのまま使用します。

217日前原文(github.com)

概要

DeepSeek-OCRは、視覚エンコーダの役割をLLM中心の視点から探究するためのモデル。 多様な画像・PDF文書をOCRし、Markdown変換などに対応。 CUDA11.8＋PyTorch2.6.0環境で動作し、vLLM・Transformers両推論方式をサポート。 複数の解像度・モードに対応し、実用的なプロンプト例も用意。 導入・推論手順や依存パッケージの詳細な説明を提供。

DeepSeek-OCR概要と特徴

  • DeepSeek-OCR は、視覚エンコーダのLLM統合観点からの研究用OCRモデル
  • 画像・PDF文書 のテキスト認識（OCR）機能
  • Markdown変換 など多様な出力に対応
  • CUDA11.8＋PyTorch2.6.0 環境での動作確認済み
  • vLLM ・ Transformers 両推論方式サポート

インストール手順

  • リポジトリのクローン

    • git clone https://github.com/deepseek-ai/DeepSeek-OCR.git
    • DeepSeek-OCRディレクトリへ移動

  • conda環境の作成

    • conda create -n deepseek-ocr python=3.12.9 -y
    • conda activate deepseek-ocr

  • パッケージのインストール

    • pip install torch==2.6.0 torchvision==0.21.0 torchaudio==2.6.0 --index-url https://download.pytorch.org/whl/cu118
    • pip install vllm-0.8.5+cu118-cp38-abi3-manylinux1_x86_64.whl
    • pip install -r requirements.txt
    • pip install flash-attn==2.7.3 --no-build-isolation

  • vLLMとTransformersの混在について

    • vLLM 0.8.5+cu118はtransformers>=4.51.1を要求
    • 両方を同一環境で動作させる場合、インストールエラーは無視可能

vLLMによる推論

  • 設定ファイルの編集

    • DeepSeek-OCR-master/DeepSeek-OCR-vllm/config.pyでINPUT_PATH/OUTPUT_PATH等を設定

  • 画像OCRの実行

    • cd DeepSeek-OCR-master/DeepSeek-OCR-vllm
    • python run_dpsk_ocr_image.py

  • PDF OCR（並列処理）

    • python run_dpsk_ocr_pdf.py
    • A100-40Gで約2500tokens/s

  • ベンチマーク用バッチ評価

    • python run_dpsk_ocr_eval_batch.py

Transformersによる推論

  • Pythonコード例

    • from transformers import AutoModel, AutoTokenizer
    • import torch, os
    • os.environ["CUDA_VISIBLE_DEVICES"] = '0'
    • model_name = 'deepseek-ai/DeepSeek-OCR'
    • tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True)
    • model = AutoModel.from_pretrained(model_name, _attn_implementation='flash_attention_2', trust_remote_code=True, use_safetensors=True)
    • model = model.eval().cuda().to(torch.bfloat16)
    • prompt = "<image>\n<|grounding|>Convert the document to markdown."
    • image_file = 'your_image.jpg'
    • output_path = 'your/output/dir'
    • res = model.infer(tokenizer, prompt=prompt, image_file=image_file, output_path=output_path, base_size=1024, image_size=640, crop_mode=True, save_results=True, test_compress=True)

  • コマンドライン実行例

    • cd DeepSeek-OCR-master/DeepSeek-OCR-hf
    • python run_dpsk_ocr.py

サポート解像度・モード

  • ネイティブ解像度モード

    • Tiny: 512×512（64 vision tokens）
    • Small: 640×640（100 vision tokens）
    • Base: 1024×1024（256 vision tokens）
    • Large: 1280×1280（400 vision tokens）

  • ダイナミック解像度モード

    • Gundam: n×640×640 + 1×1024×1024

プロンプト例

  • 文書のMarkdown変換

    • <image>\n<|grounding|>Convert the document to markdown.

  • 画像のOCR

    • <image>\n<|grounding|>OCR this image.

  • レイアウトなしOCR

    • <image>\nFree OCR.

  • 図表解析

    • <image>\nParse the figure.

  • 画像詳細説明

    • <image>\nDescribe this image in detail.

  • 特定領域検出

    • <image>\nLocate <|ref|>xxxx<|/ref|> in the image.

可視化・謝辞

  • 可視化機能 の提供
  • Vary, GOT-OCR2.0, MinerU, PaddleOCR, OneChart, Slow Perception のモデル・アイデア参照
  • Fox, OminiDocBench のベンチマーク利用
  • 論文引用情報は近日公開予定

この内容に従い、DeepSeek-OCRの導入・利用・特徴を簡潔に把握可能。

Hackerたちの意見

プロトタイピングや遊びにはすごく良さそうだね。でも、もし最新のアプリケーションを作るなら、画像セグメンテーションやテキスト認識に関しては、自然言語よりももっと良いAPIがあるんじゃないかな？LLMの欠点を抱えながら、プロダクション規模のCVアプリを作るのはかなりの労力だと思う。あまり詳しくない分野だけど、これが最先端の結果を出すとは思えないな。それだと分析が変わってくるよね。

└

例えば特定の産業用途の画像セグメンテーションモデルを作ると想像してみて。LLMのアプローチを使えば、少なくとも生の画像から自然言語でトレーニングデータを作れるよ。

この論文は、ただのOCR用のVLM以上に面白いよ。圧縮についても話し始めてるし。例えば、こんな引用があるよ。>「私たちの研究は、視覚-テキスト圧縮の境界を探る初期の探求を示しており、テキストトークンをデコードするために必要な視覚トークンの数を調査しています。初期結果は励みになります：DeepSeek-OCRは約10倍の比率でほぼロスレスのOCR圧縮を達成し、20倍の圧縮でも60%の精度を保っています。（写真トークンは10個のテキストトークンに相当すると言えるかも…）初心者にこの情報理論的な直感を説明してくれる人いる？なぜこれが機能するのか、テキストトークンがまだ「粒度が細かすぎる」/繰り返しすぎて理想的なエントロピーコーディングに近づけないからなのか？それとも視覚トークンに切り替えることで「一単語ずつ」作業する制限から逃れられて、エントロピーに近づけるのかな（算術エンコーディングがハフマンコードと比べてそうするように）？それから、長いコンテキストを扱うために、文字通り(?)画像をダウンサンプリングして、テキスト領域と画像領域の情報損失の対応を形成することについて話し始めるんだ。

└

LLMはトークンごとに計算量が二次的に増えるから、かなり重いんだよね。彼らはVLMでテキストトークンを視覚トークンに圧縮しようとしてるみたい。計算コストを下げるために、トークン化する前にテキストを画像に変換するかもしれないね。

└

各テキストトークンはしばしばサブワードユニットだけど、VLMでは視覚トークンが意味空間にあるんだ。意味空間は明らかにサブワードスライスよりもずっと圧縮できるよ。注意：専門家じゃないから、ざっくりした話ね。

彼らがバリアント名に「ガンダム」を使ってるのが面白いね。ガンダム-Mとガンダムが一番強力なやつなんだろうな。

LLMのOCRアプローチは、Azure AI Document Intelligence（https://learn.microsoft.com/en-us/azure/ai-services/document...）やGoogleのVision API（https://cloud.google.com/vision?hl=en）と比べてどうなんだろう？

└

なんでダウンボートされてるのかよくわからないけど、私も気になるな。

└

OmniAIは、企業のLLMとクラウドOCRサービスを比較するベンチマークを持ってるよ。https://getomni.ai/blog/ocr-benchmark（2025年2月）ただ、2月以降にLLMが急速に進化してるから、その点は注意してね。私たちのユースケースでは、Qwen3-VLファミリー、特にQwen3-VL-235B-A22B-Instructの結果がかなり良くなってる。

DeepSeekだからオープンソースライセンスが期待できるけど、（私みたいに）それを明示的に見たい人のために、GitHubリポジトリでは明らかじゃないからね： https://huggingface.co/deepseek-ai/DeepSeek-OCR/blob/main/LI... TLDR: MITライセンスだよ。

└

GitHubリポジトリでは明らかじゃないからね 右のサイドバーとreadmeタブ、LICENSEというファイルに「MITライセンス」って書いてあるよ。

└

モデルの重みもMITだよ: https://huggingface.co/deepseek-ai/DeepSeek-OCR/blob/main/LI...

この論文にはAnnaのアーカイブについては何も触れられてないね。DeepSeekがAnnaの提供を利用して、OCR研究者に750万（350TB）の中国のノンフィクションコレクションへのアクセスを許可してるなら、驚かないけど…これはLibrary Genesisよりも大きいよ。https://annas-archive.org/blog/duxiu-exclusive.html

└

ハハハ、これもすぐに思い浮かんだ！OCRデータセットのリリースはいつになるんだろうね。

なんかPaddleOCRを思い出すな。DeepSeek OCRがモバイルアプリに統合されたら最高だね。そうなったらOCRがもっと便利になる！

└

iOSにはすでにAppleのVision APIで、テキスト検出とドキュメントスキャナーが両方搭載されてる。LLMベースのソリューションと比べてどれくらい良いのかはちょっと分からないな。同じように、GoogleもMLKitでOCRをデバイス上で動かしてるけど、もう何年も前からだしね。

私の印象では、OCRは基本的に解決済みって感じだね。ここで言及されてるOmniAIのベンチマークも、2025年2月以降は新しいモデルで更新されてないし。一般的なLLMが自社のOCR製品よりもOCRが得意になってるんじゃないかな。私は各ページを画像としてGemini 2.5 Flash Liteに送って、Markdownで内容を抽出してもらうだけで、幅広いOCRタスクを解決できてるよ。バッチモードで1000ページあたり約$0.20かかるけど、結果は素晴らしい。今でもOCRが苦戦してるところがあれば、ぜひ聞きたいな。

└

私の印象では、OCRは基本的に解決済みって感じだね。実際にはそう思わないな。特に、テーブル形式の検出にはまだ苦労してるみたい。

└

技術的にはOCRじゃないけど、HTR（手書き文字/トランスクリプト認識）はまだ難しいね。LLMは精度が上がったけど、彼らのミスは非常に特定しにくいんだ。なぜなら、デジタイズできないテキストを「幻覚」みたいに生成しちゃうから。

└

機械が認識できないものを「わからない」と言わずに作り上げることを受け入れられるなら、はい、それは解決です。（皮肉じゃないよ。場合によっては許容されることもある。）

└

それが解決したとは思えない。クリエイティブなレイアウトの雑誌でOCRを試してみて。無理だよ。僕はヴィンテージのコンピュータ雑誌を集めていて、時々最新のメカニズムでOCRを試みるけど、どれも人間の手がかなり必要だよ。

└

インスピレーショナルなテキストが書かれたマグカップには「豊かな可能性」って書いてあるの？

└

多くのOCR/LLM（Gemini Pro 2.5でも）は、複雑なテーブルをMarkdownやHTMLに変換するのがまだまだ苦手だよ。複数のヘッダーやマージされたセルがあるテーブル、チェックボックスが混ざった複数の列、正しく理解されない複数ページのテーブルとかね。Llamaindexもその辺りでは全然ダメだよ。これらの特定の問題に強いOCR/LLMがあれば教えてほしいな。複雑なテーブルの例: https://cdn.aviation.bot/complex-tables.zip このテーブルを正しく解析するには、まずテーブルのヘッダーを手動でHTMLに解析する必要があるよ。でも、それでもチェックボックスが混ざっちゃう。完全なテーブルの例: https://www.easa.europa.eu/en/icao-compliance-checklist

└

印刷されたテキストのOCRは一つの問題かもしれないけど、手書きのOCR（いわゆるHTR）はまだまだ解決から遠いよ。実際、一般的な歴史的HTRが有用に使える実用的なタスクを見つけるのは難しいんだ。最新のモデルでもね。

└

VLLMは複雑なレイアウトが苦手で、幻覚のリスクが高いよ。契約書や健康データには絶対に単独で使わない方がいい。

特定のOCRモデルをダウンロードする代わりに、現在のベストなマルチモーダル基盤モデルをダウンロードしたらどうなるの？30GB未満でそれは何になるの？

リポジトリには言語サポートについては書かれてないけど、論文によるとほぼ100言語に対応してるみたいで、いい感じだね。ただ、GeminiやMistral OCRと比べてどうなのか試してみないと。