Почему Together AI возвращает 429 и как читать x-ratelimit-reset

Задача считается выполненной не после HTTP 200, а после проверки структуры ответа и контрольного бизнес-условия. Запишите точный model ID, endpoint, SDK, serving mode и параметры генерации. Без этой карточки удачный тест невозможно повторить после обновления модели.

Проверенные параметры

• Фиксированные per-model limits не публикуются: динамический лимит меняется с использованием.
• При serverless 429 заголовок x-ratelimit-reset сообщает рекомендуемое число секунд до повтора.
• Равномерный трафик предпочтительнее burst: при 60 RPM пример документации советует примерно 1 RPS, а не 60 запросов за секунду.
• Для dedicated GPU quota уменьшают replicas, останавливают неиспользуемые deployments или обращаются за квотой; это не лечится обычным request retry.

Не переносите настройки между serverless, batch и on-demand автоматически. Они различаются жизненным циклом, способом масштабирования и смыслом ошибок. Любой пример с <MODEL_ID>, <ACCOUNT_ID> или <SHAPE_NAME> — шаблон: значение берут из своего каталога или фактического вывода tg, а не угадывают.

Контрольный пример до внедрения

Вход: Ступенчатый тест с постоянной длиной prompt и уровнями 1, 2, 4, 8 RPS.

Ожидаемый результат: Зафиксирована граница появления 429, прочитан reset, повтор отложен; средняя скорость сглажена и retry storm отсутствует.

Сохраните вход, очищенный JSON-ответ, HTTP-код, request ID, model ID и время выполнения. Ключ авторизации, персональные данные и закрытые документы в артефакт теста не попадают. Если задача связана с качеством модели, отделите технический успех запроса от смыслового PASS: валидный JSON может содержать неверный факт, а быстрый поток — неполный текст.

Настройка по шагам

1. Создайте отдельный API-ключ тестового проекта и передайте его через переменную TOGETHER_API_KEY. Не вставляйте ключ в Python, браузерный JavaScript, скриншоты и репозиторий.
2. Откройте актуальную карточку модели и подтвердите нужную возможность: streaming, tools, structured output, batch либо deployment shape. Поддержка одной функции не доказывает поддержку другой.
3. Зафиксируйте минимальный тест: один запрос, одна модель, один набор параметров. На первом запуске отключите автоматические retry, чтобы увидеть исходную ошибку.
4. Выполните шаблон ниже. Проверяйте не только наличие choices, но и нужные поля, finish_reason, формат данных и контрольные маркеры.
5. Добавьте отрицательный тест из раздела ошибок. Сервис должен отказать предсказуемо, а приложение — сохранить безопасную диагностику и не повторять неисправимый запрос.
6. Прогоните минимум 20–50 обезличенных примеров реального распределения: короткие и длинные входы, кириллицу, пустые значения, граничные числа и ожидаемые отказы.
7. Только после этого включайте retry, concurrency, кэш или масштабирование. Меняйте по одному фактору и сравнивайте с тем же baseline.

Рабочий шаблон

for attempt in range(6):
    raw=client.chat.completions.with_raw_response.create(model=MODEL,messages=messages)
    if raw.http_response.status_code != 429: break
    reset=float(raw.http_response.headers.get('x-ratelimit-reset','1'))
    time.sleep(min(reset,60)+random.random())
else: raise RuntimeError('retry budget exhausted')

Команда иллюстрирует проверяемый контракт, а не готовый production-сервис. Добавьте timeout, централизованную маскировку секретов, ограничение размера входа и request ID. Для операций, создающих ресурсы, сначала выводите совместимые варианты и сохраняйте возвращённый resource name.

Готовый промпт для теста

Выполни только одну задачу на входных данных ниже.
Не добавляй факты, которых нет во входе.
Если обязательного значения нет, верни ошибку MISSING_FIELD.
Формат ответа соблюдай буквально и не добавляй Markdown.

Вход: {CONTROL_INPUT}
Ожидаемые контрольные маркеры: {EXPECTED_MARKERS}

Этот промпт полезен как воспроизводимый fixture. Он не заменяет response_format, JSON Schema, серверную валидацию аргументов или проверку прав. Если контракт должен быть строгим, его обеспечивает код, а не обещание модели.

Как проверить результат

• тип workload определён
• reset записан
• RPS известен
• jitter включён
• retry budget ограничен