Como o Meta Transforma Capacidade Ociosa de Inferência de IA em Anúncios Melhores (Sem Quebrar o Baseline)

O Paradoxo da Capacidade de Inferência

Olha só a situação: toda frota de inferência em larga escala vive com uma contradição. A frota está globalmente limitada, mas existem bolsões de capacidade localmente ociosos. Provisionamento para pico, timing de desenvolvimento de modelos, proporção de recursos por região e heterogeneidade de aceleradores criam esses descompassos.

Na escala do Meta, esses bolsões temporários somam muito compute. A pergunta não é se existe capacidade ociosa — é se dá pra usá-la sem comprometer o serving de baseline. Vamos ver como o Meta resolveu isso.

A sacada central: capacidade oportunista é preemptível, volátil e sem garantias. Só workloads com alta elasticidade, qualidade sustentada em escala e poucas dependências cross-service conseguem consumi-la com segurança.

(Fonte: Meta Engineering)

Duas Alavancas de Elasticidade Complementares

O Meta identificou duas alavancas que atendem aos critérios estruturais. Cada uma consome um mix de recursos diferente, então juntas cobrem mais do pool oportunista do que qualquer uma sozinha.

Rank More Ads (RMA)

Para cada request do usuário, o sistema de anúncios escolhe alguns anúncios entre milhões de candidatos em menos de um segundo. Os estágios de ranking vão reduzindo o conjunto, e os estágios finais só avaliam os top candidatos dos anteriores.

RMA aumenta o número de candidatos avaliados quando há capacidade oportunista. Mais candidatos → mais chance de achar anúncios relevantes. Como os candidatos extras passam pelo upstream pesado em CPU (retrieval, feature processing) e pela inferência pesada em acelerador, RMA precisa de surplus de CPU e acelerador.

Serve Better Models (SBM)

SBM muda a fatia de requests roteados para um modelo mais poderoso conforme a capacidade de acelerador flutua. Mantém o volume de candidatos constante, então a demanda de CPU no upstream fica estável — ou seja, SBM consome surplus só de acelerador que o RMA não consegue usar.

# Ilustração conceitual dos perfis de recurso das duas alavancas
levers = {
    "RMA": {"cpu": "alto", "acelerador": "alto", "impacto_upstream": "significativo"},
    "SBM": {"cpu": "baixo", "acelerador": "alto", "impacto_upstream": "mínimo"},
}

# Cobertura combinada: RMA usa surplus de CPU+GPU, SBM usa surplus só de GPU
def capacidade_utilizavel(cpu_surplus, gpu_surplus):
    rma_utilizavel = min(cpu_surplus, gpu_surplus)   # limitado pelo recurso mais escasso
    sbm_utilizavel = gpu_surplus - rma_utilizavel    # sobra de GPU que só o SBM usa
    return rma_utilizavel + sbm_utilizavel

Por que as duas juntas?

O valor incremental de cada alavanca muda com tráfego, cobertura atual e mix de recursos. A qualquer momento, a próxima unidade de capacidade oportunista pode render mais ranqueando candidatos ou roteando mais requests para um modelo poderoso. O Meta rebalanceia periodicamente com base em performance medida.

Takeaway de arquitetura: não construa um único mecanismo de elasticidade. Construa um conjunto pequeno de alavancas com perfis de recurso disjuntos e aloque entre elas dinamicamente.

Usando Capacidade Preemptível com Segurança

Capacidade oportunista pode ser recolhida mais rápido do que os control loops conseguem reagir. O design do Meta gira em torno de um requisito duro:

Perder capacidade oportunista pode reduzir trabalho incremental — mas nunca pode sobrecarregar a capacidade de baseline.

Três mecanismos garantem isso:

1. Isolamento físico vs. lógico

• SBM → isolamento físico. Modelo baseline e modelo poderoso usam routing targets separados. Réplicas dedicadas servem o baseline; réplicas oportunistas servem o modelo poderoso. Quando a capacidade encolhe, o tráfego volta pro baseline, cuja capacidade já está provisionada.
• RMA → isolamento lógico. O sistema calcula quanto trabalho extra de ranking as réplicas oportunistas suportam e define um orçamento global. O baseline é protegido limitando o trabalho incremental total — sem separação física de requests.

2. Feedback loops por workload

• RMA usa um controlador PID central olhando tail latency. Latência abaixo da meta → ranqueia mais anúncios. Latência subindo → ranqueia menos. Os clientes aplicam a meta nos novos requests.
• SBM usa um controlador central para a meta de cobertura mais um model router no cliente. O router segmenta requests por valor previsto de engajamento e roda explore-and-exploit para medir o benefício incremental do modelo poderoso por segmento — porque benefício incremental nem sempre acompanha o valor absoluto do request.

3. Load shedding por valor em múltiplas camadas

Os loops centrais operam na ordem de minutos. Preempção pode acontecer em milissegundos. Por isso servidor e cliente derrubam carga localmente:

As duas camadas usam sinais de valor para escolher o que descartar, minimizando impacto na qualidade durante transições.

Limitações e Cuidados

• Não é padrão geral. Só workloads com alta elasticidade e poucas dependências cross-service se qualificam. Serviço fortemente acoplado com garantias de consistência rígidas não pode consumir capacidade preemptível assim.
• Estimativa de valor é gargalo. Tanto o roteamento do SBM quanto o load shedding dependem de sinais de valor. Modelo de valor mal calibrado descarta o trabalho errado.
• Explore-and-exploit tem custo. Sondar segmentos continuamente consome capacidade real e pode servir modelos subótimos temporariamente.
• Fragmentação limita ROI. Capacidade presa em aceleradores incompatíveis ou regiões sem deploy de modelo compatível fica inutilizável até a portabilidade melhorar.

Próximos Passos

Se você está desenhando algo parecido, comece por estas perguntas:

1. Quais workloads são autocontidos e elásticos? Precomputação em batch, expansão de ranking e roteamento por tier de modelo são candidatos comuns.
2. Dá pra isolar baseline do trabalho opcional? Isolamento físico é mais simples; lógico exige contabilidade precisa de capacidade.
3. Qual é sua estratégia de shedding rápido? Se o controlador central é sua única defesa, você tem uma janela de exposição de vários minutos.
4. Como vai medir valor incremental? Sem sinal de valor, não dá pra priorizar o que descartar ou rotear.

O roadmap do Meta aponta para elasticidade de precomputação (trabalho feito antes do request, menos preso à localização do tráfego ao vivo), portabilidade de modelo entre tipos de acelerador e um alocador baseado em otimização que distribui capacidade automaticamente entre as alavancas.

A Moral da História

O sistema do Meta é aula de usar recurso volátil sem apostar a casa nele. O padrão generaliza além de ads: isole o baseline, adicione alavancas elásticas com perfis de recurso disjuntos, feche o loop com shedding local rápido e deixe os controladores centrais convergirem devagar.

A parte mais difícil não é o ML — é a contabilidade de capacidade e o sinal de valor que tornam a degradação graciosa possível.

Leia também:

• Chega de Prompts Monolíticos para Agentes de IA: Trate como Build Artifacts
• Data Commons MCP Agora no Google Cloud: Consulte Dados Públicos com IA, Sem Setup