DeepSeek-V4.1-Flash Vision API: DeepSeekのネイティブマルチモーダルモデルに画像を送信する方法

DeepSeekのビジョンサポートは、2026年9月10日にサイドプロジェクトではなくなりました。DeepSeek-V4.1-FlashのGAリリースにより、画像入力はdeepseek-flashという1つのIDのメインモデルに統合されました。個別のビジョンビルドや「Exp」サフィックスは存在しません。リリースノートではdeepseek-v4-flashとdeepseek-v4-flash-vision-expの両方が廃止され、どちらの名前へのリクエストもV4.1-Flashに到達するようになりました。

これは、3週間前に実験的なエンドポイントを基に構築した場合に重要となります。V4-Flash-Vision-Expに対して記述したリクエスト形式は引き続き機能しますが、画像を読み取るモデルは新しくなっています。これは、テキストバックボーンと並行してゼロからトレーニングされたビジョンエンコーダーを持つ763Bパラメータのモデルです。このガイドでは、「ネイティブマルチモーダル」が実際に何を意味するのか、画像を配信する3つの方法、detailパラメータ、画像のコスト、そして古い名前と新しい名前が同じように動作することを証明する反復可能なビジョンテストをApidogで構築する方法について説明します。

要約

モデルID: deepseek-flash。従来のdeepseek-v4-flash-vision-expという名前も引き続き解決されますが、V4.1-Flashによって処理されます。
画像はユーザーメッセージのcontent配列に含めます。base64データURL (最大32MiB)、外部URL (最大8,192文字)、またはファイルIDを使用します。
オプションのdetailフィールド: low、high (別名original)、またはauto。
DeepSeekが報告するビジョンベンチマーク: MMMU-Pro 56.5、CVBench 77.9、DocVQA 95.6、RefCOCO 86.0。
料金は標準のFlashレート: オフピーク時100万キャッシュミス入力トークンあたり$0.15、ピーク時$0.30。
コンテキストは100万トークン、最大出力は384Kで、テキストのみの呼び出しと同じです。

ここで言う「ネイティブマルチモーダル」とは

Vision-Expは、完成したテキストモデルに画像エンコーダーを接続していました。V4.1-Flashは逆のアプローチを取っています。モデルカードによると、画像は最初から45兆トークンの事前学習コーパスの一部であり、エンコーダーは既存のビジョンモデルから借用されたものではなく、ゼロからトレーニングされた新しいDeepSeek-ViTです。バックボーンは5520億パラメータの専門家混合モデルであり、エンコーダーを接続すると合計7630億パラメータに達します。プレフィル時には80億パラメータのみがアクティブになり、デコード時には160億パラメータがアクティブになります。これにより、これほど大規模なモデルでもFlashの速度と価格で動作します。V4-Flash APIガイドのテキスト専用モデルであるV4-Flashは、Vision-Expが拡張したベースでした。

DeepSeekは、モデルカードでこれら4つのビジョン評価スコアを報告しています。これらはベンダー自身の測定値であるため、APIを通じて独自のドキュメントを処理するまでは、主張として扱ってください。

ベンチマーク	測定内容	V4.1-Flash
MMMU-Pro	画像とテキストの両方を必要とする大学レベルの質問	56.5
CVBench	自然写真におけるカウント、奥行き順序、空間関係	77.9
DocVQA	スキャンされたドキュメントやフォームに対する質問応答	95.6
RefCOCO	画像内のフレーズが参照するオブジェクトの特定	86.0

APIユーザーにとって、DocVQAとRefCOCOは注目すべき項目です。ドキュメントQAは、請求書やフォームの抽出の背景にあるスコアです。RefCOCOはグラウンディングです。「メールフィールドの下にある送信ボタン」が与えられた場合、モデルはそれを見つけられるでしょうか？そのスキルは、スクリーンショットをエージェントのアクションに変えます。アーキテクチャの概要では、テキスト側の詳細と技術レポートをより深く掘り下げています。

リクエスト形式: 画像を配信する3つの方法

ワイヤー形式には変更はありません。OpenAI SDKを使用してhttps://api.deepseek.comのChat Completionsエンドポイントを呼び出し、テキストと画像の部分を同じcontent配列に入れ、モデルをdeepseek-flashに設定します。以下は、請求書をJSONに変換する完全な呼び出し例です。

