Together AI desacopla autoscaling de divisões de tráfego

Together AI publicou um guia de implantação detalhado para seu produto Dedicated Model Inference. O núcleo do sistema é composto por três entidades imutáveis: configs, deployments e endpoints.

Um config (prefixo `cr_...`) especifica tipo de GPU, quantidade de GPUs, estratégia de paralelismo e perfil de otimização (latência, throughput ou balanceado). Configs nunca são mutados — crie um novo e aponte um deployment para ele. Um deployment vincula uma revisão específica do modelo a um config específico, carrega uma política de autoscaling e executa as réplicas reais. Deployments são descartáveis; criar e destruir é rotina. O endpoint é a identidade estável — uma string `<project_slug>/<endpoint_name>` que sua aplicação passa como parâmetro `model` na API de inferência padrão — e mantém a divisão de tráfego que determina quais deployments recebem requisições.

O roteamento de divisão de tráfego difere do load-balancing convencional. Cada entrada é um par `{deployment_id, weight}`. O router computa a capacidade efetiva como `weight × ready_replicas`, e o tráfego flui proporcionalmente àquela capacidade, não apenas ao weight. Se deployment A tem weight 1 e 1 réplica pronta enquanto deployment B tem weight 1 e 3 réplicas prontas, a divisão real é 25%/75% sem nenhuma mudança de configuração conforme as réplicas escalam. Deployments degradados ou em escala contribuem zero capacidade; o tráfego drena para recursos disponíveis automaticamente.

Autoscaling e roteamento se tornam a mesma operação. Quando A escala de 1 para 3 réplicas, sua capacidade triplica e absorve proporcionalmente mais tráfego sem uma atualização de roteamento. Roteamento baseado em percentuais saturaria em scale-down e ficaria ocioso em scale-up. Weight values não têm restrição de soma — 0.7/0.3 e 700/300 produzem roteamento idêntico — embora times precisando de percentuais inteiros fixos possam usar modo cohort A/B, que impõe sum-to-100.

Remova um deployment da rotação com um comando CLI: `tg beta endpoints update $DEPLOYMENT_B --traffic-weight 0`. Sharp edge: um deployment recém-criado não recebe tráfego até aparecer na divisão de tráfego do endpoint. O comando CLI `together beta endpoints deploy` define a divisão automaticamente, é por isso que o quickstart funciona; times usando a API bruta ou SDK devem definir manualmente ou receberão `routing_error` responses imediatamente.

A seleção de config usa quatro seletores: tipo de acelerador (H100, H200, B200), contagem de acelerador (1, 2, 4 ou 8 GPUs), perfil de otimização e topologia (agregada vs. desagregada). O perfil de otimização exige a maior atenção. Latência usa batches menores e escalonamento eager — menor time-to-first-token, menores tokens-per-GPU-hour. Throughput usa batches maiores para maximizar utilização; latência por requisição sobe. Balanceado fica no meio. Para a maioria dos times, comece com os perfis de deployment pré-certificados que acompanham cada modelo no catálogo: `tg beta models public zai-org/GLM-5.2 --json | jq '.data[0].deploymentProfiles[]'` retorna IDs de config verificados por benchmark prontos para usar. O perfil certificado GLM-5.2 aponta para 4× NVIDIA B200 com quantização FP4 e tensor parallelism TP4.

O design da Together torna o routing weight um knob de carga por-réplica em vez de um percentual de tráfego. Isso mantém autoscaling e política de tráfego de lutarem um contra o outro — mas times devem entender a fórmula de capacidade antes de ajustar weights em produção.