Когда дело доходит до автомасштабирования больших языковых моделей (LLM), стандартные подходы часто дают сбой: GPU могут казаться недозагруженными, пока очередь запросов уже забита, а холодные старты занимают минуты. Together AI представила новую функцию автомасштабирования для своего выделенного инференса, которая учитывает эти особенности, помогая инженерам балансировать между производительностью и стоимостью.
Традиционные механизмы автомасштабирования, хорошо работающие для обычных веб-сервисов, для LLM оказываются неэффективны. Основные причины:
- Ошибочные метрики. Загрузка GPU (например, 60%) не всегда отражает реальную нагрузку. Очередь запросов может быть уже переполнена, а утилизация GPU измеряет арифметическую интенсивность, а не давление на систему.
- Долгие холодные старты. Новой реплике требуется несколько минут для размещения на узле GPU, загрузки десятков гигабайт весов в VRAM и прогрева. Это означает, что масштабироваться после пика трафика уже поздно.
Система Together AI позволяет настраивать политику автомасштабирования, включающую границы числа реплик, одну или несколько метрик масштабирования с целевыми значениями и временные окна. Контрольный цикл непрерывно оценивает наблюдаемую метрику, рассчитывает желаемое количество реплик, смягчает эти значения через временные окна, применяет границы и затем размещает GPU. Если целевое значение превышено, система пропорционально увеличивает количество реплик.
Ключевую роль играют временные окна:
scale_up_window— как долго нагрузка должна сохраняться, прежде чем будут добавлены реплики. Его рекомендуется делать коротким, так как стоимость ложного масштабирования вверх — это несколько реплика-минут, а стоимость пропущенного — рост задержки для пользователей.scale_down_window(по умолчанию 5 минут) — как долго система должна оставаться спокойной, прежде чем будут удалены реплики. Его следует делать дольше естественного ритма трафика, чтобы избежать ложного масштабирования вниз, которое может привести к холодному старту при следующем пике.
Платформа предлагает восемь метрик для автомасштабирования, разделённых на три категории:
- Concurrency-driven (
inflight_requests) — это безопасный вариант по умолчанию. Метрика является опережающим индикатором, она растёт, когда спрос превышает возможности сервиса, но до того, как задержка заметно ухудшится. Целевое значение 8 concurrent-запросов на реплику — хороший старт. - SLO-driven (
ttft,e2e_latency) — позволяют масштабироваться на основе гарантированной производительности. Задержка является отстающим сигналом, поэтому к такой метрике нужно добавлять запасmin_replicas.ttft,decoding_speedиthroughput_per_replicaтребуют, чтобы клиенты использовали стриминг. - Efficiency-driven (
gpu_utilization,token_utilization) — используются для оптимизации стоимости, когда важно максимально загрузить оборудование. При их использовании необходимо внимательно следить за p95-задержками, так как GPU может быть загружен, но задержка при этом будет высокой.
Важно понимать поведение холодных стартов. Установка min_replicas: 0 и max_replicas: 0 останавливает развёртывание, но не обеспечивает автоматического пробуждения. Процесс холодного старта состоит из размещения GPU, загрузки весов (до десятков ГБ), загрузки движка и прогрева. На H100 это занимает от 86 секунд (для базовой модели Qwen3.5-9B) до 145 секунд (для кастомной 18 ГБ модели), а до первого токена может пройти ещё 26–40 секунд. Масштабирование с 1 до 2 реплик занимает около 2,5 минут. Это означает, что функция автостопа выгодна только при длительных простоях и готовности первого пользователя терпеть задержку или ошибку. Для сервисов с SLO или автоматическими вызовами рекомендуется держать min_replicas: 1. Если пик трафика происходит быстрее холодного старта, запросы встают в очередь, задержка растёт, а риск ошибок и таймаутов увеличивается.
Together AI провела эксперимент с развёртыванием Qwen3.5-9B на 1xH100 с границами 1–3 реплики, имитируя синусоидальную нагрузку с пиками. Были протестированы три политики: inflight_requests (цель 8), ttft p95 (300 мс) и gpu_utilization (75%).
inflight_requestsмасштабировался от 1 до 3 реплик, снижая p95-задержку.ttft p95иgpu_utilizationне масштабировались вовсе, поскольку их метрики оставались в пределах цели, несмотря на насыщение системы. Эксперимент показал, что толькоinflight_requests, как прямой сигнал давления на очередь, смог распознать проблему насыщения системы. Остальные метрики выглядели «здоровыми», пока пользователи уже сталкивались с задержками.
Together AI предлагает инженерам детальный контроль над автомасштабированием LLM, что критично для баланса между стоимостью и производительностью. Однако платформа не решает проблему холодных стартов на стороне пользователя, и выбор оптимальной политики по-прежнему требует глубокого понимания конкретной нагрузки и тщательного мониторинга.