Otto ore di esecuzione, 966 chiamate modello e zero errori di generazione: il test pubblicato da un utente con DeepSeek Harness e NInfer su una singola RTX PRO 6000 racconta qualcosa di più di un esperimento riuscito. La configurazione era locale: il client Windows eseguiva tutte le operazioni di shell e sui file, mentre una macchina separata, raggiunta via LAN, faceva soltanto inference con Qwen3.8-27B e una context window da 262K token. Il server non aveva accesso alle operazioni locali, e questo separa il controllo dal calcolo in modo netto.

I numeri del workload mostrano un profilo sbilanciato verso input lunghi: 131,2 milioni di token in ingresso contro 853,3 mila in uscita dopo l'inclusione della compattazione, con un rapporto di circa 160 token di input per ogni token prodotto. La richiesta root mediana arrivava a 136,6K token, il p95 a 205,9K e il valore massimo a 231,2K. Non sorprende che il costo computazionale fosse dominato dalla rilettura del contesto, non dalla generazione. La velocità di decode pesata è stata di 104,83 token al secondo, e il tempo al primo token per la root aveva una mediana di 0,8 secondi, ma un p95 di 136 secondi: quando la richiesta entrava sulla GPU, la decodifica viaggiava, mentre la coda e il prefill producevano i ritardi più pesanti.

Il layer locale ha eseguito 1.421 operazioni reali tra PowerShell, letture, modifiche, scritture e ricerche, con 30 fallimenti e un tasso di errore del 2,11%. Le operazioni sui file si chiudevano per lo più in millisecondi. Non è un dettaglio secondario: in uno scenario agentico, l'affidabilità degli strumenti può essere più vincolante della qualità del modello. Qui il modello non ha avuto alcun errore di generazione, mentre gli strumenti hanno assorbito la quasi totalità dei problemi, un dato che sposta l'attenzione dall'LLM alla pipeline.

Se lo stesso carico fosse passato dalle API, il confronto pubblicato stima costi equivalenti da 18,61 dollari con DeepSeek V4 Flash fino a 677,32 dollari con Claude Opus 4.6, passando per 27,26 dollari con GPT-5.6 Luna e 270,93 dollari con Claude Sonnet 5. Sono stime basate sui listini correnti e senza sconti di cache: chi usa provider con cache aggressiva può spendere meno, ma il punto non è il valore assoluto. Il punto è che su un carico con prompt ripetuti da sei cifre e 160 token di input per ogni token di output, il costo marginale delle API cresce con la lunghezza del contesto, mentre il costo marginale locale, una volta disponibile l'hardware, resta legato a energia e manutenzione.

La scelta della quantization mista Q4/Q5/Q6 spiega in parte la fattibilità su una singola GPU workstation: riduce la pressione sulla VRAM e sulla banda, anche se introduce un trade-off sulla precisione che non sempre emerge nei benchmark più brevi. Il prossimo test con NVFP4 potrebbe spostare ancora il profilo. L'aspetto strutturale, però, è un altro: il controller e il motore di inference sono separati e comunicano sulla LAN. Questo consente di tenere le operazioni sul file system e sulla shell lontane dal processo di inference, un vincolo utile per chi vuole evitare che dati operativi escano dalla rete locale. Non elimina le complessità di gestione, ma rende il self-hosted più credibile per carichi agentici lunghi.

Per chi valuta il deployment on-premise, il test non è una dimostrazione universale: una singola scheda, un client Windows e una LAN non equivalgono a un cluster aziendale, e il costo di hardware, energia e competenze non va ignorato. Ma segnala che una porzione di workload, oggi pagata a token, può essere assorbita da un parco macchine locale quando il contesto è grande e ripetuto. Gli incentivi per i team si spostano: dall'ottimizzazione del prompt per ridurre i token, all'ottimizzazione della coda e del prefill per saturare la GPU. Non è più solo una questione di prezzo per token; è una questione di architettura di esecuzione. AI-RADAR offre framework analitici su /llm-onpremise per soppesare questi trade-off.