Chi lavora con LLM in locale conosce la frustrazione: una piccola modifica al prompt di sistema, l’ordine dei messaggi non rispettato, persino un parametro come reasoning_effort cambia e all’improvviso il tempo di risposta si allunga, la GPU ricomincia a ricalcolare anziché usare la cache. Il costo di prefill, già sensibile su hardware consumer, diventa una tassa occulta che erode l’efficienza del self-hosted.

Cache-hunter, un tool costruito da un maker della comunità, affronta il problema alla radice. Funziona come un proxy tra l’harness e l’endpoint LLM: intercetta le sessioni, tiene traccia degli hash dei componenti ripetuti e mostra in una tabella dove la stabilità si rompe. Le celle rosse segnalano l’invalidazione. L’autore lo ha testato con il proprio harness e con diversi client noti – tra cui Claude Code, Cline, Pi, Hermes e Vibe – rilevando nella maggioranza dei casi prompt di sistema instabili, tool che mutano inaspettatamente o variazioni nell’ordine dei messaggi.

La costruzione è minimalista ma affronta un punto dolente: pochi harness verificano sistematicamente la riproducibilità delle chiamate. Quando si progetta un’interfaccia conversazionale o un agente, la tendenza è a concentrarsi sulla correttezza delle risposte, mentre i motori di inference ottimizzano la latenza tramite KV-cache. Una cache solida può ridurre il time-to-first-token anche del 70%, ma ogni minima divergenza strutturale la invalida. Su un cluster GPU la ricaduta è limitata; su una singola scheda, in un armadio o su un desk, la differenza si sente, anche nella bolletta energetica.

Perché la cache è un indicatore di maturità dell’harness

La presenza di uno strumento come cache-hunter racconta un momento preciso nell’evoluzione degli stack locali: stiamo passando dall’entusiasmo per il “funziona” alla ricerca di prevedibilità e contenimento dei costi. Chi costruisce harness non è più solo un hobbista; sempre più spesso il self-hosted di LLM serve piccole imprese, studi legali, realtà che trattano dati regolati. Per loro, l’efficienza dell’inference non è un vezzo ma un fattore di Total Cost of Ownership, accanto alla sovranità dei dati.

Cache-hunter non introduce tecniche nuove – il calcolo di hash per rilevare cambiamenti è un pattern consolidato – ma lo rende accessibile e diagnostico in un flusso di sviluppo. L’effetto collaterale più interessante è che costringe a riflettere su come si compone ogni chiamata: quale struttura dati per i messaggi, se il sistema prompt viene ricostruito ogni volta, se i tool mantengono lo stesso ordinamento e contenuto. Un harness che non supera il test cache-hunter sta, di fatto, chiedendo più computazione del necessario a ogni interazione.

La direzione è chiara: l’infrastruttura per LLM on-premise sta incorporando tool di osservabilità che prima appartenevano solo ai sistemi distribuiti su cloud. È un segnale che la comunità del fai-da-te non solo raggiunge la maturità dei prodotti commerciali, ma in alcuni casi la anticipa, spinta da un rapporto più diretto con l’hardware e le sue limitazioni fisiche. Cache-hunter è un mattone di questa infrastruttura: piccolo, specializzato, risolve un problema vero senza aggiungere complessità. E ricorda che il costo di un modello non si misura solo in token al secondo, ma in quanti di quei token potevamo evitarci.