NEC Vector Engine: как векторный суперкомпьютер превратился в PCIe-карту

Казалось, векторная идея осталась музейным экспонатом. Но NEC не свернула это направление, а миниатюризировала его. Вместо огромного шкафа-суперкомпьютера SX компания создала Vector Engine – процессор, который физически ставится в стандартный PCIe-слот сервера, как видеокарта. Это позволило сохранить саму философию длинных векторов, но избавиться от необходимости строить под неё отдельные машинные залы.

Название SX-Aurora TSUBASA отражает эту переходную природу: «Aurora» – новое поколение, «Tsubasa» (крыло) – образ старой школы, получившей новую, компактную форму.

Здесь легко провести аналогию с GPU, но она обманчива. В классической схеме CPU+GPU процессор хоста управляет всем процессом: готовит данные, запускает вычислительные ядра на ускорителе, забирает результат. GPU – исполнитель отдельных фрагментов работы, а не хозяин всего приложения.

NEC перевернула эту схему. Обычный сервер называется Vector Host (VH), а сама плата – Vector Engine (VE). Но именно VE запускает полное приложение целиком – включая его скалярные, невекторизуемые части, – тогда как хост берёт на себя операционную систему, файловый ввод-вывод, сетевые вызовы и системное администрирование.

Разница принципиальна: в GPU-модели приложение постоянно “прыгает” между хостом и устройством, и каждый такой переход стоит времени. В модели VE это узкое место исчезает почти полностью, потому что программе не нужно возвращаться на хост для выполнения обычного кода – она просто продолжает работать на той же карте. Хост подключается по PCIe и участвует через DMA, но не диктует логику выполнения.

Для разработчика с опытом в экосистеме CUDA это выглядит непривычно: карта здесь не аксессуар для “тяжёлых кусков”, а полноценная вычислительная платформа, программируемая на C, C++ или Fortran с использованием OpenMP внутри одного VE и MPI между несколькими VE или узлами.

NEC формулирует идеологию VE тремя аспектами: длинные векторы, огромная пропускная способность памяти, немного, но очень мощных ядер. Эта формула объясняет почти все конструктивные решения архитектуры.

Длина вектора. Каждое ядро VE20 располагает 64 архитектурными векторными регистрами, а каждый регистр вмещает 256 элементов по 8 байт – то есть 256 чисел двойной точности, или 2 КиБ данных в одном регистре. Для сравнения: 512-битный регистр AVX-512 хранит всего восемь таких чисел. Иными словами, одна инструкция VE обрабатывает столько данных, сколько 32 инструкции современного x86-SIMD.

Память как приоритет. Реальные научные программы редко ограничены количеством арифметических блоков – их обычно ограничивает скорость подачи данных. Если процессор способен на 20 терафлопс, но не может прокормить конвейеры данными достаточно быстро, часть исполнительных блоков просто простаивает. Векторная архитектура решает эту проблему иначе, чем GPU: вместо переключения между тысячами лёгких потоков она использует предсказуемый, длинный, непрерывный поток элементов, который скрывает задержку доступа к памяти самой своей регулярностью.

Немного, но крупных ядер. VE20 содержит десять векторных ядер с частотой 1,6 ГГц. Одно ядро развивает до 307 гигафлопс FP64 и 614 гигафлопс FP32; в сумме десять ядер дают теоретический пик 3,07 терафлопс двойной точности и 6,14 терафлопс одинарной. Это скромно по сравнению с современными AI-ускорителями, но у VE иная цель – не пиковые числа, а высокая устойчивая производительность на реальных научных кодах.

Каждое векторное ядро VE20 состоит из четырёх функциональных блоков: Scalar Processing Unit (SPU), Vector Processing Unit (VPU), блока генерации и трансляции адресов и внутреннего кроссбара пересылки данных.

Общая схема структуры Vector Core. Источник: NEC

SPU отвечает за всё, что не векторизуется: переходы, вызовы функций, исключения, подготовку адресов и общее управление векторным блоком. Это важная деталь – векторный процессор не требует, чтобы весь код был идеально параллельным; скалярная логика тоже обрабатывается прямо на карте, причём SPU способен выбирать и исполнять до четырёх инструкций за такт с предсказанием ветвлений и аппаратным prefetch.

VPU – вычислительное сердце ядра. В нём находится 128 КиБ архитектурных векторных регистров и 32 параллельных векторных конвейера (VPP), каждый со своим набором исполнительных блоков: три FMA-конвейера (fused multiply-add – операция a×b+c за один шаг с одним округлением), два ALU-конвейера и отдельный конвейер для записи и сложных операций.

Арифметика здесь работает так: 3 FMA-конвейера × 32 канала × 2 операции на FMA = 192 операции двойной точности за такт на одно ядро. Отдельно поддерживаются деление и извлечение квадратного корня – операции, которые редко доминируют в профиле нагрузки, но способны резко тормозить расчёт, если алгоритм часто к ним обращается.

Любопытная деталь: программист и компилятор видят только 64 архитектурных регистра, но физически VPU располагает 256 регистрами. Механизм переименования регистров устраняет ложные зависимости между инструкциями, позволяет заранее подгружать данные и не останавливать конвейер из-за долгих операций типа деления. Плюс к этому VPU умеет планировать векторные инструкции внеочередно. Получается гибрид: снаружи – классическая векторная машина с огромными регистрами, внутри – приёмы, характерные для современных высокопроизводительных скалярных CPU.

Если ядра – это двигатель, то память – топливная система, без которой двигатель бессмысленен. VE20 использует шесть стеков HBM2, соединённых с кристаллом через кремниевый интерпозер; каждый стек обслуживается собственным контроллером, и суммарная пропускная способность достигает 1,53 ТБ/с – то есть примерно по 256 ГБ/с на модуль.

NEC приводит для VE20 показатель Byte/FLOP на уровне 0,5 – соотношение объёма памяти к вычислительной мощности. Чем выше это число, тем больше шанс, что программа с посредственной арифметической интенсивностью всё же покажет достойную реальную (не пиковую) производительность, а не будет простаивать в ожидании данных.

Между ядрами и памятью расположен общий последний уровень кэша (LLC) объёмом 16 МБ, разбитый на 128 банков (восемь групп по 16), с суммарной пропускной способностью до 3 ТБ/с. LLC дублирует в себе содержимое кэшей скалярной части и спроектирован так, чтобы несколько ядер могли одновременно к нему обращаться без превращения кэша в единое узкое место.

Кэш и контроллеры памяти умеют работать не только с обычным последовательным чтением данных, но и с типичными для научных расчётов способами доступа: чтение через равные промежутки (с шагом), сбор и рассылку разрозненных значений по массиву, а также обращение к данным через вспомогательные индексные таблицы. Для таких случаев предусмотрены отдельные аппаратные оптимизации записи с шагом и операций сбора/рассылки, а также возможность задавать приоритет, какие данные в кэше нужно сохранять дольше, а какие – вытеснять первыми.

Все эти узлы – ядра, кэш и контроллеры памяти – связаны внутренней сетью на кристалле, устроенной как многослойная двумерная решётка из 16 уровней. Она обеспечивает теоретическую пропускную способность до 409,6 ГБ/с на чтение и столько же на запись для каждого ядра .

Первое поколение, VE10, легло в основу ранних систем SX-Aurora TSUBASA: восемь векторных ядер, шесть модулей HBM2, пропускная способность около 1,22 ТБ/с и пиковая производительность до 2,45 терафлопс FP64.

Второе поколение, VE20, увеличило число ядер до десяти, добавило 16 МБ общего LLC и подняло пропускную способность памяти до 1,53 ТБ/с – рост примерно на четверть. Пиковая производительность выросла до 3,07 терафлопс FP64.

Третье поколение, VE30, стало самым крупным обновлением в истории линейки: число ядер выросло до 16 (на 60% больше, чем у VE20), память перешла на более быстрый стандарт HBM2e, а пропускная способность подскочила до 2,45 ТБ/с, то есть выросла ещё почти на 60% относительно VE20. Пиковая производительность достигла 4,9 терафлопс FP64, а объём кэша увеличился до 64 МБ.

Важно не сравнивать эти цифры напрямую с современными AI-ускорителями типа NVIDIA A100 или H100. Те проектировались вокруг матричных тензорных операций и низкоточных форматов (BF16, FP8) для нейросетей; Vector Engine изначально строился вокруг FP64-векторизации и сбалансированного доступа к памяти для классического научного HPC. Поэтому уместнее сравнивать не у кого больше терафлопсов, а какая доля пиковой производительности реально достижима на конкретном алгоритме.

