Together AI ha lanzado una primitiva nativa de experimento A/B a nivel de endpoint, permitiendo que los equipos dividan el tráfico de inferencia en vivo entre un modelo de control y hasta 20 despliegues de variantes sin cambios de código en el lado del cliente. Cierra una brecha que la mayoría de los equipos de plataforma ML cierran con feature flags ad-hoc y strings de modelo hardcodeados.

El tráfico se resuelve primero a través de la división de pesos existente del endpoint. Cuando una solicitud llega al brazo de control y un experimento A/B está adjunto, la plataforma remuestrea la solicitud entre los miembros del experimento por sus porcentajes. Los despliegues de variantes deben llevar cero peso en la división base—existen como despliegues shadow que el experimento enruta exclusivamente. Los porcentajes entre control y todas las variantes deben sumar 100%. Críticamente, estos son verdaderos porcentajes de tráfego fijos independientes del recuento de réplicas o autoscaling. La división no se desviará cuando las réplicas escalen bajo carga, eliminando una fuente silenciosa de sesgo de muestreo en esquemas de enrutamiento ponderados por capacidad.

La progresión de ramp que Together AI documenta se asigna directamente al tradeoff riesgo/señal. Una división 95/5 da exposición mínima en el primer contacto: acumulación lenta de señal pero radio de explosión contenido. 80/20 ofrece una lectura más significativa después de que el candidato sobrevive la exposición inicial. 50/50 se reserva para confirmación en etapa tardía entre dos opciones ya validadas. Cada ramp es un cambio de estado explícito y revisable en el objeto del experimento. Actualizar la lista de miembros la reemplaza de forma atómica y está protegida por un etag—ramps concurrentes de compañeros de equipo se rechazan en lugar de sobrescribirse silenciosamente, previniendo race conditions en el runbook de ops.

Terminar un experimento es una única llamada delete. El tráfico vuelve al 100% a control sin cambios en el cliente, sin lógica de enrutamiento que deshacer. Esto importa: la patología de enfoques DIY es que la lógica del experimento se envía dentro de la aplicación, y el código de rama sobrevive al experimento porque eliminarlo requiere un deploy separado con su propia superficie de riesgo.

El soporte multi-way desbloquea comparaciones de cuantización sin reestructuración. Un control de precisión completa junto a tres variantes cuantizadas (INT8, GPTQ, AWQ) se ejecuta como un único experimento siempre que los porcentajes sumen 100%. La plataforma enruta métricas por-despliegue—latencia, tasa de error, throughput—que los arquitectos unen contra señales de producto como tasa de thumbs-up, conclusión de tarea y abandono de sesión. Las puntuaciones de benchmark offline explícitamente no son el objetivo; el enfoque de la guía es que la evaluación offline no refleja dinámicas de tráfico en vivo, perfiles de costo o distribuciones de latencia bajo carga real.

El desafío estadístico de las pruebas A/B de LLM no se resuelve completamente. Las salidas no determinísticas inflan varianza en métricas de calidad relativamente a pruebas A/B tradicionales, lo que significa que la significancia estadística en una división 95/5 requiere substancialmente más tiempo y volumen. Los equipos que se mueven a 80/20 demasiado rápido con señal débil están haciendo un juicio, no uno estadístico. Los porcentajes fijos ayudan, pero los equipos aún necesitan definir umbrales de aceptación antes de hacer ramp, no durante.

El resultado: empuja la lógica del experimento a la capa de serving, no a la capa de aplicación. Fija tu despliegue de control a una versión específica de modelo, no un alias flotante. Define umbrales de rollback—tasa de error, delta p99 de latencia, presupuesto de costo-por-solicitud—antes de que la primera solicitud llegue a la variante.