Последние пару лет я много экспериментировал с LLM на разных железках от GPU-кластеров в облаке до маленьких Raspberry Pi. И вот одна из любимых задачек-провокаций: «А можно ли запустить модель на Pi 4, 5?» Если коротко: можно попробовать, но физика тут сильнее хайпа. У платы есть 8-16 ГБ памяти, у модели десятки гигабайт даже в самых «жестких» квантовках. В лоб это не работает, но зато эксперимент дает интересный результат: мы понимаем, где проходят границы устройства и какие архитектурные схемы реально полезны.

На мой взгляд, будущее не за гигантскими fine-tuned моделями, а за умными комбинациями из «малых» моделей, RAG и грамотной оркестрации. Fine-tuning остается инструментом для узкоспециализированн��х задач. В большинстве случаев куда выгоднее гибридная схема: данные хранятся и обрабатываются локально (например, на Raspberry Pi), а ресурсоемкая генерация передается в облако. Реализовал такой подход на инфраструктуре Cloud.ru Evolution: там живут большие LLM, а локальный Raspberry Pi выступает в роли приватного узла для индексации и предобработки данных. Этот гайд посвящен именно локальной части — превращению «малинки» в автономного AI-ассистента.

Ollama на Raspberry Pi: как превратить «малинку» в локального AI-ассистента

С помощью Ollama — open source решения — LLM можно запускать прямо на Raspberry Pi, без интернета и сторонних API. С Ollama Raspberry Pi превращается в локальный AI-движок для простых задач. Не ждите качества ChatGPT, но модели на 2-4 B параметров справляются с базовыми сценариями:

• ответы на фактические вопросы по заранее загруженным данным;

• генерация коротких текстов (до 200-300 токенов);

• извлечение информации из документов;

• простые агенты с четкой функциональностью, например, парсинг логов, форматирование данных.

Для сложных задач (длинная генерация, рассуждения, креатив) понадобятся модели 12 B+ — их на Pi запустить можно, но работать всё это будет мучительно медленно.

Процесс настройки:

1. Устанавливаем Ollama и WebUI.

2. Загружаем компактную модель (TinyLlama или Phi-3 Mini).

3. Подключаемся к веб-интерфейсу и тестируем возможности.

 Минимальные требования:

• Raspberry Pi 4 или 5;

• microSD от 32 ГБ;

• стабильный интернет для установки и загрузки модели.

Устанавливаем Ollama на Raspberry Pi

 Шаг 1. Открываем терминал

Стандартным способом — иконка с чёрным экраном или сочетание Ctrl + Alt + T.

 Шаг 2. Запускаем установку

Выполняем команду: curl -fsSL https://ollama.com/install.sh | sh

Она скачает необходимые пакеты и установит сервис.

 Шаг 3. Дожидаемся завершения

Как только в терминале снова появится приглашение (pi@raspberrypi:~$), малинка готова к следующему этапу — загрузке и запуску моделей. После установки у вас появляется сервис, который будет управлять LLM и к которому позже можно будет обращаться через команды или WebUI. 

Загрузка и запуск модели для Ollama

Чтобы Ollama выполняла запросы, ей нужна модель — файл весов. Без весов инференс невозможен. Команда ollama pull <model:tag> загружает в локальное хранилище конкретную модель (семейство, размер, вариант instruct, квантование). После загрузки модель запускают командой ollama run <model:tag> и работают с ней локально, без внешних API.

Список готовых моделей есть в библиотеке Ollama (ollama.com/library): выбираете тег и скачиваете веса командой ollama pull <model:tag>. Можно подключать модели не только из этой библиотеки, но и напрямую с Hugging Face. Для этого нужен формат весов GGUF (он совместим с llama.cpp и рассчитан на работу при дефиците памяти); модель подключают через файл Modelfile с ссылкой вида hf://…, после чего создают локальный образ и запускают его как обычную модель в Ollama. Квантование определяет, сколько памяти потребуется и какое качество вы получите. В общих чертах: варианты уровня q4_K_M дают минимальные требования к ОЗУ и подходят для слабых машин, q5-семейство требует больше памяти, но держит ответы стабильнее, а q8 даёт лучшее качество ценой заметно больших ресурсов. На Raspberry Pi 5 разумно начинать с моделей на 7B в квантовании q4_K_M (или, если есть запас по памяти, q5_K_S), ограничивать контекст до 2–4 тысяч токенов и не завышать параметры генерации. Такой набор позволит запустить локальный инференс без интернета и сторонних API и при этом не упираться в железо.

