#vision api

6つのVision APIモデルを実測：Gemini 2.5、GPT-4.1、Qwen3 VLの画像理解はどう選ぶべきか

画像理解APIをプロダクトに入れるとき、「画像対応モデルです」という説明だけでは足りません。

モデルページには vision input 対応と書かれていても、実運用では次のような点を確認する必要があります。

OpenAI互換の image_url payload が本当にモデルまで届いているか

HTTP 200 が返っても、モデルが画像を見たとは限らない

ユーザーが待つ画面で十分に速いか

バッチ処理で十分に安いか

失敗時に fallback しやすいか

usage metadata から壊れた media path を検知できるか

今回は、同じOpenAI互換API形式で6つのvision-capableモデルを比較しました。

gemini-2.5-flash

gemini-2.5-flash-lite

gpt-4.1-mini

gpt-4.1-nano

qwen3-vl-flash

qwen3-vl-plus

目的は「絶対的な最強モデル」を決めることではありません。

より実用的な問いは、どのユーザーworkflowにどのモデルをroutingすべきかです。

テスト方法

すべてのリクエストは Crazyrouter の OpenAI互換 Base URL を使いました。

https://cn.crazyrouter.com/v1

API形式は chat/completions で、画像は messages[].content[] の中に image_url として渡しています。

テスト画像は2つです。

Python logo

GitHub logo

各モデルで各画像を3回ずつ処理しました。つまり、1モデルあたり合計6リクエストです。

テスト時刻：2026-06-21T13:36:32Z

これは Vision API smoke test です。image_url 経路が正常に動くか、モデルが簡単な画像認識をできるかを見るためのテストです。OCR、図表理解、文書抽出、手書き文字、医療画像などの完全な評価ではありません。

先に結論

今回の結果から見ると、実用上のおすすめは次の通りです。

リアルタイムのユーザー画像アップロード：gpt-4.1-mini

大量のlogo / icon / 簡単な画像分類：qwen3-vl-flash

低コストなGeminiルート：gemini-2.5-flash-lite

低コストなOpenAI系ルート：gpt-4.1-nano

Qwen VLの品質重視アップグレード：qwen3-vl-plus

今回のimage_url経路ではデフォルト非推奨：gemini-2.5-flash

一番重要な発見はこれです。

HTTP 200 は、画像理解が成功した証明ではありません。

今回 gemini-2.5-flash は6回すべてHTTP上は成功しましたが、画像認識は 0/6 でした。「画像が提供されていない」という応答や、GitHub logoを別のロゴとして認識する出力もありました。

これはproductionでかなり危険な失敗パターンです。API呼び出しは成功しているように見えるのに、モデルは画像を正しく処理していないからです。

全体結果

モデルHTTP成功正しく認識no-image応答平均レイテンシ最遅リクエスト10k回相当の概算コスト向いている用途qwen3-vl-flash6/66/603.819s5.975s$0.0915低コストな大量認識gpt-4.1-mini6/66/601.491s2.189s$0.5226ユーザー向けリアルタイム機能gpt-4.1-nano6/66/602.863s4.213s$0.1666低コストなOpenAI系fallbackqwen3-vl-plus6/66/603.859s4.821s$0.3848Qwen系の品質重視ルートgemini-2.5-flash6/60/614.965s9.507s$0.6168今回のimage_url経路では失敗gemini-2.5-flash-lite6/66/602.618s4.195s$0.5466低コストなGeminiルート

10k回相当の概算コストは、今回のlogo認識テストで観測されたusageに基づくものです。大きな画像、OCR、長い説明、multi-image promptでは実際のコストは変わります。

重要なのは、モデルの単価だけではなく cost per successful image task を見ることです。

安いモデルでも、retryやfallbackが頻発するならproductionでは安くありません。

Accuracy：5モデルは成功、1モデルは失敗

今回のsmoke testでの正答率は以下です。

qwen3-vl-flash: 6/6

