Как Together AI управляет выделенным инференсом: endpoint, deployment и config

Зачем нужна трёхуровневая архитектура для инференса

Одна модель, один сервер, один адрес для запросов. Эта схема работает, пока вы не начинаете масштабироваться. Появляются новые версии модели, нужно тестировать гипотезы, сравнивать конфигурации GPU. Эндпоинты множатся, конфигурации путаются, а любое обновление грозит простоем.

Together AI предложила трёхуровневую архитектуру, которая наводит порядок в этом хаосе. Она разделяет управление инференсом на три независимых слоя: endpoint (стабильное имя для вызова), deployment (связка модели и конфигурации) и config (неизменяемый рецепт производительности). Каждый слой отвечает за свою задачу, а вместе они дают гибкость, недоступную при монолитном подходе.

Главное преимущество такого разделения - возможность менять модели и настройки на лету, не затрагивая клиентский код. Ваши пользователи продолжают отправлять запросы на один и тот же URL, а за кулисами в этот момент может происходить что угодно: A/B-тест, теневое тестирование новой версии или плавный переезд на другую конфигурацию железа.

Три уровня управления: endpoint, deployment, config

Архитектура построена по принципу разделения ответственности. Каждый уровень решает конкретную задачу и ничего не знает о внутренностях других. Это позволяет менять любой компонент независимо.

Endpoint: стабильное имя для вызова

Endpoint - это публичный URL, на который клиенты отправляют запросы. Он остаётся неизменным на всём жизненном цикле сервиса. Все внутренние изменения - замена модели, смена конфигурации GPU, переключение между версиями - происходят без смены адреса.

Клиентский код не нужно трогать при обновлении. Вы просто меняете привязку endpoint к новому deployment, и трафик начинает поступать на другую модель. Пользователи не замечают переключения.

Один endpoint может обслуживаться несколькими deployments одновременно. Это основа для A/B-тестов и постепенных обновлений: часть трафика идёт на старую версию, часть - на новую, а клиенты продолжают стучаться в один адрес.

Deployment: связка модели и конфигурации

Deployment - это активная, работающая связка конкретной модели и конкретного config. Если endpoint отвечает на вопрос «куда отправлять запрос», то deployment определяет «кто и как будет обрабатывать».

Ключевая особенность - автоконфигурация. Система сама подбирает оптимальные параметры развёртывания: количество реплик, распределение по GPU, настройки параллелизма. Вам не нужно вручную рассчитывать, сколько видеокарт потребуется под ожидаемую нагрузку.

Под одним endpoint может быть несколько deployments с разными весами. Вес определяет, какая доля эффективной ёмкости приходится на каждый deployment. Это гибче, чем жёсткое разделение трафика по процентам, потому что учитывает фактическое количество готовых к работе реплик.

Config: неизменяемый рецепт производительности

Config - это зафиксированный набор технических параметров, который определяет, как именно будет работать модель. В него входят: тип и количество GPU, настройки оптимизации (квантование, тензорный параллелизм), параметры пакетной обработки запросов.

Config неизменяем. После создания его нельзя отредактировать - только создать новый. Это даёт два преимущества. Первое - воспроизводимость: вы всегда можете вернуться к проверенной конфигурации, потому что она никуда не исчезла. Второе - аудит: всегда понятно, с какими настройками работала модель в конкретный момент времени.

Такой подход напоминает инфраструктуру как код. Вы не правите конфигурации на ходу, рискуя забыть, что меняли. Вы создаёте новый config, тестируете его через deployment с нулевым весом и только потом переключаете трафик.

Как работает маршрутизация: эффективная ёмкость вместо процентов

Традиционный подход к распределению трафика - задать проценты: 80% на версию A, 20% на версию B. Это работает, пока количество реплик не меняется. Но если версия A масштабируется под нагрузку, а версия B стоит на месте, проценты перестают отражать реальность.

Together AI использует другой принцип - эффективную ёмкость. Это произведение веса deployment на количество готовых реплик. Маршрутизатор смотрит на эффективную ёмкость каждого deployment и распределяет запросы пропорционально ей.

Почему одинаковые веса не означают равный трафик

Представьте: у вас два deployments с одинаковым весом 1. У первого - 2 готовые реплики, у второго - 1. Эффективная ёмкость первого: 1 × 2 = 2. Второго: 1 × 1 = 1. Суммарная ёмкость: 3.

Первый deployment получит 2/3 трафика, второй - 1/3. Хотя веса одинаковые, доли трафика разные. Система стремится к тому, чтобы каждая реплика получала равную нагрузку, а не к тому, чтобы каждый deployment получал равную долю запросов.

Это важное различие. Оно означает, что при масштабировании одного из deployments нагрузка автоматически перераспределяется без ручного изменения весов. Вы добавляете реплики - deployment забирает больше трафика. Убираете - меньше.

Автоматическое перераспределение при масштабировании

Когда вы добавляете реплики в deployment, его эффективная ёмкость растёт. Маршрутизатор мгновенно пересчитывает пропорции и начинает отправлять больше запросов на этот deployment. Никаких ручных правок конфигурации, никаких перезапусков.

То же самое при уменьшении числа реплик: эффективная ёмкость падает, доля трафика снижается. Система сама заботится о том, чтобы оставшиеся реплики не были перегружены.

Этот механизм критически важен для бесшовных обновлений. Вы запускаете новую версию модели с одной репликой и минимальным весом, а затем просто наращиваете количество реплик. Трафик перетекает плавно, без единой потерянной секунды. Подробнее о том, как устроена надёжность AI-сервисов на практике, мы разбирали в статье о реальных показателях доступности.

