Ben Koska, Założyciel i Dyrektor Generalny SF Tensor – Seria Wywiadów

Ben Koska, Założyciel i Dyrektor Generalny SF Tensor, jest badaczem sztucznej inteligencji i inżynierem systemów, znanym ze swojej pracy nad wysokowydajnymi obliczeniami, optymalizacją jądra i wydajnym szkoleniem modeli. Jego doświadczenie obejmuje rozwijanie niskopoziomowej infrastruktury sztucznej inteligencji, poprawę wydajności szkolenia i projektowanie narzędzi, które umożliwiają rozwój zaawansowanych modeli bez ciężaru inżynierskiego. Koncentruje się na budowaniu systemów, które pushują granice szybkości, przenośności i niezawodności na heterogenicznym sprzęcie.

SF Tensor to firma, którą kieruje, aby wprowadzić tę filozofię w praktykę. Wprowadza jednolity model programowania, optymalizator jądra i warstwę orchestracji międzychmurnej, zaprojektowaną w celu usunięcia złożoności rozproszonych obciążeń sztucznej inteligencji. Platforma ma na celu dać inżynierom czyste, niezależne od sprzętu środowisko, w którym mogą pisać raz, wdrażać wszędzie i automatycznie osiągać wysoką wydajność. Misją SF Tensor jest uczynienie obliczeń sztucznej inteligencji znacznie szybszymi, łatwiejszymi w zarządzaniu i wolnymi od blokady dostawcy.

Założyłeś SF Tensor w wieku 19 lat, po tym, jak już kierowałeś inżynierią w kilku startupach. Co skłoniło Cię do podjęcia wyzwania reinwencji infrastruktury sztucznej inteligencji tak wcześnie w swojej karierze?

Problem, który rozwiązujemy, jest tym, którym się głęboko przejmuję, ponieważ jest to problem, z którym spotkałem się sam. Kiedy rozwijaliśmy to, co jest teraz rdzeniem SF Tensor, nie pracowaliśmy nad projektem komercyjnym, ale nad projektem akademickim. Otrzymaliśmy grant na przeprowadzenie pewnych interesujących badań, ale spędziliśmy większość czasu na walce z infrastrukturą i optymalizacjami, zamiast prowadzić badania. Stwierdziliśmy, że ludzie byli zdecydowanie bardziej zainteresowani naszą technologią infrastruktury, a nie naszym projektem badawczym.

SF Tensor zajmuje się jednym z najtrudniejszych problemów w sztucznej inteligencji — przerwaniem dominacji NVIDIA CUDA. Jak podejście do zaprojektowania systemu, który mógłby osiągnąć prawdziwą przenośność sprzętu bez kompromisowania wydajności?

Na końcu dnia, cała sztuczna inteligencja sprowadza się do prostych matematyki. Każdy model jest podstawowo zestawem operacji matematycznych, których wyniki musimy obliczyć. Traktując to głównie jako problem matematyczny, a nie problem informatyczny, możemy zidentyfikować najmniejszy zestaw ograniczeń obliczeń, a następnie wygenerować miliony do miliardów różnych sposobów, aby te obliczenia przekształcić w kod maszynowy, znajdując najszybszy. To łatwiej powiedzieć niż zrobić, ponieważ nie możemy tak naprawdę uruchomić miliardów różnych programów, aby znaleźć najszybszy, więc aby przyciąć nasz przestrzeń wyszukiwania, musieliśmy stworzyć dokładny model matematyczny, aby oszacować szybkość danego programu dla danego sprzętu, co jest jednym z podstawowych innowacji, które umożliwiają nam to, co robimy dzisiaj.

Blog firmy podkreśla innowacje wokół optymalizacji kompilatora i orchestracji międzychmurnej. Jak podejście SF Tensor różni się od istniejących ram, takich jak PyTorch czy JAX?