На скрине виден запуск команды: ollama run tinyllama. Это означает, что мы подтягиваем и запускаем модель TinyLlama.

Что именно скачивается:

●      pulling ... 100% — подтягиваются все необходимые части модели: сами веса (основной файл на сотни мегабайт) и вспомогательные метаданные (манифест, контрольные суммы, digest);

●      verifying sha256 digest — проверка целостности файла, чтобы убедиться, что модель не повредилась при загрузке;

●      writing manifest — запись описания модели, чтобы Ollama знал, как с ней работать.

 Для чего это всё:

1. TinyLlama — это компактная языковая модель, оптимизированная для работы на устройствах с ограниченными ресурсами, как Raspberry Pi.

2. С ее помощью можно протестировать Ollama: задать вопрос, сгенерировать текст, проверить скорость и отклик.

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

Результат

После загрузки можно общаться с моделью. В примере:>>> write a short funny poem about racoon.

Модель отвечает коротким стихом про енота. Значит всё работает: от скачивания весов до генерации текста.

Поднимаем Docker и WebUI

После установки Ollama можно продолжить работу из терминала, и этого достаточно для базовых сценариев. Если удобнее графика и настройки в пару кликов, используйте Open WebUI в Docker — это альтернатива, а не обязательный следующий шаг.

Два варианта работы:

• CLI-вариант (по умолчанию): ollama pull/run, запросы через API или терминал.

• GUI-вариант (альтернативный): разворачиваем Open WebUI в контейнере и подключаем его к локальной Ollama.

Рекомендуется начать с CLI, убедиться, что модель отвечает стабильно, и только затем при необходимости перейти к WebUI.

Шаг 1. Устанавливаем Docker

Docker здесь нужен как «контейнерный движок»: он будет запускать WebUI в изолированной среде, чтобы не ломать систему. Всё делается одной строкой:

sudo apt install docker.io

Ждем завершения. Индикаторов прогресса тут мало, но как только терминал вернул приглашение (pi@raspberrypi:~$), установка закончилась.

 Шаг 2. Запускаем WebUI в контейнере

Теперь запускаем сам интерфейс:

sudo docker run -d -p 3000:8080 -v ollama:/root/.ollama -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:ollama

Чтобы упростить доступ для локального использования, добавьте флаг -e WEBUI_AUTH=False. Это отключит экран аутентификации (регистрацию и логин), что идеально для single-user сценария на Raspberry Pi. Но будьте осторожны: без аутентификации интерфейс открыт для всех в сети — используйте только в безопасной среде. Если база данных не свежая (уже есть пользователи), флаг может не сработать. В таком случае удалите volume и перезапустите.

docker run -d -p 3000:8080 -e WEBUI_AUTH=False -v ollama:/root/.ollama -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:ollama

Как правильно развернуть Ollama и Open WebUI

Команда из примера поднимает Open WebUI со встроенной Ollama внутри контейнера. Если на хосте у вас уже установлена системная Ollama, получится две независимые инстанции: контейнерная и хостовая. Они не связаны между собой и по умолчанию используют разные кэши.

Есть два понятных подхода.

Подход 1. Одна Ollama в системе, WebUI — в контейнере

Ollama ставится на хост, дает CLI и локальный API (порт 11434). Контейнер с Open WebUI работает как интерфейс и ходит в хостовую Ollama по URL, который вы явно указываете в переменной окружения. Плюс этого способа — единый кэш моделей и одна «точка правды». Минус — нужно корректно пробросить доступ из контейнера к порту хоста. На Linux может понадобиться добавить в docker run резолвинг host.docker.internal или указать IP хоста.

Подход 2. Всё внутри контейнера (Open WebUI + встроенная Ollama)

