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 maneira certa de pensar." Executar o Hermes Agent em modelos na nuvem estava custando entre $10 e $20 por dia em créditos, sem contar o risco de privacidade de rotear chaves de API, dados de clientes e fluxos de trabalho de negócios através de servidores de terceiros. A solução é colocar o agente e o modelo que ele utiliza em hardware que você possui, 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 workflow 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 stack funcional de automação de negócios
O Hardware: O que há dentro do MS-S1 MAX
O MS-S1 MAX é construído na plataforma Strix Halo da AMD — 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á lançou para este formato. Essa é a diferença entre uma máquina que só consegue lidar com chat simples e uma que pode executar um loop de agente real com chamadas de ferramentas, subagentes e contexto longo por conta própria
Especificações do SoC (AMD Ryzen AI Max+ 395, 4nm Strix Halo, 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, 256GB/s de largura de banda
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 em uma prateleira 24 horas por dia, 7 dias por semana
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 energia 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 quad channel. O driver AMDGPU pode alocar RAM do sistema como VRAM através da GTT (Tabela de Tradução Gráfica), e nesta máquina a iGPU pode reivindicar até 96GB desse pool, deixando 32GB para a CPU. Esse teto de 96GB significa que esta única máquina pode hospedar um modelo genuinamente capaz e fazê-lo enquanto executa o processo do agente, o painel de controle e outros serviços sempre ativos na mesma caixa
Configurando a Camada de Modelo (llama.cpp no Strix Halo)
para manter contêineres Toolbox pré-construídos para 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 seja livre para alocar RAM do sistema como VRAM via 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 o 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 nele:
toolbox enter llama-vulkan-radv
Dentro, llama-cli e llama-server estão prontos para executar modelos. Force todas as camadas para a GPU para que a CPU permaneça 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_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 reiniciar nada manualmente — baixe o binário Linux, dê chmod +x nele 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 fornece uma interface web para trocar modelos para diferentes tarefas (modelo mais leve/rápido para respostas rápidas, o 120B para qualquer coisa que precise de mais raciocínio) sem tocar na máquina diretamente, e o histórico do chat persiste durante a troca
Os Números de Desempenho (Por Que Esta Máquina Pode Suportar uma Carga de Trabalho de Agente)
Usando 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 de várias etapas sem que cada tarefa se transforme em uma longa espera.
Teste de carga no mundo real: solicitar ao GPT-OSS-120B "Gere um ensaio sobre LLMs (5000 palavras)" produziu 7.990 tokens a 51,2 tokens/segundo. O consumo de energia médio foi de aproximadamente 110W na iGPU, com a temperatura da borda 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 realista deixar isso funcionando 24 horas por dia, 7 dias por semana, 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 Workflow: 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á sendo executado 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 mais baixo para tarefas curtas como e-mails ou postagens sociais
2. Defina o modelo local como padrão, não como a única opção. A configuração de produção real é 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, depois 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, loops longos de depuração ou tarefas onde a velocidade importa mais do que a privacidade. O Open Router é uma maneira 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 horas por dia, 7 dias por semana. Um fluxo de trabalho de negócios só funciona se não cair quando você fecha seu laptop. Ative 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 Tailscale. Isso é o que transforma o MS-S1 MAX de "uma máquina na qual tenho que sentar na frente" em infraestrutura. Instale o Tailscale (plano pessoal gratuito, até seis usuários) no mini PC e no que você realmente usa para trabalhar no dia a dia — laptop, telefone. Depois que ambos estiverem na mesma rede Tailscale:
- Faça SSH no mini PC a partir de um laptop para executar comandos de administrador que o agente não pode executar sozinho
- Abra o painel de controle do Hermes Agent remotamente como se estivesse sendo executado em localhost, mesmo que esteja fisicamente em uma máquina do outro lado da sala ou do outro lado 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 "aceitar" nos controles de acesso do Tailscale para que o telefone possa 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 stack conectada dessa forma, o padrão do dia a dia é: pesquisa, escrita, resumos e chamadas de ferramentas de rotina são executados localmente no MS-S1 MAX gratuitamente, com os resultados enviados através do Telegram, um painel de controle ou qualquer coisa com que o Hermes se integre. Qualquer coisa que precise ser rápida (tempo real, voltada para o cliente) ou que precise de 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 de Hardware Determina Quanto Disso Você Realmente Obtém
O modelo local é o gargalo para tudo acima dele. Um modelo de 9B a dezenas baixas de tokens/segundo pode executar o Hermes Agent, mas tarefas de agente de várias etapas com subagentes e chamadas de ferramentas se estendem por muitos minutos, o que limita 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 diária a máquina local pode absorver por conta própria — mais da lógica de negócios permanece em hardware que você possui, 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
Privacidade é a parte que não muda com o hardware. Seja qual for o modelo sendo executado localmente, chaves de API, dados de clientes e fluxos de trabalho de negócios nunca saem da rede. Isso é verdade em um Raspberry Pi executando um modelo minúsculo e verdadeiro no MS-S1 MAX executando um de 120B — o hardware apenas decide quanto trabalho útil acontece antes de você precisar recorrer à opção de nuvem
Conclusão Prática
Para uma stack de agente local 24 horas por dia, 7 dias por semana, 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, headroom sustentado de energia/térmico 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
A memória da iGPU endereçável de 96GB 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 sendo executado 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 uma empresa 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 traz expansão PCIe e dual M.2, consumo ocioso de ~5W, Ethernet dupla de 10 Gbps e USB4 v2 (80 Gbps) — nada disso é específico para LLM, mas tudo importa se esta máquina estiver fazendo função dupla como mais do que apenas a caixa do agente
