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

DeepSeek-v4-フラッシュビジョン-exp

概要

deepseek-v4-flash-vision-exp モデルは、 画像とテキスト の同時入力に対応 JPEG, PNG, GIF, WebP 形式の画像ファイルをサポート 画像送信方法は 3種類 (Base64, 外部URL, Files API経由) リクエストや画像サイズなどに 制限事項 あり OpenAI互換、Anthropic互換、Responses APIでも利用可能

deepseek-v4-flash-vision-expモデルの画像入力方法

  • 画像とテキストの同時入力 による多様な解析(画像説明、テキスト抽出、グラフ分析など)
  • 対応画像形式 :JPEG、PNG、GIF、WebP
  • 画像形式の判定 はファイル内容から自動判別

画像送信方法

  • Base64エンコード画像(インライン)

    • 画像をBase64でエンコードし、data: URLとしてリクエストに直接埋め込み
    • 48 MiB のリクエストボディ上限に含まれる
    • ローカルファイル利用時に最適
  • 外部画像URL

    • 公開アクセス可能なhttp(s)リンクを指定
    • URL長は 8192文字以内、画像サイズは 32 MiB以下
    • ダウンロード時間は60秒以内
  • Files API経由のファイル参照

    • 画像を一度アップロードし、返却された file_id で参照
    • 64 MiB までの画像に対応
    • 複数回使い回し大容量画像 に最適
    • file_dataによるBase64インライン埋め込みも選択可能(file_idとの併用不可)

画像詳細度(detailフィールド)

  • detailパラメータで画像処理の粒度を設定可能
    • low :512×512へ縮小し高速・低コスト
    • high/original/auto :元画像を維持

Files API利用推奨ケース

  • リクエストボディが48 MiBを超える場合
  • 32 MiB超の画像を扱う場合
  • 同一画像を複数回使い回す場合

トークン消費

  • 画像は リサイズ後のピクセル数 に応じてトークン化
    • 小さい画像(384×384未満)は拡大、大きい画像は 800×800相当 に縮小
    • 1画像あたり最大384トークン
    • 複数画像も 独立して計算

主な制限事項

  • サポート画像形式: JPEG, PNG, GIF, WebP
  • 外部URL長: 8192文字
  • リクエストボディサイズ: 48 MiB
  • 1画像サイズ(Base64/外部URL): 32 MiB
  • 1画像サイズ(Files API): 64 MiB
  • 1リクエスト画像数: 600枚
  • 画像合計サイズ: file_id画像なし64 MiB、file_id画像含む最大200 MiB
  • 画像1辺最大: 8192 px(画像15枚以上の場合4096 px)
  • 画像はuserメッセージのみ対応 (system/assistantメッセージ不可)
  • deepseek-v4-flash-vision-exp以外のモデルは画像非対応

Anthropic APIでの画像利用

  • Anthropic互換エンドポイントhttps://api.deepseek.com/anthropic)でも画像送信可
  • 画像ブロック形式はOpenAI互換APIと異なり、source.typebase64, url, file を指定
    • base64 :media_type(例:image/jpeg)必須
    • url :最大8192文字
    • fileanthropic-beta: files-api-2025-04-14ヘッダー必須

Responses APIでの画像利用

  • OpenAI互換Responses API でも画像送信可
  • 画像はinput_imageパートで送信
  • detailフィールド で画像処理粒度指定(Files APIのfile_id時は無効)
  • system/assistantメッセージの画像は非対応 (400エラー)

参考:画像処理の流れと制限

  • 画像送信→トークン変換→リサイズ→モデル推論 という流れ
  • 複数API方式 (OpenAI互換、Anthropic互換、Responses API)で柔軟運用可能
  • 用途や画像サイズ、再利用有無 に応じて適切な方法選択が重要

Hackerたちの意見

DeepSeek v4 Flash 0731は、自分に視覚能力があると思い込んで、実際には見えないことがわかるとテキストベースの画像分析ツールを作り出すことが多いって聞いたよ。そういう意味では、これはモデルにとって素晴らしいアップグレードだね。実際、0731にはスクリーンショットを見ないように言わなきゃいけなかった。画像を読み取ろうとしてセッションが壊れちゃうから。

3つの別々のプロジェクトでピクセルを分析して、視覚を再現しようとしたんだ。

これを軽減するために、ハーネスが別のモデルを使うっていう「スキル」を与えたんだ。

うん、よく見たことある。接続されたデバイスからスクリーンショットを引っ張ってくるのに、頼まれもしないのに頑張ってて、そしたら…あ、やべえ、見えないわ。

大きな画像はアスペクト比を保ちながら縮小されるから、リサイズ後の総ピクセル数はだいたい800×800画像のそれに近くなるよ。便利だけど、OCRや他の多くのアプリケーションにはもう少し高い方がいいね(例えば、A4サイズやレターサイズのページを入れる場合)。

分割してフィードできる?

DSがPlaywrightのスクリーンショットを正確に見ることができないのが、Sonnetから一番恋しいところだな。これは期待できそう。 > 画像はその寸法に基づいてトークンに変換されて、そのトークンはテキストトークンと一緒に請求されるよ。 > 推論の前に、すべての画像は自動的にリサイズされる: > - 総ピクセル数が約384×384未満の画像は、アスペクト比を保ちながら拡大される。 > - 大きな画像はアスペクト比を保ちながら縮小されて、リサイズ後の総ピクセル数はだいたい800×800画像のそれに近くなる。 > その結果、画像ごとに384トークンの上限があるよ。例えば、2000×2000画像と5000×5000画像はリサイズ後に同じ数のトークンを消費する。リクエストに複数の画像が含まれている場合、各画像は同じルールの下で独立してカウントされる—マルチ画像リクエストのための別計算はないよ。画像ごとに400トークンだと、1ドルで2,500画像になるはず。編集: フォーマット。

うーん、800×800だと使い道がかなり減っちゃうな。

面白いね。Deepseekの創設者が、マルチモーダルモデルには全く焦点を当てないことに決めて、テキストだけにするって言ってたよね。AGIを達成するにはそれで十分だと信じてるみたい。

あなたが言ってるのは、ダリオが画像生成について言ったことだと思うよ。

明確にマルチモーダルサポートを追求していると言ってたよ。会議の議事録からの引用: https://github.com/demo-zexuan/liang-wenfeng-investor-meetin... それでも、コンポーネントとしては、マルチモーダルサポートを実装することは間違いないし、すでにやってるよ。V4やその後のバージョンがマルチモーダル機能をネイティブにサポートするように、関連するモデルを開発する予定だよ。以前に言われたことがあって、それがあなたの考えにもっと合ってるかも。AIトレーニングで優れた成果を上げるためには、グローバルモデルやマルチモーダルアプローチは必要ないんだ。AIトレーニングの範囲を狭めて、マルチモーダリティを排除することで、特定のタスクはアルゴリズムの妥当性を損なうことなく達成できないかもしれない。結局、マルチモーダルアプローチは実装する必要があるよ。誰が何を言ったのかはわからないけど、スピーカーIDが欠けてるからね。

ちなみに、deepseekはかなり前から別のビジョン対応モデルを持っていて、それがチャットインターフェースのビジョンモードにも使われてるんだよね。

Hacker Newsで議論の続きを見る