Выкананне агента Hermes локальна ў Rootless Podman з Ollama на GPU AMD

Выкорыстанне агента AI для працы з местнымі зьвіздкамі Markdown і Obsidian здаецца простым, пакуль не выйдзе пытанне ад доступу. Агент Hermes ад Nous Research можа выкананыць каманды тэрміналу, рэдагаваць файлы, выкананыць код і запускаць іншыя інструменты. Якім б не быў модэль, якому паведамляецца працаваць толькі з аднай папкай, гэта не стварае межы безпекі, адколі інструкцыя — гэта проста тэкст. У сабеўной дакументацыі Hermes таксама зазначаецца, што настройка HERMES_WRITE_SAFE_ROOT захоўвае звычныя інструменты рэдагавання файлоў, але інструменты тэрміналу все равно можу дацягнуцца да усяго, да чаго можа дацягнуцца акаунт операцыйнай сістэмы, на якой працюе Hermes.

У паказанай выкладцы Hermes знаходзіцца ўнутрь rootless Podman, палягаючы рыхтоўкаў з серверам Ollama, які запускае локальную мадэль на GPU AMD. Hermes можа рэдагаваць толькі адну папку, якая спецыяльна монтуўцца. Рэшта файлавой сістэмы хоста проста не існуе ў пространі імен кантэйнера, таму ён не можа туда даступіць. Hermes офіцыйна падтрымлівае працу ў кантэйнерэ, зберагае стацыонарны стан пад /opt/data і работае з самастаянымі серверамі інферэнціі, такімі як Ollama, праз канцэнтры, сумэнныя з OpenAI.

Этапы нараджэння былі адрабоўваны на EndeavourOS, пахоўдзеце Arch. Команды з інсталяцыі пакетаў трэба прыстосаваць да іншых дыстрыбуцыяў.

Інсталяцыя rootless Podman

На Arch або EndeavourOS інсталюйце Podman за дапамойкай Pacman:

sudo pacman -Syu podman

Pacman можа запытаць, які рантайм OCI выкорыстаць, пропонуючы тры наступныя варыянты:

1) crun
2) krun
3) runc

Выбор, які быў зроблены тут, ёсць першы:

1

Этот рантайм — crun. Гэта практычна пазней, калі функцыя Podman «keep-groups», якая перадае дадатковыя групы хоста ў кантэйнер без корня, працюе з crun.

Паказваючы версію і запытаўшы Podman, які рантайм ён вікорыстоўвае, паўтарыце установку:

podman --version
podman info --format '{{.Host.OCIRuntime.Name}}'

Другій командзе трэба адпаведзець назвай працоўнага часу:

crun

Контэйнеры без корневага таксама патрабуюць падпарадных каратаўванняў UID і GID для карыстальніка, таму пераканайцеся, што такі елементы існуюць у обох файлах:

grep "^$USER:" /etc/subuid
grep "^$USER:" /etc/subgid

З даўэйшчы кожны каманды Podman трэба выкананы як звычайным пользоватэлям. Не падставляйце ў пачатак іх слова sudo.

Рэмонт rootless OverlayFS калі гэта неабходна

Першая праба запуску адпаведнага абразу на гэтым апараце зазнала неудачы з спамою пра тое, што ядро не падтрымвае функцыю overlay на файлавай сістэме ext:

kernel does not support overlay fs:
'overlay' is not supported over extfs

Калі гэта адбудзецца, установіце рэалізацыю ў прасторэ карыстальніка:

sudo pacman -S fuse-overlayfs

Podman рэкамендуе fuse-overlayfs для настройкаў без root, калі стандартны overlay недаступны, і яго можна явна вызначыць як програму для маунтавання без root. Пераканайцеся, што ён установлена:

which fuse-overlayfs

Апэктываны шлях ёсць:

/usr/bin/fuse-overlayfs

Канфігурацыя знаходзіцца ў файле для кожнага карыстальніка:

~/.config/containers/storage.conf

Калі ён ужэ існуе, выконайце яго рэдагаванне заместа слепага замены. У раздэле зберагчыка трэба выбраць драйвер для аверкана:

[storage]
driver = "overlay"

І другы раздзел павінен называць програму для падключэння:

[storage.options.overlay]
mount_program = "/usr/bin/fuse-overlayfs"

Пасля тага пераканацецеся ў эфектывах настройках, фільтруючы выходныя даны дыбагавання Podman:

podman info --debug | grep -Ei 'graphDriverName|mount_program|overlay'

Перакладчык дадзеных на большыя дрыўы

Для гэтага праекту гэты крок стаў неабходным практычна адразу. Лялька Ollama сама по сабе займае калькі гігабайтаў, а мадэлі часта дадаюць ўсё ў тым жа дыяпазоне 5–20 ГБ або нават больш, калі ж Podman таксама вікорыстоўвае тымчасовы прастор на дыску пад час завантажэння і распаковкі шароў. Першая спроба завантажыць Ollama ў канцэ настаўлялася з паведамленнем пра тое, што на паце пад тымчасовым каталогам не застало прастору:

write /var/tmp/container_images_storage...:
no space left on device

У задачы задзейнаюць два адзельныя месца, якія лёгкая працяя заўярнуць. Пастаячая безкорэневая схованка для адпраўк, контэйнероў і тымпаў зазвычай знаходзіцца пад дырэктарыем домашней папкі:

$HOME/.local/share/containers/storage

З’явілія шары, тым часам, тымчасова зберагаюцца ў:

/var/tmp

Змена параметра --tmpdir у Podman не перамешчае катэгорыяў для завантажэння. У дасведчэннях Podman саветуецца замест таго выкарыстоўваць зменную сераўыска TMPDIR.

Калі ёсць большы локальны файлавы сістэм, створыце структуру, у якой будзе адна катэгорыя для зберагачэння і адна — для тымчасовых файлаў:

/path/to/large-drive/podman/
├── storage/
└── tmp/

Створыце якіясь элементы і перадаце права ўласнасці нынешнему карыстальніка:

sudo mkdir -p /path/to/large-drive/podman/storage
sudo mkdir -p /path/to/large-drive/podman/tmp
sudo chown -R "$USER:$USER" /path/to/large-drive/podman

Потым адаптуйце настройкі хранення, каб ўсё можна было зменіць:

mkdir -p ~/.config/containers
nano ~/.config/containers/storage.conf

Накірматыце корань графіка на новы катэгарыф зберагача, заўсёды застаўляючы драйвер наслаення:

[storage]
driver = "overlay"
graphroot = "/path/to/large-drive/podman/storage"

І застаўце настройкі програмы монтавання fuse-overlayfs:

[storage.options.overlay]
mount_program = "/usr/bin/fuse-overlayfs"

Выберыце местную сістэму файлаў для гэтага. У дасягледах Podman паведамляецца, што NFS і іншы сетавыя сістэмы файлаў паставляюць некорэктную працę як сховішча для кантэйнераў без прав root.

Тэмпарарныя файлы, якія былі завантажаны, таксама трэба пераместыць, таму задаце TMPDIR для чырговага шэлу:

export TMPDIR=/path/to/large-drive/podman/tmp

Ён будзе стацыонарным у Bash, калі яго дадаць у прафіле і перзагрузіць:

echo 'export TMPDIR=/path/to/large-drive/podman/tmp' >> ~/.bashrc
source ~/.bashrc

Пераканаўце новыя месцазнаходжэнні прытым, як што будзе выкарыстоўванаць з старага. Аддрукуйце корань графа і фільтруйце выходныя даны дыбагу для тэмпарарыянага каталогу і прыстаўкі программы:

podman info --format 'GraphRoot: {{.Store.GraphRoot}}'
podman info --debug | grep -Ei 'graphRoot|imageCopyTmpDir|mount_program'

Толькі пасля настаўлення новага Podman і толькі тады, калі новы корань графа абавесна правільны, можна расследзіць можлівасць выдалення застарэлага сховішча, якое знаходзіцца ў старым месцы:

~/.local/share/containers/storage

Не робіце гэта ляхоўна на існуючай установцы. Гэта таксама прычына, чаму месца зберагача павінна быць выбрана раней, чым ствараецца том модэля Ollama.

Адна папка для Hermes, два тома для стану

Выберыце адны катэгарычны катэкор дырэктарыя, да якога можа з’явіцца Hermes, і зробіце гэта свядома. Экспортуйце яго шлях у зменную і створыце папку:

export HERMES_WORKSPACE="$HOME/path/to/Hermes-Workspace"
mkdir -p "$HERMES_WORKSPACE"

У Obsidian хорашым выборам являецца адзін спецыяльны папка ўнутрь храніцы, напрыклад, каталог для даследавання, які знаходзіцца празаўсёды з персональнымі і рабочымі папкамі:

Obsidian Vault/
├── Personal/
├── Work/
├── Research/
└── Agent Workspace/       ← only this folder is exposed

Усе іншае ў сховішчы застаецца невідным для агента.

Далей створыце два томы, якімі сам Подман керуе:

podman volume create hermes-data
podman volume create ollama-models

Першы выконвы калічуе настройкі, памяць і стан Hermes. Другі выконвы калічуе локальную мадэль. Ніякі з іх не выклікае патрэбы ў выкладзенні якіх-лібо іншых каталога хоста для агента.

Наданне доступу кантэйнеру да GPU AMD

Гэта настройка прызначаная для AMD ROCm, а не для NVIDIA CUDA. На карце AMD не трэба інсталаваць nvidia-container-toolkit — гэта было зроблена ранейш, перш чым была з’явілася памылка. Інструкцыі ўжоў Ollama для стварэння кантэйнера вікорыстоўваюць образ ollama/ollama:rocm для GPU AMD і перадаюць у кантэйнер два вузлы прыстрою:

/dev/kfd
/dev/dri

Пераканаўцеся, чы ўхосты ўсё ж існуе:

ls -l /dev/kfd
ls -l /dev/dri/render*

Потым адзірніце групы абанку:

groups

Калі абанац не ўключаны ў групы відзняць і рэндэрацыі, дадзіце яго:

sudo usermod -aG video,render "$USER"

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

groups

Пасля новага запуску, запрацавайце яго ўтроці:

groups

Рэзультат тады павінен уключаць обе групы:

video render

Параметр --group-add keep-groups у Podman пазней перадае гэтыя дапаможнія групы ў кантэйнер без корня, ў яком можна выкарыстоўваць прыстроі GPU.

Перакананне ў робачым стане прыстрою TUN

Іншая проблема выйшла з сеткавання без корня. Pasta, стандартны механізм сеткавання без корня у Podman, скаржылася, што не можа ачысці прыстрой TUN:

pasta failed with exit code 1:
Failed to open() /dev/net/tun: No such device

Шукайце вузел прыстрою:

ls -l /dev/net/tun

Калі яго няма, запусціце модуль ядра:

sudo modprobe tun

Потым пераканацце знова. Калі modprobe паведамляе, што модуль не існуе для дзейнуючага ядра, а сістэма няўзніклі ў версію вышэй, парабяльце версію дзейнуючага ядра з каталогамі модуляў:

uname -r
ls /usr/lib/modules/

У такій дынамічнай дыстрыбуцыі, як Arch, апарат можа проста яшчэ запускаць старэйшы кэрнэл, чыя модулі былі адчынены пад час апгрэйда. Запускайце камп’ютар занова і спробавайце зноў.

Выбір локальнага модэлю

Для карточак з прыблізна 16 ГБ VRAM Ollama наразе рэкамендуе gemma4 як локальны модэль для Hermes, а сістэмы з прыблізна 24 ГБ могу выбраць модэлі на кшталт qwen3.6. У даным прыкладзе выкарыстоўваецца варыянт gemma4 з 12 мільярда параметраў:

gemma4:12b

Зберагуйце яго ў зменнай, налаштаваючы мадэль па рэальнай апаратнае частцы:

export HERMES_MODEL="gemma4:12b"

Іншым важлівым показнікам ёсць дужына кантэксту. Ollama за замовчанням налаштоввае GPU з VRAM менш чым 24 Гіб толькі на 4K дужыну кантэксту, тады як обе праекты рэкамендуюць мінімум 64 000 токенав кожны раз, калі задыяныя агенты. Гэта будзе налаштавана яшчэ адзін раз у далейшым разе.

Зялленне зображэнняў і модэлю

Патрэбны тры зображэння: звычайнае зображэння Ollama, версія для ROCm і зображэння Hermes:

podman pull docker.io/ollama/ollama:latest
podman pull docker.io/ollama/ollama:rocm
podman pull docker.io/nousresearch/hermes-agent:latest

Звычныя адпрацоўвальнікі Ollama абавяжаны адзінразовым завантажэнням модэлю. Адпрацоўвальнік ROCm становіцься стацыонарным серверам для выканання запытанняў у AMD.

Завантажыце модэль у яго постоянную прастору за дапамогою тымчасовага кантэйнера. Спачатку празначыце ўсе застарэлыя кантэйнеры:

podman rm -f ollama-bootstrap 2>/dev/null

Потым запускайце прыемнік дадзеных з монтаваным об’ёмам модэлю, і больш нічога:

podman run -d \
  --name ollama-bootstrap \
  -v ollama-models:/root/.ollama \
  docker.io/ollama/ollama:latest

Калі сетаванне пасты без корня яшчэ не працюе, тады сетаванне хоста ўзьмецца як альтэрнатыва толькі для гэтага тымчасовага дасягвальніка. Зноў адзьёміце кантэйнер:

podman rm -f ollama-bootstrap 2>/dev/null

І пачніце з сеткі хоста:

podman run -d \
  --network host \
  --name ollama-bootstrap \
  -v ollama-models:/root/.ollama \
  docker.io/ollama/ollama:latest

У гэтым кантэйнеры не падключана жадная рабочая прастора Hermes. З’явіце мадэль праз яе:

podman exec -it ollama-bootstrap \
  ollama pull "$HERMES_MODEL"

Падтвердзіце за дапамою спіса:

podman exec ollama-bootstrap ollama list

Выбраны модэль павінна з’явіцца:

gemma4:12b

Адзьямайце вялікі контэйнер. Модэль застаецца ў прасторэ:

podman rm -f ollama-bootstrap

Калі Podman скаржыцца, што імя кантэйнера ужо зайнятае:

container name "ollama-bootstrap" is already in use

Не трэба продовжваць выдумваць новыя назвы. Лепш адчысці стары кантэйнер:

podman rm -f ollama-bootstrap

альбо аддыяце флаг --replace.

Внутраняя сетка і пад

У першым дыяграме ўзагалі не было сеткі:

--network none

Гэта частка была заменена на спецыяльны внутршній мост Podman. Hermes і Ollama атрымліваюць спяльную прастору імен сеткі, праз якую яны можаць спілкувацца адзін з адным, тады калі Podman обмежвае доступ з зовнішняй сяроды. Параметр --internal існуе саме для таго, каб обмежыць зовнішній доступ у сетках з мостамі. Створыце яго:

podman network create \
  --ignore \
  --internal \
  hermes-internal

Потым створыце пад на той сетцы:

podman pod create \
  --name hermes-local \
  --network hermes-internal \
  --userns=keep-id:uid=10000,gid=10000

Парадыгма keep-id размешчае адказначку хоста без спецыяльных прав усерэдзінэ ў прасторэ імен корыстніка кантэйнера, а цыфры, якія там паказваюцца, можна выбраць. Кантэйнер Hermes запускаецца пад ідэнтыфікатарамі 10000:10000, і самэ гэта прычына таго, што паказваюцься гэтыя значэнні.

Запуск Ollama з ROCm

З’явілася адна з менш очывістых проблем. Команда, якая нарэшце запрацавала, выглядае так:

podman run -d \
  --name ollama \
  --pod hermes-local \
  --device /dev/kfd \
  --device /dev/dri \
  --group-add keep-groups \
  -e HOME=/root \
  -e OLLAMA_MODELS=/root/.ollama/models \
  -e OLLAMA_CONTEXT_LENGTH=64000 \
  -v ollama-models:/root/.ollama \
  docker.io/ollama/ollama:rocm

Ягоў спецыяльныя для AMD лініі ўключаюць:

--device /dev/kfd
--device /dev/dri
--group-add keep-groups
ollama/ollama:rocm

У гэтым лейяуце Podman не трэба прыхіляць два зменныя сераўыску:

HOME=/root
OLLAMA_MODELS=/root/.ollama/models

Прычына — загадочныя некалькання. Мадэль была завантажана правільна, існавалі файлы blob і manifest, а тымчасавы кантэйнер быў належна падключаны. Аднак спісаванне модэляў не прадаў жадных рэзультатаў:

podman exec ollama ollama list

Лог кантэйнера рассказаў гэту історыю:

podman logs ollama

У яго было показана, што Ollama выкарыстоўвае катэгорыю домашнья дырэктарыя корневага файлавога сістэмы і шлях да модэляў, які вылучаецца з яе:

HOME=/
OLLAMA_MODELS=/.ollama/models

адзе сама модэль насправды жыла:

/root/.ollama/models

Ollama стварае свой стандартны шлях да модэлю на адмінскай дырэктарыі плюс .ollama/models, як толькі OLLAMA_MODELS не зменяе гэта. Таму модэль ніколі не была відсутняя — Ollama проста шукала ў неправільным месцы. Явна настройка обох зменных адразу ж выправіла гэту проблему:

HOME=/root
OLLAMA_MODELS=/root/.ollama/models

Цяпер абзац з інформацыяй павінен паказваць модэль:

podman exec ollama ollama list

Парабяранне аб выкарыстоўванні GPU

Шукайце ў лог-файле рэквізіты ROCm і GPU:

podman logs ollama 2>&1 | grep -Ei 'gpu|rocm|amd|gfx'

У працюючай сістэме AMD выканаецца адгукаванне ROCm вычысловага прыстрою. Пасля гэтага запускаецца шырокі тэст, які прасіць мадэль дасты точны адказ:

podman exec -it ollama \
  ollama run gemma4:12b \
  "Reply with exactly: AMD GPU test successful"

Адразу пасля таго, абразоўваеце модэлі, якія працуюць:

podman exec ollama ollama ps

Две ступкі заслуговаюць на увагу:

PROCESSOR
CONTEXT

У ідэале століцца з працоўнікам выканання паказвае GPU, а не пераказваўанне на CPU, пры чым кантэкст стосуецца:

64000

Сама Ollama рэкамендуе пераглядаць спіс своіх процэсаў, каб пабачыць як выдзелены кантэкст, так і працэс пераказвання дадзеных. Мадэль, якая адзначае вялікі натыўны кантэкст, не павінна неабходна атрымляць столькі ж выдзеленых рэсурсаў.

Запуск Hermes з аднам mount

Цяпер створыце кантэйнер Hermes унутрь таго ж пода:

podman run -d \
  --name hermes \
  --pod hermes-local \
  --security-opt=no-new-privileges \
  --pids-limit 512 \
  -v hermes-data:/opt/data \
  -v "$HERMES_WORKSPACE:/opt/data/workspace:rw,nodev,nosuid" \
  -w /opt/data/workspace \
  docker.io/nousresearch/hermes-agent:latest \
  sleep infinity

