图像输入用 base64 还是 URL：聚合站上各后端接受的编码方式对照

在调用支持视觉能力的模型时，图像输入有两种常见方式：将图像编码为 base64 data URI 直接嵌入请求，或提供可公开访问的外链 URL。不同模型后端对这两种方式的接受程度并不一致，选择不当可能导致请求失败或产生额外开销。

两种编码方式的基本概念

• base64 data URI：把图像二进制数据编码为 base64 字符串，并以 data:image/jpeg;base64,... 的形式内联在消息内容中。这种方式不依赖外部可访问性，但会显著增大请求体体积。
• 外链 URL：提供一个 HTTP/HTTPS 链接，由模型服务端自行抓取图像。请求体小，但要求链接公网可访问且稳定。

聚合站统一了 API 入口，但底层仍调用各模型厂商的原生接口，因此各后端对图像输入格式的支持情况需要分别看待。

六个后端的支持情况对照

以下基于各后端公开的 API 文档整理，实际行为可能随版本更新而变化，建议以官方文档为准。

| 后端 | base64 data URI | 外链 URL | 备注 |
| --- | --- | --- | --- |
| Claude | 支持 | 支持 | 两种方式均可，URL 需可公开访问 |
| GPT | 支持 | 支持 | 两种方式均可，URL 需可公开访问 |
| DeepSeek | 视模型而定 | 视模型而定 | 仅部分视觉模型支持图像输入 |
| Qwen | 支持 | 支持 | 视觉模型通常两种方式都接受 |
| GLM | 支持 | 支持 | 视觉模型通常两种方式都接受 |
| Kimi | 支持 | 支持 | 视觉模型通常两种方式都接受 |

注意：上表为一般性对照。具体模型是否支持视觉输入、支持哪种编码方式，请查阅对应后端的官方文档。聚合站不会改变后端本身的能力边界。

载荷体积对 token 花费的影响

base64 编码会使图像数据膨胀约 33%，再叠加 JSON 转义等开销，请求体可能达到原图大小的 1.3 倍以上。这带来两个层面的影响：

1. 请求传输开销：更大的请求体需要更长的上传时间，在弱网环境下更明显。聚合站按官方价 ×1.3 扣费，计费基于后端返回的 token 用量，而非请求体字节数，因此 base64 本身不会直接增加 token 费用。
2. 图像 token 化方式：后端通常将图像切分为图块（tile）或按分辨率折算为 token。base64 与 URL 只是传输方式，最终图像 token 数由后端的分辨率处理策略决定。但需注意，部分后端在通过 URL 抓取图像时可能进行额外压缩或缩放，间接影响 token 数。

因此，从费用角度看，两种方式在 token 计费上通常等价，差异主要体现在传输可靠性和后端兼容性上。

如何选择编码方式

• 优先使用外链 URL：当图像已有稳定的公网地址（如对象存储、CDN），且后端支持 URL 输入时，URL 方式请求体小、传输快，是更轻量的选择。
• 使用 base64 的场景：图像仅本地存在、无法公开访问，或后端不支持 URL 输入时，base64 是可靠的回退方案。
• 注意大小限制：无论哪种方式，都需遵守后端对单张图像大小和请求体总大小的限制。base64 会放大体积，更容易触达上限。
• 聚合站视角：由于聚合站按官方价 ×1.3 扣费，而贡献 key 按 ×1.1（优质 ×1.2）返 USDC，费用结构与编码方式无关。选择编码方式时，应优先考虑兼容性与稳定性，而非试图通过编码方式降低费用。

实践建议

1. 在开发阶段，先用小尺寸图像分别测试目标后端对 base64 和 URL 的接受情况，确认行为一致后再批量使用。
2. 对于生产环境，建议将图像上传至可公开访问的对象存储，使用 URL 方式减少请求体；同时保留 base64 回退路径以应对后端限制。
3. 监控请求失败率与延迟，若发现某后端对 URL 抓取不稳定，可切换为 base64。
4. 关注各后端官方文档的更新，图像输入格式的支持情况可能随模型版本变化。

通过理解各后端的编码方式差异与 token 计费逻辑，可以在聚合站上更高效地使用视觉模型，避免因格式不兼容导致的调试成本。