gpt-4.1-mini: 6/6

gpt-4.1-nano: 6/6

qwen3-vl-plus: 6/6

gemini-2.5-flash-lite: 6/6

gemini-2.5-flash: 0/6

簡単なlogo / icon recognitionでは、6つ中5つのルートが正しく動きました。つまり、基本的な画像分類であれば、軽量モデルでも十分なケースがあります。

ただし gemini-2.5-flash の結果は重要です。HTTP success は image path が正常であることを意味しません。

Latency：最速はGPT-4.1 Mini

平均レイテンシの低い順です。

gpt-4.1-mini: avg 1.491s, median 1.292s, slowest 2.189s

gemini-2.5-flash-lite: avg 2.618s, median 2.627s, slowest 4.195s

gpt-4.1-nano: avg 2.863s, median 2.562s, slowest 4.213s

qwen3-vl-flash: avg 3.819s, median 3.493s, slowest 5.975s

qwen3-vl-plus: avg 3.859s, median 3.729s, slowest 4.821s

gemini-2.5-flash: avg 4.965s, median 4.333s, slowest 9.507s

ユーザーが画面上で待つ機能では、レイテンシはプロダクト品質の一部です。画像をアップロードして返答を待つ場合、1〜2秒の差は体感に影響します。

6 个 Vision API 模型实测总览：Gemini 2.5、GPT-4.1、Qwen3 VL 图片理解怎么选？

如果你在做图片理解、截图识别、logo 检测、图片分类、客服截图分析，或者给 agent workflow 接入视觉输入，模型选择不能只看“支持图片”四个字。

真正上线时，你至少要回答 6 个问题：

image_url 请求链路是否真的可用？

HTTP 200 是否等于模型真的看到了图片？

哪个模型对实时用户上传更快？

哪个模型适合批量低成本识图？

usage / image token 信号是否可信？

出错时应该 fallback 到哪个模型？

这篇文章把前面 15 篇 pairwise benchmark 的结果综合起来，对 6 个模型做一次总览：

gemini-2.5-flash

gemini-2.5-flash-lite

gpt-4.1-mini

gpt-4.1-nano

qwen3-vl-flash

qwen3-vl-plus

测试统一使用 Crazyrouter OpenAI-compatible Base URL：

https://cn.crazyrouter.com/v1

请求格式是 OpenAI 兼容 chat/completions，图片通过 messages[].content[] 中的 image_url 传入。每个模型测试两张公开图片：Python logo 和 GitHub logo；每张图跑 3 次，所以每个模型共 6 次请求。

测试时间：2026-06-21T13:36:32Z。这是实测 API 结果，不是官网参数搬运。

一句话结论

如果你只想快速选型：

实时用户上传图片 / 低延迟交互：优先 gpt-4.1-mini

批量 logo / 图标 / 简单图片分类：优先 qwen3-vl-flash 或 gemini-2.5-flash-lite

OpenAI 路线低成本备用：gpt-4.1-nano

Qwen 质量优先路线：qwen3-vl-plus

本轮不建议做默认 image_url 识图路由：gemini-2.5-flash

最重要的一点：HTTP 200 不等于图片理解成功。本轮 gemini-2.5-flash 的请求全部返回成功，但图片识别正确率是 0/6，还出现了“未提供图片”、错识别 CBC logo、飞船等异常输出。

6 个模型总表