Важна тое, чаго ў яму не ёсць. Нічога з гэтага не праблывае:

/:/host
/home:/home
~/.ssh
~/.config
Docker socket
Podman socket

Едынственным дэтэрмінаваным параметрам пры прыяўленні хоста ёсць папка рабочага прастору, якая супараднавана з каталогам дадзэння кантэйнера:

$HERMES_WORKSPACE
        ↓
/opt/data/workspace

Сама дзеяння Hermes знаходзіцца ў названым томе, які монтуецца па яго шляху да дадзэнняў:

hermes-data
        ↓
/opt/data

Афіцыйны кантэйнер выкарыстоўвае /opt/data для стойкага стану і автаматычна задае яму значэнне HERMES_WRITE_SAFE_ROOT. Гэты захад захісту лічыцца частынай багатаслоўнага захавання, а не главным «сандбоксам», адколькі у дасягліх дакументах Hermes паведамляецца, што команды тэрміналу можу абійсці ўскоранення, накладзеныя на працэю з файламі. Рэальныя межы — гэта прастор імен файловай сістэмы Podman.

Перакананне ў межах маунта

Пераканайцеся, калі саме тое, што хост фактычна выкладзае для вжытку Hermes:

podman inspect hermes \
  --format '{{range .Mounts}}{{println .Type .Source "->" .Destination}}{{end}}'

Можна спакаваць две лініі: адна для павеліга дадзэнняў, а другая — для дазволенай папкі:

Podman volume -> /opt/data
your allowed folder -> /opt/data/workspace

Дырэктарыяй домашней папкі і сокет container-runtime не павінны быць прыказаны. Акрутна пераканаўцеся ў сокце:

podman exec hermes sh -c \
  'test ! -S /var/run/docker.sock && echo "No Docker socket exposed"'

Можна таксама пераглядаць шляхі, чутлівыя да хоста, напрыклад, выявляючы, чы рэдакт SSH ўвідны:

podman exec hermes sh -lc \
  'test -e "$HOME/.ssh" && echo "SSH directory visible" || echo "Host SSH directory not visible"'

Памятаце, што кантэйнеры маюць свае сабе сістэмныя каталогі. Іх наявнасць ўсё правільна, адколькі яны належаць кантэйнеру, а не хосту.

Hermes, які падключаецца да Ollama

Оба кантэйнеры выкарыстоўваюць аднойчы сэрвіс сеткавага іменавання падконтэйнера, таму яны вяршаюць абмен трафікам праз лупбэк. Прабавіце API Ollama, сумесны з OpenAI, заўтрачыўшыся ў кантэйнеры Hermes:

podman exec hermes python -c \
'import urllib.request; print(urllib.request.urlopen("http://127.0.0.1:11434/v1/models").read().decode())'

Адказкам трэбаецца быць у фармаце JSON, які містыць локальную модэль. Першая спроба выкарыстоўвала Python heredoc, але нічога не выдрукавала:

podman exec hermes python - <<'PY'
...
PY

Прычына была простая. Python чытае свой праграму з яго стандартнага уводу ў такім фармаце, але для команды podman exec не было задана задача падключыць стандартны увод. Дадзенне флага для інтэрактыўнага рэжыму дазволяе версіі з heredoc працаваць:

podman exec -i hermes python - <<'PY'
import urllib.request
print(
    urllib.request.urlopen(
        "http://127.0.0.1:11434/v1/models"
    ).read().decode()
)
PY

Тая неяўная адзнака коштавала каля калькі хвілін.

Доказ таго, што зовнішній свет недоступны

Спробуйце запрашаць зовнішній веб-сайт з усерэдзіні кантэйнера Hermes:

podman exec hermes python -c \
'import urllib.request; print(urllib.request.urlopen("https://example.com", timeout=5).read())'

Ён павінен не запусцівацца, і гэта ўмышлена. Hermes можа дасягнуць Ollama ўнутрь капсулы, але сетка не дае ніякога нормальнага зовнішньага доступу.

Не панікуйце, калі спіс кантэйнероў будзе такім:

podman ps

Паказвае порт падле Ollama:

11434/tcp

Гэта не значыць, што порт быў публікаваны на хосце. Публікаваны порт выглядае больш што так:

0.0.0.0:11434->11434/tcp

У гэтай наладзе нідзе не выкарыстоўваецца -p 11434:11434.

Наведчы Hermes на локальны Ollama

Запускайце наладку Hermes як карыстальніка кантэйнера, працуючы ў працоўнай зоне:

podman exec -it \
  --user 10000:10000 \
  -w /opt/data/workspace \
  hermes \
  hermes model

