Token Management in Multi-Tenant AI Inference Platforms

Este artigo apresenta os "token pools", uma abstração de plano de controle para plataformas de inferência de IA multi-tenant que gerencia a capacidade como direitos expressos em unidades nativas de inferência, permitindo um equilíbrio dinâmico entre utilização de recursos e garantias de nível de serviço através de alocação prioritária e mecanismos de justiça baseados em dívida, sem modificar o runtime subjacente.

O essencial

Imagine que você tem um restaurante de luxo (a plataforma de IA) que serve milhões de pratos diferentes (os pedidos de IA) para milhares de clientes ao mesmo tempo.

O problema é que a cozinha (os servidores de GPU) é limitada. Se todos os clientes pedirem pratos gigantes ao mesmo tempo, a cozinha entra em colapso, a comida demora horas para sair e ninguém fica feliz.

Até hoje, os restaurantes tentavam resolver isso de duas formas ruins:

1. Mesas Reservadas (Endpoints Dedicados): Cada cliente tinha sua própria mesa e chef. Se o cliente não pedisse nada, a mesa ficava vazia e o chef parado, desperdiçando espaço.
2. Limite de Pedidos por Minuto (Rate Limits): O garçom dizia: "Você só pode pedir 10 pratos por minuto". Mas isso não funcionava bem, porque um "prato pequeno" (uma pergunta curta) gasta pouca energia da cozinha, enquanto um "banquete" (uma pergunta longa e complexa) gasta a energia de dez pratos pequenos. O limite de "10 pedidos" não levava em conta o tamanho real do trabalho.

O artigo que você enviou apresenta uma solução inteligente chamada "Pools de Tokens" (ou "Piscinas de Tokens"). Vamos usar uma analogia para entender como funciona:

A Analogia do "Crédito de Energia"

Em vez de contar apenas "quantos pedidos" você faz, o sistema agora conta quanto "combustível" (tokens) cada pedido vai gastar na cozinha.

Imagine que a cozinha tem um tanque de combustível limitado. O sistema de "Pools de Tokens" funciona como um gerente de energia inteligente que distribui esse combustível antes mesmo de você entrar na cozinha.

1. As Três Regras do Gerente (Os Recursos)

O gerente olha para três coisas antes de deixar um pedido entrar:

• Velocidade (Tokens por segundo): Quão rápido você quer que a comida saia?
• Espaço na Geladeira (KV Cache): Quanta memória a receita precisa para ser preparada? (Alguns pratos exigem geladeiras gigantes).
• Número de Cozinheiros (Concorrência): Quantos pratos podem ser feitos ao mesmo tempo na mesma panela?

2. Os Tipos de Clientes (Classes de Serviço)

O sistema trata os clientes de forma diferente, dependendo do que eles pagaram ou da importância do pedido:

• Clientes VIP (Dedicados/Garantidos): Eles têm uma mesa reservada. Mesmo que a cozinha esteja cheia, o pedido deles nunca é cancelado. Eles têm prioridade absoluta.
• Clientes Flexíveis (Elasticos): Eles têm um limite de consumo, mas podem pedir mais se sobrar espaço. Se a cozinha ficar cheia, eles podem ter que esperar um pouco, mas o sistema garante que, se eles esperaram muito, receberão um "cupom de desconto" (crédito) para serem atendidos mais rápido depois.
• Clientes de Oportunidade (Spot/Preemptíveis): Eles só podem comer se sobrar comida. Se a cozinha ficar cheia, o pedido deles é cancelado imediatamente para dar lugar aos VIPs. É como comer sobras de buffet: se sobrar, ótimo; se não, você fica sem.

3. O Sistema de "Dívida" (Debt Mechanism)

Esta é a parte mais brilhante da ideia.
Imagine que o cliente "Flexível" teve que esperar muito porque a cozinha estava cheia. O sistema anota isso como uma dívida.

• Quando a cozinha esvazia um pouco, o sistema olha para as "dívidas".
• Quem deve mais (quem esperou mais) ganha prioridade para ser atendido primeiro, mesmo que não seja um VIP.
• Isso garante que ninguém fique esperando para sempre. É como um sistema de justiça que diz: "Você sofreu muito ontem, hoje você passa na frente".

