Проблема «хрупкого» продакшена
В экосистеме открытых моделей обновления выходят часто, но внедрение новых чекпоинтов или семейств моделей (например, переход с Qwen2.5 на Qwen3.5) сопряжено с рисками. Традиционные методы имеют критические недостатки:
- Hard swap (Жесткое переключение): Весь трафик мгновенно перенаправляется на новую модель. Если p95 латентность удваивается, проблема обнаруживается только после жалоб пользователей или в дашбордах, а откат происходит под давлением на «холодный» старый инстанс.
- DIY staged cutover (Ручное поэтапное переключение): Требует написания скриптов, ручного управления трафиком через Grafana и постоянного мониторинга. Человек становится узким местом и источником ошибок.
Решение: Canary Rollouts
Together AI внедрил автоматизированный механизм, который переносит безопасность в платформу. Вы описываете источник, цель, шаги и критерии «здоровья», а платформа управляет процессом. Ключевая особенность — метрические шлюзы (metric gates), которые проверяют показатели после каждого шага. Если метрика выходит за рамки, rollout автоматически приостанавливается, и вы принимаете решение об откате.
Реальный кейс: Qwen2.5-7B → Qwen3.5-9B
Разработчики провели тестовый rollout, который наглядно продемонстрировал эффективность системы. При переключении трафика на 10% система зафиксировала регрессию p95 латентности на 137%. Шлюз сработал, rollout был отменен, а трафик возвращен к старой модели. При этом ни один живой запрос не был потерян, а пользователи не заметили сбоев.
Три стратегии переключения
Все стратегии используют единый движок и проверки здоровья, но различаются по распределению трафика и затратам на ресурсы:
| Стратегия | Паттерн трафика | Доп. ресурсы | Метрические шлюзы | Лучше всего для |
|---|---|---|---|---|
| Canary | Поэтапное увеличение (по умолчанию 5% → 25% → 50% → 100%) | Почти размер источника (наложение на один шаг) | Да, после каждого шага | Тестирования на живом трафике перед полным переходом |
| Blue-green | Один шаг 0% → 100% после проверки здоровья | Полный размер обоих деплойментов до слива источника | Нет (нет окна ожидания) | Самой быстрой смены, когда можно временно удвоить ресурсы |
| Rolling | Пошаговая замена реплик (replica-by-replica) | Количество реплик источника + одна лишняя в середине шага | Нет | Изменений конфигурации движка той же модели при ограниченных GPU |
Как это работает технически
Процесс rollout начинается в состоянии PENDING и требует явного запуска, что позволяет команде провести ревью плана. Внутри каждого шага Canary происходит строгая последовательность действий для предотвращения инцидентов:
- Масштабирование цели (Target scales up): Новые реплики запускаются ДО перенаправления трафика. Это гарантирует наличие емкости.
- Проверка здоровья (Health gate): Трафик направляется только на реплики, где движок загружен и отвечает, а не просто запущен.
- Ожидание распространения (Propagation wait): Пауза между сдвигом трафика и удалением емкости источника, чтобы глобальные кэши маршрутизации обновились.
- Слив источника (Source drains): Старая модель отключается только после завершения перенаправления.
Система не имеет состояния FAILED, оставляющего трафик в подвешенном состоянии. Rollout завершается либо как COMPLETED (цель обслуживает), либо как CANCELED (разделение трафика замораживается, и можно запустить обратный процесс). Для управления используется CLI-утилита tg (версия 2.34.0+) или REST API.
Источник: Together AI ↗