Agente de IA, LLM ou assistente: qual a diferença?

Qual é a diferença entre um agente de IA, um LLM e um assistente de IA?

Um agente de IA, um LLM e um assistente de IA são três camadas da mesma stack. Para os distinguir, verifique o que cada um exige de um servidor. Um LLM (large language model) é um ficheiro de pesos que precisa de RAM e capacidade de processamento. Um assistente é esse modelo integrado numa interface de chat, com uma conta e histórico guardado, quase sempre no hardware de outra pessoa. Um agente é um assistente que também dispõe de ferramentas e de um ciclo de execução. Além disso, mantém credenciais, o que obriga a executá-lo numa máquina que permaneça ligada.

A maioria dos textos sobre este tema limita-se às definições. As definições só são importantes porque cada camada tem custos diferentes. Uma requer RAM. A seguinte requer um URL público e TLS (transport layer security). A última requer credenciais. Depois de um agente utilizar uma credencial, é necessário substituí-la.

Um LLM é composto por pesos, e os pesos precisam de RAM

Um LLM é um ficheiro de números. Descarrega-o, um runtime carrega-o para a memória e ele responde a um pedido de cada vez. O contrato é limitado: entra texto e sai texto. O modelo não tem memória entre chamadas, não tem relógio, não tem acesso à rede e não consegue abrir um ficheiro. Tudo o que um LLM parece recordar foi colocado no seu contexto pelo programa que o chama.

O número que determina o seu plano VPS é o tamanho desse ficheiro, porque todo o conteúdo permanece na memória enquanto o modelo está em execução. Com a quantização de 4 bits que o Ollama fornece por predefinição, conte com cerca de 0.6 GB por mil milhões de parâmetros. Depois, acrescente 1 ou 2 GB para a janela de contexto e para o próprio runtime.

[
  {
    "label": "qwen3:4b",
    "download_gb": 2.5,
    "ram_gb_needed": 6
  },
  {
    "label": "qwen3:8b",
    "download_gb": 5.2,
    "ram_gb_needed": 8
  },
  {
    "label": "qwen3:14b",
    "download_gb": 9.3,
    "ram_gb_needed": 12
  },
  {
    "label": "qwen3:32b",
    "download_gb": 20.0,
    "ram_gb_needed": 24
  }
]

A build qwen3:8b ocupa 5.2 GB em disco e precisa de cerca de 8 GB de RAM para funcionar sem swapping. Um VPS com 4 GB não consegue carregar qwen3:14b, que ocupa 9.3 GB antes de introduzir uma única palavra. A maior linha desta tabela, qwen3:32b, precisa de cerca de 24 GB, o que, na maioria das tabelas de preços, corresponde a um plano diferente e a uma mensalidade diferente.

Caber na memória é uma questão. A velocidade é outra. Num VPS apenas com CPU, o gargalo é a largura de banda da memória, não a velocidade do clock. Por isso, um modelo que cabe na memória pode responder a apenas alguns tokens por segundo. Isso é aceitável para uma tarefa que é executada durante a noite, mas é desagradável num chat. Uma GPU aumenta esse valor aproximadamente uma ordem de grandeza e também aumenta a fatura. Por isso, decida com base numa medição: faça um benchmark do VPS com a carga de trabalho que pretende executar e leia quando um VPS com GPU compensa o preço. Para começar a executar os pesos, consulte Ollama no seu próprio VPS.

Um assistente é um LLM com uma interface de chat

Um assistente é a camada de produto à volta de um modelo. ChatGPT e Claude são assistentes: um modelo, uma janela de chat, uma conta, conversas guardadas e um limite de pedidos. Quase nada disso é executado em hardware que controla, por isso um assistente alojado custa uma subscrição e 0 GB de RAM.

A versão self-hosted é um frontend como o Open WebUI, ligado a um Ollama local ou a uma API alojada. O frontend é um software pequeno. Conte com cerca de 1 GB residentes para a interface de chat, além do que o modelo necessitar. O que ele precisa, e um modelo isolado não, é de um URL público e de um certificado, porque pretende aceder-lhe a partir de um telemóvel: emita o certificado com Certbot e Nginx ou termine o TLS no Traefik à frente de várias aplicações. Se ainda estiver a escolher um frontend, compare as alternativas ao Open WebUI.

Um assistente responde. Não executa ações. Quando escreve um comando shell, uma pessoa lê esse comando e decide se o deve colar. Essa pessoa é uma camada de segurança. Um agente é o componente que a remove.

Um agente adiciona ferramentas e um ciclo

Um agente é um assistente que pode chamar funções e ler os resultados. Duas partes executam este trabalho. A primeira é uma ferramenta: uma descrição de uma função que o modelo pode solicitar, juntamente com o seu código de execução. A segunda é o ciclo: o seu programa chama o modelo, o modelo solicita uma ferramenta, o programa executa-a, adiciona o resultado à conversa e chama novamente o modelo. Isto repete-se até o modelo indicar que terminou ou até ser atingido um limite.

