---
title: "DeepSeek-OCRとは？光学圧縮の仕組みとOCR 2との違い・使い方・API"
url: "https://www.issoh.co.jp/tech/details/9455/"
published: 2025-10-23
updated: 2026-10-07
categories: ["AI"]
publisher: "株式会社一創"
---

# DeepSeek-OCRとは？光学圧縮の仕組みとOCR 2との違い・使い方・API

DeepSeek-OCRは、DeepSeekが2025年10月20日に公開したOCRモデルです。文書の画像を少数の「ビジョントークン」に圧縮し、そこから文字を復元します。論文の主張は「テキストを画像として持てば、LLMに渡すトークンを7〜20分の1にできる」というもので、OCRの精度競争とは別の問いから出発しています。2026年1月27日には後継のDeepSeek-OCR 2が公開され、エンコーダーが作り直されました。この記事では、2026年10月7日時点の一次情報（論文・公式リポジトリ・Hugging Face・各ランタイムのソース）をもとに、仕組み、OCR 2との違い、動かし方、APIで使う方法、日本語文書での注意点を整理します。

## まとめ：DeepSeek-OCRとOCR 2の要点

- **何をするモデルか**：文書画像をビジョントークンに圧縮し、Markdownやテキストに変換するビジョン言語モデルです。総パラメータは約33億（3B級）、重みはHugging Faceで公開されています。
- **「97%」の意味**：英語文書（Foxベンチマーク）で、テキストのトークン数がビジョントークンの10倍以内なら復元精度が約97%、20倍では約60%という実験値です。日本語の文書や一般的な帳票での精度ではありません。
- **いま使うならOCR 2**：OCR 2はエンコーダーのCLIPを小型LLM（Qwen2-0.5B）に置き換え、読み順を画像の意味から組み立てます。OmniDocBench v1.5の総合スコアは初版の87.36から91.09へ上がりました。ライセンスは初版がMIT、OCR 2がApache-2.0です。
- **公式APIは無い**：DeepSeekの公式APIのモデル一覧にOCRモデルはありません。APIとして使うなら、vLLMで自前のOpenAI互換サーバーを立てるか、OCR 2を載せているホスティング事業者（例：Novita）を使います。
- **ローカル実行**：公式手順はNVIDIA GPU（CUDA 11.8・torch 2.6.0）前提です。初版はOllama（v0.13.0以降）とllama.cppで動き、OCR 2はllama.cppが2026年5月に対応しました。LM Studioでは読み込めないという未解決の報告が残っています。
- **日本語は自社の文書で測ってから**：学習データ約3,000万ページのうち中国語と英語が約2,500万ページで、公開されているベンチマークも中英のみです。日本語の帳票や縦書きでは、日本語特化のOCRと並べて比較してください。

## DeepSeek-OCRの位置づけ：LLMの長文処理をOCRで検証したモデル

DeepSeek-OCRの論文タイトルは「Contexts Optical Compression（コンテキストの光学的圧縮）」です。LLMは文章が長くなるほど計算量が増えます。そこで、1,000語の文章を1枚の画像にして、100個前後のビジョントークンで持てないか、という問いを立てました。OCRは「画像から元の文章をどこまで復元できるか」を数値で測れるため、この圧縮の検証台として選ばれています。

そのため、DeepSeek-OCRは帳票読み取り製品のように作られてはいません。論文が挙げる実用面の成果は、A100-40G 1枚で1日20万ページ以上、20ノード（A100-40Gを各8枚）で1日3,300万ページという、LLMの学習データを作るための処理量です。精度を最優先する業務OCRとして選ぶなら、後述のベンチマークでの位置づけを見てから判断するのが安全です。

| 項目     | DeepSeek-OCR                     |
| ------ | -------------------------------- |
| 公開日    | 2025年10月20日（論文 arXiv 2510.18234） |
| 総パラメータ | 3,336,106,240（BF16）              |
| エンコーダー | DeepEncoder（約3.8億）               |
| デコーダー  | DeepSeek3B-MoE-A570M             |
| ライセンス  | MIT                              |
| 出力     | Markdown・プレーンテキスト・座標付きレイアウト      |

