Interviste
Ben Koska, Fondatore e Amministratore Delegato di SF Tensor – Serie di Interviste
Ben Koska, Fondatore e Amministratore Delegato di SF Tensor, è un ricercatore di intelligenza artificiale e ingegnere di sistemi noto per il suo lavoro su calcolo ad alte prestazioni, ottimizzazione del kernel e formazione di modelli efficienti. Il suo background spazia dallo sviluppo di infrastrutture di intelligenza artificiale a basso livello, al miglioramento della velocità di formazione e alla progettazione di strumenti che rendono lo sviluppo di modelli avanzati accessibile senza un sovraccarico di ingegneria pesante. Si concentra sulla costruzione di sistemi che spingono i limiti di velocità, portabilità e affidabilità su hardware eterogeneo.
SF Tensor è l’azienda che guida per trasformare quella filosofia in una piattaforma pratica. Introduce un modello di programmazione unificato, un ottimizzatore del kernel e uno strato di orchestrazione cross-cloud progettato per rimuovere la complessità dei carichi di lavoro di intelligenza artificiale distribuiti. La piattaforma mira a fornire agli ingegneri un ambiente pulito, agnostico per l’hardware, in cui possono scrivere una volta, distribuire ovunque e raggiungere automaticamente prestazioni elevate. La missione di SF Tensor è quella di rendere il calcolo dell’intelligenza artificiale drasticamente più veloce, più facile da gestire e libero da vincoli di fornitore.
Hai fondato SF Tensor a soli 19 anni, dopo aver già guidato l’ingegneria in molte startup. Cosa ti ha ispirato a intraprendere la sfida di reinventare l’infrastruttura di intelligenza artificiale così presto nella tua carriera?
Il problema che stiamo risolvendo è uno che mi sta molto a cuore, perché è uno che ho incontrato io stesso. Quando abbiamo sviluppato ciò che ora è il core stack di SF Tensor, non stavamo lavorando su un progetto commerciale, ma su un’iniziativa accademica. Avevamo ricevuto una sovvenzione per condurre alcune ricerche molto interessanti, ma abbiamo trascorso la maggior parte del nostro tempo a gestire l’infrastruttura e le ottimizzazioni, invece di fare ricerca. Abbiamo scoperto che le persone erano universalmente più interessate alla nostra tecnologia di infrastruttura, non al nostro progetto di ricerca.
SF Tensor sta affrontando uno dei problemi più difficili dell’intelligenza artificiale — liberarsi dal dominio di NVIDIA CUDA. Come hai approcciato la progettazione di un sistema che potesse raggiungere una vera portabilità hardware senza compromettere le prestazioni
Alla fine del giorno, tutta l’intelligenza artificiale si riduce a semplice matematica. Ogni modello è essenzialmente un insieme di operazioni matematiche che dobbiamo calcolare per ottenere i risultati. Trattandolo principalmente come un problema matematico piuttosto che un problema di informatica, possiamo identificare l’insieme più piccolo di vincoli sui calcoli, quindi generare milioni o miliardi di modi diversi per trasformare quei calcoli in codice macchina, trovando il più veloce. Questo è più facile a dirsi che a farsi, poiché non possiamo effettivamente eseguire miliardi di programmi diversi per trovare il più veloce, quindi per ridurre lo spazio di ricerca, abbiamo dovuto creare un modello matematico preciso per stimare la velocità di un dato programma per un dato hardware, che è una delle innovazioni chiave che rendono possibile ciò che facciamo oggi.
Il blog dell’azienda evidenzia innovazioni intorno all’ottimizzazione del compilatore e all’orchestrazione cross-cloud. Puoi spiegare come l’approccio di SF Tensor differisce da framework esistenti come PyTorch o JAX?
Non abbiamo ancora scritto un blog tecnico al riguardo, ma in realtà supportiamo framework come PyTorch e JAX, consentendo al codice scritto in essi di essere ottimizzato dal nostro stack. Ci sono diverse decisioni architettoniche che JAX e PyTorch hanno preso che li differenziano dal nostro stack, ma la più significativa è che trattiamo l’intero modello come un singolo calcolo da risolvere, invece di moduli individuali che devono essere ottimizzati individualmente e poi congiuntamente. A questo proposito, invece di applicare tecniche di ottimizzazione del compilatore tradizionali e cercare di applicare ogni ottimizzazione individuale, creiamo uno spazio di ricerca di milioni o talvolta miliardi di potenziali kernel e affermiamo che nessun essere umano può possibilmente creare un set di regole per trasformare qualsiasi codice nel più veloce, quindi dobbiamo semplicemente creare ogni combinazione e poi identificare il più veloce.
Molte startup si concentrano sull’efficienza di formazione, ma tu hai sottolineato l'”imposta sull’infrastruttura” — il tempo che i ricercatori perdono nella gestione del calcolo invece di innovare. Come SF Tensor affronta questo squilibrio?
Crediamo che entrambi i problemi debbano essere affrontati e gran parte del nostro lavoro è rivolto a risolvere l’efficienza di formazione, ma il problema più acuto che possiamo risolvere attualmente senza essere condizionati da future innovazioni è l’imposta sull’infrastruttura, poiché è un problema che abbiamo già risolto per noi stessi.
Hai menzionato di aver raggiunto riduzioni dei costi di formazione fino all’80%. Quali ottimizzazioni o innovazioni architettoniche rendono possibile ciò?
Il nostro intero stack software è costruito sull’idea che un compilatore basato sulla ricerca batterà sempre le regole create dall’uomo. Finora, il più grande vincolo su questi compilatori è stato il fatto che non è possibile testare e classificare miliardi o anche milioni di kernel. È stato quindi necessario per noi creare un modello matematico del calcolo che possa stimare con precisione il tempo che un dato calcolo, o un insieme di calcoli, richiederà su un dato hardware. Facendo ciò, possiamo espandere lo spazio di ricerca e poi ridurlo, il che è una necessità se si vuole trovare i kernel più veloci in modo coerente.
Come il tuo background nello sviluppo del linguaggio di programmazione Emma influenza l’architettura e la filosofia di SF Tensor verso le prestazioni e l’astrazione?
Non dirlo ai miei investitori, ma nel profondo sono ancora un ingegnere di compilatori. Sono sempre stato interessato a trovare modi diversi per rendere le cose anche solo marginalmente più veloci. Sviluppando Emma, abbiamo gettato via l’intero compilatore 4 o 5 volte; abbiamo iniziato da capo ogni volta perché abbiamo incontrato un’ottimizzazione che non potevamo implementare dato il sistema di vincoli attuale, costringendoci a rielaborare il sistema per renderlo ancora più generale, pur consentendo di scendere al livello più basso di ottimizzazione quando necessario, spesso andando contro i principi comuni di progettazione del compilatore e del linguaggio. Quei risultati e l’architettura risultante combinati con quasi due anni di ciò che sembrava a molti un’ottimizzazione minore e scommesse sbagliate si sono trasformati in un sistema che ci consente ora di iterare più velocemente e ottimizzare meglio di qualsiasi sistema che abbia seguito i principi comuni, poiché quei principi sono fondamentalmente progettati per CPU, non GPU e modelli di intelligenza artificiale.
Hai lavorato su esecuzioni di formazione su larga scala su oltre 4.000 GPU — quali sono state alcune delle lezioni più importanti apprese nella gestione del calcolo a quella scala?
Una delle più grandi è che il guasto hardware è molto più comune e problematico di quanto si possa supporre. Avendo trascorso molto tempo lavorando con programmi tradizionali e compilatori, generalmente parlando, un computer fa esattamente ciò che gli viene detto, e se qualcosa va storto, è quasi sempre colpa della persona che ha scritto il codice. Con le GPU, d’altra parte, il guasto hardware è un’evenienza comune, specialmente in esecuzioni di formazione distribuite su cluster molto grandi. Ciò va di pari passo con il fatto che, a differenza delle CPU che generalmente agiscono in modo deterministico e prevedibile, le GPU a volte, inspiegabilmente, fanno cose come abbassare la velocità dell’orologio senza alcun motivo apparente, rallentando l’intero processo di formazione perché un singolo chip sta funzionando più lentamente.
Y Combinator ha sostenuto alcune delle aziende di infrastruttura più trasformative nel settore tecnologico. Come quell’esperienza ha plasmato il tuo approccio alla scalabilità del prodotto e della visione di SF Tensor?
Andando in Y Combinator pensavo che la scommessa che volevamo fare allora fosse ambiziosa. Dopo solo alcune settimane, la nostra definizione di ambizioso era drasticamente cambiata, e abbiamo raddoppiato la scommessa su una scommessa ancora più grande. Inoltre, il senso di comunità e apprendimento che posso prendere il telefono o inviare un’e-mail a quasi qualsiasi azienda o persona là fuori e ricevere una risposta e un consiglio nell’arco di poche ore, ha cambiato il modo in cui pensiamo ad affrontare i problemi e ad abbracciare un approccio significativamente più collaborativo.
Guardando avanti, hai espresso interesse per modelli non LLM, robotica e dati sintetici. Come queste aree rientrano nella tua visione a lungo termine per l’azienda?
Gli LLM sono assolutamente una tecnologia interessante e avranno una parte integrante nel modo in cui il mondo apparirà nel futuro, ma il motivo per cui sono così più avanzati rispetto a qualsiasi altra area dell’intelligenza artificiale deriva principalmente dal fatto che c’è molto denaro investito nel loro sviluppo, e ci sono abbastanza persone che collaborano sul problema che hanno ottenuto una buona ottimizzazione. Se possiamo abbassare la barriera di ingresso, consentendo ai ricercatori di tutto il paese e del pianeta, anche a quelli con risorse limitate e scarsa conoscenza in ottimizzazioni, di eseguire la loro ricerca il più possibile a buon mercato ed efficientemente, credo che vedremo una nuova generazione di modelli che affronteranno problemi per i quali gli LLM non sono adatti, sia perché interagiscono con il mondo fisico o perché sono problemi che non possono essere espressi correttamente nel linguaggio.
Cosa pensi che lo stack di infrastruttura di intelligenza artificiale sarà come tra cinque anni — e dove vedi il ruolo di SF Tensor all’interno di esso?
Tra cinque anni, spero che molte più aziende avranno sviluppato e rilasciato i propri chip specializzati e che i ricercatori saranno in grado di sfruttare e utilizzare tali chip senza dover scrivere codice specifico per essi, idealmente senza nemmeno sapere che esistono. Quello è il futuro verso cui stiamo lavorando e che credo avremo un ruolo significativo nel plasmare.
Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare SF Tensor.
