O stack vertical de SLM: GPU, treino e camada de aplicação para IA específica de domínio em 2026

Stack vertical de SLM: as camadas de GPU, treino e aplicação

A 1 de julho de 2026, o CEO da Palantir, Alex Karp, sentou-se no programa Squawk Box da CNBC e disse algo que todos os compradores de IA empresarial pensavam, mas que ninguém com tribuna tinha dito em voz alta: «Algo correu completamente mal na forma como a IA é vendida.» O diagnóstico foi preciso. As empresas estão a pagar por tokens que não produzem qualquer valor operacional. Os pesos dos modelos treinados com os seus dados proprietários, a verdadeira inteligência competitiva, voltam para os laboratórios. E o modelo de preços foi desenhado para o manter dependente, não capaz.

A resposta de Karp é a soberania: controle a sua computação, os pesos dos seus modelos, o seu stack de dados e a sua vantagem. Não é uma posição filosófica. É uma decisão de arquitetura. E a arquitetura para onde aponta tem nome: o stack vertical de SLM.

Este artigo explica como é esse stack, como construir cada camada e porque é que um fundador com um caso de uso específico pode superar um modelo de fronteira de uso geral no seu próprio problema, por uma fração do custo.

Porque é que o modelo de pagamento por token está a desmoronar-se

A economia de alugar inteligência a um laboratório de fronteira fazia sentido em 2023. Os modelos pareciam magia, construir o seu era proibitivo e as diferenças de benchmark entre modelos grandes e pequenos eram enormes. Nenhuma dessas três condições se verifica em 2026.

Os modelos de pesos abertos (Llama 3.2, Phi-4-mini, Gemma 3) são agora 16 vezes mais baratos por token do que as API de fronteira e muitas vezes igualam-nas ou superam-nas em tarefas restritas e bem definidas. A infraestrutura de fine-tuning que há dois anos exigia uma equipa de engenheiros de ML corre agora numa única A100 numa tarde. E o mundo empresarial começou a fazer contas. Os tópicos do Reddit e os canais do Discord onde os engenheiros de ML falam com franqueza contam a mesma história: para classificação, extração, resumo, geração de código num âmbito definido e saída estruturada (que cobrem cerca de 80% das cargas de trabalho reais de IA empresarial), um modelo de 7B ajustado bate um modelo de 70B guiado por prompts em precisão, latência e custo ao mesmo tempo.

As contas que estão a mudar comportamentos

API de LLM de fronteira

$2–$30 por milhão de tokens

$15,000–$75,000/mês em escala

Os seus dados treinam o modelo deles

Latência: 2–8 segundos

SLM ajustado (alojado internamente)

$0.10–$0.50 por milhão de tokens

$150–$800/mês em escala

Os seus dados ficam na sua infraestrutura

Latência: 80–300 ms

A diferença de custo não é marginal. É uma ordem de grandeza. E acumula-se à medida que o volume cresce. Uma startup que processa 500,000 chamadas à API por mês tem pela frente $10,000–$40,000 em faturas de tokens, ou $300–$600 a alojar internamente um SLM ajustado. Essa diferença paga dois engenheiros.

O que é, afinal, um modelo de linguagem pequeno?

Os SLM são modelos de linguagem na gama de 1 a 15 mil milhões de parâmetros. Parece uma distinção técnica, mas tem implicações práticas concretas: correm numa única GPU (ou até em CPU em algumas configurações), são ajustados em horas em vez de semanas, cabem em ambientes de periferia e em instalações próprias, e produzem inferência em 80–300 ms em vez de segundos.

Os principais SLM de pesos abertos em 2026 são:

Phi-4-mini (3.8B, Microsoft): atualmente o líder em benchmarks na classe de 3–4B. Corre em ~3 GB de VRAM, janela de contexto de 128K, lidera em MMLU e raciocínio matemático. Excecional para tarefas de raciocínio estruturado com uma pegada reduzida.
Gemma 3 (2B / 7B, Google): licença comercial sólida, otimizado para cloud e periferia. Particularmente adequado à compreensão de documentos e ao seguimento de instruções em conversas de vários turnos.
Llama 3.2 (1B / 3B, Meta): concebido para implementação na periferia, em dispositivos móveis e embebidos. O modelo de 1B corre no CPU de um telemóvel. Excelente para encaminhamento, classificação e extração leve.
Mistral 7B / Mixtral 8x7B: fortes em geração de código e seguimento de instruções. A arquitetura MoE esparsa do Mixtral dá-lhe uma força muito acima do seu número de parâmetros ativos.

