Autoscaling da Together AI Reduz Custos de GPU Ociosa Usando Sinais de Fila

A Together AI lançou autoscaling para seu produto Dedicated Model Inference. Os times agora definem limites de réplica e direcionam métricas nativas de inferência em vez de sinais orientados por CPU que falham sob cargas de LLM. A configuração é um único comando CLI PATCH.

O modelo de cobrança cobra por réplica-minuto, tornando GPUs ociosas um custo direto. Os engenheiros enfrentam dois modos de falha: sobreprovisionamento e pagamento por GPUs com 15% de utilização, ou subprovisionamento e colapso da latência p95 quando o tráfego ultrapassa a capacidade de batch. Uma réplica no seu limite de concorrência não se degrada gradualmente—enfileira, e TTFT pode saltar de 200 ms para 15 s. Autoscaling de CPU clássico e regras reativas da nuvem não resolvem isso.

Autoscaling clássico falha em um ponto específico: uma GPU relata 60% de utilização enquanto sua fila de requisições se acumula, porque utilização mede intensidade aritmética, não profundidade de fila. Cold starts de LLM levam vários minutos. Uma nova réplica deve ser colocada em um nó GPU, puxar dezenas de gigabytes de pesos para VRAM e aquecer. No momento em que o tráfego picos, um scale-out acionado na borda do pico já é tarde demais. O sistema deve agir em sinais antecedentes, não sinais atrasados.

O loop de controle da Together AI é proporcional: desired_replicas = ceil(N × observed / target). Se o target é 8 requisições em-voo por réplica e a contagem observada é 16, o sistema quer 2× réplicas, sujeito aos limites min/max configurados. Duas janelas de tempo previnem oscilação. scale_up_window define por quanto tempo a pressão deve persistir antes do scale-out disparar. Mantenha curto: um falso scale-up custa alguns réplica-minutos; um perdido custa latência. scale_down_window padrão é 5 minutos e define por quanto tempo a calma deve durar antes de uma réplica ser removida. Mantenha mais longo que o ciclo de tráfego, porque scale-in prematuro dispara um cold start no próximo pico. Esta assimetria é deliberada e requer ajuste por carga de trabalho.

A plataforma expõe oito métricas de autoscaling em três categorias. Scaling orientado por concorrência em inflight_requests é o padrão seguro: é um indicador antecedente que sobe antes da latência se degradar visivelmente, não requer tráfego em streaming, e mapeia diretamente para batching do mecanismo. O target padrão de 8 por réplica deve subir para cargas de trabalho chat de prompt curto que fazem batch bem e cair para tráfego de agente de contexto longo com custos pesados de prefill. Métricas orientadas por SLO—ttft e e2e_latency—são sinais atrasados. No momento em que p95 ultrapassa um threshold, os usuários já foram afetados. Combine-os com headroom em min_replicas. Uma terceira categoria orientada por eficiência direciona custo-por-inferência diretamente.

Uma política mínima: min_replicas 1, max_replicas 6, scale_up_window 60s, scale_down_window 300s, scaling_metric ttft, scaling_target 500, scaling_percentile p95. Definir min e max iguais trava a frota em tamanho fixo e desabilita autoscaling. Definir ambos para zero interrompe deployment e cobrança—um padrão para endpoints dev que não rodam durante a noite.

A parte difícil é escolher a métrica certa para o formato de tráfego antes da carga chegar. Engenheiros rodando endpoints multi-tenant com cargas de trabalho mistas—sessões chat curtas e chamadas de agente de contexto longo—descobrem que uma única métrica e target não se mantêm em ambos. O post do blog repassa a mesma carga sob três políticas de autoscale para mostrar como a escolha de métrica desloca o comportamento de pico. Cada classe de carga de trabalho provavelmente precisa de seu próprio deployment e política. Consolidá-las em um pool economiza overhead de frota mas troca precisão de ajuste por simplicidade. Acertar errado envia TTFT de 200 ms de volta para 15 s—o mesmo precipício que o loop de controle existe para prevenir.

Se você estiver rodando Dedicated Model Inference na Together AI, defina scale_up_window agressivamente curto, scale_down_window para pelo menos 5 minutos, e padrão para inflight_requests a menos que você tenha um SLO contratual difícil. Nesse caso, direcion ttft p95 com min_replicas suficientes para absorver um ciclo de tráfego antes do scale-out completar.