Бен Коска, основатель и генеральный директор SF Tensor – Серия интервью

Бен Коска, основатель и генеральный директор SF Tensor, является исследователем в области ИИ и системным инженером, известным своей работой над высокопроизводительными вычислениями, оптимизацией ядра и эффективной тренировкой моделей. Его опыт включает в себя разработку низкоуровневой инфраструктуры ИИ, улучшение пропускной способности тренировки и проектирование инструментов, которые делают разработку продвинутых моделей доступной без тяжелой инженерной нагрузки. Он фокусируется на создании систем, которые расширяют пределы скорости, портативности и надежности на разнообразном оборудовании.

SF Tensor – это компания, которую он возглавляет, чтобы превратить эту философию в практическую платформу. Она вводит унифицированную модель программирования, оптимизатор ядра и слой оркестровки, предназначенный для удаления сложности распределенных рабочих нагрузок ИИ. Платформа направлена на предоставление инженерам чистой, независимой от оборудования среды, где они могут писать код один раз, развертывать его где угодно и автоматически достигать высоких результатов. Миссия SF Tensor – сделать вычисления ИИ значительно быстрее, проще в управлении и свободными от привязки к поставщикам.

Вы основали SF Tensor в возрасте 19 лет, после того как уже возглавляли инженерию в нескольких стартапах. Что вдохновило вас на решение проблемы переосмысления инфраструктуры ИИ так рано в своей карьере?

Проблема, которую мы решаем, – это проблема, которую я глубоко заботлюсь, потому что это проблема, с которой я сам столкнулся. Когда мы разработали то, что сейчас является ядром SF Tensor, мы не работали над коммерческим проектом, это было академическое начинание. Мы получили грант на проведение некоторых интересных исследований, но потратили большую часть времени на борьбу с инфраструктурой и оптимизацией, вместо того, чтобы заниматься исследованиями. Мы обнаружили, что люди были универсально более заинтересованы в нашей технологии инфраструктуры, а не в нашем исследовательском проекте.

SF Tensor решает одну из самых сложных проблем в ИИ – освобождение от доминирования NVIDIA CUDA. Как вы подходили к проектированию системы, которая могла бы достичь真正й портативности оборудования без компромисса в производительности?

В конце концов, все ИИ сводится к простой математике. Каждая модель по сути является набором математических операций, которые нам нужно вычислить. Относясь к этому в первую очередь как к математической проблеме, а не как к проблеме информатики, мы можем определить минимальный набор ограничений на расчеты, а затем сгенерировать миллионы до миллиардов разных способов превратить эти расчеты в машинный код, найдя самый быстрый. Это легче сказать, чем сделать, поскольку мы не можем фактически запустить миллиарды разных программ, чтобы найти самый быстрый, поэтому, чтобы сузить наш поисковый prostor, нам пришлось разработать точную математическую модель для оценки скорости данной программы для данного оборудования, что является одним из основных инноваций, которые делают возможным то, что мы делаем сегодня.

Блог компании подчеркивает инновации в области оптимизации компилятора и оркестровки в облаке. Можете ли вы объяснить, как подход SF Tensor отличается от существующих фреймворков, таких как PyTorch или JAX?

Мы еще не написали технический блог об этом, но мы фактически поддерживаем фреймворки, такие как PyTorch и JAX, позволяя коду, написанному на них, быть оптимизированным нашим стеком. Есть несколько архитектурных решений, которые JAX и PyTorch приняли, которые отличают их от нашего стека, но наиболее значимым из них является то, что мы относимся ко всей модели как к единому расчету, который необходимо решить, а не к отдельным модулям, которые необходимо индивидуально и совместно оптимизировать. В этой связи мы вместо применения традиционных методов оптимизации компилятора и попыток применения каждого отдельного оптимизации создаем пространство поиска миллионов до иногда миллиардов потенциально ядер и утверждаем, что ни один человек не может придумать набор правил для преобразования любого данного кода в самый быстрый, поэтому мы должны вместо этого просто создать каждую комбинацию, а затем определить самую быструю.

Многие стартапы фокусируются на эффективности тренировки, но вы подчеркнули “инфраструктурный налог” – время, которое исследователи теряют при управлении вычислениями вместо инноваций. Как SF Tensor решает этот дисбаланс?

Мы считаем, что обе проблемы необходимо решать, и много нашей работы посвящено решению проблемы эффективности тренировки, но наиболее острая проблема, которую мы можем решить прямо сейчас, не полагаясь на какие-либо будущие инновации, – это инфраструктурный налог, поскольку это проблема, которую мы уже решили для себя.

Вы упоминали достижение до 80% сокращения затрат на тренировку. Какие конкретные оптимизации или прорывы в архитектуре делают это возможным?