import base64, json
from openai import OpenAI

client = OpenAI(api_key="YOUR_DEEPSEEK_KEY", base_url="https://api.deepseek.com")

with open("invoice-2026-0912.png", "rb") as f:
    image_b64 = base64.b64encode(f.read()).decode()

schema_hint = (
    "Return only JSON with keys: invoice_number (string), issue_date (YYYY-MM-DD), "
    "vendor (string), currency (string), line_items (array of {description, quantity, "
    "unit_price, amount}), subtotal, tax, total (numbers)."
)

response = client.chat.completions.create(
    model="deepseek-flash",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": schema_hint},
            {
                "type": "image_url",
                "image_url": {
                    "url": f"data:image/png;base64,{image_b64}",
                    "detail": "high",
                },
            },
        ],
    }],
    temperature=1.0,
    max_tokens=2048,
)

invoice = json.loads(response.choices[0].message.content)
print(invoice["invoice_number"], invoice["total"])
print(response.usage.prompt_tokens, "prompt tokens")

それがオプション1のbase64インラインです。自己完結型で、画像あたり32MiBに制限されており、一度限りの呼び出しやネットワークから出ないファイルに適しています。

オプション2は外部URLです。画像がCDNまたはオブジェクトストレージに公開リンクを既に持っている場合、エンコードをスキップしてリンク（最大8,192文字）を渡します。このcurlリクエストは、ホストされている料金表を読み取ります。

curl https://api.deepseek.com/chat/completions \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-flash",
    "messages": [{
      "role": "user",
      "content": [
        {"type": "text", "text": "List every plan name and its monthly price from this chart as a JSON array."},
        {"type": "image_url", "image_url": {"url": "https://assets.example-saas.com/pricing/plans-q3.png", "detail": "auto"}}
      ]
    }]
  }'

オプション3はファイルIDです。DeepSeekのFiles APIを通じて画像を一度アップロードし、バイトを再送信する代わりにfileパートで参照します。

{"type": "file", "file": {"file_id": "file-api-xxxxxxxxxxxxxxxx"}}

スイート内の各テストが比較対象とする参照スクリーンショットのように、同じ画像が複数のリクエストに登場する場合は常にファイルIDを選択してください。全パラメータの詳細については、V4.1-Flash APIガイドをご覧ください。

`detail`パラメータとリクエスト制限

detailはオプションであり、image_urlオブジェクト内に存在します。Vision-Expから引き継がれた3つの値:

"low"は512x512にダウンスケールします。最も安価で高速。「これはダッシュボードか、それとも領収書か」といった質問に適しています。
"high" (別名"original")は元の解像度を維持します。高密度なドキュメント、小さな活字、12ピクセルのラベルが重要なUIスクリーンショットに使用します。
"auto"はAPIに選択させます。

まず直面する制限:

制限	値
インラインbase64画像	最大32 MiB
外部URLの長さ	最大8,192文字
ファイルID参照	Files APIを通じてサポート
コンテキストウィンドウ	100万トークン
最大出力	384Kトークン
`detail`値	`low`、`high`/`original`、`auto`

Vision-Expガイドには、画像数、ボディサイズ、ピクセル寸法に関するさらなる制限が記載されていました。それらは実験的なモデル向けに公開されたものです。V4.1-Flashでそれらに依存する前に、API変更履歴を確認してください。一つのルールは変わっていません。画像はユーザーメッセージに属します。システムまたはアシスタントメッセージに画像を入れると、400エラーが返されます。

deepseek-flashでの画像のコスト

個別のビジョン料金はありません。画像は、2026年9月10日04:00 UTCから有効な料金ページに記載されているFlashレートで入力トークンとして課金されます。

deepseek-flash、100万トークンあたり	オフピーク	ピーク
入力、キャッシュヒット	$0.003	$0.006
入力、キャッシュミス	$0.15	$0.30
出力	$0.60	$1.20

ピーク時間は月曜日から金曜日のUTC 01:00～04:00と06:00～10:00です。オフピーク時は半額です。Vision-Expでは、各画像は最大384入力トークンとして課金されていました。その制限がV4.1-Flashに変わらず引き継がれるかは、ドキュメントで[要確認]です。すべての応答のusage.prompt_tokensは実際のカウントを報告するため、Pythonの例でそれが出力されます。

