L'aggiornamento 0.12.0 di halogen parte da una segnalazione concreta: il server degradava quando il contesto diventava profondo. I numeri pubblicati da peonist-ai su un sistema Ryzen AI Max+ 395 con 128 GB di memoria unificata danno la misura della correzione. A 1.004.581 token di contesto, con greedy decoding e 64 token generati, la decodifica di Qwen3.8-Flash-Next passa da 27,3 a 38,3 token al secondo; il prefill a freddo scende da 21,2 a 17,9 minuti. A 258.794 token il miglioramento è più contenuto, da 42,9 a 45,0 token/s in decodifica e da 1.086 a 1.114 token/s nel prefill. La media a 32k, rilevata su dieci prompt serviti, non cambia.

Il dato tecnico da osservare è dove si concentra il guadagno. La differenza percentuale maggiore si registra sul contesto estremo, non sui benchmark brevi. Questo indica una correzione mirata alla gestione dello stato con un milione di token, non un generico tuning. Il server gira tramite podman con HALOGEN_CTX=1048576 e HALOGEN_ROPE_YARN=4, configurazione che richiede la piattaforma da 128 GB. Non è un dettaglio marginale: su un milione di token, l'occupazione di memoria e la strategia di caching determinano se il sistema è utilizzabile o meno.

L'aspetto che merita più attenzione è il costo del primo token. Un prefill a freddo di circa 18 minuti può sembrare proibitivo, ma va letto insieme al percorso sulla cache dei prompt: un turno successivo sullo stesso contesto arriva al primo token in circa 0,55 secondi. Questo ridefinisce il tipo di applicazioni realistiche. Se il contesto va ricaricato ogni volta, 18 minuti restano una barriera; se invece il contesto viene mantenuto in memoria per domande ripetute su documenti lunghi, il sistema diventa interattivo. La scelta di architettura non è quindi solo tecnica, ma riguarda il modello d'uso: ingestion una tantum e interrogazioni multiple è uno scenario molto diverso dal batch singolo.

Da una prospettiva on-premise, il risultato segnala che il long context in locale non richiede necessariamente un data center. La piattaforma Strix Halo con memoria unificata elimina i trasferimenti tra CPU e GPU, un collo di bottiglia tipico dei sistemi con GPU discrete quando il contesto cresce. La barriera si sposta dalla potenza di calcolo pura alla quantità di RAM e alla qualità del runtime di serving. Questo ha implicazioni di TCO: per carichi di questo tipo, 128 GB di memoria unificata su un singolo nodo possono sostituire configurazioni più costose e complesse, ma impongono vincoli chiari sul prefill a freddo e sul riutilizzo del contesto.

Non è un punto di arrivo. L'autore chiede a chi ha sweep a un milione di token di rieseguirli sulla 0.12.0, un invito che mette in evidenza la scarsità di benchmark riproducibili in questa fascia. I numeri attuali riguardano condizioni precise: una richiesta a freddo per le righe a 262k e 1M, percorso cold, prompt identici, default speculative drafter. Per chi valuta deployment self-hosted, i trade-off tra prefill, caching e memoria unificata sono il cuore della decisione; AI-RADAR dedica a queste valutazioni una sezione specifica su /llm-onpremise, senza consigli preconfezionati ma con l'analisi dei vincoli.