Контейнер содержит и интерфейс, и Ollama. Это изолированная установка с собственным кэшем в /root/.ollama (обычно монтируется в именованный том). Такой вариант удобен для быстрого старта и полной изоляции окружения. Если на хосте уже скачаны модели, они не используются автоматически, потому что кэш другой. При желании можно смонтировать хостовую папку ~/.ollama в контейнер, чтобы разделить кэш - это простой и эффективный шаг, который проще настройки связи между отдельными компонентами, например, через API или порты.

Коротко: выбирайте один из вариантов и придерживайтесь его. Если важна простота и единый кэш — ставьте Ollama на хост и подключайте к ней WebUI. Если нужна изоляция «всё в одном» — используйте образ со встроенной Ollama и храните кэш в томе или монтируйте существующий кэш для экономии места и времени.

Пример монтирования кэша в команде запуска контейнера (добавьте флаг -v):

docker run -d -p 3000:8080 -e WEBUI_AUTH=False -v /home/pi/.ollama:/root/.ollama -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:ollama

Это позволит контейнеру использовать модели с хоста без повторной загрузки, упростив управление.

Что происходит на этом этапе:

• d — контейнер работает в фоне

• p 3000:8080 — пробрасываем порт 8080 контейнера на порт 3000 Raspberry Pi

• v ... — подключаем тома, чтобы данные не потерялись при перезапуске

• -restart always — контейнер будет подниматься автоматически после перезагрузки.

Проверяем контейнеры Docker и ловим «unhealthy»

После запуска WebUI вроде всё было красиво: команда отработала, терминал вернулся, и я уже готов был открывать браузер на http://localhost:3000. Но захотелось проверить, а что там творится внутри Docker.

 Запускаю: sudo docker ps -a

И тут классика: контейнер вроде работает, но статус гордо пишет unhealthy.

Что показала команда:

• CONTAINER ID — уникальный идентификатор контейнера.

• IMAGE — образ, из которого он сделан (ghcr.io/open-webui/open-webui:ollama).

• COMMAND — стартовый скрипт внутри (bash start.sh).

• CREATED и STATUS — время жизни контейнера и его текущее состояние. У меня он живёт пару минут, но уже «нездоров».

• PORTS — видно, что порт проброшен на 3000, значит снаружи к нему реально постучаться.

• NAMES — название контейнера, по которому его удобно идентифицировать (open-webui). 

Почему так бывает

Docker сам проверяет «здоровье» контейнера через healthcheck. Если внутри сервис не отвечает так, как ожидается (например, WebUI не успел стартовать или споткнулся на настройках), то он вешает ярлык unhealthy. 

Как я решил проблему (и почему теперь знаю, где живут модели)

После танцев с Docker и статуса unhealthy я пошел глубже. Подумал: «А может, дело вообще в данных? Где Ollama и WebUI хранят свои файлы?»

Запускаю: sudo docker volume inspect ollama open-webui

И вот тут пазл сложился.

Что показывает вывод:

• CreatedAt — когда именно создался том. Удобно, если забыли, когда поднимали сервис.

• Driver: local — значит, всё хранится прямо на диске Raspberry Pi.

• Mountpoint: "/var/lib/docker/volumes/ollama/_data" — фактическая папка, где лежат модели и кэш.

 То же самое для open-webui: там уже база пользователей и настройки интерфейса.

Зачем это нужно

1. Во-первых, теперь я знаю, что модели Ollama физически лежат тут: /var/lib/docker/volumes/ollama/_data.

Путь к весам зависит от способа установки.

Вариант A: запуск в Docker
Модели хранятся в томе Docker. Если использован именованный том ollama, фактический путь будет:
/var/lib/docker/volumes/ollama/_data

Вариант B: нативная установка (install.sh)
Модели располагаются в:
/usr/share/ollama/.ollama/models

Чтобы не путать читателя и команды, в этой статье дальше я использую один выбранный вариант и придерживаюсь его по всему тексту. Если вы разворачиваете иначе, просто скорректируйте путь к моделям.

