Мы в лаборатории «Синнтерком» собираем ИИ-решения на локальном железе — таком, где данные не покидают периметр заказчика. Когда к нам приехала Repka Pi 5, мы поставили себе простую цель: к вечеру плата должна отвечать на вопросы языковой моделью, причём на встроенном нейропроцессоре, а не только на CPU. Получилось. Рассказываем, как повторить, и показываем честные цифры.
Что за железо #
Repka Pi 5 — российская плата на Rockchip RK3588: четыре ядра Cortex-A76 (2,26 ГГц у нашего образца) плюс четыре A55, у нас версия с 16 ГБ памяти и модулем eMMC на 64 ГБ. Внутри чипа — NPU на 6 TOPS (INT8), три вычислительных ядра. Форм-фактор Raspberry Pi 5, вес — 58 граммов вместе со штатным радиатором: мы взвесили сами, плата встанет в шкаф автоматики, терминал или корпус станка.
Приятная неожиданность: в вендорном ядре Repka OS (6.1.115) уже стоит драйвер нейропроцессора RKNPU v0.9.8 — ровно тот, что нужен рантаймам Rockchip. Ничего пересобирать не пришлось.
Путь: три шага #
Шаг 1 — проверить NPU. Берём librknnrt (рантайм RKNN 2.3.2 из открытого SDK Rockchip) и любую rknn-модель, запускаем rknn_benchmark. У нас тестовая модель отработала со средним временем 771 мс на прогон — на несколько процентов быстрее, чем тот же тест на другой плате с RK3588, которая была под рукой. Драйвер из коробки совместим — можно жить.
Шаг 2 — языковая модель на NPU. Для LLM у Rockchip отдельный стек — RKLLM. Ставим рантайм (мы работали с SDK 1.3.0), берём готовую сборку модели под RK3588 — мы использовали Qwen3.5-4B в 8-битном квантовании W8A8 (файл ~5,6 ГБ, на eMMC помещается свободно) — и поднимаем сервер с OpenAI-совместимым API из примеров SDK. Всё завелось без единой правки под Repka OS.
Шаг 3 — тот же вопрос на CPU. Для сравнения ставим Ollama (llama.cpp) с той же моделью в 8 битах.
СОВЕТ
На big.LITTLE ограничьте генерацию четырьмя потоками: на восьми быстрые A76 ждут медленные A55, и скорость заметно падает. В Ollama это строка PARAMETER num_thread 4 в Modelfile.
Цифры #
Все замеры — штатный радиатор, без обдува, комнатная температура:
| Конфигурация | Скорость |
|---|---|
| NPU, Qwen3.5-4B W8A8 | 4,5 токена/с, 30 генераций подряд без деградации |
| CPU, та же модель в 8 битах | 4,8 токена/с (контрольный RK3588-стенд рядом — 4,5) |
| CPU, модель 9 млрд параметров, 4 бита | 3,7 токена/с — плата тянет и такой класс |
К СВЕДЕНИЮ
Почему процессор и NPU идут вровень? Генерация текста упирается не в вычислительную мощность (TOPS), а в скорость чтения весов из памяти — а память у CPU и NPU здесь общая, поэтому оба стека приходят примерно к одному потолку: 4,5 против 4,8 токена в секунду. Разница не в скорости, а в цене: NPU-вариант оставляет процессор свободным под остальную работу и греет плату заметно меньше — под длинной нагрузкой с вентилятором полка 59 °C против 79 °C у процессорного варианта. Для встраиваемых задач это обычно важнее лишних процентов скорости.
Про тепло скажем честно: под длинной непрерывной генерацией SoC выходит на ~84 °C — производительность не падает, но запаса немного. На плате есть штатный разъём вентилятора; для круглосуточных ИИ-сценариев рекомендуем им воспользоваться.
Что это значит на практике #
Плата размером с банковскую карту за день превращается в автономного ИИ-ассистента: отвечает по документам, без интернета и без передачи данных наружу. Для задач, где важен реестр Минпромторга, у Repka уже есть зарегистрированные модели, и производитель говорит, что Pi 5 на подходе.
Проверить всё написанное можно вживую: Repka Pi 5 стоит первой в каталоге стендов нашей открытой лаборатории — lab.synntes.com. Задайте ей вопрос сами и посмотрите на скорость, нагрев и загрузку в реальном времени: мы показываем работу железа как есть, без рекламных цифр.
Источники и сборки #
Всё, что мы использовали, открыто:
- rknn-llm — стек Rockchip для языковых моделей на NPU: рантайм, примеры серверов, конвертер;
- rknn-toolkit2 — рантайм librknnrt и rknn_benchmark для проверки NPU;
- Qengineering/Qwen3.5-4B-rk3588 — готовая сборка модели под RK3588, конвертировать самому не пришлось;
- Ollama — CPU-вариант через llama.cpp;
- repka-pi.ru — Repka OS и документация платы.
Приложение: поднять NPU-вариант за десять команд #
Проверено на Repka OS v1.0.4 (ядро 6.1.115, драйвер RKNPU v0.9.8 уже в системе). Понадобится ~6 ГБ свободного места.
# 1. Рантайм RKLLM из открытого SDK
git clone --depth 1 https://github.com/airockchip/rknn-llm
sudo cp rknn-llm/rkllm-runtime/Linux/librkllm_api/aarch64/librkllmrt.so /usr/lib/
# 2. Готовая сборка модели под RK3588 (~5,6 ГБ)
pip3 install -U "huggingface_hub[cli]"
hf download Qengineering/Qwen3.5-4B-rk3588 \
qwen3.5-4b_w8a8_rk3588.rkllm --local-dir ~/models
# 3. Сервер с OpenAI-совместимым API — из примеров SDK
cd rknn-llm/examples/rkllm_server_demo
pip3 install flask
python3 flask_server.py \
--rkllm_model_path ~/models/qwen3.5-4b_w8a8_rk3588.rkllm \
--target_platform rk3588
# 4. Первый вопрос (из соседнего терминала)
curl http://127.0.0.1:8080/rkllm_chat \
-H "Content-Type: application/json" \
-d '{"model":"qwen3.5-4b","messages":[{"role":"user","content":"Привет! Кто ты?"}],"stream":false}'
CPU-вариант ещё короче: curl -fsSL https://ollama.com/install.sh | sh, затем ollama run qwen3.5:4b-q8_0 (и не забудьте совет про четыре потока выше).
Нагрузку на NPU по ходу генерации видно в /sys/kernel/debug/rknpu/load, температуру — в /sys/class/thermal/thermal_zone0/temp.
Статья подготовлена лабораторией ИИ ООО «Синнтерком» (Пермь, lab.synntes.com). Плату предоставила команда Repka Pi.
А сколько он рам-памяти отъедает?
Могу предположить что всю)
Как минимум swap надо отключать и всю модель в оперативку грузить и тогда скорость будет хоть куда не шло.
Ну это я про qwen на ollama говорю.
Хороший вопрос — ответим замером с той самой платы, а не прикидкой.
NPU-вариант: сам процесс сервера занимает около 0,2 ГБ, а веса модели (файл 5,6 ГБ) он подключает отображением в память — система держит их в файловом кэше. Итого счёт за модель — примерно 6 ГБ, на 16-гигабайтной версии платы свободными остаются ещё ~10.
Про «отъест всю» — вышло наоборот и даже нагляднее: прямо сейчас на этой же плате рядом с 4-миллиардной моделью на NPU работает воркер распределённой 30-миллиардной модели (8,8 ГБ) и пара служебных сервисов — и всё вместе живёт в 16 ГБ без борьбы.
Swap отключать не пришлось: он на плате есть (1 ГБ), но горячий путь генерации — чтение весов — идёт из кэша, и на 30 генерациях подряд деградации скорости мы не увидели (цифра из статьи). В своп уезжает только холодная обвязка сервера. С Ollama на CPU механика та же: llama.cpp тоже отображает файл модели в память, так что потребность ≈ размер файла плюс кэш контекста, а не «вся память».
Для 8-гигабайтной версии платы честная рекомендация: 4-миллиардная модель в 8 битах поместится, но впритык — лучше 4-битное квантование или версия платы на 16 ГБ.
А проверить можно вживую, не веря нам на слово: https://lab.synntes.com/module/chat — выберите стенд Repka Pi 5, задайте вопрос и смотрите на пульс железа прямо на кнопке: память, температура, скорость.
Спасибо! А почему именно qwen выбран, а не gemma 4 e2b, например?
Спасибо за вопрос! Причины три, и все прозаичные.
Первая — путь «за один день»: у Qwen3.5-4B есть готовая, проверенная сообществом сборка W8A8 под RK3588 (Qengineering, ссылка в статье) — скачал и запустил. Конверсия своей модели через rkllm-toolkit — отдельное приключение со своими граблями, для статьи про «от коробки до вечера» оно лишнее.
Вторая — сравнимость: у нас в лаборатории одна линейка моделей на всех стендах и контурах, чтобы разница железа была видна на одном и том же вопросе. Появляется новая плата — спрашиваем её о том же, о чём остальных.
Третья — gemma мы вовсе не отвергли: она работает у нас на этой же витрине, причём именно как «другое мнение». В модуле «Консилиум» ответ проверяет каскад из разных моделей: пара qwen-4B на NPU + gemma4 на CPU, а при их споре подключается третья, на отдельном сервере. Для такой схемы вторая модель обязана быть другой линейки — иначе она соглашается с первой чаще, чем должна. Посмотреть можно тут: https://lab.synntes.com/module/consilium
До NPU-сборки gemma 4 E2B мы пока не добрались — если у вас есть опыт её конверсии под RKLLM, с интересом почитаем.