384トークンの上限が維持される場合、1枚の画像はピーク時のキャッシュミスレートで約$0.000115、オフピーク時でその半額となり、1,000枚の請求書で約$0.12の画像入力費用がかかります。実際のパイプラインでは出力が支配的です。1枚の請求書あたり400トークンのJSONは、ピーク時で画像自体の約4倍のコストがかかります。重要なのは厳密な応答スキーマであり、画像のダウンスケールではありません。ピーク時、オフピーク時、キャッシュヒット時の計算はDeepSeek-V4.1-Flashの料金解説で詳しく説明されています。要するに、キャッシュミス入力は8月にVision-Expが請求した料金より32%安くなっています。

パイロット実施に値する3つのユースケース

ドキュメント抽出。 請求書、領収書、納品書、保険フォームなど。固定されたJSONスキーマをプロンプトで指定し、detail: "high"で送信し、記録を信頼する前に明細項目が小計と一致するかどうかを確認します。
アサーションテストのためのUIスクリーンショット。 デプロイ後にページをキャプチャし、期待される要素が存在するか、どこにあるかを尋ね、その回答を合否判定に利用します。RefCOCOが関連するベンチマークです。その目的は、指定された要素を見つけることです。
チャートの読み取り。 チャート画像から系列名、軸ラベル、プロット値をテーブルに抽出します。線が重なっていたり、軸にラベルがなかったりする場合は、人間の目視確認が必要です。

Apidogでのビジョンエンドポイントのテスト

ビジョンリクエストを手動で反復処理するのは手間がかかります。base64のブロブはJSONボディを読みにくくし、detail設定を比較するにはほぼ同一のペイロードを操作する必要があります。以下に、読みやすく、ワンクリックで再実行できるループを示します。

環境設定。 base_url、api_key、model (deepseek-flash)、detail (high)の変数を作成します。後でdetailレベルを切り替えるのは、ペイロードの編集ではなくドロップダウンの変更で行います。
リクエスト前スクリプトでの画像のエンコード。 base64をボディに貼り付ける代わりに、リクエスト前スクリプトでサンプルファイルをエンコードし、その結果をimage_b64変数に書き込みます。表示されるボディは数行のままで、テスト画像を交換するには1つのパスを変更するだけです。
変数を含むリクエストボディの保存。 "model": "{{model}}"、"detail": "{{detail}}"、および"url": "data:image/png;base64,{{image_b64}}"を使用します。再利用できるようにテストケースとして保存します。
JSON形式のアサート。 応答がJSONとして解析され、invoice_numberが空でない文字列、line_itemsが空でない配列、totalが数値であり、usage.prompt_tokensが選択したしきい値を下回ることをアサートします。これにより、「問題なし」が合否判定に変わります。
レガシー名が同じモデルにルーティングされることを確認。 保存したリクエストを複製し、modelをdeepseek-v4-flash-vision-expに設定し、同じ画像に対して両方を1つのテストシナリオで実行します。抽出されたフィールドとusage.prompt_tokensの数を比較します。結果が一致すれば、リリースノートが述べている通り、両方の名前がV4.1-Flashに到達することを確認でき、安心して設定を変更できます。
CIでの実行。 apidog-cliを使用して、プロンプトが変更されるたびにシナリオを実行し、スキーマの回帰が本番環境に出る前に検出できるようにします。

Apidogをダウンロードすれば、約15分でセットアップが完了します。ApidogはAPIレイヤーをテストするものであり、モデルホストをテストするものではないため、後でルーティングするあらゆるOpenAI互換エンドポイントに対して同じシナリオが機能します。

まとめ

実験的なエンドポイントは、リクエスト形式と価格設定を証明しました。V4.1-Flashは両方を維持し、最初のトレーニングトークンから画像を認識していたモデルに入れ替わります。クライアントをdeepseek-flashに向け、detailを変数に保持し、返されるJSONをアサートし、Apidogの同じシナリオでレガシー名を一度実行してルーティング変更を確認してください。その後、残る唯一の疑問は、ご自身のドキュメントでの精度ですが、それに対する答えを出すテストが今、手元にあります。

要約