Как разделить трафик между deployments Together AI без неверных процентов

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

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

• CLI задаёт вес каждой deployment через tg beta endpoints update dep_... --traffic-weight и сохраняет остальные веса.
• Python SDK заменяет весь traffic split, поэтому в запрос включают каждую deployment, которая должна получать трафик.
• В Python аргумент traffic_split использует snake_case, но update_mask должен быть API-путём trafficSplit.
• Deployment с весом 0, отсутствующая в split или без ready replicas трафик не получает; без routable deployment endpoint даёт 400 endpoint_not_configured.

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

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

Вход: Baseline dep_old с весом 90 и candidate dep_new с весом 10; обе имеют одинаковое число ready replicas.

Ожидаемый результат: На большой серии доля приближается к 90/10; при разном числе replicas ожидаемая доля пересчитывается как weight × ready replicas.

Сохраните вход, очищенный 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.

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

client.beta.endpoints.update('ep_abc123',project_id=project_id,traffic_split=[{'deployment_id':'dep_old','weight':90},{'deployment_id':'dep_new','weight':10}],update_mask='trafficSplit')
# проверить ready replicas и распределение по response metadata на большой серии

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

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

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

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

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

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

• обе deployment ready
• весь split передан
• mask верен
• ошибок 400 нет
• фактическая доля измерена