模型HTTP 成功识图正确no-image 回复平均延迟中位延迟最慢请求输入价 / 1M tokens输出价 / 1M tokens10k 次测试式调用估算usage/image 信号定位qwen3-vl-flash6/66/603.819s3.493s5.975s$0.05$0.4$0.0915有 image_tokens 信号低价批量识图首选，适合 logo、图标、简单截图分类gpt-4.1-mini6/66/601.491s1.292s2.189s$0.26$1.04$0.5226image_tokens 为 0/缺失，需 smoke test低延迟线上交互首选，适合用户实时上传图片gpt-4.1-nano6/66/602.863s2.562s4.213s$0.065$0.26$0.1666image_tokens 为 0/缺失，需 smoke test低成本 OpenAI 路线，适合轻量视觉标签和简单分类qwen3-vl-plus6/66/603.859s3.729s4.821s$0.1429$1.4286$0.3848image_tokens 为 0/缺失，需 smoke testQwen 质量优先路线，适合比 flash 更重的视觉理解gemini-2.5-flash6/60/614.965s4.333s9.507s$0.17$0.68$0.6168image_tokens 为 0/缺失，需 smoke test本轮 image_url 路径异常，不建议作为默认识图路由gemini-2.5-flash-lite6/66/602.618s2.627s4.195s$0.055$0.22$0.5466image_tokens 为 0/缺失，需 smoke test低价 Gemini 轻量路线，本轮识图 6/6 正确

按准确率排序

本轮是简单 logo / 图标识别 smoke test。正确识别率如下：

qwen3-vl-flash — 6/6 正确

gpt-4.1-mini — 6/6 正确

gpt-4.1-nano — 6/6 正确

qwen3-vl-plus — 6/6 正确

gemini-2.5-flash-lite — 6/6 正确

gemini-2.5-flash — 0/6 正确

这里要特别注意：除了 gemini-2.5-flash，其它 5 个模型在这轮简单图片理解中都是 6/6 正确。也就是说，如果你的任务只是 logo、图标、简单截图分类，很多轻量模型已经足够，不一定要直接上最贵路线。

但 gemini-2.5-flash 是一个典型反例：HTTP 全成功，但视觉输入链路没有正确工作。这类问题在生产环境里比显式报错更危险，因为系统可能以为模型已经看过图片，然后继续执行错误逻辑。

按速度排序

平均延迟从低到高：

gpt-4.1-mini — 平均 1.491s，中位 1.292s，最慢 2.189s

gemini-2.5-flash-lite — 平均 2.618s，中位 2.627s，最慢 4.195s

gpt-4.1-nano — 平均 2.863s，中位 2.562s，最慢 4.213s

qwen3-vl-flash — 平均 3.819s，中位 3.493s，最慢 5.975s

qwen3-vl-plus — 平均 3.859s，中位 3.729s，最慢 4.821s

gemini-2.5-flash — 平均 4.965s，中位 4.333s，最慢 9.507s

如果是用户在线等待的功能，比如聊天窗口里上传图片、客服系统实时分析截图、agent 需要马上根据图片决策，速度优先级很高。本轮 gpt-4.1-mini 的平均延迟最低，是实时交互场景的强候选。

但速度不能脱离正确率。一个很快但没看到图片的路由没有意义。因此生产默认路由要同时看：

是否真的识图成功；

平均延迟是否低；

最慢请求是否可接受；

failure mode 是否可被监控和 fallback。

按成本排序

这里用本轮观测到的平均 prompt/completion tokens，粗略估算 10,000 次同类请求的成本。排序如下：

qwen3-vl-flash — 约 $0.0915 / 10k 次，平均 prompt tokens 111.0，completion tokens 9.0

gpt-4.1-nano — 约 $0.1666 / 10k 次，平均 prompt tokens 227.0，completion tokens 7.3

qwen3-vl-plus — 约 $0.3848 / 10k 次，平均 prompt tokens 176.0，completion tokens 9.3

gpt-4.1-mini — 约 $0.5226 / 10k 次，平均 prompt tokens 159.0，completion tokens 10.5

gemini-2.5-flash-lite — 约 $0.5466 / 10k 次，平均 prompt tokens 970.5，completion tokens 5.8

gemini-2.5-flash — 约 $0.6168 / 10k 次，平均 prompt tokens 68.8，completion tokens 73.5

注意：这个成本估算是基于本轮 logo 识别任务，不等于所有图片任务的真实成本。更复杂的文档截图、OCR、长描述输出会改变 token usage。

