> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apiyi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 识图请求一直超时，是图片太大了吗？

> GPT 识图时一直无响应、返回 429 负载饱和或 400 patches 超限，多半是单张图片像素过大。说明各线路的上限、判断方法和缩图代码。

## 简短回答

很可能是。GPT 系列识图按 32×32 像素的图块计算，图片越大，图块越多。单张图超过约 **3000 万像素**（例如 6700×4500）时，部分线路会直接拒绝；超过约 **6000 万像素**时，高峰期往往会**排队几分钟后才拒绝**，客户端先等到超时，看上去就像「一直没响应」。

这类失败是确定性的，**重试、换 Key 都不会成功**。上传前把图片长边缩到 2048 像素左右即可，识别效果不变，输入 tokens 还会降到原来的几十分之一。

## 三种典型现象

同一张超大图，在不同线路、不同时段，表现可能是下面任意一种：

| 你看到的现象 | 报错关键词 | 说明 |
| - | - | - |
| 请求一直没有响应，最终客户端超时或连接被断开 | 无（客户端只看到 timeout） | 原厂在高峰期先排队，约 5 分钟后才拒绝，客户端已经先断开 |
| `429` 当前分组上游负载已饱和 | `exceeds the maximum usage size allowed during peak load` | 单个请求的用量超过高峰期允许的上限，不是并发限流 |
| `400` 图片超限 | `requires 67081 patches after processing, exceeding the limit of 30000` | 单张图处理后的图块数超过上限，需要缩图 |

> [!WARNING]
>
> 看到 `429` 不要马上加大重试。先看报错正文：如果是 `maximum usage size` 或 `patches`，问题出在请求本身太大，重试只会继续占用并发、继续等待。

## 实测：图片尺寸与结果

2026-10-20 用 `gpt-6.1-sol` 测了同一张图的不同尺寸（JPEG，通过 OpenAI 兼容 chat 的 `image_url` 以 Base64 上传）：

| 图片尺寸 | 像素 | 请求体 | 结果 | 耗时 | 输入 tokens |
| - | - | - | - | - | - |
| 2048×1365 | 280 万 | 0.75 MB | 成功，文字全部识别正确 | 6 秒 | 3,321 |
| 4096×2731 | 1120 万 | 2.9 MB | 成功 | 10 秒 | 13,228 |
| 6000×4000 | 2400 万 | 6.2 MB | 成功 | 20 秒 | 28,219 |
| 7200×4800 | 3460 万 | 8.8 MB | 成功 | 26 秒 | 40,519 |
| 9000×6000 | 5400 万 | 13.7 MB | 成功 | 40 秒 | 63,638 |
| 10240×6827 | 7000 万 | 17.7 MB | **无响应，约 300 秒后连接被断开** | — | — |

从结果可以看出：

* **tokens 随像素线性增长**，大约是「像素数 ÷ 1024 × 1.2」。9000×6000 的图比 2048 的图多花约 19 倍 tokens，识别结果却完全一样。
* **能不能通过，与线路和时段有关**。上表是在非高峰时段、单条线路上测得的；另一条线路对单图有 30000 图块（约 3000 万像素）的硬上限，高峰期的门槛也会更低。
* 所以**不要把「实测能过」当成安全上限**。识图场景把长边控制在 2048 像素就足够。

## 怎么判断是不是图片太大

**1. 看请求体大小**

Base64 编码会让体积膨胀约 1.33 倍。请求体达到几 MB 甚至十几 MB，基本可以判定图片没有缩放过。

**2. 看报错正文**

搜索 `patches`、`maximum usage size`、`image exceeds` 这几个关键词。命中任何一个，都是图片太大。

**3. 用缩小后的图对照**

把同一张图缩到长边 2048 再发一次。如果几秒内就返回，说明问题出在图片尺寸，而不是模型或网络。

## 解决方法：上传前缩放

```python theme={null}
import base64, io
from PIL import Image

def image_to_data_uri(path, max_side=2048, quality=85):
    img = Image.open(path)
    img = img.convert("RGB")                      # 统一转 RGB，兼容 PNG / MPO 等格式
    img.thumbnail((max_side, max_side))           # 等比缩放，长边不超过 max_side
    buf = io.BytesIO()
    img.save(buf, "JPEG", quality=quality)
    return "data:image/jpeg;base64," + base64.b64encode(buf.getvalue()).decode()
```

把返回值填进 `image_url.url` 即可。缩放后一张图通常只有几百 KB，几秒内就能返回。

> [!TIP]
>
> 需要识别极小的文字（例如整页扫描件里的脚注）时，与其上传一张超大原图，不如把页面**裁成几块**分别上传，或者先裁出需要识别的区域。这样每张图都在安全范围内，识别效果反而更好。

## 常见问题

> **为什么别人用同一个模型都正常？**
>
> 多数人上传的是截图或手机照片，缩放后只有几百万像素。只有上传几千万像素的原图时，才会触发单请求用量上限，所以同一时段其他人不受影响。

> **这类失败会扣费吗？**
>
> 被原厂拒绝的请求（`429`、`400`）不会产生消费记录，可以在调用日志里确认。

> **把客户端超时调长能解决吗？**
>
> 不能。超时调长只是等到原厂返回拒绝，最终结果还是失败。正确做法是缩图。

> **Claude、Gemini 等其他模型也有限制吗？**
>
> 有，只是规则不同：Claude 单图超过 10MB 直接拒绝（同样返回 `429`），Kimi 单图超过 16384 tokens 报错，Seed 总像素上限为 3600 万，Gemini 会自动缩小。详见[图像理解](/api-capabilities/vision-understanding)的「大图先缩放」一节。

## 相关文档

> **[图像理解](/api-capabilities/vision-understanding)**
>
> 各模型识图写法、大图处理与实测结果

> **[模型调用报错怎么排查？](/faq/model-error-troubleshooting)**
>
> 按错误类型定位问题

> **[如何避免接口超时？](/faq/timeout-configuration)**
>
> 配置 timeout 与长请求排查

> **[API 可以开多少并发？](/faq/api-concurrency)**
>
> 区分真正的并发限流与其他 429


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.