Início / Blog / LLM local
IA local e arquitetura backend

Arquitetura local de LLM com Ollama, ChromaDB e FastAPI

Executar um modelo na própria máquina pode ampliar o controle dos dados, permitir trabalho offline e baratear experimentos. Isso não torna o serviço automaticamente seguro ou pronto para produção. Uma arquitetura útil separa a API, o runtime de inferência, o modelo de embeddings, o banco vetorial e o ciclo de vida dos documentos; também deixa visíveis latência, memória, autorização e falhas.

Dê uma responsabilidade clara a cada componente

Mantenha execução do modelo, busca e contrato da API operáveis de forma independente
1 / ClienteRequisição autenticada e entrada limitada.
2 / FastAPIValidação, política, timeout e resposta.
3 / BuscaConsulta Chroma com filtros de origem e cliente.
4 / OllamaEmbeddings e geração no hardware gerenciado.
5 / RetornoResposta fundamentada, citações e ID de rastreio.

Separe a indexação das perguntas

A ingestão documental é uma tarefa controlada: extrair arquivos, associar metadados estáveis de origem e versão, segmentar pela estrutura, gerar embeddings e gravar IDs determinísticos. No caminho de consulta, autentique a pessoa, aplique permissões, gere o embedding da pergunta com o modelo compatível, recupere um conjunto limitado de passagens e monte o contexto com referências. Separar os fluxos facilita reindexação, retries e controle de qualidade.

Use o mesmo modelo de embeddings e o mesmo pré-processamento no índice e na consulta. Trocar o modelo ou as dimensões é uma migração: crie uma coleção compatível, compare os resultados e faça a virada de forma explícita. Guarde versões, regras de segmentação e hashes das fontes para explicar como o corpus foi produzido.

Trate o limite do FastAPI como uma API real

LimiteDecisão operacionalPor que importa
EntradaLimitar corpo, prompt e tipos de arquivoControla memória, latência e abuso
ConcorrênciaSemáforo de inferência ou filaEvita esgotar RAM/VRAM em picos
TimeoutOrçamentos separados para busca e geraçãoEvita conexões presas e falhas imprevisíveis
IdentidadeAutenticar antes dos filtros por clienteImpede exposição cruzada de documentos
ObservabilidadeID, modelo, tempos e status sem prompts sensíveisAjuda no diagnóstico sem registrar segredos

Use o ciclo de vida da aplicação para inicializar clientes compartilhados e encerrá-los corretamente. Evite carregar uma cópia do modelo por worker da API: muitas vezes a memória do modelo é o recurso escasso, não o processamento das requisições. Valide exatamente a configuração de workers e GPU que será operada.

Planeje memória, carga do modelo e vazão

Pesos, tamanho de contexto, lotes, gerações simultâneas e busca vetorial disputam recursos. Quantização pode reduzir memória com uma troca potencial de qualidade; meça a tarefa e tokens por segundo no hardware de destino. Inicialização fria, espera na fila e geração são partes diferentes da latência. Acompanhe cada uma separadamente.

Limite concorrência e tamanho das filas. Se o usuário puder aguardar, retorne um identificador de tarefa e um endpoint de status em vez de manter conexões HTTP ilimitadas. Defina o comportamento com modelo indisponível, disco cheio ou índice em reconstrução. Um serviço local ainda precisa de backup dos documentos e metadados vetoriais, além de restauração testada.

Local não significa privado por padrão

Prenda as portas de inferência e do banco ao loopback ou a uma interface privada protegida; não as exponha diretamente à internet. Defina autenticação, TLS, autorização e limites de taxa em uma fronteira clara. Mantenha chaves fora do repositório e restrinja quais usuários e processos acessam o modelo e os documentos. Revise telemetria, relatórios de falha, uploads temporários e logs, que também podem vazar conteúdo sensível.

Arquivos recuperados podem conter instruções maliciosas. Trate-os como contexto não confiável, não habilite ferramentas sem necessidade explícita e nunca deixe uma passagem conceder autoridade. Implemente retenção e exclusão que removam de forma coerente a fonte e seus trechos derivados.

Avalie o serviço completo

Monte um conjunto fixo de perguntas, fontes esperadas, critérios de resposta e casos de recusa. Teste recall e ranking da busca separados de fundamentação, precisão das citações e utilidade da resposta. Inclua concorrência, entradas longas, índice vazio, versões antigas, fronteiras de acesso e reinicialização do modelo. Compare alterações de modelo e quantização em qualidade e operação.

Em resumo

Ollama, ChromaDB e FastAPI compõem uma pilha local útil quando cada responsabilidade está clara: a ingestão mantém o corpus, a busca aplica permissões, a inferência tem limites de recurso e a API oferece um contrato confiável. “Local” é uma decisão de implantação, não uma garantia de segurança. Meça qualidade, capacidade e recuperação na máquina e no fluxo que você realmente vai manter.

Referências