2 pontos por GN⁺ 2023-12-03 | 1 comentários | Compartilhar no WhatsApp
  • A Unsloth oferece o Unsloth Studio para executar e treinar modelos localmente e o Unsloth Core baseado em código, cobrindo modelos de texto, áudio, embeddings e visão em Windows, Linux, WSL e macOS
  • Os recursos de treinamento oferecem suporte a fine-tuning, RL e pré-treinamento de mais de 500 modelos, com foco em até 2x mais velocidade de treino, até 70% menos VRAM e nenhuma perda de precisão
  • Os recursos de inferência incluem busca, download e execução de modelos GGUF, adaptadores LoRA e modelos safetensors, exportação de modelos, tool calling, busca na web, execução de código e endpoints locais de inferência via API
  • O Unsloth Studio se vincula por padrão ao localhost; --secure usa um túnel HTTPS do Cloudflare, e -H 0.0.0.0 pode expor a porta bruta externamente, então a proteção da chave de API e o uso de --disable-tools são importantes
  • A licença tem estrutura dupla de Apache 2.0 e AGPL-3.0: o pacote Core fica sob Apache 2.0, enquanto alguns componentes opcionais, como a UI do Studio, ficam sob AGPL-3.0

O que a Unsloth oferece

  • O Unsloth Studio (Beta) é uma interface web para executar e treinar modelos localmente
  • O Unsloth Core é a versão baseada em código e tem requisitos diferentes do Studio
  • Os comandos iniciais de instalação são fornecidos por sistema operacional

Recursos de inferência

  • Há suporte para buscar, baixar e executar modelos, incluindo os formatos GGUF, adaptadores LoRA e safetensors
  • É possível salvar ou exportar modelos em GGUF, safetensors de 16 bits e outros formatos
  • O tool calling oferece suporte a tool calling com autorrecuperação e busca na web
  • A execução de código permite que o LLM teste código em um ambiente sandbox com artifacts do Claude
  • Por meio de endpoints de inferência via API, é possível implantar e executar LLMs locais com Claude Code e ferramentas do Codex
  • É possível se conectar a provedores de API como OpenAI e Anthropic, ou a servidores como vLLM e Ollama
  • É possível conversar com imagens, áudio, PDFs, código, DOCX e mais
  • A equipe afirma ter corrigido bugs que melhoram a precisão de modelos em colaboração direta com equipes ligadas a gpt-oss, Qwen3, Llama 4, Mistral, Gemma 1-3 e Phi-4

Recursos de treinamento e desempenho

  • A Unsloth oferece suporte a treinamento e RL para mais de 500 modelos
    • Até 2x mais velocidade de treino
    • Até 70% menos VRAM
    • Nenhuma perda de precisão
  • Usa Triton customizado e kernels matemáticos
    • Há links para um caso de colaboração com PyTorch em RL com FP8
    • Há links para um caso de colaboração com Hugging Face em MoE mais rápido
  • O Data Recipes gera datasets automaticamente a partir de PDF, CSV, DOCX e outros formatos, e permite editar dados em fluxos visuais baseados em nós
  • Em aprendizado por reforço, a ferramenta afirma usar até 80% menos VRAM com GRPO, FP8 e outros modos
  • Os modos de treinamento suportados incluem full fine-tuning, RL, pretraining, treinamento em 4-bit, 16-bit e FP8
  • Os recursos de observabilidade permitem monitorar o estado do treinamento em tempo real, com suporte a loss, uso de GPU e customização de gráficos
  • Há suporte a treinamento Multi-GPU, com grandes melhorias previstas em breve

Requisitos de instalação e execução

  • O Unsloth Studio funciona em Windows, Linux, WSL e macOS
    • CPU: atualmente suporta Chat e Data Recipes
    • NVIDIA: suporta treinamento em RTX 30/40/50, Blackwell, DGX Spark, Station e mais
    • macOS: suporta treinamento, MLX e inferência GGUF
    • AMD: suporta Chat e Data; para treinamento é preciso usar o Unsloth Core, e o suporte no Studio chegará em breve
    • Multi-GPU: já disponível hoje, com grandes upgrades planejados
  • O comando para iniciar o Studio é unsloth studio -p 8888
  • A imagem Docker está disponível como contêiner unsloth/unsloth
  • A instalação do Unsloth Core traz exemplos baseados em uv e Python 3.13
    • Linux, WSL: uv venv unsloth_env --python 3.13 seguido de uv pip install unsloth --torch-backend=auto
    • Windows: depois de instalar Python 3.13 e astral-sh.uv, instalar da mesma forma
    • No Windows, pip install unsloth só funciona se o PyTorch já estiver instalado
  • A instalação para GPUs AMD e Intel segue respectivamente o AMD Guide e o Intel Guide