デコーダーは30億パラメータのMixture-of-Experts（MoE）で、1トークンごとに動くのは5.7億パラメータだけです。総パラメータと実際の計算量が一致しない仕組みは、[MoE（Mixture of Experts）の疎活性化とルーターの仕組み](/tech/details/15810/)で詳しく扱っています。

## 光学的圧縮（Contexts Optical Compression）の仕組みと圧縮率の実測値

### DeepEncoderがビジョントークンを16分の1に減らす流れ

DeepEncoderは、局所的な特徴を拾うSAM-base（約8,000万パラメータ）と、全体の意味をとらえるCLIP-large（約3億パラメータ）を直列につないだエンコーダーです。間に2層の畳み込みを挟み、SAMが出したパッチを16分の1に減らしてからCLIPに渡します。1024×1024の画像なら、16×16ピクセルのパッチ4,096個が256トークンになります。高解像度の画像を受け取っても、計算の重いCLIP側には少数のトークンしか届かないため、メモリ消費が抑えられます。

### Fox実験の圧縮率と精度：10倍で約97%、20倍で約60%

圧縮の限界は、Foxベンチマークの英語文書のうち、正解テキストが600〜1,300トークンのページで測られています。画像を512×512（64トークン）と640×640（100トークン）に縮め、文字をどこまで復元できるかを見た結果が次の表です。

| 正解テキストのトークン数 | 64トークン時の精度 | 圧縮率   | 100トークン時の精度 | 圧縮率   | ページ数 |
| ------------ | ---------- | ----- | ----------- | ----- | ---- |
| 600〜700      | 96.5%      | 10.5倍 | 98.5%       | 6.7倍  | 7    |
| 800〜900      | 83.8%      | 13.2倍 | 96.8%       | 8.5倍  | 28   |
| 1,000〜1,100  | 79.3%      | 16.5倍 | 91.5%       | 10.6倍 | 11   |
| 1,200〜1,300  | 59.1%      | 19.7倍 | 87.1%       | 12.6倍 | 4    |

