Как мы за неделю подружили DeepSeek-R1 с отечественными процессорами ARM64, NVIDIA A100 в 100% отечественном сервере / Хабр

Всем привет!

Меня зовут Алфёров Валентин, я директор по развитию компании Е-Флопс. В этой статье хочу поделиться с вами опытом нашего инженера-тестировщика, который рассказал мне эту историю, продемонстрировал результат и даже уговорил записать видео об этом))). Всё, что написано дальше, рассказ Сергея Шишкина от первого лица.

Дисклеймер: мы не пытаемся сказать, что сделали нечто революционное. LLM на GPU‑ускорителях запускали многие. Но запустить её на реальном сервере с отечественными ARM‑процессорами, с двумя NVIDIA Tesla A100, в изолированном контуре - и чтобы она ещё работала без падений - это оказалось нетривиальным квестом.

Делимся результатом и рецептом.

1. Зачем нам вообще локальная LLM?

Коротко про LLM и «ИИ»

Большие языковые модели (LLM) - это не магия, а очень большие нейросети, обученные предсказывать следующий токен (кусочек текста). Их называют «ИИ», потому что они умеют обобщать, писать код, отвечать на вопросы и даже шутить. Но под капотом - матричные умножения, attention и гигабайты весов.

Почему локально, а не ChatGPT?

Мы разрабатываем и тестируем железо и софт, пишем тонны документации. Использовать облачные LLM у нас нет возможности исходя из внутренних регламентов безопасности использования данных: данные уходят вовне, а у нас есть жесткие требования к информационной безопасности. Поэтому мы решили поднять собственную LLM внутри закрытого контура, на собственных серверах.

Кроме того, мы хотели проверить:

Как отечественные процессоры с архитектурой ARM64 (96 ядер на вычислительный модуль) справляются с инференсом LLM;
Можно ли эффективно использовать два ускорителя NVIDIA A100 без NVLink; что сломается, а что заработает;
Сколько типовой пользователь потратит времени на развертывания аналогичной системы.

Спойлер: многое сломалось, но мы победили.

2. Почему выбрали DeepSeek-R1-Distill-Llama-70B?

Вариантов много: Llama 3, Qwen, Mistral, российские модели… Мы выбрали DeepSeek- R1-70B в квантизации Q4_K_M по нескольким причинам:

Открытая модель - можно качать и использовать без ограничений;
Достаточно мощная для начала (тестовая генерации документации, помощь в отладке, ревю кода). Мы взяли такую модель, чтобы контекстное окно в 128000 токенов гарантированно поместилось в VRAM двух нейроускорителей;
Скромная ресурсоёмкость - 70B параметров в 4-битном виде с окном в 128000 токенов весят примерно по 42 ГБ на каждый ускоритель A100. Это оставляет запас для будущих экспериментов, так как у каждого по 80 ГБ VRAM;
Популярность и отзывы - модель показала себя неплохо на бенчмарках и в реальном использовании.

Позже мы хотим экспериментировать с Qwen3 72B или даже 200B+ с RAG (Retrieval- Augmented Generation), но для первого блина решили не брать самый тяжёлый ком).

3. На каком железе всё это работает?

Сервер «М1» в сборе:

Шасси: М1РШ (19″, 6U, 4×CRPS 3000 Вт).
Вычислительный модуль:
- Модель: MB2_б.
- Процессоры: 2 × ARM64, Cortex-A75, 48 ядер на сокет, всего 96 ядер.
- Оперативная память: 384 ГБ DDR4-3200 ECC (12×32 ГБ).
- Графические ускорители: 2 × NVIDIA Tesla A100 80GB PCIe (без NVLink).
- Накопители: 256 ГБ NVMe М.2 для системы.
- Сеть: 1GbE.

Почему именно так?

MB2_б - модель вычислительного модуля, спроектированная для задач ИИ, которая позволяет размещать 2 полноразмерных GPU-ускорителя (двойная ширина (два слота PCIe x16)).
NVIDIA Tesla A100 - золотой стандарт для LLM: 80 ГБ HBM2e, Tensor Cores, поддержка FP16/BF16/INT8.
384 ГБ ОЗУ - для будущих больших контекстов и нескольких параллельных запросов.

Важный нюанс с NUMA: наша платформа привязывает GPU к разным NUMA-узлам:

GPU0 → потоки 0-47,
GPU1 → потоки 48-95.

Это положительно сказалось на производительности (и мы к этому ещё вернёмся).

4. Как ставили: сборка, драйверы, танцы с бубном

Процесс был задокументирован в 16-страничном отчёте. Приведу сокращённый, но честный путь.

4.1. ОС и ядро

Мы используем Debian 13 (trixie) с ядром 6.12.28-baikal-arm64.

cat /etc/os-release
# PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
uname -r
# 6.12.28-baikal-arm64

4.2. Драйверы NVIDIA и CUDA

nvidia-smi --version
# NVIDIA-SMI 550.163.01, CUDA 12.4

Под ARM64 драйверы работают, но есть свои особенности (например, сборка из репозитория NVIDIA, а не из Debian).

4.3. Сборка llama.cpp с CUDA — танцы...

Стандартная команда да cmake -DGGML_CUDA=ON работает, но есть подводные камни:

Обязательно отключите shared libraries: -DBUILD_SHARED_LIBS=OFF, иначе получаете undefined reference to ggml_cuda_op_* при линковке.
Явно укажите архитектуру CUDA: -DCMAKE_CUDA_ARCHITECTURES="80" (для A100).
Проверяем, что CUDA подхватилась:

ldd ./build/bin/llama-server | grep 
cuda # libcudart.so.12, libcuda.so.1 
# — есть!

4.4. Запуск сервера с правильным NUMA и распараллеливанием

Это ключевой момент. Из-за привязки GPU к разным NUMA-узлам нужно:

Использовать --numa distribute - разрезать запросы между узлами.
Разделить тензоры между GPU: --tensor-split 0.5,0.5 (поровну).
Указать количество потоков CPU = половине ядер (48, а не 96), чтобы не создавать лишнего контекста.

5. Что получилось: скорость, метрики, скриншоты

5.1. Загрузка GPU

nvidia-smi

Каждая A100 жрёт ~40-42 ГБ памяти (из 80). Остальное - про запас и кэш.

5.2. Тестовый запрос

curl -s http://localhost:8080/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{ "model": "deepseek-r1-70b", "messages": [{"role": "user", "content": "2+2="}], "max_tokens": 10, "stream": false }'

Ответ приходит за ~0.5 секунды на простом вопросе.

5.3. Скорость генерации (токенов/с)

Мы замерили на задаче средней сложности (написание короткого фрагмента документации):

Prefill (обработка входа) — около 600 токен/с.
Generation (декодинг) — 20–23 токен/с.

Это быстрее, чем чтение человеком. Для двух параллельных пользователей скорость падает до ~19-21 токен/с на каждого - всё ещё комфортно.

5.4. Почему разнесли модель на два ускорителя?

Модель 70B в Q4_K_M весит 42 ГБ. Один ускоритель A100 80 ГБ мог бы обрабатывать ее целиком, но:

Тогда пропадает возможность параллельной обработки разных запросов на разных GPU.
Мы теряем NUMA-оптимизацию (каждый GPU-ускоритель работает со «своим» центральным процессором (CPU)). Tensor parallelism (разрезание матриц) даёт небольшой выигрыш в скорости на больших батчах.
Нам нужно было проверить работу сразу двух GPU-ускорителей.

Поэтому --tensor-split 0.5,0.5 - осознанное решение.

5.5. Ограничения и подводные камни

Веб-интерфейс llama.cpp выдаёт TypeError: Cannot read properties of undefined - это баг, лечится обновлением llama.cpp.
Бред, вместо осмысленного ответа победили правильной конфигурацией запуска с рабочим параметром чата.

5.6. Как это выглядит на экране монитора

Вот так выглядит интерфейс общения с LLM

6. Фотографии железа (как оно выглядит вживую)

Вот так выглядит наш сервер «М1» в серверной стойке с задней части. Рука на вычислительном модуле, на котором крутится LLM

Вот я вынимаю вычислительный модуль из серверного шасси

Вот он, вычислительный модуль МВ2б — Вот он, вычислительный модуль МВ2_б

Вот я снял переднюю часть верхней крышки вычислительного модуля

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

Вот нижний ярус вычислительного модуля. Центральная перегородка, которая разделяет потоки воздуха на GPU-ускорители и системную плату, снята

7. Описание вычислительного модуля МВ2б

Вычислительный модуль MB2_б двойной ширины (специализированная модель для ИИ нагрузок) установлен в шасси М1РШ сервера «М1» в исполнении для инфраструктуры стоек 19” (есть еще исполнение для стоек стандарта OCP 12В и 48В) и занимает в 6U шасси 2 слота.

Описание МВ2_б:

На лицевой панели: слот расширения OCP, 8 накопителей SSD NVMe с горячей заменой форм-фактора М.2, два порта SFP28 (25 GbE), разъем USB-C, предназначенный для подключения KVM адаптера, кнопки Power, Reset, ID, вентиляционная решётка, скрывающая GPU-ускоритель.
Внутри: на нижнем ярусе - системная плата MBS01 (Ключевская) с двумя процессорами отечественного чипмейкера на борту, 12 слотами оперативной памяти DDR4 и двумя SSD дисками M.2 для размещения ОС или гипервизора.
Внутри на верхнем ярусе: сами GPU Nvidia A100, установленные в райзеры PCIe x16 4.0. Благодаря огромным пассивным радиаторам, занимают почти всё внутреннее пространство верхнего яруса.

8. Провокационный вопрос: на каких процессорах работает LLM?