不过它能说明一个生产选型原则：不要只看模型单价，要看 cost per successful image。

如果便宜模型需要频繁 fallback 或人工复核，最终未必便宜。反过来，如果任务足够简单，便宜模型 6/6 正确，就没必要每次都走更贵模型。

6 个模型怎么选？

1. gpt-4.1-mini：实时交互优先

适合：

用户上传图片后立即返回结果；

客服截图分析；

chat app 里的图片理解；

Тест 6 Vision API моделей: Gemini 2.5, GPT-4.1 и Qwen3 VL для понимания изображений

Если вы добавляете image understanding в продукт, формулировки вроде «модель поддерживает изображения» недостаточно.

Страница модели может обещать vision input, но production route всё равно должен ответить на более практичные вопросы:

Доходит ли OpenAI-compatible payload с image_url до модели?

Означает ли HTTP 200, что модель действительно увидела изображение?

Какая модель достаточно быстрая для user-facing image uploads?

Какая модель достаточно дешёвая для bulk image classification?

Какую модель использовать как fallback?

Можно ли по usage metadata заметить сломанный media path?

Чтобы сравнение было ближе к реальной разработке, я протестировал шесть vision-capable моделей через один и тот же OpenAI-compatible API формат:

gemini-2.5-flash

gemini-2.5-flash-lite

gpt-4.1-mini

gpt-4.1-nano

qwen3-vl-flash

qwen3-vl-plus

Цель — не найти «абсолютного победителя». Более полезный вопрос звучит так: какую модель стоит выбрать для конкретного пользовательского workflow?

Как проводился тест

Все запросы шли через Crazyrouter OpenAI-compatible Base URL:

https://cn.crazyrouter.com/v1

Формат запроса — chat/completions; изображение передавалось через messages[].content[] как объект image_url.

Для теста использовались две стабильные публичные картинки:

Python logo

GitHub logo

Каждое изображение запускалось по 3 раза на каждой модели. Итого — 6 запросов на модель.

Время теста: 2026-06-21T13:36:32Z.

Это vision API smoke test. Он помогает проверить, работает ли маршрут image_url, и способна ли модель выполнить простое визуальное распознавание. Это не полноценный benchmark для OCR, chart reasoning, document extraction, handwriting или medical images.

Короткая рекомендация

По результатам этого запуска:

Real-time user uploads / минимальная latency: gpt-4.1-mini

Bulk logo, icon или простая image classification: qwen3-vl-flash

Низкобюджетный Gemini route: gemini-2.5-flash-lite

Низкобюджетный OpenAI-family route: gpt-4.1-nano

Qwen VL route с приоритетом качества: qwen3-vl-plus как upgrade path

Не использовать как default image_url vision route в этом запуске: gemini-2.5-flash

Самый важный вывод:

HTTP 200 не доказывает, что понимание изображения сработало.

В этом тесте gemini-2.5-flash вернул HTTP success во всех 6 запросах, но visual recognition score был 0/6. В ответах встречались “no image provided”, неправильное распознавание CBC logo и нерелевантные описания объектов.

Это опасный failure mode: API call выглядит успешным, но модель не обработала изображение корректно.

Общая таблица результатов

МодельHTTP successCorrect recognitionNo-image repliesAvg latencyMedian latencySlowest requestInput price / 1M tokensOutput price / 1M tokensEstimated cost / 10k test-style callsПозиционированиеqwen3-vl-flash6/66/603.819s3.493s5.975s$0.05$0.40$0.0915Лучший low-cost route для bulk recognitiongpt-4.1-mini6/66/601.491s1.292s2.189s$0.26$1.04$0.5226Лучший low-latency route для user-facing функцийgpt-4.1-nano6/66/602.863s2.562s4.213s$0.065$0.26$0.1666Низкобюджетный OpenAI-family routeqwen3-vl-plus6/66/603.859s3.729s4.821s$0.1429$1.4286$0.3848Qwen VL upgrade route с приоритетом качестваgemini-2.5-flash6/60/614.965s4.333s9.507s$0.17$0.68$0.6168image_url path не сработал в этом запускеgemini-2.5-flash-lite6/66/602.618s2.627s4.195s$0.055$0.22$0.5466Низкобюджетный Gemini lightweight route

Оценка стоимости 10k calls основана на observed usage в этом простом logo recognition тесте. Это не универсальная цена для всех image workloads. Более крупные изображения, OCR, длинные описания и multi-image prompts могут сильно изменить token usage.

Практическая production-метрика — это не просто цена модели. Это cost per successful image task.

Дешёвый route, который часто требует retry или fallback, может оказаться дороже более надёжного route.

Accuracy: пять моделей прошли, одна провалилась

Correct recognition в smoke test:

qwen3-vl-flash: 6/6

gpt-4.1-mini: 6/6

gpt-4.1-nano: 6/6

qwen3-vl-plus: 6/6

gemini-2.5-flash-lite: 6/6

gemini-2.5-flash: 0/6

Для простого logo и icon recognition пять из шести маршрутов сработали корректно. Это означает, что для базовой image classification часто достаточно lightweight models.

Но gemini-2.5-flash — важный предупреждающий пример: HTTP success не означает, что image path здоров.

Latency: GPT-4.1 Mini оказался самым быстрым

Average latency от меньшей к большей:

gpt-4.1-mini: avg 1.491s, median 1.292s, slowest 2.189s

gemini-2.5-flash-lite: avg 2.618s, median 2.627s, slowest 4.195s

gpt-4.1-nano: avg 2.863s, median 2.562s, slowest 4.213s

qwen3-vl-flash: avg 3.819s, median 3.493s, slowest 5.975s

qwen3-vl-plus: avg 3.859s, median 3.729s, slowest 4.821s

gemini-2.5-flash: avg 4.965s, median 4.333s, slowest 9.507s

Для user-facing функций latency — часть качества продукта. Если пользователь загружает изображение и ждёт ответа, разница в одну-две секунды заметна.

Для таких workflow gpt-4.1-mini — самый сильный default route в этом запуске.

6 Vision API Models Tested: Gemini 2.5, GPT-4.1, and Qwen3 VL for Image Understanding

If you are building image understanding into a product, the phrase “supports images” is not enough.

A model page can say that a model supports vision input, but your production route still has to answer harder questions:

Does the OpenAI-compatible image_url payload actually reach the model?

Does HTTP 200 mean the model really saw the image?

Which route is fast enough for user-facing image uploads?

Which route is cheap enough for bulk image classification?

Which route should be used as fallback when the first model fails?

Can usage metadata reveal a broken media path?

To make the comparison more practical, I tested six vision-capable models through the same OpenAI-compatible API shape:

gemini-2.5-flash

gemini-2.5-flash-lite

gpt-4.1-mini

gpt-4.1-nano

qwen3-vl-flash

qwen3-vl-plus

The goal is not to crown a universal winner. The useful question is: which model should you route to for a specific user workflow?

Test setup

All tests used the Crazyrouter OpenAI-compatible Base URL:

https://cn.crazyrouter.com/v1

The request format was chat/completions, with the image passed through messages[].content[] as an image_url object.

Each model was tested on two stable public images:

Python logo

GitHub logo

Each image was run three times per model, so every model had six requests in total.

Test time: 2026-06-21T13:36:32Z.

This is a vision API smoke test. It is useful for checking whether the image_url route works and whether the model can perform simple visual recognition. It is not a full OCR, chart reasoning, document extraction, handwriting, or medical-image benchmark.

Quick recommendation

Based on this run:

Real-time user uploads / lowest latency: use gpt-4.1-mini

Bulk logo, icon, or simple image classification: use qwen3-vl-flash

Low-cost Gemini route: consider gemini-2.5-flash-lite

