Hermes Agent requisitos: que máquina roda o agente sem travar?

Fala aí, beleza? Tem uma confusão gigante rolando sempre que alguém pergunta que máquina o Hermes Agent pede, e ela vem de misturar duas contas MUITO diferentes numa só

Uma conta é o que o agente consome por si: o processo que fica de pé, as sessões abertas, o dashboard

A outra é o que o modelo escolhido consome, e essa varia de "nada na sua máquina" (modelo em nuvem) até "preciso de RAM pra caramba" (modelo local)

O Hermes Agent é open source da Nous Research sob licença MIT, e a documentação dele deixa claro que a mesma ferramenta roda desde um VPS de US$ 5 até cluster de GPU ou serverless que hiberna quando ocioso

Ou seja: não existe um número mágico de RAM pra colar aqui

Existe uma régua, e ela começa por onde o modelo vai rodar

Bora separar as duas contas?

O que o agente consome x o que o modelo consome:

Se liga nisso, porque é aqui que a decisão nasce

O Hermes trata cada gateway como um processo Python leve, e perfil ocioso não fica comendo recurso à toa

A parte que escala com a sua escolha é a coluna da direita

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

Repara numa coisa: o Hermes não te entrega uma tabela oficial de "mínimo de CPU e RAM"

Ele entrega mecanismo: teto de memória, descarte de sessão, alerta em dois níveis e banner

É um jeito diferente de pensar requisito, e faz sentido pra uma ferramenta que roda tanto em VPS baratinha quanto em DGX

Quanta memória para rodar o modelo local:

Agora a coluna que pesa de verdade

Se o modelo vai rodar na SUA máquina, o requisito de hardware é o requisito do modelo, não o do agente

A documentação recomenda o Qwen3.5-9B pra começar: ele cabe em 8 GB+ de memória unificada com quantização, e um 9B em Q4 ocupa cerca de 5 GB

Aí soma o KV cache: em contexto de 128K com Q4, mais 4 a 5 GB

Percebe como o número sobe rápido? 😀

E a velocidade? Porque caber na memória é só metade do problema, a outra metade é não esperar meia vida por resposta

Um aviso pra tabela abaixo não te confundir: a documentação usa um modelo de 31B como exemplo de "modelo grande", ou seja, a mesma vizinhança dos 27B/35B que pedem 32 GB+

Olha o caso da GPU de 12 GB: mesmo sem caber o modelo inteiro na VRAM, o offload parcial ainda vale a pena

Muita gente descarta a placa achando que é tudo ou nada, e não é

Do lado NVIDIA, a própria empresa posiciona PCs RTX, workstations RTX PRO e o DGX Spark como hardware indicado pra rodar o Hermes local sempre ligado

O DGX Spark tem 128 GB de memória, o que permite servir modelos locais bem maiores, e a NVIDIA cita modelos Qwen de 27B e 35B rodando via llama.cpp, LM Studio ou Ollama

Não precisa de PC da Nasa pra começar, mas pra 27B/35B em casa a conta é essa mesmo

Onde rodar o Hermes Agent: VPS, máquina local, Docker ou nuvem

A pergunta "que máquina o Hermes pede" muda completamente de resposta dependendo do cenário

Então vamos por cenário, beleza?

VPS barata com o modelo em nuvem:

É o caminho mais leve

O Hermes aceita Nous Portal, OpenRouter, OpenAI e qualquer endpoint compatível, então a máquina só segura o agente e as ferramentas

Com hermes setup --portal, um OAuth do Nous Portal cobre um modelo mais as quatro ferramentas do Tool Gateway (busca web, geração de imagem, TTS e navegador)

Aqui a máquina não precisa de GPU nenhuma, porque a geração acontece do outro lado da rede

E se um dia você quiser sair dessa VPS, dá pra migrar o Hermes para outra máquina sem começar do zero

Máquina local com Ollama ou LM Studio:

O Hermes tem integração nativa com os dois

Aqui mora a pegadinha mais comum: o padrão do Ollama é 2048 tokens de contexto, e o Hermes exige no mínimo 64.000

Tome cuidado! Esse contexto NÃO pode ser definido pela API compatível com OpenAI (/v1/chat/completions), tem que ser configurado server-side ou por Modelfile

ollama run --num_ctx 64000 <modelo>

O erro comum aqui: olhar o /api/show e achar que resolveu