A ideia-chave é que nenhum destes modelos vai bater o GPT-5 num benchmark geral. Não é esse o ponto. Um modelo de 3.8B ajustado com 50,000 exemplos da sua tarefa específica vai bater o GPT-5 nessa tarefa, e vai fazê-lo por 1/30 do custo e com uma latência 10 vezes menor.

O stack vertical de três camadas

Construir uma capacidade de IA específica de domínio que seja sua de ponta a ponta significa tomar decisões deliberadas em três camadas: computação, treino e aplicação. A maioria dos fundadores que tentaram e falharam tratou-as de forma independente. Não o são. Cada camada limita e possibilita as outras.

Camada 1: GPU (computação)

A camada de GPU é onde a maioria dos fundadores investe demais ou faz a aposta de arquitetura errada. A boa notícia é que os requisitos de hardware para trabalho com SLM verticais em 2026 são muito inferiores aos de há apenas 18 meses.

Para fazer o fine-tuning de um modelo de 7B com LoRA ou QLoRA (a abordagem padrão), precisa de uma única A100 de 80GB ou de duas A6000. Custo na cloud: $2–$4/hora. Uma execução completa de fine-tuning com 10,000 exemplos demora 2 a 6 horas. Total: menos de $25 por execução de treino. Não é uma despesa de capital: é um custo variável que paga quando retreina.

Para inferência, um modelo de 7B quantizado (INT4/INT8) serve 100 a 500 pedidos simultâneos numa única A10G (24GB de VRAM, ~$1.50/hora). Nessa escala, alojar internamente é quase sempre mais barato do que as chamadas à API ao fim de 30 a 60 dias de implementação.

Para requisitos de periferia ou de instalações próprias, comuns na saúde, no setor jurídico e na administração pública, a classe de modelos de 1–3B corre em placas de consumo NVIDIA RTX 4090 (~$2,000) ou em Apple Silicon M3 Ultra. Sem dependência da cloud, sem saída de dados, sem exposição em termos de conformidade.

Guia para escolher o nível de GPU

Modelo de 1–3B, periferia ou instalações próprias: RTX 4090, Apple M3 Ultra, NVIDIA Jetson
Modelo de 7B, fine-tuning e disponibilização na cloud: A10G (inferência), A100 (treino)
Modelo de 13B: 2× A100 ou H100 para treino; A100 para inferência quantizada
Cargas em lote / assíncronas: as instâncias spot reduzem o custo de treino em 60–70%

Camada 2: treino (pipeline de fine-tuning)

Esta é a camada que entrega a verdadeira vantagem competitiva. O modelo base é público. Qualquer pessoa pode começar com o Llama ou o Phi. O que não conseguem replicar são os seus dados de treino: os exemplos específicos do domínio, os casos-limite e os formatos de saída que codificam o seu conhecimento operacional nos pesos do modelo.

Alex Karp disse-o em termos duros: os laboratórios de fronteira estão a «roubar os pesos e a vantagem» das empresas que usam as suas API, porque cada consulta e cada sinal de correção que fornece ao usar uma API na cloud contribui, direta ou indiretamente, para melhorar o modelo deles. Quando é dono do seu pipeline de fine-tuning, esse sinal continua a ser seu.

O fluxo padrão de fine-tuning:

Organize um conjunto de dados específico da tarefa. Precisa de 1,000–50,000 pares instrução–resposta de alta qualidade para a tarefa em causa. A qualidade vale mais do que a quantidade. 2,000 exemplos etiquetados por especialistas superam de forma consistente 50,000 exemplos com ruído. Comece pelas suas saídas existentes (documentos, decisões e dados estruturados do passado), use um modelo de fronteira para gerar dados de treino sintéticos a baixo custo e depois valide uma amostra à mão.
Aplique fine-tuning com LoRA / QLoRA. A Low-Rank Adaptation congela a maioria dos pesos do modelo base e treina apenas um pequeno conjunto de matrizes adaptadoras, tipicamente 0.1–1% do total de parâmetros. É assim que se ajusta um modelo de 7B numa única GPU sem ficar sem memória. Ferramentas: a biblioteca PEFT da Hugging Face, o Unsloth (2 a 5 vezes mais rápido) e o Axolotl para pipelines complexos.
Avalie com rigor antes de lançar. Construa um conjunto de avaliação reservado de 200–500 exemplos com etiquetas de referência. Acompanhe a precisão na tarefa, a taxa de alucinação e o cumprimento do formato. Um modelo com 95% de precisão no seu conjunto de avaliação que falha em casos-limite em produção é pior do que um modelo de 90% com modos de falha conhecidos.
Defina uma cadência de retreino. O valor do modelo multiplica-se quando retreina com saídas e correções de produção. Um ciclo de retreino mensal ou trimestral, alimentado por dados de uso real, cria uma vantagem que se alarga com o tempo. É este o núcleo da vantagem vertical: cada ciclo torna o seu modelo melhor na sua tarefa específica, enquanto as API genéricas continuam genéricas.

Camada 3: camada de aplicação

A camada de aplicação é onde o seu modelo se liga aos fluxos de trabalho reais, e onde vive a maioria das decisões de produto. Acertar nesta camada é o que separa uma demo que funciona de um sistema de produção em que os utilizadores confiam.

Como o seu SLM é restrito por desenho, a camada de aplicação tem de gerir o âmbito com clareza. Um SLM de documentação clínica não deve tentar responder a perguntas médicas gerais. Um extrator de contratos jurídicos não deve tentar dar aconselhamento jurídico. A camada de aplicação impõe esse limite, através da estrutura do prompt, da validação da saída e da lógica de encaminhamento.

Infraestrutura de disponibilização: o vLLM e o Ollama são os dois servidores de inferência open source dominantes em 2026. O vLLM trata da disponibilização multi-inquilino de alto débito com PagedAttention. O Ollama é mais simples de operar e excelente para uso de um só inquilino ou de developers. Ambos suportam modelos quantizados e API compatíveis com a OpenAI, pelo que o código existente que chama a OpenAI pode ser redirecionado para o seu SLM alojado internamente com a alteração de uma única linha de URL.
Imposição de saída estruturada: em tarefas de domínio, quase sempre quer JSON ou saída estruturada. Use descodificação restringida por gramática (Outlines, Guidance ou a saída estruturada integrada do vLLM) para garantir que o modelo devolve uma saída válida e conforme ao esquema. Isto elimina a fonte mais comum de falhas a jusante.
Aumento por recuperação: um stack de SLM + RAG é muitas vezes mais poderoso do que um modelo grande sozinho. O SLM trata do raciocínio e da geração; a camada de recuperação ancora-o em documentos atuais e proprietários. Isto é particularmente eficaz em contextos jurídicos, financeiros e de saúde, onde a atualidade e a fidelidade aos documentos importam mais do que um conhecimento amplo do mundo.
Camada de encaminhamento: em produção, a arquitetura mais inteligente encaminha os pedidos com critério. As tarefas simples e de alto volume vão para o SLM. As complexas, ambíguas ou pouco frequentes escalam para um modelo de fronteira através de uma API. Um classificador de 1B consegue tomar esta decisão de encaminhamento em menos de 10 ms. O resultado: 70–80% dos pedidos são servidos pelo seu SLM barato e rápido, e os restantes 20–30% são escalados. O seu custo médio por consulta desce 85–90% enquanto a qualidade se mantém alta.

Casos de uso verticais em que este stack ganha claramente

A abordagem de SLM vertical não é universalmente melhor do que um modelo de fronteira. É muitíssimo melhor para uma classe específica de problemas: tarefas de alto volume, bem definidas e ricas em dados, num domínio com conhecimento proprietário.

Saúde: documentação clínica

Um modelo de 3B ajustado com notas clínicas, códigos CID e resumos de alta supera de forma consistente os LLM gerais em tarefas de documentação. A latência importa nos fluxos clínicos: 100 ms contra 3 segundos é a diferença entre uma ferramenta usada e uma ferramenta abandonada. A soberania dos dados não é negociável ao abrigo da HIPAA: um SLM alojado internamente é a única opção viável.

Jurídico: extração e revisão de contratos

As tarefas de PLN jurídico (extração de cláusulas, sinalização de riscos, identificação de obrigações) estão entre as que mais se prestam a SLM ajustados. O espaço de saída é restrito: tipos de cláusula específicos, indicadores de risco sim/não, resumos estruturados. Um modelo de 7B treinado com 5,000 contratos anotados encontra disposições que um modelo geral não vê, e sem qualquer risco de documentos confidenciais saírem da infraestrutura da sociedade de advogados.

Finanças: classificação de transações e deteção de anomalias

As instituições financeiras que processam milhões de transações por dia não podem suportar nem o custo nem a latência das API de fronteira. Um modelo de 1–3B ajustado trata da categorização de transações, da extração de sinais de fraude e da análise de textos regulamentares com latência inferior a 100 ms e rastreabilidade total, um requisito regulamentar na maioria das jurisdições.

Indústria: deteção de defeitos e manutenção

Os dados não estruturados dos registos de manutenção, das leituras de sensores e dos relatórios de qualidade são extraordinariamente valiosos e totalmente proprietários. Um SLM ajustado que entende as suas máquinas específicas, os seus modos de falha e as referências das suas peças supera qualquer modelo geral, e pode ser implementado nas suas instalações, no chão de fábrica.

Produtos SaaS: funcionalidades específicas de domínio

Se está a construir um SaaS vertical (para imobiliário, recursos humanos, logística ou educação), integrar um SLM ajustado no seu produto cria uma vantagem de funcionalidade. A sua funcionalidade de IA entende a taxonomia do seu domínio, os padrões de dados dos seus clientes e os seus formatos de saída de uma forma que nenhum concorrente que use uma API genérica consegue replicar sem os seus dados de treino.

A soberania da IA não é ideologia: é arquitetura

O manifesto de nove pontos da Palantir sobre soberania da IA, publicado na véspera da entrevista de Karp à CNBC, lê-se como uma provocação. Na verdade, é um documento de arquitetura. O argumento central é prático: o «tokenmaxxing», o modelo de negócio que cobra por token por inteligência geral, incentiva as coisas erradas. Incentiva scripts descartáveis em vez de sistemas robustos, a dependência em vez da capacidade e o volume de consumo em vez da qualidade do resultado.

A parceria entre a Palantir e a Nvidia anunciada na mesma semana é a expressão comercial desta tese: um «sistema operativo de IA soberano» que dá às instituições controlo sobre a sua computação, os seus modelos e o seu stack de dados como um produto integrado. Quer o compre à Palantir quer o construa por conta própria, a direção é a mesma: seja dono do stack.

Para os fundadores, a implicação é simples. Se a capacidade de IA do seu produto é uma chamada a uma API externa, não tem vantagem defensável. Qualquer concorrente pode fazer a mesma chamada. Se a sua capacidade é um modelo ajustado, treinado com dados proprietários e a correr numa infraestrutura que controla, isso é um verdadeiro ativo competitivo, que se reforça a cada ciclo de retreino e se torna mais difícil de replicar quanto mais tempo o mantiver a funcionar.

Quando o stack vertical é a escolha errada

O stack vertical de SLM nem sempre é o certo. Exige um investimento inicial em curadoria de dados, infraestrutura de treino e disciplina operacional que nem todas as equipas estão em condições de fazer. Três situações em que deve manter-se na API:

Ainda está à procura do encaixe produto-mercado. Se a definição da sua tarefa muda de semana para semana, o fine-tuning é esforço desperdiçado. Construa com uma API até a tarefa estar estável e bem compreendida. Depois, construa o SLM.
Ainda não tem dados etiquetados suficientes. O fine-tuning com menos de 500 exemplos costuma produzir modelos instáveis. Se não conseguir recolher ou gerar mais de 1,000 exemplos de alta qualidade, use few-shot prompting com um modelo de fronteira e invista em paralelo na recolha de dados.
A sua tarefa exige realmente um conhecimento amplo do mundo. A síntese de investigação, o trabalho criativo aberto e as tarefas que exigem integrar contextos reais diversos continuam a favorecer os grandes modelos de fronteira. A abordagem de SLM destaca-se em profundidade, não em amplitude.

Por onde começar

O ponto de entrada prático para a maioria dos fundadores é um fine-tuning piloto numa única tarefa de alto volume, que consiga medir com precisão e que tenha critérios de sucesso claros. Escolha uma tarefa pela qual esteja atualmente a pagar $3,000–$10,000/mês em custos de API. Faça as contas para um SLM de 7B ajustado. O caso de negócio costuma ficar evidente logo no primeiro cálculo.

As três perguntas para saber se está pronto para um SLM vertical

1. Tem uma única tarefa bem definida a correr em alto volume (mais de 10,000 consultas por mês)?
2. Tem, ou consegue gerar, mais de 2,000 exemplos etiquetados dessa tarefa?
3. A soberania dos dados, a latência ou o custo importam o suficiente para justificar 2 a 4 semanas de engenharia?

Se respondeu sim às três, está pronto para construir a primeira camada do seu stack vertical. O resto decorre daí.

A ideia central de Karp, de que algo correu completamente mal na forma como a IA é vendida, é menos uma crítica à OpenAI e à Anthropic do que a constatação de um mercado num ponto de inflexão. A infraestrutura para construir na vertical já é acessível. Os modelos de pesos abertos são suficientemente bons. A economia é convincente. Só falta decidir construir algo que seja seu em vez de alugar algo de que depende.