💻 informatica

Break Later or Never: Prefix-Preserving Context Compaction for Coding Agents

Questo articolo affronta il conflitto tra la compattazione del contesto e il prefix caching negli agenti di codifica introducendo il "batched observation masking" e "ObsDrop", una tecnica a livello di KV-cache che rilascia i dati obsoleti di tool-osservazione preservando al contempo il prefisso logico dei token, migliorando così significativamente il throughput e la latenza senza compromettere la qualità del compito.

Autori originali: Musa Cim, Burak Topcu, Mahmut Kandemir

Pubblicato 2026-11-11

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Musa Cim, Burak Topcu, Mahmut Kandemir

Articolo originale sotto licenza CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immaginate un programma per computer progettato per scrivere codice, correggere bug software o risolvere complessi problemi di ingegneria. Questi "agenti di programmazione" non lavorano in un unico colpo; operano in una lunga conversazione ciclica con un modello linguistico di grandi dimensioni. In ogni passaggio, l'agente pensa, emette un comando a uno strumento (come aprire un file o eseguire un test) e poi legge il risultato. Poi ripete il processo, aggiungendo il nuovo risultato alla sua cronologia. Con il tempo, questa cronologia si trasforma in un documento massiccio contenente decine di migliaia di parole. Per mantenere il sistema in funzione, il computer deve ricordare ogni singola parola di questa conversazione per comprendere il passaggio attuale. Questo requisito di memoria crea un carico pesante, rallentando il sistema e rendendolo costoso da gestire.

Per gestire questo accumulo crescente di testo, gli ingegneri hanno sviluppato modi per rimpicciolire la cronologia, un processo chiamato compattazione del contesto. Il metodo più comune è semplicemente eliminare parti della conversazione o sostituirle con un breve riassunto. Tuttavia, esiste una trappola nascosta in questo approccio. I moderni computer sono incredibilmente efficienti nel riutilizzare il lavoro già svolto. Se una nuova richiesta inizia con le stesse identiche parole di una precedente, il computer può saltare il lavoro pesante e passare direttamente alla parte nuova. Ma se si elimina o si riscrive l'inizio della conversazione, anche solo leggermente, il computer perde la memoria del passato e deve ricominciare il calcolo pesante da zero. I ricercatori dietro questo studio hanno scoperto che l'atto stesso di cercare di risparmiare spazio modificando il testo spesso costringe il computer a fare molto più lavoro, annullando qualsiasi risparmio e, a volte, rendendo il sistema più lento e costoso.

Il team, basato alla Pennsylvania State University, si è posto l'obiettivo di comprendere questo conflitto tra il risparmio di spazio e il risparmio di tempo. Hanno osservato che gli agenti di programmazione ripetono naturalmente quasi l'intera cronologia della loro conversazione in ogni singolo passaggio. Poiché la cronologia viene principalmente solo aggiunta, come un diario dove si scrivono solo nuove voci in fondo, il computer può riutilizzare i suoi calcoli precedenti quasi perfettamente, raggiungendo un tasso di riutilizzo del 98-99 percento. La parte più grande di questo costo di memoria non deriva dai pensieri dell'agente, ma dai dati grezzi che riceve, come il contenuto dei file o i log dei test software. I ricercatori hanno scoperto che quando utilizzavano metodi standard per eliminare o riassumere questi vecchi file, interrompevano la catena del riutilizzo. Il computer era costretto a rileggere e ricalcolare tutto ciò che seguiva la cancellazione, trasformando un compito rapido in uno lento e costoso.

Per risolvere questo problema, i ricercatori hanno prima testato un semplice aggiustamento al modo in cui avviene l'eliminazione. Inveve di eliminare le vecchie informazioni dopo ogni singolo passaggio, hanno provato a eliminarle solo una volta ogni pochi passaggi. Questo piccolo cambiamento, che chiamano "mascheramento a lotti" (batched masking), ha permesso al computer di mantenere intatta la propria memoria per periodi più lunghi. Ha ridotto l'importante quantità di testo che l'agente doveva trasportare fino alla metà, mantenendo comunque alto il tasso di riutilizzo della memoria del computer, tra il 95 e il 98 percento. Questo approccio ha ridotto il costo di esecuzione dell'agente fino al 18 percento e ha fatto completare i compiti fino al 21 percento più velocemente. Si è trattato di una soluzione pratica che non richiedeva modifiche al software sottostante del computer, ma semplicemente un modo più intelligente di programmare le eliminazioni.

Tuttavia, il team si è reso conto che anche questo miglioramento comportava comunque la riscrittura del testo, il che inevitabilmente interrompeva la catena della memoria al momento della cancellazione. Hanno quindi sviluppato una soluzione più avanzata chiamata ObsDrop. Invece di eliminare parole dal testo che l'agente vede, ObsDrop lavora all'interno della memoria stessa del computer. Mantiene il testo esattamente com'è, in modo che il computer possa ancora riconoscere il pattern e riutilizzare i propri calcoli precedenti. Ma in background, rilascia silenziosamente le posizioni di memoria che contengono i dati vecchi e irrilevanti, come il contenuto dei file che non sono più necessari. Ciò consente al computer di mantenere intatta la cronologia logica per la velocità, pur liberando fisicamente lo spazio necessario per eseguire più agenti contemporaneamente.