Esse endpoint informa o contexto MÁXIMO do modelo, não o num_ctx efetivo que você configurou

Se você definiu um num_ctx customizado, precisa definir o mesmo valor de contexto no Hermes, senão os dois lados discordam

Se você tá avaliando esse caminho, vale ver o que muda rodando o Hermes com Ollama antes de dimensionar a máquina

Docker, quando um perfil não pode derrubar o outro:

O backend Docker permite containers separados por perfil, com --memory e --cpus

O ganho é isolamento: uma sessão descontrolada de ferramenta de navegador não causa OOM em outro perfil

Por baixo, o Hermes sobe um container longevo com docker run -d ... sleep infinity e roteia terminal, arquivos e execute_code via docker exec nele

Sandbox e serverless que hiberna:

O Hermes suporta sete backends de terminal: máquina local, container Docker, servidor remoto via SSH, sandbox Modal, workspace Daytona, Vercel Sandbox e container Singularity/Apptainer

O próprio projeto cita serverless (Daytona, Modal) que hiberna quando ocioso e custa quase nada parado

E o sistema operacional?

Suportados: Linux, macOS, WSL2, Windows nativo (Windows 10 e Windows 11, sem WSL, Cygwin ou Docker) e Android via Termux

No Windows nativo, tudo roda nativamente com uma única exceção de paridade: o painel de terminal embutido do dashboard

E atenção: o WSL1 não é suportado de forma confiável

O instalador WSL2 provisiona kernel WSL2, Virtual Machine Platform e Ubuntu padrão em Windows 10 22H2+ ou Windows 11

Fora do Windows, o único pré-requisito é o Git (no Linux, também curl e xz-utils disponíveis)

O instalador resolve o resto sozinho: instala Python, Node.js, ripgrep e ffmpeg, clona o repositório, cria o ambiente virtual e configura o comando global hermes e o provedor de LLM

O launcher vai parar em ~/.local/bin/hermes na instalação de usuário, ou em /usr/local/bin/hermes (com bibliotecas em /usr/local/lib/…) quando você instala como root

Como ficou o consumo na prática rodando em VPS

No vídeo abaixo eu mostro a instalação do Hermes Agent numa VPS contratada, não na máquina local, acessando tudo pelo terminal do painel do provedor

A instalação saiu com dois comandos, um pra baixar e outro pra executar, e dava pra ver o instalador puxando os pacotes que ainda não existiam na máquina

No fim, o agente subiu sozinho, sem eu precisar iniciar nada manualmente

Fui de quick setup, que é o mínimo necessário pra colocar a ferramenta de pé

Aí veio a parte que interessa pra este post: em vez de ficar rodando comando de monitoramento na mão, eu pedi ao próprio agente que me mostrasse o uso de disco e memória da VPS

A resposta veio rápida: 8% de uso de disco e cerca de 7 GB de memória disponível

Máquina bem folgada, com o modelo rodando em nuvem

Essa é justamente a âncora concreta do argumento: quando o modelo não está na sua máquina, o agente sozinho pesa pouco

Na comparação com o concorrente que eu uso como referência no vídeo, o Hermes me pareceu mais leve tanto pra executar comandos quanto pra processar ações, com setup bem enxuto

Sobre planos de VPS, minha leitura foi essa: o plano de entrada aguenta pra quem só quer testar e ver como a ferramenta se comporta, o intermediário roda com folga e deixa espaço pra montar várias coisas em cima do agente, e planos maiores fazem sentido pra quem já tem um projeto mais ambicioso na cabeça

Um detalhe da contratação: escolhi localização no Brasil e um sistema operacional simples, tirando o N8N que vinha pré-instalado, pra começar com a máquina limpa

Isso não muda nada pro Hermes, é só preferência minha de começar do zero

Ah, e nem tudo foi perfeito: ao testar a busca web pelo agente, tomei um bloqueio do Google na tentativa

Está lento: é o hardware, a rede ou a tarefa?

Aqui é onde a maioria culpa a máquina sem checar nada, e às vezes a máquina não tem culpa nenhuma

Vamos por origem

Hardware: o silêncio longo que parece travamento

Sintoma: você manda a primeira mensagem com modelo local e o agente fica minutos calado, aí de repente começa a responder em ritmo normal

Causa: em hardware lento ou com pouca VRAM, o processamento do prompt (o prefill) domina o primeiro turno

