«We have a phrase inside Intel. We are supposed to be a data driven company and the phrase is, "Don't argue with the emotions, argue with the data." »

Andrew S. Grove, Chairman of the Board, Intel Corporation, August 9, 1998

В июле 2023-го года в «Байкал Электроникс» стартовал проект по разработке собственного AI-процессора. В данной публикации мы хотим рассказать, почему мы выбрали именно архитектуру GPGPU, какими данными при решении мы руководствовались, а во второй части немного рассказать о ходе разработки и поделиться полученным опытом.

Почему именно GPGPU?

2023-ий год Россия встретила в достаточно странной ситуации, когда с одной стороны, всем была понятна необходимость и перспективность развития аппаратных решений для ИИ, с другой — этих решений, можно сказать, не было. Актуальная на тот момент времени ситуация была описана в данной статье. Более того, из 4-х перечисленных решений,по большому счёту, только одно (IVA TPU) можно считать действительно специализированным индустриальным AI‑процессором. Нейроморфные процессоры (коим является Altai от Мотив НТ) на данный момент являются скорее предметом научных изысканий и не в состоянии конкурировать с промышленными AI‑процессорами на более классических архитектурах. Приведённые же решения от Элвис и Модуль являются просто DSP‑процессорами, прилаженными для задач ИИ. Неудивительно, что они проигрывают специализированным AI‑процессорам на порядки. Ситуация выглядела достаточно удручающе, что и побудило нас стартовать проект по разработке собственного AI‑ядра. Вариантов того, какой архитектурный подход выбрать, было несколько. Вооружившись научным подходом и руководствуясь заветами титанов индустрии микроэлектроники, таких как легендарный Энди Гроув, мы провели анализ существующих подходов к разработке AI‑процессоров. Вот, что у нас получилось в итоге:

Нейроморфные процессоры

Здесь не будем долго останавливаться. Как было написано выше — нейроморфные процессоры пока удел скорее исследовательских лабораторий. И есть подозрение, что в части высокопроизводительных вычислений, долго ещё там и останутся (если не навсегда). Основная концепция нейроморфных процессоров заключается в отказе от традиционного подхода, когда работа нейронных сетей симулируется через обычные арифметические операции (в основном, это fused multiply add различной точности, используемый для перемножения матриц/векторов). Идея состоит в том, чтобы максимально приблизиться к биологической модели мозга, работающего в импульсном режиме. Главная проблема такого подхода на данный момент — практически полная несовместимость со всем стеком моделей и программного обеспечения, разработанного в индустрии ИИ к сегодняшнему дню, что вынуждает разработчиков фактически в ручном режиме портировать современные сетки на новый вычислитель. Выпущено много различных нейроморфных решений, из самых известных — Intel Loihi / Loihi 2, IBM TrueNorth, в России — Altai Мотив НТ. Но на текущий момент на мировом рынке нет ни одного массового, коммерчески успешного нейроморфного процессора. Для компании, нацеленной на разработку индустриальных решений, рассматривать такой вариант серьёзно смысла не имело.

«Data flow» процессоры

Под данным видом AI‑процессоров мы понимаем плеяду появившихся на буме AI решений — Cerebras, SambaNova, Groq — эксплуатирующих идею более интеллектуального управления потоком данных между вычислительными блоками, по сравнению с CPU и GPGPU. Ведь одна из основных проблем современных вычислителей — так называемая Memory Wall. Простыми словами, проблема заключается в постоянно растущем разрыве между скоростью работы вычислительных блоков в процессоре и скоростью доставки к ним данных из памяти. Чтобы минимизировать простои процессора и получить высокую степень утилизации вычислительной мощности, необходимо успевать загружать необходимые для работы данные из памяти. Классический подход, когда данные берутся из памяти, производятся вычисления, после чего результаты складываются обратно, зачастую приводят к большому количеству излишних транзакций. Размеры кэшей, которые призваны уменьшить проблему, зачастую, недостаточны — они составляют десятки мегабайт, когда как для задач ИИ требуются на порядок большие цифры. Поэтому, вполне логичной выглядит идея передавать результаты вычислений напрямую блоку, выполняющему следующий этап вычислений. Тем более, что структура современных алгоритмов ИИ этому благоволит — она описывается графом, где узлами являются операции с высокой (как правило) вычислительной ёмкостью. Например, примерно так выглядит граф достаточно простой сети Resnet50:

Resnet-50
Resnet-50

Поэтому, если адаптировать алгоритм вычисления такой сети под Data Flow процессор, мы можем получить серьёзное ускорение. Давайте на примере процессора от компании Groq посмотрим, как это примерно может выглядеть в железе:

 

Groq
Groq

Видно, что процессор состоит из большого количества регулярных элементов, объединённых в слои в зависимости от своей специализации (перемножение матриц, работа с векторами, трансформация данных). Что в итоге это даёт? Сравнение производительности и остальных характеристик такого рода решений крайне сложный процесс. Хотя бы потому, что просто так купить процессор от Groq или SambaNova не получится. А маркетинговые материалы компаний‑производителей страдают скудностью данных и очевидным желанием приукрасить результаты. Поэтому давайте обратимся к такому замечательному сайту artificialanalysis.ai, на котором приведены замеры, которые можно взять за точку отсчёта. Для начала, посмотрим производительность на модели llama-3.3:

Llama 3.3
Llama 3.3

Что мы видим? Первые 3 места (Groq Spec decoding исключим пока из рассмотрения, ввиду неопределённости наличия данной оптимизации на других платформах и её неоднозначности) занимают представители 3-х DataFlow процессоров — Cerebras, Sambanova и Groq. Все остальные провайдеры ИИ‑решений используют GPGPU карты Nvidia. Особенно впечатляет отрыв Cerebras, опережающего ближайшего GPGPU конкурента более чем на порядок. Казалось бы, вот он, настоящий убийца Nvidia! Хуанг в панике, инвесторы срочно продают акции его компании и вкладывают в Data Flow процессоры (Cerebras, кстати, готовится выйти на IPO в ближайшее время). Но возникает вопрос, почему компании, существующие уже почти декаду (Cerebras основан в 2015-м, Groq в 2016-м, Sambanova в 2017-м) и выпустившие уже не по одному поколению специализированных AI‑чипов, так и не составили серьёзную конкуренцию Nvidia? Чтобы ответить на этот вопрос, давайте посмотрим для начала на ещё один график с вышеупомянутого сайта:

Pricing
Pricing

Это цена, которую платят клиенты за использование ИИ‑ускорителей в облаках провайдеров для сети llama 3.3. Видно, что все Data Flow процессоры расположились в правой части. Другими словами, они проигрывают конкуренцию GPGPU от Nvidia в части цены. И дело тут не в масштабировании производства — AI‑процессоры от Nvidia продаются с огромной маржинальностью и пространство для игры с ценой все участники рынка имеют большое. Главная причина в том, что весь стек ПО для разработки ИИ‑решений в основном разработан под GPGPU, и более того — во многом в рамках экосистемы Cuda от Nvidia. Это значит, что для Data Flow‑процессора необходимо создавать собственный стек, причём во многом сильно отличающийся от уже существующих подходов. Заметьте, на вышеприведённых графиках разработчики Data Flow процессоров и провайдеры ИИ‑услуг — это одни и те же компании. т.е. де‑факто — это не компании, разработчики ИИ‑процессоров, а провайдеры ИИ‑услуг, разработавшие для собственных нужд специализированные ИИ‑процессоры. Потому что иначе продвинуть их на рынок крайне сложно. И стоимость такого подхода для инвесторов крайне недешёвая — инвестиции в каждую из компаний составляют около $1–2 млрд:

Cerebras

SambaNova

Groq

Max node, nm

5

5

4

Founded, year

2015

2017

2016

Funding, bln $

0,78

1,1

2

С учётом, что разработка непосредственно самого чипа составляет порядка $100 млн, остальное — это затраты на разработку ПО, создание дата‑центров и т. д. Всё это бьёт по цене конечных решений.

С технической точки зрения у такого подхода также есть проблемы. Например, чип от Cerebras, обладающий беспрецедентной производительность, имеет размер в пластину и цену в миллионы долларов. Очевидно, что с технической точки зрения именно технология масштабирования процессора на всю пластину является ключевой — а это проприетарная технология, разработанная совместно с TSMC и пока недоступная другим разработчикам процессоров. А цена в миллионы долларов сразу переводит решение из массового рынка в сегмент «luxury».

Решения же от SambaNova и Groq не имеют настолько радикального преимущества по производительности, способной компенсировать проблемы с софтом и проигрыша в гибкости, по сравнению с GPGPU. Они заточены по сути только для inference LLM моделей, не способны делать обучение и будут испытывать проблемы с производительностью за пределами нескольких адаптированных и затюннингованных ИИ‑моделей. К тому же, сейчас они сравниваются с предыдущим поколением GPGPU от Nvidia — H100. Вышедшие недавно B100/200, скорее всего, сравняются по цифрам или даже обгонят текущие решения от Groq и SambaNova.

Резюмируя вышенаписанное — Data Flow процессоры, обладая определёнными локальными преимуществами, по сумме остальных факторов не могут составить конкуренцию GPGPU процессорам на широком рынке. Они требуют больших вложений на проведение исследований для создания архитектуры, разработки большого стека ПО и специализированных компетенций в области ИИ, при этом имеют ограниченное применение и не способны конкурировать на массовом рынке с GPGPU. Примерно к таким же выводам склоняются эксперты из Semianalysis:

“The question that really matters though, is if low latency small model inference is a large enough market on its own, and if it is, is it worth having specialized infrastructure when flexible GPU infrastructure can get close to the same cost and be redeployed for throughput or large model applications fairly easily”

Многоядерные CPU с массивным SIMD

Самым ярким представителем данного класса процессоров является линейка Xeon Phi от компании Intel. Также сходный подход исповедует компания Esperanto в своём чипе ET‑SOC-1 (в разработке которого автору довелось принять участие).

Ключевая идея следующая — если мы решаем массивно‑параллельную задачу (а к таким относятся AI‑нагрузки), то давайте радикально упростим обычное CPU‑ядро — выбросим дорогостоящие механизмы переупорядочивания команд, предсказания переходов и предподкачки данных, поставим максимально большое количество ядер — десятки/сотни (как в Xeon Phi) или даже тысячи (как в Esperanto). А для увеличения вычислительной мощности добавим ещё широкий SIMD. Как говорится, казалось бы, что может пойти не так?

С точки зрения аппаратной архитектуры, тут есть, как минимум, 2 ключевые проблемы:

  • CPU — это, как ни крути, вычислитель, предназначенный на максимальную однопоточную производительность. Это съедает транзисторный бюджет и площадь. Если ядро максимально упрощать, то это приводит к тому, что утилизация конвейера падает. Банально, последовательность 2-х инструкций fma→fma вызовет задержку в несколько тактов, пока результат первой операции выработается. И нужно искать операции, которые можно выполнять в промежутках. Особенно ухудшают ситуацию самое главное зло любого процессорного конвейера — операции доступа в память (вспоминаем тот самый пресловутый Memory Wall). Эту проблему можно отчасти решать техникой SMT (Simultaneous Multithreading), когда одно физическое ядро исполняет несколько логических потоков. Но предел этой оптимизации ограничен и достаточно дорог в ядре CPU. В Xeon Phi максимальной конфигурации было 72 физических ядра и 288 логических потока (4 потока на 1 ядро), в ET‑SOC-1 1088 ядер и 2176 потоков (2 потока на 1 ядро). Для сравнения, современные GPGPU от Nvidia могут исполнять 270 000+ потоков одновременно (или 8000+ варпов, об этом ниже). Резюмируя — урезанный CPU не имеет хороших встроенных аппаратных механизмов исполнения множества параллельных инструкций. Здесь он полностью зависит от того, насколько хорошо компилятор использовал векторный блок. Но софтварная векторизация в общем случае — нерешаемая проблема компиляции. И параллелизм уровня команд (ILP) в одном потоке исполнения CPU (или даже в нескольких, если считать SIMD) заведомо ограничен. Поэтому утилизация векторного блока будет неминуемо страдать.

  • Подсистема кэшей. У CPU она, опять‑таки, заточена на оптимизацию задержек (latency), в то время как для многопоточных задач куда более важной характеристикой является пропускная способность (throughput). К примеру, у классических CPU типичная задержка обращения к кэшу данных 1-го уровня L1D составляет 3–4 такта, тогда как у GPGPU это число находится в диапазоне 20–30 тактов. Но при этом, кэши GPGPU способны обрабатывать десятки потоков одновременно. Стандартные кэши CPU на такое неспособны, а редизайн в более дружелюбной для массовой мультипоточности манере снова сталкивается с врожденной однопоточностью CPU‑ядра.

Также, есть одна серьёзная проблема, относящаяся, скорее, к программной архитектуре. Разработчики многоядерных процессоров в маркетинговых материалах любят бравировать «простотой программирования» их решений, т.к. это «обычные CPU». На самом деле, ситуация обстоит ровно наоборот. Такие чипы — это не обычные CPU, а содержащие десятки и даже тысячи ядер. И чтобы утилизировать всю мощь такого CPU, вам необходимо умело использовать максимальное количество ядер, демонстрируя всё мастерство вашего многопоточного программирования. Программировать многопоточные приложения в целом уже задача со звёздочкой, а программировать многопоточное приложение, использующее 1000 ядер, и к тому же не затыкающееся на обмене данными — задача, выходящая далеко за рамки тривиальной. Поэтому, в реальности, пользователям таких систем придётся пользоваться библиотеками и фрейворками, созданными компанией‑разработчиком AI‑процессора, т.к. только специально обученные люди смогут эффективно программировать такого рода систему непосредственно. т.е. по факту, мы опять попадаем в ситуацию, когда вместе с процессором необходимо самостоятельно портировать и поддерживать огромный стек ИИ‑софта и, в этом отношении, становиться на одну ступень с разработчиками Data Flow процессоров, при этом серьёзно уступая им в производительности. Именно поэтому, в вышеприведённых графиках сравнения решений от провайдеров ИИ‑услуг, нет ни одного многоядерного CPU. Они просто неконкурентны ни по одному пункту.

Даже сравнение их пиковой производительности с GPGPU выглядит печально:

Xeon Phi

ET-SOC-1

Nvidia A100

Node, nm

14

7

7

FP16 TOPS

27

35

312

INT8 TOPS

NA

139

624

CPU cores

72

1088

CPU Threads

288

2166

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

Собственно, именно история со ставкой на проект Larrabee и вышедшей из него линейки Xeon Phi сыграло крайне отрицательную штуку с компанией Intel. Презрев заветы своих основателей и руководствуясь скорее синим снобизмом, чем опорой на научный подход и компетентный технический анализ, компания Intel долго упорствовала в попытке с данным тупиковым подходом догнать убегающих вперёд конкурентов. Было упущено драгоценное время, что привело сначала к закрытию линейки Xeon Phi, потом серии лихорадочных и невнятных покупок стартапов, а в итоге, к окончательному проигрышу стремительно взлетающему вверх рынку ИИ‑ускорителей. Именно этот провал стал одним из ключевых причин текущего кризиса компании и изменений в руководстве.

TPU (Systolic arrays)

Строго говоря, аббревиатура TPU (Tensor Processing Unit) может применяться к различным классам вычислителей. Но, исторически, она была популяризована компанией Google для описания разработанного своими силами AI‑ускорителя Google TPU. Данный ускоритель использовал архитектуру, основанную на идее систолического массива. В GPGPU от Nvidia также есть свои тензорные ядра, но принципы их работы отличаются от Google TPU (идейно они ближе к реализации широкого SIMD в многоядерных CPU). Поэтому, наименование TPU во многом стало аналогом «решение на основе систолического массива» и мы будем придерживаться данной терминологии.

Собственно говоря, идея систолического массива проста и была известна (и применялась) ещё на заре появления компьютерной индустрии в 40-х годах 20-го века. Выглядит она примерно вот так: 

Systolic Array
Systolic Array

Т.е. если мы хотим перемножить 2 матрицы A и B, то формируем матрицу из вычислительных элементов (PE, в нашем случае выполняющего умножение с аккумуляцией — FMA) необходимого размера и последовательно подаём на входы вектора из элементов. С одной стороны подаются элементы матрицы А, с другой — матрицы B. Результат вычисления (FMA) и элемент матрицы B передаётся в одну сторону (в нашем случае вниз), а в другую сторону (вправо) передаётся элемент матрицы A.

Подход выглядит подкупающе простым — никаких тебе сложных конвейеров, алгоритмов планирования, замороченной управляющей логики. А так как перемножение матриц является важнейшей операцией для современных алгоритмов искусственного интеллекта, составляющей большую часть вычислительной мощности нейросетей, то, казалось бы, отличная идея применить систолический массив для дизайна AI‑процессора. Для недостающих операций, которые нельзя (или очень невыгодно) исполнять на матричном блоке, добавляются несколько специализированных блоков и можно идти на фабрику выпускать чип. Но, к сожалению, реальность несколько суровее. Технически, тут есть как минимум 2 проблемы:

  • Опять злополучная программная экосистема. Очевидно, что TPU абсолютно не совместим с существующим стеком программного обеспечения для AI. Причём несовместим принципиально — на уровне программной модели. По сути, TPU здесь имеет схожую ситуацию с Data Flow процессорами, когда надо самостоятельно разрабатывать весь инструментарий и поддержку в ИИ‑фреймворках. А это может означать затраты, превосходящие на порядки ресурсы, потраченные на разработку самого железа. Показательно, что в вышеприведённых графиках сравнения скорости/цены работы сетей у провайдеров ИИ‑услуг нет ни одного решения на базе систолического массива. Наверное, только Google TPU является массовым, но фактически используемым для внутренних нужд продуктом. Попытки других игроков на рынке серверных ИИ‑вычислений использовать TPU‑подход в чистом виде, так или иначе, привели их к отказу от данной идеи. И программная экосистема здесь была не единственным фактором.

  • Сложность аппаратной имплементации систолических массивов. Дело в том, что красивая архитектурная картинка с точки зрения логического дизайна разбивается о суровые реалии дизайна физического. Для получения большого количества OPS/FLOPS, очевидно, размер систолического массива должен быть достаточно большим. Типичный размер составляет 128×128, или даже 256×256 элементов. Это 16 384 или 65 536 FMA вычислителей. Причём, в наивной имплементации, мы получим ещё по 2 регистра на каждый FMA‑блок (не забываем, что у нас цифровой дизайн). А если мы хотим ещё и конвейеризованный FMA (а это обязательно, иначе пропускная способность нашего блока снизится в разы), то количество регистровых слайсов увеличится ещё в несколько раз. В итоге мы получаем монолитный блок с сотнями тысяч тактируемых элементов, что даже для этапа логического синтеза представляет уже сложную задачу. А с учётом дальнейшей необходимости развести по такому блоку клоковое дерево, задача становится совсем уж нетривиальной. В итоге, инженерам приходится придумывать различные ухищрения для того, чтобы решить данные проблемы, и реальная имплементация TPU усложняется и отходит от изначальной простой идеи. Показательно, что систолических массивов в железе больше 256×256 не существует, а основная масса не перешагнула порог 128×128. При этом частоты TPU заметно ниже не только по сравнению с CPU, но также уступают GPGPU. Вот как выглядит картина для разных вариантов размера систолического массива (наивная реализация) при логическом синтезе на ячейках библиотеки GPDK045 (на других технологиях картина выглядит схожим образом):

Размер матрицы

Площадь, мм^2

Потребление, мВт

Частота, МГц

4х4

0,0559

9,7

500

8х8

0,222

39,4

350

16х16

0,888

159,4

250

32х32

3,536

639

230

Синтез варианта 32×32 длился больше 5 часов, поэтому пришлось на нём остановиться. Но и так видно, что при росте размера матрицы, частота заметно падает. И это только пока логический синтез, без учёта проблем синтеза клокового дерева.

Давайте посмотрим, к чему это приводит в конечном счёте. Сравним цифры производительности и энергопотребления Google TPU v3 и Google TPU v4 с конкурентами от Nvidia — картами V100 и A100, выходивших примерно в один срок и на идентичных техпроцессах. По данным чипам есть достаточно много информации, в отличие от их более современных вариантов. А так как мы сравниваем архитектурные подходы, то принципиально картина будет идентична для всех поколений. 

Google TPUv3

Nvidia V100

Google TPUv4

Nvidia A100

Node, nm

16

12

7

7

Performance, bf16/fp16 TOPS

123

125

275

312

Max Freq, MHz

940

1530

1050

1410

Power, W

262

300

192

300

TDP, W

450

300

300

400

Power, W, BERT

197

380

Power, W, ResNet

206

273

Die size, mm^2

700

815

600

826

Здесь необходимо сделать несколько комментариев.

Во-первых, различие в 12 и 16 нанометров для V100 и Google TPU v3 не должно вводить в заблуждение — на самом деле для данного вида вычислителей это один и тот же техпроцесс (маркетинговые штучки от TSMC).

Во‑вторых, если цифры по нанометрам и теоретическим TOPS являются точными, то вот данные по потребляемой мощности и производительности реальной являются очень приблизительными. Для Google TPU мы можем полагаться только на заявления самой компании Google (а эти заявления страдают предвзятостью, что мы увидим ниже). Для решений Nvidia тоже достаточно много цифр, интерпретация которых затруднена. Тем не менее, в таблице приведены некоторые ориентиры, но воспринимать их надо с крайней степенью осторожности.

Основной массив данных был почерпнут из данной статьи «TPU v4: An Optically Reconfigurable Supercomputer for Machine Learning with Hardware Support for Embeddings», опубликованной инженерами Google. В ней в самом начале декларируются достаточно амбициозные тезисы, а именно:

For similar sized systems, it is ~4.3x–4.5x faster than the Graphcore IPU Bow and is 1.2x–1.7x faster and uses 1.3x–1.9x less power than the Nvidia A100

Но при детальном прочтении видно, что это не совсем корректные заявления. Оставим несчастный Graphcore, разберёмся с цифрами производительности Google TPU v4 и Nvidia A100. Вышеозначенные утверждения о превосходстве Google TPU v4 основаны на графиках измерения производительности обучения двух видов сетей (ResNet и BERT) из бенчмарка MLPerf. 

TPU v4 vs Nvidia A100
TPU v4 vs Nvidia A100

Что мы видим здесь на самом деле? Что заявление о превосходстве над Nvidia A100 основано на сравнении конфигурации в 4096 чипов. Но это не сравнение архитектуры непосредственно AI‑процессоров, а сравнение дизайна целой системы. Не секрет, что линейка Google TPU проектировалась с большим упором на масштабируемость чипов при организации в большую систему (статьи о Google TPU в основном рассказывают как раз об этом, и раскрывают мало деталей про архитектуру непосредственно самого вычислителя). Даже если эти цифры верны, то нет никаких гарантий, что условный Яндекс, Алибаба или запрещённый Facebook не соберут 4096 вычислителей A100 в более производительную систему. Что же касается измерения производительности архитектуры непосредственно самих чипов, то нас интересует не крайне правая, а крайне левая точка (пусть это всё равно не 1 к 1, а 8 к 8, но других данных нет). И видно, что в реальности NVidia A100 немного обыгрывает Google TPU v4 на ResNet и едва ли не в 2 раза быстрее на BERT (логарифмический масштаб и качество графика не даёт возможности посчитать точнее, но порядок примерно такой).

Более того, в общем‑то, есть показатели, которые фундаментально определяют реальную производительность вычислителей на задачах ИИ. Это:

  • Теоретическая производительность в ТераОпсах, и:

  • Реальная утилизация этих ТераОпсов или MFU (Model Flops Utilization — утилизация доступных на вычислителе FLOPS одним проходом модели)

Из вышеприведённых данных в таблице видно, что чистое количество FLOPS у Nvidia всегда выше. Что же касается MFU, то в силу своей гибкости GPGPU априори должен иметь большую утилизацию по сравнению с TPU, где требуется маппирование любых матричных вычислений на заданный размер 128×128, что в итоге часто будет приводить к недозагрузке матричного вычислителя. Если говорить о конкретных цифрах, то Semianalysis приводит следующие данные: 

Flops utilization
Flops utilization

То есть, A100 суммарно примерно на 31% производительнее. При этом есть заявления, что на NVidia A100 некоторые команды достигали утилизации в 80%. т.е. разрыв по производительности в сравнении с Google TPU v3 увеличивается почти в 2 раза.

Кстати, цифры в ~50% утилизации на LLM моделях на Google TPU v4 можно признать очень достойным результатом, для достижения которого потребовались большие усилия софтварной команды Google. Как это может выглядеть в ситуации, когда у вас нет такого ресурса для программной поддержки вашего аппаратного решения как у Гугла, можно посмотреть вот в этой статье на примере российского решения IVA TPU. Цифры даже для удобного ResNet-50 с учётом всех оптимизаций достигают максимум 24.7%, а для остальных случаев зачастую вообще находятся на уровне единиц процентов.

Что касается сравнения реальной энергоэффективности, то, как было написано выше, тут у нас нет точных данных и есть большое пространство для спекуляций и манипуляций. Например, в той же статье про Google TPU v4 максимально потребляемая мощность декларируется в 192 Ватта (на стр. 7), и уже через 2 страницы средняя мощность на запусках BERT и Resnet указывается 197 и 206 Ватт соответственно. К тому же отметим, что, начиная с Google TPUv3, для данных вычислителей используется жидкостное охлаждение (что как бы намекает).

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

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

GPGPU

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

 

Готовность к промышленному применению

Гибкость

Сложность создания программной экосистемы для ИИ

Производительность

Энергоэф.

Нейроморфные

нет

низкая

высокая

низкая

высокая

Data Flow

да

средняя

высокая

высокая

средняя

Many Cores CPU

да

высокая

средняя

средняя

средняя

TPU

да

средняя

средняя

средняя

средняя

GPGPU

да

высокая

низкая

высокая

средняя

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

 Источник

Суммарно с AMD, производители GPGPU занимают минимум 96 процентов данного рынка. Из оставшихся 4% Huawei и Intel также двигаются в сторону разработки конкурентноспособных GPGPU. Оставшуюся часть занимают DataFlow процессоры. Здесь не учтены гиперскейлеры, разрабатывающие свои решения (упомянутый Google, а также Amazon, Tesla и д.р.), но это суммарно несколько процентов, никак не отменяющие тотального доминирования GPGPU.

В чём особенность работы GPGPU, почему данная архитектура столь удачно работает для задач ИИ, мы расскажем вам во второй части статьи. А также немного приоткроем детали разработки. Оставайтесь на связи и ждём вас во второй части.

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


  1. schulzr
    03.06.2025 16:01

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

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


    1. Armmaster Автор
      03.06.2025 16:01

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


      1. Moog_Prodigy
        03.06.2025 16:01

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


        1. Armmaster Автор
          03.06.2025 16:01

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


  1. schulzr
    03.06.2025 16:01

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

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


    1. Armmaster Автор
      03.06.2025 16:01

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


  1. Wicron
    03.06.2025 16:01

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


    1. beeruser
      03.06.2025 16:01

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


  1. SnakeSolid
    03.06.2025 16:01

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

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

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


    1. Armmaster Автор
      03.06.2025 16:01

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

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


    1. NKulikov
      03.06.2025 16:01

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

      Их нету(практически) в 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.


  1. ivankudryavtsev
    03.06.2025 16:01

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


  1. rPman
    03.06.2025 16:01

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

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


    1. Armmaster Автор
      03.06.2025 16:01

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


    1. acc0unt
      03.06.2025 16:01

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

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

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

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

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


      1. rPman
        03.06.2025 16:01

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

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


        1. acc0unt
          03.06.2025 16:01

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

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

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

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

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


          1. rPman
            03.06.2025 16:01

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


  1. rigdo
    03.06.2025 16:01

    Интересно Ваше мнение об устроставах tenstorrent ( https://tenstorrent.com/hardware/blackhole, https://hc2024.hotchips.org/assets/program/conference/day1/88_HC2024.Tenstorrent.Jasmina.Davor.v7.pdf ), вы отнесёте его к "Data flow", или к GPGPU? У Вас будет что-то похожее, или ближе к Nvidia/amd/...?


    1. Armmaster Автор
      03.06.2025 16:01

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

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


  1. checkpoint
    03.06.2025 16:01

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

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

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


    1. Armmaster Автор
      03.06.2025 16:01

      Правильно ли я понял, что под 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МГц на микроновском техпроцессе невозможны. Производительность такого рода системы будет мизерная, идея сама по себе бессмысленна и не имеет никаких реальных шансов для имплементации


      1. checkpoint
        03.06.2025 16:01

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


  1. old_bear
    03.06.2025 16:01

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


    1. Armmaster Автор
      03.06.2025 16:01

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

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

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

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


  1. Vasyash511
    03.06.2025 16:01

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


  1. lgorSL
    03.06.2025 16:01

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


    1. acc0unt
      03.06.2025 16:01

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

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


  1. acc0unt
    03.06.2025 16:01

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

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


  1. redfire
    03.06.2025 16:01

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


    1. Armmaster Автор
      03.06.2025 16:01

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

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

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

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


  1. event1
    03.06.2025 16:01

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

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


    1. Armmaster Автор
      03.06.2025 16:01

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

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


      1. event1
        03.06.2025 16:01

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

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

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

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


        1. Armmaster Автор
          03.06.2025 16:01

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


        1. beeruser
          03.06.2025 16:01

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

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

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

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

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

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


          1. event1
            03.06.2025 16:01

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


  1. raf329
    03.06.2025 16:01

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

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


    1. Armmaster Автор
      03.06.2025 16:01

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