Сценарии использования: A/B-тесты, тени и обновления

Трёхуровневая архитектура закрывает три основные задачи эксплуатации моделей в продакшене: сравнение версий, безопасное тестирование и обновление без простоев.

A/B-тестирование моделей и конфигураций

Чтобы сравнить две модели или две конфигурации одной модели, вы создаёте два deployments под одним endpoint. Назначаете им веса - например, 1 и 1 - и система автоматически делит трафик с учётом количества реплик.

Дальше вы собираете метрики: задержку, пропускную способность, качество ответов. Переключение между вариантами происходит плавно и обратимо. Если новый вариант показывает себя хуже, вы просто уменьшаете его вес до нуля или удаляете deployment. Трафик возвращается к проверенной версии.

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

Теневые эксперименты без риска

Deployment с нулевым весом не получает пользовательский трафик. Но он остаётся активным и готовым к работе. Это открывает сценарий теневого тестирования.

Вы можете направить на такой deployment копию реальных запросов (зеркалирование трафика) и оценить, как новая модель или конфигурация справляется с боевой нагрузкой. Пользователи при этом не видят результатов работы теневого deployment - они продолжают получать ответы от основной версии.

Другой вариант - использовать нулевой вес для внутренних тестов. Команда может прогонять через deployment синтетические запросы, проверять стабильность и производительность перед тем, как выводить новую версию на пользователей.

Бесшовные обновления: от старой версии к новой

Классическая проблема: нужно обновить модель, но остановка сервиса недопустима. Трёхуровневая архитектура решает её через стратегию rolling update.

Вы запускаете новый deployment с небольшим количеством реплик и низким весом. Маршрутизатор начинает отправлять на него малую долю трафика. Убедившись, что всё работает стабильно, вы увеличиваете количество реплик нового deployment и одновременно уменьшаете реплики старого. Трафик плавно перетекает.

В любой момент процесс можно остановить или обратить вспять. Если новая версия начала выдавать ошибки, вы просто сворачиваете её deployment, и весь трафик возвращается к старой, стабильной версии. Никаких простоев, никаких потерянных запросов. Платформа Together AI также поддерживает канареечные и сине-зелёные обновления с автоматическим откатом - мы рассказывали об этом в обзоре новой платформы для инференса open-weight моделей.

Выбор профиля оптимизации: задержка или пропускная способность

Config определяет не только железо, но и то, как модель обрабатывает запросы. Два ключевых параметра, между которыми всегда приходится искать баланс - задержка и пропускная способность.

Метрики для сравнения: latency vs throughput

Задержка (latency) - это время, за которое модель отвечает на один запрос. Измеряется в миллисекундах. Критична для интерактивных сценариев: чат-ботов, голосовых ассистентов, автодополнения кода. Пользователь ждёт ответа здесь и сейчас, каждая лишняя миллисекунда раздражает.

Пропускная способность (throughput) - количество запросов, которое модель обрабатывает за секунду. Важна для пакетной обработки: классификации тысяч документов, генерации описаний для каталога товаров, анализа логов. Здесь не важна скорость отдельного ответа, важен общий объём работы в единицу времени.

Параметры config напрямую влияют на эти метрики. Тензорный параллелизм (распределение модели по нескольким GPU) ускоряет обработку одного запроса, но может снизить общую пропускную способность. Размер батча (количество запросов, обрабатываемых одновременно) увеличивает throughput ценой роста задержки для каждого отдельного запроса.

Как подобрать конфигурацию под свою задачу

Начните с автоконфигурации - Together AI сама подберёт параметры под модель и доступное железо. Затем создайте два config с разными профилями: один с упором на низкую задержку, другой - на высокую пропускную способность.

Разверните оба варианта как deployments под одним endpoint с одинаковыми весами и подайте на них реалистичную нагрузку. Сравните метрики. Для чат-бота смотрите на медианную задержку и процентиль 95 (сколько времени ждут ответа самые «медленные» 5% пользователей). Для пакетной обработки - на количество запросов в секунду и стабильность этого показателя.

Выбрав профиль, зафиксируйте его в config. Если требования изменятся - создадите новый config и повторите тестирование. Старый останется доступным для отката.

Выделенный инференс против публичного API: когда что выбирать

Публичный API - это общий пул ресурсов. Вы отправляете запросы, провайдер маршрутизирует их на свободные GPU. Плюсы: не нужно настраивать инфраструктуру, платите только за использование, запуск занимает минуты. Минусы: вы делите ресурсы с другими клиентами, производительность может плавать, контроль над конфигурацией минимален.

Выделенный инференс - это зарезервированные под вас GPU. Вы получаете гарантированную производительность, полный контроль над config, возможность тонкой настройки под свою нагрузку. Плюсы: предсказуемая задержка, стабильная пропускная способность, безопасность данных (модель не делит железо с чужими задачами). Минусы: нужно управлять конфигурацией, ресурсы оплачиваются независимо от utilisation.

Правило выбора простое. Для прототипа, пет-проекта или сервиса с низкими требованиями к стабильности - публичного API достаточно. Для продакшена, где важна каждая миллисекунда задержки или где нагрузка предсказуема и высока - выделенный инференс. Для сценариев, где вы планируете A/B-тесты, теневые эксперименты и частые обновления моделей - выделенный инференс даёт инструменты, которых нет в публичном API.

Разделение ответственности между компонентами - общий тренд в AI-разработке. Похожий подход, но в другой плоскости, демонстрирует Cursor: разделение AI-агентов на планировщиков и исполнителей позволило сократить объём репозитория на 85% и снизить затраты до 15 раз. Подробнее об этом эксперименте - в статье о разделении труда в AI-разработке.