128 GB di memoria unificata. Fino a 96 GB assegnabili alla GPU. Hermes Agent puntato su localhost invece che sui server di qualcun altro.
«Tutti dicono che gli agenti locali sono gratis. Non credo sia il modo giusto di vederla». Eseguire Hermes Agent su modelli cloud costava 10-20 $ al giorno in crediti, senza contare il rischio per la privacy di instradare chiavi API, dati dei clienti e flussi di lavoro aziendali attraverso server altrui. La soluzione è mettere l'agente e il modello che utilizza su hardware di tua proprietà, in esecuzione 24/7, così che l'intero sistema diventi infrastruttura invece di una fattura ricorrente.
Questo è un diario di costruzione, non un confronto: Minisforum MS-S1 MAX come macchina sempre accesa, Hermes Agent come strato operativo che ci gira sopra. Insieme formano un setup che sta in un armadio, rimane acceso permanentemente e gestisce compiti aziendali reali – redigere contenuti, fare ricerche, eseguire chiamate a strumenti, gestire sotto-agenti – senza costi per token nel cloud e senza che i dati lascino la rete. Qui sotto: cosa c'è dentro l'MS-S1 MAX, come configurarlo, i numeri reali delle prestazioni e come collegare Hermes Agent come stack di automazione aziendale funzionante.
L'hardware: cosa c'è dentro l'MS-S1 MAX
L'MS-S1 MAX è basato sulla piattaforma AMD Strix Halo – attualmente il silicio più performante per mini PC per eseguire localmente modelli linguistici di grandi dimensioni, perché abbina una CPU potente alla GPU integrata più grande che AMD abbia mai spedito in questo formato. È la differenza tra una macchina che può gestire solo semplici chat e una che può eseguire un vero ciclo di agente con chiamate a strumenti, sotto-agenti e contesto lungo in autonomia.
Specifiche del SoC (AMD Ryzen AI Max+ 395, Strix Halo a 4 nm, TDP 45-120 W):
1ComponenteSpecificaCPU16 core / 32 thread, Zen 5, 3.0 GHz base – 5.1 GHz boost, 64 MB cache L3GPU Radeon 8060S, 40 CU RDNA 3.5, 2.9 GHz, VRAM condivisa di sistemaNPUXDNA, 50 TOPSPCIeGen 4, 16 lineeRAMLPDDR5X, 8000 MT/s, fino a 128 GB, quad channel, larghezza di banda 256 GB/s
La iGPU da 40 CU / 2560 unità di shading è grossomodo paragonabile a una scheda discreta RX 7600 XT in termini di potenza grezza, il tutto integrato in un mini PC abbastanza piccolo da poter restare acceso 24/7 su uno scaffale.
Perché la iGPU lavora più duramente qui rispetto ai laptop: di solito la 8060S è limitata a circa 55 W nei chassis dei portatili. Il sistema di raffreddamento più generoso dell'MS-S1 MAX (6 heatpipe, doppia ventola) permette a Minisforum di spingere il limite di potenza a 120 W in modalità prestazioni, con clock sostenuti corrispondentemente più alti – importante per una macchina pensata per eseguire inferenza in modo continuo, non a brevi raffiche.
Il trucco della RAM che rende possibile il flusso di lavoro aziendale: l'MS-S1 MAX monta 128 GB di LPDDR5X unificata, saldata e in configurazione quad-channel. Il driver AMDGPU può allocare RAM di sistema come VRAM tramite GTT (Graphics Translation Table), e su questa macchina la iGPU può arrivare a utilizzare fino a 96 GB di quel pool, lasciando 32 GB alla CPU. Questo tetto di 96 GB significa che questa singola macchina può ospitare un modello davvero capace e farlo mentre esegue il processo agente, la dashboard e altri servizi sempre accesi sullo stesso sistema.
Configurare il livello del modello (llama.cpp su Strix Halo)
per mantenere i contenitori Toolbox precompilati per llama.cpp su Strix Halo, con diversi backend: vulkan-amdvlk, vulkan-radv, rocm-6.4.4, rocm-6.4.4-rocwmma, rocm-7rc-rocwmma. Sono costruiti principalmente per l'HP G1a Mini (stesso chip Strix Halo), ma funzionano sulla maggior parte delle macchine Strix Halo, inclusa l'MS-S1 MAX. Il backend vulkan-radv si è dimostrato il più stabile nei test e carica i modelli più grandi senza problemi.
BIOS/UEFI: impostare l'allocazione minima di VRAM a 1 GB (il minimo del BIOS Minisforum) in modo che il driver AMDGPU sia libero di allocare RAM di sistema come VRAM tramite GTT.
Parametri del kernel (testati su Arch Linux, ma qualsiasi distribuzione recente con supporto del kernel per Strix Halo dovrebbe funzionare) per massimizzare l'allocazione di VRAM e ridurre la latenza:
amd_iommu=off amdgpu.gttsize=131072 amdttm.pages_limit=33554432 amdttm.page_pool_size=15728640
Creare il toolbox con pass-through della GPU:
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
Entrarci:
toolbox enter llama-vulkan-radv
All'interno, llama-cli e llama-server sono pronti per eseguire i modelli. Forzare tutti i livelli sulla GPU in modo che la CPU resti libera per tutto il resto (il processo agente, Tailscale, le dashboard):
1# Solo terminale2llama-cli --no-mmap -ngl 999 --flash-attn on -m <modello>34# Interfaccia web server – è quella a cui punterà Hermes Agent5llama-server --no-mmap -ngl 999 --flash-attn on --host <indirizzo_ip> --port <numero_porta> -m <modello>
I modelli qui utilizzati provengono da Unsloth su Hugging Face, in formato GGUF.
Passare da un modello all'altro: llama-swap semplifica la sostituzione del modello che serve l'agente senza dover riavviare nulla manualmente – scaricare il binario Linux, eseguire chmod +x e definire un file config.yaml:
1modelli:2 "OpenAI-20B-GPT-OOS":3 comando: |4 llama-server --no-mmap -ngl 999 --flash-attn on --port ${PORT} -m /modelli/gpt-oss-20b-GGUF/gpt-oss-20b-F16.gguf -c 400005 "gemma-3-27b-it-abliterated":6 comando: |7 llama-server --no-mmap -ngl 999 --flash-attn on --port ${PORT} -m /modelli/gemma-3-27b-it-abliterated-GGUF/gemma-3-27b-it-abliterated.q6_k.gguf -c 400008 "OpenAI-20B-NEO-CODEPlus":9 comando: |10 llama-server --no-mmap -ngl 999 --flash-attn on --port ${PORT} -m /modelli/OpenAI-20B-NEO-CODEPlus-Q5_1/OpenAI-20B-NEO-CODEPlus-Q5_1.gguf -c 4000011 "OpenAI-120B-GPT-OOS":12 comando: |13 llama-server --no-mmap -ngl 999 --flash-attn on --port ${PORT} -m /modelli/gpt-oss-120b-GGUF/gpt-oss-120b-UD-Q4_K_XL-00001-of-00002.gguf -c 40000
Questo fornisce un'interfaccia web per cambiare modello in base al compito (un modello più leggero/veloce per risposte rapide, il 120B per qualsiasi cosa richieda più ragionamento) senza toccare direttamente la macchina – e la cronologia chat viene mantenuta durante il passaggio.
I numeri delle prestazioni (perché questa macchina può sostenere un carico di lavoro da agente)
Utilizzando llama-bench per l'elaborazione del prompt (pp512) e la generazione di testo (tg128):
1ModelloDimensioniElaborazione Prompt (t/s)Generazione Testo (t/s)GPT-OSS-120B (Q4_K_XL)58,7 GB454,15 ± 2,9856,61 ± 0,03GPT-OSS-20B (F16)12,8 GB965,54 ± 9,5646,84 ± 0,06Gemma-3-27B (Q6_K)20,6 GB178,14 ± 1,099,65 ± 0,01Qwen3-30B-A3B (BF16)56,9 GB163,01 ± 1,339,23 ± 0,04
Il numero che conta per un agente sempre attivo: un modello da 120B, completamente locale, che genera a 56,6 token/secondo. È abbastanza veloce da permettere a Hermes Agent di eseguire catene di chiamate a strumenti in più passaggi senza che ogni attività si trasformi in una lunga attesa.
Test di carico reale: chiedendo a GPT-OSS-120B di "Generare un saggio sugli LLM (5000 parole)" ha prodotto 7.990 token a 51,2 token/secondo. Il consumo energetico medio era di circa 110 W sulla iGPU, con la temperatura di bordo stabilizzata intorno ai 68-69 °C – silenzioso e non particolarmente caldo, grazie al dissipatore con 6 heatpipe e doppia ventola e a un aggiornamento del BIOS alla versione 1.03 che ha migliorato la curva della ventola. Questo profilo di potenza e termico è ciò che rende realistico lasciarlo acceso 24/7 come macchina aziendale, senza che diventi un pericolo d'incendio.
NPU: la NPU XDNA 2 (50 TOPS) non è stata utilizzata in questa configurazione – il supporto è ancora acerbo. FastFlowLM, un progetto che abilita l'inferenza di LLM sulle NPU Ryzen AI, sembra promettente come futuro modo per scaricare ancora più carico di lavoro, ma attualmente richiede Windows.
Il livello operativo: collegare Hermes Agent sopra
È qui che la macchina si trasforma da semplice punto di riferimento per benchmark a vero strumento aziendale. Hermes Agent è lo strato che prende il modello locale di cui sopra e lo trasforma in qualcosa che fa cose: redige contenuti, esegue chiamate a strumenti, naviga, gestisce sotto-agenti e agisce in base a una pianificazione.
1. Installare Hermes Agent e puntarlo al modello locale. La procedura di onboarding di Hermes chiede un provider di modello. Scegliere locale/self-hosted compatibile con OpenAI, puntarlo a localhost:<porta> dove è in esecuzione llama-server, e saltare la chiave API poiché è locale. Hermes richiede specificamente una lunghezza minima del contesto di 64.000 token – aumentarla se il flusso di lavoro prevede codifica pesante o documenti lunghi, tenerla più bassa per attività brevi come email o post sui social.
2. Impostare il modello locale come predefinito, non come unica opzione. La configurazione di produzione reale è ibrida per progettazione, ma non perché l'hardware non regga – bensì perché alcune attività non necessitano davvero di un modello locale da 120B: risposte rapide, formattazione semplice, brevi ricerche. Impostare il modello locale come predefinito, poi aggiungere un provider di fallback (OpenAI, Claude o Open Router) con istruzioni di instradamento per i casi in cui aggiunge effettivamente valore – catene di chiamate a strumenti pesanti, lunghi cicli di debug o attività in cui la velocità conta più della privacy. Open Router è un modo economico per farlo: 10 $ bastano per circa 1.000 richieste, utile come valvola di sfogo per attività non critiche dei sotto-agenti.
3. Tenerlo acceso 24/7. Un flusso di lavoro aziendale funziona solo se non si spegne quando chiudi il portatile. Abilitare il riavvio automatico di Hermes Agent all'avvio:
1sudo systemctl enable tailscaled2sudo systemctl enable hermes-agent
Qualsiasi assistente di codifica AI (Codex, Claude, Gemini, Warp) può generare il file di servizio equivalente se Hermes Agent non è stato installato come servizio systemd per impostazione predefinita.
4. Raggiungerlo da qualsiasi luogo con Tailscale. Questo è ciò che trasforma l'MS-S1 MAX da "una macchina davanti a cui devo sedermi" in infrastruttura. Installare Tailscale (piano personale gratuito, fino a sei utenti) sul mini PC e su qualsiasi dispositivo con cui lavori quotidianamente – portatile, telefono. Una volta che entrambi sono sulla stessa rete Tailscale:
- Collegarsi in SSH al mini PC dal portatile per eseguire comandi amministrativi che l'agente non può eseguire da solo.
- Aprire la dashboard di Hermes Agent da remoto come se fosse in esecuzione su localhost, anche se fisicamente la macchina è in un'altra stanza o in un altro paese.
- Su iOS, dato che alcune app terminale (Termius) saltano l'handshake SSH previsto da Tailscale, impostare la modalità di accesso SSH su "accetta" nei controlli di accesso di Tailscale in modo che il telefono possa connettersi – utile per risolvere un flusso di lavoro bloccato quando non si è alla scrivania.
5. Lasciare che l'agente gestisca le attività aziendali. Con lo stack cablato in questo modo, lo schema quotidiano è: ricerca, scrittura, riassunti e chiamate a strumenti di routine vengono eseguiti localmente sull'MS-S1 MAX gratuitamente, con i risultati inviati tramite Telegram, una dashboard o qualsiasi altra integrazione supporti Hermes. Qualsiasi attività che debba essere veloce (in tempo reale, rivolta al cliente) o che richieda un ragionamento che il modello locale non può eguagliare viene instradata al provider di fallback per eccezione, non per impostazione predefinita.
Perché la scelta dell'hardware determina quanto di tutto questo ottieni effettivamente
Il modello locale è il collo di bottiglia per tutto ciò che sta sopra. Un modello da 9B a basse decine di token/secondo può eseguire Hermes Agent, ma le attività agente in più passaggi con sotto-agenti e chiamate a strumenti si allungano fino a diversi minuti, limitando quanto del carico di lavoro può realisticamente rimanere locale prima che l'instradamento di fallback debba subentrare. Un modello locale della classe 120B a 56+ token/secondo cambia quanto del carico di lavoro quotidiano la macchina locale può assorbire da sola – più logica aziendale rimane su hardware di tua proprietà e il fallback cloud diventa uno strumento per veri casi limite, invece del percorso predefinito per qualsiasi cosa non banale.
La privacy è la parte che non cambia con l'hardware. Qualunque modello sia in esecuzione localmente, le chiavi API, i dati dei clienti e i flussi di lavoro aziendali non lasciano mai la rete. Questo vale su un Raspberry Pi che esegue un modello minuscolo, e vale sull'MS-S1 MAX che ne esegue uno da 120B – l'hardware decide solo quanto lavoro utile viene svolto prima di dover ricorrere all'opzione cloud.
Conclusioni pratiche
Per uno stack agente locale 24/7 pensato per gestire effettivamente flussi di lavoro aziendali – non solo per dimostrare una risposta in chat – i requisiti sono: memoria unificata sufficiente per caricare un modello davvero capace, margine di potenza/termico sostenuto per eseguire quel modello in modo continuo e un consumo a riposo sufficientemente basso da non rappresentare una spesa reale se lasciato acceso.
La memoria iGPU indirizzabile fino a 96 GB dell'MS-S1 MAX, il carico sostenuto di 110 W e il raffreddamento silenzioso a 6 heatpipe coprono il lato hardware. Hermes Agent, puntato su llama-server in esecuzione locale e raggiungibile da qualsiasi luogo tramite Tailscale, copre il lato operativo. Insieme formano un singolo mini PC che può stare in un armadio, rimanere acceso permanentemente ed eseguire una parte significativa del carico di lavoro AI quotidiano di un'azienda senza fatture cloud ricorrenti e senza che i dati lascino l'edificio.
Per uso generale come workstation, l'MS-S1 MAX offre anche espansione PCIe e dual M.2, consumo a riposo di circa 5 W, doppia Ethernet a 10 Gbps e USB4 v2 (80 Gbps) – nessuna di queste caratteristiche è specifica per LLM, ma tutte sono importanti se questa macchina svolge un doppio ruolo, non solo come agente.
