Arquitetura de LLM: Design de Sistemas para IA em Produção
Executar um modelo é um problema de infraestrutura. Obter valor de um modelo é um problema de arquitetura.
A camada de infraestrutura — tempos de execução, hardware, endpoints de API — determina o que é possível. A camada de arquitetura determina o que realmente acontece com uma solicitação: qual modelo a trata, quanto custa, o que a valida e como as falhas são capturadas.
A maioria dos sistemas começa com um único modelo e nenhuma arquitetura. Isso está correto para prototipagem. Torna-se uma desvantagem em produção.
A arquitetura de LLM abrange as decisões de design que transformam “um modelo que posso chamar” em “um sistema no qual posso confiar”.
Onde a Arquitetura de LLM se Encaixa na Pilha
A arquitetura de LLM situa-se no meio de um modelo de três camadas:
| Camada | O que abrange | Área Relacionada |
|---|---|---|
| Modelos | Tempos de execução, serving, configuração de GPU | Hospedagem de LLM · Performance de LLM |
| Arquitetura | Encaminhamento, custo, barreiras de segurança, orquestração | Você está aqui |
| Aplicações | Assistentes de IA, pipelines de RAG, agentes | Sistemas de IA · RAG |
A camada de arquitetura é frequentemente ignorada no início. Ela torna-se essencial quando você tem mais de um modelo, mais de um tipo de tarefa ou mais de um usuário. Cada padrão de arquitetura neste cluster existe porque “um modelo para tudo” deixou de funcionar.
Mapa do Cluster
Os cinco tópicos deste cluster se complementam. Leia nesta ordem para o caminho mais lógico:
- Você está aqui — este pilar: o que é arquitetura de LLM, como as peças se encaixam
- Prompts — Escrevendo Prompts Eficazes para LLMs — a base: moldando o que o modelo recebe
- Encaminhamento — Estratégias de Encaminhamento de Modelos — o despachante: qual modelo trata o quê
- Custo — Otimização de Custos para Sistemas de LLM — orçamentação de tokens, cache, economia de modelos locais vs API
- Segurança — Barreiras de Segurança (Guardrails) de LLM na Prática — validação de entrada, filtragem de saída, conformidade
- Orquestração — Design de Sistemas Multi-Modelo — padrões sequenciais, paralelos, hierárquicos e de ensemble
Se você só tiver tempo para um, comece com o encaminhamento. É o ponto de decisão onde a arquitetura começa.
Engenharia de Prompts
A engenharia de prompts é a camada mais próxima do modelo. Antes do encaminhamento, antes do cache, antes das barreiras de segurança — está o prompt. O que você envia ao modelo determina o que você recebe de volta.
As técnicas práticas que importam:
- Clareza e estrutura — instruções claras superam estruturas engenhosas
- Exemplos específicos — exemplos de poucos tiros (few-shot) ancoram o comportamento do modelo
- Atribuição de papel — prompts baseados em papel afinam o tom e as restrições
- Abordagens variadas — diferentes formatos revelam a que o modelo responde
- Gestão de contexto — o que você inclui molda o que o modelo pondera
A engenharia de prompts não é uma tarefa única. É uma calibração contínua entre os requisitos da sua tarefa e o comportamento do modelo.
Aprofundamento:
- Escrevendo Prompts Eficazes para LLMs — técnicas práticas para performance de modelos de linguagem
Encaminhamento de Modelos
Uma camada de encaminhamento decide qual modelo trata qual solicitação. Sem ela, cada solicitação vai para o mesmo modelo — frequentemente muito grande para tarefas simples, muito pequeno para as complexas.
Quatro estratégias de encaminhamento cobrem a maioria dos casos de produção:
| Estratégia | Otimizar para | Melhor quando |
|---|---|---|
| Baseada em capacidade | Qualidade da tarefa | Cargas de trabalho de complexidade mista |
| Ciente do custo | Gasto de tokens | Sistemas com restrições orçamentais |
| Ciente da latência | Tempo de resposta | Ferramentas interativas e chat em tempo real |
| Híbrida | Todos os três | Sistemas de produção com restrições reais |
Uma cadeia de fallback lida com falhas: ordene os modelos do melhor ao mais confiável, terminando com um modelo local que não pode ser limitado por taxa ou desligado por uma interrupção de API.
Aprofundamento:
- Estratégias de Encaminhamento de Modelos: Local vs API, Ciente de Custo, Ciente de Latência — encaminhamento baseado em capacidade, ciente de custo e ciente de latência com código Python
Otimização de Custos
Os custos de LLM escalam linearmente com o uso. As estratégias que realmente reduzem a conta:
Orçamentação de tokens define limites por sessão, por tarefa ou adaptativos. Orçamentos adaptativos rastreiam o uso real e ajustam as alocações ao longo do tempo.
Inferência local altera completamente a estrutura de custos. Após a amortização do hardware, os modelos locais rodam pelo custo da eletricidade. Uma GPU com uso moderado paga a si mesma em meses.
Cache é a otimização mais subestimada. Cache de correspondência exata captura prompts repetidos. Cache semântico captura prompts que significam a mesma coisa. Para sistemas de alto tráfego, o cache semântico elimina uma grande parte das chamadas de API antes que elas aconteçam.
Cadeias de fallback reduzem o custo médio por solicitação: prefira modelos caros quando o orçamento permitir, recorra a modelos mais baratos ou locais à medida que a sessão progride.
Aprofundamento:
- Otimização de Custos para Sistemas de LLM: Orçamentação de Tokens, Modelos de Fallback, Cache — números reais de hardware, tabelas de ponto de equilíbrio e padrões Python funcionais
Barreiras de Segurança (Guardrails)
Os LLMs são imprevisíveis por padrão. As barreiras de segurança restringem o que entra e o que sai — sem remover a capacidade do modelo.
Três camadas de barreiras de segurança importam na prática:
Validação de entrada para problemas antes que alcancem o modelo. A sanitização de prompts captura tentativas de injeção. Limites de comprimento previnem o desperdício de tokens. Filtros de conteúdo bloqueiam violações de política antes que a inferência custe algo.
Filtragem de saída captura problemas após a geração. A validação estrutural garante formas de resposta esperadas. Verificações de conteúdo bloqueiam saídas prejudiciais. Verificação de fatos (para domínios críticos) valida afirmações contra uma base de conhecimento.
Mecanismos de segurança protegem o sistema ao longo do tempo: limitação de taxa previne abuso, orçamentos de tokens limitam os custos por solicitação, gestão da janela de contexto previne transbordamento e vazamento de dados entre turnos.
Para sistemas pesados em conformidade (GDPR, HIPAA, SOC 2), adicione registro de auditoria com entradas estruturadas e apenas de acréscimo e controles de residência de dados.
As barreiras de segurança lidam com a conversa do modelo, mas uma vez que agentes chamam ferramentas e delegam trabalho a outros agentes, uma segunda camada de segurança torna-se necessária: quem pode agir, em nome de quem e com qual rastro de auditoria. Isso é segurança de protocolo, não filtragem de I/O de modelo.
Aprofundamentos:
- Barreiras de Segurança (Guardrails) de LLM na Prática: Validação de Entrada, Filtragem de Saída, Segurança — padrões práticos de barreiras de segurança e notas de conformidade
- Segurança de Agentes A2A e MCP: Identidade, Delegação e Rastros de Auditoria — segurança de protocolo de agentes além da segurança de prompts: identidade, autorização, gateways e controles de delegação
Design de Sistemas Multi-Modelo
Quando um único modelo não é suficiente, a questão de arquitetura é: como orquestrar múltiplos modelos sem criar complexidade que custa mais do que economiza?
Cinco padrões cobrem o espaço:
| Padrão | Latência | Custo | Qualidade | Usar quando |
|---|---|---|---|---|
| Modelo Único | Mais baixa | Mais baixo | Variável | Prototipagem, cargas de trabalho uniformes |
| Sequencial (Pipeline) | Alta | Médio | Alta | Fluxos de trabalho multi-etapa com especialização |
| Paralelo (Fan-Out) | Baixa | Alta | Alta | Tarefas independentes, teste A/B |
| Hierárquico (Planejador-Executor) | Alta | Alta | Mais alta | Raciocínio complexo com execução especializada |
| Ensemble | Médio | Mais alto | Mais alta | Decisões críticas requerendo consenso |
A regra geral: comece com o padrão mais simples que lida com suas restrições reais. A maioria dos sistemas de produção atinge o paralelo ou hierárquico apenas após o encaminhamento baseado em capacidade deixar de ser suficiente.
Aprofundamento:
- Design de Sistemas Multi-Modelo: Quando Usar Qual Modelo e Porquê — todos os cinco padrões com código Python funcional e tabelas de compensação
Framework de Decisão de Arquitetura
Use isto como um triage rápido para o que adicionar e quando:
| Problema | Solução | Quando adicioná-lo |
|---|---|---|
| A conta é muito alta | Encaminhamento ciente de custo, cache, inferência local | Quando os custos de API se tornam uma linha orçamental real |
| A latência é muito alta | Encaminhamento ciente de latência, modelos menores | Quando os utilizadores notam lentidão |
| A qualidade é inconsistente | Encaminhamento baseado em capacidade, cadeia de fallback | Quando tarefas simples recebem modelos caros ou tarefas complexas recebem modelos baratos |
| Os utilizadores estão a abusar do sistema | Validação de entrada, limitação de taxa | Quando você abre acesso para além de uma equipa de confiança |
| As respostas são inseguras ou fora da política | Filtragem de saída, barreiras de conteúdo | Quando você serve utilizadores gerais |
| Um modelo trata de tudo | Design multi-modelo | Quando as cargas de trabalho divergem o suficiente para justificar a complexidade |
| Os prompts não estão a funcionar | Iteração de engenharia de prompts | Sempre — os prompts precisam de ajuste conforme as tarefas evoluem |
Construa a arquitetura de baixo para cima. A engenharia de prompts está sempre em escopo. Adicione encaminhamento quando as compensações de custo/qualidade se tornarem reais. Adicione barreiras de segurança quando servir utilizadores externos. Adicione orquestração multi-modelo por último.
Como a Arquitetura de LLM se Relaciona com os Outros Tópicos
A arquitetura de LLM situa-se na interseção de vários clusters relacionados:
Infraestrutura (abaixo desta camada):
- Hospedagem de LLM em 2026: Infraestrutura Local, Auto-hospedada e em Nuvem Comparadas — tempos de execução (Ollama, llama.cpp, vLLM), hardware e decisões de serving. Os padrões de arquitetura dependem da infraestrutura disponível. O encaminhamento ciente de custo só faz sentido se você tiver modelos locais e de API a rodar.
- Performance de LLM em 2026: Benchmarks, Garrafalos e Otimização — números de latência, limites de VRAM, medições de throughput. Estes são os inputs empíricos para decisões de encaminhamento e seleção de modelo.
Camadas de aplicação (acima desta camada):
- Sistemas de IA: Assistentes Auto-hospedados, RAG e Infraestrutura Local — os sistemas que consomem decisões de encaminhamento, barreiras de segurança e orquestração. A arquitetura multi-modelo é um pré-requisito para assistentes de IA em produção.
- Tutorial de Geração Aumentada por Recuperação (RAG) — O RAG é em si um padrão de arquitetura: um pipeline de recuperação alimentando contexto em um LLM. Os padrões de encaminhamento, custo e barreiras de segurança deste cluster aplicam-se também dentro dos pipelines de RAG.
Camada operacional:
- Observabilidade: Monitorização, Métricas, Guia Prometheus e Grafana — a arquitetura de LLM em produção precisa de observabilidade. O rastreamento de custos, monitorização de latência e métricas de violação de barreiras de segurança requerem instrumentação na camada de arquitetura, não apenas na camada de infraestrutura.