I ricercatori hanno testato questo nuovo sistema su potenti server che eseguivano più agenti simultaneamente. Hanno scoperto che all'aumentare del numero di agenti, i metodi standard iniziavano a soffrire, con il sistema che rallentava drasticamente man mano che finiva la memoria o doveva ricalcolare costantemente. Al contrario, il sistema ObsDrop manteneva la sua velocità ed efficienza. Sotto carico pesante, ha permesso ai server di elaborare tra le 2,45 e le 2,85 volte più lavoro rispetto a prima e, in alcune configurazioni specifiche, il miglioramento ha raggiunto oltre cinque volte la velocità originale. Il sistema ha gestito la pressione senza perdere la qualità del lavoro prodotto dagli agenti.

Questo lavoro evidenzia una lezione cruciale per il futuro dell'intelligenza artificiale: gestire la memoria di un agente intelligente non riguarda solo quanto testo si conserva, ma come lo si conserva. Comprendendo che la capacità del computer di riutilizzare il lavoro passato è fragile, i ricercatori hanno dimostrato che una gestione efficace richiede di preservare la struttura della conversazione anche mentre si scartano i dati. Il loro nuovo metodo, ObsDrop, offre un modo per avere entrambe le cose: un'impronta di memoria più snella e un sistema più veloce e reattivo, garantendo che questi potenti strumenti di programmazione possano scalare per affrontare i problemi complessi di domani senza restare bloccati dalla propria cronologia.

Riepilogo Tecnico: Break Later or Never: Prefix-Preserving Context Compaction for Coding Agents

Problematica

Gli agenti di coding operano invocando ripetutamente i Large Language Models (LLM) su cronologie in crescita e di tipo append-only, composte da ragionamento, chiamate a strumenti (tool calls) e osservazioni degli strumenti (tool observations). Questo carico di lavoro è unicamente favorevole al prefix caching, poiché ogni nuova richiesta tipicamente riutilizza la stratta maggior parte del contesto precedente, permettendo ai motori di serving di saltare la costosa fase di "prefill" per i token ripetuti.

Tuttavia, esiste un conflitto critico tra la compattazione del contesto (necessaria per gestire memoria e costi man mano che le traiettorie crescono) e il prefix caching. I metodi di compattazione tradizionali (ad esempio, troncamento, mascheramento, riassunto) riscrivono la cronologia del prompt. Poiché il prefix caching si basa sull'esatta corrispondenza dei token, qualsiasi modifica al prompt invalida la cache Key-Value (KV) per quel prefisso e per tutti i token successivi. Ciò costringe il sistema a ricalcolare (re-prefill) l'intero suffisso, annullando i risparmi computazionali derivanti dalla cache. Il paper identifica che, sebbene le osservazioni degli strumenti (viste di file, log dei test) costituiscano la maggior parte del costo del contesto, rimuoverle tramite l'editing del prompt rompe la cache del prefisso, rendendo potenzialmente un prompt più corto più costoso da servire rispetto a uno più lungo e non modificato.

Metodologia

Gli autori caratterizzano questa interazione e propongono soluzioni a due livelli: a livello di prompt e a livello di cache KV.

1. Caratterizzazione e Mitigazione a Livello di Prompt

Anatomia del Costo: Lo studio analizza le traiettorie degli agenti di coding su SWE-bench (Verified e Multilingual) utilizzando i modelli Qwen3-Coder e Devstral-Small. Risulta che, senza compattazione, i tassi di hit del prefix-cache sono del 98–99%. Il costo è dominato dalla rilettura delle osservazioni degli strumenti, non dal ricalcolo.
Valutazione delle Politiche Esistenti:
- Sliding Window (Finestra Scorrevole): Scarta i turni più vecchi. Sebbene riduca la lunghezza del prompt, sposta il punto di inizio del prefisso, causando un re-prefill del 100% della finestra ad ogni step. Ciò comporta elevati costi di serving e bassi tassi di successo del task.
- Observation Masking (Mascheramento delle Osservazioni): Sostituisce le vecchie osservazioni con segnaposto. Sebbene preservi meglio il successo del task rispetto alle finestre scorrevoli, modifica comunque il prompt ad ogni step, invalidando la cache del prefisso e forzando i re-prefill.
- LLM Summarization (Riassunto tramite LLM): Sostituisce la cronologia con un riassunto. Questo introduce un overhead di decodifica (generazione del riassunto) e può causare la perdita di informazioni critiche, riducendo il successo del task nei benchmark multilingue.
Batched Observation Masking (Mascheramento delle Osservazioni a Batch): Gli autori propongono una semplice mitigazione in cui il mascheramento delle osservazioni viene applicato solo una volta ogni $k'$ turni (ad esempio, ogni 8 step) invece che ad ogni step. Ciò ammortizza il costo di invalidazione del prefisso, preservando il 95–98% del riutilizzo del prefisso pur riducendo la lunghezza del contesto.

2. ObsDrop: Compattazione a Livello di KV

