La morte lenta dello scaling: perché più grande non è più sempre meglio
Sara Hooker — già a capo di Cohere For AI, una delle pochissime ricercatrici con la pelle nel gioco sia in industria che in accademia — ha pubblicato un saggio dal titolo On the slow death of scaling. Affronta una domanda che, per gran parte dell'ultimo decennio, era stata trattata come già risolta: più grande è sempre meglio?
La risposta onesta, sostiene, è no. E le conseguenze dell'aver assunto il contrario sono più grandi di quanto la maggior parte dei team — e dei regolatori — abbia iniziato a fare i conti. Questo è il primo post di una serie in tre parti che smonta il saggio e ne ricava cosa significhi per chiunque stia consegnando o governando IA nel 2026.
Il decennio che ha reso "scala" sinonimo di "progresso"
La storia che Hooker racconta inizia con un incidente. Nel 1945 Percy Spencer notò che una tavoletta di cioccolato gli si scioglieva in tasca vicino al magnetron di un radar, e ottenemmo il forno a microonde. Negli anni 2000 le GPU — progettate negli anni 70 per renderizzare Mario — vennero ridestinate alla moltiplicazione di matrici e ottenemmo il deep learning. Il paper di Google del 2012 usava 16.000 core CPU per classificare gatti; un anno dopo, lo stesso task veniva risolto con due core CPU e quattro GPU.
Quel momento accese una corsa al compute e, con essa, una cultura. La vecchia battuta di Ken Thompson — "nel dubbio, usa la forza bruta" — è stata elevata a bitter lesson di Rich Sutton: getta più compute sul problema, e l'ingegneria della conoscenza umana continuerà a perdere. Dal 2017 al 2023 i costi di training sono cresciuti di circa quattro ordini di grandezza. GNMT è costato ~100K$ per essere addestrato; Gemini Ultra ha superato i 100M$. La "formula" è diventata: scala la dimensione del modello e i dati di training, ripeti.
Le implicazioni di capitale sono state enormi. La ricerca di frontiera è migrata fuori dall'accademia, dentro una manciata di laboratori industriali. Hooker cita la geografia in modo diretto: la produzione notevole di modelli ML è oggi concentrata in USA e Cina a un livello che nel 2010 sarebbe stato impensabile. La cultura della pubblicazione aperta è collassata in parallelo. I lab industriali hanno smesso di pubblicare non perché la scienza sia diventata più difficile da scrivere, ma perché il moat si è spostato dagli algoritmi al capex.
L'evidenza che l'assunto si sta rompendo
Qui il saggio diventa scomodo per chiunque abbia una roadmap che dipende dal dogma bigger-is-better.
Hooker traccia l'Open LLM Leaderboard su due anni. Il trend non è sottile:
- Falcon 180B — un tempo di frontiera — è battuto facilmente da Llama-3 8B, Command R 35B e Gemma 2 27B.
- Aya 23 8B e Aya Expanse 8B battono BLOOM 176B pur avendo il 4,5% dei parametri.
- I migliori modelli sotto i 13B battono di routine modelli molto più grandi presentati nella stessa finestra.
Non sono casi limite. Sono il trend dominante su un benchmark pubblico, su un arco pluriennale. Se "più grande" implicasse ancora "meglio" in modo significativo e affidabile, nulla di tutto questo starebbe accadendo. Quello che stiamo vedendo è che il tasso di rendimento per unità di compute sta cambiando, e il cambiamento è guidato da cose diverse dal puro conteggio dei parametri — qualità dei dati, tecnica algoritmica, scelte architetturali. Entreremo nel merito nella Parte 2.
Perché le scaling law sono state sopravvalutate
La giustificazione intellettuale dominante per la traiettoria bigger-is-better sono state le scaling law — Kaplan et al. (2020), Chinchilla, Hernandez et al. — che provano a predire come la loss diminuisca al crescere di compute, dati e parametri. Sono diventate, nelle parole di Hooker, "una frase passe-partout per giustificare di tutto, dai massicci investimenti di capitale negli startup di IA alle decisioni politiche sulle soglie di compute."
Ma il saggio cataloga, con citazioni, una serie di caveat che dovrebbero rendere nervoso chiunque usi le scaling law per qualsiasi cosa al di là di un singolo training run pianificato:
- Predicono per lo più la test loss in pre-training, non le capacità downstream — e la relazione fra le due è "torbida o incoerente". È la discussione sulle emergent properties, che Hooker riformula con ironia: le proprietà emergenti sono semplicemente la nostra ammissione che le scaling law non hanno predetto ciò che è uscito.
- Sono state difficili da replicare sotto assunzioni leggermente diverse sulla distribuzione dei dati (Besiroglu et al. 2024 su Chinchilla; Anwar et al. 2024).
- Molte "power law" poggiano su meno di 100 data point (Ruan et al. 2024). In qualsiasi altro campo non passerebbe la review.
- Alcune capacità downstream scalano in modo erratico o non seguono affatto power law (Srivastava et al. 2023; Caballero et al. 2023).
- Reggono meglio quando architettura, ottimizzatore e qualità dei dati restano costanti — esattamente le condizioni meno probabili da mantenere su un orizzonte di pianificazione pluriennale.
La lettura onesta è che le scaling law sono utili per pianificare il prossimo training run dentro un regime noto, e poco più. Trattarle come una previsione portante sulla traiettoria delle capacità IA su anni è sempre stato un azzardo.
Il problema di policy che questo genera
Qui il saggio diventa portante per chiunque non stia effettivamente addestrando modelli di frontiera — che è la maggior parte di noi. La regolazione è stata costruita sopra l'assunto bigger-is-better. L'EU AI Act, gli executive order USA e l'ondata di linguaggio sulle soglie di compute nella legislazione 2024–25 condividono tutti una premessa strutturale: che il training compute (FLOP in fase di training, o per proxy l'accesso all'hardware) sia il miglior indicatore di capacità e quindi di rischio.
Se Hooker ha ragione — e l'evidenza empirica che presenta è difficile da liquidare — allora le soglie di compute:
- Mancano interamente i modelli piccoli ma capaci. Un modello da 8B che batte uno da 180B su capacità nocive non farà scattare alcuna soglia basata sui FLOP.
- Sovra-regolano modelli grandi ma sotto-performanti, creando costo di compliance per una capacità che non esiste.
- Invecchieranno male man mano che il compute in inference, i sistemi agentici e le tecniche gradient-free (Parte 3) spostano dove la capacità si accumula davvero.
- Concentrano ulteriormente il potere scrivendo nella legge gli assunti di scala dell'attuale oligopolio.
Le "responsible scaling policies" di Anthropic e OpenAI ereditano lo stesso assunto incorporato: che lo scaling continuerà ad accadere e l'unica domanda aperta è come scalare responsabilmente. La sfida di Hooker è più scomoda: e se lo scaling non fosse l'unico — o nemmeno il più interessante — asse di progresso?
Cosa significa se stai consegnando prodotto, non policy
Le implicazioni cascano verso il basso. Se sei un CTO, un VP Eng o un fondatore tecnico che sceglie i modelli per la produzione:
- Smetti di indicizzare sul conteggio dei parametri. È sempre stato un proxy rumoroso ed è ora attivamente fuorviante. I punteggi sulle leaderboard aperte, le eval task-specific e il mix di traffico della tua produzione ti dicono molto di più dei B-di-parametri.
- Default su "il modello più piccolo che supera la barra di eval", non "il modello più grande che il budget consente". Il costo di inference si compone nel tempo. La realtà 8B-batte-180B significa che di solito puoi cavartela con molto meno di quanto il marketing del vendor lasci intendere.
- Tratta con sospetto qualsiasi roadmap vendor la cui value proposition sia "saremo più grandi l'anno prossimo". Alcuni dei più importanti guadagni di capacità degli ultimi 24 mesi — RAG, tool use, chain-of-thought, distillation — non hanno richiesto alcuno scaling.
- Sottoponi ad audit qualsiasi documento di pianificazione interno che usi le scaling law come previsione. Sono cattivi previsori al di fuori di regimi di training stretti. Se una roadmap a 3 anni dipende dall'estrapolazione di una scaling law, quello è un rischio, non un piano.
L'assunto bigger-is-better è stato utile per un decennio. Sta morendo, con grazia e lentamente. La domanda interessante è cosa viene dopo — e qui le cose tornano a essere eccitanti. La creatività ingegneristica è stata schiacciata dal capex per anni. Sta per tornare a contare.
Prossimo nella serie: Cosa guida davvero il tasso di rendimento sul compute — rendimenti decrescenti sui parametri, il ruolo della qualità dei dati, i miglioramenti algoritmici che fanno il lavoro vero, e perché l'architettura è il soffitto di cui nessuno parla.


