Hermes opzetten op je eigen hardware

Geschreven op 31 juli 2026. De services hieronder zijn inmiddels veranderd: llama.cpp heeft het overgenomen van vLLM en het model is Qwen3.6-35B-A3B. De opzet met een proxy in het midden is precies zo gebleven, en dat is eigenlijk de kern van dit stuk.

Een lokaal taalmodel is nog geen assistent. Tussen de GPU en iets wat je echt kunt gebruiken zit een laag configuratie die bepaalt of het geheel betrouwbaar is of alleen op papier indrukwekkend. Mijn opzet bestaat uit drie systemd-services die elk één taak hebben.

De drie lagen

ServicePoortRol
vllm8000serveert het model op de Arc-GPU
litellm4000proxy, stuurt lokaal door of naar de cloud
hermes-agent9119de agent zelf, met een dashboard

De proxy in het midden is hier de belangrijkste keuze. Hermes praat nooit rechtstreeks met vLLM, altijd met LiteLLM. Daardoor is een ander model kiezen een regel configuratie in plaats van een herbouw, en kan ik per taak een ander model kiezen zonder dat de agent er iets van merkt.

hermes             -> Qwen3-14B locally, with reasoning
hermes-fast        -> same model, reasoning off
hermes-cloud-flash -> DeepSeek V4 Flash ($0.14/$0.28 per Mtok, 1M context)
hermes-vision      -> Qwen3-VL-2B on the CPU

Een les over reasoning-modellen

Die tweede route, met reasoning uit, leek gratis optimalisatie: dertig keer minder tokens voor een eenvoudig antwoord. Toen zette ik hem in voor het automatisch taggen van documenten. Met 412 bestaande tags in de prompt hield het model op met kiezen en begon het de lijst uit te breiden. Negenenzeventig tags, geen einde in zicht, tot de client het na vijf minuten opgaf. Een repetition penalty maakte de tags uniek zonder de stroom te stoppen. Pas met reasoning aan kwam er een net antwoord van vijf tot zeven tags terug. Sindsdien is de snelle route bedoeld voor eenvoudig werk, en nooit voor kiezen uit een lange lijst.

Integraties, en waarom het wrappers werden

De agent praat met Paperless-ngx, Linkwarden, Radarr, Sonarr, Lidarr, Plex en een selfhosted SearXNG. In het begin liet ik het model die API’s zelf aanroepen. Dat ging mis op een manier die ik had onderschat: het verzon endpoints die aannemelijk klinken en niet bestaan, las de foutcode verkeerd, en raadde me daarna aan serverinstellingen te wijzigen om een probleem op te lossen dat er nooit was.

Wat het oploste was een kleinere opdracht, geen groter model. Overal waar iets verzonnens onopgemerkt zou blijven, staat nu een getest commando in /usr/local/bin: paperless-upload, linkwarden-search, linkwarden-add. Het model maakt op dat punt niets meer zelf. Het geeft alleen dingen door. Elk script leest zijn sleutels rechtstreeks uit het configuratiebestand en stopt hard bij een lege waarde, want een leeg token geeft een 401 die verdacht veel op een serverfout lijkt.

Wat ik zou meenemen

Twee dingen. Zet een proxy tussen je agent en je model, ook als je maar één model hebt, want je wilt later wisselen zonder iets kapot te maken. En de grens tussen wat je het model laat doen en wat je in code vastlegt, volgt niet de moeilijkheid. Die volgt hoe zichtbaar je fouten zijn. Code die je zelf kunt nalezen, mag het model prima schrijven. Een lijst met je eigen data niet.

← Alle berichten