O paper SOMA, 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 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. Meu livro Engenharia de Prompt para Devs também aborda técnicas de orquestração e controle de custo em sistemas que misturam modelos de tamanhos diferentes.