O Que Acontece na Prática?

O artigo fez dois testes em um laboratório (um pequeno servidor de IA):

1. Teste de Proteção: Um cliente "barulhento" (com muitos pedidos baratos) tentou inundar o sistema.

   • Sem o novo sistema: Todos os clientes, inclusive os VIPs, ficaram com a comida demorando horas.
   • Com o novo sistema: O gerente bloqueou os pedidos baratos imediatamente. Os VIPs continuaram recebendo comida rápida (menos de 1,2 segundos), e os pedidos baratos foram rejeitados educadamente, pedindo para tentarem mais tarde.

2. Teste de Justiça: Dois clientes flexíveis competiam por espaço. Um queria a comida agora (urgente), o outro podia esperar (não urgente).

   • O sistema deu prioridade ao urgente.
   • Mas, como o "não urgente" ficou esperando, ele acumulou "dívida".
   • Com o tempo, a dívida dele aumentou tanto que ele começou a ganhar prioridade sobre o urgente, garantindo que ele não fosse esquecido.

Resumo Simples

O artigo propõe mudar a forma como controlamos o acesso à Inteligência Artificial. Em vez de apenas dizer "pare de pedir", o sistema agora diz: "Quanto esse pedido vai custar de energia e quem tem direito a essa energia agora?".

É como ter um semáforo inteligente que não apenas fecha a rua para todos, mas decide quem passa com base no tamanho do carro, na urgência da viagem e em quem ficou parado no trânsito ontem. Isso garante que os carros de emergência (serviços críticos) sempre passem, enquanto os carros comuns (serviços flexíveis) compartilham o espaço de forma justa e dinâmica.

Em uma frase: É um sistema de gestão de filas para IA que é justo, rápido e impede que um único usuário "trave" o sistema para todos os outros.

Resumo técnico

1. O Problema

As plataformas de inferência de IA multi-tenant (multi-inquilino) enfrentam um desafio fundamental: equilibrar a alta utilização de recursos com garantias de nível de serviço (SLOs) sob demanda variável. As abordagens convencionais falham em atingir esse equilíbrio por dois motivos principais:

• Endpoints Dedicados: Garantem isolamento, mas deixam capacidade ociosa (estrangulada) quando os modelos não estão sendo usados, exacerbando ineficiências devido à longa cauda de modelos pouco utilizados.
• Limites de Taxa (Rate Limits) Tradicionais: Gerenciam a admissão de requisições sem considerar o custo real de execução. Por exemplo, limitam "tokens por minuto", mas tratam todos os tokens como iguais, ignorando que requisições com contextos longos consomem muito mais memória de cache (KV Cache) e tempo de GPU do que requisições curtas.

Além disso, o tráfego de inferência é caracterizado por "rajadas" (bursts) heterogêneas (comprimento de prompt, comprimento de saída, concorrência) que esgotam recursos específicos (como o KV Cache) de formas que os limitadores de taxa convencionais não conseguem prever ou mitigar, levando à degradação de latência para todos os usuários durante períodos de sobrecarga.

2. Metodologia: Token Pools (Pools de Tokens)

O artigo propõe uma nova abstração de controle chamada Token Pools, que representa a capacidade de inferência em unidades nativas de inferência, em vez de unidades genéricas de computação (como CPU/GPU).

Modelo de Recursos

O sistema gerencia três recursos escaláveis principais:

1. Throughput de Tokens ($\lambda$): Taxa de produção de tokens (tokens/segundo).
2. Capacidade de KV Cache ($\chi$): Memória necessária para o estado de atenção (bytes).
3. Concorrência ($r$): Número de sequências de inferência ativas simultaneamente.

Mecanismos Principais

• Entitlements (Direitos): Os inquilinos possuem "entitlements" que definem suas cota de capacidade. Diferente de limites estáticos, esses direitos autorizam tanto a admissão de API quanto decisões de autoscaling baseadas em um modelo de capacidade unificado.
• Classes de Serviço: Define uma hierarquia de proteção (Dedicado, Garantido, Elástico, Spot, Preemptível).
  • Dedicado/Garantido: Nunca são reduzidos.
  • Elástico: Podem ser reduzidos abaixo da base, mas acumulam "dívida".
  • Spot: Não têm garantia, são os primeiros a sofrer throttling (limitação).