出典は[DeepSeek-OCRの論文](https://arxiv.org/abs/2510.18234)のTable 2（7行のうち4行を抜粋）です。「10倍未満で約97%」「20倍で約60%」という要旨の数字はこの表から来ています。読むときは2点に注意してください。1つは、対象が英語の文書だけで、行ごとのページ数が4〜28と少ないことです。もう1つは、圧縮率が10倍を超えると精度が急に落ちることです。論文は、長い文書ほどレイアウトが複雑になること、512×512では文字がつぶれることを理由に挙げています。実務で文書を読ませるときは、後述のBaseやGundamのようにトークンを多く使うモードで動かすのが前提です。

### 初版DeepSeek-OCRの解像度モードとビジョントークン数

初版は、1ページに使うビジョントークンの数を解像度モードで選べます。

| モード    | 解像度                  | ビジョントークン  |
| ------ | -------------------- | --------- |
| Tiny   | 512×512              | 64        |
| Small  | 640×640              | 100       |
| Base   | 1024×1024            | 256       |
| Large  | 1280×1280            | 400       |
| Gundam | 640×640をn枚＋1024×1024 | n×100＋256 |

Gundamは、ページを640×640の小片に切った局所ビューと、全体を縮めた1024×1024のビューを組み合わせる動的解像度モードです。OmniDocBench（v1.0）では、Smallの100トークンでGOT-OCR2.0（256トークン）を上回り、Gundam（平均795トークン）で1ページ平均6,790トークンを使うMinerU2.0を上回ったと報告されています。Transformersで動かすときは `base_size`・`image_size`・`crop_mode` の組み合わせでモードを選びます（Gundamは `base_size=1024, image_size=640, crop_mode=True`）。

## DeepSeek-OCR 2の変更点：DeepEncoder V2と読み順の改善

DeepSeek-OCR 2は2026年1月27日に公開されました（論文 [arXiv 2601.20552「Visual Causal Flow」](https://arxiv.org/abs/2601.20552)）。変わったのはエンコーダーで、デコーダーは同じ3B規模のDeepSeek-MoEのままです。

従来のビジョン言語モデルは、画像のパッチを左上から右下へ機械的に並べてLLMに渡します。段組みの論文や表の多い資料では、この並びが人間の読み順と食い違います。OCR 2のDeepEncoder V2は、CLIPの代わりに小型LLMのQwen2-0.5Bをエンコーダーとして使い、「因果フロークエリ」という学習可能なトークンで、画像の内容に応じてビジョントークンを並べ替えてからデコーダーに渡します。

| 項目                   | DeepSeek-OCR        | DeepSeek-OCR 2      |
| -------------------- | ------------------- | ------------------- |
| 公開日                  | 2025年10月20日         | 2026年1月27日          |
| エンコーダー               | SAM-base＋CLIP-large | SAM-base＋Qwen2-0.5B |
| 総パラメータ               | 3,336,106,240       | 3,389,119,360       |
| ビジョントークン             | 64〜（モード選択）          | 256〜1,120           |
| OmniDocBench v1.5 総合 | 87.36（1,156トークン）    | 91.09（1,120トークン）    |
| 読み順の編集距離             | 0.085               | 0.057               |
| ライセンス                | MIT                 | Apache-2.0          |

OCR 2の解像度は1種類の動的モードだけで、768×768の局所ビュー0〜6枚と1024×1024の全体ビュー1枚を組み合わせます。トークン数は「局所ビュー枚数×144＋256」で、256から1,120の範囲に収まります。初版のTinyやSmallのような極端な圧縮モードは無くなりました。研究用の圧縮実験をしたいなら初版、文書をMarkdownにしたいならOCR 2、と使い分けるのが妥当です。

本番運用に近い指標も改善しています。正解の無い本番データで同じ文が繰り返し出力される割合（反復率）は、オンラインのユーザー画像で6.25%から4.17%へ、PDFの処理で3.69%から2.88%へ下がりました。一方で、論文は新聞のように文字が極端に詰まった紙面を弱点として挙げています。テキストの編集距離が0.13を超え、原因として「トークン上限の1,120では足りない」「新聞の学習データが25万件しかない」の2点を書いています。

## OmniDocBench v1.5で見る他のOCRとの位置づけ

OCR 2の論文は、中英9種類・1,355ページの文書解析ベンチマークOmniDocBench v1.5で他のモデルと比べています。総合スコアを抜き出すと次のとおりです（高いほど良い。DeepSeek以外の数値はOmniDocBenchリポジトリからの転載と論文に記載）。

| モデル            | 方式       | 総合    | 1ページの最大ビジョントークン数 |
| -------------- | -------- | ----- | ---------------- |
| PaddleOCR-VL   | パイプライン   | 92.86 | –                |
| DeepSeek-OCR 2 | エンドツーエンド | 91.09 | 1,120            |
| MinerU2.5      | パイプライン   | 90.67 | –                |
| Qwen3-VL-235B  | エンドツーエンド | 89.15 | 6,000超           |
| dots.ocr       | エンドツーエンド | 88.41 | 6,000超           |
| Gemini-2.5 Pro | エンドツーエンド | 88.03 | –                |
| DeepSeek-OCR   | エンドツーエンド | 87.36 | 1,156            |
| Marker-1.8.2   | パイプライン   | 71.30 | –                |

この表から言えるのは、DeepSeek-OCR 2が「総合スコアで1位のモデル」ではないということです。DeepSeek自身の比較でも、レイアウト解析と認識を分けたパイプライン型のPaddleOCR-VLが上にいます。OCR 2が勝っているのは、1ページを1,120ビジョントークン以下で読みながら、6,000ビジョントークン超を使う大型モデルと同等以上のスコアを出している点です。大量の文書を少ないビジョントークンで読みたい場合の候補になります。ただし実際の計算コストはエンコーダー・出力の長さ・実行環境で変わるため自社環境で測る必要があり、1ページの精度を最優先するならPaddleOCR-VLなどと並べて比べてください。

同じ表に載っているdots.ocrの後継は[dots.mocrの実力と日本語精度・導入手順](/tech/details/11776/)で、0.9Bの軽量モデルは[GLM-OCRの実体と日本語精度・vLLM/Ollama導入手順](/tech/details/10872/)で扱っています。PDFをMarkdownにするパイプライン型のツールとしては[Marker（marker-pdf）の使い方と商用ライセンス制約](/tech/details/12109/)も比較対象になります。

## DeepSeek-OCRの使い方：Transformers・vLLMで文書をMarkdownにする手順

### 公式推論手順のGPU環境と依存パッケージ

[公式リポジトリ](https://github.com/deepseek-ai/DeepSeek-OCR-2)の手順は、初版・OCR 2ともにNVIDIA GPUとCUDA 11.8を前提にしています。モデルは `.cuda()` でGPUに載せ、注意機構にFlashAttention 2を使うため、Apple SiliconやCPUだけの環境では公式手順のままでは動きません。

| 項目                  | 公式の検証環境                   |
| ------------------- | ------------------------- |
| Python              | 3.12.9                    |
| CUDA                | 11.8                      |
| torch               | 2.6.0（torchvision 0.21.0） |
| transformers        | 4.46.3（tokenizers 0.20.3） |
| flash-attn          | 2.7.3                     |
| vLLM（リポジトリ同梱スクリプト用） | 0.8.5+cu118               |

transformersは4.46.3に固定されています。vLLM 0.8.5は「transformers 4.51.1以上が必要」という警告を出しますが、READMEは同じ環境で両方を動かすなら無視してよいと書いています。環境構築は次のとおりです。

```
git clone https://github.com/deepseek-ai/DeepSeek-OCR-2.git
cd DeepSeek-OCR-2
conda create -n deepseek-ocr2 python=3.12.9 -y
conda activate deepseek-ocr2
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のwheelはGitHubのv0.8.5リリースページから事前にダウンロードし、クローンしたDeepSeek-OCR-2ディレクトリ直下に置いてから、上のインストールコマンドを実行します。初版を使う場合は、リポジトリ名と環境名の `-2` を外せば同じ手順です。

### Transformersで画像をMarkdownに変換するコード

1枚の画像を変換する最小のコードです。公式のHugging Faceモデルカードに載っているOCR 2の例をそのまま使っています。

```
from transformers import AutoModel, AutoTokenizer
import torch
import os

os.environ["CUDA_VISIBLE_DEVICES"] = "0"
model_name = "deepseek-ai/DeepSeek-OCR-2"

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. "
res = model.infer(
    tokenizer,
    prompt=prompt,
    image_file="your_image.jpg",
    output_path="your/output/dir",
    base_size=1024,
    image_size=768,
    crop_mode=True,
    save_results=True,
)
```

`trust_remote_code=True` は、Hugging Face上のモデル付属のPythonコードを実行するという指定です。社内環境で動かすなら、モデルのリビジョンを固定し、付属コードを確認してから使ってください。初版を使う場合は `model_name` を `deepseek-ai/DeepSeek-OCR` にし、`image_size` を640にします。

### DeepSeek-OCRの出力形式別プロンプト

出力の形式はプロンプトで切り替えます。公式READMEに載っているものを用途別に並べると次のとおりです。

| 用途             | プロンプト（<image>の後に続ける）                               |
| -------------- | -------------------------------------------------- |
| 文書をMarkdownに変換 | `<\|grounding\|>Convert the document to markdown.` |
| レイアウトなしで文字だけ   | `Free OCR.`                                        |
| 文書以外の画像の文字（初版） | `<\|grounding\|>OCR this image.`                   |
| 文書中の図表の解析（初版）  | `Parse the figure.`                                |
| 指定語の位置を探す（初版）  | `Locate <\|ref\|>xxxx<\|/ref\|> in the image.`     |

`<|grounding|>` を付けると、段落ごとに座標とラベルが付いたレイアウト付きの出力になります。RAGに投入するならMarkdown変換、検索用の全文テキストだけが欲しいなら `Free OCR.` が向いています。OCR 2のREADMEに載っているのは上の2つだけです。

### PDFの一括処理：vLLMスクリプト

PDFはリポジトリ同梱のvLLMスクリプトで処理します。`config.py` の `INPUT_PATH` と `OUTPUT_PATH` を書き換えてから実行します。

```
cd DeepSeek-OCR2-master/DeepSeek-OCR2-vllm
python run_dpsk_ocr2_pdf.py
```

PDFはページごとに画像化されてから並行処理されます。初版のREADMEは、A100-40G 1枚でおよそ毎秒2,500トークンの処理速度を示しており、OCR 2のREADMEは初版と同等の速度としています。

## DeepSeek-OCRをAPIとして使う方法：公式API・vLLMサーバー・ホスティング

### DeepSeek公式APIのOCRモデル提供状況

DeepSeekの公式APIの[料金ページ](https://api-docs.deepseek.com/quick%5Fstart/pricing)に載っているモデルは `deepseek-flash`（DeepSeek-V4.1-Flash）と `deepseek-v4-pro` の2つで、DeepSeek-OCRは提供されていません。`deepseek-flash` は画像入力（Vision）に対応しているため、画像を渡して文字を書き出させることはできますが、これは汎用モデルによる読み取りで、DeepSeek-OCRの圧縮やレイアウト付き出力とは別物です。V4系の仕様と料金は[DeepSeek V4の仕組みとPro/Flashの性能・料金](/tech/details/12053/)にまとめています。

### vLLMによるOpenAI互換サーバーの構築手順

自社で「DeepSeek-OCRのAPI」を持ちたい場合は、vLLM本体の対応を使うのが近道です。初版はvLLM v0.11.1から、OCR 2はv0.16.0（2026年2月25日リリース）から本体に組み込まれています。ここではリポジトリ同梱スクリプト用のvLLM 0.8.5環境とは別の仮想環境を作成し、使用するvLLM版の対応GPU・ドライバー要件に合わせてインストールします。

```
uv pip install -U vllm --torch-backend auto
vllm serve deepseek-ai/DeepSeek-OCR \
  --logits_processors vllm.model_executor.models.deepseek_ocr:NGramPerReqLogitsProcessor \
  --no-enable-prefix-caching \
  --mm-processor-cache-gb 0
```

これはvLLM Recipesに載っている初版のコマンドです。OCR 2を使う場合は、モデル名を `deepseek-ai/DeepSeek-OCR-2` に変更します（ロジットプロセッサーの指定は同じです）。`NGramPerReqLogitsProcessor` は同じ語句の繰り返し出力を抑える処理で、公式例では表のタグ（`<td>`・`</td>`）だけを抑制の対象外にしています。起動すると `http://localhost:8000/v1` にOpenAI互換のエンドポイントが立ち、OpenAIのSDKから画像付きのチャットとして呼び出せます。vLLM自体の仕組みとOllamaとの使い分けは[vLLMとは？PagedAttentionの仕組みと使い方](/tech/details/15786/)を参照してください。

### ホスティング事業者のAPI：Novitaのdeepseek-ocr-2

GPUを持たずにAPIで使う場合は、OCR 2を載せているホスティング事業者を使います。たとえばNovitaのOpenAI互換APIには `deepseek/deepseek-ocr-2` があり、2026年10月7日時点の料金は入力・出力とも100万トークンあたり0.03ドル、コンテキスト長は8,192トークンです。画像1枚が最大1,120トークンで、出力のMarkdownも同じ8,192トークンの枠に入るため、1リクエストで送るのは1ページずつが基本です。外部APIに文書を送ることになるため、契約書や個人情報を含む文書は、送信先の所在地とデータの扱いを確認してから使ってください。料金とモデルの掲載は変わるため、使う前に事業者のモデル一覧で確かめてください。

## Ollama・llama.cpp・LM Studioでのローカル実行

GPUサーバーを用意せずに手元で試す方法は、ランタイムごとに対応状況が違います（2026年10月7日時点）。

| ランタイム           | 初版                  | OCR 2         |
| --------------- | ------------------- | ------------- |
| Ollama          | 対応（v0.13.0以降・6.7GB） | 公式ライブラリに掲載なし  |
| llama.cpp（mtmd） | 2026年3月25日に対応       | 2026年5月29日に対応 |
| LM Studio       | 読み込めない報告が未解決        | 動かない報告が未解決    |
| vLLM            | v0.11.1以降           | v0.16.0以降     |

Ollamaでは `ollama run deepseek-ocr` で初版を取得でき、タグは `3b` と `3b-bf16` の2つです。プロンプトは画像のパスに続けて書きます。

```
ollama run deepseek-ocr "/path/to/image\n<|grounding|>Convert the document to markdown."
```

LM Studioの公式バグトラッカーには、DeepSeek-OCRを読み込めないという報告が4件、2026年10月7日時点で未解決のまま残っています。対象はLM Studio 0.3.30〜0.4.0で、WindowsでのGGUF版（「unknown model architecture」で失敗）と、macOSのMLX版（初版の実行時エラー、OCR 2の「Model type deepseekocr\_2 not supported」）です。いずれも報告時点の版での事象なので、LM Studioで試す場合は、使うランタイムの版とモデルの形式（GGUFかMLXか）を確認してから読み込んでください。確実に動かしたいなら、公式の手順があるOllama（初版）か、OCR 2まで対応したllama.cppを先に使うのが無難です。llama.cppは2026年に入ってから初版・OCR 2ともに対応し、その後も複数タイルやバッチ処理の修正が続いているため、使うときは最新のビルドを使ってください。

## 日本語文書でDeepSeek-OCRを採用する前の確認事項

DeepSeek-OCRを日本語の業務文書に使う場合、論文やREADMEの数値はそのまま当てはまりません。理由は学習データと評価データの両方にあります。

初版の論文によると、文書の学習データはインターネット上のPDF約3,000万ページで、約100言語を含みます。ただし内訳は中国語と英語が約2,500万ページ、その他の言語の合計が約500万ページです。レイアウト付きの精細な正解（fine annotations）が作られたのは中国語と英語の各200万ページで、少数言語の正解は、PDFから機械的に抜き出したテキストや、それで学習させたモデルの出力から作られています。写真に写った文字（看板など）の学習は中国語と英語だけです。評価に使われたFoxは英語、OmniDocBenchは中国語と英語で、日本語の精度はDeepSeekからは公表されていません。縦書きの評価もありません。

この前提から、次のような場面ではDeepSeek-OCRを第一候補にしないほうがよいと判断できます。

- 縦書きの書籍や古い公文書など、日本語特有のレイアウトが中心の文書（日本語の学習と評価がされた[YomiToku](/tech/details/6169/)や[NDLOCR-Lite](/tech/details/11281/)が先に試す対象になります）
- 新聞や細かい文字の多い帳票など、1ページの文字量が極端に多い文書（OCR 2の論文自身が新聞を弱点に挙げています）
- 1文字の読み違いも許されない用途で、出力をそのまま記録に使う場合（総合スコアではPaddleOCR-VLが上にあり、どのモデルでも人の確認工程が必要です）
- NVIDIA GPUが無く、外部APIにも文書を出せず、Ollamaやllama.cppでのローカル推論でも必要な精度・処理時間を満たせない環境

中英の文書が混ざる大量のPDFをLLMやRAGに取り込む前処理では、画像表現を1ページ256〜1,120ビジョントークンに収めるOCR 2が候補になります。ただし、OCRで生成するテキストと、その後RAGに投入するテキストのトークン数は別に発生します。採用を決める前に、自社の文書を50〜100ページほど選び、候補のモデルと並べて文字の編集距離と処理時間を測ってください。OCRの方式や精度の測り方の基本は[OCRとは？光学文字認識の仕組み・種類・精度](/tech/details/13582/)で解説しています。

## 光学圧縮がLLMの長文コンテキストと記憶管理に与える示唆

論文が最も強く主張しているのは、OCRの精度よりも「古い会話や文書を画像として持てば、LLMの記憶を安く保てる」という可能性です。直近の文脈はテキストのまま持ち、古くなった文脈ほど低い解像度の画像に描き直してトークンを減らしていけば、人の記憶がだんだん薄れるのに近い「忘却」を作れる、という提案です。20倍圧縮で精度が約60%まで落ちる結果も、論文では欠点ではなく忘却の仕組みとして使える性質として扱われています。

ただし、これは研究の方向性の提示であり、DeepSeek-OCRやOCR 2に「LLMの記憶を圧縮する機能」が付いているわけではありません。公開されているのはあくまで文書を読むOCRモデルです。長文コンテキストのコスト削減を目的にするなら、現時点では、ここから派生する研究の成果を待つ段階です。

## よくある質問

### DeepSeek-OCRは無料で商用利用できますか？

重みは無料でダウンロードでき、商用利用もできます。ライセンスは初版がMIT、DeepSeek-OCR 2がApache-2.0です。再配布時は各ライセンスの表示・同梱条件を確認してください。Apache-2.0では、ライセンス文の提供、変更したファイルへの変更通知、該当する権利表示の保持、元の配布物にNOTICEがある場合の帰属表示の継承などが必要です。自前で動かすGPUの費用は別にかかります。

### DeepSeek-OCRとDeepSeek-OCR 2はどちらを使えばよいですか？

文書をMarkdownやテキストに変換する目的なら、OCR 2を選んでください。OmniDocBench v1.5の総合スコアは87.36から91.09へ、読み順の誤りも0.085から0.057へ改善しています。64や100トークンまで縮める圧縮実験をしたい場合と、Ollamaで手軽に試したい場合は初版を使います。

### DeepSeek-OCRはAPIで使えますか？

DeepSeekの公式APIにOCRモデルはありません。vLLM（初版はv0.11.1以降、OCR 2はv0.16.0以降）でOpenAI互換サーバーを自前で立てるか、NovitaのようにOCR 2を載せているホスティング事業者のAPIを使います。

### LM StudioやOllamaでDeepSeek-OCRは動きますか？

Ollamaでは初版が `ollama run deepseek-ocr` で動きます（v0.13.0以降）。OCR 2はOllamaの公式ライブラリに掲載されていません。LM Studioでは、0.3.30〜0.4.0のGGUF版・MLX版で読み込めないという報告が未解決のまま残っています。LM Studioで試す場合はランタイムの版とモデル形式を確認し、確実に動かしたいならOllama（初版）かllama.cppを使ってください。

### DeepSeek-OCRは日本語の文書を読めますか？

学習データに日本語を含む約100言語のPDFが入っているため、読むことはできます。ただし学習の中心は中国語と英語で、日本語や縦書きの精度は公表されていません。業務で使う前に、自社の文書で日本語特化のOCRと比較してください。

## 関連記事

- [OCRとは？光学文字認識の仕組み・種類・精度と実装での組み込み方を解説](/tech/details/13582/)
- [dots.mocrとは？83.9点の実力と日本語精度・導入手順【2026年9月】](/tech/details/11776/)
- [GLM-OCRとは？0.9Bの実体と日本語精度・vLLM/Ollama導入手順とAPI料金](/tech/details/10872/)
- [vLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの使い分け](/tech/details/15786/)
- [DeepSeek V4とは？Compressed Sparse Attention(CSA)の仕組みとPro/Flashの性能・料金・移行期](/tech/details/12053/)

---

出典: [DeepSeek-OCRとは？光学圧縮の仕組みとOCR 2との違い・使い方・API](<https://www.issoh.co.jp/tech/details/9455/>)（株式会社一創）