多模态请求体超限：token 与字节是两本账
文本正常、带图就失败——问题出在传输层的字节账上。
做多模态对话时遇到过一类奇怪的失败：文本请求一切正常，一旦附带截图就报请求体过大。第一反应是上下文窗口不够，查下来发现根本不是——网关是按 HTTP 请求体的字节数拒请求的，和 token 数量是两个维度。
数字对比说明问题
一张 0.9 MB 的 PNG 截图，编码进消息后是 base64 字符串，体积膨胀约三分之一，达到 1.2 MB 左右。而在模型的 token 记账里，这张图通常只值几百个 token。也就是说：
- 按 token 算：远远没到上限；
- 按字节算：单这一张图就可能顶满网关的请求体限制。
更糟的是多轮对话会把同一张图反复发出去——每一轮都要重新带上历史里的图片，字节数逐轮累加，直到某轮突然失败。
为什么阈值配置救不了
很多框架的压缩阈值是按 token 比例设的，比如"上下文占用超过 80% 才触发裁剪"。字节超限发生在传输层，请求根本没进到模型，这套压缩逻辑一次都不会执行。要在图片进入消息之前就把体积压下来。
实际有效的四招
一、转码 + 缩放。PNG 截图转 JPEG（质量 80 上下）通常能降一个数量级；长边限制在 1400 像素以内，绝大多数界面截图信息量不受影响。
二、超长图切块。整页截图的宽高比常常超过 3，直接缩放到长边 1400 会让文字糊掉。按原宽切成若干段分别编码，可读性反而更好。
三、文档别转图。PDF、Word、PPT 优先抽文本。同一份二十多页的文档，逐页转成图片是十几 MB，抽出纯文本只有几十 KB，差几百倍。只有确实需要看版式时才转图。
四、用完即弃。图片理解完成后，把消息里的图像数据换成一句文字摘要再保留在历史中，后续轮次不再携带原始字节。
顺手建立的预算意识
把限制显式写进流程会比事后救火省事：单轮最多带几张图、整个会话累计多少张、总字节不超过多少。超了就先看能不能用文字描述替代——大部分情况下，一张图想表达的东西，模型看完之后一句话就能概括出来。
token 是模型的账本，字节是网络的账本。两本账都要记，只看一本迟早翻车。