TraceSpec augmente de 12,5–22,6% le débit de DSpark pour les agents LLM

Une équipe de Renmin University of China et de Huawei présente TraceSpec, un ensemble composé d'un banc d'évaluation et d'une méthode d'entraînement du modèle brouillon pour le décodage spéculatif des agents. L'idée : un agent interroge le modèle des dizaines de fois sur un historique qui s'allonge, fait de raisonnements, d'actions et de réponses d'outils. La métrique habituelle, le taux moyen d'acceptation des tokens, mélange pourtant des décisions très différentes. TraceSpec les analyse séparément, puis entraîne le brouillon là où il diverge le plus souvent du modèle cible. Sur Qwen3 en 4B, 8B et 14B, à deux températures, le débit en mode rejeu progresse de 12,5–22,6% par rapport à la base DSpark.

Pourquoi la métrique moyenne est trompeuse

Les auteurs ont d'abord mesuré le comportement du décodage spéculatif dans le travail réel d'un agent. Ils ont utilisé deux scénarios : BrowseComp-Plus (recherche de réponses dans des documents web) et SWE-bench Verified (correction de vrais bugs dans des dépôts). Pour DSpark avec Qwen3-8B, la longueur moyenne acceptée en navigation web passe de 3,633 tokens par tour avec un contexte jusqu'à 2k à 5,479 avec un contexte de 16k–32k. Sur le même intervalle, le débit chute de 82,73 à 22,54 tokens par seconde. En génie logiciel, il recule de 73,83 à 28,19 tokens par seconde.

Pris isolément, ce résultat semble indiquer que « le contexte long aide le brouillon ». Mais lorsque les chercheurs ont comparé des actions de navigation tardives comparables au sein des mêmes tâches, l'acceptation baissait au contraire. La hausse de la métrique moyenne s'explique par la composition des appels : les longs historiques contiennent davantage de requêtes courtes et prévisibles vers les outils. Dans le scénario SWE, la courbe n'est même pas monotone : la longueur acceptée atteint un pic à 8k–16k, puis retombe à 16k–32k pour les trois méthodes testées, DFlash, EAGLE-3 et DSpark.

Comment sont conçus le corpus et l'entraînement

Pour une comparaison équitable, les auteurs ont constitué TraceSpec-Traj : 10 000 états pour l'entraînement et 2 500 pour le test, répartis à parts égales entre recherche web et génie logiciel. Un état correspond à l'historique précédant un tour de l'assistant, associé à la phase (planification, action, réflexion, réponse finale), à la longueur du préfixe et à la position dans la trajectoire. Le corpus couvre les 40 combinaisons de deux domaines, cinq plages de contexte et quatre phases. Les trajectoires proviennent de DeepResearch-traj, des données Nebius SWE-agent et des collections R2E-Gym ; les tâches des parties d'entraînement et de test ne se recoupent pas. En rejeu, les cinq méthodes de référence reçoivent exactement les mêmes préfixes sauvegardés.

TraceSpec conserve l'architecture et la fonction de distillation de DSpark. Ce sont les données et leur poids dans l'entraînement qui changent. Au lieu des réponses finales, le brouillon apprend sur tous les tours intermédiaires des trajectoires générées par le modèle cible. Pour chaque état, les auteurs estiment l'écart d'acceptation corrigé du préfixe : une divergence précoce interrompt la chaîne de tokens acceptés consécutivement, son poids est donc plus élevé. Cette estimation est lissée selon le contexte, la phase, le type de tâche et l'état de l'outil. Le budget de prédictions est fixe, et les requêtes courtes vers les outils comme les longs raisonnements produisent un nombre de prédictions différent : l'échantillonnage est donc normalisé par le nombre d'événements.

Ce que montrent les expériences et leurs limites

Les auteurs ont comparé TraceSpec à cinq méthodes de référence dans 108 configurations. En rejeu, il arrive en tête dans les 24 comparaisons par phase. Sur le débit de génération, il devance DSpark dans 15 des 18 réglages : le gain n'est donc pas systématique. Parmi les méthodes de référence, DSpark affiche la plus grande longueur acceptée dans les 18 comparaisons, et le passage de la température 0 à 1 fait baisser la longueur acceptée pour chacune d'elles.

Les ablations sur Qwen3-4B montrent la contribution de chaque composant. L'allocation adaptative du budget augmente la longueur acceptée de 3,3–10,0% par rapport à un entraînement fixe sur des tours complets. Des comparaisons supplémentaires confirment l'intérêt des conditions d'état et de la prise en compte des tokens acceptés consécutivement.

Les limites sont aussi visibles. Le gain principal de 12,5–22,6% a été mesuré en rejeu de préfixes sauvegardés, et non sur la latence de bout en bout des épisodes. Seuls les modèles Qwen3 et deux scénarios, la navigation web et la programmation, ont été testés. L'extrait de l'article s'interrompt sur l'analyse du coût des épisodes ; le gain de bout en bout sur le temps de tâche ne peut donc pas être confirmé ici. Conclusion pratique pour ceux qui exploitent des agents : avant de fine-tuner un brouillon, il vaut la peine de décomposer l'acceptation par phase et par position dans la trajectoire. Les auteurs ont publié le code et les ressources sur GitHub, dans le dépôt Robot2050/TraceSpec.