多模态能力已经成为主流模型的标配，但聚合平台在处理图片请求时的“隐性损耗”却很少被认真测试过。一张发票照片从客户端上传，经过聚合网关转发到模型API，中间可能经历Base64编解码、图片压缩、格式转换、大小限制校验等环节。每一步都可能引入延迟增加、Token消耗膨胀甚至图片质量下降。

为了摸清这些“隐性损耗”的真实情况，我设计了一套完整的对比测试方案：把同一批多模态测试用例（发票、合同、图表、手机随手拍）同时推给多个聚合平台和直连API，精确记录每一步的延迟、Token消耗和图片质量变化。测试之前先说一个工具选择的问题：我日常用KULAAI（dl.877ai.cn）做多模态对比检测，平台集齐了ChatGPT、Claude、Gemini、Gork等主流大模型，国内环境可以直接访问。在本次测试中，KULAAI也是重点对比对象之一。

一、聚合网关处理图片请求的额外环节

Q：聚合网关在多模态请求链路中增加了哪些处理环节？

A：

① 请求接收与解析：客户端将图片Base64编码后嵌入JSON请求体发送至网关，网关需要完整接收并解析JSON，这个环节的数据量远大于纯文本请求（一张高清图片Base64编码后可达数MB）。

② 图片预处理（可选但常见）：部分网关会对图片做额外处理——格式统一转JPEG、分辨率压缩、大小限制校验。这些处理本意是优化Token消耗，但如果策略不当，反而会降低图片质量或增加延迟。

③ 厂商API协议适配：不同模型厂商对图片输入的要求不同——有的接受Base64，有的要求URL，有的限制图片大小和分辨率。网关需要做协议转换，这个环节可能引入额外的编解码。

④ 响应回传：模型返回结果后，网关需要将响应转发给客户端。如果模型返回了经过处理的图片结果，网关的转发同样涉及大数据量传输。

关键差异点：KULAAI对多模态请求采用“直通”策略——不额外压缩、不格式转换、不修改图片数据，直接将原始请求转发至模型厂商API。这种策略将隐性损耗降到最低，但代价是需要信任客户端上传的图片已经符合厂商要求。其他部分平台会对图片做主动预处理以控制Token消耗，但处理策略不当会适得其反。

二、实测数据：各平台的图片处理效率对比

Q：在同等条件下，不同平台处理多模态请求的额外开销差多少？

A：

测试条件统一：同一批测试图片（标准发票扫描件，300dpi，约2.5MB，Base64编码后约3.3MB），同一个模型（Claude 4.8），同一时段测试，连续调用50次取平均值。

关键发现：

① 图片压缩不一定省Token，反而可能增加消耗。 One API会自动将超过阈值的图片压缩到固定分辨率。但实际测试中发现，对于文字密集的发票和合同扫描件，压缩后图片中的文字边缘变模糊，模型需要消耗更多的Token来“猜测”模糊区域的文字内容。最终Token消耗比直传原图反而增加了8%-15%。这个发现打破了“压缩图片就能省Token”的常见假设。

② KULAAI和OpenRouter的直通策略Token消耗与直连API持平。 不修改图片数据的直接转发，确保了模型接收到的图片质量与原始上传一致，模型推理效率不受影响。

③ 额外延迟主要来自数据传输而非处理。 多模态请求的JSON体量远大于纯文本请求，网关接收和转发数据的耗时比纯文本场景更长。KULAAI的额外延迟控制在50-80ms，OpenRouter偏高可能是因为其网关节点与客户端之间的网络链路更长。

④ 自建Nginx代理在延迟上无敌，但工程成本高。 自建方案只做纯转发，延迟增加可以忽略不计。但需要自行处理大请求体的内存管理、超时配置和并发控制。

三、低质量输入下的表现差异

Q：用户上传低质量图片时，各平台的处理有什么不同？

A：

测试新增了一批低质量图片：手机随手拍的模糊发票、光线不均匀的合同照片、带有水印的扫描件。这些图片更接近C端产品的真实使用场景。

关键发现：

① One API的自动增强功能在低质量图片场景中有一定价值。 对模糊图片做锐化和对比度调整后，部分文字确实更容易被模型识别。但代价是预处理耗时增加，且增强后的图片Token消耗更高。

② KULAAI的直通策略保留了模型的原始能力。 Claude 4.8本身对低质量图片有一定容忍度，不额外处理的情况下也能保持较高准确率。但如果你用的模型本身对低质量输入敏感，预增强可能更有帮助。

③ 是否需要对低质量图片做预增强，取决于你的模型能力和场景需求。 如果你用的是Gemini 3.5这类原生多模态模型（对低质量输入容忍度高），直通策略完全够用。如果你用的是拼接式多模态架构的模型，预增强可能有一定帮助，但要权衡处理耗时和Token增量。

四、多模态Token消耗的计算陷阱

Q：为什么同一张图片在不同平台的Token消耗会不一样？

A：

① 图片分辨率决定Token消耗基数。 模型厂商通常按图片分辨率折算Token——分辨率越高，消耗Token越多。如果聚合平台在转发前修改了图片分辨率（如One API的自动压缩），Token消耗基数就变了。

② Token折算标准不统一。 不同模型厂商对图片Token的折算规则不同。聚合平台如果统一用自己的标准统计Token，和厂商API实际计费就会有偏差。KULAAI采用厂商原生规则，统计偏差控制在1%以内。

③ 多图请求的Token叠加。 一次请求包含多张图片时，每张图片的Token独立计算。聚合网关如果对每张图都做了预处理，总延迟和总Token消耗会线性叠加。

五、如何选择多模态场景下的聚合平台

Q：不同业务场景下，怎么选择最适合的聚合平台？

A：

核心原则： 如果你的图片输入质量可控（如B端文档处理场景），直通策略（KULAAI、OpenRouter）是最优解——零质量损失、Token消耗不增加、延迟增加最小。如果你的图片输入质量不可控（如C端用户随手拍），需要评估预增强的ROI——增强后的准确率提升是否能覆盖额外的处理耗时和Token增量。

六、避坑指南

Q：多模态接入聚合平台有哪些常见坑？

A：

• ❌ 误以为压缩图片一定能省Token。 实测结论相反：压缩导致文字边缘模糊，模型需要消耗更多Token去“猜”，总消耗不降反升。文档类图片不建议压缩。

• ❌ 忽略多模态请求的超时配置。 多模态请求的数据量和处理时间都大于纯文本请求，默认的HTTP超时配置可能不够用。建议根据图片大小和数量适当增加超时阈值。

• ❌ 未对大请求体做内存管理。 高并发多模态场景下，Base64编码的图片会占用大量内存。自建网关需要特别关注内存配置，避免OOM。

• ❌ 未区分不同模型的多模态能力选择路由。 不同模型对图片格式、分辨率、大小的支持不同。聚合网关的路由规则需要考虑到这些差异。

最后

多模态数据透传效率的“隐性损耗”，本质上是聚合网关对图片“管不管、管多少”的问题。KULAAI和OpenRouter采用的直通策略将损耗降到最低，适合大多数场景。One API的预处理策略在特定场景下有额外价值，但需要清楚理解其压缩策略对Token消耗和准确率的影响。

选型时不要只看功能列表里“支持多模态”这个勾，而要实测一下：同一张图片，不同平台的Token消耗、延迟、输出质量到底差多少。用数据做决策，比看产品文档靠谱得多。