La Paradoja de la Capacidad de Inferencia
¡Hola Devs! Fíjate en esto: toda flota de inferencia a gran escala vive con una contradicción. La flota está globalmente limitada, pero hay bolsas de capacidad localmente ociosas. Provisionar para el pico, el timing de desarrollo de modelos, la proporción de recursos por región y la heterogeneidad de aceleradores generan estos desfases.
A la escala de Meta, esas bolsas temporales suman mucho compute. La pregunta no es si existe capacidad ociosa — es si puedes usarla sin comprometer el serving de baseline. Vamos a ver cómo Meta resolvió esto.
La idea central: capacidad oportunista es preemptible, volátil y sin garantías. Solo workloads con alta elasticidad, calidad sostenida a escala y pocas dependencias cross-service pueden consumirla con seguridad.
(Fuente: Meta Engineering)
Dos Palancas de Elasticidad Complementarias
Meta identificó dos palancas que cumplen los criterios estructurales. Cada una consume un mix de recursos distinto, así que juntas cubren más del pool oportunista que cualquiera sola.
Rank More Ads (RMA)
Para cada request del usuario, el sistema de anuncios elige unos cuantos anuncios entre millones de candidatos en menos de un segundo. Las etapas de ranking van reduciendo el conjunto, y las etapas finales solo evalúan los top candidatos de las anteriores.
RMA aumenta el número de candidatos evaluados cuando hay capacidad oportunista. Más candidatos → más chance de encontrar anuncios relevantes. Como los candidatos extra pasan por el upstream pesado en CPU (retrieval, feature processing) y por la inferencia pesada en acelerador, RMA necesita surplus de CPU y acelerador.
Serve Better Models (SBM)
SBM cambia la fracción de requests ruteados a un modelo más poderoso conforme la capacidad de acelerador fluctúa. Mantiene el volumen de candidatos constante, así que la demanda de CPU en el upstream queda estable — o sea, SBM consume surplus solo de acelerador que RMA no puede usar.
# Ilustración conceptual de los perfiles de recurso de las dos palancas
levers = {
"RMA": {"cpu": "alto", "acelerador": "alto", "impacto_upstream": "significativo"},
"SBM": {"cpu": "bajo", "acelerador": "alto", "impacto_upstream": "mínimo"},
}
# Cobertura combinada: RMA usa surplus de CPU+GPU, SBM usa surplus solo de GPU
def capacidad_utilizable(cpu_surplus, gpu_surplus):
rma_utilizable = min(cpu_surplus, gpu_surplus) # limitado por el recurso más escaso
sbm_utilizable = gpu_surplus - rma_utilizable # sobra de GPU que solo usa SBM
return rma_utilizable + sbm_utilizable
¿Por qué las dos juntas?
El valor incremental de cada palanca cambia con el tráfico, la cobertura actual y el mix de recursos. En cualquier momento, la siguiente unidad de capacidad oportunista puede rendir más ranqueando candidatos o ruteando más requests a un modelo poderoso. Meta rebalancea periódicamente según la performance medida.
Takeaway de arquitectura: no construyas un solo mecanismo de elasticidad. Construye un set pequeño de palancas con perfiles de recurso disjuntos y aloca entre ellas dinámicamente.
Usando Capacidad Preemptible con Seguridad
La capacidad oportunista puede recuperarse más rápido de lo que los control loops reaccionan. El diseño de Meta gira en torno a un requisito duro:
Perder capacidad oportunista puede reducir trabajo incremental — pero nunca debe sobrecargar la capacidad de baseline.
Tres mecanismos lo garantizan:
1. Aislamiento físico vs. lógico
- SBM → aislamiento físico. Modelo baseline y modelo poderoso usan routing targets separados. Réplicas dedicadas sirven el baseline; réplicas oportunistas sirven el modelo poderoso. Cuando la capacidad se contrae, el tráfico regresa al baseline, cuya capacidad ya está provisionada.
- RMA → aislamiento lógico. El sistema calcula cuánto trabajo extra de ranking soportan las réplicas oportunistas y define un presupuesto global. El baseline se protege limitando el trabajo incremental total — sin separación física de requests.
2. Feedback loops por workload
- RMA usa un controlador PID central mirando tail latency. Latencia bajo la meta → ranquea más anuncios. Latencia subiendo → ranquea menos. Los clientes aplican la meta en nuevos requests.
- SBM usa un controlador central para la meta de cobertura más un model router en el cliente. El router segmenta requests por valor previsto de engagement y corre explore-and-exploit para medir el beneficio incremental del modelo poderoso por segmento — porque el beneficio incremental no siempre acompaña el valor absoluto del request.
3. Load shedding por valor en múltiples capas
Los loops centrales operan en el orden de minutos. La preempción puede llegar en milisegundos. Por eso servidor y cliente sueltan carga localmente:
| Capa | Tiempo de reacción | Mecanismo |
|---|---|---|
| Controlador central | Minutos | Ajusta meta de candidatos de RMA / cobertura de SBM |
| Shedding en servidor | Milisegundos | Descarta trabajo oportunista de bajo valor en el cuello de botella |
| Shedding en cliente | Milisegundos | Observa estado del servidor y descarta requests de bajo valor |
Ambas capas usan señales de valor para elegir qué descartar, minimizando el impacto en calidad durante transiciones.
Limitaciones y Cuidados
- No es patrón general. Solo workloads con alta elasticidad y pocas dependencias cross-service califican. Un servicio fuertemente acoplado con garantías de consistencia rígidas no puede consumir capacidad preemptible así.
- La estimación de valor es cuello de botella. Tanto el routing de SBM como el load shedding dependen de señales de valor. Un modelo de valor mal calibrado descarta el trabajo equivocado.
- Explore-and-exploit tiene costo. Sondear segmentos continuamente consume capacidad real y puede servir modelos subóptimos temporalmente.
- La fragmentación limita el ROI. Capacidad atrapada en aceleradores incompatibles o regiones sin deploy de modelo compatible queda inutilizable hasta que mejore la portabilidad.
Próximos Pasos
Si estás diseñando algo parecido, empieza con estas preguntas:
- ¿Qué workloads son autocontenidos y elásticos? Precomputación en batch, expansión de ranking y routing por tier de modelo son candidatos comunes.
- ¿Puedes aislar baseline del trabajo opcional? Aislamiento físico es más simple; lógico exige contabilidad precisa de capacidad.
- ¿Cuál es tu estrategia de shedding rápido? Si el controlador central es tu única defensa, tienes una ventana de exposición de varios minutos.
- ¿Cómo vas a medir valor incremental? Sin señal de valor, no puedes priorizar qué descartar o rutear.
El roadmap de Meta apunta a elasticidad de precomputación (trabajo hecho antes del request, menos atado a la ubicación del tráfico en vivo), portabilidad de modelo entre tipos de acelerador y un alocador basado en optimización que distribuye capacidad automáticamente entre las palancas.
La Moraleja
El sistema de Meta es clase magistral de usar recurso volátil sin apostar la casa en él. El patrón generaliza más allá de ads: aísla el baseline, agrega palancas elásticas con perfiles de recurso disjuntos, cierra el loop con shedding local rápido y deja que los controladores centrales converjan despacio.
La parte más difícil no es el ML — es la contabilidad de capacidad y la señal de valor que hacen posible la degradación graciosa.
Lee también: