128 GB einheitlicher Arbeitsspeicher. Bis zu 96 GB für die GPU. Hermes Agent, der auf localhost zeigt, anstatt auf fremde Server
„Jeder sagt, lokale Agenten sind kostenlos. Ich glaube nicht, dass das der richtige Blickwinkel ist." Den Hermes Agent auf Cloud-Modellen zu betreiben, kostete täglich 10–20 Dollar an Credits – zusätzlich zum Sicherheitsrisiko, API-Schlüssel, Kundendaten und Geschäftsabläufe durch fremde Server zu leiten. Die Lösung besteht darin, den Agenten und das von ihm genutzte Modell auf eigener Hardware laufen zu lassen, rund um die Uhr, sodass das Ganze zur Infrastruktur wird statt zu einer wiederkehrenden Rechnung
Dies ist ein Bauprotokoll, kein Vergleich: Minisforum MS-S1 MAX als Dauerläufer-Maschine, Hermes Agent als Workflow-Ebene darauf. Zusammen ergeben sie ein Setup, das im Schrank steht, dauerhaft läuft und reale Geschäftsaufgaben erledigt – Inhalte entwerfen, Recherche betreiben, Tool-Aufrufe ausführen, Unter-Agenten verwalten – ohne Cloud-Kosten pro Token und ohne dass Daten das Netzwerk verlassen. Nachfolgend: Was im MS-S1 MAX steckt, wie man ihn einrichtet, die echten Leistungszahlen und wie man Hermes Agent als funktionierende Geschäftsautomatisierung darauf aufbaut
Die Hardware: Was im MS-S1 MAX steckt
Der MS-S1 MAX basiert auf AMDs Strix-Halo-Plattform – derzeit der leistungsfähigste Mini-PC-Chip zum lokalen Ausführen großer Sprachmodelle, da er eine starke CPU mit der größten integrierten GPU kombiniert, die AMD je in diesem Formfaktor ausgeliefert hat. Das ist der Unterschied zwischen einer Maschine, die nur einfache Chats bewältigt, und einer, die eine echte Agenten-Schleife mit Tool-Aufrufen, Unter-Agenten und langem Kontext eigenständig ausführen kann
SoC-Daten (AMD Ryzen AI Max+ 395, 4 nm Strix Halo, 45–120 W TDP):
1ComponentSpecCPU16 Kerne / 32 Threads, Zen 5, 3,0 GHz Basis – 5,1 GHz Boost, 64 MB L3-CacheGrafikRadeon 8060S, 40 CU RDNA 3.5, 2,9 GHz, systemweit geteilter VRAMNPUXDNA, 50 TOPSPCIeGen 4, 16 LanesRAMLPDDR5X, 8000 MT/s, bis zu 128 GB, Quad-Channel, 256 GB/s Bandbreite
Die iGPU mit 40 CU / 2560 Shader-Einheiten ist in ihrer Rohleistung ungefähr mit einer diskreten RX 7600 XT vergleichbar – integriert in einen Mini-PC, der klein genug ist, um 24/7 auf einem Regal zu laufen
Warum die iGPU hier härter arbeitet als in Laptops: Die 8060S ist in Laptop-Gehäusen normalerweise auf etwa 55 W begrenzt. Die größere Kühllösung des MS-S1 MAX (6 Heatpipes, zwei Lüfter) erlaubt es Minisforum, die Leistungsgrenze im Performance-Modus auf 120 W zu erhöhen, mit entsprechend höheren dauerhaften Taktraten – wichtig für eine Maschine, die Inference kontinuierlich und nicht nur in kurzen Stößen ausführen soll
Der RAM-Trick, der den Geschäftsworkflow ermöglicht: Der MS-S1 MAX wird mit 128 GB verlötetem, einheitlichem, Quad-Channel-LPDDR5X ausgeliefert. Der AMDGPU-Treiber kann über die GTT (Graphics Translation Table) System-RAM als VRAM zuweisen, und bei dieser Maschine kann die iGPU bis zu 96 GB dieses Pools beanspruchen, sodass 32 GB für die CPU übrig bleiben. Diese 96-GB-Grenze bedeutet, dass diese einzelne Maschine ein wirklich leistungsfähiges Modell hosten kann und dabei gleichzeitig den Agentenprozess, das Dashboard und andere ständig laufende Dienste auf demselben Rechner ausführt
Einrichten der Modellebene (llama.cpp auf Strix Halo)
Für die Wartung vorgefertigter Toolbox-Container für llama.cpp auf Strix Halo über mehrere Backends: vulkan-amdvlk, vulkan-radv, rocm-6.4.4, rocm-6.4.4-rocwmma, rocm-7rc-rocwmma. Sie sind hauptsächlich für den HP G1a Mini (derselbe Strix-Halo-Chip) gebaut, funktionieren aber auf den meisten Strix-Halo-Maschinen, einschließlich des MS-S1 MAX. Das vulkan-radv-Backend war in Tests am stabilsten und lädt die größeren Modelle problemlos
BIOS/UEFI: Minimale VRAM-Zuweisung auf 1 GB setzen (das Minimum im Minisforum-BIOS), damit der AMDGPU-Treiber System-RAM über GTT als VRAM zuweisen kann
Kernel-Parameter (getestet auf Arch Linux, aber jede aktuelle Distribution mit Strix-Halo-Kernel-Unterstützung sollte funktionieren), um die VRAM-Zuweisung zu maximieren und die Latenz zu reduzieren:
amd_iommu=off amdgpu.gttsize=131072 amdttm.pages_limit=33554432 amdttm.page_pool_size=15728640
Toolbox mit GPU-Durchleitung erstellen:
toolbox create llama-vulkan-radv
--image docker.io/kyuz0/amd-strix-halo-toolboxes:vulkan-radv
-- --device /dev/dri --group-add video --security-opt seccomp=unconfined
In die Toolbox wechseln:
toolbox enter llama-vulkan-radv
In der Toolbox sind llama-cli und llama-server bereit, Modelle auszuführen. Alle Ebenen auf die GPU zwingen, damit die CPU für alles andere frei bleibt (Agentenprozess, Tailscale, Dashboards):
1# Nur Terminal2llama-cli --no-mmap -ngl 999 --flash-attn on -m <model>34# Webserver-UI – darauf wird Hermes Agent zeigen5llama-server --no-mmap -ngl 999 --flash-attn on --host <ip_address> --port <port_number> -m <model>
Die hier verwendeten Modelle stammen von Unsloth auf Hugging Face, im GGUF-Format.
Wechseln zwischen Modellen: llama-swap erleichtert das Austauschen des Modells, das den Agenten bedient, ohne manuell etwas neu starten zu müssen – das Linux-Binary herunterladen, chmod +x ausführen und eine config.yaml definieren
1models:2 "OpenAI-20B-GPT-OOS":3 cmd: |4 llama-server --no-mmap -ngl 999 --flash-attn on --port ${PORT} -m /models/gpt-oss-20b-GGUF/gpt-oss-20b-F16.gguf -c 400005 "gemma-3-27b-it-abliterated":6 cmd: |7 llama-server --no-mmap -ngl 999 --flash-attn on --port ${PORT} -m /models/gemma-3-27b-it-abliterated-GGUF/gemma-3-27b-it-abliterated.q6_k.gguf -c 400008 "OpenAI-20B-NEO-CODEPlus":9 cmd: |10 llama-server --no-mmap -ngl 999 --flash-attn on --port ${PORT} -m /models/OpenAI-20B-NEO-CODEPlus-Q5_1/OpenAI-20B-NEO-CODEPlus-Q5_1.gguf -c 4000011 "OpenAI-120B-GPT-OOS":12 cmd: |13 llama-server --no-mmap -ngl 999 --flash-attn on --port ${PORT} -m /models/gpt-oss-120b-GGUF/gpt-oss-120b-UD-Q4_K_XL-00001-of-00002.gguf -c 40000
Dies bietet ein Web-UI zum Wechseln von Modellen für verschiedene Aufgaben (leichteres/schnelleres Modell für schnelle Antworten, das 120B für alles, was mehr Überlegung erfordert), ohne die Maschine direkt zu berühren – und der Chatverlauf bleibt beim Wechsel erhalten
Die Leistungszahlen (Warum diese Maschine eine Agenten-Workload bewältigen kann)
Mit llama-bench für Prompt-Verarbeitung (pp512) und Textgenerierung (tg128):
1ModelSizePrompt Processing (t/s)Text Generation (t/s)GPT-OSS-120B (Q4_K_XL)58.7GB454.15 ± 2.9856.61 ± 0.03GPT-OSS-20B (F16)12.8GB965.54 ± 9.5646.84 ± 0.06Gemma-3-27B (Q6_K)20.6GB178.14 ± 1.099.65 ± 0.01Qwen3-30B-A3B (BF16)56.9GB163.01 ± 1.339.23 ± 0.04
Die Zahl, die für einen ständig laufenden Agenten zählt: ein 120B-Modell, vollständig lokal, generiert mit 56,6 Token pro Sekunde. Das ist schnell genug, dass Hermes Agent mehrstufige Tool-Calling-Ketten ausführen kann, ohne dass jede Aufgabe zu einer langen Wartezeit wird.
Reale Auslastungstests: Die Eingabe „Verfasse einen Aufsatz über LLMs (5000 Wörter)" in GPT-OSS-120B produzierte 7.990 Token bei 51,2 Token/Sekunde. Die Leistungsaufnahme lag im Durchschnitt bei etwa 110 W auf der iGPU, die Randtemperatur pendelte sich bei etwa 68–69 °C ein – leise und nicht besonders heiß, dank des Kühlers mit 6 Heatpipes und zwei Lüftern sowie eines BIOS-Updates auf Version 1.03, das die Lüfterkennlinie verbesserte. Dieses Leistungs- und Wärmeprofil macht es realistisch, diese Maschine 24/7 als Geschäftsrechner laufen zu lassen – eine Brandgefahr ist sie nicht
NPU: Die XDNA-2-NPU (50 TOPS) wurde in diesem Setup noch nicht genutzt – die Unterstützung ist noch unreif. FastFlowLM, ein Projekt, das LLM-Inference auf Ryzen-AI-NPUs ermöglicht, sieht vielversprechend aus als zukünftige Möglichkeit, noch mehr der Workload auszulagern, erfordert aber derzeit Windows
Die Workflow-Ebene: Hermes Agent darauf aufbauen
Hier verwandelt sich die Maschine von einem Benchmark in ein echtes Geschäftswerkzeug. Hermes Agent ist die Ebene, die das lokale Modell von oben nimmt und in etwas verwandelt, das Dinge tut: Inhalte entwerfen, Tool-Aufrufe ausführen, browsen, Unter-Agenten verwalten und nach einem Zeitplan handeln
1. Hermes Agent installieren und auf das lokale Modell ausrichten. Die Einrichtung von Hermes fragt nach einem Modellanbieter. Lokal/selbst gehostet mit OpenAI-Kompatibilität wählen, auf localhost:<port> zeigen, wo llama-server läuft, und den API-Schlüssel überspringen, da es lokal ist. Hermes wünscht eine minimale Kontextlänge von 64.000 Token – erhöhen, wenn der Workflow umfangreiches Codieren oder lange Dokumente umfasst, niedriger lassen für kurze Aufgaben wie E-Mails oder Social-Media-Beiträge
2. Das lokale Modell als Standard festlegen, nicht als einzige Option. Das reale Produktionssetup ist von Natur aus hybrid – nicht, weil die Hardware nicht mithalten könnte, sondern weil manche Aufgaben wirklich kein 120B-Modell brauchen: schnelle Antworten, einfache Formatierung, kurze Abfragen. Das lokale Modell als Standard festlegen, dann einen Fallback-Anbieter (OpenAI, Claude oder Open Router) mit Routing-Anweisungen für die Fälle hinzufügen, in denen er tatsächlich Mehrwert bringt – schwere Tool-Calling-Ketten, lange Debugging-Schleifen oder Aufgaben, bei denen Geschwindigkeit wichtiger ist als Privatsphäre. Open Router ist ein günstiger Weg, dies zu tun: 10 Dollar geben etwa 1.000 Anfragen, nützlich als Druckventil für nicht kritische Unter-Agenten-Aufgaben
3. 24/7 laufen lassen. Ein Geschäftsworkflow funktioniert nur, wenn er nicht ausfällt, sobald man den Laptop zuklappt. Hermes Agent so einrichten, dass er beim Booten automatisch neu startet:
1sudo systemctl enable tailscaled2sudo systemctl enable hermes-agent
Jeder KI-Code-Assistent (Codex, Claude, Gemini, Warp) kann die entsprechende Service-Datei generieren, falls Hermes Agent nicht standardmäßig als systemd-Dienst installiert wurde
4. Von überall mit Tailscale darauf zugreifen. Das macht aus dem MS-S1 MAX von „einer Maschine, vor der ich sitzen muss" eine Infrastruktur. Tailscale (kostenloser persönlicher Plan, bis zu sechs Benutzer) auf dem Mini-PC und auf dem Gerät installieren, mit dem man täglich arbeitet – Laptop, Telefon. Sobald beide im selben Tailscale-Netzwerk sind:
- Per SSH vom Laptop aus auf den Mini-PC zugreifen, um Admin-Befehle auszuführen, die der Agent selbst nicht ausführen kann
- Das Hermes-Agent-Dashboard remote öffnen, als ob es auf localhost liefe, obwohl es physisch auf einer Maschine im selben Raum oder im anderen Ende des Landes ist
- Auf iOS, da einige Terminal-Apps (Termius) den SSH-Handshake überspringen, den Tailscale erwartet, den SSH-Zugriffsmodus in Tailscales Zugriffskontrollen auf „accept" setzen, damit das Telefon eine Verbindung herstellen kann – nützlich, um einen hängengebliebenen Workflow zu beheben, wenn man nicht am Schreibtisch ist
5. Den Agenten die Geschäftsaufgaben erledigen lassen. Wenn der Stack so verdrahtet ist, sieht das tägliche Muster so aus: Recherche, Texte, Zusammenfassungen und routinemäßige Tool-Aufrufe laufen kostenlos lokal auf dem MS-S1 MAX, Ergebnisse werden per Telegram, einem Dashboard oder einer anderen Integration von Hermes weitergeleitet. Alles, was schnell sein muss (Echtzeit, kundenorientiert) oder Überlegungen erfordert, die das lokale Modell wirklich nicht bieten kann, wird per Ausnahme zum Fallback-Anbieter geleitet – nicht standardmäßig
Warum die Hardwarewahl bestimmt, wie viel davon man tatsächlich bekommt
Das lokale Modell ist der Engpass für alles darüber. Ein 9B-Modell mit niedrigen zweistelligen Token pro Sekunde kann Hermes Agent ausführen, aber mehrstufige Agentenaufgaben mit Unter-Agenten und Tool-Aufrufen dauern viele Minuten, was begrenzt, wie viel der Workload realistisch lokal bleiben kann, bevor das Fallback-Routing übernehmen muss. Ein lokales Modell der 120B-Klasse mit 56+ Token/Sekunde ändert, wie viel der täglichen Workload die lokale Maschine allein bewältigen kann – mehr der Geschäftslogik bleibt auf eigener Hardware, und der Cloud-Fallback wird zum Werkzeug für echte Randfälle statt zum Standardweg für alles, was nicht trivial ist
Privatsphäre ist der Teil, der sich mit der Hardware nicht ändert. Unabhängig davon, welches Modell lokal läuft, verlassen API-Schlüssel, Kundendaten und Geschäftsabläufe niemals das Netzwerk. Das gilt auf einem Raspberry Pi mit einem winzigen Modell und gilt auf dem MS-S1 MAX mit einem 120B-Modell – die Hardware bestimmt nur, wie viel sinnvolle Arbeit erledigt wird, bevor man zur Cloud-Option greifen muss
Praktische Erkenntnis
Für einen 24/7 laufenden lokalen Agenten-Stack, der tatsächlich Geschäftsworkflows tragen soll – nicht nur eine Chat-Antwort demonstrieren – sind die Anforderungen: genug einheitlicher Speicher, um ein wirklich leistungsfähiges Modell zu laden, genug dauerhafte Leistungs-/Wärmekapazität, um dieses Modell kontinuierlich laufen zu lassen, und eine niedrig genuge Leerlaufleistungsaufnahme, dass das Dauerlaufen nicht als echter Kostenfaktor auffällt
Die 96 GB adressierbare iGPU-Speicher, 110 W dauerhafte Lastleistungsaufnahme und leise Kühlung mit 6 Heatpipes des MS-S1 MAX decken die Hardwareseite davon ab. Hermes Agent, auf den lokal laufenden llama-server ausgerichtet und von überall per Tailscale erreichbar, deckt die Workflow-Seite ab. Zusammen ergibt das einen einzigen Mini-PC, der im Schrank stehen kann, dauerhaft läuft und einen bedeutenden Teil der täglichen KI-Workload eines Unternehmens ausführen kann – ohne wiederkehrende Cloud-Rechnung und ohne dass Daten das Gebäude verlassen
Für den allgemeinen Arbeitsplatzgebrauch bietet der MS-S1 MAX außerdem PCIe- und Dual-M.2-Erweiterung, etwa 5 W Leerlaufleistung, Dual-10-Gbit/s-Ethernet und USB4 v2 (80 Gbit/s) – nichts davon ist LLM-spezifisch, aber alles ist wichtig, wenn diese Maschine doppelte Aufgaben als mehr als nur der Agentenrechner übernimmt
