Notas prácticas: Ejecute Hermes Agent localmente (y de forma segura) con Ollama y
Guía paso a paso para utilizar las notas prácticas: Ejecutar Hermes Agent localmente (y de forma segura) con Ollama, además de contratos, verificaciones y espacios para código adicional destinados a los equipos que implementan este patrón.
Úselo como una versión reestructurada dirigida a operadores de las ideas presentadas en “Ejecutar Hermes Agent localmente (y de forma segura) con Ollama y Rootless Podman en Arch Linux”: etapas claras, secciones de código ordenadas y notas de recuperación que perduran tras una transferencia. La etapa de Resumen funciona mejor cuando se considera como una superficie medible. Capture una transcripción de referencia, un caso de fallo y la nota de reversión antes de ampliar el alcance. Trate esta etapa como un contrato entre las entradas y los resultados validados. Asigne nombres a los artefactos, defina comprobaciones de éxito y rechace completaciones parciales silenciosas.
1. Instalar Rootless Podman
Para la etapa de Podman sin root en la primera instalación, defina las entradas, el propietario de la tarea y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar la tarea a partir de un punto de control conocido sin tener que adivinar el estado oculto. Registre los tiempos de ejecución y el costo de tokens o consultas junto con los resultados funcionales. La visibilidad temprana del costo evita facturas inesperadas cuando el proceso pasa de entornos de demostración a entornos compartidos. Separe la construcción del cliente del bucle de mensajes para que sea posible cambiar los proveedores sin tener que reescribir la máquina de estados de la conversación.
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. Corrija OverlayFS sin root si es necesario
Para la etapa 2 de Fix rootless OverlayFS, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Mantenga la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de secretos y las banderas de funcionalidad deben estar en un lugar que los operadores puedan auditar sin tener que leer todo el sistema. Separe la construcción del cliente del bucle de mensajes para que sea posible cambiar los proveedores sin tener que reescribir la máquina de estados de la conversación.
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. Opcional: mover el almacenamiento de Podman a una unidad más grande
Para la etapa opcional de migración a Podman, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Documente tanto la ruta óptima como la ruta de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores. Separe la construcción del cliente del bucle de mensajes para que sea posible cambiar los proveedores sin tener que reescribir la máquina de estados de la conversación. Para la etapa opcional de migración a Podman, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Trate esta etapa como un contrato entre las entradas y los resultados validados. Asigne nombres a los artefactos, defina comprobaciones de éxito y rechace las completaciones parciales silenciosas.
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. Cree la única carpeta de host a la que tendrá acceso Hermes
Al trabajar en el paso 4 de Crear la única etapa, anote primero los requisitos: entradas necesarias, señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación ayuda a mantener honestos los cambios posteriores en el código. Registre los tiempos y el costo del token o consulta junto con los resultados funcionales. Tener visibilidad del costo desde el principio evita facturas inesperadas cuando se pasa de entornos de demostración a entornos compartidos. Registre el ID de la solicitud, el ID del modelo y la latencia en cada llamada. Sin ese registro, los errores intermitentes del proveedor parecen bugs de la aplicación.
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. Configure el acceso a la GPU AMD
Al trabajar en la etapa 5 de Configurar GPU AMD, anote primero el contrato: los datos de entrada requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación ayuda a mantener honestas las futuras modificaciones del código. Guarde la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de datos confidenciales y las banderas de funcionalidad deben estar en un lugar donde los operadores puedan auditarlos sin tener que leer todo el código. Registre el ID de la solicitud, el ID del modelo y la latencia en cada llamada. Sin ese registro, los errores intermitentes del proveedor parecen ser defectos de la aplicación.
/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. Verificar /dev/net/tun
Al trabajar en la fase de 6 Check dev net, anote primero el contrato: las entradas requeridas, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Documente junto con ello el camino óptimo y el camino de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no de mejoras posteriores. Registre el ID de la solicitud, el ID del modelo y la latencia en cada llamada. Sin ese registro, los errores intermitentes del proveedor parecen bugs de la aplicación. Al trabajar en la fase de 6 Check dev net, anote primero el contrato: las entradas requeridas, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Trate esta fase como un contrato entre las entradas y las salidas validadas. Asigne nombres a los artefactos, defina las comprobaciones de éxito y rechace las completaciones parciales silenciosas.
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. Elija un modelo local
La etapa 7 “Elija un modelo local” funciona mejor cuando se trata como una superficie medible. Capture una transcripción exitosa, un caso de fallo y la nota de reversión antes de ampliar el alcance. Registre los tiempos y el costo de tokens o consultas junto con los resultados funcionales. Tener visibilidad del costo desde el principio evita facturas inesperadas cuando el proceso pasa de la versión de demostración a entornos compartidos. Fije el intérprete y el archivo de bloqueo de dependencias antes de enseñar el bucle. La diferencia entre el portátil y los entornos de integración continua es la causa más común de fallos silenciosos en las demostraciones de API.
gemma4:12b
export HERMES_MODEL="gemma4:12b"
8. Descargue las imágenes del contenedor
La etapa de contenedor “8 Pull” funciona mejor cuando se trata como una superficie medible. Capture un registro exitoso, un caso de fallo y la nota de reversión antes de ampliar el alcance. Mantenga la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de secretos y las banderas de funcionalidad deben estar en un lugar donde los operadores puedan auditarlos sin tener que leer todo el sistema.
podman pull docker.io/ollama/ollama:latest
podman pull docker.io/ollama/ollama:rocm
podman pull docker.io/nousresearch/hermes-agent:latest
9. Descargue el modelo en un volumen persistente
La etapa 9 de descarga del modelo funciona mejor cuando se trata como una superficie medible. Capture un registro ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Documente tanto el camino óptimo como el de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son ajustes realizados posteriormente. Fije el intérprete y el archivo de bloqueo de dependencias antes de enseñar el bucle. La diferencia entre la computadora portátil y los entornos de integración continua es la causa más común de fallos silenciosos en las demostraciones de API. La etapa 9 de descarga del modelo funciona mejor cuando se trata como una superficie medible. Capture un registro ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Trate esta etapa como un contrato entre las entradas y las salidas validadas. Asigne nombres a los artefactos, defina verificaciones de éxito y rechace las completaciones parciales silenciosas.
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. Crear una red exclusiva para uso interno
En la fase de creación de una red exclusiva para uso interno, defina las entradas, el responsable de cada paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Registre los tiempos de ejecución y el costo en tokens o consultas junto con los resultados funcionales. Tener visibilidad del costo desde el principio evita facturas inesperadas cuando la ruta pasa de entornos de demostración a entornos compartidos. Separe la construcción del cliente del bucle de mensajes para que sea posible cambiar los proveedores sin tener que reescribir la máquina de estados de la conversación.
--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. Iniciar Ollama con AMD ROCm
Para iniciar Ollama con una etapa específica, defina las entradas, el responsable de esa etapa y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar la etapa desde un punto de control conocido sin tener que adivinar el estado oculto. Mantenga la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de secretos y las banderas de funcionalidad deben estar en un lugar donde los operadores puedan auditarlos sin necesidad de leer todo el sistema. Separe la construcción del cliente del bucle de mensajes para que sea posible cambiar los proveedores sin tener que reescribir la máquina de estados de la conversación.
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. Verificar si ROCm está utilizando realmente la GPU
En la fase de 12 Verify ROCm, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Documente tanto la ruta óptima como la ruta de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores. Separe la construcción del cliente del bucle de mensajes para que sea posible cambiar los proveedores sin tener que reescribir la máquina de estados de la conversación. En la fase de 12 Verify ROCm, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Trate esta fase como un contrato entre las entradas y los resultados validados. Asigne nombres a los artefactos, defina comprobaciones de éxito y rechace las completaciones parciales silenciosas.
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. Iniciar Hermes con exactamente un montaje de carpeta de host
Al trabajar en la fase 13 de inicio de Hermes, anote primero el contrato: entradas requeridas, señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Registre los tiempos y el costo de tokens o consultas junto con los resultados funcionales. Tener visibilidad del costo desde el principio evita facturas inesperadas cuando el proceso pasa de entornos de demostración a entornos compartidos. Registre el ID de la solicitud, el ID del modelo y la latencia en cada llamada. Sin ese registro, los errores intermitentes del proveedor parecen bugs de la aplicación.
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. Verificar los límites de montaje
Al trabajar en la etapa 14 de Verificación del montaje, anote primero el contrato: los datos de entrada requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación ayuda a mantener honestas las futuras modificaciones del código. Guarde la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de secretos y las banderas de funcionalidad deben estar en un lugar donde los operadores puedan auditarlos sin tener que leer todo el sistema. Registre el ID de la solicitud, el ID del modelo y la latencia en cada llamada. Sin ese registro, los errores intermitentes del proveedor parecen ser bugs de la aplicación.
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. Verificar que Hermes pueda llegar a Ollama
Al trabajar en las 15 etapas que Verify Hermes puede implementar, anote primero el contrato: los datos requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación garantiza que los cambios posteriores en el código sean transparentes. Documente tanto la ruta de éxito como la ruta de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores. Registre el ID de la solicitud, el ID del modelo y la latencia en cada llamada. Sin ese registro, los errores intermitentes del proveedor parecen bugs de la aplicación. Al trabajar en las 15 etapas que Verify Hermes puede implementar, anote primero el contrato: los datos requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación garantiza que los cambios posteriores en el código sean transparentes. Trate esta etapa como un contrato entre los datos de entrada y los resultados validados. Asigne nombres a los artefactos, defina las comprobaciones de éxito y rechace las completaciones parciales silenciosas.
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. Verifique que el acceso a la red externa esté bloqueado
La fase 16 de Verificar que el acceso a la red externa esté bloqueado funciona mejor cuando se trata como una superficie medible. Capture una transcripción de éxito, un caso de fallo y la nota de reversión antes de ampliar el alcance. Registre los tiempos y el costo del token o consulta junto a los resultados funcionales. Tener visibilidad del costo desde temprano evita facturas inesperadas cuando el proceso pasa de la demostración a entornos compartidos. Fije el intérprete y el archivo de bloqueo de dependencias antes de explicar el bucle. La diferencia entre la computadora portátil y los entornos de integración continua es la causa más común de fallos silenciosos en las demostraciones de 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. Configure Hermes para utilizar Ollama local
La configuración 17 de Hermes para la puesta en escena funciona mejor cuando se trata como una superficie medible. Capture un registro exitoso, un caso de fallo y la nota de reversión antes de ampliar el alcance. Mantenga la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de secretos y las banderas de funcionalidad deben estar en un lugar donde los operadores puedan auditarlos sin tener que leer todo el sistema. Fije el intérprete y el archivo de bloqueo de dependencias antes de explicar el bucle. La diferencia entre la computadora portátil y el entorno CI es la causa más común de fallos silenciosos en las demostraciones de 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. Utilice el backend de terminal local de Hermes: dentro del contenedor
La etapa local de 18 Use Hermes funciona mejor cuando se trata como una superficie medible. Capture un registro ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Documente tanto el camino óptimo como el de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son ajustes realizados posteriormente. Fije el intérprete y el archivo de bloqueo de dependencias antes de explicar el bucle. La diferencia entre usar una computadora portátil y los entornos de integración continua es la causa más común de fallos silenciosos en las demostraciones de API. La etapa local de 18 Use Hermes funciona mejor cuando se trata como una superficie medible. Capture un registro ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Trate esta etapa como un contrato entre las entradas y las salidas validadas. Asigne nombres a los artefactos, defina verificaciones de éxito y evite completaciones parciales silenciosas.
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. Lanzamiento de Hermes
Para la fase 19 de lanzamiento de Hermes, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Registre los tiempos y el costo de tokens o consultas junto con los resultados funcionales. La visibilidad temprana del costo evita facturas inesperadas cuando el proceso pasa de entornos de demostración a entornos compartidos. Separe la construcción del cliente del bucle de mensajes para que sea posible cambiar los proveedores sin tener que reescribir la máquina de estados de la conversación.
podman exec -it \
--user 10000:10000 \
-w /opt/data/workspace \
hermes \
hermes
20. Iniciar el entorno automáticamente al arrancar
Para la fase de inicialización del entorno en el paso 20, defina las entradas, el responsable de dicho paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido, sin tener que adivinar el estado oculto. Mantenga la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de datos secretos y las banderas de funcionalidad deben estar en un lugar donde los operadores puedan auditarlos sin necesidad de leer todo el sistema. Separe la construcción del cliente del bucle de mensajes para que sea posible cambiar los proveedores sin tener que reescribir la máquina de estados de la conversación.
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
Resolución de problemas en los casos en que realmente ocurrieron errores
Para la resolución de problemas en esta etapa, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Documente tanto la ruta óptima como la ruta de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores. Separe la construcción del cliente del bucle de mensajes para que sea posible cambiar los proveedores sin tener que reescribir la máquina de estados de la conversación. Para la resolución de problemas en esta etapa, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Trate esta etapa como un contrato entre las entradas y los resultados validados. Asigne nombres a los artefactos, defina comprobaciones de éxito y rechace las completaciones parciales silenciosas.
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
Por qué prefiere esto en lugar de confiar simplemente en el agente
Al trabajar en la sección “¿Por qué prefiere esta etapa?”, anote primero el contrato: los datos necesarios, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación ayuda a mantener honestas las futuras modificaciones del código. Registre los tiempos y el costo de tokens o consultas junto con los resultados funcionales. Tener visibilidad del costo desde el principio evita facturas inesperadas cuando el proceso pasa de la fase de demostración a entornos compartidos. Registre el ID de la solicitud, el ID del modelo y la latencia en cada llamada. Sin ese registro, los errores intermitentes del proveedor parecen bugs de la aplicación.
Prompt restrictions
↓
Hermes file write protections
↓
Hermes container filesystem
↓
Rootless Podman user namespace
↓
Host filesystem permissions
Una nota sobre las herramientas de IA locales en constante evolución
Al trabajar en la nota A sobre la etapa de ejecución rápida, anote primero el contrato: los datos necesarios, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Guarde la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de datos secretos y las banderas de funcionalidad deben estar en un lugar donde los operadores puedan auditarlos sin tener que leer todo el sistema. Registre el ID de la solicitud, el ID del modelo y la latencia en cada llamada. Sin ese registro, los errores intermitentes del proveedor parecen ser bugs de la aplicación.
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?
Resultado final
Al trabajar en la etapa de resultado final, anote primero el contrato: los datos de entrada requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación garantiza que los cambios posteriores en el código sean transparentes. Documente tanto la ruta de éxito como la ruta de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no de mejoras posteriores. Registre el ID de la solicitud, el ID del modelo y la latencia en cada llamada. Sin ese registro, los errores intermitentes del proveedor parecen bugs de la aplicación. Al trabajar en la etapa de resultado final, anote primero el contrato: los datos de entrada requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación garantiza que los cambios posteriores en el código sean transparentes. Trate esta etapa como un contrato entre las entradas y los resultados validados. Asigne nombres a los artefactos, defina comprobaciones de éxito y rechace las completaciones parciales silenciosas.
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
Lista de verificación operativa
Al trabajar en la fase de lista de verificación operativa, anote primero el contrato: los datos necesarios, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación garantiza que los cambios posteriores en el código sean transparentes.
Prefiera unidades pequeñas y verificables a scripts extensos. Cuando un paso falla, el error debe indicar una única responsabilidad y no un proceso complicado.
Registre el ID de la solicitud, el ID del modelo y la latencia en cada llamada. Sin ese registro, los errores intermitentes del proveedor parecen bugs de la aplicación.
Mantenga el estado del grafo simple y tipado. Los bloques anidados ocultan qué nodo escribió qué campo y dificultan la reanudación después de interrupciones.
Añada una prueba básica que ejecute la ruta crítica en CI con fixtures, y no con APIs pagadas en tiempo real, siempre que lo permitan los presupuestos.
Mantenga la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de secretos y las banderas de funcionalidad deben estar en un único lugar que los operadores puedan auditar sin tener que leer todo el sistema.
Antes de promocionar la pila tecnológica, congele las versiones, guarde una transcripción de referencia para la ruta crítica y confirme los pasos para realizar un rollback. Los entornos compartidos necesitan límites de velocidad, verificaciones de tenencia y un responsable claro para la rotación de secretos. Prefiera una fiabilidad sencilla a demostraciones ingeniosas pero puntuales.
Nota para el lote bab1ff410bd9: mantenga las claves del proveedor fuera del repositorio, establezca un límite para los tokens por sesión y guarde las transcripciones junto a los archivos de prueba eval para que los cambios posteriores en el modelo sigan siendo comparables.
Lecturas relacionadas
- Notas prácticas: Construir un agente de IA autocorregible con LangGraph y Ollama — Guía paso a paso de las Notas prácticas: Construir un agente de IA autocorregible con LangGraph y Ollama: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan este patrón.
- Notas prácticas: 6A. Construir un agente de chat con AWS Bedrock y Terraform — Guía paso a paso de las Notas prácticas: 6A. Construir un agente de chat con AWS Bedrock y Terraform: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan este patrón.