Исследование

• Железо: Intel Core Ultra 7 155H (6P+8E+2LP, 22 потока), Intel Arc Graphics MTL (iGPU, unified memory), 64 GB RAM (доступно ~60 GB), Ubuntu 26.04 LTS.
• Репозиторий: ~/ai/llama.cpp, текущий коммит e107984bc (build 10788)
• Модель-эталон: Qwen3-Coder-30B-A3B-Instruct Q4_K_M (MoE, 30.5B параметров / 3B активных, 17.28 GiB)

TL;DR

• Vulkan > SYCL на Arc MTL: prefill 213 vs 95 t/s, decode 15.7 vs 18 t/s → Vulkan.
• MoE 6× быстрее dense на iGPU: 30B-A3B = 15.7 t/s decode, dense 27B = 2.5 t/s.
• SYCL молча падал без libumf.so.1 в LD_LIBRARY_PATH — чинить нельзя оставить.
• Итог: локальный кодинг-стек llama-server (Vulkan, 32K) + kilo CLI, автозапуск через systemd.

1. Оптимизация сборки

1.1. Эволюция сборок

1.2. Итоговый скрипт сборки ~/ai/llama.cpp/build.sh

#!/bin/bash
set -e

# Инициализация окружения Intel oneAPI (|| true: setvars.sh выходит с кодом 3,
# если переменные уже установлены в текущей сессии — это не ошибка).
# ВАЖНО: не подключаем /opt/intel/openvino/setvars.sh - он экспортирует TBB_DIR
# на свою TBB 2021.13, а MKL-SYCL требует TBB 2023.1 (символ get_thread_reference_vertex).
source /opt/intel/oneapi/setvars.sh --force || true

# Полностью очищаем прошлую неудачную сборку
rm -rf build

# icx/icpx + GCC 15 toolchain (в gcc-13 нет libstdc++ headers, g++-13 не установлен)
cmake -B build \
  -DCMAKE_BUILD_TYPE=Release \
  -DCMAKE_C_COMPILER=icx \
  -DCMAKE_CXX_COMPILER=icpx \
  -DGGML_SYCL=ON \
  -DGGML_SYCL_F16=ON \
  -DGGML_VULKAN=ON \
  -DCMAKE_C_FLAGS="--gcc-install-dir=/usr/lib/gcc/x86_64-linux-gnu/15 -march=native -O3" \
  -DCMAKE_CXX_FLAGS="--gcc-install-dir=/usr/lib/gcc/x86_64-linux-gnu/15 -march=native -O3"

cmake --build build --config Release -j$(nproc)

1.3. Ключевые решения по сборке и почему

• icx/icpx вместо GCC. Компиляторы Intel генерируют код с лучшей векторизацией для SYCL-ядер; SYCL-бэкенд в принципе рассчитан на clang-семейство. CPU-часть при этом остаётся совместимой с ABI.
• --gcc-install-dir=/usr/lib/gcc/x86_64-linux-gnu/15. icpx не включает собственные libstdc++ headers, а использует системный GCC toolchain. В системе GCC 15 — только он содержит нужные headers; попытка собрать с gcc-13 падала на отсутствии заголовков.
• -march=native -O3. Нативный код под Meteor Lake (AVX2/FMA/BMI2 и т.д.).
• GGML_SYCL=ON + GGML_VULKAN=ON в одной сборке. Оба бэкенда живут в одном бинарнике как отдельные shared-библиотеки (libggml-sycl.so, libggml-vulkan.so) — это позволило честно сравнивать их между собой одним llama-bench --device.
• GGML_SYCL_F16=ON. fp16-вычисления на iGPU: Arc MTL поддерживает fp16 нативно, это критично для скорости.
• Конфликт TBB (грабли, задокументированные в скрипте). OpenVINO-окружение экспортирует TBB_DIR на свою TBB 2021.13, а libmkl_sycl_blas (тянутся SYCL-бэкендом) требуют TBB 2023.1 — несовпадение символа get_thread_reference_vertex. Поэтому подключается только /opt/intel/oneapi/setvars.sh, никогда /opt/intel/openvino/setvars.sh.
• setvars.sh --force || true. Повторный source в той же сессии возвращает код 3 — это не ошибка сборки.

1.4. Отдельная ветка: OpenVINO/NPU

Параллельно собиралась версия с GGML_OPENVINO=ON (build/ReleaseOV. NPU Intel AI Boost виден и работает. Для LLM-инференса MoE-моделей уровня 30B NPU не даёт выигрыша против iGPU — оставлен как экспериментальный путь.

Подумаем о космической терморегуляции и охлаждении электроники.

Введение

Сейчас в ИТ-сообществе активно обсуждается новый глобальный тренд — вынос ИИ-вычислений прямо на орбиту. Идея заманчивая, но есть один нюанс: ИИ-серверы потребляют колоссальные 13 кВт электроэнергии и выделяют столько же тепла.
Мой интерес к этой теме подогрел реальный случай — недавно мне довелось вживую изучить специальный сервер, созданный для работы в космосе. Это заставило меня закопаться в спецификации и стандарты NASA/ESA. Как инженеры решают проблему охлаждения в вакууме, где конвекция не работает, а привычные нам вентиляторы абсолютно бесполезны? Добро пожаловать в ликбез по космической терморегуляции.
Охладить электронику в космосе — та ещё задача. Включи ноутбук: на Земле лишнее тепло молча унесёт воздух, и мы этого даже не замечаем. В вакууме воздуху неоткуда взяться, конвекция не работает, и от лишнего тепла можно избавиться только излучением.

Рассмотрим два дизайна серверов:

1. 2 процессора AMD 9005 (CPU_0 и CPU_1), от каждого процессора разведено 5 слотов PCIe x16, в слоты от CPU_0 установлена 4 ускорителя Nvidia H200 NVL, они объединены мостами NVLink 4-post, а так же адаптер Infiniband 400Gbps, в слоты от CPU_1 установлена 4 ускорителя Nvidia H200 NVL, они объединены мостами NVLink 4-post, а так же адаптер Infiniband 400Gbps, таким образом у нас всего 8 ускорителей Nvidia H200 NVL и два адаптера Infiniband 400Gbps.
2. 2 процессора AMD 9005 (CPU_0 и CPU_1), к каждому процессору подключен PCIe Switch Broadcom PEX89144 (BR_0 и BR_1 соответственно), подключение BR к CPU выполнено PCIe5 x16. От коммутатора BR_0 и BR_1 разведено 5 слотов PCIe x16, в слоты от BR_0 установлена 4 ускорителя Nvidia H200 NVL, они объединены мостами NVLink 4-post, а так же адаптер Infiniband 400Gbps, в слоты от BR_1 установлена 4 ускорителя Nvidia H200 NVL, они объединены мостами NVLink 4-post, а так же адаптер Infiniband 400Gbps, таким образом у нас всего 8 ускорителей Nvidia H200 NVL и два адаптера Infiniband 400Gbps.

Краткий вывод

Дизайн 1 (прямое подключение к CPU) является более оптимальным решением для задач инференса и fine-tuning больших моделей, требующих взаимодействия между двумя группами GPU. Прямое подключение через CPU обеспечивает более низкую латентность (15-25 мкс против 2-5 мкс через InfiniBand), лучшую интеграцию с технологиями GPUDirect и упрощённую топологию для tensor parallelism и pipeline parallelism.​