Una RTX 6000 Pro da 96 GB di VRAM, un LLM qwen3.8:27b in FP8 e una context window piena da 262.144 token: il test di codehamr su un porting da 2,1 MB di C a HTML/three.js è brutale per definizione. Il file sorgente vale circa 600.000 token, più del doppio della finestra disponibile, quindi l’agente deve esplorare il codice e decidere cosa conta. Con un solo prompt, senza follow-up, i risultati mostrano che il modello cloud Opus 5 ha chiuso in 21 minuti con 1.759 righe e un porting “okay”; le due varianti locali di qwen3.8:27b, sotto harness diversi, hanno prodotto 949 e 1.056 righe in 4 ore e 18 minuti e 1 ora e 40 minuti, entrambe “bad”. Nel video di accompagnamento, il C originale precede i tre porting.

Questa non è una classifica di merito tra modelli. È un esperimento a singola esecuzione, con un prompt scarno e nessuna iterazione umana. Ma sposta l’attenzione su un punto che nei benchmark di inference pura spesso sfugge: il wall clock di un agente self-hosted non coincide con la velocità di generazione dei token. Le ore di GPU qui documentate non sono spiegate dalle righe prodotte: 949 righe in oltre quattro ore equivalgono a un output medio molto basso, ma non sappiamo quanti token intermedi abbia generato l’agente per esplorare il file, quante chiamate al modello abbia fatto il harness e quanto overhead abbia introdotto la gestione del contesto.

Il dettaglio più interessante è che gli stessi pesi sotto due harness diversi hanno portato allo stesso porting rotto. Il harness “hermes”, con più macchinario, ha impiegato più di due volte il tempo del harness “codehamr” per raggiungere un risultato analogo. Questo suggerisce che l’overhead dell’orchestrazione può dominare il costo operativo quando il prompt non dà al modello una strategia di navigazione. In un contesto aziendale self-hosted, questo ha implicazioni dirette sul TCO: non basta confrontare costo per token, bisogna misurare il costo per attività completata, includendo il tempo GPU sprecato in ragionamenti intermedi poco utili.

C’è un’asimmetria strutturale con il cloud: Opus 5, da servizio gestito, beneficia di un harness ottimizzato e probabilmente di un bilanciamento del carico che riduce i tempi morti. Il setup locale descritto usa vLLM con KV cache FP8 e contesto massimo: configurazione seria, ma su singola GPU. Il divario di 21 minuti contro 4 ore non è solo una questione di capacità del modello; è il risultato di come l’agente usa il contesto, di quante volte rilegge porzioni del file e di quanto la pipeline locale sia in grado di parallelizzare le richieste.

Per chi osserva il deployment on-premise, il test segnala che la maturità di un LLM locale non si giudica solo dalla qualità delle risposte a prompt brevi. Serve misurare il comportamento agentico su task lunghi, con strumenti di navigazione del codice e gestione della context window. La scelta del harness e la progettazione del prompt diventano parte dell’infrastruttura tanto quanto la GPU. Su AI-RADAR, la sezione /llm-onpremise raccoglie framework analitici per valutare questi trade-off.

La domanda finale dell’autore — dove finiscono quelle ore? — resta aperta. Ma il fatto che un harness verboso non abbia salvato un prompt scarno è un indizio: il tempo di calcolo non si trasforma automaticamente in migliore output. Nei deployment locali, questa è una lezione costosa.