---
title: "Como orquestrar SLM e LLM em produção para cortar custo sem explodir latência"
author: "Ricardo Pupo Larguesa"
date: "2026-05-14 14:52:00-03"
category: "Na Prática"
url: "http://scale.press/portal/aintuicao/post/2026/05/14/como-orquestrar-slm-e-llm-em-producao-para-cortar-custo-sem-explodir-latencia/md"
---

## Resumo
- SOMA adapta SLM via LoRA nos primeiros turnos para servir o restante do diálogo
- Redução de custo e latência mantendo coerência em conversas longas
- Orquestração entre modelo pequeno e grande substitui a escolha binária
- Latência do gate pode anular ganhos em aplicações de tempo real
- Código disponível e análise teórica no arXiv

---

O paper [SOMA](https://arxiv.org/abs/2605.11317), publicado no arXiv em 11 de maio de 2026, descreve uma forma concreta de servir diálogos multi-turno sem pagar o preço cheio de um LLM grande em toda a conversa. A técnica usa os primeiros turnos para estimar o manifold de respostas local e adapta um modelo pequeno via soft prompts e LoRA localizada. Depois, um gate simples decide se o modelo pequeno já basta ou se é preciso voltar para o modelo grande.

Em termos práticos, o sistema destila conhecimento do LLM proprietário para um SLM que roda localmente ou em instâncias menores. Os experimentos mostram redução de custo e latência mantendo coerência em conversas longas, fazendo uma adaptação específica ao contexto da conversa atual.

A tese que me interessa aqui é que a discussão de 2026 não é mais "qual modelo escolher", mas "como orquestrar modelo pequeno e grande no mesmo fluxo". Já escrevi sobre memória episódica em maio, quando discutimos a migração de SaaS para modelos locais de 3B parâmetros. O SOMA vai um passo além ao propor que o modelo pequeno não precisa ser estático. Ele pode ser ajustado rapidamente por turno sem fine-tuning completo.

Entretanto, existe um contraponto que vale colocar na mesa. A latência adicional do gate e da eventual rollback pode anular boa parte da economia em aplicações de tempo real. Em cenários onde o usuário espera resposta em menos de 800 ms, o overhead de decidir qual modelo chamar pode ser maior que o ganho de custo. Na [T2S](https://t2s.com.br) já vimos isso acontecer com pipelines híbridos: a arquitetura fica elegante no papel e lenta na prática.

Para quem está implementando agora, três pontos práticos merecem atenção. Primeiro, o método exige que os primeiros turnos sejam representativos. Se o usuário muda de assunto radicalmente depois do terceiro turno, o modelo pequeno adaptado pode degenerar. Segundo, o rollback para o modelo grande precisa ser confiável e barato de detectar. Terceiro, o custo de manter o gate em produção não é zero e deve ser medido antes de prometer redução de 70 % na conta.

Em sala de aula, observo que os alunos que testam arquiteturas híbridas costumam tropeçar exatamente no ponto de decisão: eles otimizam o modelo pequeno para média de benchmark e esquecem que produção cobra o pior caso. O SOMA oferece uma forma mais estruturada de fazer essa decisão, mas ainda depende de quem define o threshold do gate.

Se você está avaliando pipelines híbridos para algum produto, o SOMA é um dos poucos papers recentes que traz análise teórica junto com código disponível. Vale rodar os experimentos com o seu dataset de conversas reais antes de assumir que o ganho de custo vai aparecer em produção.

Para acompanhar discussões como essa e testar ideias em projetos reais, conecte-se comigo: [https://linktr.ee/ricardo.pupo](https://linktr.ee/ricardo.pupo). Meu livro [Engenharia de Prompt para Devs](https://www.casadocodigo.com.br/products/livro-engenharia-de-prompt) também aborda técnicas de orquestração e controle de custo em sistemas que misturam modelos de tamanhos diferentes.