Nie napisaliśmy jeszcze technicznego bloga o tym, ale tak naprawdę wspieramy ramy takie jak PyTorch i JAX, pozwalając kodowi napisanemu w nich być optymalizowanym przez nasz stos. Są pewne decyzje architektoniczne, które JAX i PyTorch podjęły, które różnią się od naszego stosu, ale najbardziej znaczącą jest to, że traktujemy cały model jako jeden obliczenie do rozwiązania, zamiast poszczególnych modułów, które muszą być oddzielnie i wspólnie zoptymalizowane. W tym celu, zamiast stosowania tradycyjnych technik optymalizacji kompilatora i prób stosowania każdej optymalizacji, tworzymy przestrzeń wyszukiwania milionów do czasem miliardów potencjalnych jąder i twierdzimy, że żaden człowiek nie może stworzyć zestawu reguł, aby przekształcić dowolny kod w najszybszy, więc musimy po prostu stworzyć każdą kombinację, a następnie zidentyfikować najszybszą.

Wiele startupów koncentruje się na efektywności szkolenia, ale Ty podkreślasz “podatek infrastrukturalny” — czas, jaki badacze tracą na zarządzaniu obliczeniami zamiast innowacjami. Jak SF Tensor rozwiązuje ten problem?

Wierzymy, że oba problemy muszą być rozwiązane, i wiele naszej pracy idzie w kierunku rozwiązania efektywności szkolenia, ale najbardziej palącym problemem, który możemy rozwiązać teraz bez opierania się na przyszłych innowacjach, jest podatek infrastrukturalny, ponieważ jest to problem, który już rozwiązaliśmy dla siebie.

Stwierdziłeś, że osiągnąłeś do 80% redukcji kosztów szkolenia. Jakie konkretnie optymalizacje lub przełomy architektoniczne umożliwiają to?

Nasz cały stos oprogramowania opiera się na idei, że kompilator oparty na wyszukiwaniu zawsze wygra z regułami stworzonymi przez człowieka. Do tej pory największym ograniczeniem tych kompilatorów było to, że nie jest możliwe przetestowanie i ocena miliardów lub nawet milionów jąder. Było więc konieczne, abyśmy stworzyli model matematyczny obliczeń, który może dokładnie oszacować czas, jaki dany obliczenie lub zestaw obliczeń zajmie na danym sprzęcie. Dzięki temu możemy rozszerzyć naszą przestrzeń wyszukiwania, a następnie ją przyciąć, co jest konieczne, jeśli chcemy znaleźć najszybsze jądra w sposób ciągły.

Jak Twoje doświadczenie w budowaniu języka programowania Emma wpływa na architekturę i filozofię SF Tensor w kierunku wydajności i abstrakcji?

Nie mów miłośnikom inwestycyjnym, ale w sercu jestem nadal inżynierem kompilatora. Zawsze byłem zainteresowany znalezieniem różnych sposobów, aby uczynić rzeczy nawet tylko nieznacznie szybszymi. Podczas rozwijania Emmy wyrzuciliśmy cały kompilator 4 lub 5 razy; zaczynaliśmy od zera, każdy raz, ponieważ wpadliśmy w optymalizację, którą nie mogliśmy zaimplementować ze względu na bieżące ograniczenia, co zmusiło nas do przebudowy systemu, aby był jeszcze bardziej ogólny, jednocześnie pozwalając nam na osiągnięcie najniższego poziomu optymalizacji, gdy jest to konieczne, często idąc przeciwko powszechnym zasadom projektowania kompilatora i języka. Te nauki i wynikowa architektura połączyły się z niemal dwoma latami tego, co wyglądało na mniejsze optymalizacje i złe zakłady, które skumulowały się w system, który pozwala nam teraz iterować szybciej i optymalizować lepiej niż jakikolwiek system, który podążał za powszechnymi zasadami, ponieważ te zasady są podstawowo zaprojektowane dla procesorów, a nie dla układów GPU i modeli sztucznej inteligencji.