Não é sessão travada, é o modelo mastigando o prompt antes de gerar

Correção: o Hermes já se antecipa a isso

Ao detectar localhost ou IP de LAN, o read timeout de socket sobe de 120s para 1800s (30 minutos) e a detecção de stream parado é desativada

Se você definir HERMES_STREAM_READ_TIMEOUT explicitamente, esse valor sempre prevalece, então cuidado ao setar um número baixo achando que tá otimizando

Sintoma 2: o dashboard mostra banner de memória baixa e sessões somem do meio do caminho

Causa: o gateway cruzou o teto e começou a descartar as sessões menos usadas recentemente

Correção: olhar o log em WARNING (ele traz o RSS medido e as sessões removidas) e revisar o memory_high_mb ou o limite de cgroup/systemd sob o qual o gateway roda

Ambiente: o shell que atrasa cada comando

Sintoma: todo comando demora um tanto a mais do que deveria, ou simplesmente parece rodar pra sempre até dar timeout

Causa: rc files pesados

Sourcing de nvm.sh, por exemplo, soma latência a TODO start de shell

E pior: qualquer coisa em .bashrc/.zshrc que peça input, chame read, anexe tmux/screen ou imprima menu trava um shell não interativo

Correção: limpar a inicialização do shell e deixar o que pede interação fora do caminho não interativo

Já me ferrei com esse tipo de coisa, e o sintoma engana total: parece a ferramenta, é o seu .bashrc

Tarefa: o que você mandou o agente fazer

Sintoma: você troca de modelo no meio da conversa e a mensagem seguinte demora e sai cara

Causa: cada /model reseta o cache de prompt

A primeira mensagem depois da troca relê a conversa inteira a preço cheio de input

Correção: delegar a subagentes (que ganham contexto próprio) ou abrir sessão nova

Sintoma 2: o agente fica lerdo depois que um script de cron roda

Causa: saída gigante

Script despejando megabytes atrasa o agente e pode estourar limites de token

Correção: filtrar ou resumir a saída no próprio script, antes de ela chegar no agente

E a rede?

Sendo honesto: não existe número oficial publicado de banda ou latência mínima pra usar o Hermes com provedor em nuvem

O que existe é o comportamento de timeout de socket, que muda conforme o endpoint é local ou remoto

Então o jeito de investigar rede aqui é por eliminação: se o hardware tá folgado e a tarefa é pequena, sobra o caminho até o provedor

As ferramentas que respondem por você:

Antes de culpar qualquer coisa, roda o diagnóstico

1. hermes doctor faz o diagnóstico interativo, apontando o que falta e como corrigir, inclusive dependências de backend
2. hermes status dá a visão geral do runtime
3. hermes dump gera a informação de debug pra compartilhar quando você for pedir ajuda

E pra prevenir: se o modelo é local, dimensiona memória pensando em modelo + KV cache juntos; se é nuvem, foca em manter o shell limpo e a saída das tarefas enxuta

As duas causas mais chatas de lentidão não são hardware, são configuração de ambiente e tarefa mal desenhada

Conclusão

A régua de decisão pros requisitos do Hermes Agent é essa, e nessa ordem: escolhe primeiro ONDE o modelo vai rodar, depois dimensiona a máquina

Modelo em nuvem? O agente é leve, e o projeto assume isso ao citar desde um VPS de US$ 5 até serverless que hiberna ocioso

Modelo local? Aí a conta é do modelo: 9B em Q4 ocupa cerca de 5 GB, o KV cache de 128K em Q4 soma 4 a 5 GB, 16 GB deixa o contexto de 128K confortável e os 27B/35B só fazem sentido com 32 GB+ de memória unificada

Próximo passo prático, antes de sair culpando o hardware: hermes doctor e hermes status

E confere o contexto, porque o mínimo de 64.000 tokens não é sugestão: modelo com janela menor é rejeitado no startup

Pra referência, a versão estável mais recente é a v0.20.1 (tag v2026.8.13, publicada em 13 de agosto de 2026), que consolida os PRs mergeados desde a v0.20.0, de 03/08/2026

O projeto é open source sob licença MIT, da Nous Research, lançado em 25 de fevereiro de 2026

Massa ver uma ferramenta que roda tanto num VPS baratinho quanto num DGX Spark de 128 GB sem mudar de identidade 🙂

até o próximo post!