Per risolvere completamente il conflitto tra compattazione e caching, gli autori introducono ObsDrop, un meccanismo che disaccoppia la sequenza logica di token (il prompt inviato al modello) dalla residenza fisica dei KV (ciò che è memorizzato nella memoria della GPU).

Meccanismo: ObsDrop lascia invariati il prompt e le posizioni dei token per garantire che il matching del prefisso rimanga valido. Tuttavia, rilascia le voci KV corrispondenti alle osservazioni degli strumenti obsolete dalla memoria della GPU.
Implementazione:
- SGLang: Implementato all'interno della cache RadixAttention. ObsDrop identifica gli intervalli di osservazione, sostituisce i loro indici di slot KV con uno slot "morto" riservato (indice 0) e restituisce gli slot fisici all'allocatore. Il kernel di attention viene quindi istruito a saltare questi slot morti.
- Sparse-vLLM: Implementato come uno strato indipendente che rilascia le voci KV delle vecchie osservazioni mantenendo la struttura logica del prefisso.
Ottimizzazione: Per evitare l'overhead a runtime, il tracciamento degli slot morti è gestito sulla CPU e le liste degli indici di attention vengono rimosse in un singolo passaggio sulla GPU prima dell'esecuzione del kernel, preservando i CUDA graph.

Contributi Chiave

Caratterizzazione: Il paper dimostra che gli edit del prompt sono una componente del costo di compattazione precedentemente trascurata. Negli agenti di coding, l'alto tasso di riutilizzo del prefisso significa che rompere la cache del prefisso è spesso più costoso dei risparmi di memoria ottenuti con la compattazione.
Prompt Compaction-Aware (Compattazione del Prompt Consapevole del Prefisso): Gli autori dimostrano che il batching del mascheramento delle osservazioni (mascheramento ogni $k'$ step) è una soluzione pratica, agnostica rispetto al motore, che preserva il 95–98% del riutilizzo del prefisso riducendo al contempo la lunghezza del contesto fino al 50%.
ObsDrop: Un nuovo meccanismo di compattazione a livello di KV che recupera la memoria per le osservazioni obsolete senza alterare il prompt logico. Ciò consente al sistema di mantenere il matching del prefisso riducendo al contempo la residenza KV e il lavoro di attention.
Valutazione End-to-End: Valutazione completa su SGLang e Sparse-vLLM, utilizzando backend FlashInfer e Triton, sotto diversi livelli di concorrenza.

Risultati

Livello Prompt (Mascheramento a Batch):
- Riduce la lunghezza media del contesto fino al 50%.
- Riduce il costo di serving fino al 18% e il tempo di completamento del task (TCT) fino al 21%.
- Mantiene tassi di successo del task comparabili a quelli senza compattazione.
Livello KV (ObsDrop):
- Throughput: In condizioni di alta concorrenza (16 agenti), ObsDrop raggiunge un throughput da 2,45× a 2,85× superiore con FlashInfer e fino a 5,37× con il backend Triton rispetto a nessuna compattazione.
- Latenza: ObsDrop riduce significativamente la latenza della coda (p95 TTFT) sotto pressione di memoria, prevenendo l'evizione della cache e i conseguenti cicli di re-prefill che affliggono gli scenari di "nessuna compattazione".
- Efficienza: ObsDrop riduce il volume di token soggetti ad attention del 19–44% attraverso diversi modelli e motori, abbassando direttamente i costi computazionali.
- Qualità: I tassi di successo del task rimangono vicini alla baseline di "nessuna compattazione", a differenza degli approcci di riassunto aggressivo o della finestra scorrevole che degradano le prestazioni.

Significato e Dichiarazioni

Il paper sostiene che la gestione efficace del contesto per gli agenti di coding deve considerare non solo quali token vengono mantenuti, ma anche come la compattazione interagisce con i meccanismi di caching del sistema di serving.

Il Trade-off: Gli autori affermano che il conflitto tra compattazione e prefix caching è fondamentale. Gli edit del prompt inevitabilmente rompono il riutilizzo della cache, mentre ObsDrop risolve questo problema operando a livello di KV.
Impatto Sistemico: ObsDrop fornisce un primitivo che permette ai motori di serving di recuperare memoria senza rompere la cronologia logica necessaria per il prefix caching. Ciò è particolarmente critico sotto carichi di lavoro concorrenti dove la pressione sulla memoria causa l'evizione della cache, portando a un aumento netto della latenza della coda.
Dichiarazioni Modeste: Gli autori riconoscono che l'intervallo di batching ottimale ( $k'$ ) può variare per traiettoria e che la loro implementazione in vLLM richiede un ulteriore disaccoppiamento dell'identità del blocco dalla residenza KV. Posizionano ObsDrop non come un sostituto universale per tutte le tecniche di compressione, ma come una soluzione specifica per l'unico carico di lavoro "append-only, observation-heavy" degli agenti di coding.

In sintesi, il paper dimostra che preservando il prefisso logico pur eliminando fisicamente i dati delle osservazioni obsolete, gli agenti possono ottenere miglioramenti significativi in termini di prestazioni e costi senza sacrificare la qualità del task.