Trentasei token al secondo, per la precisione 36,25. Non è un numero che fa impallidire una GPU moderna, ma la storia diventa interessante quando si scopre che il motore dietro quella cifra è un binario C99 senza dipendenze — niente Python, niente CUDA, niente BLAS — e che gira su un comune Intel Xeon, con soli quattro thread. Il progetto, pubblicato su GitHub con il nome project-zero, mostra come un approccio artigianale all'inference di modelli ternari possa regalare prestazioni di tutto rispetto, ma anche dove il vero muro—fisico, prima ancora che computazionale—blocca ogni ulteriore progresso.

BitNet, la famiglia di modelli che comprime i pesi a soli 1,58 bit (valori -1, 0, +1), è stato fin dall'inizio un candidato naturale per l'inference su CPU: il risparmio di memoria è estrema, e la matematica necessaria si riduce a somme di interi. Il problema è che quasi tutti gli stack di inference trattano anche i pesi ternari come se fossero float32, dispacchettando i byte in vettori a precisione piena prima di moltiplicare. Il creatore di project-zero ha invece scritto routine SIMD in assembler per AVX2 e AVX-512, usando le istruzioni VNNI (vpdpbusds) per accumulare i prodotti direttamente in registri interi. I pesi sono stipati quattro per byte e non vengono mai trasformati in float. Il thread pool, costruito su atomiche C11 con backoff spin-then-yield, azzera la contesa di sincronizzazione durante la generazione dei token. Il risultato è un singolo eseguibile che espone un'API compatibile con OpenAI, senza strati interpretati.

Tutta questa ingegnosità, però, si infrange contro un limite che la CPU non può aggirare: la banda passante della DRAM. A batch size 1, il decode di BitNet viaggia al 95% della larghezza di banda teorica della memoria del sistema. Significa che il processore aspetta i dati più di quanto calcoli. Rendere i kernel ancora più veloci non serve a nulla: il tempo di latenza reale non si sposta finché non si parallelizzano più sequenze contemporaneamente, ammortizzando il costo dei trasferimenti.

È un segnale strutturale che va letto con attenzione. Primo, dimostra che per l'inference di modelli estremamente quantizzati il vero hardware critico non è la CPU ma il sottosistema di memoria. Scegliere un server per deployment on-premise basandosi solo sulle specifiche di calcolo è fuorviante: contano molto di più i canali di memoria, la tipologia (DDR5, HBM, eventuale CXL) e l'architettura del memory controller. Secondo, ribadisce che la frontiera della compressione dei pesi non è una bacchetta magica: anche con 1,58 bit, il collo di bottiglia rimane lo spostamento dei parametri dalla RAM ai registri. Terzo, per chi deve far girare LLM in ambienti air-gapped o con vincoli di sovranità dei dati, l'accoppiata “modello iper-quantizzato + motore C senza dipendenze” abbassa la barriera di ingresso, ma impone di investire in configurazioni di memoria generose.

C'è anche una lezione di metodo. L'approccio zero-dependency, compilato in un binario unico, elimina intere classi di problemi di sicurezza e di supply chain: nessuno stack Python da auditare, nessun driver CUDA da aggiornare. Per chi valuta trade-off sul TCO di un'infrastruttura locale, questo tipo di runtime può ridurre i costi operativi e di manutenzione, a patto che le prestazioni in scenari con più utenti siano validate. Su questo il lavoro è ancora aperto: il repository chiede dati da altre architetture CPU, specialmente AMD Zen e ARM NEON, per capire se la saturazione della banda è un muro comune o se qualche piattaforma riesce a spostarlo più in là. L'invito, per chi fa deployment on-premise, è a misurare la propria memoria prima di comprare calcolo.