Trump , AI, e the Man in The Loop.
Forse non si sa molto, ma la nuova parola chiave nel mondo delle vendite di AI non è più “replace people”. È diventata “man in the loop”. E questo è dovuto al fatto che i dementi che immaginavano aziende fatte di sola OpenAI, o di sola Claude, hanno provato a lasciarle lavorare unsupervised, senza nessuno che controllasse davvero cosa stessero facendo, e hanno ottenuto risultati meno che pessimi.
Sia chiaro: non è la prima volta che lo vedo. Quando ancora programmavo in ADA95 e C++, arrivò Java, e tutti i managerz ci guardavano con sufficienza, spiegandoci che con Java anche una scimmia avrebbe potuto fare le stesse cose che facevamo noi. Secondo loro, peraltro, eravamo pure sottopagati solo nella nostra fantasia: in realtà bastava prendere qualcuno a caso, dargli Eclipse, due manuali, una JVM, e il problema era risolto.
Ci fu davvero il periodo delle scimmie. Molti di noi — me compreso — diventarono System Engineer, perché sembrava che il mestiere del programmatore “serio” fosse ormai destinato a diventare una specie di lavoro da catena di montaggio digitale.
Poi, però, a un certo punto si cominciò a notare una cosa stranissima: alcuni, con Java, erano più bravi di altri.
E allora, puf: ottimizziamo Java di qui, regoliamo bene il Garbage Collector di là, capiamo come funzionano davvero i thread, i pool, le performance, la memoria, le librerie, i framework, le servlet, gli application server. Alla fine ne emerse una categoria di ottimi programmatori Java che, guarda caso, costavano quanto quelli di prima.
Nel frattempo, alcuni di noi si erano dati alla carriera di System Engineer. E che successe?
Arrivò il Cloud.
Morale: secondo loro, con il Cloud e con DevOps non ci sarebbe stato più bisogno di System Engineer. Bastava cliccare su una console, scrivere due YAML, spostare qualche container da una parte all’altra, e il mestiere spariva. Tutto automatico. Tutto elastico. Tutto “as a service”.
Realtà: è emersa una categoria di System Engineer certificati per il Cloud, che sono — ovviamente — anche più costosi di quelli che sanno “solo” gestire host. Perché adesso non devono sapere soltanto come funziona una macchina: devono sapere come funziona una piattaforma intera, con IAM, reti virtuali, storage distribuito, billing, sicurezza, automazione, osservabilità, disaster recovery, Kubernetes, e tutto il presepe.
Adesso arriva la AI.
Secondo loro, dovevano mandare a casa la gente, specialmente quella costosa, e rimpiazzarla. Il sogno era sempre lo stesso: togliere di mezzo competenza, esperienza, stipendi alti, persone che fanno domande, persone che dicono “no, così non funziona”, e sostituirle con una scatola magica che produce codice a comando.
Risultato: senza supervisione, le AI programmano, sì. Ma programmano malissimo. Producono codice che sembra codice, che a prima vista ha anche la forma del codice, che compila persino, qualche volta, ma poi va guardato, testato, corretto, incatenato al muro e interrogato con una lampada puntata in faccia. Perché i risultati, lasciati andare da soli, sono pessimi.
Morale?
Adesso la parola d’ordine è “man in the loop”.
Significa che qualcuno deve dire, in maniera precisa — anche se meno formale di prima — cosa fare. Qualcuno deve spiegare alla AI che cosa si vuole ottenere, quali vincoli rispettare, quali test scrivere, quale sia il DoD di ogni task, cioè la Definition of Done, e come verificare che il prodotto finito funzioni davvero.
Qualcuno deve dire alla AI non soltanto “scrivimi questa cosa”, ma anche “scrivila così, non fare quest’altra cosa, testa questo caso, considera questo errore, non rompere questa interfaccia, non inventarti una dipendenza a caso, non decidere da sola che il problema fosse un altro”.
E allora sì: avrete del buon codice.
E lo avrete, probabilmente, in circa metà del tempo. A volte in un terzo. Non è poco. Anzi, è tantissimo.
Ma chiaramente dovete scrivere prompt poderosi, dovete sapere cosa state chiedendo, dovete sapere riconoscere quando la risposta è sbagliata, e dovete avere con voi una AI che possa tenere tutto quel contesto senza dimenticarsi, dopo dieci minuti, perché era entrata nella stanza.
In altre parole: non avete eliminato il mestiere.
Avete solo cambiato l’interfaccia.
La mia opinione su questo la conoscete, ma siccome siamo in tempo di crociate contro la AI, allora la ripeto.
La prima AI fu inventata circa 15.000 anni fa. Si chiama “cane”.
È artificiale? Sì. Prima non esisteva in natura. È intelligente? Fuori di dubbio.
Ha mandato in pensione i cacciatori? No. Ha mandato in pensione i pastori? No.
Il cane può cacciare da solo? Sì. In natura alcuni sopravvivono benissimo. Ma non fanno surplus. Non tornano alla caverna con più carne di quanta ne serva a loro, non organizzano una dispensa, non costruiscono una strategia economica intorno alla caccia.
L’uomo può cacciare senza cane? Certo. Lo ha fatto, lo fa, e in alcuni casi lo farà ancora. Ma il surplus è poco, o comunque è molto più costoso da ottenere.
La coppia K9, uomo-cane, invece, caccia e fa surplus. Porta a casa, cioè, più ciccia di quella che mangia. Il cane non sostituisce l’uomo, e l’uomo non diventa inutile perché esiste il cane. Succede una cosa molto più interessante: nasce un’unità operativa nuova, composta da due intelligenze diverse, con capacità diverse, limiti diversi, sensi diversi, tempi di reazione diversi.
Il cane sente odori che l’uomo non sente. Corre in modo diverso. Insegue in modo diverso. Capisce segnali che l’uomo non vede. Ma l’uomo pianifica, conserva, distribuisce, decide dove andare domani, e soprattutto decide che cosa significhi “successo” dentro quella caccia.
Lo stesso, a mio avviso, vale per la AI.
Alla fine sarà una specie di unità K9: Uomo+AI.
Non una AI che lavora da sola, perché da sola può anche produrre qualcosa, ma non necessariamente produce valore. Non un uomo che rifiuta la AI per orgoglio professionale, perché può anche continuare a lavorare, ma probabilmente con meno surplus. La cosa interessante sarà la coppia: una persona competente, capace di decidere, giudicare, correggere, indirizzare, e una AI capace di accelerare, proporre, generare, esplorare alternative, eseguire pezzi di lavoro a velocità oscene.
Non mi meraviglia quindi che sia saltato fuori il nuovo tormentone del “man in the loop”. Era inevitabile.
E non mi meraviglierò quando le persone certificate per questo lavoro costeranno anche più di quanto costino ora. Perché, come sempre, il management parte sognando la scimmia economica, poi scopre che la scimmia economica fa danni, e alla fine paga carissimo qualcuno che sappia tenere il guinzaglio.
Non mi meraviglia quindi che adesso il contro-ordine sia “man in the loop”.
Anche per altri motivi.
Proviamo a fare una previsione di costi per una persona che voglia usare la AI scaricando il modello e facendolo girare sul proprio computer, senza mandare tutto a OpenAI, Anthropic, Google, Meta, o a qualche altro buco nero contrattuale nel quale entrano dati aziendali e da cui escono clausole scritte in legalese.
Gli serve, prima di tutto, che il computer abbia una scheda Thunderbolt. Meglio Thunderbolt 4 o 5, perché altrimenti cominciamo già male. Poi si tratta di comprare una enclosure esterna, cioè una scatola capace di contenere una scheda grafica desktop, alimentarla, raffreddarla, e collegarla al computer.
Dentro ci mettete una scheda grafica con una GPU decente. Tutto insieme fa una scatolina, più o meno elegante, che attaccate al computer e sulla quale fate girare la vostra AI in locale.
Sembra semplice, e in effetti lo è. Nel senso in cui è semplice anche dire “compro una macchina, ci metto la benzina e vado a Roma”. Poi scoprite che la macchina costa, la benzina costa, l’autostrada costa, il parcheggio costa.
Quanto costa?
| Fascia | Hardware | Costo indicativo | Cosa ci fai |
|---|---|---|---|
| Minimo sensato | eGPU enclosure + RTX 3090 24 GB usata | 1.400–2.000 € | 7B, 13B, 14B comodissimi; 30B/32B quantizzati; 70B solo molto compresso o parzialmente su RAM |
| Consumer nuovo potente | eGPU enclosure + RTX 4090 24 GB | 3.500–4.200 € | Come sopra, ma più veloce; per LLM il problema resta: sempre 24 GB |
| Consumer moderno migliore | eGPU enclosure/AI box + RTX 5090 32 GB | 4.100–5.200 € | 32B molto comodi; 70B in quantizzazione spinta/stretta; meglio della 4090 per VRAM |
| Workstation “seria” | eGPU enclosure + RTX A6000 / RTX 6000 Ada 48 GB | 4.500–9.000 € | 70B quantizzato bene, contesti decenti; molta meno sofferenza |
| Sboronata assoluta | RTX PRO 6000 Blackwell 96 GB + chassis adatto | 11.000–15.000+ € | 70B comodo, modelli più grossi quantizzati, contesti lunghi; però siamo nel territorio workstation vera |
I costi sono alti per qualcuno che se la voglia fare in casa, questo sì. Non siamo più nella fascia del giocattolo da appassionato che compra una scheda video, la infila in una scatola Thunderbolt e si sente improvvisamente il Lawrence Livermore National Laboratory. Siamo nei casi della workstation professionale o aziendale per PMI.
Ma non sono costi impossibili. Sono costi da attrezzatura professionale. Una workstation per far girare bene dei CAD avanzati, fare simulazioni serie, lavorare con rendering 3D, video pesante, modellazione tecnica, o calcolo scientifico, non costa meno. Anzi, spesso costa uguale, o di più.
La differenza è che, quando dici “workstation per CAD”, il manager capisce. Perché ha già visto l’ingegnere, il progettista, l’architetto, il tecnico con due monitor, la macchina rumorosa sotto la scrivania, la licenza software che costa come una Panda usata, e nessuno si scandalizza troppo.
Quando invece dici “workstation per AI locale”, nella testa di molti si accende ancora la lucina sbagliata: pensano al chatbot, al giochino, alla demo, alla ragazzina che chiede alla AI di scriverle una poesia su un unicorno depresso. Non pensano all'ambiente di sviluppo integrato con la AI.
E allora sembrano soldi buttati.
Ma se quella macchina serve a tenere dati aziendali in locale, a processare documenti interni, a scrivere codice sotto supervisione, a fare assistenza tecnica, a classificare ticket, a leggere specifiche, a produrre report, a cercare anomalie, a generare bozze, a interrogare knowledge base che non volete caricare sul cloud di qualcun altro, allora non è più un giocattolo.
È una workstation.
Solo che invece di avere sopra CAD, FEM, CFD, rendering o montaggio video, ha sopra modelli AI.
E siccome una PMI normalmente non compra una workstation professionale perché “fa figo”, ma perché qualcuno la usa per produrre valore, il ragionamento rimane lo stesso: quanto costa, quanto dura, quante ore-uomo risparmia, che rischi riduce, che lavoro rende possibile?
Visto così, 11–15K non sono bruscolini, ma non sono nemmeno fantascienza. Sono il prezzo di ingresso per una macchina professionale dedicata a un lavoro professionale.
Il problema, semmai, è che non basta comprarla.
Bisogna anche avere qualcuno che sappia usarla.
La domanda è: cosa succede nel momento in cui scatoline del genere cominciano a diffondersi?
Perché le più economiche non costano moltissimo, almeno non per un singolo professionista. Certo, non stiamo parlando della macchina capace di farvi girare il modello mostruoso, con 80 miliardi di parametri, contesto infinito, velocità da datacenter e risposta istantanea mentre voi sorseggiate il caffè.
Stiamo parlando di un compromesso.
Un compromesso senza troppe pretese, ma abbastanza efficace se lo lasciate lavorare la notte. Per il vostro pezzetto di codice, magari aspetterete fino al mattino. Ma va bene: la notte voi dormite. La macchina no.
Ed è qui che la faccenda diventa interessante.
Perché una cosa è comprare una workstation da 15.000 euro per far girare bene modelli grossi, con prestazioni professionali e tempi di risposta ragionevoli. Un’altra cosa è comprare una scatolina più modesta, collegarla al portatile o alla workstation che avete già, e usarla come acceleratore locale per lavori batch, analisi, refactoring, generazione di test, documentazione, controllo di codice, piccoli agenti, o assistenti specializzati.
Non farà miracoli. Non sostituirà un cluster. Non vi darà la sensazione di avere in casa un pezzo di datacenter travestito da tostapane.
Però lavora.
E soprattutto lavora mentre voi fate altro.
Questa è una differenza enorme. Perché non serve sempre avere la risposta in tempo reale. Ci sono lavori per i quali va benissimo lanciare un task la sera, andare a dormire, e trovare al mattino un risultato da controllare. Magari non perfetto, magari da correggere, magari da rimettere dentro il loop umano, ma comunque un risultato.
Un compromesso senza pretese, ma abbastanza efficace se lo lasciate lavorare la notte, potrebbe essere questo:
| Componente | Fascia realistica |
|---|---|
| Enclosure eGPU Thunderbolt decente | 350–500 € |
| Alimentatore, se non incluso | 100–200 € |
| Cavi, adattatori, minuteria | 50–100 € |
| GPU usata con 24 GB di VRAM, tipo RTX 3090 | 700–900 € |
| GPU nuova con 24 GB di VRAM, tipo RTX 4090 | 2.500–3.500 € |
| Totale “povero ma serio” | circa 1.200–1.700 € |
| Totale “voglio fare sul serio” | circa 3.000–4.200 € |
La domanda che vi farete ora è: ma allora perché tutti vogliono questi megadatacenter?
Se davvero una PMI, uno studio professionale, o persino un singolo consulente un po’ motivato possono comprarsi una scatola, infilarci dentro una GPU, scaricare un modello e farlo girare in locale, perché mai Microsoft, Google, Amazon, Meta, OpenAI e compagnia cantante stanno costruendo datacenter grandi come province belghe?
La risposta è semplice: perché i megadatacenter non servono soltanto a far girare i modelli.
Servono anche, e soprattutto, al lavoro di ingestion, training e deep learning.
Insomma: servono a creare i modelli che poi voi scaricate e fate girare. Una cosa è usare un modello già addestrato. Un’altra cosa è costruirlo, addestrarlo, ripulire i dati, macinare quantità oscene di testo, immagini, codice, audio, video, log, documenti, esempi, controesempi, preferenze umane, feedback, test, benchmark, ottimizzazioni e tutta la catena industriale che precede il momento in cui voi scrivete “fammi una funzione che ordina questa lista”.
È la differenza tra comprare un’automobile e costruire una fabbrica di automobili.
Voi potete comprare l’automobile, metterla in garage, farci manutenzione, cambiarle le gomme, magari anche modificarla un poco. Ma non per questo avete una pressa industriale, una catena di montaggio, una fonderia, un reparto verniciatura, un ufficio progettazione e una rete mondiale di fornitori.
Allo stesso modo, potete far girare un modello in casa. Potete anche fine-tunarlo, adattarlo, quantizzarlo, specializzarlo su qualche dataset aziendale, costruirci sopra una vostra interfaccia, metterlo dentro un processo. Ma creare da zero un modello competitivo è un’altra religione. Lì servono ferro, energia, dati, banda, storage, raffreddamento, competenze rare, e soprattutto una quantità di capitale che normalmente non si trova sotto il cuscino.
Quindi sì: la AI locale può diffondersi. E probabilmente si diffonderà, almeno in alcune nicchie professionali. Non sarà necessariamente la soluzione migliore per tutti, e certamente non sarà una soluzione energy saving su scala globale. Perché cento, mille, diecimila macchine sparse, magari inefficienti, magari mal raffreddate, magari accese tutta la notte per fare lavori che un datacenter ottimizzato farebbe meglio, non sono automaticamente più ecologiche solo perché stanno sotto la scrivania.
Anzi.
Dal punto di vista energetico, il datacenter centralizzato ha spesso vantaggi evidenti: raffreddamento progettato bene, carichi ottimizzati, hardware usato in maniera più continua, manutenzione professionale, economie di scala. La scatolina domestica, invece, ha un vantaggio diverso: privacy, controllo, indipendenza dal fornitore, latenza locale, possibilità di lavorare su dati che non volete spedire fuori.
Non è la stessa partita.
E qui arriva la domanda interessante: se tutti cominciano a far girare in casa, o in azienda, le AI locali, di cosa vive chi produce i modelli?
Perché addestrare modelli costa. Costa in GPU. Costa in corrente. Costa in personale. Costa in dati. Costa in ricerca. Costa in errori. Costa in esperimenti buttati via. Costa in datacenter che devono essere costruiti prima ancora di sapere se il modello che uscirà sarà davvero migliore del precedente.
Se il business model rimane “vi faccio pagare ogni prompt”, allora la diffusione dei modelli locali è un problema. Perché ogni utente che scarica il modello e lo fa girare da sé è un utente che non paga più il pedaggio a ogni domanda.
Ma se il business model cambia, allora la faccenda diventa diversa.
Chi produce modelli potrebbe vivere vendendo modelli migliori. Versioni enterprise. Licenze commerciali. Aggiornamenti. Modelli specializzati. Supporto. Certificazioni. Toolchain. Fine-tuning gestito. Dataset puliti. Sistemi di valutazione. Garanzie legali. Appliance preconfigurate.
Stack completi per aziende. Esattamente come è successo mille volte nell’informatica: il software può anche essere scaricabile, ma qualcuno paga per averlo buono, mantenuto, aggiornato, certificato, integrato e supportato.
In altre parole, il cloud AI non sparisce.
Ma non sarà più l’unica forma possibile.
Avremo datacenter enormi per produrre i modelli, addestrarli, aggiornarli, migliorarli e servirli a chi vuole pagare a consumo. E avremo, dall’altra parte, workstation, scatoline, server aziendali, appliance locali, piccoli cluster, roba da PMI, roba da professionisti, roba da consulenti che vogliono tenere il controllo del proprio lavoro.
Ed è qui che il “man in the loop” diventa ancora più importante.
Perché qualcuno dovrà scegliere il modello. Qualcuno dovrà capire se conviene usarlo in cloud o in locale. Qualcuno dovrà valutare il costo energetico, il costo hardware, il costo delle API, il rischio sui dati, la latenza, la qualità, la manutenzione, la sicurezza, il ciclo di aggiornamento.
Qualcuno dovrà sapere quando ha senso comprare la scatolina, quando ha senso usare il datacenter, e quando invece il progetto è solo l’ennesimo modo elegante per bruciare soldi con una dashboard moderna.
Quel qualcuno, ancora una volta, non sarà sostituito dalla AI.
Sarà quello che tiene il guinzaglio.
Andiamo a prendere i prezzi della AI che sostituisce il programmatore umano, quella “agentica” e tutto quanto.
Possiamo usare questa pagina, e chiederci quanto costerebbe mettere al lavoro Codex, cinque gioorni alla settimana, per otto ore.
https://developers.openai.com/api/docs/pricing
La pagina e' offuscata in maniera assurda, e' come se vi vendessero il pane calcolando il numero di lieviti che hanno lavorato per farlo.
Proviamo lo stesso.
Supponiamo di voler sostituire un programmatore.
Quindi non stiamo parlando del caso in cui chiedete alla AI “fammi una funzione in Python”, aspettate dieci secondi, copiate, incollate e andate a prendere il caffè. Stiamo parlando di otto ore al giorno, cinque giorni a settimana, con un limite di token molto alto, o idealmente senza limite pratico.
Cioè: la AI legge codice, produce codice, corregge codice, esegue test, interpreta errori, rilegge file, modifica patch, ricomincia, tiene contesto, accumula roba, la perde, gliela ridate, riprova, scrive documentazione, genera test, corregge test, e in generale fa quella cosa che i manager chiamano “sostituire un programmatore”, perché chiamarla “creare una macchinetta che consuma token come una mietitrebbia impazzita” suona meno bene nella slide.
Usando i prezzi API attuali, il conto dipende completamente da quanti token consuma ogni ora.
| Scenario | Token/ora stimati | GPT-5.1 / Codex | GPT-5.1-Codex mini | GPT-5.5 | GPT-5.5 Pro |
|---|---|---|---|---|---|
| Leggero assistito | 250k input + 50k output | 141 $/mese | 28 $/mese | 476 $/mese | 2.858 $/mese |
| Realistico pesante | 1M input + 200k output | 563 $/mese | 113 $/mese | 1.905 $/mese | 11.431 $/mese |
| Agentico pesante | 5M input + 1M output | 2.815 $/mese | 563 $/mese | 9.526 $/mese | 57.156 $/mese |
| Furia senza freni | 20M input + 4M output | 11.258 $/mese | 2.252 $/mese | 38.104 $/mese | 228.624 $/mese |
Con un uso leggero, diciamo 250.000 token di input e 50.000 token di output all’ora, un modello tipo GPT-5.1-Codex costa circa 140 dollari al mese. Sembra pochissimo.
Ma quello non è un programmatore sostituito. Quello è un assistente usato con parsimonia.
Se salite a un uso più realistico e pesante, diciamo 1 milione di token di input e 200.000 token di output all’ora, arrivate a circa 560 dollari al mese con GPT-5.1-Codex.
Se invece lo usate davvero come agente, lasciandolo macinare codice, test, errori, patch, tentativi e contesto per otto ore al giorno, una stima da 5 milioni di token di input e 1 milione di token di output all’ora vi porta intorno ai 2.800 dollari al mese.
E se lo lasciate correre senza guinzaglio, con contesti enormi, molti tentativi, molti file, molta generazione e molti giri a vuoto, potete arrivare tranquillamente oltre gli 11.000 dollari al mese.
E questo con GPT-5.1-Codex. Se usate modelli più costosi, tipo GPT-5.5 o GPT-5.5 Pro, il conto può diventare ridicolo molto in fretta.
Quindi no: la AI via API non costa “niente”. Costa poco se la usate poco. Costa ragionevolmente se la usate bene. Costa parecchio se la usate come un programmatore automatico che lavora otto ore al giorno. E costa una follia se la lasciate lavorare senza supervisione, cioè esattamente il modo in cui alcuni manager immaginavano di sostituire le persone.
Il punto è che un essere umano costa a tempo.
Una API costa a digestione.
Più legge, più scrive, più corregge, più sbaglia, più ritenta, più contesto si porta dietro, più paga.
E allora il famoso “man in the loop” non serve solo a migliorare la qualità. Serve anche a non far esplodere la fattura.
Come potete vedere nella colonna della sofferenza a destra, se fate programmazione professionale con un contesto discreto, una scatolina a programmatore ci esce eccome.
Il “realistico pesante” gli undicimila euro ve li brucia in un mese. La scatolina dura piu' di un mese.
Se andiamo sulla furia senza freni, cioe' su quello che per otto ore al giorno vuole codice elaborato, commentato, documentato, testato, eccetera, beh, li' siamo a cifre enormi.
Non appena questo modo di stimare i costi in anticipo si diffondera', inizierete a vedere le scatolette AI da ufficio che si diffondono.
Le troverete nelle offerte dei negozi di informatica, online, eccetera.
E allora saremo nella situazione nella quale i giganteschi datacenter, costosissimi, non avranno più un vero prodotto da vendere a quei prezzi.
Perché tutti vorranno i modelli, ma nessuno vorrà pagare ogni volta per usarli.
Capex è meglio di opex.
La scatolina vince.
O, perlomeno, vince abbastanza da fare male al modello economico attuale. Perché se una PMI, uno studio professionale, un consulente, o anche solo un programmatore abbastanza determinato possono comprarsi il proprio acceleratore locale, scaricare un modello, e lavorare senza pagare il tassametro a token, allora il datacenter non sparisce, ma perde una parte della rendita.
E quindi occorre, a tutti i costi, avere qualcosa che la scatolina non possa fare.
Il mito.
La leggenda.
Il modello talmente potente che non può essere scaricato. Il modello talmente pericoloso che non può essere dato in mano alla gente. Il modello che, a sentire i produttori — e persino il presidente USA — non può venire usato liberamente perché bucherebbe immediatamente i sistemi di difesa americani.
Improbabile.
Sappiamo bene che i cinesi sono avanti quanto gli USA sulla AI, o comunque abbastanza vicini da rendere ridicola la narrativa del “noi abbiamo il drago nucleare e loro stanno ancora litigando con Excel”. Se esistessero davvero modelli capaci, da soli, di bucare immediatamente i sistemi di difesa americani, quei sistemi sarebbero morti da mo’. Non perché lo dice qualche blogger cattivo, ma perché nel mondo reale, quando esiste un’arma simile, qualcuno prima o poi la usa, la copia, la ruba .
Ma il punto non è nemmeno se il mito sia vero.
Il punto è che, così facendo, alzano l’asticella della sfida.
La tua scatolina può scrivere codice? Sì.
Può fare refactoring? Sì.
Può leggere documentazione aziendale? Sì.
Può generare test? Sì.
Può aiutare un professionista? Sì.
Ma può fare staccah staccah ci stanno tracciando?
Eh?
No.
Perché quello è il mito. Perché nessuno lo ha mai visto. Perché quel modello non lo scarichi. Perché non lo puoi testare. Perché non lo puoi confrontare. Perché non lo puoi mettere nella tua scatolina. Però sui giornali esiste. Nelle conferenze esiste. Nelle audizioni al Congresso esiste.
Nei comunicati stampa esiste. Nelle slide degli investitori esiste.
E finché esiste lì, esiste abbastanza da giustificare il datacenter.
Ma anche questo durerà poco.
Lo sgonfiarsi della bolla della AI arriverà, secondo me, in quattro fasi.
- Cominceranno a vendersi scatoline esterne Thunderbolt/altro, con dentro una GPU, da attaccare al computer come oggi attaccate un disco esterno, solo più rumoroso, caldo e costoso.
- Sempre più professionisti e PMI capiranno che, per molti lavori, non serve pagare il superdatacenter a consumo. Basta una AI locale, magari più lenta, magari meno brillante, ma privata, controllabile, ammortizzabile e già abbastanza buona.
- Sempre meno persone spenderanno soldi nella AI “da superdatacenter” o nelle API per i casi d’uso ordinari. Rimarranno il training, i modelli enormi, i servizi enterprise, i carichi di picco, le aziende che vogliono outsourcing totale, e chi preferisce opex a capex. Ma la rendita del “paghi ogni domanda” inizierà a soffrire.
- E a quel punto arriverà il problema vero: fare i modelli costa troppissimo. Addestrarli costa. Raffinarli costa. Tenerli aggiornati costa. Fare ingestion costa. Curare i dataset costa. Pagare ricercatori, GPU, energia, storage, raffreddamento e datacenter costa. Se però il mercato vuole scaricare il modello, farlo girare in locale, e non pagare più l’uso a consumo, il conto non torna più.
POP.
Non necessariamente perché la AI sia inutile.
Ma perché, ancora una volta, il problema non sarà tecnico.
Sarà economico.
Uriel Fanelli
—Written using Blogfrei: https://git.keinpfusch.net/loweel/blogfrei
Fedi: @uriel@bbs.keinpfusch.net
XMPP: uriel@keinpfusch.net
vecchio blog: https://blog.keinpfusch.net
email: blog@keinpfusch.net