• Mecanismo de Prioridade e Dívida:
  • A prioridade de uma requisição é calculada dinamicamente combinando a classe de serviço, a urgência do SLO, o histórico de rajadas e a dívida de serviço acumulada.
  • Dívida ($d_e$): Se um inquilino elástico recebe menos recursos do que sua cota base (underservice), ele acumula dívida. Isso aumenta sua prioridade futura, garantindo que receba recursos compensatórios quando a capacidade estiver disponível, promovendo uma convergência justa (fair-share).
• Arquitetura de Controle:
  • O sistema opera como uma camada de controle (control-plane) acima dos runtimes de inferência existentes (como vLLM) e do agendador do Kubernetes.
  • Utiliza Nós Virtuais no Kubernetes para representar a capacidade do pool de tokens.
  • O Gateway de API realiza o controle de admissão: antes de enviar uma requisição ao backend, verifica se o entitlement do inquilino pode "financiar" o custo estimado da requisição. Se o pool estiver sobrecarregado, requisições de baixa prioridade (ex: Spot) são rejeitadas com HTTP 429, protegendo as de alta prioridade.

3. Contribuições Chave

1. Formalização de Recursos Nativos: Decomposição da capacidade de inferência em throughput, KV Cache e concorrência, com um mecanismo de prioridade que integra classe de serviço, SLO e dívida.
2. Arquitetura de Admissão no Gateway: Uma implementação que repurciona o agendador do Kubernetes (via nós virtuais) para controle de admissão de capacidade de tokens, sem modificar os runtimes de inferência subjacentes.
3. Mecanismo de Dívida para Justiça: Um sistema de feedback que garante que inquilinos elásticos recebam compensação por períodos de escassez, evitando a fome (starvation) e promovendo equidade entre cargas de trabalho com SLOs heterogêneos.

4. Resultados Experimentais

Os autores realizaram dois experimentos em um cluster Kubernetes com backend vLLM:

• Experimento 1: Proteção Interclasse (Cross-Class Protection)

  • Cenário: Sobrecarga onde tráfego "Spot" (baixa prioridade) ameaça degradar o tráfego "Garantido".
  • Resultado: Com Token Pools, a latência P99 para cargas de trabalho garantidas foi mantida abaixo de 1,2 segundos, mesmo durante a sobrecarga. O sistema rejeitou seletivamente o tráfego Spot.
  • Comparação: Sem controle de admissão, a latência degradou para mais de 19 segundos para todos os usuários devido ao acúmulo de filas.

• Experimento 2: Compartilhamento Justo Sensível a SLO (SLO-Aware Fair Share)

  • Cenário: Escassez de capacidade (falha de nó) com múltiplos inquilinos "Elásticos" tendo diferentes requisitos de latência (ex: assistente de código de 500ms vs. pipeline de dados de 30s).
  • Resultado: O sistema direcionou o throttling para a carga de trabalho com SLO mais relaxado (pipeline de dados), protegendo a de baixa latência.
  • Mecanismo de Dívida: O inquilino com SLO relaxado acumulou dívida, o que aumentou sua prioridade ao longo do tempo, garantindo que ele recebesse uma fatia crescente de recursos e não fosse totalmente ignorado, demonstrando convergência justa.

5. Significado e Conclusão

O trabalho demonstra que o controle de admissão deve ocorrer na fronteira da API (Gateway), e não apenas no nível do agendador de GPUs. Ao tomar decisões antes da execução, o sistema pode degradar-se graciosamente, rejeitando requisições de baixa prioridade para preservar a qualidade de serviço das críticas.

A proposta de Token Pools oferece uma solução prática para a maturidade da infraestrutura de inferência de IA, permitindo:

• Isolamento de ruído entre vizinhos (noisy neighbors).
• Utilização eficiente de recursos através de backfill de tráfego de baixa prioridade.
• Justiça dinâmica baseada em dívida, sem a necessidade de reconfiguração manual de limites durante falhas ou picos de demanda.

Esta abordagem permite a adoção em plataformas existentes (como Kubernetes com vLLM) sem a necessidade de substituir os motores de execução maduros, focando apenas na camada de gerenciamento de recursos e políticas.