Ben Koska, grundlægger og administrerende direktør for SF Tensor – Interviewserie

Ben Koska, grundlægger og administrerende direktør for SF Tensor, er en AI-forsker og systemingeniør kendt for sit arbejde med højpræstationsberegning, kerneloptimering og effektiv modeltræning. Hans baggrund omfatter udvikling af lavniveuau AI-infrastruktur, forbedring af træningsgennemløb og design af værktøjer, der gør avanceret modeludvikling tilgængelig uden tung vægtsætning af ingeniørarbejde. Han fokuserer på at opbygge systemer, der presser grænserne for hastighed, bæring og pålidelighed på tværs af heterogene hardware.

SF Tensor er det selskab, han leder for at omsætte denne filosofi til en praktisk platform. Det introducerer en samlet programmeringsmodel, en kerneloptimerer og en cross-cloud-koordineringslag, der er designet til at fjerne kompleksiteten af distribuerede AI-arbejdsbyrder. Platformen har til formål at give ingeniører en ren, hardware-agnostisk miljø, hvor de kan skrive én gang, udrulle overalt og automatisk opnå høj ydeevne. SF Tensors mission er at gøre AI-beregning dramatisk hurtigere, lettere at styre og fri for vendor-lås.

I grundlagde SF Tensor, da du kun var 19 år gammel, efter allerede at have ledet ingeniørarbejde i flere startups. Hvad inspirerede dig til at påtage dig udfordringen med at genopfinde AI-infrastruktur så tidligt i din karriere?

Problemet, vi løser, er et, som jeg dybt omfatter, fordi det er et, jeg selv har stået overfor. Da vi udviklede, hvad der nu er SF Tensors kernestack, arbejdede vi ikke på et kommercielt projekt, men på et akademisk projekt. Vi havde modtaget en bevilling til at udføre nogle rigtig interessante forskningsprojekter, men tilbragte det meste af vores tid med at håndtere infrastruktur og optimeringer i stedet for at udføre forskning. Vi fandt ud af, at folk var universelt mere interesseret i vores infrastrukturteknologi end i vores forskningsprojekt.

SF Tensor tackler en af de sværeste problemer i AI – at bryde fri fra NVIDIAs CUDA-dominans. Hvordan gjorde du tilgangen til at designe et system, der kunne opnå sand hardware-portabilitet uden at gå på kompromis med ydeevnen

Til sidst handler det hele af AI om simple matematiske beregninger. Hver model er i virkeligheden en samling af matematiske operationer, som vi skal beregne resultaterne for. Ved at behandle det primært som et matematisk problem i stedet for et computerproblematik, kan vi identificere den mindste sæt af begrænsninger for beregningerne og derefter generere millioner til milliarder af forskellige måder at omdanne disse beregninger til maskinkode og finde den hurtigste. Det er lettere sagt end gjort, da vi ikke kan køre milliarder af forskellige programmer for at finde den hurtigste, så for at beskære vores søgefelt, måtte vi udvikle en matematisk model til at estimeere hastigheden af et givent program for en given hardware, hvilket er en af de centrale innovationer, der gør, hvad vi gør muligt i dag.

Selskabets blog fremhæver innovationer omkring compiler-optimering og cross-cloud-koordinering. Kan du forklare, hvordan SF Tensors tilgang adskiller sig fra eksisterende rammer som PyTorch eller JAX?

Vi har ikke skrevet en teknisk blog om det endnu, men vi støtter faktisk rammer som PyTorch og JAX, så kode skrevet i dem kan optimeres af vores stack. Der er flere arkitektoniske beslutninger, som JAX og PyTorch har truffet, som adskiller dem fra vores stack, men den mest betydningsfulde er, at vi behandler hele modellen som en enkelt beregning, der skal løses, i stedet for enkeltstående moduler, der skal optimeres individuelt og derefter sammen. For denne grund behandler vi ikke traditionelle compiler-optimeringsteknikker og prøver at anvende hver enkelt optimering, men i stedet opretter vi et søgefelt på millioner til milliarder af potentielle kernels og gør krav på, at ingen menneske kan muligvis komme op med en samling af regler til at omdanne en given kode til den hurtigste, så vi må i stedet oprette hver kombination og derefter identificere den hurtigste.

Mange startups fokuserer på træningseffektivitet, men du har understreget “infrastruktur-afgiften” – den tid, som forskere taber på at styre beregning i stedet for at innovere. Hvordan adresserer SF Tensor denne ubalance?

Vi tror, at begge problemer må løses, og en stor del af vores arbejde går til at løse træningseffektivitet, men det mest akutte problem, som vi kan løse lige nu uden at være afhængig af fremtidige innovationer, er infrastruktur-afgiften, da det er et problem, vi allerede har løst for os selv.

Du har nævnt op til 80% reduktion i træningsomkostninger. Hvad specifikke optimeringer eller arkitektoniske gennembrud gør dette muligt?

