Il laboratorio ISTA Deep Algorithms and Systems Lab ha rilasciato una build Coder di DeepSeek-V4.1-Flash-1017 che dimezza gli esperti instradati e porta i pesi del transformer a 1 bit per parametro, conteggiati rispetto ai 551,9 miliardi di parametri del modello originale. La release interessa chi esegue modelli in locale: il GGUF gira su llama.cpp dalla build b11870 e su Strata, e il repository include l'allocazione RCO per-tensore completa.

Il modello di partenza è un mixture-of-experts sparse: 384 esperti instradati per livello, 6 attivi per token, 763,2 miliardi di parametri complessivi, di cui 551,9 nel transformer. La build potata mantiene 192 esperti su 384 in ogni livello e riduce i pesi del transformer da 138,2 GB della build non potata IQ2_XXS a 72,1 GB. Il conteggio a 1 bit per parametro deriva dalla divisione di 72,12 GB per i 551,9 miliardi di parametri originali; gli esperti rimossi contano zero bit, mentre i 280,1 miliardi di parametri mantenuti viaggiano in media a 2,06 bit. Nessun peso individuale scende sotto 1 bit.

Per chi valuta un deployment self-hosted, però, quella cifra non racconta tutto. Il file Engram condiviso da 110,6 GB e il proiettore visivo restano identici alla release non potata. La riduzione dei pesi transformer libera 66,1 GB, ma il file Engram da solo pesa 110,6 GB, più dei 72,1 GB dei pesi potati. Se si ha già la build non potata, i file condivisi non vanno riscaricati; se si parte da zero, l'ingombro complessivo non scende in proporzione al bitrate medio dichiarato.

Dietro il risultato ci sono due tecniche diverse. GSQ è una quantization scalare post-training che apprende congiuntamente le assegnazioni di griglia e le scale di gruppo, riducendo il divario tra quantization scalare e vettoriale a bassi bit-width restando compatibile con i tipi GGUF standard. RCO impone budget esatti tramite discesa del gradiente sulla funzione obiettivo, senza messa a punto per singolo vincolo: in questo caso seleziona gli esperti da mantenere ottimizzando la divergenza KL rispetto al modello non potato. Il vincolo uniforme per livello non è un dettaglio secondario. GGUF memorizza un solo conteggio di esperti per l'intero modello, quindi ogni livello deve tenere esattamente lo stesso numero di esperti; livelli disomogenei richiederebbero padding che restituirebbe la memoria risparmiata. RCO tratta il budget di ogni livello come vincolo rigido e lo rispetta a ogni passo di ottimizzazione, mentre una formulazione con penalità arriverebbe solo a una soluzione approssimata e richiederebbe un coefficiente per livello.

Sui benchmark il cedimento è contenuto nella generazione di codice singola: LiveCodeBench v6 scende da 89,71 a 88,57, mantenendo il 98,7% della capacità. Su SWE-bench Verified il calo è più marcato: 77,00 contro 81,20, pari al 94,8%. La spiegazione è nella natura del test: SWE-bench Verified esegue traiettorie agentiche lunghe su repository reali e tollera meno la riduzione di capacità, perché gli errori si accumulano tra i turni. Il laboratorio ha pubblicato anche esempi reali, ciascuno in un singolo file HTML: un SVG animato di un pellicano in bicicletta, un giardino pagoda in voxel con three.js e un sandbox voxel in prima persona giocabile. Sono capacità creative che sopravvivono alla potatura, ma la release resta sperimentale e il team chiede feedback soprattutto sulle capacità non presenti nella miscela di calibrazione.

La pubblicazione dell'allocazione RCO per-tensore offre una base trasparente per capire quali esperti sono stati sacrificati. Per chi esegue già la build non potata, il vantaggio immediato è la possibilità di scaricare solo i nuovi pesi transformer e mantenere i file condivisi. Per chi parte da zero, invece, il risparmio reale va misurato sull'intera directory del modello, non sul bitrate medio dei parametri mantenuti.