«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:
Поэтому, если адаптировать алгоритм вычисления такой сети под Data Flow процессор, мы можем получить серьёзное ускорение. Давайте на примере процессора от компании Groq посмотрим, как это примерно может выглядеть в железе:
Видно, что процессор состоит из большого количества регулярных элементов, объединённых в слои в зависимости от своей специализации (перемножение матриц, работа с векторами, трансформация данных). Что в итоге это даёт? Сравнение производительности и остальных характеристик такого рода решений крайне сложный процесс. Хотя бы потому, что просто так купить процессор от Groq или SambaNova не получится. А маркетинговые материалы компаний‑производителей страдают скудностью данных и очевидным желанием приукрасить результаты. Поэтому давайте обратимся к такому замечательному сайту artificialanalysis.ai, на котором приведены замеры, которые можно взять за точку отсчёта. Для начала, посмотрим производительность на модели 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? Чтобы ответить на этот вопрос, давайте посмотрим для начала на ещё один график с вышеупомянутого сайта:
Это цена, которую платят клиенты за использование ИИ‑ускорителей в облаках провайдеров для сети 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-го века. Выглядит она примерно вот так:
Т.е. если мы хотим перемножить 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.
Что мы видим здесь на самом деле? Что заявление о превосходстве над 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 приводит следующие данные:
То есть, 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, почему данная архитектура столь удачно работает для задач ИИ, мы расскажем вам во второй части статьи. А также немного приоткроем детали разработки. Оставайтесь на связи и ждём вас во второй части.