Chamadas especulativas de ferramentas cortam latência de agentes

Proposta e ganhos potenciais

O speculative programmatic tool calling (sPTC) é uma técnica para orquestradores que geram e executam código, como os baseados em REPL. A ideia é iniciar chamadas de ferramentas a partir de trechos parciais do código enquanto o modelo ainda transmite tokens, em vez de esperar a geração completa. Quando o programa final realmente faz a chamada, o resultado já pode estar disponível em cache. A proposta parte da visão de que o código em um REPL pode ser a principal ação do sistema, com outras ferramentas expostas como funções desse ambiente.

A técnica busca reduzir latência em dois pontos. Primeiro, sobrepõe chamadas já identificadas à geração do contexto principal, que pode ser demorada, sobretudo quando o modelo passa muito tempo “pensando”. Segundo, funciona como um compilador JIT simples para detectar chamadas independentes que o programa escreveu de forma bloqueante e executá-las em paralelo, mesmo sem o código usar explicitamente operações assíncronas. O método é considerado especialmente útil para chamadas a submodelos ou subagentes, que frequentemente têm latência alta e se tornam gargalos em orquestradores baseados em execução de código.

Como a especulação é controlada

A implementação propõe um contrato de biblioteca com um mecanismo que identifica quais ferramentas podem ser especuladas e registra seus resultados como promessas. Durante a transmissão, um espaço de nomes “sombreado” analisa o código parcial, lança chamadas permitidas de forma assíncrona e armazena os resultados. O REPL real consulta esse armazenamento quando a chamada ocorre; se não houver resultado especulado, executa a ferramenta normalmente.

Chamadas com argumentos literais, como textos ou números, podem ser reconhecidas diretamente. Dependências entre chamadas também podem ser antecipadas quando usam funções consideradas puras e sem efeitos colaterais: uma chamada posterior espera o resultado da anterior e é executada assim que ele chega. Condicionais e laços podem ser avaliados quando suas dependências são seguras. Já dependências que envolvem operações não permitidas, como ler um arquivo com open, bloqueiam a especulação daquela cadeia.

Para lidar com variáveis, condicionais e laços, a implementação mantém uma cópia profunda do REPL principal, chamada shadow REPL, que executa parcialmente o código sem alterar o estado real. Ferramentas e funções externas são marcadas como inseguras quando podem produzir efeitos colaterais. O executor especulativo não substitui o executor real, porque o código final pode conter erros ou chamadas incompletas. Além disso, chamadas idênticas precisam ser identificadas por seus argumentos e pela ocorrência, já que subchamadas não determinísticas não devem compartilhar automaticamente o mesmo resultado.

Resultados e limitações

Os testes foram feitos nos conjuntos OOLONG (trec-coarse, 132 mil) e OOLONG-Pairs (32 mil), em um nó com 8×H100 80B usando um servidor vLLM e o modelo Qwen3-30B-A3B-Instruct-0527. Foram comparadas temperaturas de 0,7 e 0,0, com cinco repetições, quatro ou oito execuções concorrentes e registro do número médio de subchamadas e turnos. A aceleração dos RLMs ficou geralmente entre 1× e 1,2×. O ganho exato é difícil de estimar, pois depende da latência das ferramentas, da quantidade de tokens, da carga do servidor e da trajetória escolhida pelo orquestrador; casos mais determinísticos foram considerados, mas não apresentados por serem específicos.

O custo adicional de tempo da implementação é descrito como geralmente pequeno, pois o analisador apenas verifica se uma chamada pode ser antecipada. A cópia do REPL tende a ser barata diante da memória ocupada por suas variáveis. O pior cenário ocorre quando o servidor da ferramenta fica congestionado por muitas requisições especulativas, algo que pode ser controlado pela agressividade da técnica e pela fila de chamadas.

Escopo futuro

Abordagens anteriores exploraram a sobreposição durante a decodificação ou wrappers assíncronos, mas a proposta argumenta que programas mais complexos oferecem mais oportunidades do que o chamado tradicional de ferramentas. No longo prazo, o maior ganho poderia vir de técnicas JIT mais sofisticadas, capazes de sobrepor chamadas à própria execução do REPL. A implementação atual cobre combinações de Python, bash e Bun com orquestradores de codificação, RLMs e agentes de jogos, mas o objetivo seria torná-la independente de linguagem e de orquestrador. O código apresentado pode ser integrado às implementações existentes como extensão.