TraceSpec aumentou em 12,5–22,6% o throughput do DSpark para agentes de LLM

Uma equipe da Renmin University of China e da Huawei apresentou o TraceSpec, que combina um conjunto de avaliação e um método de treinamento do modelo rascunho na decodificação especulativa de agentes. A ideia parte de um fato: o agente faz dezenas de chamadas ao modelo sobre um histórico que cresce com raciocínios, ações e respostas de ferramentas, e a métrica média habitual de aceitação de tokens mistura decisões completamente diferentes. O TraceSpec analisa essas decisões separadamente e depois treina o rascunho nos pontos em que ele mais costuma divergir do modelo-alvo. Em Qwen3 de 4B, 8B e 14B, com duas temperaturas, o throughput no modo replay subiu 12,5–22,6% em relação ao DSpark de base.

Por que a métrica média engana

Os autores primeiro mediram como a decodificação especulativa se comporta no trabalho real de um agente. Usaram dois cenários: BrowseComp-Plus (busca de respostas em documentos da web) e SWE-bench Verified (correção de bugs reais em repositórios). No DSpark com Qwen3-8B, o comprimento médio aceito em navegação subiu de 3,633 tokens por rodada, com contexto de até 2k, para 5,479 com contexto de 16k–32k. No mesmo intervalo, o throughput caiu de 82,73 para 22,54 tokens por segundo. Em engenharia de software, caiu de 73,83 para 28,19 tokens por segundo.

À primeira vista, isso parece indicar que "contexto longo ajuda o rascunho". Porém, quando os pesquisadores compararam ações tardias equivalentes de navegação dentro das mesmas tarefas, a aceitação diminuía. O aumento da métrica média se explica pela composição das chamadas: históricos longos contêm mais consultas curtas e previsíveis a ferramentas. No cenário SWE, a curva sequer é monotônica: o comprimento aceito atinge o pico em 8k–16k e cai em 16k–32k nos três métodos testados, DFlash, EAGLE-3 e DSpark.

Como funcionam o corpus e o treinamento

Para uma comparação justa, foi criado o TraceSpec-Traj: 10 000 estados de treino e 2 500 de teste, divididos igualmente entre pesquisa na web e engenharia de software. O estado é o histórico até a próxima jogada do assistente, junto com a fase (planejamento, ação, reflexão, resposta final), o comprimento do prefixo e a posição na trajetória. O corpus cobre as 40 combinações de dois domínios, cinco faixas de contexto e quatro fases. As trajetórias vêm do DeepResearch-traj, dos dados do Nebius SWE-agent e das coleções R2E-Gym; as tarefas de treino e de teste não se sobrepõem. No replay, os cinco métodos de base recebem os mesmos prefixos salvos.

O TraceSpec mantém a arquitetura e a função de destilação do DSpark. Mudam os dados e a proporção deles no treinamento. Em vez de respostas finais, o rascunho é treinado em todos os passos intermediários das trajetórias geradas pelo modelo-alvo. Para cada estado, estima-se a lacuna de aceitação com correção por prefixo: uma divergência precoce interrompe a cadeia de tokens aceitos em sequência, por isso seu peso é maior. A estimativa é suavizada por contexto, fase, tipo de tarefa e estado da ferramenta. O orçamento de previsões é fixo, e consultas curtas a ferramentas e raciocínios longos geram números diferentes de previsões, por isso a amostragem é normalizada pelo número de eventos.

O que os experimentos mostraram e quais são os limites

Os autores compararam o TraceSpec com cinco métodos de base em 108 configurações. No replay, ele lidera em todas as 24 comparações por fase. Em throughput de geração, supera o DSpark em 15 de 18 configurações, ou seja, o ganho não aparece em todas. Entre os métodos de base, o DSpark teve o maior comprimento aceito em todas as 18 comparações, e, na passagem da temperatura 0 para 1, o comprimento aceito cai em cada um deles.

As ablações no Qwen3-4B mostram a contribuição de cada parte. A alocação adaptativa do orçamento aumenta o comprimento aceito em 3,3–10,0% em comparação com o treinamento fixo em passos completos. Comparações adicionais confirmam a utilidade das condições de estado e da contagem de tokens aceitos em sequência.

As limitações também são visíveis. O ganho principal de 12,5–22,6% foi medido no replay de prefixos salvos, e não na latência ponta a ponta dos episódios. Foram testados apenas modelos Qwen3 e dois cenários, navegação e programação. O trecho do artigo termina na análise do custo dos episódios, então o ganho ponta a ponta no tempo da tarefa não pode ser confirmado aqui. A conclusão prática para quem opera agentes: antes de ajustar o rascunho, vale decompor a aceitação por fase e por posição na trajetória. Os autores publicaram o código e os recursos no GitHub, no repositório Robot2050/TraceSpec.