Il team di Blockway ha pubblicato Agens Volundr 32B Preview, un modello dense da circa 32 miliardi di parametri distribuito su 72 layer, sotto licenza Apache-2.0. Non è il classico annuncio di un nuovo LLM: qui la notizia è l'architettura ibrida che riduce il KV cache a 18 layer su 72. Per chi esegue modelli on-premise, questa scelta tocca il vincolo più concreto dei carichi a contesto lungo.

Nei transformer tradizionali, il KV cache cresce con la lunghezza del contesto e può saturare la VRAM prima ancora dei pesi. Blockway parte da un dato di campo: i suoi clienti eseguono i modelli sulle proprie macchine, quindi il limite reale a contesto esteso è la memoria, non il numero di parametri. Di conseguenza, il team ha progettato uno stack in cui la maggior parte dei layer non mantiene un KV cache.

Dei 72 layer, 54 adottano la Kimi Delta Attention: attenzione lineare con stato ricorrente a dimensione fissa, senza KV cache. Altri 17 usano la BCSA, un'attenzione compressa-sparsa che mantiene una finestra esatta sugli ultimi 4.096 token e aggrega il contesto precedente in blocchi 4:1; un indexer appreso seleziona i 512 blocchi più rilevanti. Solo il layer 72 usa full attention. A questo si aggiunge Engram, una memoria n-gram basata su hash collegata a due layer e ospitata nella RAM di sistema, e mHC con quattro flussi residui invece di uno. Il risultato dichiarato è un contesto di 262K token.

I numeri di velocità pubblicati dal team mostrano una decode quasi piatta. Su due GPU da 48 GB in BF16, il modello produce 25,1 token/s a 1K di contesto e 23,9 token/s a 128K. La prefill scende da 2.122 a 1.297 token/s nello stesso arco. In INT4 da 31,7 GiB su una singola GPU da 48 GB, la decode arriva a 31,0 token/s a 1K e resta a 29,1 token/s a 32K. Il throughput aggregato in BF16 è di 127 token/s con 8 utenti e 130 con 16; in INT4 scende a 117 con 8 utenti. Sono dati misurati dal team con il proprio fork di sglang, non con runtime standard.

Il punto strutturale non è solo la velocità, ma dove finisce il collo di bottiglia. Riducendo il KV cache e spostando parte della memoria in RAM host, questo tipo di architettura cambia il dimensionamento hardware per il self-hosted. Non elimina la necessità di GPU: i pesi e la finestra esatta restano su VRAM. Però rende meno probabile che servano due o più GPU solo per ospitare il contesto lungo. Chi valuta un'infrastruttura locale può guardare a configurazioni con una singola GPU da 48 GB e più RAM di sistema, con effetti diretti su TCO e complessità di gestione.

Il rovescio della medaglia è sulle prestazioni agentiche. Nei benchmark pubblicati, il modello supera il Qwen3.8-27B su LiveCodeBench v6, HumanEval, AIME 2025 e MATH-500, ed è in linea su MMLU-Pro, IFEval e GPQA Diamond. Ma resta indietro sui task agentici: tau2-bench a 74,2 contro 79-80 della concorrenza e SWE-bench Verified a 44 contro 58-64 in un sottoinsieme di 50 task. Il team lo riconosce e indica la chiusura di questo divario come priorità per la versione completa, con pre-training aggiuntivo fino a circa 10 miliardi di token e training su sessioni agentiche lunghe.

C'è poi il tema del serving. Oggi il modello gira solo con il fork sglang del team: stock sglang e vLLM non lo caricano ancora, mentre GGUF e llama.cpp sono nei piani ma non disponibili. Per un deployment on-premise reale, questa dipendenza da un runtime custom è il costo di integrazione più rilevante. I container Docker sono disponibili per GPU Ada da 48 GB e per H100/H200. Il drafter DFlash2, in repository separato, porta accelerazioni fino a 3,6x su output JSON e tool, 2,0x sul codice e 1,6x in modalità thinking su singolo utente, ma il beneficio cala oltre circa 8 utenti concorrenti.

Blockway lo presenta come un preview e invita a provarlo, segnalare errori e suggerire benchmark. La domanda di fondo non è se il KV cache sparirà, ma quanto rapidamente i runtime standard sapranno supportare architetture ibride come questa. Finché non ci riescono, il vantaggio architetturale resta vincolato al fork del produttore.