Pracowałeś nad dużymi zestawami szkoleniowymi na ponad 4000 GPU — jakie były największe nauki wyniesione z zarządzania obliczeniami w takiej skali? 

Jednym z największych jest to, że awaria sprzętu jest znacznie bardziej powszechna i problematyczna, niż można by przypuszczać. Po spędzeniu dużo czasu na pracy z tradycyjnymi programami i kompilatorami, ogólnie rzecz biorąc, komputer robi dokładnie to, co mu powiedziano, i jeśli coś pójdzie nie tak, jest to prawie zawsze wina osoby, która napisała kod. Z drugiej strony, awaria sprzętu jest powszechnym zjawiskiem, szczególnie w rozproszonych zestawach szkoleniowych na bardzo dużych klastrach. Idzie to w parze z faktem, że w przeciwieństwie do procesorów, które generalnie działają w sposób deterministyczny i przewidywalny, układy GPU czasem niewytłumaczalnie robią rzeczy, takie jak obniżanie częstotliwości zegara bez widocznego powodu, spowalniając cały proces szkolenia, ponieważ jeden chip działa wolniej.

Y Combinator wspierał niektóre z najbardziej przełomowych firm infrastrukturalnych w technologiach. Jak ten doświadczenie ukształtował Twoje podejście do skalowania produktu i wizji SF Tensor? 

Wchodząc do Y Combinator myślałem, że zakład, który chcieliśmy wtedy złożyć, był ambitny. Po kilku tygodniach nasze pojęcie ambicji uległo drastycznej zmianie, i podwoiliśmy nasz zakład, stawiając na jeszcze większy zakład. Poza tym, poczucie społeczności i wiedzy, które mogę uzyskać, dzwoniąc lub wysyłając e-mail do prawie każdej firmy lub osoby, i otrzymując odpowiedź i radę w ciągu kilku godzin do kilku dni, zmieniło to, jak myślimy o rozwiązywaniu problemów i przyjmowaniu znacznie bardziej współpracującego podejścia.

Spójrzając w przyszłość, wyraziłeś zainteresowanie modelami nie-LLM, robotyką i danymi syntetycznymi. Jak te obszary wpisują się w Twoją długoterminową wizję dla firmy? 

Modele LLM są absolutnie interesującą technologią i będą miały integralną część w tym, jak świat będzie wyglądał w przyszłości, ale powodem, dla którego są one tak znacznie bardziej zaawansowane niż jakikolwiek inny obszar sztucznej inteligencji, wynika głównie z faktu, że jest wiele pieniędzy inwestowanych w ich rozwój, i jest wystarczająco dużo ludzi współpracujących nad tym problemem, aby go zoptymalizować. Zakładając, że możemy obniżyć barierę wejścia, pozwalając badaczom na całym świecie, nawet tym z ograniczonymi zasobami i małą wiedzą na temat optymalizacji, prowadzić badania tak tanio i efektywnie, jak to możliwe. W takim przypadku uważam, że zobaczymy nowe pokolenie modeli, które będą rozwiązywać problemy, dla których modele LLM nie są odpowiednie, albo dlatego, że oddziałują z światem fizycznym, albo dlatego, że są to problemy, które nie mogą być właściwie wyrażone w języku.

Co myślisz, jaki będzie wyglądał stos infrastruktury sztucznej inteligencji za pięć lat — i gdzie widzisz rolę SF Tensor w tym?

Za pięć lat mam nadzieję, że wiele firm rozwinie i wyda własne specjalistyczne układy, i że badacze będą mogli wykorzystywać i wykorzystywać je bez konieczności pisania kodu specjalnie dla nich, idealnie bez nawet wiedzy o ich istnieniu. To jest przyszłość, do której dążymy i w której, jak wierzę, będziemy miały znaczącą rolę w kształtowaniu.

Dziękuję za wspaniały wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić SF Tensor.