128GB de memória unificada. Até 96GB para a GPU. Hermes Agent apontado para localhost em vez de servidores de terceiros
"Todo mundo diz que agentes locais são gratuitos. Acho que essa não é a melhor forma de enxergar isso." Executar o Hermes Agent em modelos na nuvem estava custando de $10 a $20 por dia em créditos, além do risco de privacidade ao rotear chaves de API, dados de clientes e fluxos de trabalho de negócios pelos servidores de outra pessoa. A solução é colocar o agente e o modelo que ele utiliza em hardware próprio, funcionando 24 horas por dia, 7 dias por semana, transformando tudo em infraestrutura em vez de uma conta recorrente.
Este é um registro de construção, não uma comparação: Minisforum MS-S1 MAX como a máquina sempre ligada, Hermes Agent como a camada de fluxo de trabalho sobre ela. Juntos, formam uma configuração que fica em um armário, permanece ligada permanentemente e lida com tarefas reais de negócios – criar conteúdo, realizar pesquisas, executar chamadas de ferramentas, gerenciar subagentes – sem custo por token na nuvem ou dados saindo da rede. Abaixo: o que há dentro do MS-S1 MAX, como configurá-lo, os números reais de desempenho e como conectar o Hermes Agent sobre ele como uma pilha de automação de negócios funcional.
O Hardware: O Que Há Dentro do MS-S1 MAX
O MS-S1 MAX é construído na plataforma AMD Strix Halo – atualmente o silício de mini PC mais capaz para executar grandes modelos de linguagem localmente, pois combina uma CPU potente com a maior GPU integrada que a AMD já enviou para este formato. Essa é a diferença entre uma máquina que só consegue lidar com chats simples e uma que pode executar um loop de agente real com chamadas de ferramentas, subagentes e contexto longo de forma autônoma.
Especificações do SoC (AMD Ryzen AI Max+ 395, Strix Halo de 4nm, TDP de 45-120W):
1ComponenteEspecificaçãoCPU16 núcleos / 32 threads, Zen 5, 3.0 GHz base – 5.1 GHz boost, 64MB de cache L3GráficosRadeon 8060S, 40 CU RDNA 3.5, 2.9 GHz, VRAM compartilhada com o sistemaNPUXDNA, 50 TOPSPCIeGen 4, 16 pistasRAMLPDDR5X, 8000 MT/s, até 128GB, quad channel, largura de banda de 256GB/s
A iGPU de 40 CUs / 2560 unidades de sombreamento é aproximadamente comparável a uma RX 7600 XT discreta em desempenho bruto, integrada em um mini PC pequeno o suficiente para ficar funcionando 24/7 em uma prateleira.
Por que a iGPU trabalha mais aqui do que em laptops: a 8060S é normalmente limitada a cerca de 55W em chassis de laptop. A solução de resfriamento maior do MS-S1 MAX (6 heatpipes, ventoinhas duplas) permite que a Minisforum aumente o limite de potência para 120W no modo de desempenho, com clocks sustentados correspondentemente mais altos – importante para uma máquina projetada para executar inferência continuamente, não em rajadas curtas.
O truque de RAM que torna o fluxo de trabalho de negócios possível: o MS-S1 MAX vem com 128GB de LPDDR5X soldada, unificada e em quad channel. O driver AMDGPU pode alocar RAM do sistema como VRAM através da GTT (Tabela de Tradução de Gráficos) e, nesta máquina, a iGPU pode reivindicar até 96GB desse pool, deixando 32GB para a CPU. Esse limite de 96GB significa que esta única máquina pode hospedar um modelo genuinamente capaz e fazer isso enquanto executa o processo do agente, o painel de controle e outros serviços sempre ativos na mesma caixa.
Configurando a Camada do Modelo (llama.cpp no Strix Halo)
para manter contêineres Toolbox pré-construídos para o llama.cpp no Strix Halo, em vários backends: vulkan-amdvlk, vulkan-radv, rocm-6.4.4, rocm-6.4.4-rocwmma, rocm-7rc-rocwmma. Eles são construídos principalmente para o HP G1a Mini (mesmo chip Strix Halo), mas funcionam na maioria das máquinas Strix Halo, incluindo o MS-S1 MAX. O backend vulkan-radv tem sido o mais estável nos testes e carrega os modelos maiores sem problemas.
BIOS/UEFI: defina a alocação mínima de VRAM para 1GB (o mínimo da BIOS Minisforum) para que o driver AMDGPU fique livre para alocar RAM do sistema como VRAM através da GTT.
Parâmetros do kernel (testados no Arch Linux, mas qualquer distribuição recente com suporte ao kernel Strix Halo deve funcionar) para maximizar a alocação de VRAM e reduzir a latência:
amd_iommu=off amdgpu.gttsize=131072 amdttm.pages_limit=33554432 amdttm.page_pool_size=15728640
Crie a toolbox com passagem de 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
Entre nela:
toolbox enter llama-vulkan-radv
Dentro dela, o llama-cli e o llama-server estão prontos para executar modelos. Force todas as camadas para a GPU para que a CPU fique livre para todo o resto (o processo do agente, Tailscale, painéis de controle):
1# Apenas terminal2llama-cli --no-mmap -ngl 999 --flash-attn on -m <modelo>34# Interface web do servidor — é para onde o Hermes Agent apontará5llama-server --no-mmap -ngl 999 --flash-attn on --host <endereço_ip> --port <número_da_porta> -m <modelo>
Os modelos usados aqui vieram do Unsloth no Hugging Face, no formato GGUF.
Alternando entre modelos: o llama-swap facilita a troca de qual modelo está servindo o agente sem precisar reiniciar nada manualmente – baixe o binário Linux, dê chmod +x e defina um config.yaml.
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
Isso oferece uma interface web para alternar modelos para diferentes tarefas (modelo mais leve/rápido para respostas rápidas, o de 120B para qualquer coisa que exija mais raciocínio) sem tocar na máquina diretamente, e o histórico do bate-papo persiste durante a troca.
Os Números de Desempenho (Por Que Esta Máquina Pode Sustentar uma Carga de Trabalho de Agente)
Usando o llama-bench para processamento de prompt (pp512) e geração de texto (tg128):
1ModeloTamanhoProcessamento de Prompt (t/s)Geração de Texto (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
O número que importa para um agente sempre ativo: um modelo de 120B, totalmente local, gerando a 56,6 tokens/segundo. Isso é rápido o suficiente para que o Hermes Agent execute cadeias de chamadas de ferramentas em várias etapas sem que cada tarefa se transforme em uma longa espera.
Teste de carga no mundo real: ao solicitar ao GPT-OSS-120B "Gere um ensaio sobre LLMs (5000 palavras)", foram produzidos 7.990 tokens a 51,2 tokens/segundo. O consumo de energia ficou em média ~110W na iGPU, com a temperatura da borda se estabilizando em torno de 68-69°C – silencioso e não particularmente quente, graças ao cooler de 6 heatpipes/ventoinhas duplas e a uma atualização de BIOS 1.03 que melhorou a curva da ventoinha. Esse perfil de energia e térmico é o que torna viável deixar esta máquina funcionando 24/7 como uma caixa de negócios, em vez de um risco de incêndio.
NPU: a NPU XDNA 2 (50 TOPS) não foi usada nesta configuração ainda – o suporte ainda é imaturo. O FastFlowLM, um projeto que permite inferência de LLM em NPUs Ryzen AI, parece promissor como uma forma futura de descarregar ainda mais a carga de trabalho, mas atualmente requer Windows.
A Camada de Fluxo de Trabalho: Conectando o Hermes Agent por Cima
É aqui que a máquina se transforma em uma ferramenta de negócios real, em vez de um benchmark. O Hermes Agent é a camada que pega o modelo local acima e o transforma em algo que faz coisas: cria conteúdo, executa chamadas de ferramentas, navega, gerencia subagentes e age com base em uma programação.
1. Instale o Hermes Agent e aponte-o para o modelo local. A integração do Hermes pergunta por um provedor de modelo. Escolha local/auto-hospedado compatível com OpenAI, aponte para localhost:<porta> onde o llama-server está rodando e pule a chave de API, já que é local. O Hermes especificamente quer um comprimento mínimo de contexto de 64.000 tokens – aumente isso se o fluxo de trabalho envolver codificação pesada ou documentos longos, mantenha-o mais baixo para tarefas curtas como e-mails ou postagens em redes sociais.
2. Defina o modelo local como padrão, não como a única opção. A configuração real de produção é híbrida por design, mas não porque o hardware não consegue acompanhar – é porque algumas tarefas genuinamente não precisam de um modelo local de 120B: respostas rápidas, formatação simples, consultas curtas. Defina o modelo local como padrão e, em seguida, adicione um provedor de fallback (OpenAI, Claude ou Open Router) com instruções de roteamento para os casos em que ele realmente agrega valor – cadeias pesadas de chamadas de ferramentas, longos loops de depuração ou tarefas onde a velocidade importa mais que a privacidade. O Open Router é uma forma barata de fazer isso: $10 compram aproximadamente 1.000 requisições, útil como uma válvula de escape para tarefas de subagentes não críticas.
3. Mantenha-o funcionando 24/7. Um fluxo de trabalho de negócios só funciona se não cair quando você fecha seu laptop. Habilite o Hermes Agent para reiniciar automaticamente na inicialização:
1sudo systemctl enable tailscaled2sudo systemctl enable hermes-agent
Qualquer assistente de codificação de IA (Codex, Claude, Gemini, Warp) pode gerar o arquivo de serviço equivalente se o Hermes Agent não foi instalado como um serviço systemd por padrão.
4. Alcance-o de qualquer lugar com o Tailscale. Isso é o que transforma o MS-S1 MAX de "uma máquina na qual preciso sentar na frente" em infraestrutura. Instale o Tailscale (plano pessoal gratuito, até seis usuários) no mini PC e em qualquer dispositivo que você realmente usa no dia a dia – laptop, celular. Depois que ambos estiverem na mesma rede Tailscale:
- Faça SSH no mini PC a partir de um laptop para executar comandos de administração que o agente não pode executar sozinho
- Abra o painel do Hermes Agent remotamente como se estivesse rodando em localhost, mesmo que esteja fisicamente em uma máquina do outro lado da sala ou do país
- No iOS, como alguns aplicativos de terminal (Termius) pulam o handshake SSH que o Tailscale espera, defina o modo de acesso SSH como "accept" nos controles de acesso do Tailscale para que o celular consiga se conectar – útil para corrigir um fluxo de trabalho travado enquanto estiver longe de uma mesa
5. Deixe o agente executar as tarefas de negócios. Com a pilha conectada dessa forma, o padrão do dia a dia é: pesquisa, redação, resumos e chamadas de ferramentas de rotina são executados localmente no MS-S1 MAX gratuitamente, com os resultados enviados através do Telegram, de um painel ou de qualquer integração que o Hermes suporte. Qualquer coisa que precise ser rápida (em tempo real, voltada para o cliente) ou que exija raciocínio que o modelo local genuinamente não consegue igualar é roteada para o provedor de fallback por exceção, não por padrão.
Por Que a Escolha do Hardware Determina Quanto Disso Você Realmente Obtém
O modelo local é o gargalo para tudo que está acima dele. Um modelo de 9B com baixas dezenas de tokens/segundo pode executar o Hermes Agent, mas tarefas de agente em várias etapas com subagentes e chamadas de ferramentas se estendem por muitos minutos, o que limita o quanto da carga de trabalho pode realisticamente permanecer local antes que o roteamento de fallback tenha que assumir. Um modelo local na classe de 120B a 56+ tokens/segundo muda o quanto da carga de trabalho do dia a dia a máquina local pode absorver por conta própria – mais da lógica de negócios permanece em hardware próprio, e o fallback na nuvem se torna uma ferramenta para casos extremos genuínos, em vez do caminho padrão para qualquer coisa não trivial.
A privacidade é a parte que não muda com o hardware. Independentemente do modelo que está rodando localmente, chaves de API, dados de clientes e fluxos de trabalho de negócios nunca saem da rede. Isso é verdade em um Raspberry Pi rodando um modelo minúsculo e verdadeiro no MS-S1 MAX rodando um de 120B – o hardware apenas decide quanto trabalho útil acontece antes que você precise recorrer à opção da nuvem.
Conclusão Prática
Para uma pilha de agente local 24/7 projetada para realmente carregar fluxos de trabalho de negócios – não apenas demonstrar uma resposta de chat – os requisitos são: memória unificada suficiente para carregar um modelo genuinamente capaz, capacidade de potência/térmica sustentada suficiente para executar esse modelo continuamente e consumo ocioso baixo o suficiente para que deixá-lo ligado não apareça como uma despesa real.
Os 96GB de memória iGPU endereçável do MS-S1 MAX, o consumo sustentado de carga de 110W e o resfriamento silencioso de 6 heatpipes cobrem o lado do hardware. O Hermes Agent, apontado para o llama-server rodando localmente e acessível de qualquer lugar via Tailscale, cobre o lado do fluxo de trabalho. Juntos, isso é um único mini PC que pode ficar em um armário, permanecer ligado permanentemente e executar uma parte significativa da carga de trabalho diária de IA de um negócio, sem uma conta recorrente de nuvem ou dados saindo do prédio.
Para uso geral como estação de trabalho, o MS-S1 MAX também oferece expansão PCIe e dual M.2, ~5W de consumo ocioso, Ethernet dual de 10Gbps e USB4 v2 (80Gbps) – nada disso é específico para LLM, mas tudo importa se esta máquina estiver fazendo dupla função como algo mais do que apenas a caixa do agente.
