IBM показала архитектуру, которая может изменить расчёт корпоративной AI-инфраструктуры: вместо переноса данных из мейнфрейма во внешний Arm-кластер компания предлагает запускать Arm-софт на том же процессоре, где работает z/Architecture. Это ещё не готовая экономия, но уже достаточный повод остановить автоматическую закупку отдельного контура под каждую новую AI-нагрузку.
Что именно построила IBM
Как пишет Tom's Hardware по итогам Hot Chips 2026, IBM разработала ядро с нативным исполнением двух ISA. Оно может выполнять инструкции z/Architecture и AArch64, динамически переключаясь между ними, по утверждению компании, за наносекунды.
Это не гибридный процессор, где Arm- и z/Architecture-ядра просто расположены рядом. Обе системы команд поддерживает одно ядро. Для AArch64 IBM реализовала в железе версию v9.3 с SVE и поддержкой 2792 инструкций. Arm-виртуальные машины работают через Linux KVM, а стандартные инструкции z/Architecture обходят этот слой.
IBM утверждает, что Arm-софт сможет исполняться без модификаций, а виртуальные машины будут вести себя так, будто запущены на обычном Arm-процессоре. Именно это важнее остальных параметров. Новый чип получит 11 ядер на техпроцессе 2 нм с базовой частотой 5,7 ГГц, 36 МБ частного L2 на ядро, 432 МБ виртуального L3 и 3,5 ГБ виртуального L4. На кристалле также останутся ускорители AI, сжатия и криптографии и встроенный DPU.
Рядом IBM показала следующее поколение AI-ускорителя: 16 ядер, поддержку FP4 и MXFP4, 96 ГБ HBM3e и пропускную способность до 4 ТБ/с. По данным компании, это в 20 раз выше показателя нынешней конфигурации с LPDDR5.
Выигрыш не в частоте, а в отмене обязательного порта
До сих пор у IBM было два неудобных варианта. Можно было переносить софт на s390x, но Тина Тарквинио, директор по продуктам IBM Z и LinuxONE, прямо признала: компания не сможет портировать всё. Либо предприятия держали отдельные Arm- или x86-серверы для софта, который изначально создавался под эти платформы.
Dual-ISA атакует именно эту развилку. Если приложение уже работает в Arm-виртуальной машине, у инфраструктурной команды появляется третий вариант: не переписывать его под z/Architecture и не выносить исполнение в отдельный кластер. Для AI это особенно существенно, потому что, как отмечает Tom's Hardware, большая часть разработки такого софта ориентируется на x86 и Arm, а мейнфрейм затем вынужден догонять экосистему собственными портами.
Для российского оператора практический вопрос звучит не как «быстрее ли новый процессор», а как «можно ли перестать таскать данные к модели». Исполнение рядом с транзакционным контуром потенциально сокращает лишние перемещения данных и число инфраструктурных границ. Но слово «потенциально» здесь главное: IBM пока показала механизм исполнения, а не готовый каталог совместимых AI-продуктов.
Из публикации следует, что без изменений должны запускаться Arm-программы и виртуальные машины. Автоматическая совместимость конкретных контейнерных платформ, AI-фреймворков и коммерческих приложений из этого не следует: их перечня IBM не раскрыла. Нет и данных о ценах, условиях лицензирования, накладных расходах KVM или сравнительной стоимости внешнего inference-кластера и исполнения на мейнфрейме.
Поэтому победитель пока один: команда, которая отвечает за архитектуру и получает больше вариантов размещения нагрузки. Поставщики отдельных Arm-серверов могут потерять часть сценариев, но только если IBM докажет экономику. Сам факт, что код запускается, ещё не означает, что его выгодно там держать. В корпоративной инфраструктуре лицензия иногда весит больше, чем весь разговор о наносекундах.
Что проверять в дорожной карте
Сейчас владельцам инфраструктуры стоит пересчитать хотя бы один реальный сценарий: Arm-виртуальная машина с AI-сервисом обращается к данным мейнфрейма из внешнего кластера или исполняется рядом с ними. Сравнивать нужно задержку, объём перемещаемых данных, требования безопасности, лицензирование и полную стоимость, а не только загрузку CPU.
Главный маркер на следующем этапе: IBM должна опубликовать перечень поддерживаемых Arm-стеков и измерения реальных AI-нагрузок вместе с коммерческими условиями. Если появятся воспроизводимые сравнения внешнего inference-кластера и dual-ISA-конфигурации, консолидацию можно будет закладывать в бюджет. Если останутся только частота, число инструкций и обещание нативности, отдельный серверный остров пока рано сносить.