视觉后端最多吃几张图：在一把 key 上探测多图输入的静默丢弃点
本文介绍如何通过实验探测不同视觉模型后端对多图输入数组长度的实际容纳上限，并识别超出限制时静默丢弃图片的临界点。内容涵盖探测方法、常见行为模式和工程应对策略，帮助开发者避免因图片被静默丢弃导致的输出偏差。
为什么需要关心多图输入的静默丢弃
当一次请求传入多张图片时，不同视觉后端对图片数组长度的处理策略并不一致。部分后端在图片数量超过内部上限时，不会返回错误码，而是直接丢弃多余的图片，继续处理剩余部分。这种静默丢弃会导致模型看到的上下文与预期不符，输出结果可能基于不完整的信息，且难以从响应中察觉。
在聚合站场景下，同一个 API key 可以调用多个后端模型，各后端的丢弃行为可能不同。因此，在正式业务中使用多图输入前，有必要逐个后端探测其实际容纳上限，并确认超出时的行为是报错还是静默截断。
探测的基本思路
探测的核心是构造一组图片数量递增的请求，观察模型响应是否随图片数量变化而出现异常。具体步骤如下：
- 准备可区分的测试图片：每张图片包含一个唯一且易于识别的标记（例如不同的数字或图案）。这样可以通过模型回答判断它实际看到了哪些图片。
- 设计提问方式：要求模型列出它看到的所有标记，或回答与最后一张图片相关的问题。如果最后几张图片被丢弃，模型的回答会缺少对应标记。
- 逐步增加图片数量：从较少的数量开始，每次增加一张，直到出现以下任一情况：请求报错、模型回答缺失部分标记、或响应时间/计费出现明显变化。
- 重复验证：对每个后端至少重复两到三次，排除偶发因素。
常见行为模式
根据探测经验，视觉后端对多图输入的处理大致有以下几种模式：
- 显式报错：图片数量超过上限时返回明确的错误信息，这是最安全的行为。
- 静默丢弃头部或尾部：后端只保留前 N 张或后 N 张图片，其余直接忽略，响应正常但内容缺失。
- 按 token 预算截断：后端根据总 token 预算决定能容纳多少张图片，图片尺寸和复杂度会影响实际上限。
- 全部接受但质量下降：图片数量过多时模型注意力分散，回答质量下降，但不会明确提示。
需要注意的是，同一后端在不同模型版本或不同输入尺寸下，上限可能变化。探测结果应视为当前配置下的经验值，而非固定常量。
如何判断发生了静默丢弃
静默丢弃不会体现在 HTTP 状态码或错误字段中，需要从响应内容推断：
- 模型回答中缺少某张测试图片的唯一标记。
- 当提问指向最后一张图片时，模型回答与图片内容无关或表示未看到。
- 对比减少图片数量后的回答，发现信息量反而更完整。
- 响应中的用量统计（如图片 token 数）与传入图片数量不成比例。
建议在探测脚本中自动比对模型回答与预期标记集合，一旦发现缺失即记录当前图片数量为疑似临界点。
工程上的应对策略
确认各后端的静默丢弃点后，可以采取以下措施：
- 在应用层做前置校验：根据探测结果设置每个后端的图片数量上限，超出时主动拆分请求或提示用户。
- 优先选择显式报错的后端：对于多图输入场景，优先使用超出限制会报错的后端，便于及时发现和降级。
- 合并图片：将多张图片拼接为一张大图，绕过数组长度限制，但需注意分辨率和 token 消耗的变化。
- 记录探测结果：将各后端的实际上限和丢弃行为写入配置或文档，随模型版本更新定期复测。
在聚合站上探测的注意事项
使用一个 API key 调用多个后端时，探测请求会分别路由到不同模型。建议在请求中明确指定目标模型，并分别记录结果。同时注意，聚合站的计费按官方价乘以系数扣除，探测多图请求会消耗相应额度，应控制探测规模。由于聚合站不要求 KYC，可以用 Base 上的 USDC 充值后直接开始小规模探测，无需等待审核。
探测完成后，将各后端的临界点整理成表，作为后续业务代码中图片数量校验的依据，可以有效避免因静默丢弃导致的输出偏差。