Il 27B che batte il 397B: fine della favola dello scaling

Il 22 aprile 2026 il team Qwen di Alibaba ha rilasciato Qwen3.6-27B (Apache 2.0, peso 55 GB, context 262K nativi). Sui benchmark di coding batte il modello della generazione precedente, Qwen3.5-397B-A17B, uscito appena due mesi fa. Un 27B dense che supera un MoE da 397 miliardi di parametri totali. Simon Willison l'ha fatto girare su Mac in quantizzazione Q4 (16.8 GB) a 25 token/s.

Il titolo che ti vende il prodotto è "un 27B ha battuto un 397B — la fine della favola dello scaling". Ed è un titolo che funziona perché risuona con una fatica culturale vera: quella di chi nel 2024 si era rassegnato a pensare che solo le big tech con datacenter da miliardi avrebbero fatto modelli competitivi.

Però è anche un titolo fuorviante su almeno due livelli. Se vogliamo capire davvero cosa sta succedendo nelle scaling law — e se vogliamo usare questa informazione per scegliere che modello mettere in produzione — bisogna smontare un po' la narrativa e guardare i numeri veri.

Il numero che ti dicono vs il numero vero

Parametri totali: il 397B ne ha 397 miliardi. Il 27B ne ha 27 miliardi. Sì, 15x meno.

Parametri attivi per token: il 397B è un Mixture of Experts. Attiva 17B parametri per ogni token che genera (10 esperti routed su 512 + 1 shared = 11 attivi). Il 27B dense ne attiva 27B — tutti. Il dense, per ogni token, fa 1.6x più lavoro aritmetico del MoE che stiamo dicendo di aver battuto.

Il confronto corretto non è mai stato 15x contro 1x. È:

Storage su disco: dense 55.6 GB, MoE 807 GB (14.5x di differenza)
Costo aritmetico per token: dense 1.6x più alto del MoE
Capability per parametro attivo: qui il dense vince di brutto, perché ottiene più con compute per-token simile

Lo dico perché è fondamentale per capire il resto: la storia non è "fare meno e ottenere di più". La storia è più interessante di così, ed è dove la teoria delle scaling law negli ultimi sei anni ha avuto il suo pendolo più ampio.

Le scaling law, in breve (per chi non le conosce)

Nel gennaio 2020, un paper di OpenAI (Kaplan et al., arXiv:2001.08361) ha provato a trovare una formula per come la loss di un modello di linguaggio cala al crescere di tre cose: parametri del modello (N), dimensione del dataset (D), compute totale di training (C). La conclusione era bellissima perché pulita: la loss scala come una power-law in tutte e tre. Raddoppi i parametri, raddoppi il dataset, raddoppi il compute, e la loss cala di una frazione prevedibile.

La conclusione operativa — quella che ha plasmato tutto il 2020-2022 — è stata: il compute-optimal è modelli grandi allenati su dataset relativamente modesti. È il frame che ha prodotto GPT-3 175B, PaLM 540B, Megatron-Turing 530B. Grosso e affamato.

Poi nel marzo 2022 è arrivato Chinchilla (Hoffmann et al., DeepMind, arXiv:2203.15556). Hanno allenato oltre 400 modelli per trovare la relazione ottima tra parametri e dati. La risposta ha spostato il pendolo: per ogni raddoppio di parametri, raddoppia anche i token di training. Una rule of thumb pratica: circa 20 token per ogni parametro.

Chinchilla 70B ha battuto Gopher 280B, GPT-3 175B, MT-NLG 530B. La stessa compute, spesa in modo diverso, produceva un modello più piccolo ma migliore.

Quella lezione — più dati, meno parametri — è la radice di tutto quello che è venuto dopo. Inclusa la generazione Qwen3.6.

La Densing Law: il vero framework teorico

Se Chinchilla era il 2022, il 2024 ha portato un'idea più precisa. Un team dell'Università Tsinghua (Xiao et al., arXiv:2412.04315, pubblicato su Nature Machine Intelligence) ha analizzato 51 modelli open source e formulato quella che chiamano Densing Law:

La "capability density" — cioè la capacità per parametro — raddoppia ogni 3,3-3,5 mesi.

