多模态请求图片变大后为什么失败：base64 体积、token 预算与压缩顺序

多模态请求“小图能发，大图就失败”，通常不是图片突然失效，而是同一份内容在请求链路里经历了三次变大：原始字节先被编码成 base64，文本载荷又占用上下文预算，服务端还可能按图片尺寸计算视觉 token。排查时要把这三层拆开，先看字节，再看编码后的请求体，最后对照所用模型的官方限制。

先压缩到业务仍可辨认的尺寸，再测 base64 后的请求体和 token 估算；不要只看图片文件在磁盘上的大小。

失败现场：同一张图为什么换个尺寸就不行

线上日志里最容易误导人的一行，是“文件大小只有几 MB”。这只说明磁盘上的 JPEG 或 PNG 多大，不代表 HTTP 请求中的 data URL、多轮消息文本以及模型侧视觉输入有多大。尤其是 PNG，像素尺寸很高但画面看起来并不复杂，压缩器未必能把它压到合适范围。

先把 imageBytes、base64Data 和 estimateTokens 分开测

不要在一个异常处理器里只打印“请求失败”。下面的最小示例把三个观测点保留下来。estimateTokens 是应用侧估算函数，不代表具体模型的官方计费或限制算法；它的价值是让压缩前后有可比的相对结果。

function inspectImage(imageBytes, mimeType, prompt) {
  const base64Data = imageBytes.toString('base64');
  const dataUrl = `data:${mimeType};base64,${base64Data}`;
  const estimateTokens = estimateVisionTokens(imageBytes.length, prompt.length);

  return {
    imageBytes: imageBytes.length,
    base64Chars: base64Data.length,
    dataUrlChars: dataUrl.length,
    estimateTokens
  };
}

这里先记录长度，再决定是否压缩。若日志只保留 HTTP 400，就无法判断是 base64 膨胀还是模型输入预算不足。日志中不要打印完整 data URL，它可能很长，也可能把用户图片内容带进日志系统。

压缩顺序决定了请求能否稳定复现

处理顺序建议固定成：读取原图字节，检查像素尺寸，按最长边缩放，选择适合内容的 JPEG 或 WebP 质量，再编码成 base64，最后组装请求。先把 base64 塞进 JSON 再临时压缩，既浪费内存，也很难定位是哪一层超限。

async function buildRequest(imageBytes, mimeType, prompt) {
  const resizedBytes = await resizeForModel(imageBytes, { maxEdge: 1600 });
  const base64Data = resizedBytes.toString('base64');
  const estimateTokens = estimateVisionTokens(resizedBytes.length, prompt.length);

  if (estimateTokens > 12000) {
    throw new Error('image input budget exceeded');
  }

  return {
    input: [{
      type: 'image_url',
      image_url: { url: `data:${mimeType};base64,${base64Data}` }
    }, { type: 'text', text: prompt }]
  };
}

示例里的 1600 和 12000 是演示用阈值，不是所有模型都适用。真正上线前，应把它们放进配置，并依据目标模型的官方文档调整。阈值触发后，优先降低最长边或质量；如果图片包含小字，不能只追求体积，还要做一次识别结果抽样。

三类报错对应三条处理路径

请求体被网关拒绝，先查 data URL 和 JSON 字符串长度；服务端返回上下文超限，重点看图片尺寸、文字 prompt 与历史对话是否一起进入模型；图片可发送但识别质量明显下降，则检查缩放是否抹掉了文字和细线。三者可以同时发生，但修复顺序不能混在一起。

• 载荷过大：在进入 HTTP 客户端前记录 base64Data.length，并对不同 MIME 类型做对比。
• 预算不足：缩短无关 prompt，减少历史消息，再按模型官方规则核对视觉输入。
• 质量下降：给票据、表格和截图保留更高分辨率，必要时分区域裁剪，而不是盲目降低质量。

常见问题：压缩后仍失败该看哪里

只改 JPEG quality 就够了吗？

不一定。像素尺寸、编码格式、base64 长度和文本上下文都可能是瓶颈，先保留四项观测值再改参数。

可以直接把图片 URL 交给模型吗？

是否支持取决于具体接口和模型。若使用 URL，仍要验证可访问性、权限、响应 MIME 类型和服务端对远程图片的限制。

为什么本地测试成功，线上却失败？

线上可能追加了历史消息、网关大小限制或不同的模型配置。把 buildRequest 的最终字段长度和模型标识记录下来，才能做同条件复现。

上线前留一份可复现检查单

每次请求至少保存图片 MIME 类型、像素尺寸、imageBytes、base64Data.length、prompt 长度、estimateTokens 和最终模型配置。不要保存完整图片或 data URL。这样即使服务端只返回一个笼统的请求错误，也能先判断问题落在文件、编码还是模型输入层。