A Together AI lançou uma primitiva nativa de experimento A/B no nível do endpoint, permitindo que times dividam o tráfego de inferência ao vivo entre um modelo de controle e até 20 deployments de variantes sem mudanças de código no cliente. Isso fecha uma lacuna que a maioria das equipes de plataforma ML preenchem com feature flags ad-hoc e strings de modelo hardcoded.

O tráfego é resolvido primeiro através da divisão de peso existente do endpoint. Quando uma requisição chega no braço de controle e um experimento A/B está anexado, a plataforma faz re-amostragem da requisição entre os membros do experimento pelos seus percentuais. Os deployments de variantes devem carregar zero peso na divisão base—eles existem como deployments shadow que o experimento roteia exclusivamente. Os percentuais entre controle e todas as variantes devem somar 100%. Criticamente, estas são verdadeiras compartições de tráfego fixas independentes da contagem de réplicas ou autoscaling. A divisão não vai desviar conforme réplicas escalam sob carga, eliminando uma fonte silenciosa de viés de amostragem em esquemas de roteamento ponderado por capacidade.

A progressão de ramp que a Together AI documenta mapeia diretamente para o tradeoff risco/sinal. Uma divisão 95/5 dá exposição mínima no primeiro contato: acúmulo lento de sinal mas raio de explosão contido. 80/20 oferece uma leitura mais significativa depois que o candidato sobrevive à exposição inicial. 50/50 é reservado para confirmação em estágio tardio entre duas opções já validadas. Cada ramp é uma mudança de estado explícita e revisável no objeto do experimento. Atualizar a lista de membros a substitui atomicamente e é protegida por uma etag—ramps concorrentes de colegas de time são rejeitadas em vez de silenciosamente sobrescritas, prevenindo race conditions no runbook de ops.

Encerrar um experimento é uma única chamada delete. O tráfego retorna 100% para controle sem mudanças no cliente, nenhuma lógica de roteamento a desfazer. Isso é importante: a patologia de abordagens DIY é que a lógica do experimento vai dentro da aplicação, e o código de branch sobrevive ao experimento porque removê-lo requer um deploy separado com sua própria superfície de risco.

O suporte multi-way desbloqueia comparações de quantização sem reestruturação. Um controle de precisão total ao lado de três variantes quantizadas (INT8, GPTQ, AWQ) rodando como um único experimento contanto que os percentuais somem 100%. A plataforma roteia métricas por-deployment—latência, taxa de erro, throughput—que os arquitetos juntam contra sinais de produto como taxa de thumbs-up, conclusão de tarefa e abandono de sessão. Scores de benchmark offline são explicitamente não o alvo; o framing do guia é que avaliação offline não reflete dinâmica de tráfego ao vivo, perfis de custo ou distribuições de latência sob carga real.

O desafio estatístico de testes A/B de LLM não é totalmente resolvido. Outputs não-determinísticos inflam variância em métricas de qualidade relativo a testes A/B tradicionais, significando que significância estatística em uma divisão 95/5 requer substancialmente mais tempo e volume. Times que se movem para 80/20 muito rápido com sinal fino estão fazendo um julgamento, não um. Percentuais fixos ajudam, mas times ainda precisam definir limites de aceitação antes de fazer ramp, não durante.

O takeaway: coloque lógica de experimento na camada de serving, não na camada de aplicação. Fixe seu deployment de controle em uma versão específica de modelo, não um alias flutuante. Defina limites de rollback—taxa de erro, delta p99 latência, orçamento custo-por-requisição—antes da primeira requisição chegar na variante.