Полезно знать: путь можно переопределить переменной окружения OLLAMA_MODELS. Это пригодится, если нужно хранить веса на отдельном диске. Проверить активный путь можно по конфигурации сервиса или параметрам запуска.

2. Во-вторых, это отличный способ понять, не «сломался» ли контейнер из-за отсутствия или повреждения файлов.

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

Если вдруг захочется реально заглянуть внутрь, говорят, можно сделать так:

ls -lh /var/lib/docker/volumes/ollama/_data — и сразу увидеть, какие модели там лежат. 

НО! Лучше не смотреть содержимое тома или системной папки напрямую. Проще и безопаснее узнать установленные модели штатными командами. Введите ollama list, чтобы увидеть список моделей, и ollama show <model:tag>, чтобы посмотреть размер и теги. 

Если Ollama запущена в контейнере, можно выполнить docker exec -it <имя_контейнера> ollama list. Когда нужен только путь к данным, запросите его командой docker volume inspect ollama и возьмите значение поля Mountpoint. Для нативной установки модели по умолчанию лежат в /usr/share/ollama/.ollama/models, путь можно переопределить переменной окружения OLLAMA_MODELS. Редактировать файлы в этих каталогах вручную не стоит.

4. А если чувствуете в себе дух исследователя, то есть ещё один прием:

sudo docker run --rm -it -v ollama:/data ubuntu bash

После этого можно походить по папке /data внутри контейнера.

Сильное заявление, но проверять я его, честно говоря, не стал. Просто оставлю это здесь, а вдруг кому пригодится. У меня все заработало, и я успокоился.

Открываем интерфейс WebUI

И вот он, момент истины. Я вбиваю в браузер: https://localhost:3000/.

И вот он, момент истины. Открываю в браузере: http://localhost:3000/ — по умолчанию интерфейс доступен по HTTP. Если запускали Python-вариант или контейнер с --network=host, заходите на http://localhost:8080/.

и… — интерфейс WebUI открылся!

Малинка подняла AI-ассистента с веб-панелью. Внутри — привычный интерфейс: поле для ввода запроса, история сообщений, настройки модели. 

Создаем аккаунт в Open WebUI

После установки и запуска интерфейса в браузере вас встречает форма регистрации. Тут без сюрпризов: классическая страница «Name, Email, Password». Опционально, вы можете упростить процесс, добавив флаг -e WEBUI_AUTH=False при запуске контейнера. Это отключит экран регистрации, и интерфейс станет доступен сразу без аккаунта. Но лучше этого не делать: без аутентификации любой в вашей локальной сети (или даже из интернета, если порт открыт) сможет получить доступ к WebUI, что создаёт серьёзные риски безопасности. Ваши модели, данные и запросы станут уязвимыми для несанкционированного использования или атак. Для домашнего или тестового сценария на изолированном Pi это приемлемо, но в общем случае оставьте auth включённым, чтобы защитить систему.

Что заполняем:

• Name — любое имя. Можно свое, можно «Lord of Raspberry Pi». Главное, потом не забыть, что это ваш профиль.

• Email — можно ввести любой рабочий адрес. WebUI не шлет «письма счастья» или подтверждения, так что можно даже написать тестовый pi@local.test.

• Password — ну, тут как обычно: не «1234» и не «qwerty».

Как это работает

WebUI создает локального пользователя в своей базе (тот самый том open-webui). Это нужно, чтобы:

1. Настройки и история диалогов сохранялись.

2. Можно было зайти под своим логином, если интерфейс используют несколько человек (например, коллеги делят одну малинку).

Выбираем модель в WebUI

 После регистрации нас встречает пустой экран WebUI и приветственное Hello, Maksim. Возникает вопрос: «А где же сам AI?» Секрет в выпадающем списке Select a model в верхней части экрана. Именно здесь подключаются те модели, которые вы скачали через Ollama.

Что делаем на этом этапе:

1. Жмем на Select a model.

2. В поиске вводим название нужной модели например, gemma2:2b или phi-4:mini. Это компактные варианты на 2–4B параметров, актуальные на 2025 год; они легче и быстрее старых версий вроде tinyllama или phi-3, но всё равно подходят для старта на Raspberry Pi 5.

