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 efektywnym szkoleniem modeli. Jego doświadczenie obejmuje rozwijanie niskopoziomowej infrastruktury AI, poprawę wydajności szkolenia i projektowanie narzędzi, które umożliwiają zaawansowane rozwijanie modeli bez ciężaru inżynierii. Koncentruje się na budowaniu systemów, które pushują granice szybkości, przenośności i niezawodności w heterogenicznych środowiskach sprzętowych.

SF Tensor to firma, którą prowadzi, aby wprowadzić tę filozofię w praktykę. Wprowadza jednolity model programowania, optymalizator jądra i warstwę orchestracji międzychmur, zaprojektowaną w celu usunięcia złożoności rozproszonych obciążeń AI. 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ń AI dramatycznie szybszymi, łatwiejszymi w zarządzaniu i wolnymi od blokady dostawców.

Założyłeś SF Tensor w wieku zaledwie 19 lat, po tym, jak już kierowałeś inżynierią w kilku startupach. Co skłoniło Cię do podjęcia wyzwania reinwencji infrastruktury AI 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 sam się zetknąłem. Kiedy rozwijaliśmy to, co jest teraz rdzeniem SF Tensor, nie pracowaliśmy nad projektem komercyjnym, ale nad przedsięwzięciem 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 powszechnie bardziej zainteresowani naszą technologią infrastruktury, a nie naszym projektem badawczym.

SF Tensor zajmuje się jednym z najtrudniejszych problemów w AI — przełamaniem dominacji NVIDIA CUDA. Jak podejścia do projektowania systemu, który mógłby osiągnąć prawdziwą portowalność sprzętu bez kompromisów w wydajności?

Ostatecznie cała AI sprowadza się do prostych matematyki. Każdy model jest podstawowo zestawem operacji matematycznych, których wyniki musimy obliczyć. Traktując to przede wszystkim 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 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ą to, co robimy dzisiaj.

Blog firmy podkreśla innowacje wokół optymalizacji kompilatora i orchestracji międzychmur. Czy możesz wyjaśnić, w jaki sposób podejście SF Tensor różni się od istniejących frameworków takich jak PyTorch lub JAX?

Nie napisaliśmy jeszcze technicznego bloga o tym, ale tak naprawdę wspieramy frameworki takie jak PyTorch i JAX, pozwalając kodowi napisanemu w nich być optymalizowanym przez nasz stos. Istnieją pewne decyzje architektoniczne, które JAX i PyTorch podjęły, które różnią się od naszego stosu, ale najbardziej znacząca z nich jest taka, że traktujemy cały model jako pojedyncze obliczenie do rozwiązania, zamiast poszczególnych modułów, które muszą być optymalizowane indywidualnie, a następnie wspólnie. W tym zakresie, zamiast stosowania tradycyjnych technik optymalizacji kompilatora i prób stosowania każdej indywidualnej optymalizacji, tworzymy przestrzeń wyszukiwania milionów, a czasem miliardów potencjalnych jąder i twierdzimy, że żaden człowiek nie możepossibly przyjść z zestawem 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 podkreślałeś „podatek infrastrukturalny” — czas, jaki badacze tracą na zarządzaniu obliczeniami zamiast innowacji. Jak SF Tensor rozwiązuje ten dysbalans?

Wierzymy, że oba problemy muszą być rozwiązane, a 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.

Wspomniałeś o uzyskaniu nawet 80% redukcji kosztów szkolenia. Jakie konkretnie optymalizacje lub przełomy architektoniczne umożliwiają to?

Cały nasz 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 milionów lub nawet miliardów jąder. Było więc konieczne, abyśmy stworzyli model matematyczny obliczeń, który może dokładnie oszacować czas, jaki dana operacja lub zestaw operacji 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łynęło na architekturę i filozofię SF Tensor w kierunku wydajności i abstrakcji?

Nie mówcie moim inwestorom, ale w sercu jestem nadal inżynierem kompilatora. Zawsze interesowałem się 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ż natrafiliśmy na optymalizację, której nie mogliśmy zaimplementować ze względu na bieżące ograniczenia, zmuszając nas do przerobienia systemu, aby był jeszcze bardziej ogólny, pozwalając nam na osiągnięcie najniższego poziomu optymalizacji, gdy jest to konieczne, często idąc wbrew 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 drobne 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 z systemów, które podążały za powszechnymi zasadami, ponieważ te zasady są fundamentalnie zaprojektowane dla CPU, a nie GPU i modeli AI.

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

Jednym z największych jest to, że awarie sprzętu są znacznie częstsze i bardziej problematyczne, niż się wydaje. Poświęciwszy dużo czasu na pracę 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, awarie sprzętu są powszechnym zjawiskiem, zwłaszcza w rozproszonych przebiegach szkoleniowych na bardzo dużych klastrach. Idąc w parze z tym jest fakt, że w przeciwieństwie do CPU, które zwykle działają w sposób deterministyczny i przewidywalny, 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 doświadczenie z nimi ukształtowało 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 postawić wtedy, był ambitny. Po kilku tygodniach nasza definicja ambitnych zmieniła się dramatycznie, i podwoiliśmy stawkę na jeszcze większy zakład. Dla innego, poczucie społeczności i uczenia się, które mogę podnieść telefon lub wysłać e-mail do prawie każdej firmy lub osoby i otrzymać odpowiedź i radę w ciągu kilku godzin do dni, zmieniło sposób, w jaki myślimy o rozwiązywaniu problemów i przyjmowaniu znacznie bardziej współpracowego podejścia.

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

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 AI, wynika głównie z faktu, że jest wiele pieniędzy inwestowanych w ich rozwój, i jest wystarczająco wielu ludzi współpracujących nad tym problemem, aby został on wystarczająco zoptymalizowany. Zakładając, że możemy obniżyć barierę wejścia, pozwalając badaczom na całym świecie, nawet tym z ograniczonymi zasobami i niewielką wiedzą na temat optymalizacji, prowadzić swoje badania tak tanio i efektywnie, jak to możliwe. W takim przypadku myślę, że zobaczymy nowe pokolenie modeli, które będą rozwiązywać problemy, dla których LLM nie są odpowiednie, czy to dlatego, że oddziałują one z fizycznym światem, czy 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 AI za pięć lat — i gdzie widzisz rolę SF Tensor w nim?

Za pięć lat mam nadzieję, że wiele więcej firm rozwinie i wyda swoje specjalistyczne chipy, i że badacze będą mogli wykorzystywać je bez konieczności pisania kodu specyficznego dla nich, idealnie bez nawet wiedzy o ich istnieniu. To jest przyszłość, którą budujemy i w której będziemy miały znaczącą rolę.

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