Мы задали модели вопрос:

«На каких процессорах ты работаешь?» Модель честно ответила (перефразирую):

«Я выполняюсь на двух GPU NVIDIA A100, а CPU управляют вводом-выводом, планированием и prepost-обработкой. Мои матричные вычисления идут на Tensor Cores A100, CPU почти не участвуют в генерации.»

То есть центральные процессоры выступают в роли дирижёров оркестра из GPU. Это нормально для задачи LLM, поэтому можно было бы использовать менее производительные процессоры, или даже один.

9. Технологический суверенитет: при чём тут ИИ?

Нам задали уточняющий вопрос:

«Как решение на базе российского центрального процессора и open‑source LLM может обеспечить технологический суверенитет?»

Отвечаем: мы продемонстрировали суверенное программно-аппаратное решение, основанное на суверенной аппаратной платформе, построенной на отечественных процессорах, что гарантирует отсутствие закладок, «килл-переключателя» и т.д., а используемое ПО - модель DeepSeek-R1 относится к категории открытого ПО, веса можно проверить и даже до обучить на своих данных. Нет привязки к вендорам из недружественных стран.
Данное решение обеспечивает информационную безопасность компании, которая использует ИИ в своей деятельности - всё работает в изолированном контуре. Данные не уходят за пределы организации.

И да, мы не говорим, что уже полностью независимы от NVIDIA. Но мы делаем первый шаг: учимся запускать LLM на российском CPU + любых доступных GPU. В планах использование российских ускорителей, тем более что ранее мы уже успешно протестировали совместимость нашей серверной платформы с ускорителями компании «ХайТек» и сейчас проводим тестирование ускорителей еще одной российской компании.

10. А что дальше? Планы на Qwen3 и RAG

Текущая установка - тестовый прототип. В ближайших планах:

Развернуть Qwen3-72B (или даже 110B) - более мощную open‑модель.
Добавить RAG - прикрутить векторную базу данных (например, Qdrant или Chroma), чтобы модель отвечала на вопросы по нашей внутренней документации (технические описания, схемы, протоколы испытаний).
Увеличить контекст до 256k токенов - чтобы можно было загрузить целиком большой кусок кода или документ.
Перевести сервер в полностью изолированный контур (без доступа к внешней сети), закешировав все зависимости.

11. Отечественные LLM: что есть и что с ними не так?

Мы тоже смотрели в сторону российских моделей:

GigaChat (Сбер) - закрытая модель, для локальной установки требует коммерческой лицензии и специализированного железа.
YandexGPT - облачная модель, локальной версии нет.
Открытые разработки отдельных команд - часто отстают по качеству от DeepSeek- R1 или Llama-3-70B на бенчмарках.

Тем не менее, мы не против использовать отечественные open‑source модели, когда они достигнут сопоставимого уровня. Наше решение не привязано к конкретной модели - благодаря llama.cpp мы можем подставить любую модель в формате GGUF, хоть российскую, хоть китайскую, хоть американскую.

12. Наши компетенции: мы не только тестируем, но и внедряем

Развёртыванием данного решения занимался Сергей Шишкин, наш ведущий инженер отдела тестирования. Но у нас есть несколько команд, которые:

Разрабатывают серверы с нуля: начиная с разработки плат, корпусов, встроенного и прикладного ПО, и заканчивая постановкой на серийное производство и обеспечением поддержки наших продуктов. Это наше первое основное направление деятельности.
Разрабатывают, собирают и тестируют кластеры из десятков узлов, суперкомпьютеры в сотни узлов, в том числе, ориентированные на использование ИИ. В целом создают решения, ориентированные на ИИ, облачные нагрузки, большие данные, контейнеры и виртуализацию. Это наше второе направление, которое постепенно расширяется в сторону наращивания компетенций в развертывании и настройке кластерной сети (RoCE, InfiniBand) для многоузловых (часто распределенных) комплексов, настройке работы специфических приложений заказчика в среде контейнеризации, портировании (как совместно с производителем ПО, так и самостоятельно) прикладного ПО на архитектуру ARM64, в том числе AI-фреймворков, как в данном проекте.

13. Заключение: почему мы написали эту статью?

Мы не пытаемся удивить мир чем-то сверхновым. Мы просто показываем реальный рабочий прототип, где LLM с открытым кодом работает на отечественных процессорах с архитектурой ARM64 и двух NVIDIA Tesla A100. Мы задокументировали все грабли, и готовы помочь Вам, чтобы Вы не наступали на них, если решите повторить.

Спасибо, что прочитали и проявили интерес к нашей работе!

Мы будем рассказывать о новых интересных решениях по мере прохождения ими стадии прототипирования.

Видеоверсия этого кейса с Сергеем Шишкиным - скоро на наших каналах RUTUBE и VK Видео. Ссылки будут добавлены здесь и в описании.

Удачи в ваших AI-проектах!