Hele vores software-stack er bygget på idéen om, at en søgebaseret compiler altid vil slå menneskeskabte regler. Indtil nu har den største begrænsning for disse compilere været, at det ikke er muligt at benchmark og rangere milliarder eller endda millioner af kernels. Det var derfor nødvendigt for os at oprette en matematisk model af beregning, som kan estimeere tiden, som en given beregning eller en samling af beregninger, vil tage på en given hardware. Ved at gøre dette kan vi udvide vores søgefelt og derefter beskære det, hvilket er en nødvendighed, hvis man vil finde de hurtigste kernels konsekvent.

Hvordan påvirker din baggrund i opbygning af Emma-programmeringssproget SF Tensors arkitektur og filosofi over for ydeevne og abstraktion?

Fortæl ikke mine investorer, men i hjertet er jeg stadig en compiler-ingeniør. Jeg har altid været interesseret i at finde forskellige måder at gøre tingene endnu bare incrementerligt hurtigere. I udviklingen af Emma kastede vi hele compileren 4 eller 5 gange; vi startede fra scratch hver gang, fordi vi stødte på en optimering, som vi ikke kunne implementere givet de nuværende begrænsninger, hvilket tvang os til at genkonstruere systemet til at være endnu mere generelt, mens vi stadig tillod os at gå ned på det laveste niveau af optimering, når det var nødvendigt, ofte imod almindelige principper for compiler- og sprogdesign. Disse erfaringer og den resulterende arkitektur kombinerer næsten to års, hvad der så ud som mindre optimeringer og forkerte væddemål, har akkumuleret sig til et system, der tillader os at iterere hurtigere og optimere bedre end nogen af de systemer, der fulgte almindelige principper, fordi disse principper er fundamentalt designet til CPU’er, ikke GPU’er og AI-modeller.

Du har arbejdet med storstilet træningskørsler på over 4.000 GPU’er – hvad var nogle af de største lærdomme fra at styre beregning i den skala? 

En stor lærdom er, at hardware-fejl er langt mere udbredt og problematisk, end man måske antager. Efter at have tilbragt en del tid med at arbejde med traditionelle programmer og compilere, generelt taler en computer præcis, som den bliver fortalt, og hvis noget går galt, er det næsten altid skylden hos personen, der skrev koden. Med GPU’er er hardware-fejl en almindelig foreteelse, især i distribueret træning på ekstremt store cluster. Det følger hånd i hånd med, at til forskel fra CPU’er, der generelt opfører sig på en forudsigelig og deterministisk måde, kan GPU’er nogen gange uforklarligt gøre ting som at sænke urtakt for ingen åbenbar grund, hvilket langsommere hele træningsprocessen, fordi en enkelt chip kører langsommere.

Y Combinator har støttet nogle af de mest transformative infrastrukturselskaber i tech. Hvordan har denne oplevelse formet din tilgang til at skala SF Tensors produkt og vision? 

Da jeg startede i Y Combinator, troede jeg, at det væddemål, vi ville gøre dengang, var ambitiøst. Efter kun få uger havde vores definition af ambitiøst ændret sig drastisk, og vi satte vores lid til et endnu større væddemål. For det andet har fornemmelsen af fællesskab og læring, som jeg kan ringe til eller sende en email til næsten ethvert selskab eller person derude og få svar og råd inden for få timer til dage, ændret måden, vi tænker om at tackle problemer og omfavne en mere samarbejdsorienteret tilgang.

I fremtiden har du udtrykt interesse for ikke-LLM-modeller, robotteknologi og syntetisk data. Hvordan passer disse områder ind i din langsigtede vision for selskabet? 

LLM’er er absolut en interessant teknologi og vil have en integreret del i, hvordan verden ser ud i fremtiden, men grunden til, at de er så meget mere avancerede end noget andet område af AI, stammer hovedsageligt fra, at der investeres meget i deres udvikling, og der er nok mennesker, der samarbejder om problemet, så de er blevet ret godt optimeret. Hvis vi kan sænke barrieren for indgang, så forskere over hele landet og planeten, selv med begrænsede ressourcer og lidt eller ingen viden om optimeringer, kan udføre deres forskning så billigt og effektivt som muligt, tror jeg, vi vil se en helt ny generation af modeller dukke op, der vil tackle problemer, som LLM’er ikke er egnede til, enten fordi de interagerer med den fysiske verden eller fordi de er problemer, der ikke kan udtrykkes ordentligt i sprog.

Hvad tror du, AI-infrastruktur-stakken vil se ud som om fem år – og hvor ser du SF Tensors rolle indenfor den?

Om fem år håber jeg, at mange flere selskaber vil have udviklet og frigivet deres egne specialiserede chip, og at forskere vil kunne udnytte og anvende dem uden at skulle skrive kode specifikt til dem, idealt uden endda at skulle vide, at de findes. Det er den fremtid, vi arbejder imod, og som jeg tror, vi vil have en betydelig rolle i at forme.

Tak for det gode interview, læsere, der ønsker at lære mere, skal besøge SF Tensor.