Что такое форк Strata под IBM AC922 и зачем он понадобился
Автор взял инференс-движок Strata, который написал разработчик под ником Niko1221, и существенно переработал его под сервер IBM AC922. Правки вносились итерациями с ИИ-ассистентом Opus 5.5, а результаты автор описал в обсуждении на r/LocalLLaMA: A Strata fork for IBM AC922 running Qwen3.8-FN UD-Q4_K_XL.
IBM AC922, машина 2018 года, это два процессора POWER9 по 20 ядер с SMT4 и до шести GPU NVIDIA Tesla V100 SXM2, подключённых к CPU через NVLink. В конфигурации автора карт четыре, по 16 ГБ каждая. Пропускную способность канала CPU-GPU производитель заявляет на уровне 150 ГБ/с, а драйверы NVIDIA при этом разрешают unified memory access.
Задача формулируется без затей: заставить современный инференс LLM работать на нестандартном железе, где привычные движки выдают невнятные цифры. Похожие истории уже случались на другой технике: например, Strata на RTX 5070 с 12 ГБ VRAM выдаёт около 65 ток/с там, где llama.cpp давал 15, и там причина тоже в привязке движка к конкретному железу.
Код форка выложен публично: github.com/eelgaev/Strata-AC922.
Стартовая точка: что выдавал llama.cpp на этой машине
До переработки llama.cpp на этой конфигурации показывал около 130 ток/с prefill и 15 ток/с decode. Разрыв между этими двумя числами и есть суть проблемы: обработка промпта ещё куда ни шло, а генерация практически нерабочая. 15 ток/с на выходе означают, что короткий ответ на несколько абзацев придётся ждать минутами, и ни о каком интерактивном чате речи не идёт.
Причина не в том, что llama.cpp плохой движок. Его оптимизации рассчитаны на связку x86 и современных GPU, где Tensor Core работают с BF16, а память между CPU и ускорителем устроена предсказуемо. POWER9 и Volta в эту картину не попадают: часть путей просто не задействуется, а часть работает неэффективно. Получается несоответствие движка и железа, а не ошибка в реализации.
Ключевые изменения: что именно дало кратный прирост
Автор называет пять направлений: FP16 вместо BF16, управление памятью, кэширование экспертов на GPU, более эффективное использование NVLink и ставку на Tensor Core вместо операций на CUDA-ядрах. В обсуждении речь идёт о Qwen3.8-FN в кванте UD-Q4_K_XL, а объём экспертов в 72 ГиБ указывает на архитектуру со смесью экспертов.
FP16 вместо BF16: почему на V100 это меняет всё
Tensor Core в Tesla V100 рассчитаны на FP16. Аппаратная поддержка BF16 появилась в GPU только с архитектурой Ampere, поэтому на Volta этот формат обрабатывается обычными CUDA-ядрами. Пока расчёты шли в BF16, тензорные блоки простаивали, а арифметика висела на универсальных блоках.
Перевод модели в FP16 вернул вычисления на Tensor Core, и это одна из главных причин, по которой prefill вырос в разы. Ограничение у решения тоже есть, и оно жёсткое: приём привязан к Volta. На A100 и H100 картина обратная, там BF16 поддерживается аппаратно и часто выгоднее по точности и объёму памяти.
Page-lock 72 ГиБ экспертов и работа с памятью
Все 72 ГиБ экспертов закреплены в оперативной памяти через page-lock сразу на обоих сокетах POWER9. Page-lock означает, что страницы прибиты к физическим адресам и не могут уехать в swap. Для передачи на GPU это принципиально: данные уходят по DMA без ожидания подкачки и без риска получить page fault ровно в тот момент, когда карта ждёт их для следующего слоя.
GPU забирают эти данные по NVLink 2.0 примерно по 70 ГБ/с каждая. Это фактическая скорость в конкретном сценарии, а не предельная пропускная способность интерконнекта. Платформа в целом заявлена на 150 ГБ/с между CPU и GPU.
Кэширование экспертов на GPU и роль NVLink 2.0
В моделях со смесью экспертов основной трафик при генерации идёт по весам экспертов: на каждый токен нужно подтянуть те, что выбрал роутер. Если все 72 ГиБ лежат только в RAM, decode превращается в непрерывный поток передач по шине. Кэш самых востребованных экспертов прямо на картах срезает эту нагрузку и оставляет на NVLink только то, что действительно нужно.
NVLink 2.0 здесь работает как основной ресурс. На PCIe вышло бы заметно меньше, и decode упёрся бы в шину задолго до трёхзначных значений. Фактические 70 ГБ/с на карту показывают, что интерконнект в этой сборке нагружен серьёзно.
Результаты: 7 357 ток/с prefill и 113 ток/с decode в цифрах
Все числа ниже взяты из описания автора форка, независимых измерений в открытых источниках нет. Версии драйверов, операционной системы и параметры промптов, кроме длины 252K токенов, он не приводит, так что повторить замеры один в один по этому тексту не получится. Сравнивать цифры из одного источника всегда стоит с оглядкой: у сторонних замеров одной и той же модели разброс бывает заметным, как в случае с тестами DeepSeek V4.1 Flash на восьми A40 в Q2_K и Q4_K_M.
| Метрика | llama.cpp (до) | Форк Strata (пик) |
|---|---|---|
| Prefill, короткий промпт | ~130 ток/с | 7 350 ток/с |
| Prefill, промпт 252K токенов | н/д | 7 090 ток/с за 35 с |
| Decode, пик | ~15 ток/с | ~113 ток/с |
| Decode, код | н/д | ~100 ток/с |
| Decode, проза | н/д | ~84 ток/с |
| Первый токен на глубине 252K | н/д | 0,26 с, далее 60 ток/с |
Prefill: 7 350 ток/с на коротком промпте и 7 090 на 252K
Пиковый prefill составил 7 350 ток/с. На промпте в 252K токенов показатель 7 090 ток/с, обработка заняла 35 секунд. Просадка меньше четырёх процентов на объёме, который для локальных сценариев считается очень длинным контекстом. Для сравнения: исходные 130 ток/с означали, что такой же промпт обрабатывался бы большую часть часа, то есть длинный контекст был недоступен в принципе.
Decode: 113 ток/с на JSON, 100 на коде, 84 на прозе
Пиковая генерация около 113 ток/с на JSON, около 100 ток/с на коде и около 84 ток/с на прозе при MTP-спекулятивном декодировании. Разброс по типам контента объясняется природой спекулятивного декодирования: чем предсказуемее последовательность, тем чаще черновые токены принимаются без пересчёта целевой моделью. JSON максимально структурирован, проза наименее, поэтому разница в 30 процентов между ними закономерна.
113 ток/с это пик, а не средняя скорость. Даже 84 ток/с на прозе дают комфортную интерактивную работу, а исходные 15 ток/с не давали её вовсе.
Первый токен на глубине 252K: 0,26 с
При глубине контекста 252K первый токен пришёл через 0,26 с, дальше генерация шла на 60 ток/с. Задержка до первого токена почти не выросла, а скорость после него заметно ниже пиковой. На такой глубине через NVLink проходит больше данных на каждый шаг, и значительная часть времени уходит на загрузку того, что нужно текущему слою.
Как это делалось: профилирование, итерации и роль Opus 5.5
Для отладки временных разрывов автор использовал NVIDIA Nsight Systems (nsys). Профилировщик показывает картину на таймлайне: сколько занимает подготовка батча, сколько ждёт копирование данных, в какой момент карта простаивает в ожидании следующей порции.
Без такого разбора правки делаются вслепую. Меняешь параметр, получаешь другой tok/s и не понимаешь, что именно сработало, а что просто совпало с другим изменением. nsys отвечает на вопрос «где теряется время» на уровне отдельных операций.
Opus 5.5 использовался для итераций и внесения правок в код. Речь об инструменте, который быстро перебирает варианты и переписывает участки кода. Что именно менять и в каком порядке, определял автор: без понимания архитектуры POWER9 и Volta профиль показывает симптомы, а не причины.
Кому это нужно и какие ограничения у решения
Форк рассчитан на POWER9, Tesla V100 и NVLink между CPU и GPU. Владельцу x86-машины с RTX 4090 он не даст ничего: FP16-путь там не даёт эксклюзивного выигрыша, а канала NVLink между процессором и картами попросту нет. Это не универсальное ускорение, а набор решений под конкретную платформу.
Стоит ли повторять на другом железе
Переносится подход: профилирование через nsys перед любыми правками, идея держать самых востребованных экспертов на GPU, page-lock для больших MoE-моделей. Не переносится напрямую FP16 вместо BF16, поскольку это специфика Volta, и опора на NVLink 2.0, поскольку это специфика AC922.
Похожие задачи решают иначе в зависимости от железа. На двух Radeon AI PRO R9700 эксперты стримят с другим балансом VRAM и RAM, а на одном B300 упираются в отказ MoE-ядра без expert parallel. Логика общая: сначала найти узкое место, потом подбирать приёмы.
Что будет с апстримом
Автор планирует вернуть часть изменений в оригинальный Strata. Полного слияния не будет: он предполагает, что движок останется ориентированным в первую очередь на конкретное железо, и считает это нормальным. Базу для форка дал Niko1221, и речь идёт о развитии под отдельный сценарий, а не о замене оригинала. Планы по апстриму описаны в том же обсуждении: источник.
Что дальше и где смотреть код
Репозиторий форка: github.com/eelgaev/Strata-AC922. Это исследовательский проект, а не готовый продукт, и установки в один клик ждать не стоит.
Если хочется повторить подход на своей машине, начните с профилирования. Прогоните свой сценарий через nsys, посмотрите, где простаивают GPU и где копируется больше всего данных. По этому списку сразу видно, какие из пяти приёмов вообще применимы к вашей конфигурации, а какие бессмысленны. Гарантий, что тот же набор правок даст кратный рост на другом железе, нет: в этом кейсе сработало совпадение архитектуры V100, NVLink 2.0 и большого объёма page-locked памяти.