El Autoscaling de Together AI Reduce los Costos de GPU Ociosa Usando Señales de Cola

Together AI lanzó autoscaling para su producto Dedicated Model Inference. Los equipos ahora establecen límites de réplica y direccionan métricas nativas de inferencia en lugar de señales orientadas a CPU que fallan bajo cargas de LLM. La configuración es un único comando CLI PATCH.

El modelo de facturación cobra por réplica-minuto, haciendo que las GPUs ociosas sean un costo directo. Los ingenieros enfrentan dos modos de fallo: sobre-provisionar y pagar por GPUs con 15% de utilización, o sub-provisionar y ver colapsar la latencia p95 cuando el tráfico supera la capacidad de lotes. Una réplica en su límite de concurrencia no se degrada gradualmente—encola, y TTFT puede saltar de 200 ms a 15 s. El autoscaling de CPU clásico y las reglas reactivas de la nube no solucionan esto.

El autoscaling clásico falla en un punto específico: una GPU reporta 60% de utilización mientras su cola de solicitudes se acumula, porque la utilización mide intensidad aritmética, no profundidad de cola. Los cold starts de LLM toman varios minutos. Una nueva réplica debe colocarse en un nodo GPU, extraer decenas de gigabytes de pesos en VRAM y calentarse. Para cuando los picos de tráfico llegan, un scale-out activado al borde del pico ya es demasiado tarde. El sistema debe actuar en señales adelantadas, no atrasadas.

El bucle de control de Together AI es proporcional: desired_replicas = ceil(N × observed / target). Si el objetivo es 8 solicitudes en vuelo por réplica y el recuento observado es 16, el sistema desea 2× réplicas, sujeto a los límites min/max configurados. Dos ventanas de tiempo previenen oscilación. scale_up_window establece cuánto tiempo debe persistir la presión antes de que se active el scale-out. Manténgalo corto: un falso scale-up cuesta algunos réplica-minutos; uno perdido cuesta latencia. scale_down_window por defecto es 5 minutos y establece cuánto tiempo debe durar la calma antes de que se elimine una réplica. Manténgalo más largo que el ciclo de tráfico, porque el scale-in prematuro desencadena un cold start en el próximo pico. Esta asimetría es deliberada y requiere ajuste por carga de trabajo.

La plataforma expone ocho métricas de autoscaling en tres categorías. El escalado impulsado por concurrencia en inflight_requests es el predeterminado seguro: es un indicador adelantado que sube antes de que la latencia se degrade visiblemente, no requiere tráfico de streaming, y se mapea directamente al lote del motor. El objetivo predeterminado de 8 por réplica debe aumentar para cargas de trabajo de chat de mensaje corto que se agrupan bien y disminuir para tráfico de agente de contexto largo con altos costos de prefill. Las métricas impulsadas por SLO—ttft y e2e_latency—son señales atrasadas. Para cuando p95 supera un umbral, los usuarios ya están afectados. Combínelos con margen en min_replicas. Una tercera categoría impulsada por eficiencia apunta a costo-por-inferencia directamente.

Una 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. Establecer min y max iguales bloquea la flota a tamaño fijo y desactiva el autoscaling. Establecer ambos a cero detiene la implementación y la facturación—un patrón para endpoints dev que no se ejecutan durante la noche.

La parte difícil es elegir la métrica correcta para la forma del tráfico antes de que llegue la carga. Los ingenieros que ejecutan endpoints multi-tenant con cargas de trabajo mixtas—sesiones de chat cortas y llamadas de agente de contexto largo—encuentran que una única métrica y objetivo no se mantienen en ambos. La publicación del blog reproduce la misma carga bajo tres políticas de autoscale para mostrar cómo la elección de métrica desplaza el comportamiento de pico. Cada clase de carga de trabajo probablemente necesita su propio despliegue y política. Consolidarlas en un pool ahorra gastos generales de flota pero intercambia precisión de ajuste por simplicidad. Equivocarse envía TTFT de 200 ms de vuelta a 15 s—el mismo acantilado que el bucle de control existe para prevenir.

Si está ejecutando Dedicated Model Inference en Together AI, establezca scale_up_window agresivamente corto, scale_down_window a al menos 5 minutos, y predeterminado en inflight_requests a menos que tenga un SLO contractual difícil. En ese caso, dirija ttft p95 con suficientes min_replicas para absorber un ciclo de tráfico antes de que se complete el scale-out.