Até pouco tempo atrás, a estratégia de IA de muita empresa cabia numa pergunta: qual é o maior e melhor modelo de linguagem disponível na nuvem? A disputa era entre GPT, Claude e Gemini, e o que se media era a qualidade da resposta em texto.

Essa pergunta ficou pequena. Quando a IA sai do teste e passa a rodar milhares de vezes por hora dentro de um processo, o custo e a demora de cada chamada começam a pesar tanto quanto a qualidade. Pôr um modelo de conhecimento geral, com centenas de bilhões de parâmetros, para dizer se um pedido é de cobrança ou de suporte é como ligar uma turbina de avião para mover um carrinho de golfe. Funciona, só que sai caro.

O que está tomando o lugar dessa pergunta é a IA modular: vários tipos de modelo trabalhando juntos, cada um na decisão em que rende mais, e uma regra clara de quando a tarefa passa de um para outro.

Vale um cuidado com os nomes logo no começo. LLM e SLM falam de tamanho. LFM fala de arquitetura, do jeito como o modelo faz as contas. Sistema 1 fala do tipo de resposta que o modelo devolve. Um mesmo modelo pode ser pequeno, ter arquitetura líquida e responder só com valores tipados. Por isso a pergunta do título é de desenho: que tipo de modelo cada decisão pede, olhando qualidade, demora, custo e as regras de governança da empresa. As quatro categorias se sobrepõem, e um sistema bem feito costuma usar várias ao mesmo tempo. SLMs e boa parte dos LFMs também são modelos de linguagem; o que os separa de um LLM é o porte, a arquitetura e a especialização, e não a função. Por isso este texto não propõe dispensar o LLM. Propõe deixar de usá-lo como escolha automática.

E existe uma opção que vem antes de todas elas, a de não usar modelo nenhum.

A tese que defendemos neste texto é a seguinte: a inteligência de um sistema depende menos da força de um modelo e mais de como as capacidades se combinam para produzir decisões confiáveis, que caibam no orçamento e que alguém consiga governar. Com isso, a pergunta sobre qual é o melhor modelo perde força. No lugar dela entram outras, mais úteis para quem opera: de que capacidade esta tarefa precisa, qual é o menor custo para a qualidade exigida, quando uma inferência probabilística é de fato necessária e quem responde pela decisão automatizada.

Em resumo

  • A primeira pergunta é se a decisão precisa de um modelo: quando uma regra em código resolve, a regra decide. A IA entra onde há ambiguidade, interpretação ou contexto que a lógica explícita não alcança.
  • Modelo grande e modelo pequeno não são rivais: modelos pequenos e especializados dão conta de boa parte das tarefas repetitivas de um agente, e o grande fica para a conversa aberta e o raciocínio amplo [5]. Os LFMs reduzem memória no dispositivo, com pesos fixos depois do treino [7].
  • Resposta no formato certo ainda pode estar errada: modelos de Sistema 1, como o Jev, devolvem valores tipados com probabilidade [8], mas formato e confiança alta não garantem que a decisão esteja correta.
  • Quem decide a passagem entre modelos responde por ela: a regra olha a confiança, o custo do erro e a política da empresa, e cada decisão precisa poder ser reconstituída por inteiro.

Do grande ao pequeno

Os grandes modelos de linguagem (LLMs) seguem sendo a melhor ferramenta para tarefas abertas: redigir, resumir, conversar, raciocinar sobre um problema mal definido. A arquitetura por trás deles, o Transformer, foi descrita em 2017 [1]. O que mudou foi a distribuição. Modelos de pesos abertos, como Llama (Meta), Qwen (Alibaba) e DeepSeek, encostaram nos modelos fechados e tornaram possível rodar IA de ponta na infraestrutura da própria empresa. O relatório do DeepSeek-V3 atribui o custo baixo de treino a um conjunto de escolhas de engenharia, entre elas a mistura de especialistas (MoE), que ativa só uma parte dos parâmetros a cada passo, e o treino em precisão reduzida [2].

Ao mesmo tempo, ganharam espaço os modelos de linguagem pequenos (SLMs), em geral abaixo de 10 bilhões de parâmetros, como a série Phi da Microsoft [4] e as versões menores do Llama e do Qwen. Pesquisadores da NVIDIA defendem que esses modelos bastam, se encaixam melhor e custam menos para a maior parte das chamadas de um sistema de agentes, porque essas chamadas são repetitivas, de escopo fechado e quase nunca conversacionais [5]. O trabalho é um artigo de posição, sem experimentos próprios com agentes, e deve ser lido assim. A conclusão prática se sustenta: um modelo pequeno, ajustado para uma tarefa, pode bastar para ela, mas não dá para esperar que ele empate com um modelo grande fora dela.

Modelos pequenos também rodam no próprio aparelho ou no servidor da empresa. Isso reduz a demora e pode manter dado sensível dentro de casa, desde que o modelo e o caminho do dado estejam de fato sob controle da empresa.

LFMs: menos memória, sem mágica

O Transformer original usa atenção plena: cada posição do texto é comparada com todas as outras, e o custo dessa comparação cresce com o quadrado do tamanho do contexto [1]. Os modelos de hoje amenizam isso de vários jeitos. Na geração, um cache guarda o que já foi calculado e evita refazer contas, mas ocupa memória que cresce junto com o contexto. Há também atenção por janela, atenção esparsa e arquiteturas híbridas. Entre as linhas que buscam outro caminho estão os modelos de espaço de estados, como o Mamba [12], e os modelos da Liquid AI, empresa criada em 2023 por pesquisadores do laboratório de ciência da computação e IA do MIT.

A pesquisa de origem da Liquid AI são as redes de constante de tempo líquida, redes contínuas no tempo em que a dinâmica de cada neurônio depende da entrada [6]. A empresa apresentou os primeiros Liquid Foundation Models (LFMs) em setembro de 2024, sem pesos públicos [11], e lançou em julho de 2025 o LFM2, com pesos abertos para uso no aparelho [7].

Dois exageros sobre os LFMs aparecem com frequência.

O primeiro é dizer que eles ajustam os parâmetros em tempo real. Os pesos ficam fixos depois do treino, como em qualquer modelo publicado. O que muda com a entrada é o cálculo: a Liquid AI descreve operadores cujos pesos efetivos são gerados, a cada passo, a partir da própria entrada [7]. O modelo se adapta ao que recebe, mas não aprende enquanto é usado.

O segundo é tratar o LFM2 como uma rede líquida aplicada à linguagem, ou como um modelo que dispensa a atenção. Ele descende daquela pesquisa, mas foi encontrado por uma busca automática de arquiteturas, medida em processadores de celular e de notebook, e é um híbrido: na versão original, 10 blocos de convolução curta e 6 blocos de atenção agrupada [7]. O ganho vem de usar menos atenção. A Liquid AI informa decodificação duas vezes mais rápida que a do Qwen3 em CPU [7], número do próprio fornecedor.

Há ainda um ponto de contrato. Os pesos do LFM2 saíram sob uma licença baseada na Apache 2.0, com uso comercial livre só para empresas com receita abaixo de 10 milhões de dólares; acima disso, é preciso licença comercial [7]. Esses números e essa licença são do LFM2 original. A Liquid já lançou gerações posteriores, e quem for escolher um modelo hoje precisa conferir, com o jurídico, as condições da versão que vai usar.

Modelos de Sistema 1: decidir rápido, sem escrever

A psicologia separa dois modos de pensar, um rápido, automático e intuitivo, e outro lento e deliberado. Os nomes Sistema 1 e Sistema 2 foram propostos por Stanovich e West [13] e ficaram conhecidos com Daniel Kahneman, em Rápido e devagar [3].

Nos últimos dois anos, boa parte do dinheiro investido em IA foi para o lado do Sistema 2, com modelos de raciocínio como o o1 da OpenAI [14] e o DeepSeek-R1 [10], que gastam mais tempo e mais tokens pensando antes de responder. Só que muitas decisões dentro de um software são de outro tipo: classificar um pedido, ler se a descrição de uma despesa sugere uma violação da política, escolher para onde mandar uma tarefa. São perguntas de resposta curta, que pedem velocidade e uma medida de confiança, e não um parágrafo.

Foi para esse espaço que a TypeSafe AI lançou o Jev, em acesso antecipado, em 15 de setembro de 2026 [9]. A empresa o chama de seu primeiro modelo de Sistema 1. Convém registrar que o nome é uma proposta dela, uma analogia com a psicologia; ainda não existe uma categoria técnica estabelecida com esse nome.

O Jev não gera texto. Ele recebe um estado em texto ou JSON e um conjunto de perguntas definidas em código, e devolve uma distribuição de probabilidade por pergunta, em três formatos: verdadeiro ou falso, escolha entre opções e nota numa escala [8]. As perguntas rodam em paralelo na mesma chamada. Na versão atual, a 1.14, de 14 de outubro de 2026, a entrada é só texto, com até 64 mil tokens por chamada, e a precisão é melhor em inglês, a língua principal do treino; há ainda um quarto formato, que localiza objetos em imagens, que a própria TypeSafe classifica como experimental [8]. Segundo a TypeSafe, a resposta chega entre 70 e 500 milissegundos, de 40 a 200 vezes mais rápido que um modelo de fronteira em perguntas desse formato, com probabilidades calibradas [9]. A própria empresa avisa que as avaliações foram feitas pela equipe dela e que os ganhos devem estar no limite superior do que se verá na prática [9].

A TypeSafe escreve também que, por abrir mão de gerar texto, o Jev não consegue alucinar [9]. Isso vale para o formato: ele não inventa um campo nem escapa do esquema. Não vale para o conteúdo. O modelo pode devolver "fraude = verdadeiro", com 0,98 de confiança, no formato perfeito, e estar errado. São três coisas diferentes. O tipo garante que a resposta cabe no contrato. A calibração garante que, num grupo grande de respostas, a confiança acompanha o acerto, mas não diz nada sobre uma resposta isolada [8]. A consistência garante respostas parecidas para entradas parecidas, o que inclui repetir o mesmo erro.

Há mais dois limites. O Jev roda só na API da TypeSafe, sem pesos abertos, e o dado enviado sai da empresa. E, como todo modelo que lê conteúdo, ele pode ser influenciado por texto escrito para manipulá-lo, o risco que o OWASP chama de injeção de prompt [15]. Quem pensar em usá-lo como filtro de segurança precisa fazer essa conta.

Classificadores rápidos existem há muito tempo. A novidade é um modelo de uso geral, configurado por perguntas em código e não por treino específico para cada tarefa, que devolve uma confiança que o software pode usar.

Como as peças trabalham juntas

É tentador desenhar isso como uma escada, em que toda tarefa entra por baixo e sobe até achar quem resolva. Na prática funciona melhor um orquestrador que olha a tarefa e escolhe o recurso. Os recursos, do mais barato ao mais caro, costumam ser estes:

  • Regra em código. Se a nota fiscal passa de R$ 10 mil e o valor está num campo numérico, uma comparação resolve, sempre do mesmo jeito, e qualquer auditor consegue refazer. Quando uma decisão pode ser escrita como regra validada e barata de executar, ela vence qualquer modelo.
  • Modelo de Sistema 1. Classifica, encaminha e responde perguntas fechadas onde há interpretação, em milissegundos. Na documentação da TypeSafe, é o código do cliente que combina essas respostas em fluxos previsíveis [8].
  • Modelos pequenos e LFMs. Resumem, extraem e analisam textos, áudios e registros longos perto de onde o dado está, com menos memória e menos nuvem. Também podem fazer triagem, sem um modelo de Sistema 1.
  • LLM. Entra quando a tarefa é aberta ou ambígua, e pode ser o primeiro recurso, se a tarefa já chega assim.

Esses quatro são exemplos, e não a lista inteira. Numa empresa, a pilha de modelos costuma ser bem maior: modelos de embedding e de reordenação para busca, modelos de documento e de leitura de imagem, transcrição e síntese de voz, aprendizado de máquina clássico, como os modelos de crédito e de fraude que os bancos usam há anos, modelos de previsão de séries temporais, modelos de guarda que filtram entrada e saída, e avaliadores que conferem o trabalho de outros modelos. Ao lado deles ficam peças que nem são modelos, como regras, otimizadores e grafos de conhecimento. O raciocínio deste texto vale para a pilha toda: cada peça entra porque uma tarefa precisa dela, com custo medido, regra de passagem e alguém que responde por ela.

Agir em sistemas externos não é privilégio do LLM. Quem age é o agente, e o que ele pode fazer depende das ferramentas que recebeu, das permissões e dos controles em volta dele, seja qual for o modelo por dentro.

A parte delicada é a regra de passagem. Usar só a confiança do modelo é pouco. Uma probabilidade bem calibrada nos testes pode deixar de ser confiável quando os dados mudam, quando alguém tenta enganar o modelo ou quando aparece um caso que a avaliação não cobriu. E uma decisão pode ter confiança alta e um custo de erro inaceitável: errar a classificação de um pedido comercial custa pouco, aprovar uma transação indevida custa muito. A regra precisa olhar a confiança, medida com dados representativos, junto com o custo do erro em cada direção, o falso positivo e o falso negativo, e com a política da empresa. Caso incerto, caso crítico ou caso fora das condições em que o modelo foi validado vai para uma verificação a mais, para outro modelo ou para uma pessoa. É a mesma lógica de autonomia por ação e na medida do risco que defendemos para agentes.

Esse desenho cria quatro decisões que alguém precisa tomar e manter:

  1. A regra de passagem. Quem define o limiar de cada passagem, com base em confiança, custo do erro e política, e quem o revê quando o erro aparece.
  2. O caminho do dado. Uma triagem numa API externa e uma análise num modelo local têm riscos de privacidade diferentes, e a política precisa dizer que dado vai para que modelo.
  3. A decisão reconstituível. Fixar a versão do modelo é o começo, mas não basta. Para refazer uma decisão é preciso saber também as instruções, as ferramentas, o contexto recuperado, os parâmetros, os dados de entrada e a regra de negócio que valia naquele dia. E um nome de versão estável numa API não prova, sozinho, que o modelo por trás não mudou.
  4. O custo de cada camada, posto ao lado do ganho que ela gera, medido no processo e não na conta de tokens.

Como decidir com evidência

Nada disso garante, de antemão, que a arquitetura modular sai mais barata. Orquestrar, integrar, observar e manter várias peças também custa. A forma honesta de decidir é medir. Pense num processo com um milhão de solicitações por mês e em três estratégias:

  • A. Toda solicitação passa por um LLM.
  • B. Um modelo menor classifica e manda ao LLM só os casos difíceis.
  • C. Regras em código, modelos especializados e LLM se combinam conforme a tarefa e o risco.

Rode as três sobre a mesma amostra de casos reais, com a resposta certa conhecida, e compare cinco números: o custo total no mês, incluindo a operação e não só a inferência; a demora no pior caso comum (o percentil 95); a qualidade das decisões, separando falso positivo de falso negativo; a fração de casos que passa adiante ou vai para uma pessoa; e o esforço da equipe para manter tudo funcionando. Não dá para saber antes qual vence, e a resposta muda de processo para processo. O que importa é que a escolha saia dos números da própria empresa, e não da fama do modelo.

Onde isso aparece no mapa do mercado

Pela nossa leitura dos Hype Cycles do Gartner de 2026, sistemas multiagentes estão no pico das expectativas no ciclo de IA Agêntica, e a orquestração de agentes e os agentes guardiões ainda estão no começo da curva. No ciclo de IA, FinOps para IA e IA soberana estão no pico, e a observabilidade de IA está no começo [16].

A curva mede expectativa e maturidade, e não adoção, então é preciso cuidado com o que se tira dela. A nossa interpretação é que a atenção do mercado está indo para a combinação de modelos e agentes, e que as questões em aberto são justamente as de orquestração, custo, soberania e governança. A ligação de cada termo a uma das quatro decisões acima também é leitura nossa: orquestração é a regra de passagem, IA soberana é o caminho do dado, observabilidade é a decisão reconstituível e FinOps para IA é o custo de cada camada.

É nesse conjunto que a Arcogi trabalha. Na arquitetura de agentes, cada agente usa só os modelos que a empresa liberou para aquele tipo de dado, e cada ato deixa um recibo com a sua origem. Um provedor de decisão como o Jev entra como recurso do hub, com a chave da própria empresa, tráfego limitado ao endereço autorizado, versão fixa e um período em sombra antes de decidir de verdade.

Conclusão: arquitetura modular é decisão de gestão

A vantagem em IA está saindo do encanto com o assistente que conversa sobre tudo e indo para a eficiência da arquitetura. Distribuir o trabalho entre regras, modelos grandes e pequenos, modelos líquidos e modelos de Sistema 1 tem tudo para reduzir o custo total, proteger melhor os dados e dar aos processos a velocidade de que eles precisam.

Resumindo a tese em uma linha: o problema define a inteligência de que se precisa, a arquitetura define como usá-la e a governança define até onde vai a autonomia. Por isso nem toda decisão precisa de um LLM, mas toda decisão automatizada precisa de critérios.

A redução de custo, porém, é uma hipótese a medir em cada caso. Cada camada a mais traz mais um fornecedor, mais um contrato, mais um ponto por onde o dado sai e mais uma decisão automática que alguém vai ter de explicar. A arquitetura modular só se paga quando cada camada tem custo medido, quando cada decisão pode ser refeita do começo ao fim e quando uma pessoa responde pela regra que manda a tarefa de um recurso para outro.

A IA propõe. A arquitetura governa. A pessoa responde.

Fundamentos e leituras

  1. Vaswani, A. et al. Attention Is All You Need. Advances in Neural Information Processing Systems 30 (NeurIPS 2017). acessar
  2. DeepSeek-AI. DeepSeek-V3 Technical Report. arXiv:2412.19437, dezembro de 2024. acessar
  3. Kahneman, D. Thinking, Fast and Slow. Farrar, Straus and Giroux, 2011. Edição brasileira: Rápido e devagar: duas formas de pensar. Objetiva, 2012. acessar
  4. Abdin, M. et al. Phi-3 Technical Report: A Highly Capable Language Model Locally on Your Phone. arXiv:2404.14219, 2024. acessar
  5. Belcak, P. et al. (NVIDIA Research). Small Language Models are the Future of Agentic AI. arXiv:2506.02153, junho de 2025; versão 3, setembro de 2026 (artigo de posição). acessar
  6. Hasani, R.; Lechner, M.; Amini, A.; Rus, D.; Grosu, R. Liquid Time-constant Networks. Proceedings of the AAAI Conference on Artificial Intelligence, 35(9), 7657–7666, 2021. acessar
  7. Liquid AI. Introducing LFM2: The Fastest On-Device Foundation Models on the Market. Blog da Liquid AI, 10 de julho de 2025. acessar
  8. TypeSafe AI. System One, Primitives, Box e Models (Jev 1.14, 14/10/2026), na documentação. docs.typesafe.ai, consultado em 3 de novembro de 2026. acessar
  9. Almeida, D. Introducing System One Models & Jev. Blog da TypeSafe AI, 15 de setembro de 2026. acessar
  10. DeepSeek-AI. DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. arXiv:2501.12948, janeiro de 2025. acessar
  11. Liquid AI. Liquid Foundation Models: Our First Series of Generative AI Models. Blog da Liquid AI, 30 de setembro de 2024. acessar
  12. Gu, A.; Dao, T. Mamba: Linear-Time Sequence Modeling with Selective State Spaces. arXiv:2312.00752, 2023. acessar
  13. Stanovich, K. E.; West, R. F. Individual differences in reasoning: Implications for the rationality debate? Behavioral and Brain Sciences, 23(5), 645–665, 2000. acessar
  14. OpenAI. Learning to Reason with LLMs. 12 de setembro de 2024. acessar
  15. OWASP GenAI Security Project. LLM01:2025 Prompt Injection. OWASP Top 10 for LLM Applications 2025. acessar
  16. Gartner. Hype Cycle for Agentic AI, 2026 (abril de 2026) e Hype Cycle for Artificial Intelligence, 2026 (agosto de 2026), resumidos em See 3 of the Most Popular Gartner Hype Cycles. Gartner, 2026. Posições lidas nos gráficos, de forma aproximada. acessar