Ben Koska, Gründer und CEO von SF Tensor – Interviewreihe

Ben Koska, Gründer und CEO von SF Tensor, ist ein AI-Forscher und Systemingenieur, der für seine Arbeit an Hochleistungsrechnern, Kernel-Optimierung und effizienter Modellausbildung bekannt ist. Sein Hintergrund umfasst die Entwicklung von Low-Level-AI-Infrastrukturen, die Verbesserung der Trainingsdurchlaufzeit und die Konzeption von Tools, die fortschrittliche Modellentwicklung ohne schwerwiegende Ingenieurüberhead ermöglichen. Er konzentriert sich auf den Bau von Systemen, die die Grenzen von Geschwindigkeit, Portabilität und Zuverlässigkeit über heterogene Hardware hinauspushen.

SF Tensor ist das Unternehmen, das er leitet, um diese Philosophie in eine praktische Plattform umzusetzen. Es introduceiert ein einheitliches Programmiermodell, einen Kernel-Optimierer und eine Cross-Cloud-Orchestrierungsschicht, die darauf ausgelegt ist, die Komplexität von verteilten AI-Workloads zu entfernen. Die Plattform zielt darauf ab, Ingenieuren eine saubere, hardwareunabhängige Umgebung zu bieten, in der sie einmal schreiben, überall bereitstellen und automatisch hohe Leistung erzielen können. Die Mission von SF Tensor ist es, AI-Rechnen dramatisch schneller, einfacher zu verwalten und frei von Anbieterbindung zu machen.

Sie haben SF Tensor im Alter von 19 Jahren gegründet, nachdem Sie bereits bei mehreren Startups die Ingenieurarbeit geleitet hatten. Was hat Sie dazu inspiriert, die Herausforderung der Neuerfindung von AI-Infrastruktur so früh in Ihrer Karriere anzunehmen?

Das Problem, das wir lösen, ist eines, das ich sehr stark betreibe, weil es eines ist, das ich selbst erlebt habe. Als wir das entwickelten, was jetzt der Kernstack von SF Tensor ist, arbeiteten wir nicht an einem kommerziellen Projekt, sondern an einem akademischen Vorhaben. Wir hatten ein Stipendium erhalten, um einige wirklich interessante Forschung durchzuführen, aber wir verbrachten den größten Teil unserer Zeit damit, Infrastruktur und Optimierungen zu kämpfen, anstatt Forschung zu betreiben. Wir fanden heraus, dass die Menschen universell mehr an unserer Infrastrukturtechnologie interessiert waren als an unserem Forschungsprojekt.

SF Tensor geht eines der schwierigsten Probleme im Bereich KI an – die Befreiung von der Dominanz von NVIDIAs CUDA. Wie haben Sie den Ansatz für die Konzeption eines Systems gewählt, das wahre Hardware-Portabilität ohne Leistungsverlust erreichen kann

Letztendlich läuft alles in der KI auf einfache Mathematik hinaus. Jedes Modell ist im Wesentlichen eine Reihe mathematischer Operationen, die wir berechnen müssen. Indem wir es hauptsächlich als mathematisches Problem und nicht als Computer-Science-Problem behandeln, können wir die kleinstmögliche Menge an Einschränkungen für die Berechnungen identifizieren und dann Millionen bis Milliarden verschiedene Möglichkeiten finden, diese Berechnungen in Maschinencode umzuwandeln, um die schnellste zu finden. Das ist leichter gesagt als getan, da wir nicht tatsächlich Milliarden von verschiedenen Programmen ausführen können, um die schnellste zu finden, also mussten wir, um unseren Suchraum zu beschneiden, ein genaues mathematisches Modell entwickeln, um die Geschwindigkeit eines gegebenen Programms für eine gegebene Hardware zu schätzen, was eine der Kerninnovationen ist, die es uns heute ermöglichen, was wir tun.

Das Blog des Unternehmens hebt Innovationen im Bereich Compiler-Optimierung und Cross-Cloud-Orchestrierung hervor. Können Sie erklären, wie der Ansatz von SF Tensor sich von bestehenden Frameworks wie PyTorch oder JAX unterscheidet?