Наш весь программный стек построен на идее о том, что компилятор на основе поиска всегда побьет человеческие правила. До сих пор самым большим ограничением на этих компиляторах было то, что невозможно протестировать и ранжировать миллионы или даже миллионы ядер. Поэтому нам пришлось создать математическую модель вычислений, которая может точно оценить время, которое данная операция или набор операций займет на данном оборудовании. Делая это, мы можем расширить наш поисковый prostor и затем обрезать его, что является необходимостью, если вы хотите найти самый быстрый ядро последовательно.

Как ваш опыт в создании языка программирования Emma влияет на архитектуру и философию SF Tensor в отношении производительности и абстракции?

Не говорите моим инвесторам, но в душе я все еще инженер компилятора. Я всегда был заинтересован в нахождении различных способов сделать вещи даже просто инкрементально быстрее. При разработке Emma мы выбросили весь компилятор 4 или 5 раз; мы начали с нуля каждый раз, потому что мы столкнулись с оптимизацией, которую мы не могли реализовать, учитывая текущие ограничения, заставляя нас переработать систему, чтобы она была еще более общей, при этом позволяя нам опуститься на самый низкий уровень оптимизации, когда это необходимо, часто противореча общим принципам проектирования компилятора и языка. Эти знания и полученная архитектура, объединенные почти два года того, что казалось многим незначительными оптимизациями и неправильными ставками, привели к системе, которая позволяет нам теперь итерировать быстрее и оптимизировать лучше, чем любая из систем, которые следовали общим принципам, поскольку эти принципы по сути предназначены для ЦП, а не для ГП и моделей ИИ.

Вы работали над крупномасштабными тренировочными запусками на 4 000+ ГП – какие были некоторые из самых больших уроков, извлеченных из управления вычислениями в таком масштабе?

Одним из них является то, что отказ оборудования намного более распространен и проблематичен, чем можно было бы предположить. После того, как я провел много времени, работая с традиционными программами и компиляторами, обычно компьютер делает именно то, что ему говорят, и если что-то идет не так, это почти всегда вина человека, который написал код. С ГП, с другой стороны, отказ оборудования является обычным явлением, особенно в распределенных тренировочных запусках на очень больших кластерах. В связке с этим идет тот факт, что, в отличие от ЦП, которые обычно ведут себя довольно определенно и предсказуемо, ГП иногда необъяснимо делают вещи, такие как снижение частоты для какой-то причины, замедляя весь процесс тренировки, потому что один чип работает медленнее.

Y Combinator поддержал некоторые из наиболее трансформирующих инфраструктурных компаний в технологиях. Как этот опыт сформировал ваш подход к масштабированию продукта и видения SF Tensor?

Входя в Y Combinator, я думал, что ставка, которую мы хотели сделать тогда, была амбициозной. После нескольких недель наше определение амбициозности кардинально изменилось, и мы удвоили ставку на еще более большую ставку. Кроме того, чувство сообщества и обучения, которое я могу взять телефон или отправить электронное письмо几乎 любой компании или человеку и получить ответ и совет в течение нескольких часов или дней, изменило то, как мы думаем о решении проблем и принятии значительно более сотруднического подхода.

Глядя вперед, вы выразили интерес к не-LLM-моделям, робототехнике и синтетическим данным. Как эти области входят в ваше долгосрочное видение компании?

LLM – это, безусловно, интересная технология и будут играть важную роль в том, как мир будет выглядеть в будущем, но причина, по которой они так намного более продвинуты, чем любая другая область ИИ, заключается в основном в том, что в их разработку вкладывается много денег, и достаточно людей сотрудничают над этой проблемой, так что они стали довольно оптимизированными. Предположим, мы можем снизить барьер для входа, позволяя исследователям по всей стране и планете, даже тем, у кого ограниченные ресурсы и мало или совсем нет знаний об оптимизациях, проводить свои исследования так дешево и эффективно, как это возможно. В этом случае я думаю, мы увидим целое новое поколение моделей, которые решат проблемы, для которых LLM не подходят, будь то потому, что они взаимодействуют с физическим миром или потому, что они являются проблемами, которые не могут быть правильно выражены в языке.

Что, по вашему мнению, будет выглядеть стек инфраструктуры ИИ через пять лет – и где вы видите роль SF Tensor в нем?

Через пять лет я надеюсь, что многие компании разработают и выпустят свои собственные специализированные чипы, и что исследователи смогут использовать и использовать их без необходимости писать код конкретно для них, идеально без даже знания о их существовании. Это будущее, к которому мы работаем, и которое, я считаю, мы будем играть значительную роль в формировании.

Спасибо за отличный интервью, читателям, которые хотят узнать больше, следует посетить SF Tensor.