Acesso remoto e requisitos de segurança

  • Por padrão, unsloth studio se vincula a 127.0.0.1, então só pode ser acessado pela máquina atual
  • --secure fornece acesso apenas por um link HTTPS gratuito do Cloudflare
    • O Studio continua no localhost
    • Se o túnel não iniciar, ele falha de forma fechada e não expõe a porta bruta
  • -H 0.0.0.0 vincula a porta bruta a todas as interfaces de rede
    • Isso permite acesso de qualquer lugar da rede, então deve ser usado apenas em redes confiáveis
  • Ferramentas do lado do servidor, como busca na web, Python e execução de código no terminal, são executadas com as permissões do usuário e vêm ativadas por padrão
  • Qualquer pessoa com acesso ao servidor e à chave de API pode executar código nessa máquina, então a chave de API deve permanecer privada e, ao expor o Studio, é necessário usar --disable-tools

Notebooks gratuitos e exemplos de modelos suportados

  • Há um notebook gratuito do Unsloth Studio para executar e treinar modelos pela interface web
  • Os exemplos de notebooks fornecem métricas de desempenho e economia de memória por modelo
    • Gemma 4 (E2B): 1,5x mais rápido, 50% menos memória
    • Qwen3.5 (4B): 1,5x mais rápido, 60% menos memória
    • gpt-oss (20B): 2x mais rápido, 70% menos memória
    • gpt-oss (20B): GRPO: 2x mais rápido, 80% menos memória
    • Llama 3.1 (8B) Alpaca: 2x mais rápido, 70% menos memória
    • Orpheus-TTS (3B): 1,5x mais rápido, 50% menos memória
  • Também são fornecidas listas separadas de notebooks para Kaggle, GRPO, TTS, embeddings e Vision
  • O catálogo completo de modelos está no Unsloth Catalog, e todos os notebooks podem ser vistos em Unsloth notebooks

Recursos recentes

  • Connections: suporte para conexão com provedores de API como OpenAI e Anthropic, ou servidores como vLLM e Ollama
  • MTP: suporte para executar Qwen3.6 MTP, com configuração automática de MTP por hardware
  • Qwen3.6: o Qwen3.6-35B-A3B pode ser treinado e executado no Unsloth Studio
  • Gemma 4: os novos modelos do Google podem ser executados e treinados diretamente no Unsloth
  • MoE LLM: para DeepSeek, GLM, Qwen e gpt-oss, a ferramenta afirma até 12x mais velocidade de treino e 35% menos VRAM
  • Embedding models: suporte a fine-tuning de embeddings cerca de 1,8x a 3,3x mais rápido
  • 7x longer context RL: um novo algoritmo de batching oferece RL com contexto 7x mais longo em comparação com outras configurações
  • 500K Context: é possível treinar modelos de 20B com mais de 500K de contexto em GPUs de 80GB
  • FP8 & Vision RL: é possível executar FP8 e VLM GRPO em GPUs de consumidor

Licença e projetos de base

  • A Unsloth usa um modelo de licença dupla com Apache 2.0 e AGPL-3.0
    • O pacote principal da Unsloth permanece em Apache 2.0
    • Alguns componentes opcionais, como a UI do Unsloth Studio, usam AGPL-3.0
  • O projeto menciona llama.cpp, Hugging Face transformers, TRL, PyTorch, Torch AO e NVIDIA NeMo DataDesigner

