> ## 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 會自動縮小。詳見[影像理解](/zh-Hant/api-capabilities/vision-understanding)的「大圖先縮放」一節。

## 相關文件

> **[影像理解](/zh-Hant/api-capabilities/vision-understanding)**
>
> 各模型識圖寫法、大圖處理與實測結果

> **[模型呼叫報錯怎麼排查？](/zh-Hant/faq/model-error-troubleshooting)**
>
> 按錯誤型別定位問題

> **[如何避免介面超時？](/zh-Hant/faq/timeout-configuration)**
>
> 配置 timeout 與長請求排查

> **[API 可以開多少併發？](/zh-Hant/faq/api-concurrency)**
>
> 區分真正的併發限流與其他 429


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