3. Если модель есть в системе, она появится в списке и станет доступна для запуска.

4. Дальше можно выбрать ее и начать общение.

Почему это важно

WebUI сам по себе — «пустая оболочка». Без выбранной модели он не знает, чем именно отвечать на запросы. Как только мы подключаем модель, интерфейс превращается в привычный чат: пишем вопрос → получаем ответ.

Скачиваем модель через WebUI

После того как интерфейс открылся и мы научились выбирать модель из списка, наступает следующий этап загрузки самой модели. WebUI тут же начинает процесс Downloading.

Что тут происходит:

• llava — это название модели (в данном случае мультимодальной, которая умеет работать и с картинками, и с текстом)

• :latest — это тег по умолчанию для конкретной модели, который задает автор сборки. Он не означает «самую свежую версию вообще». Обычно latest указывает на рекомендованную конфигурацию (размер и квантование, часто что-то вроде q4_K_M для 7B), с которой модель считается наиболее практичной. Если нужен другой размер или квант, указывайте тег явно, например, name:7b-instruct-q5_K_S. Посмотреть доступные теги и параметры можно командой ollama show name. Команды ollama pull name и ollama pull name:latest эквивалентны: обе подтянут дефолтный вариант, выбранный автором.

Интерфейс подтягивает нужные файлы с сервера Ollama, а в логах на фоне мелькают строки вида pulling manifest.

Работа с изображениями в WebUI

В интерфейсе появляется возможность выбора:

• Capture — сделать снимок с камеры (если она подключена к Raspberry Pi).

• Upload Files — загрузить картинку с диска.

 Я выбрал второй вариант: проще и надежнее.

Что это дало

Поддержка изображений открывает новый сценарий: можно попросить модель описать фото, распознать текст на картинке или «переосмыслить» картинку в шуточном ключе. Raspberry Pi превращается в карманный мультимодальный ассистент. 

Навигация к нужной папке с фото

Когда в WebUI выбираем Upload Files, открывается стандартный файловый менеджер Raspberry Pi. Тут важно не потеряться: система предлагает разные «быстрые места» (Home, Documents, Downloads и т. д.), но нужные картинки могут лежать в другом каталоге.

Как искать

1. В меню слева кликаем на Other Locations:

2. Переходим в системные папки. В моем случае изображения оказались по пути: /usr/share/rpd-wallpaper. Это стандартная директория Raspberry Pi, где лежат обои рабочего стола.

Что внутри

В ней несколько тестовых картинок: aurora.jpg, balloon.jpg, bridge.jpg, canyon.jpg и т. д., как раз удобный набор, чтобы проверить, как модель работает с изображениями. 

Первое общение модели с изображением

Мы выбрали модель llava:latest, загрузили в WebUI фото (на скрине — пейзаж с каньоном), и рядом появилась кнопка describe a picture.

Что происходит внутри:

1. WebUI отправляет картинку в модель.

2. LLaVA (Large Language and Vision Assistant) распознаёт ключевые объекты и контекст.

3. Когда мы нажимаем на describe a picture, модель описывает картинку словами.

Что это дает

Теперь Raspberry Pi — полноценный мультимодальный ассистент. Хотите, чтобы он описал фото с камеры? Или объяснил, что на скрине? Легко.

Выводы

Raspberry Pi 4/5 может тянуть LLM, но чудес ждать не стоит. Малинка не превратится в сервер с A100, зато станет отличной песочницей для экспериментов, локальных демо и ощущения «у меня свой ChatGPT дома».

Какие модели реально работают на Pi 5

• TinyLlama (~1B параметров). Очень лёгкая (меньше 1 ГБ на диске в q4), отвечает быстро, удобна для smoke-тестов и служебных задач.
  Пример: ollama pull tinyllama:<instruct-q4_K_M>

• Phi-3 Mini (~3–4B). Существенно качественнее TinyLlama, при этом остаётся юзабельной на Pi 5 в q4. Хороший компромисс для простых ассистентов и RAG-ответов.
  Пример: ollama pull phi3:<mini-instruct-q4_K_M>

