如果你在做图片理解、截图识别、logo 检测、图片分类、客服截图分析，或者给 agent workflow 接入视觉输入，模型选择不能只看“支持图片”四个字。
真正上线时，你至少要回答 6 个问题：
image_url 请求链路是否真的可用？这篇文章把前面 15 篇 pairwise benchmark 的结果综合起来，对 6 个模型做一次总览：
gemini-2.5-flashgemini-2.5-flash-litegpt-4.1-minigpt-4.1-nanoqwen3-vl-flashqwen3-vl-plus测试统一使用 Crazyrouter OpenAI-compatible Base URL：
请求格式是 OpenAI 兼容 chat/completions，图片通过 messages[].content[] 中的 image_url 传入。每个模型测试两张公开图片：Python logo 和 GitHub logo；每张图跑 3 次，所以每个模型共 6 次请求。
测试时间：
2026-06-21T13:36:32Z。这是实测 API 结果，不是官网参数搬运。
如果你只想快速选型：
gpt-4.1-miniqwen3-vl-flash 或 gemini-2.5-flash-litegpt-4.1-nanoqwen3-vl-plusgemini-2.5-flash最重要的一点：HTTP 200 不等于图片理解成功。本轮 gemini-2.5-flash 的请求全部返回成功，但图片识别正确率是 0/6，还出现了“未提供图片”、错识别 CBC logo、飞船等异常输出。
| 模型 | HTTP 成功 | 识图正确 | no-image 回复 | 平均延迟 | 中位延迟 | 最慢请求 | 输入价 / 1M tokens | 输出价 / 1M tokens | 10k 次测试式调用估算 | usage/image 信号 | 定位 |
|---|---|---|---|---|---|---|---|---|---|---|---|
qwen3-vl-flash | 6/6 | 6/6 | 0 | 3.819s | 3.493s | 5.975s | $0.05 | $0.4 | $0.0915 | 有 image_tokens 信号 | 低价批量识图首选，适合 logo、图标、简单截图分类 |
gpt-4.1-mini | 6/6 | 6/6 | 0 | 1.491s | 1.292s | 2.189s | $0.26 | $1.04 | $0.5226 | image_tokens 为 0/缺失，需 smoke test | 低延迟线上交互首选，适合用户实时上传图片 |
gpt-4.1-nano | 6/6 | 6/6 | 0 | 2.863s | 2.562s | 4.213s | $0.065 | $0.26 | $0.1666 | image_tokens 为 0/缺失，需 smoke test | 低成本 OpenAI 路线，适合轻量视觉标签和简单分类 |
qwen3-vl-plus | 6/6 | 6/6 | 0 | 3.859s | 3.729s | 4.821s | $0.1429 | $1.4286 | $0.3848 | image_tokens 为 0/缺失，需 smoke test | Qwen 质量优先路线，适合比 flash 更重的视觉理解 |
gemini-2.5-flash | 6/6 | 0/6 | 1 | 4.965s | 4.333s | 9.507s | $0.17 | $0.68 | $0.6168 | image_tokens 为 0/缺失，需 smoke test | 本轮 image_url 路径异常，不建议作为默认识图路由 |
gemini-2.5-flash-lite | 6/6 | 6/6 | 0 | 2.618s | 2.627s | 4.195s | $0.055 | $0.22 | $0.5466 | image_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.189sgemini-2.5-flash-lite — 平均 2.618s，中位 2.627s，最慢 4.195sgpt-4.1-nano — 平均 2.863s，中位 2.562s，最慢 4.213sqwen3-vl-flash — 平均 3.819s，中位 3.493s，最慢 5.975sqwen3-vl-plus — 平均 3.859s，中位 3.729s，最慢 4.821sgemini-2.5-flash — 平均 4.965s，中位 4.333s，最慢 9.507s如果是用户在线等待的功能，比如聊天窗口里上传图片、客服系统实时分析截图、agent 需要马上根据图片决策，速度优先级很高。本轮 gpt-4.1-mini 的平均延迟最低，是实时交互场景的强候选。
但速度不能脱离正确率。一个很快但没看到图片的路由没有意义。因此生产默认路由要同时看：
这里用本轮观测到的平均 prompt/completion tokens，粗略估算 10,000 次同类请求的成本。排序如下：
qwen3-vl-flash — 约 $0.0915 / 10k 次，平均 prompt tokens 111.0，completion tokens 9.0gpt-4.1-nano — 约 $0.1666 / 10k 次，平均 prompt tokens 227.0，completion tokens 7.3qwen3-vl-plus — 约 $0.3848 / 10k 次，平均 prompt tokens 176.0，completion tokens 9.3gpt-4.1-mini — 约 $0.5226 / 10k 次，平均 prompt tokens 159.0，completion tokens 10.5gemini-2.5-flash-lite — 约 $0.5466 / 10k 次，平均 prompt tokens 970.5，completion tokens 5.8gemini-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 正确，就没必要每次都走更贵模型。
gpt-4.1-mini：实时交互优先#适合：
本轮它的平均延迟最低，识图 6/6 正确。缺点是价格高于 nano 和部分 Qwen/Gemini 轻量路线。
我的建议：如果产品是“用户正在等结果”，gpt-4.1-mini 可以作为默认低延迟路线。
qwen3-vl-flash：批量低成本识图首选#适合：
本轮 qwen3-vl-flash 识图 6/6 正确，价格低，usage 里也能看到 image token 信号。它的延迟不如 gpt-4.1-mini，但在批处理场景中通常可以接受。
我的建议：如果你做的是高调用量、低复杂度的图片理解，优先考虑 qwen3-vl-flash。
gemini-2.5-flash-lite：低价 Gemini 路线#适合：
本轮 gemini-2.5-flash-lite 识图 6/6 正确，价格低。但 usage 里的 image token 信号不够直观，因此生产里必须保留视觉 smoke test，不要只看 HTTP status。
我的建议：可以作为低成本候选，但上线前要加监控，确认 image_url 链路持续正常。
gpt-4.1-nano：OpenAI 路线的低成本备选#适合：
本轮 gpt-4.1-nano 识图 6/6 正确，价格明显低于 gpt-4.1-mini，但延迟比 mini 高，复杂视觉推理能力也不应过度假设。
我的建议：适合作为简单任务的低成本路线，但复杂截图、文档理解、OCR 不要只靠它。
qwen3-vl-plus：Qwen 质量优先路线#适合：
本轮 qwen3-vl-plus 识图 6/6 正确，但延迟和输出价都更高。它不一定适合所有简单任务默认使用。
我的建议：不要拿 plus 做所有 logo 识别的默认路线；更适合 flash 不够用时升级。
gemini-2.5-flash：本轮不建议做默认 image_url 路由#这个模型最值得单独说。
本轮 gemini-2.5-flash：
这说明问题不一定是模型本身能力差，而可能是 image_url 适配、媒体转发、payload conversion 或上游路由链路存在问题。
我的建议：在当前这条 image_url 路径下，不要把 gemini-2.5-flash 作为生产默认识图路由。除非你已经用自己的图片 smoke test 验证链路恢复。
| 场景 | 推荐默认 | fallback | 原因 |
|---|---|---|---|
| 实时用户上传图片 | gpt-4.1-mini | qwen3-vl-flash / gemini-2.5-flash-lite | 低延迟优先，失败时切低成本可用路线 |
| 批量 logo / icon 识别 | qwen3-vl-flash | gpt-4.1-nano | 成本低，简单识图本轮 6/6 正确 |
| 简单截图分类 | qwen3-vl-flash / gpt-4.1-nano | gpt-4.1-mini | 先低成本，疑难样本升级 |
| 客服截图实时分析 | gpt-4.1-mini | qwen3-vl-plus | 用户等待场景，速度和稳定性优先 |
| OCR / 文档预筛选 | 需要单独测试 | qwen3-vl-plus / 更强 OCR 模型 | logo test 不能证明 OCR 质量 |
| Agent 视觉输入 | gpt-4.1-mini 或 qwen3-vl-flash | 强制 smoke test + fallback | agent 容易把错误视觉输入继续放大 |
| Gemini 路线低成本备选 | gemini-2.5-flash-lite | gpt-4.1-nano | Flash Lite 本轮正常，Flash 本轮异常 |
很多人做 Vision API benchmark 只看输出文字对不对。但在网关和生产系统里，usage metadata 也很重要。
如果一个请求返回 HTTP 200，但 prompt tokens 看起来只有文本 prompt 的量，或者 image token 字段为 0/缺失，而模型还说“没有提供图片”，这通常意味着：
这类问题在生产环境里必须被监控。否则你会以为模型质量差，但真正的问题可能是路由链路坏了。
一个实用的 Vision API routing 策略可以这样设计：
先按任务分层
每个视觉路由都做 smoke test
不要只按 HTTP status 判断健康
fallback 要有理由
记录 cost per successful image
代码里的 API endpoint 不加 UTM 参数。人看的链接才加 UTM，例如 Crazyrouter Pricing。
如果你现在要在 6 个模型里选默认路线，我会这样排：
gpt-4.1-miniqwen3-vl-flashgemini-2.5-flash-litegpt-4.1-nanoqwen3-vl-plusgemini-2.5-flash这不是说某个模型永远更好，而是说：vision model 选型必须围绕用户任务，而不是围绕模型名字。
对开发者来说，最靠谱的做法是：先用低成本路线处理简单任务，再用 smoke test、usage signals 和 fallback 机制兜底。这样才能同时控制成本、延迟和线上稳定性。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。