Resumo Técnico: Uma Camada de Runtime Orientada a Políticas para Serviço de LLMs Agentes

1. Declaração do Problema

Sistemas de Grandes Modelos de Linguagem (LLM) multiagentes tornaram-se a carga de trabalho dominante em produção, mas a pilha de serviço existente está arquiteturalmente desalinhada com seus requisitos. Os sistemas atuais operam em uma estrutura de duas camadas:

1. Framework de Agentes (Topo): Sistemas como AutoGen, LangGraph ou MetaGPT que gerenciam identidades de agentes, esquemas de função e lógica de despacho. Eles emitem chamadas de API de LLM, mas permanecem cegos a eventos de nível de engine (por exemplo, geração de tokens, estado do cache KV).
2. Engine de Serviço (Base): Engines como vLLM ou SGLang que lidam com preenchimento inicial (prefilling), agrupamento (batching) e geração de tokens. Elas observam cada evento, mas não possuem conhecimento sobre identidades de agentes ou a estrutura semântica do fluxo de trabalho multiagente.

Essa "costura" cria uma lacuna crítica para políticas transversais. Muitas estratégias de otimização — como evicção de cache KV, modelagem de agrupamentos (batch shaping), execução especulativa, equidade e aplicação de segurança — exigem acesso simultâneo a metadados de identidade de agente (do framework) e eventos de nível de engine (da engine de serviço). Atualmente, essas políticas são implementadas como "correções pontuais" (one-off patches) em qualquer um dos lados, seja no framework ou na engine. Essa abordagem é frágil, não modular e falha em aproveitar o contexto completo necessário para a tomada de decisão ótima.

2. Metodologia: A Camada de Runtime de Agentes

Os autores propõem uma intervenção arquitetural: inserir uma terceira camada, a Camada de Runtime de Agentes, entre o framework e a engine de serviço. Essa camada atua como um substrato que possui os metadados transversais do agente e expõe uma interface estável e agnóstica a políticas.

Os Quatro Primitivos

A camada define quatro primitivas genéricas através das quais qualquer política consciente de agente pode ser integrada. Essas primitivas formam um ciclo de feedback observar → pontuar → prever → agir, unificado pela identidade do agente como coordenada compartilhada:

1. observe(event): O runtime recebe eventos relevantes para políticas dos vizinhos (por exemplo, toques em blocos, chegadas de solicitações, retornos de ferramentas). Ele atualiza o estado interno marcado pela identidade do agente.
2. score(item): O runtime retorna uma prioridade por item usada por um vizinho para classificar decisões (por exemplo, qual bloco KV evictar, qual solicitação admitir).
3. predict(horizon): O runtime retorna uma previsão probabilística da atividade futura do agente (por exemplo, o próximo papel do agente, próxima chamada de ferramenta).
4. act(side_effect): O runtime emite efeitos colaterais fora do caminho crítico para um vizinho (por exemplo, aquecer um cache, pré-carregar pesos, proteger uma chamada especulativa). Esta é a única primitiva que modifica o estado do vizinho.

Estudo de Caso: CacheSage

Para validar essa abstração, os autores instanciam a camada para cacheamento KV, a política com o maior impacto imediato nos custos de serviço. Eles introduzem o CacheSage, que aborda o problema de caches de prefixo reativos descartarem "âncoras de agente" (prompts de sistema e definições de ferramentas) antes que a próxima sessão chegue.

O CacheSage implementa as quatro primitivas através de três componentes:

