GPT-4.1 Nano vs Qwen3 VL Plus Vision API ベンチマーク 2026：実運用目線の画像理解モデル比較

GPT-4.1 Nano vs Qwen3 VL Plus Vision API ベンチマーク 2026：実運用目線の画像理解モデル比較#

本番環境で vision model を選ぶとき、「画像に対応しているか」だけでは不十分です。実際の開発者が必要としているのは、ユーザーの画像アップロード、スクリーンショット、UI デバッグ、ロゴ検出、文書プレビュー、サポートチケット、そして OpenAI-compatible API 経由で視覚情報を扱う agent workflow で安定して動くルートです。

この記事では gpt-4.1-nano と qwen3-vl-plus を Crazyrouter OpenAI-compatible Base URL 経由で比較します。

https://cn.crazyrouter.com/v1

リクエスト形式は chat/completions で、messages[].content[] にテキストと image_url を入れています。各モデルは Python logo と GitHub logo の 2 つの安定した公開画像でテストし、各画像につき 3 回実行しました。

テスト時刻：2026-06-21T13:36:32Z。これは model card の転載ではなく、実際の API 測定結果です。

先に結論#

• リアルタイムのユーザー画像アップロードでは、今回より高速だった gpt-4.1-nano を優先候補にできます。
• 大量のタグ付け、ロゴ認識、軽量分類では、成功画像あたりの推定コストが低い gpt-4.1-nano が有利です。
• 複雑なスクリーンショット、文書、OCR、グラフ理解では、より強いモデルでの二段階評価を追加してください。

ユーザー視点の scorecard#

この benchmark で判断できること#

これは意図的に vision API smoke test として設計しています。判断できるのは次のような点です。

• OpenAI-compatible API 経由で image_url が動くか
• モデルがテキスト prompt だけでなく、実際に画像を見ているか
• 小さなユーザー向け image request でどちらが速いか
• 大量の簡単な画像分類でどちらが安いか
• usage metadata が画像処理と矛盾していないか

一方で、これは OCR、chart reasoning、手書き文字、医療画像、密な文書抽出、multi-image reasoning の完全評価ではありません。そのような workflow では、このテストを最初の routing check として使い、別途 domain-specific evaluation を追加してください。

Raw benchmark data#

出力例#

Production routing guidance#

1. Real-time image uploads#

チャットアプリ、カスタマーサポート、ユーザー画像アップロードでは latency と reliability が最重要です。安いモデルでも、ユーザーが再試行したり、毎回 fallback が発生したりするなら、結果的に安くありません。

2. Bulk logo、icon、screenshot tagging#

大量分類では、成功画像あたりのコストが重要です。タスクが単純で、回答形式を検証できるなら低コストルートを使い、empty answer、no-image claim、low-confidence classification のときだけ fallback します。

3. OCR と document workflows#

この benchmark は OCR quality を証明するものではありません。請求書、表、フォーム、レシート、テキスト量の多いスクリーンショットでは、実データで別の評価が必要です。ロゴを認識できるモデルが layout extraction に強いとは限りません。

4. Visual context を持つ agent workflows#

Agent は入力の安定性を必要とします。HTTP 200 でも image content が落ちるルートでは、agent が自信を持って間違った判断をする可能性があります。Agent 用途では answer correctness、usage signals、疑わしい image path で fail closed する設計が必要です。

5. Gateway media behavior#

image_url support には複数の意味があります。クライアントから URL を受け取れるだけなのか、gateway が media を取得して変換するのか、upstream provider に元の URL を渡すのか。これは bandwidth、privacy、SSRF controls、latency、billing に影響します。Media behavior は model routing の一部として扱うべきです。

HTTP 200 だけでは足りない理由#

有効な HTTP response は、API が何かを返したことを示すだけです。画像がモデルに届いた証明にはなりません。Vision API monitoring では、小さな deterministic test image を送り、答えが決まっている質問をして、テキスト回答と usage metadata の両方を確認してください。

特に usage 上で image tokens が見えない場合や、モデルが「画像が提供されていない」と答える場合は注意が必要です。それはモデル品質の問題ではなく、adapter、media-fetch、payload conversion、routing の問題かもしれません。

API example#

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://cn.crazyrouter.com/v1"
)

response = client.chat.completions.create(
    model="gpt-4.1-nano",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "Identify the main logo or object in this image."},
            {
                "type": "image_url",
                "image_url": {
                    "url": "https://raw.githubusercontent.com/github/explore/main/topics/python/python.png",
                    "detail": "low"
                }
            }
        ]
    }],
    max_tokens=40,
    temperature=0,
)

print(response.choices[0].message.content)

コード内の API endpoint に UTM パラメータは付けません。人がクリックするリンクには UTM を付けられます。例：Crazyrouter Pricing。

Final takeaway#

最適な Vision API route は workflow によって変わります。リアルタイム対話では正しい認識と低 latency。大量分類では cost per successful image。Agent や document workflow では reliability、usage signals、fallback design が重要です。

つまり、vision model は名前だけで選ぶべきではありません。タスク、failure mode、media path、latency、そして有用な結果あたりのコストで選ぶべきです。