Módulo 5.1 — Backends de execução

📋 Comparativo rápido dos 7 backends

Backend	Isolamento	Cold-start	Custo	Caso ideal
local	nenhum	~0ms	grátis	dev e CI
docker	container	~400ms	infra própria	prod self-hosted
ssh	host remoto	~50ms+RTT	VM dedicada	HPC, bare-metal
singularity	container HPC	~600ms	cluster compartilhado	SLURM, academia
modal	microVM	~2s	$/s GPU	GPU on-demand
daytona	workspace	~3s	$/h workspace	dev envs por tarefa
vercel	microVM edge	~300ms	$/GB-s	chatbot web global

💻 Local — mais simples, sem isolamento

O backend local é o default. Cada chamada de tool executa direto no processo do agente — sem container, sem rede separada, sem rootfs novo. É a configuração mais rápida e a mais perigosa.

# instalar e rodar local
$ pip install hermes-agent
$ hermes run --backend local --task "analise o CSV em ./data.csv"

# variáveis úteis
$ export HERMES_LOCAL_WORKDIR=/tmp/hermes-runs
$ export HERMES_LOCAL_TIMEOUT=120

✓ Quando FAZER local

✓Desenvolvimento e debug no seu laptop
✓CI rodando agente confiável em sandbox de runner
✓Workloads de leitura/análise sem escrita destrutiva
✓Quando latência < 50ms é requisito

✗ Quando NÃO usar local

✗Produção multi-tenant — código gerado pelo modelo toca seu host
✗Servidores compartilhados com outros serviços
✗Qualquer cenário onde rm -rf / seria catastrófico
✗Compliance que exija auditoria de execução isolada

⚠️ Atenção

O backend local herda todas as permissões do usuário que rodou o Hermes. Se você roda como root, o agente pode reformatar disco. Sempre crie um usuário hermes sem sudo, com home dedicado.

🐳 Docker — isolamento e portabilidade

O backend docker é a escolha padrão para produção self-hosted. Cada sessão de agente recebe um container dedicado a partir de uma imagem versionada com Python, libs de data science e CLIs comuns pré-instalados.