Low-cost OpenAI-family route: consider gpt-4.1-nano

Quality-oriented Qwen VL route: use qwen3-vl-plus as an upgrade path

Do not use as default image_url vision route in this run: gemini-2.5-flash

The most important finding is simple:

HTTP 200 does not prove image understanding succeeded.

In this test, gemini-2.5-flash returned HTTP success for all six requests, but the visual recognition score was 0/6. It also produced outputs such as “no image provided,” incorrect CBC logo recognition, and unrelated object descriptions.

That is the dangerous failure mode: the API call appears successful, but the model did not correctly process the image.

Overall results

ModelHTTP successCorrect recognitionNo-image repliesAvg latencyMedian latencySlowest requestInput price / 1M tokensOutput price / 1M tokensEstimated cost / 10k test-style callsPositioningqwen3-vl-flash6/66/603.819s3.493s5.975s$0.05$0.40$0.0915Best low-cost route for bulk recognitiongpt-4.1-mini6/66/601.491s1.292s2.189s$0.26$1.04$0.5226Best low-latency route for user-facing featuresgpt-4.1-nano6/66/602.863s2.562s4.213s$0.065$0.26$0.1666Low-cost OpenAI-family routeqwen3-vl-plus6/66/603.859s3.729s4.821s$0.1429$1.4286$0.3848Quality-oriented Qwen VL upgrade routegemini-2.5-flash6/60/614.965s4.333s9.507s$0.17$0.68$0.6168image_url path failed in this rungemini-2.5-flash-lite6/66/602.618s2.627s4.195s$0.055$0.22$0.5466Low-cost Gemini lightweight route

The estimated 10k-call cost is based on observed usage in this simple logo recognition test. It should not be treated as universal pricing for all image workloads. Larger images, OCR tasks, long descriptions, and multi-image prompts can change token usage significantly.

The useful production metric is not just model price. It is cost per successful image task.

A cheap route that frequently needs retries or fallback can be more expensive than a more reliable route.

Accuracy: five models passed, one model failed

Correct recognition in this smoke test:

qwen3-vl-flash: 6/6

gpt-4.1-mini: 6/6

gpt-4.1-nano: 6/6

qwen3-vl-plus: 6/6

gemini-2.5-flash-lite: 6/6

gemini-2.5-flash: 0/6

For simple logo and icon recognition, five of the six routes worked correctly. This means many lightweight models are already enough for basic image classification.

But gemini-2.5-flash is the important cautionary example: HTTP success does not mean the image path is healthy.

Latency: GPT-4.1 Mini was the fastest

Average latency from lowest to highest:

gpt-4.1-mini: avg 1.491s, median 1.292s, slowest 2.189s

gemini-2.5-flash-lite: avg 2.618s, median 2.627s, slowest 4.195s

gpt-4.1-nano: avg 2.863s, median 2.562s, slowest 4.213s

qwen3-vl-flash: avg 3.819s, median 3.493s, slowest 5.975s

qwen3-vl-plus: avg 3.859s, median 3.729s, slowest 4.821s

gemini-2.5-flash: avg 4.965s, median 4.333s, slowest 9.507s

For user-facing features, latency is part of product quality. If the user uploads an image and waits for a response, one or two seconds can matter.

For those workflows, gpt-4.1-mini is the strongest default route in this run.

【深層学習リンク】Vision API – 機械学習による画像認識, OCR  |  Google Cloud Platform

Cloud Vision API は、強力な機械学習モデルの能力を活用し、画像認識、 OCR, コンテンツ検知、顔や表情、ロゴやランドマーク検知を行います。

情報源: Vision API – 機械学習による画像認識, OCR  |  Google Cloud Platform

Vision API – 機械学習による画像認識, OCR | Google Cloud Platform スポンサー

ゲーム開発が変わる！Google Cloud Platform 実践インフラ構築 価格：2160円（税込、送料無料)