Почему модель отвечает медленно и что можно ускорить

Запрос, который вчера отрабатывал за пару секунд, сегодня висит полминуты. Прежде чем списывать это на «сервер тормозит», стоит проверить несколько конкретных вещей — половина из них полностью в ваших руках.

Размер контекста — самый частый виновник

Модели Claude и GPT в каталоге поддерживают контекст до 1 000 000 токенов (GLM — до 128K), и это удобно, пока не забываешь, что каждый лишний токен во входе — это время на его обработку до начала генерации. Если в промпт по привычке подклеивается вся история диалога, весь файл целиком вместо релевантного фрагмента, или системный промпт разросся до нескольких тысяч слов — время ответа растёт вместе с этим, даже если сам ответ короткий.

Проверить размер входа перед отправкой можно бесплатно, без обращения к модели:

curl https://api.zukko.pro/v1/messages/count_tokens \
  -H "Authorization: Bearer fetch_ваш_ключ" \
  -H "Content-Type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"claude-sonnet-5","messages":[{"role":"user","content":"..."}]}'

Если число неожиданно большое — это первое, что стоит подрезать, прежде чем разбираться дальше.

Extended thinking удлиняет ответ осознанно

Extended thinking — режим, в котором модель тратит дополнительные токены на рассуждение перед финальным ответом (поддерживает ли его выбранная модель и ваш клиент — проверьте в их настройках). Это осознанный компромисс: для задач, где важна точность (математика, многошаговая логика, разбор кода с несколькими условиями), extended thinking обычно даёт более надёжный результат, но сам процесс рассуждения занимает время и токены, которые не видны в финальном тексте напрямую. Если задача простая — короткий вопрос, форматирование текста, — включённый extended thinking может быть избыточным для неё по времени.

max_tokens и реальная длина генерации

Генерация линейна по числу токенов на выходе: чем больше вы просите модель сгенерировать, тем дольше идёт ответ, вне зависимости от того, сколько токенов реально понадобилось бы для сути ответа. Если max_tokens выставлен с большим запасом «на всякий случай», а модель в итоге генерирует близко к этому потолку из-за многословного стиля, время ответа растёт пропорционально. Стоит явно просить краткость в системном промпте, если задача не требует развёрнутого текста, и подбирать max_tokens под реальную ожидаемую длину, а не «с запасом побольше».

Обрыв на середине — это почти всегда не лимит токенов

Отдельный симптом: ответ обрывается на середине, и первое подозрение падает на лимит по токенам. На практике это почти всегда таймаут клиента или сети, а не ограничение сервера. Стоит проверить таймаут HTTP-клиента (многие библиотеки по умолчанию ставят 30-60 секунд, что маловато для длинной генерации с extended thinking) и убедиться, что max_tokens не обрезает ответ раньше времени искусственно. Помните и о деньгах: обрыв соединения на стороне клиента не останавливает списание — шлюз дочитывает ответ провайдера и списывает всю генерацию.

import requests

response = requests.post(
    "https://api.zukko.pro/v1/messages",
    headers={"Authorization": "Bearer fetch_ваш_ключ", "anthropic-version": "2023-06-01"},
    json={"model": "claude-opus-5-5", "max_tokens": 4096, "messages": [...]},
    timeout=180,  # а не дефолтные 30-60 секунд
)

Кэш ответов — бесплатное ускорение для повторов

Если один и тот же запрос от одного пользователя повторяется — например, при повторном рендере интерфейса или ретрае после сетевого сбоя — включите кэш. С заголовком X-Zukko-Cache: true (temperature: 0 тоже включает кэш, но только у моделей, которые его принимают, — модели Claude могут отклонить temperature, отличный от 1) полностью одинаковые запросы (совпадает всё тело) кэшируются на срок до 7 суток для чата, и повторный вызов возвращается мгновенно и бесплатно. Проверить попадание в кэш можно по заголовку ответа X-Zukko-Cache: hit.

curl https://api.zukko.pro/v1/messages \
  -H "Authorization: Bearer fetch_ваш_ключ" \
  -H "anthropic-version: 2023-06-01" \
  -H "X-Zukko-Cache: true" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":256,"messages":[{"role":"user","content":"Часто повторяющийся вопрос"}]}'

Это не ускоряет первый запрос, но полностью убирает задержку на всех последующих одинаковых.

Изображения на входе

Модели Claude и GPT принимают изображения (vision; у glm-5.3 и glm-5.3-flash его нет), и обработка визуального входа занимает время до начала генерации текста, сопоставимое или большее, чем обработка эквивалентного объёма текста. Если в задаче можно обойтись текстовым описанием вместо картинки — это часто быстрее.

Когда дело не в вас: 503 и недоступность провайдера

Если конкретная модель временно перегружена на стороне провайдера, шлюз может вернуть 503 provider_unavailable вместо того, чтобы просто отвечать медленнее. В этом случае ускорять нечего на своей стороне — нужно либо подождать и повторить, либо временно переключиться на другую модель из каталога. А 503 model_disabled означает, что модель выключена в каталоге, — здесь поможет только переход на другую модель (актуальный список — GET https://api.zukko.pro/v1/models).

Что можно сделать прямо сейчас

Практический чек-лист по убыванию эффекта: подрезать контекст до реально нужного через count_tokens, выставить max_tokens под ожидаемую длину ответа, отключить extended thinking для простых задач, если такая настройка доступна в клиенте, включить кэш для повторяющихся запросов через X-Zukko-Cache: true, и увеличить таймаут HTTP-клиента, если задача объективно требует долгой генерации.

Итого

Медленный ответ почти никогда не означает «сервер сломан» — чаще это сумма конкретных факторов: раздутый контекст, включённый extended thinking на простой задаче, завышенный max_tokens, или просто короткий таймаут клиента, который обрывает связь раньше, чем модель успела закончить. Каждый из этих пунктов проверяется и чинится за несколько минут.