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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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