O ciclo é código normal, e uma implementação básica cabe em menos de cem linhas. O que o transforma num agente é o facto de as ferramentas utilizarem credenciais reais, permitindo que o ciclo altere algo fora de si próprio. Este facto determina todas as decisões de alojamento seguintes. Competências dos agentes e servidores MCP (model context protocol) são duas formas de fornecer mais ferramentas a um agente sem reescrever o ciclo.

• O agente continua a executar depois de a sua sessão terminar. Uma conversa termina quando fecha o separador. Uma execução de agente pode demorar vinte minutos e deve sobreviver à suspensão do portátil, por isso deve ficar num sistema que permaneça ligado, iniciado por um serviço ou temporizador systemd que o volte a iniciar depois de um reboot.
• O agente contém segredos. Uma API key, uma SSH key, uma palavra-passe de base de dados. Qualquer coisa que o agente consiga ler pode ser utilizada por uma instrução maliciosa escondida na entrada. Por isso, mantenha os segredos fora do alcance do agente.
• O custo aumenta com o ciclo, não com a sua pergunta. Em cada passo, a conversa completa é reenviada como entrada, por isso uma execução de dez passos paga dez vezes esse transcript. É por isso que os tokens de entrada dominam o custo de um agente e que deve definir um limite rígido para o que uma execução pode gastar.
• O agente pode errar de uma forma que grava alterações. Uma resposta errada numa conversa exige apenas uma nova leitura. Um delete errado dentro de um ciclo pode eliminar o diretório. Execute-o como um utilizador com o menor privilégio que ainda permita o seu funcionamento e, no caso de agentes de programação, execute-o numa sandbox antes de lhe dar acesso ao seu repositório.

O que cada camada precisa do servidor

[
  {
    "label": "LLM (weights you host)",
    "ram_gb": 8,
    "gpu": "helps a lot",
    "public_url": "no",
    "credentials": "none"
  },
  {
    "label": "Assistant (chat surface)",
    "ram_gb": 1,
    "gpu": "no",
    "public_url": "yes",
    "credentials": "one login"
  },
  {
    "label": "Agent (tools and a loop)",
    "ram_gb": 2,
    "gpu": "no",
    "public_url": "only for webhooks",
    "credentials": "several"
  }
]

Leia atentamente a coluna de RAM, porque ela exclui o modelo. Um front-end de chat e um runtime de agente são programas pequenos. Se o agente chamar um modelo alojado, 2 GB de RAM são suficientes para o executar, e um plano económico é uma resposta adequada, não uma solução de compromisso. Se colocar os pesos no mesmo servidor, a linha do modelo com 8 GB domina todo o resto.

As outras colunas são mais importantes do que parece. Apenas a camada do modelo fica mais rápida com uma GPU. Apenas a camada do assistente precisa normalmente de um URL público, porque um browser tem de lhe conseguir aceder; um agente só precisa de um quando algo externo tem de lhe fazer chamadas, como num webhook. Além disso, um agente armazena several credenciais. Essa é a diferença real entre um agente e uma janela de chat. Uma janela de chat pode estar errada. Um agente pode estar errado e depois agir com base nesse erro.

É necessário ter uma GPU para executar um agente de IA?

Não, exceto se também alojar os pesos do modelo na mesma máquina. O ciclo do agente consiste em pedidos HTTP, análise de JSON e chamadas a subprocessos. A CPU permanece quase inativa enquanto aguarda pela rede. A questão da GPU é, na realidade, uma questão sobre a camada do LLM.

Por isso, separe as decisões. Se o texto não puder sair da sua máquina, invista na memória necessária para manter um modelo e, para obter uma velocidade utilizável, numa GPU para o executar. Se apenas quiser a automatização, alugue o modelo por token e invista o dinheiro em disponibilidade e cópias de segurança. A maioria dos agentes autoalojados em 2026 chama um modelo alojado num serviço externo e, por isso, é mais barata de executar.

É possível alojar um agente de IA no seu próprio servidor?

Sim. O agente é a camada que mais compensa alojar no seu próprio servidor, porque é no ciclo de execução que ficam os seus dados e as suas credenciais. Um VPS pequeno, com 2 GB de RAM, um gestor de serviços e acesso à rede de saída, consegue executar um agente real. Escolha o percurso de criar o seu próprio agente num VPS se quiser controlar o ciclo de execução, ou implemente um dos agentes prontos para alojamento próprio se preferir começar com algo já concluído.

Alojar o assistente no seu próprio servidor é simples: precisa apenas de um contentor e de um certificado. A parte dispendiosa é alojar o modelo, e é essa a parte que muitas pessoas abandonam depois de verem os tokens serem processados lentamente por uma CPU. Aloje os pesos do modelo localmente quando os dados não puderem sair do servidor ou quando o seu volume de utilização tornar o preço por token demasiado elevado. Caso contrário, permita que o agente chame uma API e mantenha localmente os componentes que pretende controlar.

O ChatGPT é um agente de IA?

Um produto de chat torna-se um agente assim que pode chamar uma ferramenta e agir com base no resultado sem lhe pedir confirmação. Por esse critério, os assistentes alojados com navegação, execução de código ou conectores são agentes. A diferença para si está no local onde o ciclo é executado e nas credenciais utilizadas. Num produto alojado, ambos pertencem ao fornecedor. No seu próprio servidor, ambos pertencem a si, juntamente com a responsabilidade por tudo o que o ciclo fizer às três da manhã.

Reativos, de planeamento e multiagente

As listas costumam apresentar sete tipos de agentes. A maioria desses tipos é marketing. Duas distinções alteram o código que escreve, e uma altera os custos. Um agente reativo chama uma ferramenta, lê a resposta e responde. Um agente de planeamento escreve primeiro um plano e depois executa cada etapa. Isto funciona melhor em tarefas longas e consome mais tokens, porque o plano é reenviado em cada etapa. Uma configuração multiagente permite que um agente inicie outros agentes. Ao mesmo tempo, multiplica o consumo de tokens e os modos de falha. Só compensa quando as subtarefas são realmente independentes, como pesquisar quatro fontes em simultâneo. Comece com um agente reativo. Adicione planeamento quando as execuções se tornarem longas. Recorra a uma configuração multiagente apenas no fim. Para uma visão mais ampla, consulte o que vale a pena aprender sobre agentes de IA em 2026.

Como determinar em que camada está efetivamente a executar

No servidor, verifique quais processos estão a ocupar a memória.

free -h
ps -eo rss,comm --sort=-rss | head -5

Se a linha superior for ollama ou llama-server a ocupar vários gigabytes de RSS (resident set size, a memória que o processo ocupa efetivamente), está a alojar o modelo. Se nenhum processo ultrapassar algumas centenas de megabytes e os custos da API continuarem a aumentar, está a alojar um agente ou assistente e a alugar o modelo. Se essa lista estiver vazia porque tudo acontece num separador do navegador, é cliente de um assistente. É uma opção adequada até precisar de software que atue em seu nome.

Qual pretende executar?

• Para manter o texto privado, execute o modelo: aloje um LLM localmente com Ollama e, quando um utilizador passar a dez, compare os tempos de execução em Ollama e vLLM.
• Para controlar todo o ciclo e as ferramentas, crie o agente: crie o seu próprio agente de IA numa VPS.
• Para ter algo funcional ainda hoje, implemente uma opção pronta de agentes autoalojados que vale a pena executar.
• Se nenhuma destas opções tiver ainda um servidor por baixo, comece por o que uma VPS oferece realmente.

FAQ

Um agente de IA é apenas um LLM com etapas adicionais?

As etapas adicionais são o produto. Um LLM transforma texto em texto e não faz mais nada. Um agente envolve o LLM com ferramentas que pode chamar e com um ciclo que continua a chamá-las. Essas ferramentas têm credenciais, por isso o resultado pode alterar um ficheiro, uma base de dados ou um serviço em produção. É por isso que um agente precisa de uma máquina sempre ligada, de um gestor de serviços e de uma política de segredos. Um LLM precisa apenas de memória suficiente para manter os seus pesos enquanto responde.

Preciso de uma GPU para executar um agente de IA?

Não para o agente. O ciclo consiste em pedidos HTTP, processamento de JSON e chamadas a subprocessos. Qualquer CPU gere essas tarefas enquanto aguarda pela rede. Só precisa de uma GPU quando aloja os pesos do modelo localmente e pretende obter mais do que alguns tokens por segundo. Um agente que chama um modelo alojado num serviço funciona confortavelmente num VPS pequeno sem qualquer GPU.

De quanta RAM precisa um VPS para um agente de IA?

Cerca de 2 GB quando o agente chama um modelo alojado num serviço, porque mantém apenas o runtime, as respetivas dependências e uma pequena base de dados local. Se alojar os pesos, adicione também o modelo: qwen3:8b requer, por si só, cerca de 8 GB. Por isso, uma máquina que concentra todos os componentes começa nesse valor e aumenta conforme o modelo escolhido.

Posso alojar um assistente de IA localmente e manter as minhas conversas privadas?

Sim, com uma ressalva que determina tudo. Um frontend alojado localmente, como o Open WebUI, mantém as contas e o histórico no seu servidor. As conversas só permanecem privadas se o modelo utilizado também estiver alojado localmente. Se apontar o mesmo frontend para uma API alojada num serviço, o texto continua a sair da sua máquina em cada mensagem. Nesse caso, mantém o histórico, mas não a privacidade.

Qual é a diferença entre um agente de IA e um chatbot?

Um chatbot responde e para. Um agente decide o que fazer a seguir, chama uma ferramenta, lê o resultado e decide novamente, até concluir a tarefa ou atingir um limite que o interrompa. O teste prático é o seguinte: se o software consegue alterar algo sem que uma pessoa prima um botão entre a resposta e a ação, trata-se de um agente. Nesse caso, precisa do alojamento e das salvaguardas associados a esse funcionamento.