• Железо: 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 — оставлен как экспериментальный путь.

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

Если говорить физически, зависимость описывается формулой:

Где:

• $Q$ — объемный расход воздуха (м³/с).
• $P$ — мощность тепловыделения (Вт).
• $C_p$ — удельная теплоемкость воздуха.
• $\rho$ — плотность воздуха (падает при нагреве).
• $\Delta T$ — разница температур между входящим воздухом и нагретым компонентом (или выходящим потоком).

Основные закономерности

1. Обратная зависимость от $\Delta T$: Если разница температур между воздухом и деталью сокращается (например, в комнате стало жарче), нам нужно пропорционально увеличить поток, чтобы отвести то же количество тепла.
2. Плотность воздуха ($\rho$): Горячий воздух менее плотный. При одинаковых оборотах вентилятора масса прокачиваемого воздуха падает с ростом температуры, что снижает эффективность охлаждения.
3. Нелинейность на практике: В реальных системах (например, в ПК или серверах) зависимость часто нелинейная из-за турбулентности и изменения теплопроводности материалов.

Иными словами: если температура входящего воздуха поднялась на 10 градусов, а мы хотим оставить температуру процессора прежней, вентиляторам придется крутиться значительно быстрее, чтобы компенсировать уменьшившийся «запас» по температуре.

Пробуем запускать LLM на RISC-V

Целью эксперимента было не столько проверить производительность, сколько понять применимость процессоров RISC-V в качестве управляющих в серверах для ИИ.

Компания Nvidia использует ARM процессоры Vera в качестве управляющих для GPU Rubin.

Почему бы не попробовать использовать RISC-V?

В качестве инференес-движка выбрал LLaMA C++ - LLM inference in C/C++

Критерием успеха для себя выбрал: модель LLM работает и ответила мне хотя бы одним словом.

На чем пробовал и как собирал

Одноплатник StarFive VisionFive 2:

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

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.​

Вызов продиктован современными трендами развития ИИ инфраструктуры и потребностью строительства оптимизированных ЦОД.

Опорные данные:

1. В качестве сервера для расчетов взят сервер Nvidia DGX B200 и серверы с жидкостным охлаждением размером 4U SXM B200
2. Стартовое число размещаемых в ЦОД серверов: 100 штук
3. Среднегодовой рост числа серверов: 200 штук в год

Современный машинный зал для ИИ — это высокоплотная инженерная система, где критически важны энергоэффективность, максимальная плотность размещения оборудования и стратегический выбор архитектуры охлаждения. Для ЦОД ИИ со стартом на 100 серверов NVIDIA DGX B200 (10U в стойке) с ежегодным приростом 200 серверов и расчетом на 3 года, оптимальная инфраструктура требует жесткого следования ряду технических и экономических принципов. Так же рассмотрено размещение серверов с жидкостным охлаждением, более плотное размещение.

Дал комментарий для TAdviser.

Затрагивается тема влияния ИИ в строительстве ЦОД.

Искусственный интеллект давно перестал быть футуристической концепцией и стал рабочим инструментом в самых разных сферах. Но пока обыватели обсуждают креативные возможности ChatGPT и генерацию изображений, в фундаменте цифрового мира — дата-центрах — происходит своя, не менее значимая тихая революция. От оптимизации энергопотребления до предсказательного ремонта оборудования: TAdviser поговорил с экспертами и участниками рынка, чтобы выяснить, как ИИ применяется при создании и эксплуатации ЦОДов в России.

Мы в OpenYard внимательно следим за тем, как развивается инфраструктура для искусственного интеллекта — от железа до сетей и архитектуры дата-центров. Причём это не просто рабочая необходимость, а и то, что нам самим по-настоящему интересно. В эту статью попали материалы, которые мы собираем и анализируем в процессе исследований для наших новых продуктов. Здесь собраны ключевые тренды, которые уже начинают влиять на то, как мы будем строить свою инфраструктуру и запускать модели ИИ в ближайшие 5–7 лет.

Выбирая пути развития программного продукта передо мной зачастую возникает задача проверить гипотезу.

А гипотезу я предпочитаю проверять максимально простым и быстрым способом.

Не планирую описывать команды и отдельные шаги. Опишу саму задачу и подход к решению задачи.

Задача

Запустить платформу речевой аналитики

Речевая Аналитика в телефонии - это полнотекстовый анализ телефонных разговоров. Состоит, укрупненно, из нескольких частей:

• Распознавание речи в текст
• Анализ текста (аналитика)
• Отчетность и принятие решения

Гипотеза

Оценив предложения на рынке, решил рассмотреть возможность реализовать платформу самим, внутри компании.

Простой лайвхак, как использовать Visual Studio Code (VS Code) в качестве редактора заметок на множестве рабочих мест;)

Очень просто.

Делаем себе личный закрытый репозиторий на GitHub и ведем в нем свои записи в любом удобном виде.
Хоть PlantUML, хоть текст. Очень удобно вести заметки в Markdown. А дальше - git pull, git push.

Записная книжка для работы с коллегами или друзьями? Делаем репозиторий в GitHub и приглашаем к нему коллег или друзей;)

В прошлой статье я рассказывал, как мы строим сервисы для разработчиков ИИ и, в частности, коснулся истории появления нашей MLOps Platform. Сегодня мне хотелось бы показать ее изнутри — поделиться возможностями и показать инструменты под капотом.

Надеюсь, получилось достаточно подробно. А для всего остального есть комментарии: не стесняйтесь задавать вопросы, я обязательно отвечу всем интересующимся. Поехали!

Итак, когда мы построили наш GPU SuperCloud, мы поняли, что у некоторых заказчиков есть спрос на услугу «здесь и сейчас». У кого-то горят сроки реализации проекта. Другим не хватает «инженерных» рук. Поэтому мы решили сделать инструмент, который позволял бы прийти «на все готовое». И построили MLOps Platform.