Olá a todos!
Quem me lê aqui há algum tempo já sabe quais são os meus moinhos: a dependência cega dos modelos de fronteira proprietários é uma fragilidade estratégica, e cada ferramenta que nos devolve o controlo sobre a nossa própria infraestrutura de IA merece atenção séria. Escrevi sobre isso quando vos mostrei o Open WebUI, quando testei o MAESTRO, quando passei seis dias com o AMALIA, e quando os EUA desligaram modelos da Anthropic para estrangeiros de um dia para o outro e a Europa fingiu que não era com ela.
Hoje venho desenhar mais um pouco no círculo que está ainda incompleto. Porque uma coisa é correr modelos abertos localmente. Isso já vos mostrei como fazer, e bem. Outra coisa, bem mais interessante, é treinar os vossos próprios modelos localmente, com os vossos dados, para os vossos casos de uso, sem que um único byte saia da vossa rede. E isso, até há pouco tempo, exigia uma equipa de machine learning, notebooks de Python cheios de armadilhas, e uma paciência que a maioria de nós não tem.
O Unsloth acabou com essa desculpa. E o Unsloth Studio, a interface web que a equipa lançou este ano, acabou com a desculpa seguinte.
Shall we begin?
Primeiro, o contexto: o que é o Unsloth e porque é que metade do mundo já o usa?
Para quem nunca ouviu falar, o Unsloth é um projecto open source criado pelos irmãos Daniel e Michael Han que faz uma coisa aparentemente impossível: torna o fine-tuning de modelos de linguagem radicalmente mais rápido e mais leve em memória, sem perder precisão. Os números oficiais do projecto falam em treinar mais de 500 modelos cerca de 2x mais depressa com 70% menos VRAM, e nas variantes MoE (os modelos de mistura de peritos, como o DeepSeek ou o gpt-oss) chegam a reclamar 12x mais velocidade com 35% menos memória.
Como é que eles fazem isto? Kernels Triton escritos à mão, matemática reordenada com cuidado obsessivo, e uma atenção ao detalhe que já os levou a encontrar e corrigir bugs nos próprios modelos das grandes casas. A equipa trabalha directamente com quem faz o gpt-oss, o Qwen, o Llama, o Mistral, o Gemma e o Phi, e não é raro ver correcções do Unsloth a melhorar a precisão dos modelos originais. Não é marketing: é engenharia de baixo nível feita por gente que percebe do assunto.
O resultado prático é que o repositório passa hoje das 66 mil estrelas no GitHub, e tornou-se a ferramenta de facto para quem quer fazer fine-tuning sem hipotecar a casa em GPUs. Um modelo de 7 mil milhões de parâmetros, que há três anos exigia um cluster e um orçamento a sério, treina-se hoje numa RTX 4090 durante uma noite. Ou numa RTX 3090 em segunda mão, se formos honestos quanto ao que a maioria dos casos de uso realmente precisa.
Mas o Unsloth clássico, aquilo a que agora chamam Unsloth Core, continuava a ser código. Notebooks, scripts, hiperparâmetros, formatos de dataset. Acessível para quem programa, intimidante para o resto do mundo. E é aqui que entra a novidade que justifica este post.
Unsloth Studio: todo o ciclo de vida de um modelo numa interface web local
O Unsloth Studio (ainda em Beta, convém dizer já) é uma interface web open source e no-code para correr, treinar e exportar modelos abertos, tudo numa única aplicação local. Windows, Linux, WSL e macOS. Sem conta na cloud, sem telemetria obrigatória, sem enviar dados a ninguém. A própria documentação sublinha que corre 100% offline, com autenticação por token para quem quiser expor a instância na rede interna.
E quando digo “todo o ciclo de vida”, quero mesmo dizer todo:
Procuram e descarregam modelos directamente da interface, em GGUF, safetensors ou adaptadores LoRA. Gemma, Qwen, DeepSeek, gpt-oss, Llama, Mistral, Phi, e mais umas centenas. Texto, visão, áudio TTS e modelos de embeddings, tudo suportado.
Conversam com eles numa interface de chat decente, com upload de imagens, PDFs, código, DOCX e áudio. Podem comparar modelos lado a lado, o que é óptimo para decidir qual deles serve para o vosso caso antes de investir tempo em treino.
Criam datasets a partir dos vossos documentos. Volto a isto já a seguir, porque é possivelmente a funcionalidade mais subestimada do pacote.
Treinam o modelo com esses dados, com observabilidade em tempo real do processo. Loss, métricas, progresso, tudo visível enquanto acontece, em vez do clássico terminal a cuspir números que ninguém interpreta.
Exportam o resultado para GGUF ou safetensors de 16 bits, prontos a servir no llama.cpp, no Ollama, no vLLM, ou onde vos apetecer.
E servem o modelo através de um endpoint compatível com a API da OpenAI, o que significa que qualquer ferramenta que fale esse dialecto, e hoje em dia falam praticamente todas, pode usar o vosso modelo local como backend. A documentação dá exemplos concretos de ligação ao Claude Code e ao Codex: o agente de código que usam todos os dias, mas a responder com um modelo vosso, treinado por vocês, a correr na vossa máquina.
Há mais duas coisas que me fizeram levantar a sobrancelha, pela positiva. Primeiro, o tool calling com auto-correcção: quando o modelo falha uma chamada de ferramenta, o Studio tenta recuperar em vez de rebentar, e inclui pesquisa web nativa. Segundo, a execução de código em sandbox, ao estilo dos Artifacts do Claude: o modelo pode escrever e correr Python e Bash num ambiente isolado para verificar as próprias respostas com computação real, em vez de alucinar aritmética. Num exemplo da própria equipa, um Qwen de 4 mil milhões de parâmetros pesquisou mais de vinte websites e citou fontes dentro do próprio processo de raciocínio. Localmente.
Isto tudo junto transforma o Studio naquilo que eu descreveria como um atelier completo de IA local. Não é só uma interface de chat, não é só um treinador de modelos. É o sítio onde um modelo aberto entra genérico e sai especializado.
Data Recipes: a funcionalidade que resolve o problema
Deixem-me contar-vos um segredo sujo do fine-tuning empresarial: o problema quase nunca é o treino. É o dataset. Toda a gente tem terabytes de documentos internos, manuais, tickets de suporte, contratos, relatórios. Ninguém tem esses dados no formato de pares pergunta-resposta que um treino supervisionado exige. E transformar uma pilha de PDFs num dataset de instrução decente era, até agora, trabalho manual tedioso ou um projecto de engenharia por si só.
As Data Recipes do Studio atacam exactamente isto. Arrastam PDFs, CSVs, JSONs, DOCX ou ficheiros de texto para a interface, e o sistema gera datasets sintéticos estruturados a partir deles, prontos para treino. Sem dataset prévio, sem scripts de conversão, sem aquela fase do projecto em que alguém passa três semanas a limpar dados no pandas e a questionar as suas escolhas de vida.
Sejamos claros quanto aos limites, porque eu não vos vendo banha da cobra: dados sintéticos gerados automaticamente não substituem um dataset curado por quem percebe do domínio. Se o material de origem for lixo, o dataset será lixo com melhor formatação. Mas como ponto de partida para validar se um caso de uso justifica investimento, isto reduz o custo de experimentação de semanas para uma tarde. E na prática, é essa redução que decide se uma empresa experimenta ou não.
O hardware: mais acessível do que pensam, com as ressalvas do costume
Falemos de requisitos, porque é a pergunta que me vão fazer nos comentários de qualquer maneira.
Para inferência, ou seja, para simplesmente correr modelos e conversar com eles, o Studio funciona até em CPU, e no macOS suporta inferência GGUF e MLX com aceleração nativa do Apple Silicon. Um Mac com 32 GB de memória unificada corre confortavelmente modelos na casa dos 7 a 14 mil milhões de parâmetros quantizados, e um mini PC com uma GPU modesta faz o mesmo.
Para treino, a história é um pouco mais exigente mas continua longe do proibitivo. Nas GPUs NVIDIA, o suporte cobre as RTX 30, 40 e 50, além de Blackwell, DGX Spark e afins. No macOS, o treino via MLX já funciona dentro do Studio, o que há um ano parecia ficção científica. Nas AMD, o chat e as Data Recipes funcionam no Studio, mas o treino ainda passa pelo Unsloth Core em código; o suporte completo está prometido. Multi-GPU já existe, com melhorias anunciadas.
Traduzindo para euros: uma workstation com uma RTX 4090, ou duas 3060 usadas do OLX se quiserem ir pelo caminho frugal que eu tanto estimo, chega para fazer fine-tuning QLoRA de modelos até bem acima dos 20 mil milhões de parâmetros. E já que falo em QLoRA, dois parágrafos de contexto para quem chegou agora, porque a sigla assusta mais do que devia. O LoRA (Low-Rank Adaptation) é a técnica que torna tudo isto viável em hardware de consumidor: em vez de reescrever os milhares de milhões de pesos do modelo original, treina-se um pequeno conjunto de matrizes adicionais que capturam a especialização, e o resultado é um ficheiro adaptador de 50 a 200 MB que se cola ao modelo base. O QLoRA vai mais longe e faz esse treino sobre o modelo quantizado a 4 bits, cortando os requisitos de memória para uma fracção. O detalhe operacional que as empresas deviam adorar: uma única GPU consegue servir dezenas de adaptadores diferentes sobre o mesmo modelo base, o que significa que o departamento jurídico, o suporte e a contabilidade podem ter, cada um, o “seu” modelo especializado, todos a partilhar a mesma máquina.
E se preferirem alugar em vez de comprar, o preço de uma H100 por hora caiu para valores na ordem de 1,30 dólares nas clouds especializadas, segundo o relatório de custos de fine-tuning da Spheron de Março de 2026. O mesmo relatório estima que afinar um modelo de 7B custa hoje menos de 5 dólares e demora horas. Cinco dólares. Uma experiência falhada custa menos que um menu no McDonald’s, e isso muda completamente a maneira como se decide o que experimentar.
Como pôr isto a funcionar no vosso homelab ou empresa.
O processo de instalação em Linux e macOS é anticlimático, e digo isto como elogio. Com Python e, para treino, o PyTorch instalados:
pip install unsloth
unsloth studio setup
unsloth studio
E está. A interface abre no browser, localmente. Se quiserem aceder a partir de outras máquinas da vossa rede, o clássico:
unsloth studio -H 0.0.0.0 -p 8888
Há uma flag --secure para servir sobre HTTPS, e por omissão a instância só é acessível localmente, que é exactamente o comportamento por defeito correcto. Para quem vive em Docker, como grande parte dos leitores desta casa, existe a imagem oficial unsloth/unsloth com tudo lá dentro, GPU passthrough incluído:
docker run -d -e JUPYTER_PASSWORD="mudem-isto" \
-p 8888:8888 -p 8000:8000 \
-v $(pwd)/work:/workspace/work \
--gpus all \
unsloth/unsloth
E o Windows? Funciona, mas não vos vou pôr aqui os comandos, e a razão é simples: a instalação em Windows tem particularidades suficientes, como a ordem de instalação do PyTorch e os detalhes do suporte CUDA, para que copiar meia dúzia de linhas de um blog seja a receita perfeita para uma tarde de frustração. O repositório no GitHub tem um guia dedicado ao Windows e até um script de instalação próprio, o install.ps1, que trata do processo de forma guiada. Quem estiver em Windows deve seguir esse guia oficial, que é mantido e actualizado pela equipa; e quem puder, sinceramente, use o WSL, onde os comandos acima funcionam tal e qual e a vida é mais simples.
O fluxo de trabalho típico, e falo do fluxo que faz sentido numa empresa e não numa demo de conferência, é este: escolhem um modelo base pequeno e aberto, um Qwen ou um Gemma na casa dos 4 a 9 mil milhões de parâmetros; despejam os vossos documentos internos nas Data Recipes e geram um dataset; revêem esse dataset, porque rever dados de treino não é opcional, é o trabalho; treinam com LoRA, acompanhando as métricas na interface; comparam o modelo afinado com o base, lado a lado, no chat; exportam para GGUF; e servem via endpoint OpenAI-compatible para as vossas aplicações internas, ou ligam-no directamente ao Claude Code da equipa de desenvolvimento.
Reparem no que não aparece neste fluxo: nenhum contrato com um fornecedor de API, nenhum dado a atravessar o Atlântico, nenhuma factura mensal que cresce com o sucesso do produto. É o vosso modelo. No sentido literal de propriedade.
Uma nota para quem pensa nisto ao nível de equipa e não de bancada individual: o facto de o Studio expor um endpoint compatível com a API da OpenAI significa que ele encaixa naturalmente no ecossistema que muitos de vós já têm montado. Podem pô-lo atrás do Open WebUI como mais um backend, servir vários adaptadores LoRA a partir da mesma GPU para diferentes departamentos, e ligar tudo isto ao LiteLLM para routing e controlo de custos centralizado. As peças de que vos tenho falado nos últimos meses não são projectos isolados: são componentes de uma mesma arquitectura, e o Studio acrescenta-lhe a peça que faltava, a fábrica onde os modelos se especializam antes de irem servir.
Os notebooks: 250+ receitas de treino especializado, de borla
Antes de passar à tese deste post, há um recurso que merece secção própria, porque é onde o Studio e o Unsloth Core se encontram: o repositório de notebooks da equipa, com mais de 250 notebooks de fine-tuning e reinforcement learning prontos a usar, organizados por modelo e por tipo de treino, todos com preparação de dados, treino e inferência incluídos. A lista completa e catalogada está na documentação oficial, com versões para Google Colab e para Kaggle.
Porque é que isto interessa, se o Studio é justamente a interface que dispensa código? Por duas razões. A primeira é pedagógica: os notebooks mostram-vos o que acontece debaixo do capô, célula a célula, e não há maneira melhor de perceber o que a interface está a fazer por vós do que fazê-lo uma vez à mão. A segunda é práctica: os notebooks cobrem técnicas de especialização que vão além do fine-tuning supervisionado básico, e são a porta de entrada para casos de uso avançados que mais tarde levam para dentro de casa.
Alguns exemplos do que lá encontram, para vos abrir o apetite. Notebooks de treino conversacional para o Qwen3, o Llama 3.2 e o Phi-4, que é o ponto de partida típico para assistentes internos. Notebooks de visão para o Qwen3-VL e para os Gemma, para quem precisa de modelos que leiam documentos digitalizados, faturas ou imagens técnicas. Notebooks de GRPO, a técnica de reinforcement learning que ensina modelos a raciocinar através de recompensas verificáveis, incluindo um para o gpt-oss de 20B e exemplos deliciosamente concretos como treinar um Gemma a resolver Sudoku ou a jogar 2048, que parecem brincadeira mas são o melhor tutorial de RL com recompensas que vão encontrar. Notebooks de embeddings, com o Qwen3-Embedding e o embeddinggemma, para quem quer afinar a componente de recuperação do seu RAG com vocabulário do próprio domínio, uma jogada muito subvalorizada. Notebooks de TTS com o Orpheus, para voz. E, o meu favorito para o nosso contexto, notebooks de continued pretraining para adaptar modelos a outras línguas, que é exactamente o tipo de receita relevante para quem quer um modelo que escreva português europeu como deve ser, tema que me é caro desde que testei o AMALIA.
Dois links directos para começarem já: o notebook do Llama 3 com exportação automática para o Ollama, que fecha o ciclo treino-para-produção-local numa sentada, e o notebook de inferência do gpt-oss em MXFP4, para quem quer experimentar o modelo aberto da OpenAI sem instalar nada. Os restantes estão todos indexados no repositório e na documentação, e não vos vou colar aqui a lista inteira porque ela muda todas as semanas.
O detalhe que torna isto verdadeiramente democrático: a esmagadora maioria dos notebooks foi desenhada para caber no escalão gratuito do Colab, uma T4 com menos de 15 GB de VRAM, graças às optimizações de memória do Unsloth. Ou seja, podem validar uma ideia de modelo especializado sem gastar um cêntimo em hardware, e só depois de provada a tese é que trazem o treino para a vossa infraestrutura, via Studio ou via Core. Há até notebooks específicos para GPUs AMD com ROCm, disponíveis directamente no GitHub, para quem vive desse lado da barricada. Experimentação gratuita na cloud, produção soberana em casa: é o fluxo com a melhor relação risco-benefício que conheço.
E agora a parte importante: porque é que isto é o futuro das empresas, com números
Chegámos ao ponto do post em que eu deixo de descrever a ferramenta e passo a defender uma tese. E a tese é esta: o futuro da IA nas empresas não vai ser dominado por modelos massivos de fronteira a fazer tudo, mas por frotas de modelos pequenos e altamente especializados, treinados nos dados de cada organização, para garantir duas coisas que nenhum CFO e nenhum responsável de produto dispensam: qualidade previsível e custos controlados. A menos que seja uma superempresa e que tenham pareceria com fornecedores de fronteira.
Não é uma opinião minha tirada do ar. Vejamos as provas.
A evidência académica e industrial. Em 2025, investigadores da NVIDIA publicaram um position paper com um título que dispensa interpretação: “Small Language Models are the Future of Agentic AI”. O argumento central é que, para as tarefas especializadas que compõem os sistemas de agentes, os modelos pequenos são suficientemente capazes, inerentemente mais adequados e necessariamente mais económicos. E os números que a própria NVIDIA apresenta são brutais: servir um modelo de 7 mil milhões de parâmetros é estimado como 10 a 30 vezes mais barato do que servir um modelo na gama dos 70 aos 175 mil milhões. Quando o fabricante que mais dinheiro ganha a vender GPUs para modelos gigantes vos diz que os modelos pequenos chegam para a maioria das tarefas, convém ouvir.
A evidência dos custos operacionais. Uma análise comparativa de 2026, com base nos dados da Ideas2IT, coloca o custo de um milhão de conversas mensais via API de modelo de fronteira entre 15 mil e 75 mil dólares por mês, consoante o modelo e o escalão. O mesmo volume, servido por um modelo pequeno afinado a correr em infraestrutura própria, fica entre 150 e 800 dólares mensais. Não é uma diferença de otimização; é uma diferença de 20x a 100x, para tarefas onde o modelo pequeno, treinado no domínio, tem desempenho igual ou superior. Análises de TCO independentes apontam para períodos de retorno do investimento inicial em infraestrutura entre 4 e 8 meses para cargas de trabalho de volume médio.
A evidência da qualidade. Este é o ponto que mais gente subestima, porque a intuição diz que maior é melhor. A intuição está errada quando a tarefa é estreita. Um modelo generalista de fronteira carrega conhecimento sobre poesia renascentista, culinária tailandesa e direito marítimo quando aquilo que precisam é de classificar tickets de suporte em português técnico da vossa empresa. Todo esse conhecimento extra não é ativo: é ruído, e ruído gera variância nas respostas. A literatura confirma-o desde o Gorilla em 2023, que mostrou modelos pequenos especializados a bater modelos grandes generalistas em geração de chamadas de API, até aos relatos de sectores regulados citados pela Alithya, onde empresas com SLMs especializados reportam cerca de 35% menos erros críticos nos outputs face a quem depende de LLMs genéricos, além de reduções de latência na ordem dos dois terços. Para um chatbot de apoio ao cliente, latência é experiência. Para um sistema de classificação de documentos numa clínica ou num escritório de advogados, taxa de erro é responsabilidade legal.
A evidência do padrão de arquitectura que está realmente a ser adoptado. As empresas que estão a fazer isto bem não escolheram entre fronteira e local. Montaram routing: cerca de 80% dos pedidos, os previsíveis, repetitivos e de alto volume, vão para modelos pequenos especializados dentro de casa; os 20% genuinamente complexos escalam para um modelo de fronteira. É o padrão que múltiplos deployments empresariais confirmam, e é o padrão que faz sentido. Ninguém precisa de pagar raciocínio de fronteira para extrair um NIF de uma factura. E ninguém deve confiar a um modelo de 4B a arquitectura de um sistema distribuído. Cada modelo no lugar certo, cada euro no sítio certo.
A evidência orçamental, que é a que convence quem assina. Há uma diferença estrutural entre pagar por token e pagar por infraestrutura que os relatórios de custos raramente sublinham: a previsibilidade. Uma API de fronteira é um custo variável que cresce com o uso, o que significa que o vosso melhor cenário de negócio, o produto a descolar, é também o vosso pior cenário de custos, e a meio do ano descobrem que o orçamento de IA rebentou porque os clientes gostaram demasiado da funcionalidade. Um modelo especializado em infraestrutura própria inverte a lógica: o custo é fixo e conhecido, e cada pedido adicional custa, na margem, praticamente electricidade. Junta-se a isto o factor energético, que vai deixar de ser nota de rodapé muito em breve: servir modelos de 4 a 9 mil milhões de parâmetros consome uma ordem de grandeza menos energia por pedido do que os gigantes, e numa Europa com os preços de electricidade que conhecemos e regulação de sustentabilidade a apertar, essa conta vai aparecer nos relatórios ESG quer queiram quer não.
E a evidência que eu acrescento sempre, porque vivemos na Europa: controlo. Já vimos acesso a modelos ser cortado por decisão administrativa de outro país, sem aviso, a meio de uma tarde. Já vimos ferramentas a enviar repositórios inteiros para fornecedores sem consentimento claro. Um modelo especializado treinado por vocês, guardado num ficheiro GGUF no vosso servidor, não vos pode ser retirado por um decreto de exportação, não muda de comportamento numa actualização silenciosa que rebenta com os vossos prompts em produção, e não leva os dados dos vossos clientes na bagagem. Qualidade e custo justificam a decisão perante o CFO; soberania justifica-a perante o board.
As concessões, porque eu não sou vendedor
Convém dizer o que isto não é. O Studio está em Beta, e comporta-se como tal: vão encontrar arestas, o suporte AMD para treino ainda não chegou à interface, e algumas funcionalidades mudam de quinzena a quinzena. Fine-tuning também não é um martelo para todos os pregos: se o vosso problema é conhecimento factual actualizado, a resposta chama-se RAG, não treino, e o padrão que efectivamente funciona em produção combina os dois, com o fine-tuning a moldar comportamento e formato, e o RAG a fornecer factos. E há casos de uso, os de raciocínio aberto e multidisciplinar, onde os modelos de fronteira continuam sem rival e vão continuar durante bom tempo. Eu próprio os uso todos os dias, e não finjo o contrário.
Mas nada disso belisca o argumento central. A questão nunca foi “fronteira ou local”. A questão é que a fatia do trabalho empresarial que exige fronteira é muito mais pequena do que as facturas mensais das APIs sugerem, e a tecnologia para reclamar o resto acabou de ficar acessível a qualquer equipa com uma GPU de gaming e uma tarde livre.
Por onde começar, em concreto
Se gerem tecnologia numa empresa, o meu conselho é o mesmo que dou sempre, agora com uma ferramenta melhor para o executar. Identifiquem dois ou três casos de uso de alto volume e âmbito estreito que hoje pagam a uma API externa: classificação de emails, extração de campos de documentos, resumos de tickets, respostas de primeira linha. Meçam o que isso custa por mês, porque garanto-vos que a maioria não mede. Depois instalem o Unsloth Studio numa máquina com uma RTX qualquer, despejem uma amostra dos vossos documentos nas Data Recipes, treinem um Qwen ou um Gemma pequeno durante uma noite, e comparem os resultados com o que a API vos devolve, lado a lado, na mesma interface.
Na pior das hipóteses, perderam um fim de semana e ganharam literacia técnica que vos vai ser exigida mais cedo ou mais tarde. Na melhor, e a probabilidade não é pequena, descobrem que uma fatia respeitável da vossa factura de IA pode passar a viver num servidor vosso, mais rápida, mais precisa no vosso domínio, e imune ao humor regulatório de administrações alheias.
O sloth do logótipo é uma piada da equipa: a preguiça que treina depressa. Mas a metáfora que eu tiro daqui é outra. Durante três anos, as empresas habituaram-se a alugar inteligência ao quilo, e a renda só tem subido. O Unsloth Studio é uma das primeiras ferramentas que torna a alternativa, ser dono em vez de inquilino, acessível a quem não tem uma equipa de ML. As empresas que perceberem isto primeiro vão ter os produtos mais consistentes e as margens mais saudáveis. As outras vão continuar a pagar a renda.
Até já!
Nuno