# Dockerfile mínimo de sandbox (referência docs Nous)
FROM python:3.11-slim
RUN apt-get update && apt-get install -y --no-install-recommends \
    git curl ripgrep jq sqlite3 && rm -rf /var/lib/apt/lists/*
RUN pip install --no-cache-dir pandas numpy matplotlib requests
WORKDIR /workspace
CMD ["bash"]

# build e tag
$ docker build -t hermes-sandbox:0.6 .

# rodar com Hermes
$ hermes run \
    --backend docker \
    --docker-image hermes-sandbox:0.6 \
    --docker-network none \
    --docker-cpus 2 --docker-memory 4g \
    --task "agrupe transações por mês"

Timeline de deploy Docker

Dockerfile

Defina deps mínimas + ferramentas que o agente espera (rg, jq, sqlite3, pandas).

Quanto mais enxuto, mais rápido o cold-start e menor a superfície de ataque.

Build + scan

docker build com tag semver + trivy image hermes-sandbox:0.6.

Bloqueie deploy se há CVE crítica — atualize base mensalmente.

Push para registry

docker push ghcr.io/seu-org/hermes-sandbox:0.6

Registry privado é obrigatório se a imagem contém creds embutidas (evite).

Run com limites

--network none, CPU/MEM limitados, mount read-only sempre que possível.

Adicione --security-opt no-new-privileges e drop de capabilities.

💡 Dica

Mantenha um pool de containers warm: 3-5 containers já instanciados aguardando uso. Reduz cold-start de 400ms para ~30ms. Use docker create + docker start sob demanda.

🔑 SSH — servidor remoto sem container

O backend ssh envia comandos para um host remoto via OpenSSH. Útil quando o agente roda no seu laptop mas precisa executar em servidor com GPU, ou quando o ambiente alvo proíbe Docker (caso comum em corporativo).

# prepare a chave dedicada
$ ssh-keygen -t ed25519 -f ~/.ssh/hermes_agent -N ""
$ ssh-copy-id -i ~/.ssh/hermes_agent.pub hermes@gpu-box.example.com

# rode o Hermes apontando pro host
$ hermes run \
    --backend ssh \
    --ssh-host gpu-box.example.com \
    --ssh-user hermes \
    --ssh-key ~/.ssh/hermes_agent \
    --ssh-workdir /home/hermes/sessions \
    --task "treine baseline no dataset X"

📊 Dados — quando SSH ganha de Docker

~85% dos clusters universitários proíbem Docker daemon — Singularity ou SSH são as únicas opções
40ms+RTT de cold-start: 5x mais lento que Docker local mas dá acesso a GPU 100x mais rápida
Zero overhead de imagem: usa ambiente Python já instalado no host
1 conexão multiplexada com ControlMaster reaproveita TCP entre invocações

⚠️ Atenção

SSH não é sandbox. Se o usuário remoto tem sudo, o agente também tem. Crie useradd -m -s /bin/bash hermes sem grupos privilegiados, e use ForceCommand no sshd_config para limitar comandos se necessário.

⚡ Modal — serverless GPU on-demand

O backend modal é a saída para quando o agente precisa de GPU sem manter cluster próprio. Você define a imagem, o Modal aloca A10/A100/H100 sob demanda e cobra por segundo de uso.

# configure credenciais Modal
$ pip install modal
$ modal token new

# rode agente com sandbox em GPU H100
$ export MODAL_TOKEN_ID=ak-xxxx
$ export MODAL_TOKEN_SECRET=as-xxxx
$ hermes run \
    --backend modal \
    --modal-gpu H100 \
    --modal-image hermes-sandbox-gpu:0.6 \
    --modal-timeout 600 \
    --task "fine-tune Llama 3 8B no dataset Y"

📊 Benchmark de cold-start (out 2025)

local: ~0ms (sem isolamento)
docker (warm pool): ~30ms
docker (cold): ~400ms
vercel sandbox: ~300ms (microVM Firecracker)
modal (CPU): ~1.2s
modal (GPU A10): ~2.1s
modal (GPU H100): ~3.4s (alocação + driver init)
aws agentcore: ~125ms (Firecracker snapshot/restore)

⚠️ Cuidado com a fatura

Modal cobra por segundo de execução, incluindo idle dentro do timeout. H100 a ~$0.001/s = ~$3.60/h. Um agente esquecido em loop pode gerar centenas de dólares em uma noite. Sempre defina --modal-timeout agressivo (60-120s) e configure alerta de billing.

🟪 Vercel Sandbox — edge functions efêmeras

O Vercel Sandbox dá ao Hermes uma microVM Firecracker em ~300ms direto na infra Vercel — perfeito para chatbots web globais onde o agente precisa estar próximo do usuário e cobrar só pelo tempo ativo.

# exporte token e rode
$ export VERCEL_TOKEN=$(vercel tokens list --json | jq -r '.[0].value')
$ hermes run \
    --backend vercel \
    --vercel-region iad1 \
    --vercel-runtime python3.12 \
    --vercel-timeout 300 \
    --task "responda perguntas sobre o catálogo"

# integração típica: Next.js API route invocando Hermes via backend vercel
// app/api/agent/route.ts
export async function POST(req: Request) {
  const { message } = await req.json();
  const result = await hermesAgent.run({ task: message, backend: 'vercel' });
  return Response.json(result);
}

✓ Vercel ganha quando

✓Frontend já é Next.js/Vercel
✓Tráfego global (edge em 30+ regiões)
✓Sessões curtas (<5min)
✓Sem GPU, sem libs nativas pesadas

✗ Vercel perde quando

✗Treino ou inference local de modelo (sem GPU)
✗Sessões longas > 5min (timeout duro)
✗Estado entre invocações sem S3/KV externos
✗FS persistente local

🛰️ Singularity / Daytona — HPC e dev environments

Dois backends de nicho mas estratégicos: Singularity (hoje Apptainer) roda em clusters HPC sem precisar de root, e Daytona orquestra workspaces de dev versionados por tarefa.

# Singularity (cluster SLURM)
$ singularity pull docker://ghcr.io/seu-org/hermes-sandbox:0.6
$ hermes run \
    --backend singularity \
    --singularity-image ./hermes-sandbox_0.6.sif \
    --singularity-bind /scratch:/workspace \
    --task "rode análise no dataset compartilhado"

# Daytona (workspace dev por tarefa)
$ daytona server install
$ hermes run \
    --backend daytona \
    --daytona-template python-data \
    --daytona-git-repo https://github.com/org/projeto \
    --task "implemente o feature descrito em ISSUE-42"

Singularity — quando

• Cluster acadêmico/SLURM sem Docker daemon
• HPC com GPU compartilhada (multi-job)
• Compliance que exige imagens read-only (SIF)
• Mount de scratch compartilhado entre nós

Daytona — quando

• Agente atua como dev (codificar features)
• Cada tarefa precisa de branch + workspace isolado
• Time já usa devcontainers
• Quer destruir tudo após PR mergeado

💡 Dica de escolha rápida

Decisão em 3 perguntas: (1) precisa de GPU? Sim → Modal ou SSH-para-host-GPU. (2) tráfego global de chatbot? Sim → Vercel. (3) infra própria? Sim → Docker. Caso default para prod single-region: Docker.

✅ Resumo do Módulo

✓

Local só em dev/CI confiável — herda permissões do usuário.

✓

Docker é o default sólido para prod self-hosted; use warm pool para cold-start < 30ms.

✓

SSH e Singularity destravam HPC/clusters sem daemon Docker.

✓

Modal dá GPU on-demand cobrada por segundo — exige timeout agressivo e alerta de billing.

✓

Vercel Sandbox é a escolha para chatbots web globais com sessões curtas.

✓

Daytona brilha quando o agente faz papel de dev em workspace efêmero por tarefa.

Próximo módulo:

5.2 — AWS Bedrock AgentCore (sample oficial): arquitetura Firecracker, CDK em 4 fases e custos reais.

← Voltar para Trilha Próximo →