Wir haben noch keinen technischen Blog darüber geschrieben, aber wir unterstützen tatsächlich Frameworks wie PyTorch und JAX, sodass Code, der in ihnen geschrieben wird, durch unseren Stack optimiert werden kann. Es gibt mehrere architektonische Entscheidungen, die JAX und PyTorch getroffen haben, die sie von unserem Stack unterscheiden, aber die bedeutendste ist, dass wir das gesamte Modell als eine einzelne Berechnung behandeln, die gelöst werden muss, anstatt einzelne Module, die individuell und dann gemeinsam optimiert werden müssen. In diesem Sinne wenden wir anstelle traditioneller Compiler-Optimierungstechniken und dem Versuch, jede einzelne Optimierung anzuwenden, einen Suchraum von Millionen bis hin und wieder Milliarden potenzieller Kerne und behaupten, dass kein Mensch in der Lage ist, eine Menge von Regeln zu erstellen, um jeden gegebenen Code in den schnellsten umzuwandeln, also müssen wir einfach jeden möglichen Kombination erstellen und dann die schnellste identifizieren.

Viele Startups konzentrieren sich auf TrainingsEffizienz, aber Sie haben den “Infrastrukturzoll” – die Zeit, die Forscher mit der Verwaltung von Rechenleistung verbringen, anstatt zu innovieren – betont. Wie geht SF Tensor auf diese Ungleichgewicht?

Wir glauben, dass beide Probleme angegangen werden müssen, und ein Großteil unserer Arbeit konzentriert sich auf die Lösung der TrainingsEffizienz, aber das akuteste Problem, das wir derzeit ohne auf zukünftige Innovationen angewiesen zu sein lösen können, ist der Infrastrukturzoll, da es ein Problem ist, das wir bereits für uns selbst gelöst haben.

Sie haben erwähnt, bis zu 80% Reduzierung der Trainingskosten zu erreichen. Welche spezifischen Optimierungen oder architektonischen Durchbrüche machen das möglich?

Unser gesamter Software-Stack basiert auf der Idee, dass ein Such-basierter Compiler immer menschlich erstellte Regeln schlagen wird. Bisher war die größte Einschränkung für diese Compiler die Tatsache, dass es nicht möglich ist, Millionen oder sogar Milliarden von Kernen zu benchmarken und zu bewerten. Es war daher notwendig für uns, ein mathematisches Modell von Rechenleistung zu erstellen, das in der Lage ist, die Zeit, die eine gegebene Berechnung oder eine Reihe von Berechnungen auf einer gegebenen Hardware benötigt, genau zu schätzen. Indem wir dies tun, können wir unseren Suchraum erweitern und dann beschneiden, was eine Notwendigkeit ist, wenn man die schnellsten Kerne konsistent finden möchte.

Wie beeinflusst Ihr Hintergrund bei der Entwicklung der Emma-Programmiersprache die Architektur und Philosophie von SF Tensor in Bezug auf Leistung und Abstraktion?

Lassen Sie es Ihre Investoren nicht wissen, aber im Herzen bin ich immer noch ein Compiler-Ingenieur. Ich habe immer daran interessiert, verschiedene Wege zu finden, um Dinge noch just incrementell schneller zu machen. Bei der Entwicklung von Emma haben wir den gesamten Compiler 4 oder 5 Mal neu aufgebaut; wir haben von vorne begonnen, jedes Mal, weil wir auf eine Optimierung stießen, die wir nicht umsetzen konnten, gegeben die aktuellen Einschränkungen, was uns zwang, das System neu zu konzipieren, um noch allgemeiner zu sein, während wir gleichzeitig in der Lage blieben, auf das niedrigste Level der Optimierung herabzusetzen, wenn notwendig, oft gegen gemeinsame Prinzipien von Compiler- und Sprachdesign. Diese Erkenntnisse und die resultierende Architektur, kombiniert mit fast zwei Jahren dessen, was für viele wie kleine Optimierungen und falsche Wetten aussah, haben sich zu einem System summiert, das es uns jetzt ermöglicht, schneller zu iterieren und besser zu optimieren als die Systeme, die gemeinsame Prinzipien befolgten, weil diese Prinzipien grundlegend für CPUs und nicht für GPUs und KI-Modelle konzipiert sind.