Tradotto: ogni 3,5 mesi, un modello con metà dei parametri raggiunge la SOTA precedente. È una legge empirica, non un teorema fisico, ma regge sorprendentemente bene quando la misuri retrospettivamente. Llama 3.3 70B (dicembre 2024) ha battuto Llama 3.1 405B su diversi benchmark. Phi-4 14B (Microsoft, dicembre 2024) ha raggiunto GPT-4o su GPQA. Mistral Small 3 (24B) ha battuto Llama 3.3 70B in gennaio 2025.

Qwen3.6-27B che batte Qwen3.5-397B due mesi dopo non è un'eccezione. È la Densing Law che passa per casa al momento previsto.

E la cosa che conta davvero, per chi sviluppa: la Densing Law implica che il modello di oggi con 27 miliardi di parametri equivale al modello di 3-4 mesi fa con 50-60 miliardi. Se la tendenza regge, a gennaio 2027 avremo modelli da 13 miliardi equivalenti al 27B di oggi. Ed entreranno comodi in un laptop.

Dense vs MoE: perché il MoE aveva senso (e in parte ce l'ha ancora)

Per capire perché il ritorno del dense è notevole, bisogna ricordare da dove arriviamo.

Mixtral 8x7B di Mistral, rilasciato l'8 dicembre 2023, è stato il primo MoE open di qualità con impatto reale. 45B di parametri totali, circa 13B attivi per token. Batteva Llama 2 70B con 6x la velocità di inferenza. Epoch AI ha formalizzato la rule of thumb: un MoE 8-way sparse ha gli stessi costi di decoding short-context di un dense della metà dei parametri totali. Mixtral 8x22B (140B totali) si comportava, in inference veloce, come un dense da 90B.

Per due anni questa è stata la strada. DeepSeek V3 (dicembre 2024, 671B totali / 37B attivi). DeepSeek R1 (gennaio 2025). Qwen3.5-397B-A17B (febbraio 2026, 512 esperti). Il messaggio implicito era: scala con gli esperti, non con la densità. Paga l'aritmetica solo per la frazione che serve.

Il MoE conviene ancora oggi in alcuni scenari precisi:

Prefill dominato dall'aritmetica (inferenze con contesti molto lunghi): il MoE vince sulle risorse computazionali
Batch grandi in datacenter: i costi di inferenza scalano molto meglio
Unified memory su hardware consumer (questo è il twist interessante): sui Mac Silicon e Strix Halo, dove il bottleneck è la memory bandwidth invece che l'aritmetica, il MoE vince ancora. Un MoE da 35B con 3B attivi gira a ~25 token/s su Mac M4 32GB; un dense 27B sta intorno ai 5 token/s.

Ma — e qui c'è il vero punto dell'articolo — il dense sta tornando competitivo su un asse che il framework Dense-vs-MoE non copriva: l'RLVR.

Il vero motore: il post-training è il nuovo pretraining

Qui arriviamo al frame che secondo me spiega meglio di qualsiasi altro la generazione Qwen3.6 e il ritorno del dense.

Nel periodo 2020-2022, la scaling law valeva principalmente per la pretraining loss. Ti misuravi contro il next-token prediction, e i modelli più grandi andavano meglio. Il post-training era una rifinitura (SFT, instruction tuning, magari RLHF) per rendere il modello usabile.

Nel 2025-2026 il gioco si è spostato. Il pretraining è ancora necessario, ma il capability gain reale — la differenza tra un modello che risolve un bug e uno che non ce la fa — arriva in larga parte dal post-training. E il protagonista è RLVR (Reinforcement Learning with Verifiable Rewards): addestramento in cui il modello produce risposte, un verificatore automatico (test unitari che passano, problema matematico risolto, output validato) dà un reward oggettivo, e il modello impara a ragionare meglio.

RLVR è quello che sta dietro DeepSeek-R1. È quello che dà ai modelli recenti la capacità di fare SWE-bench a percentuali una volta impossibili. E, cosa che pochi dicono, RLVR funziona male su architetture MoE.

Il motivo tecnico: durante RL, il gradient passa attraverso gli esperti che sono stati attivati per ogni token della sequenza. Nei MoE questa attivazione è sparsa e stocastica — esperti diversi per token diversi. Il risultato è una dinamica di training instabile, con "gradient blackouts" e "training collapse" documentati in diversi paper del 2025-2026 (vedi la raccolta awesome-RLVR). I dense, dove ogni gradient raggiunge ogni parametro, non hanno questo problema.

Quindi la vera storia di Qwen3.6-27B non è "un modello piccolo ha battuto un modello grande". È:

Il post-training RLVR è diventato il motore principale del capability gain
RLVR penalizza strutturalmente i MoE
Quindi oggi un dense ben post-trainato batte un MoE grande, anche se pre-trainato meglio

È un cambio di paradigma, non un'anomalia benchmark.

Qwen3.6-27B nei numeri (con caveat onesti)

Per dare sostanza al discorso, i numeri delle due versioni a confronto:

Benchmark	Qwen3.6-27B	Qwen3.5-397B-A17B	Delta
SWE-bench Verified	77,2%	76,2%	+1,0
SWE-bench Pro	53,5%	50,9%	+2,6
Terminal-Bench 2.0	59,3%	52,5%	+6,8
SkillsBench Avg5	48,2%	~30,0%	+18,2

Il delta su SkillsBench è enorme. Quello su SWE-bench Verified è di un solo punto e nasconde un problema di misura: alcune fonti riportano per il 397B uno score di 80% anziché 76,2% su SWE-Verified, probabilmente per scaffolding diverso (l'agent orchestration che gira sopra il modello). La cosa va presa per quello che è: un segnale forte, non una sentenza definitiva. SWE-bench è notoriamente sensibile al tooling — e i team rilasciano i loro numeri sotto le condizioni che li favoriscono di più.

Un commento di Hacker News ha aggiunto un'altra avvertenza: Qwen3.6-27B, pur forte in one-shot, tende a ripetere lo stesso tool call quando fallisce, invece di adattare la strategia. Strong in single step, meno maturo in agenti multi-step iterativi. Se fai lavoro agentico lungo, potrebbe valerne di meno.

Per il dev italiano: cosa farci, praticamente

Una delle ragioni per cui questa release conta, concretamente, è che 27B quantizzato gira davvero in locale su hardware prosumer. Ecco i numeri verificati:

Mac M3 Max 36 GB+: Q6_K (22,5 GB) ci sta comodo, ~5-11 token/s
Mac M3 Max 64 GB: Q8_0 (28,6 GB) con margine per context grande
RTX 4090 24 GB: Q4_K_M (16,8 GB) o Q5_K_M (19,5 GB)
RTX 5090: tutto senza compromessi, 40-50 token/s su Q6_K

Quantizzazioni raccomandate: Q4_K_M se vuoi massima velocità con perdita minima, Q5_K_M o Q6_K se lavori su task critici.

Il paradosso da tenere a mente è che se il tuo hardware è Apple Silicon, un MoE piccolo probabilmente ti gira ancora meglio (memory bandwidth limit). Un Qwen3-30B-MoE attivando 3B per token su Mac M4 vola a 25 token/s; il Qwen3.6-27B dense sta intorno a 5. Il "dense is back" vale in datacenter e su GPU discrete con molta compute, meno su unified memory.

Chiusura: non è morta la scaling law, è cresciuta

Il titolo dell'articolo è volutamente provocatorio. La scaling law non è morta. È diventata più articolata.

Il pendolo è oscillato tre volte in sei anni. Kaplan 2020: più parametri, meno dati. Chinchilla 2022: più dati, meno parametri. Densing Law 2024 + post-training era 2025-2026: capability density che raddoppia ogni 3,5 mesi, post-training RLVR come motore principale, dense che torna competitivo per ragioni strutturali (RLVR funziona male su MoE).

Per chi costruisce prodotti, l'implicazione operativa è semplice: smetti di guardare il numero di parametri totali. Non è informativo. Guarda tre cose invece:

I benchmark che contano per il tuo task (non l'MMLU generico — SWE-bench se fai coding, Terminal-Bench se fai agent, ecc.)
Il costo in compute attivo per token (dense 27B costa più del MoE 397B/A17B per token — pagabile, ma sappilo)
L'hardware che hai o che puoi permetterti (dense preferisce GPU discrete, MoE preferisce unified memory)

Il 27B che batte il 397B è una storia vera. Ma la favola dello scaling non è che vince il più piccolo. È che siamo entrati in un'era in cui il lavoro vero non lo fa più il pretraining che pompa parametri, lo fa il post-training che insegna a ragionare — e l'architettura ottima per questa nuova fase è, per ora, dense.

Il MoE non scomparirà: ha ancora vantaggi reali in datacenter e su certi carichi. Ma la narrativa "più parametri totali = più intelligente", che è stata il refrain del 2023-2024, è oggi semplicemente falsa. È cresciuta in qualcosa di più complicato, e più interessante.

Fonti: