画像を含むドキュメントを扱うプロダクトで、どのVLM（Vision-Language Model、画像とテキストを同時に理解できるモデル）を選ぶか迷っている開発者に向けた内容です。DeepSeekというAI企業が公開してきたビジョン系モデルの系譜を整理し、自分のプロダクトにどれが向くかを判断する軸を示します。
2024年以降、DeepSeekはDeepSeek-VL、DeepSeek-VL2、Janus、そして最新のdeepseek-v4-flash-vision-expと、段階的にビジョン機能を強化してきました。単に「画像入力に対応した」という一言では済まない設計変化が各世代にあります。どの世代の設計思想を選ぶかで、OCR精度やレスポンス速度、運用コストが変わってきます。
どんな場面で選定が必要になるか
PDFやスクリーンショット、チャート画像を解析する機能をプロダクトに組み込む場面を想定します。
たとえば経費精算アプリのレシート読み取り、社内文書検索でのスキャンPDF対応、ダッシュボード画像からの数値抽出などです。
こうしたタスクでは、単なる画像キャプション生成モデルでは精度が足りません。高解像度の文字を読み取る力と、文書構造を理解する力の両方が必要になります。DeepSeekの系譜はまさにこの用途を強く意識して設計されてきました。
判断軸1: 解像度とタイリング方式
DeepSeek-VLは、意味理解用の低解像度エンコーダー（SigLIP-Lベース）と、高解像度エンコーダー（SAM-Bスタイル）を組み合わせたハイブリッド構成を採用しています。
画像全体の意味を掴む処理と、小さな文字や細部を拾う処理を分けているイメージです。単一の固定リサイズでは、文書の細かい文字が潰れてしまう問題があります。
後継のDeepSeek-VL2では、アスペクト比や解像度が異なる画像に対応する動的タイリング（画像を複数のタイルに分割して処理する方式）が導入されました。スクリーンショットや縦長の帳票など、アスペクト比が不揃いな入力を扱うプロダクトなら、この世代以降の設計を意識する価値があります。
判断軸2: 推論効率とモデル規模
DeepSeek-VL2の言語コンポーネントには、Mixture-of-Experts（MoE、入力ごとに一部のパラメータだけを活性化させる仕組み）が使われています。
すべてのパラメータを毎回動かすのではなく、必要な専門家（エキスパート）ネットワークだけを呼び出すことで、モデル規模を大きくしても推論コストを抑える狙いがあります。
DeepSeek-VLはApproximately 1.3Bと7Bの2バリアントが公開され、DeepSeek-VL2はTiny・Small・より大きな変種のファミリーとして公開されています。プロダクトの推論コスト制約に応じて、まずTinyやSmallで精度を検証し、必要なら大きい変種に切り替えるという段階的な選び方ができます。
判断軸3: 理解タスクと生成タスクの分離度
Janusという別系統の研究では、視覚理解と画像生成を1つの自己回帰フレームワークで両立させる設計が検討されています。
具体的には、意味理解用の視覚パスと、画像生成用の離散トークンパスを分離しています。両者は同じ自己回帰トランスフォーマーに接続されますが、エンコーディングの経路自体は別です。
プロダクト要件が「画像を読み取るだけ」なのか「画像も生成したい」のかによって、参照すべき設計がDeepSeek-VL系なのかJanus系なのかが変わってきます。読み取り専用のOCR・文書解析用途であれば、Janusの生成パスは基本的に不要な複雑さです。
判断軸4: 学習データの検証可能性
DeepSeek-VLは3段階の学習手順（アダプター事前学習、共同事前学習、教師ありファインチューニング）を公開論文で説明しています。
最終的な事前学習データの比率は、テキストが約70%、マルチモーダルデータが約30%という具体的な数字も開示されています。急にマルチモーダルデータへ切り替えるのではなく、段階的に導入する「モダリティ・ウォームアップ」戦略も採用されています。
一方で、最新のdeepseek-v4-flash-vision-expについては、学習データの詳細がどこまで公開されているかは論文と現行のAPIドキュメントを別々に確認する必要があります。研究論文で開示された設計思想と、実際に提供されているAPIの挙動は必ずしも同じ粒度で説明されているわけではない点は、選定時に注意しておきたいところです。
選択肢の比較
| モデル | 主な強み | 向いている用途 | 注意点 |
|---|---|---|---|
| DeepSeek-VL | OCR・文書理解に特化した設計 | PDF解析、チャート読み取り | 解像度が固定的で軽量 |
| DeepSeek-VL2 | 動的タイリング、MoEによる効率化 | 高解像度・不揃いなアスペクト比の画像 | Tiny/Small/大規模の選定が必要 |
| Janus | 理解と生成の両立 | 画像生成も含む対話型アプリ | 読み取り専用用途には過剰 |
| Vision-Exp系 | 統合的なマルチモーダル対応 | 幅広い画像入力を単一APIで処理 | 学習データの詳細が要確認 |
ケース別の推奨
OCRや帳票解析が中心で、レスポンス速度とコストを重視するなら、DeepSeek-VLか、DeepSeek-VL2のTiny/Small変種が候補になります。まずは小さい変種でOCR精度をベンチマークし、不足があれば大きい変種を試す流れが無難です。
スクリーンショットや縦長帳票など、画像の形状が不揃いなプロダクトなら、動的タイリングを持つDeepSeek-VL2以降を優先して検討する価値があります。
画像生成も同じパイプラインで扱いたい場合は、Janusの設計思想が近い候補になります。ただし読み取り専用なら不要な複雑さを抱え込む点は意識しておきたいところです。
幅広い入力タイプを単一のAPIでまとめたいなら、最新のVision-Exp系がシンプルな選択肢です。ただしこの世代は学習データの開示粒度が過去の論文ほど明確でない可能性があるため、公式ドキュメントで学習データやライセンス条件を必ず確認しておく必要があります。
あえて見送るべき条件
以下のような条件では、最新のVision-Exp系を急いで採用する必要はないかもしれません。
- 学習データの詳細な開示が契約上・監査上どうしても必要な場合（現時点で確認できる情報が限られるため）
- 画像入力が単純なアイコン判定程度で、高解像度OCRが不要な場合（軽量な既存モデルで十分な可能性）
- 画像生成機能が将来的にも不要と明確な場合（Janus系の複雑さを避けられる）
- 推論コストの上限が厳しく、MoE構成のオーバーヘッドを検証する時間が取れない場合
こうした条件に当てはまる場合は、要件を絞ったうえで、DeepSeek-VLのような初期世代や、他社の軽量VLMとの比較検討を優先したほうが現実的です。
まとめ
DeepSeekのビジョン系モデルは、DeepSeek-VLのOCR特化設計から、DeepSeek-VL2の動的タイリングとMoE効率化、Janusの理解・生成分離、そして最新のVision-Exp系による統合APIへと段階的に発展してきました。
選定にあたっては、解像度処理方式・推論コスト・生成機能の要否・学習データの検証可能性という4つの軸で自分のプロダクト要件と照らし合わせるのが実用的です。
次の一歩としては、公式ドキュメントで各モデルのライセンス条件と学習データの開示範囲を確認し、候補を1〜2個に絞ってOCRベンチマークを手元のデータで試してみることをおすすめします。