多模态 AI API 图片与文件怎么传？上传、压缩和安全处理指南

给 AI API 传图片、PDF 或音频，看起来只是把文本请求多加一个字段，真正上线后却常遇到请求体过大、临时链接失效、格式兼容、重复上传、隐私泄露和异步超时。尤其经过 AI API 中转站时，应用、对象存储、中转层与上游模型之间多了一段链路，任何一层的限制不同都可能导致失败。

与其围绕某个模型写死参数，更稳妥的做法是建立独立的“多模态输入管线”：先接收和验证文件，再标准化、存储与授权，最后转换成目标供应商需要的请求格式。

三种常见传输方式怎么选

1. 公网 URL

应用把文件放到对象存储，再把 URL 交给模型服务拉取。优点是 API 请求体小，适合较大文件；缺点是上游必须能访问该地址，还要处理链接有效期、重定向和下载超时。

不要把存储桶设为永久公开。应使用短期签名 URL，并确保有效期覆盖排队与重试时间。链接过短会让首次请求成功、重试却失败；过长则扩大泄露窗口。

2. Base64 内嵌

文件编码后直接放进 JSON，部署简单，也不要求上游访问你的存储。但编码会扩大请求体，网关、Serverless 平台和中转站都可能存在各自的正文上限。它更适合小图片或内部工具，不适合不受控的大文件。

3. 供应商文件 ID

先上传到文件接口，获得 ID，再在推理请求中引用。它适合重复分析同一个文件，但要管理上传状态、归属、过期和删除。中转站是否完整代理上传与删除接口，需要单独做兼容性验收，不能因为聊天接口可用就默认文件接口也可用。

上传后先验证，不能只看扩展名

用户把可执行文件改名为 .jpg 并不会变成图片。服务端至少要检查文件头、实际 MIME、大小、像素或页数，并拒绝不支持的容器。图片解码库和文档解析器应在隔离环境运行，设置 CPU、内存与处理时限，防止压缩炸弹和畸形文件拖垮服务。

type Upload = {
  bytes: Uint8Array;
  declaredMime: string;
  ownerId: string;
};

async function prepare(upload: Upload) {
  const detected = await detectMime(upload.bytes);
  if (!ALLOWED_MIME.has(detected)) throw new Error("unsupported_file");
  if (upload.bytes.byteLength > MAX_UPLOAD_BYTES) throw new Error("file_too_large");

  const normalized = await normalizeInSandbox(upload.bytes, detected);
  const objectKey = await storePrivate(normalized, upload.ownerId);
  return createShortLivedReadUrl(objectKey);
}

常量值应根据自己的入口、候选中转站和模型上游中最严格的限制配置，并通过测试确认，不要从网上抄一个数字当作永久事实。

标准化能减少兼容性问题

手机照片可能带旋转信息、超大分辨率、透明通道和拍摄元数据。文档也可能混有扫描页、空白页和嵌入附件。进入模型前可按业务需要执行：纠正方向、限制尺寸、转换受支持格式、去除无关元数据、生成缩略图，并保留原文件的受控副本。

“压得越小越好”并不正确。票据小字、图表坐标、代码截图等任务对清晰度敏感。建议按任务建立质量档位，并用自己的样本比较答案准确性、上传耗时和成本，而不是统一缩图。

文件身份要与用户身份绑定

不要接受前端任意提交的对象存储路径。数据库应记录 file_id、所有者、租户、对象键、哈希、状态和过期时间；推理前再次检查当前用户是否有权访问。签名 URL 只是临时访问手段，不是业务授权。

同一文件重复上传时，可以用内容哈希做租户内去重，但不能跨租户暴露“这个文件已经存在”。删除操作需要同时覆盖原件、派生缩略图、解析文本、向量索引和缓存。

中转站接入的兼容性测试

对每个候选平台分别测试：URL 是否能被上游拉取、Base64 data URL 是否透传、请求体上限如何报错、文件 ID 生命周期是否完整、流式结果能否正常返回，以及日志是否记录了敏感 URL。模型列表中的“支持视觉”不代表所有文件传输方式都一致。

测试时使用无敏感内容的合成文件，并保存 request ID、状态码、错误结构与总耗时。不要用客户合同或身份证照片做连通性测试。

重试与幂等怎么设计

上传成功但推理超时，不应每次都创建新副本。为上传任务设置幂等键，先查询已有对象与状态，再决定续传或重建。异步文档解析应区分 uploaded、scanning、ready、failed 和 deleted，只有 ready 文件才能进入模型请求。

如果签名链接即将过期，重试前重新签发即可，不必复制对象。若用户取消任务，应终止仍在进行的解析，并安排清理无引用的临时文件。

隐私与日志清单

• 默认私有存储，使用短期最小权限链接
• 清理图片定位和设备等非必要元数据
• 文件名、URL 查询参数和解析文本不写普通访问日志
• 设置原件、派生物和模型结果的保留期限
• 明确中转商是否留存请求内容以及如何删除
• 对高敏数据使用经过批准的线路和区域策略

总结

多模态 API 的稳定性取决于完整输入管线，而不只是请求 JSON。先做真实格式校验和隔离解析，再按 URL、Base64 或文件 ID 的特点传输，同时管理授权、过期、重试与删除，才能避免“开发环境能用、生产随机失败”。接入前可在 openairouter.net 查看支持多模态模型的 AI API 中转站对比与排行榜，再用本文清单验证文件链路。