Sie haben an großen Trainingsläufen über 4.000+ GPUs gearbeitet – was waren einige der größten Lektionen, die Sie aus der Verwaltung von Rechenleistung in diesem Maßstab gelernt haben? 

Eine große Lektion ist, dass Hardwareausfälle viel häufiger und problematischer sind, als man annimmt. Nachdem ich viel Zeit mit traditionellen Programmen und Compilern verbracht habe, handelt ein Computer normalerweise genau so, wie er angewiesen wird, und wenn etwas schiefgeht, ist es fast immer die Schuld der Person, die den Code geschrieben hat. Bei GPUs hingegen ist Hardwareausfall ein häufiges Ereignis, besonders bei verteilten Trainingsläufen auf extrem großen Clustern. Hand in Hand damit geht die Tatsache, dass GPUs, im Gegensatz zu CPUs, die normalerweise deterministisch und vorhersehbar handeln, manchmal unerklärlicherweise Dinge tun, wie die Taktfrequenz zu senken, ohne offensichtlichen Grund, was den gesamten Trainingsprozess verlangsamt, weil ein einzelner Chip langsamer läuft.

Y Combinator hat einige der transformativsten Infrastruktur-Unternehmen in der Technologiebranche unterstützt. Wie hat diese Erfahrung Ihren Ansatz für die Skalierung von SF Tensors Produkt und Vision geprägt? 

Als ich zu Y Combinator kam, dachte ich, dass die Wette, die wir damals machen wollten, ambitioniert war. Nach nur wenigen Wochen hatte sich unsere Definition von ambitioniert jedoch dramatisch geändert, und wir setzten auf eine noch größere Wette. Zum anderen hat das Gefühl von Gemeinschaft und Lernen, dass ich einfach ein Telefon anheben oder eine E-Mail senden kann, um fast jedes Unternehmen oder jede Person zu kontaktieren und innerhalb von Stunden oder Tagen eine Antwort und einen Rat zu erhalten, unsere Art und Weise, Probleme anzugehen und eine viel kooperativere Herangehensweise zu verfolgen, verändert.

Im Blick auf die Zukunft haben Sie Interesse an nicht-LLM-Modellen, Robotik und synthetischen Daten geäußert. Wie passen diese Bereiche in Ihre langfristige Vision für das Unternehmen? 

LLMs sind absolut eine interessante Technologie und werden einen integralen Teil davon bilden, wie die Welt in der Zukunft aussehen wird, aber der Grund, warum sie so viel weiter entwickelt sind als jedes andere Gebiet der KI, liegt hauptsächlich daran, dass viel Geld in ihre Entwicklung investiert wird, und es genug Menschen gibt, die an diesem Problem zusammenarbeiten, sodass sie ziemlich optimiert wurden. Angenommen, wir können die Einstiegshürde senken und Forschern auf der ganzen Welt, auch denen mit begrenzten Ressourcen und wenig bis keinem Wissen über Optimierungen, ermöglichen, ihre Forschung so billig und effizient wie möglich durchzuführen. In diesem Fall denke ich, dass wir eine ganze neue Generation von Modellen sehen werden, die Probleme angehen, für die LLMs nicht geeignet sind, entweder weil sie mit der physischen Welt interagieren oder weil sie Probleme sind, die nicht angemessen in Sprache ausgedrückt werden können.

Was denken Sie, wie die AI-Infrastruktur-Stack in fünf Jahren aussehen wird – und wo sehen Sie die Rolle von SF Tensor innerhalb davon?

In fünf Jahren hoffe ich, dass viele mehr Unternehmen ihre eigenen spezialisierten Chips entwickelt und veröffentlicht haben werden, und dass Forscher in der Lage sein werden, diese ohne Code zu schreiben, der speziell für sie entwickelt wurde, zu nutzen, idealerweise ohne sogar zu wissen, dass sie existieren. Das ist die Zukunft, an die wir arbeiten und die ich glaube, dass wir eine signifikante Rolle bei ihrer Gestaltung spielen werden.

Vielen Dank für das großartige Interview, Leser, die mehr erfahren möchten, sollten SF Tensor besuchen.