• Mistral 7B. На Pi 5 — режим «на грани»: требуется активное охлаждение, умеренный контекст (2–4k), аккуратные настройки генерации. В q4 даёт достойное качество для коротких ответов и кода с проверкой.
  Пример: ollama pull mistral:<7b-instruct-q4_K_M>

• LLaVA 7B (мультимодальная). Понимает изображения, но заметно тяжелее по памяти и медленнее. Запускается, если есть запас ОЗУ и охлаждение; разумнее ограничивать размер картинок и контекст.
  Пример: ollama pull llava:<7b-…-q4_K_M>

Что еще заметил:

• Все примеры подразумевают квантование q4_K_M. Если есть запас по памяти, можно попробовать q5_K_S/M для большей стабильности

• Для каждой модели выбирайте instruct-вариант и проверяйте точный тег в ollama show <name> или в библиотеке (ollama.com/library)

• На Pi 5 держите контекст 2-4k токенов, снижайте temperature, и следите за температурой CPU

Работает ощутимо медленнее, но работает. Честно: на Pi 4 использовать что-то больше TinyLlama — уже мазохизм. На Pi 5 жить можно, особенно если вы ставите «облегчённые» версии (quantized модели).

Производительность (Raspberry Pi 5, 8 ГБ, 64-бит, активное охлаждение, CPU-инференс, квант q4_K_M)

Диапазоны зависят от длины подсказки/ответа, настроек (temperature, top_p), частоты CPU и охлаждения. Для q5 ожидайте чуть ниже TPS и выше TTFT; для q8 — ещё медленнее, но стабильнее по качеству.

Если хочется больше мощности, можно комбинировать Raspberry Pi как «фронт» с легкой моделью, а Cloud.ru или другое облако, как «бэк» с тяжелой LLM.

Полезные ресурсы:

1. Библиотека моделей Ollama.

2. GitHub Open WebUI.

3. Cloud.ru для тяжелых моделей и гибридных сценариев.

Итог

Да, Raspberry Pi — не серверная ферма, но отличная платформа для экспериментов с локальными LLM. Вот ключевые выводы:

• Маленькие модели (2-4B, например, Gemma2-2B, Qwen2.5-3B, Phi-3.5 Mini). Работают гладко в q4_K_M, TTFT <1 сек, TPS 8-15 ток/сек — идеально для базовых ассистентов, кода и RAG. Подойдет для повседневных тестов.

• Средние (3-7B, например, Llama3.2-B, Mistral-7B, LLaVA-7B). Терпимы с активным охлаждением и контекстом 2-4k токенов (TTFT 1-3 сек, TPS 2-6 ток/сек), но подходят только для демо. Добавьте overclocking для +20-30% скорости.

• Большие (>7B). Оставьте облаку или внешнему GPU. Pi 5 упрется в память и перегрев.

• Для оптимизации: следите за CPU-температурой (<80°C), используйте streaming для ощущения скорости и комбинируйте с облаком для тяжелых задач. В 2025 году это не только хобби, но и шаг к edge-AI в IoT-проектах.

А вот компактное резюме без повтора мысли, с техническими порогами для Pi 5 (q4_K_M, CPU, активное охлаждение):

• До 4B параметров (TinyLlama, Phi-3 Mini): интерактивная работа — ориентир TTFT < 1 c, TPS ≥ 8-10 ток/с. Подходит для ассистентов и RAG.

• 7B (Mistral q4_K_M): прототипы «на грани» — TTFT ~ 1-3 c, TPS ~ 2-6 ток/с, нужен короткий контекст (2-4k) и хорошее охлаждение.

• Мультимода 7B (LLaVA): ощутимая латентность из-за обработки изображений — TTFT ~ 2-6 c, TPS ~ 1-3 ток/с. Рассматривать как демо.

• Больше 7B: для Pi 5 практически нецелесообразно — переносите инференс «снаружи» (удаленный сервис), а локально оставляйте поиск/индексацию.

В сухом остатке: получаем компактную локальную лабораторию для LLM. Можно экспериментировать, показывать друзьям, писать статьи на Хабр и гордо говорить: «У меня GPT на малинке, а у тебя?»