• Aprendiz de Transição (observe): Mantém uma janela deslizante de contagens de transições pares de agentes ($n(a', a)$) para calcular uma matriz de transição de Markov de primeira ordem online. Ele identifica a "âncora de agente" (sistema + ferramentas) via hash de conteúdo.
• Avaliador de Probabilidade de Sobrevivência (score): Aproxima a probabilidade de um agente ser acionado dentro dos próximos $K$ passos. Em vez de cálculos exatos caros, ele usa um Grafo Acíclico Direcionado (DAG) com limite e uma Busca em Largura (BFS) para calcular um proxy de "contagem de saltos". Essa pontuação é combinada com o relógio de recência existente da engine para determinar a prioridade de evicção.
• Pré-busca entre Sessões (predict + act): Entre os passos do agendador, o runtime prevê o próximo agente ($a^*$) e emite uma solicitação de "aquecimento". Essa solicitação contém apenas o prompt de sistema e uma mensagem de usuário mínima para popular o cache KV para a âncora do agente previsto, sem injetar conteúdo específico completo da sessão.

3. Contribuições Principais

1. A Camada de Runtime de Agentes: Uma terceira camada proposta para a pilha de serviço que expõe uma interface de quatro primitivas (observe, score, predict, act). Os autores mapeiam nove políticas distintas conscientes de agentes (incluindo cacheamento KV, memoização de resultados de ferramentas, modelagem de agrupamentos e equidade) para essa interface, argumentando que todas compartilham a mesma necessidade arquitetural de eventos marcados com identidade de agente.
2. CacheSage: Uma implementação concreta da camada para cacheamento KV. Ele aprende matrizes de transição de agentes por carga de trabalho online e as utiliza para evicção baseada em sobrevivência e pré-busca entre passos. Opera com estado limitado ($\le$ 20 KB por carga de trabalho) e inclui um fallback gracioso para LRU padrão se nenhuma estrutura for aprendida.
3. Validação Empírica: Resultados preliminares em cinco cargas de trabalho multiagentes do mundo real (MMLU, MT-Bench, GAIA, GSM8K, HumanEval) demonstrando a eficácia da abordagem.

4. Resultados

Os experimentos foram conduzidos em GPUs NVIDIA H100 usando Llama-3.1-8B-Instruct, comparando o CacheSage com o vLLM e o Continuum.

• Taxa de Acerto no Cache: O CacheSage alcançou um aumento de +13 a +37 pontos percentuais (pp) nas taxas de acerto no cache em comparação com o vLLM em todas as cinco cargas de trabalho. Isso é atribuído à retenção de âncoras de agentes através de limites de sessão que caches reativos normalmente evictam.
• Latência: O Tempo Médio até o Primeiro Token (TTFT) e a latência ponta a ponta por turno foram reduzidos em 12% a 29%.
• Vazão (Throughput): A vazão do sistema aumentou em 6% a 14%.
• Sobrecarga: A sobrecarga do caminho quente é negligenciável. A função observe executa em $\sim1 \mu s$ por toque em bloco, e o avaliador executa em microssegundos de um único dígito. O estado do coordenador permanece abaixo de 25 KB.

Notavelmente, o sistema base Continuum, que usa pinos de TTL (Time-To-Live), na verdade reduziu as taxas de acerto em 9–23 pp em três cargas de trabalho de tarefas reais, destacando as compensações de políticas estáticas versus a natureza adaptativa da camada de runtime.

5. Significado e Alegações

O artigo alega que a "costura" entre o framework de agentes e a engine de serviço é melhor abordada por uma mudança arquitetural em vez de correções pontuais incrementais.

• Modularidade: A interface de quatro primitivas permite que políticas distintas compartilhem o mesmo fluxo de observação e se composam contra as mesmas primitivas sem exigir nova cirurgia na engine para cada política.
• Generalidade: A camada é agnóstica ao framework (suportando AutoGen, LangGraph, etc.) e portátil entre engines, exigindo apenas ganchos específicos em vez de modificações internas profundas.
• Validação da Lacuna: Ao demonstrar ganhos significativos de desempenho no cacheamento KV, os autores argumentam que a lacuna arquitetural é real e que uma camada de runtime de agentes é um componente necessário para o serviço eficiente de LLMs agentes.

Os autores permanecem modestos quanto ao escopo de seu trabalho atual, observando que, embora o CacheSage valide a abstração, as outras oito políticas mapeadas para a camada (por exemplo, memoização de resultados de ferramentas, execução especulativa de agentes, equidade) permanecem desafios abertos para trabalhos futuros. A contribuição principal é a interface e o argumento arquitetural, não a conclusão de cada implementação de política.