2026-09-22 · benchmark

Benchmark MCP: sette modelli, un formato

English version

Confronto controllato tra un server MCP che implementa il Mosaix Format e un file monolitico di contenuto identico. Sette LLM, quattro dimensioni di corpus, nove dimensioni di test. Il vantaggio architetturale regge su tutti i modelli — con due eccezioni istruttive.

Configurazione

Il benchmark confronta due bracci sullo stesso compito. Il braccio MCP usa un server che implementa la specifica Mosaix Format v1.2.0 — 11 tool tra cui search, read_note, write_note, compose e check. Le note sono atomiche: un'idea per nota, frontmatter auto-descrittivo (sommario, parole chiave, entità, link), ricerca BM25. Il braccio standard usa un singolo file contenente lo stesso contenuto come documento monolitico, con read_file e search_file come unici tool.

Il corpus è un catalogo di prodotti industriali (tubi idraulici, raccordi, innesti) a quattro dimensioni: 35 note, 65 note (258 KB), 143 note e 558 note (1 MB). Il monolite per il vault da 558 note è un file da 748 KB.

Sette LLM testati via OpenRouter: DeepSeek V4 Flash ($0,06/$0,14 per milione di token), GPT-5.6 Luna ($0,20/$1,20), Ministral 8B ($0,15/$0,15), GLM 5.3 Flash ($0,075/$0,25), Gemini 3.8 Flash ($0,75/$3,75), Qwen 3.8 Flash ($0,15/$0,47) e DeepSeek V4.1 Flash ($0,10/$0,40). Dati parziali per Claude Opus 4.8 e GPT-5.6 Sol (crediti esauriti a metà esecuzione).

Ogni esecuzione parte da zero: un nonce viene iniettato nel system prompt per annullare il prefix caching. Tutti i conteggi token sono non-cached. Ogni test è N=1 per braccio per modello.

Qualità delle risposte

Tre giudici LLM indipendenti hanno valutato le stesse sei risposte di entrambi i bracci su una scala 1–5 per accuratezza, completezza e pertinenza. I giudici non sapevano quale braccio avesse prodotto quale risposta.

Concordanza piena tra tre giudici di fornitori diversi. Il divario qualitativo (+1,5 punti) non è marginale — è la differenza tra una risposta incompleta che omette specifiche chiave e una risposta completa che cita codici prodotto specifici, pressioni nominali e range di temperatura. Il braccio monolite soffre perché il modello riceve l'intero documento e deve localizzare la sezione rilevante; il braccio MCP recupera solo le note pertinenti.

Costo RAG multi-turn

Sei domande consecutive sul catalogo, contesto cumulativo. Il modello deve cercare, leggere e rispondere — ogni turno si basa sul precedente. Questo è il benchmark di costo principale: misura il costo reale di retrieval su una sessione prolungata.

65 note (catalogo completo)

MCP costa il 6–56% del monolite su cinque dei sei modelli. Gemini 3.8 Flash è l'eccezione: genera meno tool call ma consuma più token per risposta MCP, rendendo il braccio atomico il 67% più costoso. Il dato è specifico del modello, non dell'architettura — il prezzo elevato per token di Gemini ($0,75/$3,75) amplifica anche piccole differenze di token.

Le tool call MCP restano in una banda stretta (20–44) indipendentemente dal modello. Quelle del monolite vanno da 44 a 600, a seconda di quanto aggressivamente il modello riprova search_file su un documento grande. La consistenza del braccio MCP suggerisce che il vantaggio viene dall'architettura, non dal comportamento specifico del modello.

558 note (8,5× più grande)

DeepSeek fallisce tutte e sei le domande sul monolite (max_loops su ogni query). MCP risponde a tutte e sei per $0,05. Luna completa tutto su entrambi i bracci ma MCP costa il 40% in meno.

Modalità senza ragionamento

Stesso task RAG a 65 note con chain-of-thought disattivato. Sei modelli testati. Disabilitare il ragionamento amplifica il vantaggio MCP perché riduce i token di output (dove MCP non ha margine) lasciando invariati i token di input (dove MCP risparmia di più).

Luna senza ragionamento a 0,03× è il miglior rapporto registrato: MCP costa il 97% in meno del monolite. La mediana sui sei modelli è 0,28× (vs 0,38× con ragionamento attivo). Tutti i modelli favoriscono MCP in modalità senza ragionamento — incluso Gemini, che con il ragionamento attivo invertiva il rapporto.

Come scalano i costi con la dimensione del corpus

DeepSeek V4 Flash sulle stesse sei domande a tre dimensioni di corpus:

Il costo MCP cresce da $0,043 a $0,050 quando il corpus scala 8,5× — un aumento del 16%. Il costo del monolite resta grosso modo costante in dollari, ma il tasso di completamento scende da 4/6 a 0/6. A 558 note, il braccio monolite non riesce a rispondere a una singola domanda entro il limite di loop. La stabilità di costo senza completamento non è una metrica utile.

Riepilogo cross-model

Le celle verdi indicano dove MCP costa meno; le rosse dove costa di più. Lo schema: MCP vince su 27 delle 29 celle misurate. Le due sconfitte hanno cause specifiche e documentate (esplosione di loop di un modello piccolo su larga scala; modello ad alto prezzo su risposte brevi). L'architettura funziona. Le eccezioni indicano dove guardare.

Stress test: query fuori dominio

Sei domande deliberatamente difficili sul vault da 558 note: un prodotto che non esiste, un dominio non coperto dal catalogo, una domanda ambigua senza contesto, un confronto impossibile, un codice prodotto errato e una specifica fisicamente impossibile. Queste domande sono progettate per testare quanto velocemente il sistema riconosce che la risposta non è nei dati.

Il braccio monolite non riesce a distinguere “non l'ho ancora trovato” da “non c'è”. Su un file da 748 KB, il modello continua a chiamare search_file con pattern diversi, sperando che la prossima ricerca trovi la risposta. DeepSeek va in timeout su quattro domande su sei. Il braccio MCP riceve un segnale definitivo dalla ricerca BM25: nessun risultato significa che il dato non è nel vault. Il modello accetta questo e risponde in 1–4 tool call.

Altre dimensioni

Tre benchmark aggiuntivi completano il quadro: latenza, costo di ingestione e operazioni CRUD.

Latenza

Tempo end-to-end per la sessione RAG a sei domande:

Più veloce su ogni modello e dimensione di corpus. Un'eccezione: Ministral 8B su 558 note impiega 4× di più con MCP, coerente con i loop di ricerca eccessivi documentati sopra. Lo speedup viene dal leggere meno: meno token in input significa meno tempo di attesa per l'elaborazione del modello.

Ingestione

Il costo una tantum di conversione del catalogo grezzo in note Mosaix atomiche, ammortizzato su tutte le query successive:

Luna produce quasi il doppio delle note di DeepSeek (60 vs 32) a un quarto del costo ($0,33 vs $1,44) in un decimo del tempo. Un modello con un prezzo per token più alto può essere drasticamente più economico in totale quando pianifica meglio e finisce in meno round.

CRUD

Create, read, search, update, supersede (seguendo la regola R7 di Mosaix: le note vengono sostituite, non cancellate) e verifica conformità. Quasi parità su tutta la linea: 0,92×–1,15× su esecuzioni a caldo. Il vantaggio cold-start (0,42×) scompare con il prefix caching, il che indica esattamente dove risiede il vantaggio MCP: nei token di input, non nelle operazioni.

Avvertenze

Questi risultati vanno letti tenendo conto delle seguenti limitazioni.

N=1 per braccio per modello per test. Le misurazioni sono direzionali, non statisticamente potenziate. Una singola esecuzione anomala potrebbe spostare qualsiasi rapporto individuale.

Tutti i modelli girano attraverso OpenRouter, che non espone i tassi di hit della prefix cache. Ogni token è conteggiato come non-cached. In produzione, il prefix caching ridurrebbe il costo del monolite — ma anche parte del vantaggio MCP, dato che il monolite beneficia di più dal caching (rilegge lo stesso grande documento ripetutamente).

Il corpus è un catalogo di prodotti industriali. I risultati potrebbero differire su task creativi, conversazionali o di generazione codice. Lo studio precedente (Perché una nota alla volta) copriva la generazione di codice; questo copre il recupero di conoscenza.

Il vault da 558 note contiene circa 133 note reali e 415 note sintetiche generate per stressare l'indice di ricerca. Le note sintetiche sono strutturalmente valide ma potrebbero non rappresentare la densità e la sovrapposizione di note nel mondo reale.

L'autore del benchmark ha progettato sia il formato che il test. Riportiamo sia le vittorie che le sconfitte (Gemini e Ministral su larga scala) e incoraggiamo la replicazione indipendente.

Ulteriori letture

Perché una nota alla volta — lo studio precedente sulla generazione di codice, che misura la compressione dei token e le prestazioni di modelli locali.

Specifica Mosaix Format v1.2.0 — la specifica completa, inclusi gli 11 tool MCP benchmarkati qui.

Repository GitHub — specifica, checker di riferimento e vault di esempio.