Ben Koska, grundare och VD för SF Tensor – Intervjuerien

Ben Koska, grundare och VD för SF Tensor, är en AI-forskare och systemingenjör som är känd för sitt arbete med högpresterande beräkningar, kerneloptimering och effektiv modellträning. Hans bakgrund omfattar utveckling av lågnivå AI-infrastruktur, förbättring av träningsgenomströmning och design av verktyg som gör avancerad modellutveckling tillgänglig utan tunga ingenjörsöverhead. Han fokuserar på att bygga system som förbättrar gränserna för hastighet, portabilitet och tillförlitlighet över heterogena hårdvaror.

SF Tensor är det företag han leder för att förvandla den filosofin till en praktisk plattform. Det introducerar en enhetlig programmeringsmodell, en kerneloptimerare och en cross-cloud-orchestreringslager som är utformad för att ta bort komplexiteten i distribuerade AI-arbetsbelastningar. Plattformen syftar till att ge ingenjörer en ren, hårdvaruagnostisk miljö där de kan skriva en gång, distribuera överallt och automatiskt uppnå hög prestanda. SF Tensors mission är att göra AI-beräkningar dramatiskt snabbare, enklare att hantera och fria från leverantörsbunden.

Du grundade SF Tensor när du var 19 år gammal, efter att ha lett ingenjörsarbetet på flera startup-företag. Vad inspirerade dig att ta på dig utmaningen att förnya AI-infrastrukturen så tidigt i din karriär?

Problemet vi löser är ett som jag bryr mig djupt om, eftersom det är ett som jag själv har stött på. När vi utvecklade vad som nu är SF Tensors kärnstack, arbetade vi inte på ett kommersiellt projekt, utan på ett akademiskt företag. Vi hade fått ett bidrag för att genomföra några intressanta forskningar, men tillbringade den överväldigande majoriteten av vår tid med att hantera infrastruktur och optimeringar, istället för att genomföra forskningen. Vi upptäckte att människor var universellt mer intresserade av vår infrastrukturteknik, inte vårt forskningsprojekt.

SF Tensor hanterar ett av de tuffaste problemen inom AI — att bryta sig loss från NVIDIAs CUDA-dominans. Hur gick du tillväga för att designa ett system som kunde uppnå sann hårdvaruportabilitet utan att kompromissa med prestanda

I slutändan handlar all AI om enkla matematiska beräkningar. Varje modell är i princip en uppsättning matematiska operationer som vi måste beräkna resultaten för. Genom att behandla det primärt som ett matematiskt problem snarare än ett datavetenskapligt problem, kan vi identifiera den minsta uppsättningen begränsningar för beräkningarna, sedan generera miljoner till miljarder olika sätt att omvandla dessa beräkningar till maskinkod, och hitta den snabbaste. Det är lättare sagt än gjort, eftersom vi inte kan köra miljoner olika program för att hitta den snabbaste, så för att beskära vår sökrymd, var vi tvungna att komma på en exakt matematisk modell för att uppskatta hastigheten på ett visst program för en viss hårdvara, vilket är en av de viktigaste innovationerna som gör det möjligt för oss att göra det vi gör idag.

Företagets blogg betonar innovationer kring compiler-optimering och cross-cloud-orchestrering. Kan du förklara hur SF Tensors tillvägagångssätt skiljer sig från befintliga ramverk som PyTorch eller JAX?

Vi har inte skrivit en teknisk blogg om det ännu, men vi stöder faktiskt ramverk som PyTorch och JAX, och tillåter kod skriven i dem att optimeras av vår stack. Det finns flera arkitekturbeslut som JAX och PyTorch har fattat som skiljer sig från vår stack, men det mest betydande är att vi behandlar hela modellen som en enda beräkning som ska lösas, istället för enskilda moduler som måste optimeras individuellt och sedan gemensamt. I den mån, istället för att tillämpa traditionella compiler-optimeringstekniker och försöka tillämpa varje enskild optimering, skapar vi en sökrymd av miljoner till ibland miljarder potentiella kärnor och hävdar att ingen människa kan möjligtvis komma på en uppsättning regler för att omvandla vilken kod som helst till den snabbaste, så vi måste istället skapa varje kombination och sedan identifiera den snabbaste.

Många startup-företag fokuserar på tränings-effektivitet, men du har betonat “infrastruktur-avgiften” — den tid forskare förlorar på att hantera beräkningar istället för att innovativa. Hur hanterar SF Tensor denna obalans?

Vi tror att båda problemen måste hanteras, och en hel del av vårt arbete går till att hantera tränings-effektivitet, men det mest akuta problemet som vi kan lösa just nu utan att vara beroende av framtida innovationer är infrastruktur-avgiften, eftersom det är ett problem som vi redan har löst för oss själva.

Du har nämnt att ni har uppnått upp till 80 procents reduktion av träningskostnader. Vilka specifika optimeringar eller arkitekturgenombrott gör detta möjligt?

Vår hela programvaru-stack bygger på idén att en sök-baserad compiler alltid kommer att slå mänskligt skapade regler. Hittills har den största begränsningen för dessa compilers varit det faktum att det inte är möjligt att testa och rangordna miljoner eller till och med miljarder kärnor. Det var därför nödvändigt för oss att skapa en matematisk modell av beräkningar som kan uppskatta den tid som en given beräkning eller uppsättning beräkningar kommer att ta på en given hårdvara. Genom att göra detta kan vi utöka vår sökrymd och sedan trimma den ner, vilket är en nödvändighet om vi vill hitta de snabbaste kärnorna konsekvent.

Hur påverkar din bakgrund i att bygga programmeringsspråket Emma SF Tensors arkitektur och filosofi mot prestanda och abstraktion?

För att vara ärlig, jag är fortfarande en compiler-ingenjör i hjärtat. Jag har alltid varit intresserad av att hitta olika sätt att göra saker och ting bara lite snabbare. När vi utvecklade Emma kastade vi ut hela compiler fyra eller fem gånger; vi började från scratch, varje gång eftersom vi stötte på en optimering som vi inte kunde implementera med de nuvarande begränsningarna, vilket tvingade oss att omkonstruera systemet för att göra det mer allmänt, samtidigt som vi tillåter oss att gå ner till den lägsta nivån av optimering när det behövs, ofta emot vanliga principer för compiler- och språkdesign. Dessa lärdomar och den resulterande arkitekturen kombinerade nästan två års vad som såg ut som mindre optimeringar och felaktiga vad, men har ackumulerats till ett system som tillåter oss att iterera snabbare och optimera bättre än något av de system som följde vanliga principer, eftersom dessa principer i grunden är utformade för CPU:er, inte GPU:er och AI-modeller.

Du har arbetat med storskaliga träningskörningar över 4 000+ GPU:er — vilka var några av de största lärdomarna från att hantera beräkningar i den skalan? 

En stor lärdom är att maskinvarufel är mycket vanligare och mer problematiska än man kan tro. Efter att ha tillbringat mycket tid med att arbeta med traditionella program och compilers, generellt sett gör en dator exakt som den blir tillsagd, och om något går fel, är det nästan alltid fel på den person som skrev koden. Med GPU:er, å andra sidan, är maskinvarufel en vanlig förekomst, särskilt i distribuerad träningskörning på extremt stora kluster. I samband med detta är det faktum att till skillnad från CPU:er som generellt sett beter sig på ett deterministiskt och förutsägbart sätt, kan GPU:er ibland oförklarligt göra saker som att sänka klockhastigheten utan synbar anledning, vilket bromsar ner hela träningsprocessen eftersom en enda chip körs långsammare.

Y Combinator har stöttat några av de mest omvälvande infrastruktur-företagen inom tech. Hur har den erfarenheten format din tillvägagångssätt för att skala SF Tensors produkt och vision? 

När jag gick in i Y Combinator trodde jag att den insats vi ville göra då var ambitiös. Efter bara några veckor hade vår definition av ambitiös förändrats drastiskt, och vi satte oss för en ännu större insats. För det andra, känslan av samhörighet och lärande som jag kan ringa upp eller skicka ett e-postmeddelande till nästan vilket företag eller person som helst och få ett svar och råd inom några timmar till dagar, har förändrat hur vi tänker på att tackla problem och anta en betydligt mer samarbetsinriktad tillvägagångssätt.

Om du ser framåt, har du uttryckt intresse för icke-LLM-modeller, robotik och syntetisk data. Hur passar dessa områden in i din långsiktiga vision för företaget? 

LLM:er är absolut en intressant teknik och kommer att ha en integrerad del i hur världen ser ut i framtiden, men anledningen till att de är så mycket mer avancerade än något annat område inom AI beror främst på att det investeras mycket pengar i deras utveckling, och att det finns tillräckligt med människor som samarbetar på problemet så att de har blivit ganska optimerade. Om vi kan sänka inträdesbarriären, så att forskare runt om i landet och på planeten, även de med begränsade resurser och liten eller ingen kunskap om optimeringar, kan utföra sin forskning så billigt och effektivt som möjligt, tror jag att vi kommer att se en hel ny generation av modeller som kommer att tackla problem som LLM:er inte är lämpade för, antingen för att de interagerar med den fysiska världen eller för att de är problem som inte kan uttryckas korrekt i språk.

Vad tror du att AI-infrastruktur-stapeln kommer att se ut som om fem år — och var ser du SF Tensors roll inom den?

Om fem år hoppas jag att många fler företag kommer att ha utvecklat och släppt sina egna specialiserade chip, och att forskare kommer att kunna utnyttja och använda dem utan att behöva skriva kod specifikt för dem, idealiskt sett utan att ens behöva veta att de existerar. Det är den framtid vi arbetar mot, och jag tror att vi kommer att ha en betydande roll i att forma den.

Tack för den underbara intervjun, läsare som vill lära sig mer kan besöka SF Tensor.