[0:03]Ovviamente, visto che con la programmazione automatica, ormai invece magari di scrivere il codice noi, scriviamo una specifica per l'implementazione iniziale o scriviamo prima
[0:20]un abbozzo di codice noi, poi una specifica di estensione e poi facciamo continuare gli i coding agent, quindi gli agenti che scrivono codice
[0:32]eh il lavoro, comunque, qualunque qualunque sia, diciamo, l'esatta struttura del nostro lavoro che dipende da quello che dobbiamo fare, da qual è l'utilizzo del progetto, da quanto critica sia la sua missione e così via,
[0:46]però ci siamo abituati che c'è una specifica, o almeno ci dovrebbe essere, poi ci sono quelli che vanno di prompt di due righe e poi per approssimazione successiva provano a far uscire la l'applicazione.
[0:58]Ciò va bene se non si hanno capacità progettuali, perché si è fuori da questa industria, da questo settore, però, secondo me, per fare le cose per bene, si dovrebbe scrivere prima una traccia per
[1:12]il modello del linguaggio da seguire in modo da arrivare al risultato migliore.
[1:16]Comunque, questa modalità di lavoro ha fatto convincere molti, è una fascinazione che ho subito pure io,
[1:27]nel senso che in parte è anche vera, che il software, più di essere ormai il codice sorgente,
[1:34]è la sua specifica. Peraltro, i coding agent funzionano abbastanza bene anche nella modalità contraria,
[1:46]quella che da un programma permette di estrarre la specifica.
[1:51]Cioè, io posso prendere un coding agent, metterlo in una un'area di lavoro dove ci sono diversi codici sorgenti e chiedergli
[2:03]studiati questo programma, questo sistema, cosa fa questo sistema, documentane ogni parte in modo che sia possibile poi riprodurlo
[2:15]solo a partire dalla specifica, possibilmente in un altro linguaggio o utilizzando delle diverse, un diverso framework, delle diverse estrazioni e così via.
[2:25]Allora, se le cose vanno così, uno può pensare in futuro non distribuiremo più
[2:33]il sorgente dei programmi, ma distribuiremo la specifica. La specifica sarà compilata in una sorgente,
[2:45]in base al livello dell'intelligenza artificiale di quel momento, per cui la stessa specifica può creare un sistema migliore, man mano che avanzano i sistemi di intelligenza artificiale, e che i coding agent si fanno migliori.
[2:59]A quel punto poi compili il programma e hai l'eseguibile, diciamo, per essere utilizzato dagli esseri umani.
[3:07]O dalle altre macchine, perché molti programmi sono, come dire, B2B, business to business, ma nel senso che vengono utilizzati più da altri programmi che da altri esseri umani.
[3:20]Questa idea qui non è priva di fondamento. È chiaro immaginare questo slittamento, questa metamorfosi, questa trasformazione della, come dire, del del della catena di montaggio del software, però non è accurata.
[3:40]Ma quello che accade, quando un software esiste da tanti anni, è che c'è un accumulo continuo di
[3:49]migliorie, piccoli dettagli che mai e poi mai avresti potuto dire, dei bug che è facile reintrodurre, se non sono già parte del codice sorgente.
[4:02]E molto spesso nella scrittura specifica sta roba qui non non la puoi catturare. Sono cose che succedono con l'esperienza, vedi con l'esperienza.
[4:11]Per cui, secondo me, il software continuerà ad essere scritto fondamentalmente come il codice sorgente, accompagnato, però, e questo è un passaggio importante, da una specifica, perché le cose non sono esclusive.
[4:27]Il software può essere una serie di codici sorgente di un'implementazione complicata più una specifica.
[4:33]La specifica serve alla gente per leggerla e nel giro di poco tempo avere idea di come funziona quel software,
[4:46]e il codice sorgente, invece, ne documenta i minuscoli dettagli, le più fini interazioni che non sarebbero ben catturate in termini testuali dal linguaggio naturale.
[4:59]Fin qui mi sembra che siano ragionamenti abbastanza condivisibili, ma quel che mi sembra, invece,
[5:12]introdurre una grande novità è il modo in cui certe librerie possono essere scritte.
[5:17]Non diventano specifica, ma diversi progetti specifici che risolvono problemi specifici,
[5:28]possono creare una costellazione di esempi che vengono utilizzati quando bisogna scrivere un nuovo sistema.
[5:35]Un esempio pratico di quello che mi sta succedendo in questi giorni, in cui sto scrivendo dei sistemi di inferenza con la programmazione automatica, cioè dei programmi che servono per eseguire nei computer propri
[5:48]dei modelli di tipo diverso. Ho implementato Flax, ora sto implementando Z-Image Turbo, un altro modello di sintesi delle immagini
[5:58]che ha delle similitudini con Flax ma anche alcune differenze. Ho implementato Voxstral, implementerò il trascrittore di Kuen,
[6:09]che è veramente piccolo, cioè è tipo 0,6 billion parameters, se mi ricordo bene,
[6:18]e quindi e promette di essere buona e questo permette praticamente di fare il bot Telegram che avevo scritto con Whisper.
[6:30]In sostanza diventa molto più interessante, nel senso che anche nel server, là dove lo installo io, può fare la trascrizione in maniera molto più veloce, perché Voxstral è 4
[6:39]miliardi di parametri, Whisper a medium è non lo so, un miliardo, se mi ricordo bene.
[6:51]Il Mister Whisper Large è qualcosa come 1,6 miliardi, insomma, sono più lenti. Voglio vedere se con Kuen riesco ad andare più veloce.
[7:02]Mi sono accorto di una cosa, una volta tu hai due approcci possibili per fare questa roba qua.
[7:09]Un approccio è quello di tipo alla GGML di Lama dot C++ e di avere una serie di kernel generici,
[7:22]un po' come Pytorch di di default, se non scrivi dei dei kernel, degli shader, diciamo custom,
[7:30]e poi combini combini queste primitive in modo da fare l'inferenza di un modello. Non sarà mai la la il modo più veloce di farlo,
[7:38]però è il modo sicuramente più comodo e più pulito. Se si vuole avere quella velocità in più, è necessario fare la fusione dei dei kernel in uno.
[7:53]Scusate, ho ricevuto una telefonata, devo andare a prendere mia figlia da scuola, ma mentre registro.
[7:59]Dicevo, GGML, o anche, diciamo, MLX, danno una serie di primitive
[8:10]che non sono specifiche per far andare il più velocemente possibile l'inferenza di certe famiglie di modelli, sono delle primitive generiche.
[8:20]Poi tu le combini assieme e fai l'inferenza dei modelli, ma se vuoi veramente trarre il massimo delle prestazioni possibili,
[8:28]devi fare altre cose, devi scriverti degli shader specifici per quei modelli là. Per cui perdi la
[8:35]perdi un sacco di roba, perdi tanto per iniziare il fatto di caricare il modello dai pesi, come li distribuisce il produttore, perché, per esempio, a te ti interessa l'inferenza con una pipeline in BF16.
[8:47]I pesi sono in FP32, quindi normali float, e tanto per iniziare se non fai una una conversione, e da questo punto di vista tante tanti tanti tanti sistemi di inferenza, infatti
[9:02]rinunciano alla ad essere troppo generalisti, per esempio, Lama.c++ ti forza ad avere i pesi in formato GGUF, perché sono già quantizzati eccetera eccetera, in modo da non fare trasformazioni al loading time.
[9:15]Ma questo non basta, dovrebbero avere i kernel fusi per ogni famiglia di modello, cosa che invece non fanno per cercare di supportare i modelli più velocemente possibile.
[9:30]Qual è il passaggio da questa idea che il prompt sia il nuovo programma, ma invece non lo è, come abbiamo detto, al fatto che però in realtà i coding agent modificano in maniera totale
[9:44]il modo in cui si può scrivere una nuova inferenza, quindi né scrivere ex novo tutto da zero
[9:54]e neanche utilizzare un framework di inferenza generalista che non ci dà le massime performance.
[10:01]Allora, ho iniziato a usare questo trucco. Dopo che ho fatto i primi due tre programmi di inferenza, ora che devo fare il quarto, ma l'ho usato questo sistema anche nel terzo,
[10:13]gli dico, guarda, io già ho scritto un'inferenza per MPS, quindi per metal, per Apple Silicon,
[10:24]molto performante per questi sistemi qua. Scrivi l'inferenza di questo nuovo modello andando a controllare l'implementazione che ho fatto in queste directory
[10:33]e utilizzale come template per appropriarti dei pattern, di tutti i trucchi che permettono di andare molto più veloci
[10:46]invece di fare un'inferenza generica. Guarda come sono stati creati gli shader ad hoc per far funzionare in maniera veloce quei modelli
[10:57]e creane di simili con le specificità, però, che ci sono nel modello di cui stiamo facendo ora l'inferenza.
[11:03]Quindi, in questo caso, in sostanza, il la la creazione del codice sorgente avviene partendo da
[11:11]altri codici sorgenti di altri progetti simili in cui c'è però un seminato, una cultura estraibile,
[11:23]una specifica, perché magari prima è giusto fare delle investigazioni che fanno capire all'intelligenza artificiale
[11:32]ehm di che si sta parlando dal punto di vista del modello esatto di cui bisogna fare l'inferenza, perché fare sta roba qua e dirgli, guarda, ne ho scritti già alcuni, va' a cercare come funziona
[11:46]mischiare gli step non è mai una buona idea. Non è mai una buona idea.
[11:51]Invece prima facciamo il lavoro per capire questo modello come funziona, quali sono le sue peculiarità.
[11:57]C'abbiamo molto chiaro come funziona la pipeline di inferenza di questo modello? Com'è la trasformazione di dati?
[12:03]Per esempio, nei modelli audio, c'è sempre la questione che bisogna capire come fare il padding, come fare la FFT per estrarre poi per generare i MEL,
[12:13]perché ovviamente non è che gli dà impasto il file wave così com'è. No, lo dividi in pezzettini, fai la trasformata di Fourier e che, praticamente, trasformi dal dominio
[12:25]del tempo al dominio, diciamo, delle delle frequenze. Devi non non gli dai i raw, diciamo, i samples che ci sono nel nel file wave.
[12:40]Gli dai, in questo pezzettino di di di di file wave, le frequenze che sono sono hanno la questa diverse frequenze hanno questa intensità.
[12:50]In questo pezzetto immediatamente dopo hanno questa intensità, in questo pezzetto hanno questa intensità e così via. Praticamente gli dai, è come prendere l'immagine di uno spettrogramma dell'audio,
[13:00]in cui c'è, praticamente, il tempo e le frequenze, e il cioè la heat map, i diversi colori sono quanto forte è quella frequenza in quel momento.
[13:12]Prendere questa roba qui e affettarla. Ok?
[13:18]Eh poi e trasformarla poi in una rappresentazione che è il Mel, che è più esplicita per il modello e poi fare far l'inferenza.
[13:26]Ora tutte ste robe qui prima gliele fai fare il lavoro di ricerca. Ti scarichi tu, tanto per iniziare se c'è la pipeline di esempio,
[13:33]Deo Gratias, te la guardi e e tanto per iniziare vedi immediatamente qual è la il modo in cui il modello funziona.
[13:42]Poi da quello estrai una specifica utilizzando l'agente. Controlli che la specifica sembra esatta.
[13:50]Ad io faccio poi un passaggio intermedio. Se la pipeline è troppo complicata faccio scrivere all'agente utilizzando Pytorch o un PII addirittura
[13:59]un'implementazione molto semplice dell'inferenza, in modo che c'è un file self-contained di 400, 500, 600 righe, che faccia completamente l'inferenza del modello.
[14:10]Poi da quello gli dici, guardati le tecniche che abbiamo utilizzato per fare l'inferenza di altri modelli per lo stesso hardware
[14:17]e trasferisci quel sapere e questo sapere, invece, di come questo modello esatto funziona in una nuova implementazione. Questo sì che mi sembra un cambiamento.
[14:29]Piuttosto che avere librerie generaliste che non arriveranno mai ad avere il massimo delle performance su alcuni ambiti,
[14:38]si ritrasforma il problema in un problema di estrazione di certi pattern e di reimplementazione da zero.
[14:45]Bene, ciao!
