Cosa guida davvero il tasso di rendimento sul compute

Nella Parte 1 abbiamo ricostruito la tesi di Sara Hooker secondo cui l'era del bigger-is-better sta finendo. La domanda naturale successiva — e quella su cui Hooker spende la maggior parte del saggio — è: se il compute non è più la leva dominante, cosa lo è?

La sua risposta: ciò che conta ora è il tasso di rendimento per unità di compute, e quel tasso è guidato da quattro cose, una sola delle quali è "più parametri". Vediamole in ordine, perché ognuna ha implicazioni su come un team di ingegneria dovrebbe scegliere modelli, progettare pipeline di training e fare budget di infrastruttura nel 2026.

1. Parametri: rendimenti decrescenti, poi stranezza

Nel 2016 Inception aveva 23M di parametri. Nel 2025 Qwen3-235B-A22B ne ha 235 miliardi. Quel salto di quattro ordini di grandezza ha comprato guadagni reali per un po'. Ha anche esposto un fatto profondamente scomodo: non capiamo perché ci servano la maggior parte di quei pesi.

Hooker cita un corpo di lavoro che lo rende concreto:

• Puoi rimuovere la maggioranza dei pesi addestrati dopo il training con perdita di performance minima (Gale et al. 2019; Han et al. 2015; Evci et al. 2019; Hooker et al. 2020). È il ben noto risultato di sparsity / pruning.
• Ma — ed ecco l'enigma — non puoi raggiungere la stessa performance se parti dalla rete più piccola in partenza. I pesi in più stanno facendo qualcosa durante il training che non stanno facendo in inference.
• Denil et al. (2014) hanno mostrato che un piccolo insieme di pesi può essere usato per predire il 95% dei pesi di una rete. Lo spazio è enormemente ridondante.

La spiegazione più semplice è scomoda: le reti profonde sono learners incredibilmente inefficienti della long tail. I pattern frequenti vengono appresi presto e a poco prezzo. Quelli rari — esattamente quelli che fanno sembrare un modello "intelligente" nei casi limite — richiedono una quota sproporzionata di compute e una quota sproporzionata di pesi, in gran parte perché addestriamo con minimizzazione della loss media ed esposizione uguale fra esempi. Il segnale degli attributi rari viene diluito negli update di batch.

Hooker la chiama "costruire una scala per la luna" — tecnicamente progredisci, ma con una struttura di costo che non può continuare a ripagare. Se accetti quella diagnosi, le prossime tre leve non sono ottimizzazioni opzionali. Sono la vera frontiera.

2. Qualità dei dati: la leva su cui tutti spendono troppo poco

La qualità dei dati compensa il compute. Hooker mette insieme un grande corpo di evidenza — deduplication, data pruning, data prioritization — che mostra come corpus di training meglio curati riducano il numero di parametri necessari a raggiungere una data soglia di capacità. Secondo Marion et al. (2023), Penedo et al. (2023), Singh et al. (2024b) e altri, dataset più piccoli ben curati possono eguagliare o battere dataset più grandi usati ingenuamente. Il tempo di training cala in modo diretto, e il risparmio di compute è strutturale, non incrementale.

Perché l'industria spende cronicamente troppo poco qui? Tre motivi familiari a chiunque abbia gestito un team ML:

1. Il lavoro di curation non si pianifica bene trimestre per trimestre. "Pulire i dati" è un verbo che non sta su una slide di roadmap. "Addestrare un modello 10× più grande" sì.
2. Il compute si compra; i dati curati si costruiscono. Puoi bonificare soldi a NVIDIA e avere GPU il trimestre prossimo. Non puoi bonificare soldi e avere un corpus pulito, deduplicato, bilanciato e a licenza chiara il trimestre prossimo.
3. Le metriche di successo si fanno gamare. I miglioramenti di benchmark dovuti alla qualità dei dati sembrano identici, in grafico, ai miglioramenti dovuti alla scala — quindi il credito va a chi è stato più rumoroso sullo scaling, non al data team che silenziosamente ha fatto la deduplication.

Lo shift che Hooker descrive — dal dato come snapshot congelato (MNIST, ImageNet, SQuAD) al dato come oggetto malleabile e ottimizzato — è uno dei cambi di paradigma più importanti del saggio. È anche il punto in cui esistono i rendimenti più asimmetrici per i team che non hanno budget da hyperscaler ma hanno competenza di dominio. Torneremo sul punto nella Parte 3 sotto "lo spazio malleabile dei dati".

3. Tecniche algoritmiche: il composto silenzioso

La terza leva è la più sottovalutata, soprattutto perché non arriva come un singolo grande breakthrough ma come un continuo gocciolio di tecniche che, individualmente, sembrano ottimizzazioni minori. Hooker elenca una lista parziale di ciò che ha compensato il compute grezzo negli ultimi anni:

• Instruction fine-tuning. Insegnare ai modelli a seguire istruzioni sopra il pre-training.
• Distillation da insegnanti più grandi. Uno "studente" piccolo e capace addestrato su dati sintetici da un "insegnante" più grande può approssimarlo a una frazione del costo di inference.
• Reasoning chain-of-thought. Un pattern di prompting e training che migliora la performance multi-step senza cambiare il compute di training.
• Aumento della context length. Cambiamenti architetturali e di attention che permettono allo stesso modello di condizionarsi su molte più informazioni in inference.
• Retrieval-augmented generation. Esternalizza la long tail dei fatti a uno strato di retrieval. Riduce l'allucinazione, riduce il bisogno di memorizzare, riduce la pressione sui parametri.
• RLHF e preference training. Constitutional AI, DPO, RLOO e altre varianti cambiano sostanzialmente il comportamento senza proporzionalmente più parametri.

Davidson et al. (2023) stimano che tecniche puramente di inference-time compute possano portare miglioramenti 5×–20× rispetto alla performance base post-training. Quel numero merita una pausa. Un miglioramento di capacità 10× che richiede zero retraining è il tipo di cosa che spacca le roadmap "modello più grande l'anno prossimo".

Per i team di ingegneria la lezione pratica è: la maggior parte della tua roadmap IA dovrebbe essere algoritmica, non di capacità. Otterrai più leva aggiungendo uno strato di retrieval implementato bene, un passo di verifica, un modello distillato task-specific o una struttura di prompt chain-of-thought, di quanto otterrai aspettando la prossima classe di taglia del modello.

4. Architettura: il fissatore del soffitto

L'architettura è la leva che tutti sottovalutano perché si muove di rado. Ma quando si muove, resetta ogni scaling law che l'ha preceduta. Hooker è diretta:

Un nuovo design architetturale può cambiare fondamentalmente la relazione tra compute e performance e rendere irrilevante qualsiasi scaling law esistente.

Abbiamo le ricevute storiche. Le CNN hanno cambiato la relazione per la visione (Ciresan et al. 2011; Krizhevsky et al. 2012; Szegedy et al. 2014). I Transformer l'hanno cambiata per il linguaggio (Vaswani et al. 2017). Ognuno di questi è stato un paradigm shift che ha reso obsolete le curve compute-performance precedenti e ha sbloccato un intero decennio di lavoro successivo.

Quasi certamente ne è dovuto un altro. Il saggio è esplicito sul fatto che l'architettura attuale "mostra tutti i segni di plateau nei rendimenti da compute aggiuntivo" e che "il prossimo passo significativo richiederà un'architettura interamente diversa". Le reti profonde sono particolarmente cattive su:

• Continual learning — soffrono di catastrophic forgetting quando i nuovi dati interferiscono con i comportamenti vecchi.
• Specializzazione della conoscenza — gli update di gradient globali non ritagliano regioni di competenza come fanno i sistemi biologici.
• Sample efficiency — hanno bisogno di molti più esempi di un bambino umano per task comparabili.

Una nuova architettura che ne risolvesse anche solo uno rimescolerebbe l'intero panorama. Per questo concentrare tutto il capex sullo scaling dell'architettura attuale è, nel framing di Hooker, sotto-investire nella fonte più probabile del prossimo salto.

Cosa cambia per i leader di ingegneria

Mettendo insieme queste quattro leve, ecco cosa porterei in una conversazione di pianificazione in Q3 2026:

• Smetti di classificare i modelli per conteggio di parametri. Classificali per capacità-per-token-per-dollaro sul tuo mix di task reale. La correlazione fra conteggio di parametri e quel rapporto è ormai debole.
• Sposta il data engineering più in alto nell'organigramma. Se non hai una persona senior che possiede curation, deduplication, compliance di licenza e prioritization dei dati, stai lasciando per terra la più grande leva gratuita.
• Tratta i miglioramenti algoritmici come prima mossa di default. Prima di commissionare un fine-tune o un deployment di modello più grande, esaurisci: retrieval, struttura di prompt, passi di verifica, distillation, tool use, chain-of-thought. La maggior parte dei team molla questo strato troppo presto.
• Traccia gli shift architetturali sul serio. Quando arriverà la prossima architettura post-transformer (e arriverà), i team che hanno sovra-investito in infrastruttura a forma di transformer — pipeline, ops, commitment con vendor — saranno i più lenti ad adattarsi. La diversità architetturale nel tuo stack è un hedge.
• Non confondere "strategia IA" con "selezione del modello". Il modello è una decisione fra tante. I dati, il retrieval, la verifica, il design human-in-the-loop — è lì che succede il lavoro differenziante.

Il framing di Hooker — tasso di rendimento per unità di compute — è quello giusto da interiorizzare. Sposta la conversazione da "quanto grande" verso "quanta capacità per unità di costo, e quali sono le leve che la muovono". Quella è una conversazione che i team di ingegneria possono effettivamente vincere, e che i CFO possono effettivamente prezzare.

---

Prossimo nella serie: Oltre lo scaling — i nuovi spazi di ottimizzazione per il progresso dell'IA. Metodi gradient-free, compute in inference come leva di prima classe, lo spazio malleabile dei dati, i sistemi agentici, e cosa la morte dello scaling significa (e non significa) per l'impatto ambientale.