Rozhovory
Ben Koska, zakladatel a CEO SF Tensor – rozhovorová série

Ben Koska, zakladatel a CEO SF Tensor, je AI výzkumník a systémový inženýr známý svou prací na high-performance compute, kernel optimalizaci a efektivní modelové trénování. Jeho pozadí zahrnuje vývoj low-level AI infrastruktury, zlepšování tréninkového průtoku a návrh nástrojů, které umožňují pokročilý modelový vývoj bez heavyweight inženýrského přetížení. Zaměřuje se na budování systémů, které tlačí limity rychlosti, portability a spolehlivosti napříč heterogenními hardwarovými zařízeními.
SF Tensor je společnost, kterou vede, aby tuto filozofii proměnil v praktickou platformu. Zavádí jednotný programovací model, kernel optimalizátor a cross-cloud orchestraci navrženými tak, aby odstranily složitost distribuovaných AI úloh. Platforma má za cíl poskytnout inženýrům čistý, hardwarově nezávislý prostředí, ve kterém mohou psát jednou, nasazovat kdekoliv a automaticky dosahovat vysoké výkonnosti. Misi SF Tensor je učinit AI výpočet dramaticky rychlejším, snadněji spravovatelným a zbaveným závislosti na dodavateli.
Vy jste založili SF Tensor ve věku 19 let, poté co jste již vedl inženýrství ve více startupů. Co vás inspirovalo k tomu, aby jste se ujal výzvy reinventovat AI infrastrukturu tak brzy ve své kariéře?
Problém, který řešíme, je jeden, o kterém jsem hluboce přesvědčen, protože je to problém, se kterým jsem se sám setkal. Když jsme vyvinuli to, co je nyní jádrem SF Tensor, nepracovali jsme na komerčním projektu, ale na akademickém úkolu. Dostali jsme grant na provedení některých opravdu zajímavých výzkumů, ale většinu našeho času jsme strávili řešením infrastruktury a optimalizací, místo aby jsme se věnovali výzkumu. Zjistili jsme, že lidé byli univerzálně více zajímáni o naši infrastrukturní technologii, než o náš výzkumný projekt.
SF Tensor se zabývá jednou z nejobtížnějších problémů v AI — osvobozením se od dominance NVIDIA CUDA. Jak jste přistupoval k návrhu systému, který by mohl dosáhnout skutečné hardwarové portability bez kompromisů ve výkonu
Na konci dne se všechna AI redukuje na jednoduchou matematiku. Každý model je v podstatě souborem matematických operací, které musíme vypočítat. Tím, že se na to díváme primárně jako na matematický problém, spíše než na počítačový vědecký problém, můžeme identifikovat nejmenší soubor omezení pro výpočty a poté vygenerovat miliony až miliardy různých způsobů, jak tyto výpočty převést na strojový kód, a najít ten nejrychlejší. To je snazší říci než udělat, protože nemůžeme skutečně spustit miliardy různých programů, abychom našli ten nejrychlejší, takže abychom omezili náš vyhledávací prostor, museli jsme vytvořit přesný matematický model pro odhad rychlosti daného programu pro dané hardwarové zařízení, což je jedna z hlavních inovací, které činí to, co děláme, možné dnes.
Blog společnosti zdůrazňuje inovace kolem kompilátorové optimalizace a cross-cloud orchestrace. Můžete vysvětlit, jak se přístup SF Tensor liší od stávajících rámců, jako jsou PyTorch nebo JAX?
Ještě jsme nenapsali technický blog o tom, ale ve skutečnosti podporujeme rámce, jako jsou PyTorch a JAX, a umožňujeme kódu psanému v nich být optimalizovaným naším stackem. Existují několik architektonických rozhodnutí, která JAX a PyTorch učinily, které je odlišují od našeho stacku, ale nejvýznamnější z nich je, že pohlížíme na celý model jako na jeden výpočet, který musí být vyřešen, místo jednotlivých modulů, které musí být individuálně a poté společně optimalizovány. Do této míry místo tradičních kompilátorových optimalizačních technik a pokusu o aplikaci jednotlivých optimalizací, vytváříme vyhledávací prostor milionů až někdy miliard potenciálních jader a tvrdíme, že žádný člověk nemůže possibly přijít s sadou pravidel, která by transformovala jakýkoli kód do nejrychlejšího, takže musíme jednoduše vytvořit každou kombinaci a poté identifikovat tu nejrychlejší.
Mnohé startupy se soustředí na tréninkovou efektivitu, ale jste zdůraznili „infrastrukturní daň“ — čas, který výzkumníci ztrácejí při správě výpočtu místo inovace. Jak SF Tensor řeší tuto nerovnováhu?
Věříme, že obě problémy musí být řešeny, a hodně naší práce se soustředí na řešení tréninkové efektivity, ale nejnaléhavějším problémem, který můžeme currently řešit bez toho, aby jsme byli podmíněni budoucími inovacemi, je infrastrukturní daň, protože je to problém, který jsme již sami vyřešili.
Vy jste zmínili dosažení až 80% snížení tréninkových nákladů. Jaké konkrétní optimalizace nebo architektonické průlomy činí to možné?
Celý náš software stack je postaven na myšlence, že search-based kompilátor vždy porazí lidsky vytvořená pravidla. Dosud největší omezení pro tyto kompilátory bylo to, že nebylo možné testovat a řadit miliardy nebo dokonce miliony jader. Bylo proto nutné pro nás vytvořit matematický model výpočtu, který je schopen přesně odhadnout čas, který bude daný výpočet nebo soubor výpočtů trvat na daném hardwarovém zařízení. Tímto způsobem jsme schopni expandovat náš vyhledávací prostor a poté jej ořezat, což je nezbytné, pokud chcete najít nejrychlejší jádra konzistentně.
Jak vaše pozadí ve výstavbě programovacího jazyka Emma ovlivňuje architekturu a filozofii SF Tensor směrem k výkonu a abstrakci?
Neříkejte mému investorovi, ale v srdci jsem stále kompilátorový inženýr. Vždy jsem byl fascinován hledáním různých způsobů, jak věci učinit ještě o málo rychlejší. Při vývoji Emma jsme vyhodili celý kompilátor 4 nebo 5krát; začali jsme od začátku, každý krát, protože jsme narazili na optimalizaci, kterou jsme nemohli implementovat vzhledem k současným omezením, což nás donutilo přestavět systém, aby byl ještě obecnější, zatímco stále umožňoval nám spadnout na nejnižší úroveň optimalizace, když bylo necessário, často proti běžným principům kompilátorového a jazykového designu. Tyto znalosti a výsledná architektura kombinované téměř dva roky toho, co vypadalo pro mnohé jako minoritní optimalizace a špatné sázky, se sčítají do systému, který nám nyní umožňuje iterovat rychleji a optimalizovat lépe než kterékoli ze systémů, které následovaly běžné principy, protože tyto principy jsou fundamentálně navrženy pro CPU, ne pro GPU a AI modely.
Vy jste pracovali na velkých škálách tréninkových běhů napříč 4 000+ GPU — co byly některé z největších lekcí, které jste se naučili při správě výpočtu v takové škále?
Jedním z velkých lekcí je, že hardwarová chyba je mnohem častější a problémovější, než by se mohlo zdát. Když jsem strávil hodně času prací s tradičními programy a kompilátory, obecně platí, že počítač dělá přesně to, co je mu řečeno, a pokud něco jde wrong, je to téměř vždy chyba člověka, který napsal kód. S GPU, na druhé straně, je hardwarová chyba častým jevem, zejména v distribuovaných tréninkových bězích na extrémně velkých clusterech. To jde ruku v ruce s tím, že na rozdíl od CPU, které obecně jednají poměrně deterministickým a předvídatelným způsobem, GPU někdy nečekaně dělají věci, jako je snižování taktovacích frekvencí bez zjevného důvodu, zpomalování celého tréninkového procesu, protože jeden čip běží pomaleji.
Y Combinator podpořil některé z nejtransformativnějších infrastrukturních společností v tech. Jak zkušenost s touto společností ovlivnila váš přístup ke škálování produktu a vize SF Tensor?
Když jsem vstoupil do Y Combinator, myslel jsem, že sázka, kterou jsme chtěli učinit, byla ambiciózní. Po několika týdnech se naše definice ambice dramaticky změnila, a my jsme se rozhodli vsadit na ještě větší sázku. Kromě toho pocit komunity a učení, který jsem mohl získat tím, že jsem mohl zavolat nebo poslat e-mail téměř jakékoli společnosti nebo osobě a získat odpověď a radu do několika hodin až dnů, změnil způsob, jakým přemýšlíme o řešení problému a přijetí mnohem více spolupracujícího přístupu.
Pohledem do budoucnosti, jste vyjádřil zájem o non-LLM modely, robotiku a syntetická data. Jak tyto oblasti zapadají do vaší dlouhodobé vize pro společnost?
LLM jsou absolutně zajímavou technologií a budou hrát integrovanou roli v tom, jak bude svět vypadat v budoucnosti, ale důvod, proč jsou tak pokročilé, je hlavně to, že do nich je investováno hodně peněz a existuje dostatek lidí, kteří na tomto problému spolupracují, takže se staly bastante optimalizovanými. Pokud můžeme snížit bariéru vstupu, umožnit výzkumníkům po celém světě a planetě, i těm s omezenými zdroji a málo znalostmi o optimalizacích, provádět svůj výzkum co nejlevněji a nejefektivněji, myslím, že uvidíme novou generaci modelů, které budou řešit problémy, které LLM nejsou vhodné, ať už proto, že interagují s fyzickým světem, nebo proto, že jsou to problémy, které nelze správně vyjádřit v jazyce.
Co si myslíte, jak bude vypadat AI infrastrukturní stack za pět let — a kde vidíte roli SF Tensor v něm?
Za pět let doufám, že mnoho společností bude mít vyvinuto a vydáno své vlastní specializované čipy, a že výzkumníci budou moci tyto čipy využívat bez nutnosti psát kód specificky pro ně, ideálně bez toho, aby museli vědět, že existují. To je budoucnost, na kterou jsme pracují, a kterou věřím, že budeme hrát významnou roli při jejím tvarování.
Děkuji za skvělý rozhovor, čtenáři, kteří chtějí se dozvědět více, by měli navštívit SF Tensor.












