Local-Splitter: A Measurement Study of Seven Tactics for Reducing Cloud LLM Token Usage on Coding-Agent Workloads

Resumo Técnico: Local-Splitter

1. O Problema

Os custos de API de Grandes Modelos de Linguagem (LLMs) na nuvem tornaram-se uma despesa operacional significativa para empresas de ferramentas de desenvolvimento. Agentes de codificação modernos enviam dezenas de milhares de tokens para modelos de ponta (frontier models) por tarefa, grande parte dos quais consistem em repetições, boilerplate ou contexto que poderia ser processado localmente de forma mais barata.

Ao mesmo tempo, modelos locais pequenos (na faixa de 1–7 bilhões de parâmetros) evoluíram a ponto de responder corretamente a uma fração significativa de consultas de desenvolvedores em hardware de consumo. A questão central do artigo é: dado um modelo local pequeno e um modelo de nuvem de ponta, qual é a melhor maneira de dividir o trabalho entre eles para minimizar o uso total de tokens na nuvem, mantendo a qualidade da resposta próxima à linha de base?

2. Metodologia e Arquitetura

Os autores desenvolveram o Local-Splitter, um shim (camada de compatibilidade) de código aberto que atua como um intermediário inteligente entre o agente e o modelo de nuvem.

• Arquitetura: O sistema expõe duas interfaces: um servidor MCP (Model Context Protocol) e um proxy HTTP compatível com a API da OpenAI. Ele encaminha as requisições através de um pipeline de sete estágios, onde cada estágio corresponde a uma tática específica.
• Modelos Utilizados:
  • Local: Llama 3.2 3B (via Ollama) rodando em hardware Apple Silicon.
  • Nuvem (Simulado): Gemma 3 4B (também rodando localmente para eliminar variância de rede, simulando um modelo mais forte).
• Cargas de Trabalho (Workloads): O estudo avaliou quatro classes de cenários realistas de agentes de codificação:
  1. WL1 (Edição Intensa): Refatoração de código, muitas edições de arquivo.
  2. WL2 (Explicação Intensa): Onboarding, perguntas sobre o que um arquivo faz.
  3. WL3 (Chat Geral): Conversas mistas, não específicas de código.
  4. WL4 (RAG Intenso): Cargas com recuperação de informação (Retrieval-Augmented Generation) e contextos longos.

3. As Sete Táticas Propostas

O estudo sistematiza e implementa sete táticas ortogonais para reduzir tokens:

1. Roteamento Local (T1): Um modelo local classifica a requisição como "trivial" ou "complexa". Se trivial, é respondida localmente; se complexa, segue para a nuvem.
2. Compressão de Prompt (T2): O modelo local reescreve o contexto (histórico, sistema, documentos) para uma forma mais curta, preservando o significado semântico, antes de enviar à nuvem.
3. Cache Semântico (T3): Armazena respostas em um índice vetorial. Se uma nova consulta for semanticamente similar a uma anterior, a resposta é servida do cache sem chamar a nuvem.
4. Rascunho Local com Revisão na Nuvem (T4): O modelo local gera um rascunho completo da resposta. A nuvem é solicitada apenas a revisar ou corrigir esse rascunho (reduzindo tokens de saída), em vez de gerar do zero.
5. Edições de Diff Mínimo (T5): Para pedidos de edição, o modelo local identifica apenas o "hunk" (trecho) relevante do arquivo, enviando apenas esse contexto à nuvem em vez do arquivo inteiro.
6. Extração de Intenção Estruturada (T6): Converte prompts de texto livre em uma estrutura JSON {intenção, alvo, restrições}, removendo a "gordura" linguística antes de enviar à nuvem.
7. Agrupamento e Cache de Prompt do Fornecedor (T7): Agrupa múltiplas consultas rápidas em uma única requisição e utiliza recursos de cache nativos dos provedores de nuvem para prefixos estáveis.

4. Resultados Principais

O estudo mediu economia de tokens, custo em dólares, latência e qualidade (usando o modelo de nuvem como juiz).

• Combinação Ótima (T1 + T2): A combinação de Roteamento Local e Compressão de Prompt foi a mais eficaz em três das quatro cargas de trabalho, alcançando economias de 45% a 79% nos tokens da nuvem.
  • Em cargas de "Explicação Intensa" (WL2), essa combinação atingiu 79% de economia.
• Dependência da Carga de Trabalho: Não existe uma configuração "ligar tudo" universal.
  • Em cargas de Edição Intensa (WL1), ativar todas as táticas (incluindo T4) foi subótimo. A tática de rascunho (T4) aumentou o custo de entrada na nuvem (devido ao prompt de revisão) mais do que economizou na saída.
  • Em cargas RAG Intensas (WL4), o conjunto completo de táticas (incluindo T4) foi benéfico, alcançando 51% de economia, pois a geração de saída longa da nuvem justificou o custo do rascunho local.
• Qualidade: A combinação T1+T2 manteve a qualidade próxima à linha de base, embora tenha havido uma pequena degradação em cenários onde o modelo local tentou responder a consultas que realmente exigiam o modelo maior (falsos positivos no roteamento).
• Latência: O uso do modelo local adiciona latência por chamada (classificação), mas a redução geral de tokens na nuvem resulta em economia de custos significativa, mesmo com o aumento de latência local.

5. Contribuições e Significado

• Taxonomia e Implementação: O primeiro estudo a medir sistematicamente sete táticas distintas em um benchmark comum, com uma implementação de código aberto que suporta qualquer modelo local (Ollama) e qualquer endpoint de nuvem compatível com OpenAI.
• Descoberta Crítica: A conclusão mais acionável é que o subconjunto ótimo de táticas depende da carga de trabalho. Agentes devem perfilar seu tráfego (ex: é mais edição ou explicação? É RAG ou chat?) e selecionar as táticas correspondentes.
• Recomendações Práticas:
  1. Comece com T1 + T2 como padrão (roteamento + compressão).
  2. Adicione T4 (rascunho/revisão) apenas para cargas de trabalho com saídas longas (ex: RAG ou geração de código extenso).
  3. Adicione T3 (cache) para cenários com alta repetição de consultas (suporte, onboarding).
  4. Evite ativar todas as táticas cegamente, pois isso pode aumentar custos em cenários de saída curta.

Conclusão

O Local-Splitter demonstra que é possível reduzir drasticamente os custos operacionais de agentes de IA na nuvem sem sacrificar a usabilidade, desde que se utilize uma abordagem de "triagem local" inteligente. A chave não é apenas ter um modelo local, mas orquestrar dinamicamente quais táticas de economia de tokens são aplicadas com base no tipo de tarefa que o agente está executando. O código, as cargas de trabalho e a infraestrutura de avaliação foram disponibilizados publicamente para reprodução e extensão.