Практичні поради: запустіть Hermes Agent локально (та безпечно) за допомогою Ollama та
Покрокова інструкція з практичних порад: запуск агента Hermes локально (та безпечно) за допомогою Ollama, а також контракти, перевірки та слоти для коду для команд, які використовують цю схему.
Використовуйте цей документ як оновлену версію ідей з статті „Запустити Hermes Agent локально (та безпечно) за допомогою Ollama та Rootless Podman на Arch Linux“ для співробітників-операторів: чіткі етапи, впорядковані блоки коду та примітки щодо відновлення, які залишаються при передачі обов’язків. Етап Огляду найкраще функціонує, якщо його розглядати як вимірювану основу. Запишіть один ідеальний зразок роботи, один випадок збою та примітки щодо скасування змін перед розширенням обсягу роботи. Розглядайте цей етап як угоду між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте мовчазного часткового виконання завдань.
1. Встановіть Rootless Podman
Для створення етапу Podman без кореневих прав під час 1-ї установки необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори мають мати можливість перезапустити крок з відомої точки контролю, не намагаючись здогадатися про прихований стан. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Візуалізація витрат заздалегідь запобігає несподіваним рахункам під час переходу від демо-середовищ до спільних. Розділіть процес створення клієнта від циклу обробки повідомлень, щоб можна було замінювати постачальників без переписування машини станів розмови.
sudo pacman -Syu podman
1) crun
2) krun
3) runc
1
podman --version
podman info --format '{{.Host.OCIRuntime.Name}}'
crun
grep "^$USER:" /etc/subuid
grep "^$USER:" /etc/subgid
2. За потреби виправте rootless OverlayFS
Для етапу 2 Fix rootless OverlayFS необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не здогадуючись про прихований стан. Конфігурацію слід тримати окремо від коду додатку. Файли середовища, сховища секретів та флаги функцій мають знаходитися в одному місці, яке оператори можуть перевірити, не читаючи весь граф. Необхідно розділити процес створення клієнта від циклу обробки повідомлень, щоб можна було замінити постачальників без переписування машини станів розмови.
kernel does not support overlay fs:
'overlay' is not supported over extfs
sudo pacman -S fuse-overlayfs
which fuse-overlayfs
/usr/bin/fuse-overlayfs
~/.config/containers/storage.conf
[storage]
driver = "overlay"
[storage.options.overlay]
mount_program = "/usr/bin/fuse-overlayfs"
podman info --debug | grep -Ei 'graphDriverName|mount_program|overlay'
3. Додатково: перемістити сховище Podman на більший диск
Для 3 необов’язкових етапів з використанням Podman необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Необхідно документувати як шлях успішного виконання, так і шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. Необхідно розділити процес створення клієнта від циклу обробки повідомлень, щоб можна було замінити постачальників без переписування машини станів розмови. Для 3 необов’язкових етапів з використанням Podman необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте безповідомного часткового завершення роботи.
write /var/tmp/container_images_storage...:
no space left on device
$HOME/.local/share/containers/storage
/var/tmp
/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"
[storage.options.overlay]
mount_program = "/usr/bin/fuse-overlayfs"
export TMPDIR=/path/to/large-drive/podman/tmp
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'
~/.local/share/containers/storage
4. Створіть єдину папку хоста, до якої матиме доступ Hermes
Під час виконання кроку «Створіть єдиний етап» спочатку запишіть умови використання: необхідні дані вхіду, сигнал про успішне виконання та наслідки часткової невдачі. Такий перелік допоможе зберегти чесність подальших змін у коді. Записуйте час виконання та витрати на токени або запити поруч із результатами функціонування. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам під час переходу з демо-середовища у спільні. У кожному запиті фіксуйте ідентифікатор запиту, ідентифікатор моделі та час затримки. Без цих записів періодичні помилки постачальника можуть здаватися багами програми.
export HERMES_WORKSPACE="$HOME/path/to/Hermes-Workspace"
mkdir -p "$HERMES_WORKSPACE"
Obsidian Vault/
├── Personal/
├── Work/
├── Research/
└── Agent Workspace/ ← only this folder is exposed
podman volume create hermes-data
podman volume create ollama-models
5. Налаштуйте доступ до GPU AMD
Під час виконання 5 етапу налаштування AMD GPU спочатку запишіть контракт: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Зберігайте конфігурацію окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, яке оператори можуть перевірити, не читаючи весь код. Логуйте ідентифікатор запиту, ідентифікатор моделі та час затримки при кожному виклику. Без цих записів періодичні помилки постачальника виглядають як баги додатку.
/dev/kfd
/dev/dri
ls -l /dev/kfd
ls -l /dev/dri/render*
groups
sudo usermod -aG video,render "$USER"
groups
groups
video render
6. Перевірте /dev/net/tun
Під час виконання 6 етапу перевірки розробчої мережі спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність у подальших змінах коду. Одночасно задокументуйте шлях успішного виконання та шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої доробки. У кожному запиті фіксуйте ідентифікатор запиту, ідентифікатор моделі та час затримки. Без цих даних періодичні помилки постачальника виглядають як баги програмного забезпечення. Під час виконання 6 етапу перевірки розробчої мережі спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність у подальших змінах коду. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Назвіть створювані елементи, визначте критерії успіху та не допускайте безповідомного часткового виконання.
pasta failed with exit code 1:
Failed to open() /dev/net/tun: No such device
ls -l /dev/net/tun
sudo modprobe tun
uname -r
ls /usr/lib/modules/
7. Виберіть локальну модель
Етап «7. Виберіть локальну модель» працює найкраще, якщо його розглядати як вимірювану поверхню. Запишіть один ідеальний приклад роботи, один випадок збою та примітки щодо скасування змін перед розширенням обсягу завдань. Запишіть час виконання та витрати на токени або запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам, коли процес переходить від демо-версії до спільних середовищ. Закріпіть інтерпретатор та файл з параметрами залежностей перед навчанням циклу. Розбіжності між ноутбуком та середовищем CI є найпоширенішою причиною прихованих збоїв у демонстраціях API.
gemma4:12b
export HERMES_MODEL="gemma4:12b"
8. Завантажте зображення контейнерів
Етап 8 «Підтягування контейнера» працює найкраще, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Тримайте конфігурацію окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код. Фіксуйте версію інтерпретатора та файл з блокуванням залежностей перед початком використання циклів. Розбіжності між ноутбуком та системою CI є найпоширенішою причиною прихованих збоїв у демонстраціях API.
podman pull docker.io/ollama/ollama:latest
podman pull docker.io/ollama/ollama:rocm
podman pull docker.io/nousresearch/hermes-agent:latest
9. Завантажте модель у постійний об’єм
Етап „9. Завантаження моделі“ працює найкраще, коли його розглядають як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Документуйте як успішний, так і відновлювальний сценарії роботи разом. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. Заблокуйте інтерпретатор та файли з інформацією про залежності перед тим, як почнете використовувати цикли. Розбіжності між ноутбуком та середовищем CI є найпоширенішою причиною прихованих збоїв у демонстраціях API. Етап „9. Завантаження моделі“ працює найкраще, коли його розглядають як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте прихованого часткового виконання завдань.
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
podman exec -it ollama-bootstrap \
ollama pull "$HERMES_MODEL"
podman exec ollama-bootstrap ollama list
gemma4:12b
podman rm -f ollama-bootstrap
container name "ollama-bootstrap" is already in use
podman rm -f ollama-bootstrap
10. Створення мережі лише для внутрішнього використання
На етапі 10 «Створення мережі лише для внутрішнього використання» необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість знову виконати крок з відомої точки контролю, не намагаючись визначити прихований стан. Необхідно фіксувати час виконання та витрати на токени або запити поруч із функціональними результатами. Чітке відображення витрат заздалегідь запобігає несподіваним рахункам під час переходу з демо-середовища у спільні середовища. Необхідно розділити процес створення клієнта від циклу обробки повідомлень, щоб можна було замінювати постачальників без переписування машини станів розмови.
--network none
podman network create \
--ignore \
--internal \
hermes-internal
podman pod create \
--name hermes-local \
--network hermes-internal \
--userns=keep-id:uid=10000,gid=10000
11. Запуск Ollama з AMD ROCm
Щоб запустити Ollama з використанням фаз, необхідно перед зміною коду визначити вхідні дані, власника кроку та критерії завершення. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Конфігурацію слід тримати окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, яке оператори можуть перевірити, не читаючи весь граф. Необхідно розділити процес створення клієнта від циклу обробки повідомлень, щоб можна було замінювати постачальників без переписування машини станів розмови.
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
--device /dev/kfd
--device /dev/dri
--group-add keep-groups
ollama/ollama:rocm
HOME=/root
OLLAMA_MODELS=/root/.ollama/models
podman exec ollama ollama list
podman logs ollama
HOME=/
OLLAMA_MODELS=/.ollama/models
/root/.ollama/models
HOME=/root
OLLAMA_MODELS=/root/.ollama/models
podman exec ollama ollama list
12. Перевірка того, чи справді ROCm використовує GPU
На етапі 12 Verify ROCm необхідно визначити вхідні дані, відповідального за крок та критерії завершення перед зміною коду. Оператори мають мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Необхідно документувати як шлях успішного виконання, так і шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. Необхідно розділити процес створення клієнта від циклу обробки повідомлень, щоб можна було замінювати постачальників без переписування машини станів розмови. На етапі 12 Verify ROCm необхідно визначити вхідні дані, відповідального за крок та критерії завершення перед зміною коду. Оператори мають мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте безповідомного часткового завершення роботи.
podman logs ollama 2>&1 | grep -Ei 'gpu|rocm|amd|gfx'
podman exec -it ollama \
ollama run gemma4:12b \
"Reply with exactly: AMD GPU test successful"
podman exec ollama ollama ps
PROCESSOR
CONTEXT
64000
13. Запустіть Hermes із саме одним монтуванням папки-хоста
Під час роботи над етапом 13 «Запустіть 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-data
↓
/opt/data
14. Перевірте межі монтування
Під час виконання 14-го етапу «Перевірка підключення» спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Зберігайте конфігурацію окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код. У кожному запиті фіксуйте ідентифікатор запиту, ідентифікатор моделі та час відгуку. Без цих записів періодичні помилки постачальника виглядають як баги додатку.
podman inspect hermes \
--format '{{range .Mounts}}{{println .Type .Source "->" .Destination}}{{end}}'
Podman volume -> /opt/data
your allowed folder -> /opt/data/workspace
podman exec hermes sh -c \
'test ! -S /var/run/docker.sock && echo "No Docker socket exposed"'
podman exec hermes sh -lc \
'test -e "$HOME/.ssh" && echo "SSH directory visible" || echo "Host SSH directory not visible"'
15. Перевірка можливості Hermes підключатися до Ollama
Під час роботи над 15 кроками, які Verify Hermes може виконати, спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Одночасно задокументуйте шлях успішного виконання та шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої доробки. У кожному виклику фіксуйте ідентифікатор запиту, ідентифікатор моделі та час затримки. Без цих даних періодичні помилки постачальника виглядають як баги програмного забезпечення. Під час роботи над 15 кроками, які Verify Hermes може виконати, спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Дайте назви елементам, визначте критерії успіху та не допускайте безповідомних часткових завершень.
podman exec hermes python -c \
'import urllib.request; print(urllib.request.urlopen("http://127.0.0.1:11434/v1/models").read().decode())'
podman exec hermes python - <<'PY'
...
PY
podman exec -i hermes python - <<'PY'
import urllib.request
print(
urllib.request.urlopen(
"http://127.0.0.1:11434/v1/models"
).read().decode()
)
PY
16. Перевірте, чи заблокований доступ до зовнішньої мережі
Етап 16 «Перевірте, чи заблокований доступ до зовнішньої мережі» працює найкраще, якщо його розглядати як вимірювану характеристику. Збережіть один ідеальний зразок роботи, один випадок збою та примітки щодо скасування змін перед розширенням обсягу роботи. Записуйте час виконання та витрати на токени або запити поруч із результатами функціональності. Відображення витрат заздалегідь запобігає несподіваним рахункам, коли процес переходить від демо-версії до спільних середовищ. Закріпіть інтерпретатор та файл блокування залежностей перед тим, як пояснювати принцип роботи циклу. Розбіжності між ноутбуком та середовищем CI є найпоширенішою причиною прихованих збоїв у демонстраціях API.
podman exec hermes python -c \
'import urllib.request; print(urllib.request.urlopen("https://example.com", timeout=5).read())'
podman ps
11434/tcp
0.0.0.0:11434->11434/tcp
17. Налаштуйте Hermes для використання локального Ollama
17. Найкраще налаштовувати Hermes для виконання завдань, якщо розглядати його як вимірювану поверхню. Збережіть один ідеальний приклад роботи, один випадок збою та запис про скасування змін перед розширенням обсягу завдань. Тримайте конфігурацію окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, щоб оператори могли їх перевіряти, не читаючи весь код. Забезпечте фіксацію версії інтерпретатора та файлу блокування залежностей перед початком використання циклів. Розбіжності між ноутбуком та системою CI є найпоширенішою причиною прихованих збоїв у демонстраціях API.
podman exec -it \
--user 10000:10000 \
-w /opt/data/workspace \
hermes \
hermes model
Ollama Cloud
Custom endpoint (enter URL manually)
http://127.0.0.1:11434/v1
gemma4:12b
64000
18. Використовуйте локальний термінал Hermes — всередині контейнера
Метод «18 Use Hermes local stage» працює найкраще, коли його розглядають як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Документуйте як успішний, так і відновлювальний сценарії роботи разом. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. Заблокуйте інтерпретатор та файли з інформацією про залежності перед тим, як почнете використовувати цикли. Розбіжності між ноутбуком та системою CI є найпоширенішою причиною прихованих збоїв під час демонстрацій API. Метод «18 Use Hermes local stage» працює найкраще, коли його розглядають як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Розглядайте цю стадію як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте прихованого часткового виконання завдань.
terminal:
backend: local
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
19. Запуск Hermes
Для 19-го етапу запуску Hermes необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись визначити прихований стан. Записуйте час виконання та витрати на токени або запити поруч із функціональними результатами. Візуалізація витрат на ранньому етапі запобігає несподіваним рахункам під час переходу з демо-середовища у спільні середовища. Відокремте створення клієнта від циклу обробки повідомлень, щоб можна було змінювати постачальників без переписування машини станів розмови.
podman exec -it \
--user 10000:10000 \
-w /opt/data/workspace \
hermes \
hermes
20. Автоматичне запуск середовища під час завантаження
Для етапу налаштування середовища у процесі 20 Start необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись визначити прихований стан. Конфігурацію слід тримати окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функціоналу мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код. Необхідно розділити процес створення клієнта від циклу обробки повідомлень, щоб можна було замінювати постачальників без переписування машини станів розмови.
mkdir -p ~/.config/systemd/user
nano ~/.config/systemd/user/hermes-local.service
[Unit]
Description=Hermes Local AI Pod
After=default.target
[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
systemctl --user daemon-reload
systemctl --user enable hermes-local.service
systemctl --user start hermes-local.service
systemctl --user status hermes-local.service
Active: active (exited)
sudo loginctl enable-linger "$USER"
loginctl show-user "$USER" -p Linger
Linger=yes
podman ps
podman exec -it \
--user 10000:10000 \
-w /opt/data/workspace \
hermes \
hermes
Усунення проблем, які дійсно виникли
Для усунення проблем на цьому етапі необхідно визначити вхідні дані, відповідальну особу за крок та критерії завершення перед зміною коду. Оператори повинні мати можливість знову виконати крок з відомої точки контролю, не намагаючись вгадати прихований стан. Необхідно документувати як шлях успішного виконання, так і шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. Необхідно розділити процес створення клієнта від циклу обробки повідомлень, щоб можна було замінити постачальників без переписування машини станів розмови. Для усунення проблем на цьому етапі необхідно визначити вхідні дані, відповідальну особу за крок та критерії завершення перед зміною коду. Оператори повинні мати можливість знову виконати крок з відомої точки контролю, не намагаючись вгадати прихований стан. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте безповідомного часткового завершення роботи.
Problem:
kernel does not support overlay fs
Fix:
Install fuse-overlayfs and configure it as the overlay mount program.
Problem:
no space left on device under /var/tmp
Fix:
Move Podman's graphroot if needed AND set TMPDIR.
Changing Podman's --tmpdir is not the same thing.
Problem:
ollama-bootstrap name already in use
Fix:
podman rm -f ollama-bootstrap
Problem:
pasta cannot open /dev/net/tun
Fix:
sudo modprobe tun
If the installed modules don't match the running kernel, reboot.
Problem:
Installed nvidia-container-toolkit on an AMD machine
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.
Problem:
Ollama model files and manifest exist, but `ollama list` is empty
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
Problem:
Hermes → Ollama Python test silently prints nothing
Fix:
If using `python -` with a heredoc, add `podman exec -i`.
Or simply use `python -c`.
Problem:
The Hermes provider menu doesn't contain "local Ollama"
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
Fix:
Set OLLAMA_CONTEXT_LENGTH=64000 server-side and configure Hermes for the same value.
Verify the real allocation with:
ollama ps
Чому ви віддаєте перевагу цьому замість простого довір’я агенту
Під час роботи над розділом «Чому ви обираєте цю стадію» спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Запишіть час виконання та витрати на токени або запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам, коли процес переходить від демо-версії до спільних середовищ. Записуйте ідентифікатор запиту, ідентифікатор моделі та час затримки після кожного виклику. Без цих записів періодичні помилки постачальника можуть здаватися багами програми.
Prompt restrictions
↓
Hermes file write protections
↓
Hermes container filesystem
↓
Rootless Podman user namespace
↓
Host filesystem permissions
Примітка щодо швидко розвиваючихся локальних інструментів ШІ
Під час роботи над приміткою A щодо швидкоплинної фази спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Зберігайте конфігурацію окремо від коду додатку. Файли середовища, сховища секретних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код. Записуйте ідентифікатор запиту, ідентифікатор моделі та час затримки після кожного виклику. Без цих записів періодичні помилки постачальника виглядають як баги додатку.
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?
Кінцевий результат
Під час роботи над етапом остаточного результату спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність у подальших змінах коду. Документуйте як шлях успішної роботи, так і шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої доробки. Записуйте ідентифікатор запиту, ідентифікатор моделі та час виконання кожного виклику. Без цих записів періодичні помилки постачальника виглядають як баги програми. Під час роботи над етапом остаточного результату спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність у подальших змінах коду. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Назвіть всі елементи, визначте критерії успіху та не допускайте безповідомного часткового завершення роботи.
Local inference YES
AMD GPU acceleration YES
Hermes persistent memory YES
One writable host workspace YES
Cloud LLM required NO
Host filesystem exposed NO
Podman/Docker socket exposed NO
Normal Internet egress NO
Entire Obsidian vault exposed NO
Перелік операційних кроків
Під час роботи над етапом перевірки операційного процесу спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успішне виконання та наслідки часткової несправності. Такий перелік допомагає зберігати чесність пізніших змін у коді.
Віддавайте перевагу невеликим, тестованим одиницям коду перед складними скриптами. Якщо якийсь крок не виконується, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність дій.
У кожному запиті фіксуйте ідентифікатор запиту, ідентифікатор моделі та час виконання. Без цих даних періодичні помилки постачальника виглядають як баги програмного забезпечення.
Зберігайте стан графа у простій та типованій формі. Вкладені структури даних приховують інформацію про те, який вузол заповнив яке поле, що ускладнює продовження роботи після перерв.
Коли це дозволяють бюджетні обмеження, додавайте тест на базову функціональність, який перевіряє критичний шлях у процесі інтеграційного тестування за допомогою фікстур, а не реальних платних API.
Зберігайте конфігурацію поза кодом додатку. Файли середовища, сховища секретів та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код.
Перед підвищенням версії стеку заморозьте версії, зробіть «золотий запис» для критичного шляху та підтвердьте кроки відкату. У спільних середовищах необхідні обмеження швидкості, перевірки прав власності та чіткий власник для заміни секретів. Віддавайте перевагу надійності перед креативними одноразовими демонстраціями.
Примітка для bab1ff410bd9: не включайте ключі постачальника до репозиторію, встановіть ліміт токенів на сеанс та зберігайте записи поруч із фіксами оцінки, щоб подальша заміна моделей залишалася порівнянною.