Together AI desvincula el autoscaling de las divisiones de tráfico

Together AI publicó una guía de implementación detallada para su producto Dedicated Model Inference. El núcleo del sistema consta de tres entidades inmutables: configs, despliegues y endpoints.

Una config (prefijo `cr_...`) especifica el tipo de GPU, la cantidad de GPUs, la estrategia de paralelismo y el perfil de optimización (latencia, rendimiento o balanceado). Las configs nunca se modifican — crea una nueva en su lugar y apunta un despliegue a ella. Un despliegue vincula una revisión específica del modelo a una config específica, implementa una política de autoscaling y ejecuta las réplicas reales. Los despliegues son descartables; crear y destruir es rutina. El endpoint es la identidad estable — una cadena `<project_slug>/<endpoint_name>` que su aplicación pasa como parámetro `model` en la API de inferencia estándar — y contiene la división de tráfico que determina qué despliegues reciben solicitudes.

El enrutamiento de división de tráfico difiere del balanceo de carga convencional. Cada entrada es un par `{deployment_id, weight}`. El enrutador calcula la capacidad efectiva como `weight × ready_replicas`, y el tráfico fluye proporcionalmente a esa capacidad, no solo al peso. Si el despliegue A tiene un peso de 1 y 1 réplica lista, mientras que el despliegue B tiene un peso de 1 y 3 réplicas listas, la división real es 25%/75% sin cambios de configuración mientras se escalan las réplicas. Los despliegues degradados o en escala contribuyen cero capacidad; el tráfico se drena automáticamente a los recursos disponibles.

El autoscaling y el enrutamiento se convierten en la misma operación. Cuando A se escala de 1 a 3 réplicas, su capacidad se triplica y absorbe proporcionalmente más tráfico sin una actualización de enrutamiento. El enrutamiento basado en porcentajes se saturaría en scale-down y estaría inactivo en scale-up. Los valores de peso no tienen restricción de suma — 0.7/0.3 y 700/300 producen enrutamiento idéntico — aunque los equipos que necesitan porcentajes enteros fijos pueden usar el modo de cohorte A/B, que impone sum-to-100.

Elimina un despliegue de la rotación con un comando CLI: `tg beta endpoints update $DEPLOYMENT_B --traffic-weight 0`. Sharp edge: un despliegue recién creado no recibe tráfico hasta que aparece en la división de tráfico del endpoint. El comando CLI `together beta endpoints deploy` establece la división automáticamente, por eso funciona el quickstart; los equipos que usan la API o SDK sin procesar deben configurarlo manualmente o recibirán respuestas `routing_error` inmediatamente.

La selección de config utiliza cuatro selectores: tipo de acelerador (H100, H200, B200), número de aceleradores (1, 2, 4 u 8 GPUs), perfil de optimización y topología (agregada vs. desagregada). El perfil de optimización requiere la mayor atención. La latencia utiliza lotes más pequeños y programación eager — menor time-to-first-token, menor tokens-per-GPU-hour. El rendimiento utiliza lotes más grandes para maximizar la utilización; la latencia por solicitud aumenta. Balanceado está en el medio. Para la mayoría de los equipos, comienza con los perfiles de despliegue precertificados que se incluyen con cada modelo en el catálogo: `tg beta models public zai-org/GLM-5.2 --json | jq '.data[0].deploymentProfiles[]'` devuelve IDs de config verificados por benchmark listos para usar. El perfil certificado GLM-5.2 apunta a 4× NVIDIA B200 con cuantización FP4 y tensor parallelism TP4.

El diseño de Together hace que el peso de enrutamiento sea un control de carga por réplica en lugar de un porcentaje de tráfico. Esto evita que el autoscaling y la política de tráfico se enfrentan entre sí — pero los equipos deben entender la fórmula de capacidad antes de ajustar los pesos en producción.