> ## 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 vision зависает, возвращает 429 upstream saturated или 400 patches exceeding the limit, скорее всего, изображение слишком большое. Лимиты для разных маршрутов, способы проверки и код для изменения размера.

## Краткий ответ

Скорее всего, да. Модели GPT обрабатывают изображения патчами размером 32×32 пикселя, поэтому чем больше изображение, тем больше патчей. Когда размер одного изображения превышает примерно **30 мегапикселей** (например, 6700×4500), некоторые маршруты отклоняют его сразу. При превышении примерно **60 мегапикселей** запрос в часы пик часто **ставится в очередь на несколько минут перед отклонением**, поэтому у вашего клиента сначала истекает время ожидания (тайм-аут) и кажется, что запрос «никогда не отвечает».

Эти сбои детерминированы: **повторные попытки или смена ключей API не помогут**. Измените размер изображения перед загрузкой так, чтобы его длинная сторона составляла около 2048 пикселей. Качество распознавания останется прежним, а количество входных tokens сократится до небольшой доли от исходного.

## Три типичных симптома

Одно и то же изображение слишком большого размера может приводить к ошибке одним из следующих способов в зависимости от маршрута и времени суток:

| Что вы видите | Ключевое слово ошибки | Пояснение |
| - | - | - |
| Запрос не возвращает ответ; в итоге у клиента истекает таймаут или закрывается соединение | Отсутствует (клиент видит только таймаут) | Провайдер ставит запрос в очередь в часы пик и отклоняет его примерно через 5 минут, когда клиент уже отключился |
| `429` upstream load saturated for the current group | `exceeds the maximum usage size allowed during peak load` | Один запрос превышает объем использования, допустимый во время пиковой нагрузки. Это не лимит параллельных запросов |
| `400` image over the limit | `requires 67081 patches after processing, exceeding the limit of 30000` | Обработанное изображение превышает лимит патчей, и его размер необходимо изменить |

> [!WARNING]
>
> Не увеличивайте количество повторных попыток при получении `429`. Сначала прочитайте сообщение об ошибке: если в нем упоминается `maximum usage size` или `patches`, значит, сам запрос слишком большой, а повторные попытки будут лишь продолжать занимать параллельные запросы и оставаться в ожидании.

## Результаты тестирования: размер изображения и результат

2026-10-20 мы отправили одно и то же изображение в разных разрешениях в `gpt-6.1-sol` (JPEG, загруженный в виде Base64 через `image_url` на OpenAI-совместимый эндпоинт чата):

| Размер изображения | Пиксели | Тело запроса | Результат | Время | Входные tokens |
| - | - | - | - | - | - |
| 2048×1365 | 2,8 Мп | 0,75 МБ | Успешно, весь текст распознан корректно | 6 с | 3 321 |
| 4096×2731 | 11,2 Мп | 2,9 МБ | Успешно | 10 с | 13 228 |
| 6000×4000 | 24 Мп | 6,2 МБ | Успешно | 20 с | 28 219 |
| 7200×4800 | 34,6 Мп | 8,8 МБ | Успешно | 26 с | 40 519 |
| 9000×6000 | 54 Мп | 13,7 МБ | Успешно | 40 с | 63 638 |
| 10240×6827 | 70 Мп | 17,7 МБ | **Нет ответа; соединение закрыто примерно через 300 с** | — | — |

О чем говорят эти результаты:

* **Количество tokens растет линейно с числом пикселей**, примерно по формуле «пиксели ÷ 1024 × 1,2». Изображение 9000×6000 расходует примерно в 19 раз больше tokens, чем версия 2048, при идентичных результатах распознавания.
* **Пройдет ли изображение большого размера, зависит от маршрута и времени суток.** Данные в таблице выше были получены во внепиковое время на одном маршруте. На другом маршруте действует жесткий лимит в 30 000 патчей (около 30 мегапикселей) на изображение, а в часы пик этот порог еще ниже.
* Поэтому **не стоит воспринимать формулировку «запрос прошел в тесте» как безопасный лимит.** Для задач распознавания изображений длины большей стороны в 2048 пикселей более чем достаточно.

## Как определить, что изображение слишком большое

**1. Проверьте размер тела запроса**

Кодирование в base64 увеличивает размер примерно в 1,33 раза. Тело запроса размером в несколько МБ или более 10 МБ почти наверняка означает, что размер изображения не был изменен.

**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")                      # normalize to RGB; handles PNG, MPO, etc.
    img.thumbnail((max_side, max_side))           # keep aspect ratio, longer 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`. После изменения размера изображение обычно занимает несколько сотен КБ, а ответ возвращается за считанные секунды.

> [!TIP]
>
> Если вам нужно прочитать очень мелкий текст (например, сноски на полностраничном скане), **разделите страницу на несколько фрагментов** и загрузите их по отдельности либо обрежьте изображение до нужной области вместо загрузки одного огромного оригинала. Каждый фрагмент останется в пределах безопасного диапазона, а качество распознавания зачастую будет лучше.

## Часто задаваемые вопросы

> **Почему у других пользователей та же модель работает нормально?**
>
> Большинство пользователей загружают скриншоты или фотографии с телефонов, разрешение которых составляет всего несколько мегапикселей. Лимит использования на один запрос исчерпывается только тогда, когда кто-то загружает оригиналы с разрешением в десятки мегапикселей, поэтому на других пользователей в этот момент проблема не распространяется.

> **Взимается ли плата за такие ошибки?**
>
> Запросы, отклоненные провайдером (`429`, `400`), не создают записей о списаниях. Вы можете убедиться в этом в своем журнале использования.

> **Поможет ли увеличение таймаута на стороне клиента?**
>
> Нет. Увеличение таймаута означает лишь то, что вы будете дольше ждать, пока провайдер отклонит запрос; он все равно завершится ошибкой. Решение — уменьшить размер изображения.

> **Есть ли лимиты у Claude, Gemini и других моделей?**
>
> Да, но правила отличаются: Claude отклоняет любое отдельное изображение размером более 10 МБ (также с `429`), Kimi возвращает ошибку, если одно изображение превышает 16,384 tokens, Seed ограничивает общее количество пикселей до 36 мегапикселей, а Gemini автоматически уменьшает масштаб. См. раздел «Сначала уменьшайте большие изображения» документа [Анализ изображений](/ru/api-capabilities/vision-understanding).

## Связанные документы

> **[Анализ изображений](/ru/api-capabilities/vision-understanding)**
>
> Как отправлять изображения в каждую модель, обработка больших изображений и результаты тестирования

> **[Как диагностировать ошибки API моделей?](/ru/faq/model-error-troubleshooting)**
>
> Локализация проблем по типу ошибки

> **[Как избежать таймаутов API?](/ru/faq/timeout-configuration)**
>
> Настройка таймаутов и устранение неполадок при длительных запросах

> **[Каковы лимиты параллельных запросов API?](/ru/faq/api-concurrency)**
>
> Как отличить реальные лимиты параллельных запросов от других ошибок 429


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