Один Vector Host может обслуживать одну, две, четыре или восемь карт VE, а стойка допускает десятки таких карт с масштабированием через MPI и высокоскоростную сеть между узлами.

Ключевая инженерная задача NEC – избавить разработчика от необходимости писать 256-элементные векторные операции вручную. Для этого создан собственный векторизующий компилятор, который анализирует обычный код на C, C++ или Fortran, находит подходящие для векторизации фрагменты и сам генерирует оптимальный машинный код.

Но автоматизация не означает независимость от структуры алгоритма. Лучше всего компилятор справляется с длинными регулярными циклами без сложных зависимостей между итерациями, классический пример SAXPY-подобного паттерна вида c[i] = a[i]*b[i] + c[i]. Такой цикл легко разбивается на длинные векторные блоки, проходящие через FMA-конвейеры почти без пауз.

Гораздо хуже ситуация с алгоритмами, где каждая итерация зависит от предыдущей, адреса данных непредсказуемы, а тело цикла насыщено условными переходами, например, обработка связных списков или преследование указателей. В таких случаях преимущество длинного вектора практически исчезает, и VE ведёт себя не лучше обычного скалярного процессора, хотя скалярная часть (SPU) всё же позволяет программе корректно работать.

Экосистема вокруг VE значительно уступает по масштабу CUDA: пользователю нужны собственные компиляторы NEC, библиотеки MPI и системное окружение платформы. Архитектура сохраняет преемственность программной модели NEC SX, а приложения SX-Aurora TSUBASA, но это скорее преимущество для унаследованных научных кодов, чем универсальный стандарт индустрии.

Естественная среда для VE – задачи, где данные представлены крупными числовыми полями, обрабатываемыми похожим образом: гидро и аэродинамика, распространение волн, теплоперенос, климатическое и погодное моделирование, вычислительная химия, молекулярная динамика, линейная алгебра и часть аналитических нагрузок.

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

NEC также заявляла платформу для задач ИИ, машинного обучения и обработки больших данных. Здесь стоит сделать оговорку: современное обучение нейросетей, особенно больших языковых моделей, обычно оптимизируется под тензорные ядра и низкоточные форматы CUDA/ROCm-экосистемы. VE может быть эффективен для отдельных аналитических нагрузок и вычислений с преобладанием широких векторных операций, но не претендует на прямую замену NVIDIA-ускорителей в типичном пайплайне обучения диффузионных моделей или LLM.

Для инженера, привыкшего мыслить в терминах CUDA-ядер и warps, VE предлагает альтернативную ментальную модель: вместо управления тысячами лёгких потоков – работа с очень длинной, единой векторной инструкцией, поддержанной мощным потоком памяти и традиционными HPC-инструментами OpenMP/MPI. Первый подход похож на управление огромной фабрикой рабочих. Второй – на очень длинную и предсказуемую автоматизированную производственную линию.

VE не стал массовым стандартом рынка, и причина не в слабости архитектуры, а в масштабе экосистемы. CUDA превратилась в фактический язык ускоренных вычислений: вокруг неё выросли библиотеки, профилировщики, облачные сервисы и огромное сообщество разработчиков. У VE своя, гораздо более нишевая программная среда.

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

Третье – стоимость переноса. Старые Fortran-коды научных институтов могут очень удачно перенестись на SX-Aurora. Новому проекту нужно оценивать не только скорость отдельного бенчмарка, но и наличие библиотек, готовых контейнеров, специалистов и облачного доступа. Производительность одного теста редко компенсирует слабую интеграцию в существующий рабочий процесс.

Ценность NEC Vector Engine не в конкретных цифрах спецификации, а в самой идее, которую эта архитектура иллюстрирует: производительность определяется тем, насколько устройство соответствует форме задачи, а не количеством ядер или заявленными терафлопс на бумаге.

VE показывает жизнеспособную альтернативу модели “GPU для всего”. Он наследует полувековой опыт классических векторных суперкомпьютеров NEC SX, но упаковывает его в привычную Linux-инфраструктуру с x86-хостом, PCIe-подключением, HBM2-памятью, DMA-передачей данных и стандартными для HPC инструментами OpenMP и MPI. Даже в эпоху доминирования GPU в задачах ИИ такая архитектура продолжает предлагать собственный, целостный ответ на главный вопрос вычислительной техники – как не дать быстрым арифметическим блокам простаивать в ожидании данных из памяти.