1 comentários

 
GN⁺ 2023-12-03
Comentários do Hacker News
  • Não rodei o código eu mesmo, mas não entendo muito bem como isso é possível
    Ao fazer profiling do fine-tuning de QLoRA Llama-2-70B em PyTorch, a maior parte do tempo de execução ficava nas grandes multiplicações de matrizes das camadas MLP, com um pouco a mais vindo da atenção
    Internamente, este repositório também parece chamar torch.matmul() para MLP e flash_attn_func() para atenção, então parece seguir o mesmo caminho do HuggingFace; por isso fico em dúvida sobre como ele pode ser tão mais rápido assim
    Há alguns kernels em Triton, mas não parece haver Triton para MLP nem para atenção, que são a maior parte do gargalo

    • Eles explicam que isso vem de um autograd customizado e otimizado, o que faz sentido, já que autograd é um componente central do cálculo de derivadas
      Também mencionam melhorias simples, como inlining de funções e otimização de memória, e essas partes certamente têm espaço para otimização
      Só não sei se essas vantagens vão continuar restritas à versão fechada “pro”
      Se forem frutos mais fáceis de alcançar, é bem provável que implementações open source adotem isso em breve
    • Há uma explicação mais detalhada em https://unsloth.ai/introducing
    • São alegações bem grandes trancadas atrás da versão pro paga. Parece um sinal de alerta
  • Ignorando por ora as críticas sobre preço, seria bom encontrar imediatamente um vendedor ou engenheiro de soluções com experiência em empresa de banco de dados em estágio inicial e começar cold calls para clientes avançados com milhares de GPUs
    Para vender isso, o caminho mais promissor parece ser fechar negócios B2B de 200 mil a 300 mil dólares ou mais

  • Para quem tiver interesse, acabei de publicar um novo post no blog cobrindo todas as otimizações
    Também há 59 benchmarks totalmente reproduzíveis: https://unsloth.ai/blog/mistral-benchmark

  • Os resultados parecem promissores, então quero testar por conta própria
    Uma pergunta sobre os benchmarks de desempenho: por que todos os resultados usando 2 GPUs e DDP levam mais tempo do que usar uma única GPU?
    Em ambos os benchmarks, uma época de treinamento faz a mesma quantidade de trabalho, então esse escalonamento reverso é inesperado

    • Há dois motivos principais
      Primeiro, o próprio DDP tem overhead. Em cada etapa de treinamento, a GPU0 e a GPU1 precisam sincronizar ao enviar os gradientes para a GPU0
      Segundo, o HuggingFace aparentemente não é muito bem otimizado para DDP por causa de movimentação ineficiente de dados, e nós corrigimos essa parte. Curiosamente, isso também ficou mais rápido em GPU única
  • Seria ótimo ter uma cronologia organizando essas várias tentativas. Já faz bastante tempo que perdi o fio da meada com tantas variantes
    Parece um trabalho bem grande, a menos que você aceite métricas autorrelatadas como verdade absoluta
    Mesmo assim, sempre há ressalvas dependendo do hardware e do escopo de uso
    Para ficar realmente útil, seria preciso um pipeline de CI/CD com várias configurações de máquina e benchmarks, além de uma forma razoável de comunicar os resultados
    Se alguém fizer isso, vai se tornar absolutamente indispensável

  • Fico curioso sobre como isso se compara com as otimizações do Sam e do llama2 do PyTorch Labs
    https://github.com/pytorch-labs/segment-anything-fast
    https://github.com/pytorch-labs/gpt-fast

    • Aquilo é para inferência, e nosso código é para treinamento
      Também estamos planejando inferência mais rápida no futuro
      Vi o GPT Fast do Chillee, e ele é absurdamente rápido
  • Um pouco relacionado: fico me perguntando se ainda vale a pena usar P100 ou P40
    Eu estava pensando em comprar uma, mas parece que Pascal está perdendo suporte em cada vez mais projetos

    • O P100 provavelmente é compatível com o Flash Attention do Xformers, mas o Triton suporta Compute Capability 7.0 ou superior, e o P100 é 6.0, então isso vira um problema
      Tecnicamente o código pode rodar, mas precisaria ser modificado para remover as mudanças relacionadas ao Triton
  • Parece muito interessante, mas fico confuso sobre por que a versão de maior ganho de velocidade foi bloqueada só para enterprise
    Faz mais sentido deixar a diferença de desempenho entre os planos Free e Paid, e diferenciar o Enterprise por coisas como suporte

    • Boa observação. Nós também pensamos nisso e ainda estamos ajustando a política de preços, então toda sugestão é bem-vinda
      É tudo novo para nós, então estamos construindo isso enquanto aprendemos na prática
  • Mencionam GPUs desde 2018, mas fico curioso por que isso não funciona, por exemplo, em uma 1080 Ti
    Olhando por alto as especificações de hardware, parece suportar CUDA 8 ou mais, e aqui está indicado 7.5
    Alguém poderia explicar melhor?

    • A 1080 Ti infelizmente não dá, porque Triton e Xformers suportam CUDA 7.0, então, a menos que OpenAI e Meta passem a suportar CUDA 6.0, também fica difícil para nós dar suporte
      O principal motivo é que, a partir de Turing, os Tensor Cores passaram a existir, então a multiplicação de matrizes mudou para uma base em Tensor Cores
    • A CUDA Compute Capability da 1080 Ti é 6.1