Il prompt caching è una delle ottimizzazioni silenziose che rendono economicamente sostenibile l'inference di Large Language Model su larga scala. Quando funziona, il sistema riutilizza i calcoli già fatti per le parti del prompt che restano identiche tra una richiesta e l'altra, evitando di ricalcolare l'KV cache da zero. I benefici in throughput e latenza sono immediati, e il costo computazionale scende di conseguenza: banale per il cloud, vitale per chi fa deployment on-premise e tiene d'occhio il Total Cost of Ownership.

Ma cosa succede quando un dettaglio di formato, apparentemente innocuo, manda all'aria tutto il meccanismo? È quello che ha scoperto l'utente CharlesStross esaminando il comportamento di DeepSeek-V4-Flash-0731, e ha pubblicato su Reddit un avviso che è un piccolo gioiello di reverse engineering pratico.

Il nodo sta nel chat template. DeepSeek non distribuisce un jinja standardizzato, ma chiunque abbia replicato fedelmente il formato definito nel codice python della casa madre si trova con una particolarità: tutti i messaggi con ruolo system, ovunque compaiano nella conversazione, vengono estratti e issati in cima al prompt, all'inizio del contesto, come se fossero un preambolo iniziale. Il formato non prevede messaggi di sistema a metà dialogo né in coda. Così, inserire un system in qualsiasi punto diverso dall'intestazione non fa che sporcare l'intero prefisso: la cache del prompt viene invalidata perché la parte iniziale – quella che dovrebbe rimanere immutabile – cambia ogni volta che aggiungi o modifichi un messaggio di sistema nel bel mezzo della storia.

Il danno non è trascurabile. Per chi usa servizi hosted, si traduce in chiamate API che consumano più token del necessario e costano di più; per chi gestisce inference in locale con llama.cpp o engine analoghi, la colpa di un prompt caching “spazzatura” ricade su un aumento di latenza end-to-end e su un impiego di risorse GPU che poteva essere evitato. L'autore della segnalazione ammette di aver perso tempo e fatica prima di individuare il misfatto, ed è proprio per risparmiare ad altri lo stesso calvario che ha condiviso il fix.

Il ruolo latest_reminder, ovvero come ci si doveva comportare fin dall'inizio

La via d'uscita esiste e si chiama latest_reminder. È un ruolo che DeepSeek ha addestrato appositamente per gestire le disambiguazioni a conversazione avviata, proprio per quei casi in cui molti template usano system a metà flusso. In sostanza, latest_reminder svolge la funzione che l'istinto dello sviluppatore attribuirebbe a un messaggio di sistema inserito più avanti: trasmette un'istruzione o un vincolo che deve valere a partire da un certo punto, senza scombinare il prefisso. L'engine deve naturalmente supportarlo; llama.cpp lo fa senza problemi, mentre su altri runtime la compatibilità va verificata.

Questo dettaglio apparentemente tecnico segnala una tensione più ampia che vive in tutto l'ecosistema dei LLM. Da un lato, la flessibilità dei chat template consente a ciascun laboratorio di modellare il formato di conversazione secondo le proprie scelte di training e allineamento. Dall'altro, le implementazioni che girano su motori di serving terze parti (vLLM, TGI, Ollama, llama.cpp) devono ricostruire fedelmente quel formato, e ogni scostamento può generare colli di bottiglia subdoli che non emergono durante i semplici test di correttezza ma solo sotto carico reale, quando la cache smette di funzionare.

Nel caso specifico, l'insicurezza sta nell'assenza di un contratto esplicito sul formato: se DeepSeek non fornisce un jinja ufficiale, chi distribuisce quantizzazioni o mette in produzione il modello deve fare reverse engineering del codice python di DeepSeek. Un'anomalia che chi sviluppa per ambienti on-premise, dove il controllo sul serving stack è totale ma anche la responsabilità di ogni ottimizzazione, conosce bene.

Cache bucata, budget sfondato

La morale per chi usa DeepSeek-V4-Flash è chiara: non mettere mai un messaggio system lontano dal suo posto designato, quello iniziale. Le alternative sono due: o si usa latest_reminder per i messaggi post-prefisso, oppure si accetta di perdere i vantaggi del caching, con quel che ne consegue in termini di costi e di esperienza utente.

Per chi valuta deployment on-premise di LLM, episodi come questo ricordano che l'efficienza reale non si misura solo in parametri del modello o in throughput di picco su benchmark, ma nella capacità di sfruttare al meglio ogni tecnica di risparmio computazionale. Un template che ignora la semantica del caching può divorare risorse che si credevano al sicuro, e una piccola accortezza di design – l'utilizzo di un ruolo dedicato anziché un abuso di system – fa la differenza tra un servizio che scala economicamente e uno che si brucia budget GPU su calcoli già fatti. Il consiglio di CharlesStross, nella sua asciuttezza da power user, è di quelli che andrebbero stampati e appesi al muro di ogni MLOps engineer.