Как стать автором
Обновить

Как мы разрабатываем отечественный AI-процессор. Часть 1. Почему GPGPU?

Уровень сложностиСредний
Время на прочтение19 мин
Количество просмотров9.1K
Всего голосов 60: ↑57 и ↓3+61
Комментарии39

Комментарии 39

Серьезное исследование! Спасибо.

Скажите, а при разработке собственных GPU есть шанс попасть в существующие программные стеки? Cuda сможет поднятся? А аналоги?

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

Скажите, а инференс LLM на ваших решениях возможен?

Мы только в процессе разработки, поэтому сейчас невозможно ничего. А так, само по себе ядро GPGPU будет обладать схожими свойствами, что и аналоги от Nvidia/AMD. Поэтому в потенциале можно делать хоть инференс, хоть трейнинг LLM. Всё будет зависеть уже от конкретной сборки на SoC , наличию нужных интерфейсов и количеству памяти

И ещё один вопрос.

А вы сами написали rtl для систолического массива?.или взяли из open source? Если это open source, то можно попросить ссылку?

К сожалению, это проприетарный код

Ждём с поддержкой vulkan

Это только вычислитель. Там нет железа для поддержки 3D графики.

Можете объяснить пару моментов:

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

Как вы планируете добавлять поддержку существующих фреймворки машинного обучения? Даже при наличии библиотеки-обертки с реализацией CUDA/Vulkan API нужно еще уметь компилировать ядра фреймворков под вашу архитектуру, а ядра по большей части оптимизированы под работу с NVidia.

  1. Только то, что необходимо для ИИ (по-крайней мере в первой версии)

  2. Ядра по сути представляют из себя код на С++, которые оптимизированы под работу на GPGPU. Конечно, в большинстве случаев этот GPGPU - Nvidia, но на самом деле прям драматической разницы во многих случаях нет. GPGPU от Nvidia , вообще говоря, тоже разные. Где-то, конечно, придётся кернелы оптимизировать.

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

Их нету(практически) в Compute-only GPU из серии H100/H200 и B200/B300. Поэтому на этих картах не возможно нормально делать рендеринг. В H100 - 24 rops, что на уровне дёшевой старой интегрированной карты. https://www.tomshardware.com/news/nvidia-h100-benchmarkedin-games И, вероятно, оставлено исключительно для каких-то целей обратной совместимости.

А есть они в универсальных GPU - L40, RTX Pro 6000, но на то они и универсальные - могут и картинку рендерить, а могут и AI посчитать, но далеко не так быстро, как Compute-only.

Одна из немногих годных статей на Хабре за последние годы. Аплодисменты автору.

Универсальный процессор делать сложно, он универсальный, подойдет и для инференса и для обучения...

Точно на хабре читал о проекте (но он кажется замкнулся сам на себе и не продает решения) когда веса сети запекаются сразу в чипе, это на пару порядков упрощает архитектуру (там даже шла речь о поддержки lora, т.е. оперативная память все же была). Конечно это подходит только для инференса, да и уже через пол года - год, решение станет 'бесполезным' (так как выйдут модели лучше). Как вы считаете, жизнеспособная идея?

Считаю, что нет

Учитывая скорость прогресса в нейросетях, и разницу в нейросетях для разных применений? Едва ли.

Если ты начинаешь разработку чипа сегодня, то на рынок ты его выбросишь хорошо если через год. За это время он устареет. К моменту появления первых реальных устройств с этим чипом - он устареет вхламину. Конкретная нейросеть уже будет далеко не SOTA, да и применения ИИ легко могут "уйти вбок" от того, что ты в чип запихнул. Не факт что эта выжженная в железе нейросеть вообще будет полезна.

Видится хоть какое-то будущее у таких вещей мне в одной нише: свёрточные сети для обработки изображений.

Условно: первые слои у свёрточных сетей для обработки изображений всегда очень похожи, и выполняют схожую функцию - вне зависимости от того, в какой сети они стоят. Это устоявшийся элемент архитектуры, и эти слои очень похожи у ResNet, CLIP, и даже у VLM. Поэтому можно прикручивать разные архитектуры обработки изображений к "замороженным", выжженным в железе высокоэффективным первым слоям. Что может быть полезно для вещей вроде чипов камер, которые всегда имеют дело с изображениями.

Но тут опять упираемся в проблемы экзотических архитектур, описанные в статье. Сети надо под такое адаптировать. Кто будет этим заниматься? И раз мы не уходим от нужды в классическом ускорителе, то не проще ли вместо тех выжженных в железе слоёв просто сделать ускоритель на 15% больше?

Время жизни современного смартфона (который на несколько порядков дороже чипа) считанные 3 года, а дешевые - порядка года (закладывают искусственные поломки). Если рассчитывать на количество и низкую цену (например в каждый смартфон вставить чип с phi4 и жрущим меньше энергии, потому что это asic а не тяжелый универсальный процессор). Я бы с удовольствием купил бы уже сейчас условную вундервафлю phi4 в формфакторе usb-флешка/диск за 200$ (а нужно то там несколько типовых гигабайт на kv-cache и по условному чипу на слой) если ее скорость будет хотя бы того же порядка что сейчас на десктопных видекартах работает, и был бы готов раз в год это обновлять (а старую на вторичный рынок, и он у этой железки будет будь здоров)

Если ты запекаешь веса прямо в чипе ro (а это буквально пересечение проводков + диод), их скорость работы будет определяться принципиальными возможностями обвязки и вычислительного блока. Мне кажется работать такой чип должен на порядок быстрее сложных gpu, потому что все рядом, там проблема больше поддержки lora и организации локальной памяти для kv-cache (а нужен ли он в этом случае? ведь веса attention тоже ro)

Есть причина, по которым сейчас в устройства ставятся универсальные перезаписываемые чипы NAND Flash, а не наглухо зашитые на фабрике чипы ROM, как во времена Apple II. Несмотря на то, что чип ROM в разы проще, и в теории его даже можно делать намного плотнее.

И причина эта в том, что гибкость - большое благо.

Вчера тебе надо было Phi 4, сегодня тебе понадобится offline распознавание речи и перевод с русского на финский, завтра ты захочешь свежую VLM от Google, послезавтра выйдет Phi 5, а к концу недели тебе понадобится запускать какую-нибудь мульитмодальную экзотику с поддержкой звука, видео и траекторий движения для роборук одновременно. Программируемый ускоритель это прожуёт. Однозадачный чип с Phi 4 - нет. А выйдут устройства с этим чипом даже не послезавтра, а в 2026 году. И будет чип лежать в устройстве мёртвым грузом.

Если прогресс в ИИ внезапно встанет колом, и окажется, что никакие новые архитектуры не нужны, а прогресс в существующих - на уровне +0.5% производительности в год? Тогда может быть смысл в выжигании нейросетей в кремнии.

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

перезаписываемые данные стоят на порядок дороже, лучший способ это уменьшить, вынести память наружу и унификация, но это за собой тянет замедление (узкая шина данных)

  1. Формально Tenstorrent - это Many Cores CPU, но, собственно, чипы данной компании явно демонстрируют, почему я в статье указал, что их программирование по факту делает их Data Flow процессорами. В общем, это можно назвать своего рода гибридом двух этих подходов.

  2. Как указано в статье, мы делаем GPGPU, т.е. это ближе к Nvidia/AMD.

Правильно ли я понял, что под GPGPU Вы имеете в виду массив из более сложных вычислительных ядер с OoO, предсказателем ветвлений и кэшами нескольких уровней ?

Вы пишите, что массив из простейших конвейерных вычислительных ядер снабженных SIMD будет пробуксовывать и его вычислительная эффективность будет низкой по сравнению с более "толстыми" ядрами. С другой стороны, если в качестве ядер использовать более продвинутые (с OoO и предсказателем), то таких ядер помещается существенно меньше на единицу площади кристалла и электроэнергии они потребляют больше. Проводилось ли какое-то моделирование эффективности выраженной в MFLOPS/мм2 (и MFLOPS/Ватт) этих двух вариантов ? Не может ли оказаться так, что кристалл усеянный большим числом меньших по размеру и более простых ядер покажет существенно более высокую производительность (и меньшее энергопотребление), даже учитывая простои конвейеров, за счет более высоких тактовых частот и существенно большего числа ядер на единице площади ? На сколько OoO ядра больше по площади чем не-OoO ?

Возможен ли вариант изготовления "полновафельной" системы (WSE под тип Esperanto) на существующих производтсвенных мощностях Микрона по 180нм ? Какова могла бы быть теоритическая производительность такого кристалла если в качестве ядер использовать конвейерные RV64I+RVV ? По некоторым прикидкам на пластину d=200мм может поместиться до 200 таких ядер с частотой тактирования 1000МГц. Не A100 конечно, но тоже что-то и своё. :-)

Правильно ли я понял, что под GPGPU Вы имеете в виду массив из более сложных вычислительных ядер с OoO, предсказателем ветвлений и кэшами нескольких уровней?

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

Проводилось ли какое-то моделирование эффективности выраженной в MFLOPS/мм2 (и MFLOPS/Ватт) этих двух вариантов ?

В статье есть таблица сравнения Xeon Phi/ET-SoC-1/Nvidia A100, где видно, что many core cpu уступают по плотности вычислений на единицу площади.

На сколько OoO ядра больше по площади чем не-OoO ?

В разы. Более того, для throughput oriented задач этот ОоО не нужен фактически. Он не даёт особого выигрыша по перфу. Заменой ОоО для throughput oriented задач является то, что называется Warp Scheduler. Опять-таки, в следующей статье я про это чуть подробнее напишу.

Возможен ли вариант изготовления "полновафельной" системы (WSE под тип Esperanto) на существующих производтсвенных мощностях Микрона по 180нм ?

WSE это Cerebras, а не Esperanto. Такой вариант на Микроне невозможен и бессмысленнен.

Какова могла бы быть теоритическая производительность такого кристалла если в качестве ядер использовать конвейерные RV64I+RVV ? По некоторым прикидкам на пластину d=200мм может поместиться до 200 таких ядер с частотой тактирования 1000МГц

Никаких 1000МГц на микроновском техпроцессе невозможны. Производительность такого рода системы будет мизерная, идея сама по себе бессмысленна и не имеет никаких реальных шансов для имплементации

Ок, спасибо за ответ. С нетерпением жду Вашу статью обьясняющую принципы работы GPGPU.

Софт действительно критически важен для любых "нетрадиционных" реализаций. В конторе где я работаю, например, программистов больше чем RTL-инженеров и это вовсе не от любви руководства к программированию.
Но мне не вполне понятен посыл статьи в духе "с GPGPU не будет проблем с софтом". Вы собираетесь CUDA-совместимый ускоритель делать? А если нет, всё равно компилятор нужен, и не факт что он будет сильно проще, чем для других вариантов архитектуры. По крайней мере если мы говорим о высокой эффективности.

Но мне не вполне понятен посыл статьи в духе "с GPGPU не будет проблем с софтом"

Скорее посыл "с GPGPU проблемы с софтом наименьшие, по сравнению с другими вариантами". Но они есть, безусловно.

Вы собираетесь CUDA-совместимый ускоритель делать? А если нет, всё равно компилятор нужен, и не факт что он будет сильно проще, чем для других вариантов архитектуры. По крайней мере если мы говорим о высокой эффективности.

Компилятор вам нужен в любом случае, вне зависимости от Cuda-совместимости. Никто не избавит вас от необходимости пилить собственный стек системного софта, само по себе это не столь большая проблема. Большая проблема начинается тогда, когда вам надо как-то серьёзно менять стек пользовательского софта. Например, у вас есть какая-то сетка, которая реализована с помощью написанных cuda-кернелов. Если вы сделаете тензорный процессор - вам придётся всё переписывать абсолютно. Т.к. модель вычислений другая. Тензорный процессор не может исполнить general purpose код из cuda-кернела. Он может оперировать только операциями над матрицами и векторами. Если же у вас GPGPU, то проблемы нет, код остаётся валидным, просто его надо откомпилировать новым компилятором. Это главная проблема.

Ппц, и на эту пое6оту, идут деньги из наших налогов.

Прикольно, в игре TIS-100 надо программировать систолический массив вычислителей размером 4х3. Я думал это автор игры придумал на основе fpga, а оказывается оно и в реальности есть.

Даже аппаратные реализации таких идей есть, и давно. Привет, Parallax Propeller и P2012 STHORM.

Это одна из очень старых идей альтернативных архитектур для вычислительных машин - которые на практике "не взлетели", и существуют только как крайне нишевые вещи.

Идея делать в России собственный конкурентоспособный ИИ-ускоритель - это, конечно, утопия невыносимая. Но сама статья при этом хорошая.

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

Очень хорошая статья, спасибо. Кое c чем не согласен и пара замечаний:
1) у systolic array по мере увеличения размера не уменьшается частота (и он по площади занимает сильно меньше, чем эквивалентный набор SM'ов с Tensor Cores, хотя последние и гибче в итоге)
2) маленькие тензорные ядра порождают большую внутреннюю полосу (чем меньше ядра, тем меньше data reuse и толще шины/полосы)
3) GPGPU легко программировать в общем случае, это да. Но в Nvidia программисты написали десятки тысяч вручную оптимизированных кернелей: для них это преимущество, а для стартапов - недостаток, нет столько программистов

1) у systolic array по мере увеличения размера не уменьшается частота (и она занимает сильно мешьше, чем эквивалентный набор SM'ов с Tensor Cores, хотя последние и гибче в итоге

Цифры опровергают ваши заявления. Причём и в имплементации Гугла, и в том, что видели мы. Но вы можете поделиться своими данными, если они у вас есть

2) маленькие тензорные ядра порождают большую внутреннюю полосу (чем меньше ядра, тем меньше data reuse и толще шины/полосы)

Это всё в теории, на практике там нет проблем

Но даже если опираться на приведённые самим же Google данные, видно, то у TPU и A100 сравнимые цифры потребления, разрыва на порядок или даже в разы нет. А с учётом проигрыша в производительности, энергоэффективность будет находится примерно на одном уровне.

Ну не нравится вам TPU и не нравится. Но зачем же приукрашивать. Разница в потреблении порядка 2х раз (206 против 400). Разница в производительности ­— 12% (275 против 312). Разница в площади 28% (600 против 826). То есть, если принять что затраты на кремний пропорциональны площади, гугл может поставить 4 чипа, там где нвидия сделает 3 и получит 800 Вт против 1200 и 1100 ТФЛОПС против 936. Естественно, это рассуждение нисколько не умаляет ваши тезисы про заинтересованный источник и трудности с ПО.

Нет, вы немного запутались в цифрах. Если я правильно понял, вы хотите посчитать потребление для Resnet-50 (только там есть 206), тогда это 273/206 = 1,33 . Разница в производительности должна считаться с учётом утилизации. Для Resnet-50 эта разница действительно будет в районе 12% (точнее по графику не понять), а вот для Bert ближе к 2х. Средняя цифра преимущества производительности на LLM у Nvidia будет порядка 31%, как приведено в таблице в статье. Иными словами, энергоэффективность примерно схожая.

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

Нет, вы немного запутались в цифрах.

Действительно запутался. Не в те таблицы посмотрел.

Про размеры кремния могу сказать одно - это не имеет никакого особого значения.

Я конечно не настоящий сварщик, но я так понимаю, что техпроцесс построен, в основном, вокруг пластины. И если на пластину влезает на треть больше чипов, то цена чипа будет, соответственно, на треть меньше.

Всё несколько сложнее. Но если очень грубо, то цена 300 мм пластины на 7 нм порядка $10 000. На пластину влезет примерно 100 чипов TPUv4 и 80 Nvidia A100. Т.е. даже если вы получите 100% выход годных, то себестоимость чипа TPUv4 будет ~$100, A100 ~125$. В реальности, у TPUv4 скорее всего выход годных будет на уровне 50%, а у Nvidia останутся те же 100% (за счёт механизма отключения неработающих SM), т.е. это будет $200 и $125 соответственно. Но по размерам сумм видно, что при цене решений в десятки тысяч долларов, сто баксов себестоимости в любую сторону не играют здесь решающей роли.

то цена чипа будет, соответственно, на треть меньше

Вы наивно полагаете, что цена прямо процорциональна площади кремния?

Intel Core i9-13900KS RCP $689.00-$699.00 Площадь кристалла 257мм²

Intel Core i3-13100F RCP $109.00-$119.00 Площадь кристалла 163мм²

Разница в размере между ними < 60%, а не 700%. Да и выход годных не сильно отличается.

13100F сейчас продают за половину этой цены рознице. И определённо не в убыток.

речь, естественно, про стоимость производства, а не цену в магазине

Отличная статья!

Systolic-подобные акселераторы распространены в application SoC (Rockchip и др), верно?

Не могу говорить за все имплементации, но из того, что я видел, там скорее что-то похожее на массивный SIMD как в CPU или тензорные блоки как в GPGPU. К сожалению, разработчики железа редко балуют нас подробностями реализаций.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий