Il nome non deve trarre in inganno: MacroStories è un modello da 19.969 parametri, 81 KB in FP32, con uno stato nascosto da 32 dimensioni e un vocabolario di appena 378 token. L'architettura usa un solo blocco decoder riapplicato quattro volte con pesi condivisi. Dentro una distribuzione narrativa ristretta, non generalista, riesce a produrre storie di 100–300 parole con obiettivo, problema, azioni pertinenti e risoluzione. Il tutto senza GPU: l'esecuzione su CPU è estremamente rapida.

Il progetto arriva da una linea di lavoro che spinge verso il basso i modelli in stile TinyStories. La notizia non è la qualità letteraria. È che la coerenza narrativa, anche in un dominio vincolato, può emergere da un'architettura quasi minimale. Questo cambia il calcolo per chi sviluppa applicazioni a dominio ristretto: invece di adattare un LLM da miliardi di parametri e pagarne l'infrastruttura, si può partire da un modello specializzato che non richiede acceleratori e consuma una frazione delle risorse. Il trade-off è netto: fuori dal perimetro addestrato il modello non generalizza. Ma quando il perimetro è noto, la complessità non necessaria diventa costo.

Il fatto che un singolo blocco decoder venga riapplicato quattro volte con pesi condivisi segnala una direzione per l'efficienza: riusare la capacità invece di aggiungere strati. È un vincolo architetturale che riduce l'ingombro e avvicina l'esecuzione a contesti edge e on-premise, dove memoria e dissipazione contano più della flessibilità. Per chi valuta deployment locale, il caso è estremo ma istruttivo: se il compito è davvero circoscritto, la soglia hardware può collassare.

Non ci sono benchmark di costo nella fonte, ma il principio di fondo è quello del TCO: un modello che evita la GPU elimina una voce rilevante dell'infrastruttura. Naturalmente, il confronto regge solo se l'attività rientra nella distribuzione del modello; per un assistente generalista non basterebbe. Eseguire tutto in locale, su CPU, toglie anche la necessità di inviare testo a servizi cloud, un aspetto che interessa chi ha vincoli di sovranità dei dati. Per chi valuta deployment on-premise, esistono trade-off tra capacità generale e costo computazionale.

L'autore, dal canto suo, è più interessato a capire quanto si possa ancora abbassare il limite inferiore e invita a provare a rompere il modello. È una domanda sperimentale, non un annuncio commerciale.