The Pulse
Un nuovo benchmark misura il costo in latenza degli handshake tra agenti
Il benchmark pubblicato su arXiv da Pranav Varshney confronta il costo degli handshake nei protocolli per agenti MCP, A2A e ACP. Rileva che i round trip determinano la latenza delle connessioni iniziali, mentre la cache può ridurre nettamen
AI.info Team · Scritto con l’IA · verificato ·
Nel nuovo benchmark, un handshake della versione precedente del Model Context Protocol (MCP) richiede 230 millisecondi; una connessione Agent2Agent (A2A) ne richiede 61. Il confronto, però, ha una sfumatura importante: un’architettura più recente di MCP riduce a 122 millisecondi il tempo misurato per la connessione iniziale, e la cache può eliminare del tutto gli scambi di rete nelle connessioni successive. I risultati, pubblicati da Pranav Varshney su arXiv il 12 agosto, quantificano un costo che i confronti tra protocolli per agenti hanno spesso considerato un criterio di progettazione senza misurarlo.
«Il numero di round trip è il fattore dominante nel costo dell’handshake.»
Pranav Varshney, «The Cost of Saying Hello: An Empirical Study of Handshake Overhead in AI Agent Communication Protocols»
Tre round trip contro uno
Un handshake è lo scambio che permette a un agente di trovare un altro sistema, sapere cosa può fare e accertare che sia pronto a ricevere un compito. Varshney ha misurato questa fase in MCP, A2A e nell’Agent Communication Protocol (ACP), usando l’SDK Python ufficiale di ciascun protocollo e una controparte minimale che espone una sola capacità. Il benchmark rileva i round trip a livello applicativo, la latenza, i byte e i token dei metadati per le connessioni iniziali, quelle successive, le incompatibilità tra capacità e le condizioni degradate.
Per le connessioni iniziali, lo studio riporta una latenza mediana di 230 millisecondi per la versione precedente di MCP, 122 millisecondi per la revisione di MCP del 2026, 61,0 millisecondi per A2A e 62,1 millisecondi per ACP, con un tempo di round trip simulato di 50 millisecondi. Gli handshake testati richiedevano tre round trip a livello applicativo per la versione precedente di MCP, due per quella più recente e uno ciascuno per A2A e ACP. Sono misurazioni relative agli SDK e alle configurazioni usati, non una classifica universale di tutte le implementazioni.
Il nuovo handshake di MCP riduce il divario
Il confronto tra le due versioni di MCP rende più complicato formulare un verdetto semplice. Secondo il paper, la revisione più recente sostituisce l’inizializzazione precedente, composta da tre messaggi, con una richiesta esplorativa e risultati memorizzabili nella cache; nel benchmark, questo cambiamento riduce del 47% la latenza della connessione iniziale rispetto alla versione precedente di MCP. Con la politica predefinita dell’SDK per le connessioni successive, la versione più recente di MCP effettua ancora un round trip e registra una mediana di 63,5 millisecondi. Quando il client fissa la versione del protocollo usata dalla controparte e riutilizza i metadati nella cache, diventa pronto senza alcuno scambio di rete; anche A2A e ACP arrivano a connessioni successive senza round trip quando le rispettive schede o i rispettivi manifest sono nella cache.
Questi vantaggi dipendono dal fatto che la controparte sia già nota. Una prima connessione a una controparte sconosciuta richiede comunque di recuperare ed esaminare le informazioni sulle capacità, mentre le descrizioni nella cache possono diventare obsolete. Il paper ha inoltre rilevato che, in caso di incompatibilità tra capacità, i client testati sostengono il costo dell’intero handshake prima di poter rifiutare una controparte: con un tempo di round trip simulato di 50 millisecondi, sono serviti 231 millisecondi per la versione precedente di MCP e circa 58-62 millisecondi per A2A e ACP.
Gli elenchi delle capacità comportano un costo separato in token
La latenza di rete è solo una parte del costo della connessione quando un LLM legge i metadati dell’altro agente. In un test che ha portato gli elenchi delle capacità a 200 voci, il paper conta 4.891 token per A2A, 15.618 per MCP e 21.405 per ACP. La cifra di ACP equivale a circa l’11% di una finestra di contesto da 200.000 token; la stessa percentuale non vale per tutti i protocolli. Varshney stima un costo marginale dei metadati che va da 24 token per capacità per A2A a 107 per ACP, con MCP a 78.
Le stime dei token derivano da voci replicate nei metadati acquisiti, conteggiate con il tokenizer o200k_base; non sono osservazioni di agenti con 200 capacità in produzione. L’autore osserva inoltre che l’esperimento usa configurazioni anonime ed esclude l’autenticazione, che potrebbe aggiungere ulteriori scambi. La condizione di rete con un tempo di 50 millisecondi è simulata a livello applicativo e i valori riportati escludono l’avvio delle connessioni TCP e TLS su una rete reale.
Un benchmark sulla fase di connessione, non sulle prestazioni nei compiti
ACP resta nel confronto anche se nel 2025 il suo progetto è confluito in A2A, perché esistono ancora implementazioni in uso e la sua architettura con un solo round trip offre allo studio un ulteriore termine di paragone. Il paper misura soltanto la fase di connessione, non la capacità degli agenti di portare a termine i compiti una volta connessi. Varshney afferma che la struttura di test del benchmark, i dati grezzi di ogni esecuzione e l’analisi sono disponibili insieme al paper, così che i team possano esaminare o riprodurre le misurazioni usando le versioni degli SDK testate.
Il risultato più chiaro non è la vittoria complessiva di un protocollo, ma una conclusione più circoscritta: nelle connessioni iniziali testate, meno scambi hanno significato meno attesa, mentre i metadati riutilizzabili hanno reso molto meno costose le connessioni successive. Per un elenco di 200 capacità, i metadati misurati variavano da 4.891 token in A2A a 21.405 in ACP.