Спаменнік падрывальніка паказвае многі хмарныя службы. Не выбірайце опцыю «хмара»:

Ollama Cloud

Заместа таго выберыце варыянт ручнага введэння канцэнтрабы:

Custom endpoint (enter URL manually)

Для базовага URL выкорыстоўваеце адрэсу loopback і шлях v1:

http://127.0.0.1:11434/v1

Калі запрашуецца ключ API, залейце яго порожнім. У ныях прыказах па інтэграцыі з Hermes ад Ollama адначы вікорыстоўваецца гэты самы патэрн з індэксам кастамнага канцэнтра з порожнім ключам для локальнага сервера. Калі запытаюцца пра сумеснасць з API, выберыце варыянт чат-камплетацый, сумесны з OpenAI. Для назвы модэлю увядзіце:

gemma4:12b

А ўжо па дужыне кантэксту:

64000

У дасягліх документацыях Hermes сказана, што локальны Ollama павінен выкарыстоўваць канцэнтры v1 і патрабуе прынеймна 64 Кб кантэксту для рабочых пралэтакаў агента, якія выкарыстоўваюць інструменты.

Выкарыстоўванне локальнага тэрмінальнага бэкенду ўнутрь кантэйнера

Спачатку гэта здаецца дзівным. Hermes зазвычай паветарае пра настройкі свайго локальнага тэрмінальнага бэкенду:

terminal:
  backend: local

Выкананыя каманды тэрміналу працуюць безпосерэдна на той жа машыне, дзе знаходзіцца Hermes, без жаднага ізолявання. На машыне, дзе Hermes установлена безпосерэдня, гэта можа быць небяпечна. У даным случае сам Hermes ужэ знаходзіцца ўнутры Podman, таму локальны бэкенд адносіцца да кантэйнера Hermes:

Hermes "local"
      ↓
Hermes container

і не даўжыню рабочай станцыі:

Hermes "local"
      ↓
your Arch workstation

Установіце задній канал:

podman exec --user 10000:10000 hermes \
  hermes config set terminal.backend local

А каталог для работы:

podman exec --user 10000:10000 hermes \
  hermes config set terminal.cwd /opt/data/workspace

Таксама варта задаць прыягоднасць для рэжыма домашньей старонкі на адміністрацыі прафіля:

podman exec --user 10000:10000 hermes \
  hermes config set terminal.home_mode profile

Не налаштоввайце Docker-бэкенд Hermes для гэтага дызайну. Гэта будзе вымагаць надання Hermes права доступу да рантайму контэйнераў, што скасоўвае адну з галоўных прымэт аісоляцыі.

Запуск Hermes

Інтэрактыўная сесія пачынаецца за аднаковым шаблонам адканання, які вікорыстоўваецца падчас налаштавання:

podman exec -it \
  --user 10000:10000 \
  -w /opt/data/workspace \
  hermes \
  hermes

Для адаптавання зьвітак, запіт можа прасіць Hermes пераглянуць зьвітакі на фармаце Markdown у працоўнай зоне, прывесты у парадак структуру і загалоўкі, выправіць фарматаванне і граматыку, захаваць усі тэхнічныя дэталі, каманды, спяваныя і звязкі Obsidian у недарабленым стане, і ніколі не скрацаваць справжній контэнт толькі для таго, каб зьвітак стаў корачэй. Змяны падаюць безпасова ў адной фолдэры хоста, якая ўстановлена.

Запуск асяроддзя пад час запуску

Калі все будзе працаваць інтэрактыўна, падмножынка должна вярнуцца пасля перзапуску без неабяжнага ручнага запуску Ollama і Hermes. Створыце ўзеўцо systemd для карыстальніка:

mkdir -p ~/.config/systemd/user
nano ~/.config/systemd/user/hermes-local.service

Этап пачатуецца з апісання і рэядка з паказаннем спаку:

[Unit]
Description=Hermes Local AI Pod
After=default.target

Раздзел са службамі — гэта одноразовая працэўнае запуск пада, зупінка яго з 30-секундным перыям павыннасці, а таксама выдазва двух хвілін на запуск:

[Service]
Type=oneshot
RemainAfterExit=yesExecStart=/usr/bin/podman pod start hermes-local
ExecStop=/usr/bin/podman pod stop -t 30 hermes-localTimeoutStartSec=120
TimeoutStopSec=60[Install]
WantedBy=default.target

Калі корань графа Podman знаходзіцца на адзінам дрыўе, гэтае дрыўа павінна быць надзеяным элементам для запуску сістэмы і не можа быць тым, што рабочы стол монтуе інтэрактыўна пасля заходу. Можна дадаць неабавязковую пераглядку монтацыі ExecStartPre, прыстосаваную да файлавой сістэмы.

Перазаваноўці systemd:

systemctl --user daemon-reload

Актывацыя едыніцы:

systemctl --user enable hermes-local.service

Пачніце яго:

systemctl --user start hermes-local.service

І пераканайцеся:

systemctl --user status hermes-local.service

Паколькі гэта абсалютна паслуга з увімкнутым параметрам RemainAfterExit, такі статус ўсё правільны:

Active: active (exited)

У Podman існуе новыя механізмы Quadlet для дэкларатыўнага стварэння контэйнераў пад кераваннем systemd. Аднак калі асяроддзе ужо створана і пераблактавана вручную, мінімальныя насланнія ад службы-выкарыстоўнікава, якая запускае под і якая вядома як працюючая, ствараюць наіменшыя проблемы.

Ёсць можласць запускаць службу-выкарыстоўнікава без прав root ў момент запуску сістэмы, яшчэ перш чым заходзіць у графічны інтэрфейс, шляхом актывацыі функцыі lingering:

sudo loginctl enable-linger "$USER"

Парабяруйце гэта:

loginctl show-user "$USER" -p Linger

Апэктываны рэзультат:

Linger=yes

Функцыя linger у Systemd дазваляе менеджэру служб карыстальніка запускацца пад час запуску сістэмы і заставацца доступным паразіч ад звычных сесій заходу. Пасля перзапуску спіс контэйнероў:

podman ps

Ўжо должна быць паказана пада, у якой запускаюцца Ollama і Hermes. Інтэрактыўная сесія Hermes такім чынам яшчэ запускаецца за дапамою каманды exec:

podman exec -it \
  --user 10000:10000 \
  -w /opt/data/workspace \
  hermes \
  hermes

Сэрвіс запуску пачынае працу асяроддзя. Ён не ачыяе інтэрактыўны чат.

Проблемы, якія фактычна выйшлі

Ёсць стыснуты спіс неудач, зустрэлых па дарозе, кожная з якіх паказвае проблему і спосаб яе адзьявлення.

Памылка з боку ядра:

Problem:
kernel does not support overlay fs

Гэта проблема была рашыта празьвячэннем fuse-overlayfs і яго выкліканнем як программы для монтавання у фармаце overlay:

Fix:
Install fuse-overlayfs and configure it as the overlay mount program.

Заканчываецца прастор пад тымчасовым каталогам:

Problem:
no space left on device under /var/tmp

Патрэбны як перасунуты корань графа, калі гэта дапаможліва, так і настройка TMPDIR, адколькі флаг tmpdir у Podman — гэта адзін другі элемент:

Fix:
Move Podman's graphroot if needed AND set TMPDIR.
Changing Podman's --tmpdir is not the same thing.

Узгоджання імен для кантэйнера bootstrap:

Problem:
ollama-bootstrap name already in use

Гэта проблема рашыяецца праз выдаленне застарэлага кантэйнера:

Fix:
podman rm -f ollama-bootstrap

Паста не можа адзьязаць прыстрой TUN:

Problem:
pasta cannot open /dev/net/tun

Гэта проблема рашыяецца праз завантажэнне модуля tun, або праз перэзапуск, калі інсталаваныя модулі не падходзяць да дзейнуючага ядра:

Fix:
sudo modprobe tun
If the installed modules don't match the running kernel, reboot.

Набор адынстрацый NVIDIA, установлены на апаратазе AMD:

Problem:
Installed nvidia-container-toolkit on an AMD machine

Гэта проста-такі працаваць не должна; у замене трэба выкарыстоўваць адпрацоўваныя зображэння ROCm з прыстроямі kfd і dri:

Fix:
Don't.
Use ollama/ollama:rocm with /dev/kfd and /dev/dri.

Новыя чыслы учаснікаў групы для відэа і рэндэраў, якія не паказаліся ў спісе груп:

Problem:
Added myself to video/render but `groups` still didn't show them

Патрэбна можлівасць выйшаць і зайсці, таму што існуючая сесія застаецца з своімі первіснымі групамі:

Fix:
Log out and back in.
The existing login session retains its original supplementary groups.

Файлы модэляў і маніфест з’яўляюцца, калі спіс Ollama ўстаўняюць пусты:

Problem:
Ollama model files and manifest exist, but `ollama list` is empty

Дыягназаваецца праз чытанне логу, і якшы толькі шляхі home і models выказваюць коран файлавой сістэмы, а тым часам том заўязаны пад катэгорыяю корыстніка root, тоабходна неабяжна задаецца обея зменныя:

Fix:
Check:
podman logs ollamaIf Ollama is using:
OLLAMA_MODELS=/.ollama/modelswhile the volume is mounted under:
 /root/.ollamaset explicitly:
HOME=/root
OLLAMA_MODELS=/root/.ollama/models

Тэст на Python з Hermes у Ollama, які безшумна прынёс нічога:

Problem:
Hermes → Ollama Python test silently prints nothing

Гэта проблема была выправлена праздадзеннем абяраннага флага пад час вікорыстоўвання heredoc, або проста праз вікорыстоўванне формы внутршней команды:

Fix:
If using `python -` with a heredoc, add `podman exec -i`.
Or simply use `python -c`.

Меню падаючага аппарату без явнага местнага пункту Ollama:

Problem:
The Hermes provider menu doesn't contain "local Ollama"

Гэта проблема была рашыта празбіром ручнага спецыяльнага канцэнтра і введэннем локальнага URL v1:

Fix:
Choose:
Custom endpoint (enter URL manually)Then:
http://127.0.0.1:11434/v1

І Гермес скаржыцца на недастатковыя параметры вікна кантэксту, навет як усе інша працавала нормальна:

Problem:
Everything works, but Hermes reports an inadequate context window

Гэта проблема рашыяецца паставленнем дужыны кантэкста з боку сервера на 64000, налашчэннем Hermes на тое жа значэнне і перакананнем рэальнага выдзелу за дапамою спісу процэсаў Ollama:

Fix:
Set OLLAMA_CONTEXT_LENGTH=64000 server-side and configure Hermes for the same value.
Verify the real allocation with:
ollama ps

Дзе павінна знаходзіцца межа доверы

Галоўны урок тут не стосуецца самаў Ollama чы ROCm. Ён стосуецца выбору месца, дзе будзе знаходзіцца межа доверы. Указванне, што не трэба чытаць нічога за межама пакета, являе сабою інструкцыю па поведзенні. Кантэйнер Podman, якому ніколі не быў даўны рэштка файловай сістэмы хоста, ўтварае межу аператывной сістэмы. Функцыя безпечнага запісу дадзеных у Hermes ўжыткова, але сам Hermes апісвае яе як дадатковы шар, а не справжню «песочню яму», адтолькі што команды шэлу можу абійсці захіст файловых інструментаў.

Утварэныя такім чынам модэлі доверы складаюць шары з самага слабкага да самага сільнага: пачынаючы з обмежэнняў, наказаных у інструкціях, і захадаў Hermes проты запісу дадзеных, і заканчываючы межай кантэйнера:

Prompt restrictions
        ↓
Hermes file write protections
        ↓
Hermes container filesystem
        ↓
Rootless Podman user namespace
        ↓
Host filesystem permissions

Нават калі мадэль отрымае злонамераныя інструкцыі, спрывучаныя ў файле Markdown, цікавым пытаннем не ёсць тое, чы робіць яна тое, што прасіваеся ў пачатковым запіце. Гэтым пытаннем ёсць тое, да чаго насправды можа дасягнуць скомпрометаваны агент. У такой конструкцыі адпаведзенне навмысна ёсць скромным.

Дыягнастыка па шарах

Hermes і Ollama або бацько быстра зміняюцца. Чынная документацыя Hermes падтрымляе самастойна розмешчаныя канцэнтры, сумесныя з OpenAI, укладзеныя ў Ollama, але таксама існуюць звесткі пра прыемнае працаванне інструментаў праз спецыяльныя канцэнтры Ollama. Калі звычны чат працюе, але Hermes, здаецца, опісвае выклікі інструментаў без ўжывання іх, перад тым, як прыпускаць, што сандбокс Podman зламаны, пераканайцеся ў чынным трэйкеры проблем Hermes.

Гэта прычына, чаму трэба тэставаць весь стак як ланцюг пытанняў: чы Podman бачыць GPU, чы Ollama бачыць мадэль, і чы Hermes можа весты кантакт з Ollama:

Does Podman see the GPU?
        ↓
Does Ollama see the model?
        ↓
Does Ollama actually use the GPU?
        ↓
Is the context really 64K?
        ↓
Can Hermes reach /v1/models?
        ↓
Can Hermes perform an actual file operation?
        ↓
Can Hermes reach anything it shouldn't?

Не прабуйце дэбагаваць усе шасць слоёў адразу.

Што дае готавая настройка

Рэзультатныя настройкі забезпечваюць локальныя вычысленні, прышвычкі AMD GPU, стойкую памяць Hermes і адну працоўную зону хоста для збіркі дадзеных:

Local inference                YES
AMD GPU acceleration           YES
Hermes persistent memory       YES
One writable host workspace    YES

І ёму не патрэбна модэль воблака, ён не адкрывае файлавую сістэму хоста, не адкрывае сокеты Podman чыста Docker, і не мае звычайнага выходу у Інтэрнэт:

Cloud LLM required             NO
Host filesystem exposed        NO
Podman/Docker socket exposed   NO
Normal Internet egress         NO
Entire Obsidian vault exposed  NO

Гэта набагато зручнейшы спосаб працаваць з адпрацоўнікам, які можа выканаць розныя задачы на месцы. Hermes усё ўсё мае достатню доступнасць, каб быць корыстным. Проста ён не можа сам адначасова вярнуцца да таго, што значыць «достатня доступнасць».