1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • O ponto central do novo modelo aberto GLM-5.2 da Z.ai é servir como um caso de uso de um modelo enorme rodando localmente, com 744B de parâmetros, 40B de parâmetros ativos e janela de contexto de 1M
  • A Unsloth oferece um caminho para execução local com Dynamic GGUF, e o quant recomendado de 2 bits UD-IQ2_M exige 239GB de disco e um ambiente com pelo menos 245GB de RAM
  • O Dynamic 1-bit mostra cerca de 76,2% de top-1 accuracy e redução de tamanho de 86%, enquanto o Dynamic 2-bit mostra cerca de 82% de accuracy e redução de 84%, contrariando a interpretação de que “o desempenho piora na mesma proporção em que o modelo encolhe”
  • Há dois caminhos de execução: Unsloth Studio e llama.cpp; o Studio oferece busca, download e execução de modelos em MacOS, Windows e Linux, além de RAM offloading e detecção de multiGPU
  • Para usar contexto longo na prática, é preciso reduzir memória com KV cache quantization do llama.cpp; q4_0 permite cerca de 3,5x mais contexto e q4_1 cerca de 3,2x

Visão geral do modelo GLM-5.2

  • GLM-5.2 é o novo modelo aberto da Z.ai e pode ser executado em hardware local via Unsloth Dynamic GGUF
  • As especificações do modelo são as seguintes
    • Parâmetros totais: 744B
    • Parâmetros ativos: 40B
    • Janela máxima de contexto: 1.048.576
  • Ele é apresentado como oferecendo desempenho SOTA em long-horizon coding, reasoning e agentic tasks
  • Segundo a Artificial Analysis e vários benchmarks, ele teria desempenho no nível de Claude 4.8 Opus, GPT-5.5 e Gemini 3.1 Pro
  • A Unsloth afirma ter recebido day-zero access da Z.ai
  • Os arquivos GGUF do GLM-5.2 podem ser baixados em GLM-5.2-GGUF no Hugging Face

Quant recomendado e requisitos de memória

  • Para equilibrar acessibilidade e precisão, é recomendado usar o quant dinâmico de 2 bits UD-IQ2_M
    • Uso em disco: 239GB
    • Cabe diretamente em um Mac com 256GB de memória unificada
    • Com MoE offloading, também funcionaria bem em 1x24GB GPU + 256GB RAM
  • O quant de 1 bit cabe em 223GB de RAM, enquanto 8-bit requer 810GB de RAM
  • Na tabela de requisitos de hardware para inferência, a memória total significa RAM + VRAM ou memória unificada
    • Os valores de memória total exibidos são: 223GB, 245GB, 290–360GB, 372–475GB, 570GB, 810GB
  • Para obter o melhor desempenho, a memória disponível somando VRAM e RAM do sistema deve ultrapassar com folga o quantized model file size

Modo Thinking e configurações de sampling

  • O GLM-5.2 oferece 3 thinking modes
    • non-thinking
    • thinking High
    • thinking Max
  • Para tarefas complexas, é recomendado usar Max Thinking
  • No Unsloth Studio, é possível alternar entre High/Max Thinking e non-Thinking pela interface
  • As configurações para a maioria dos casos de uso são as seguintes
    • temperature = 1.0
    • top_p = 0.95
    • Em outros modos, top_p = 1.0
  • O GLM-5.2 usa reasoning por padrão, e reasoning_effort pode ser "high", "max" ou desativado
  • Exemplos para desativar thinking
    • Shell comum: --chat-template-kwargs '{"enable_thinking":false}'
    • Windows PowerShell: --chat-template-kwargs "{\"enable_thinking\":false}"
  • No llama.cpp, também é possível usar --reasoning on ou --reasoning off
  • Exemplos de configuração de reasoning effort
    • --chat-template-kwargs '{"reasoning_effort":"max"}'
    • --chat-template-kwargs '{"reasoning_effort":"high"}'
    • --chat-template-kwargs '{"enable_thinking":false}'

Precisão do Dynamic GGUF e interpretação de KLD

  • A Unsloth usa o benchmark KLD (KL Divergence) para avaliar a precisão da quantização do GLM-5.2-GGUF
  • O Dynamic 4-bit UD-Q4_K_XL e o Dynamic 5-bit UD-Q5_K_XL são descritos como praticamente lossless na maioria dos casos
  • Quants menores também funcionam com um esquema de alocação dinâmica de precisão, deixando camadas importantes em maior precisão e camadas menos importantes em poucos bits
  • Os números com base em pure top-1% accuracy são os seguintes
    • Dynamic 1-bit: cerca de 76,2% de accuracy, redução de tamanho de 86%
    • Dynamic 2-bit: cerca de 82% de accuracy, redução de tamanho de 84%
    • Comparação de accuracy: {b:76,82}
  • Dizer que ele é 86% menor não significa que seja 86% pior; no caso do Dynamic 1-bit, isso é interpretado como cerca de 24% menos precisão que o modelo completo de 1,5TB
  • “76% accuracy” não quer dizer que em uma pergunta como “The capital of France is” ele escolheria Paris 76% e Sydney 24%
    • Nesse exemplo, Paris seria sempre 100% e Sydney 0%
    • O número de 76% também inclui mudanças de distribuição em filler words e stop words ao longo de todo o corpus
  • Em prompts como “Create a novel”, onde múltiplos começos corretos são possíveis, a distribuição de tokens entre o modelo base e o quantizado pode mudar
    • O baseline pode escolher [I] com 100%, enquanto o modelo quantizado pode dividir a distribuição entre [I] 76% e [The] 24%
    • Isso não significa 24% de chance de gerar saída incorreta ou gibberish
  • O KLD é a distância entre as probabilidades do baseline em BF16 ou Q8_0 e as probabilidades da versão quantizada
    • O objetivo da quantização é minimizar a média da KL divergence entre f(q(W)) e f(W)
    • f é o forward do modelo de linguagem, q é a operação de quantização e W são os parâmetros ou pesos do modelo
    • Se o KLD for 0, o modelo foi reconstruído perfeitamente
  • Rodar KLD em todo o corpus de treinamento, com por exemplo 15T tokens, é caro demais, então a Unsloth otimiza com mean KLD e amostragem de subconjuntos representativos menores
  • Mesmo 99,9% KLD costuma ser considerado bom, e a partir de 4bit haveria ganho maior, então para massive out-of-distribution tasks o Dynamic 4-bit provavelmente seria o mais adequado

Executando com Unsloth Studio

  • O Unsloth Studio é uma web UI open source para IA local e suporta a execução do GLM-5.2
  • Os principais recursos são os seguintes
    • Executar modelos locais em MacOS, Windows e Linux
    • Buscar, baixar e rodar modelos GGUF e safetensor
    • RAM offloading e detecção automática de setup multiGPU
    • Inferência rápida com CPU + GPU via llama.cpp
  • Os comandos de instalação são os seguintes
  • O comando de execução é o seguinte
    • unsloth studio -H 0.0.0.0 -p 8888
    • Depois de iniciar, basta abrir http://127.0.0.1:8888 no navegador ou a URL específica do usuário
  • Também é oferecida uma forma de executar o Studio com segurança via HTTPS
    • Em Windows, Mac e Linux: unsloth studio --secure
    • Isso usa um tunnel gratuito do Cloudflare
  • Na primeira execução, é preciso criar uma password para proteger a conta e depois fazer sign in novamente
  • Na aba Chat do Studio, procure por GLM-5.2 na barra de busca e baixe o modelo e o quant desejados
  • Antes de rodar o modelo, é preciso verificar se há compute suficiente disponível
  • No Studio, os inference parameters devem ser configurados automaticamente, mas o usuário pode alterar manualmente context length, chat template e outras opções
  • Mais informações estão no guia de inferência do Unsloth Studio

Executando com llama.cpp

  • O tutorial do llama.cpp cobre a execução do quant UD-IQ2_M e requer no mínimo 245GB de RAM
  • Para inferência local rápida, é usado o llama.cpp
  • Se você não tiver GPU ou quiser apenas inferência em CPU, troque -DGGML_CUDA=ON por -DGGML_CUDA=OFF
  • Em Apple Mac / dispositivos com Metal, siga com -DGGML_CUDA=OFF, pois o suporte a Metal já vem ativado por padrão
  • O fluxo de build é o seguinte
    • apt-get update
    • apt-get install pciutils build-essential cmake curl libcurl4-openssl-dev -y
    • git clone https://github.com/ggml-org/llama.cpp
    • cmake ... -DGGML_CUDA=ON
    • cmake --build ... --target llama-cli llama-mtmd-cli llama-server llama-gguf-split
    • cp llama.cpp/build/bin/llama-* llama.cpp
  • O llama.cpp também pode ser usado para carregar e baixar o modelo diretamente, de forma parecida com ollama run
  • Como exemplo de tipo de quantização desejado, é usado UD-IQ2_M, e é possível forçar o local de armazenamento com export LLAMA_CACHE="unsloth/GLM-5.2-GGUF"
  • O processo de download direto do llama.cpp pode ser muito lento, então é recomendado fazer o download manualmente

Download manual e exemplos de execução

  • Para um download manual mais rápido, é usado o huggingface_hub
    • pip install huggingface_hub
    • hf download unsloth/GLM-5.2-GGUF --local-dir unsloth/GLM-5.2-GGUF --include "*UD-IQ2_M*"
  • Para near full precision, pode-se usar --include "*UD-Q8_K_XL*"
  • Se o download travar, a orientação é consultar Hugging Face Hub, XET debugging
  • O comando de download do Dynamic 1-bit é o seguinte
    • hf download unsloth/GLM-5.2-GGUF --local-dir unsloth/GLM-5.2-GGUF --include "*UD-IQ1_S*"
  • Os caminhos do modelo no modo conversation são os seguintes
    • 2-bit: unsloth/GLM-5.2-GGUF/UD-IQ2_M/GLM-5.2-UD-IQ2_M-00001-of-00006.gguf
    • 1-bit: unsloth/GLM-5.2-GGUF/UD-IQ1_S/GLM-5.2-UD-IQ1_S-00001-of-00006.gguf
  • O exemplo de execução com llama-cli usa o primeiro shard do GGUF de 2 bits em --model com os seguintes parâmetros
    • --temp 1.0
    • --top-p 0.95
    • --min-p 0.01
  • Nos exemplos de execução direta, também aparece -hf unsloth/GLM-5.2-GGUF:UD-IQ2_M

Funcionamento observado no exemplo de geração

  • A documentação inclui exemplos em que o GLM-5.2 de 2 bits realiza tool-calling e geração de SVG
  • Após rodar o llama-cli, o texto segue com um pedido para gerar um “short Flappy Bird game”
  • O jogo gerado em um único HTML/JavaScript usa o nome Sunset Flier
    • Inclui canvas, tela inicial, tela de game over, HUD de pontuação, NEW BEST! e botão RETRY
    • Sem assets externos, ele gera efeitos sonoros de flap, score, hit e die com Web Audio API
    • O estado do jogo é gerenciado em quatro etapas: READY, PLAYING, DYING, OVER
    • A melhor pontuação é salva com localStorage.getItem('sunsetFlierBest') e localStorage.setItem()
  • A lógica do jogo inclui gravidade, impulso de flap, canos aleatórios, colisão, partículas, tremor de tela e sistema de medalhas
    • GRAVITY = 0.42
    • MAX_FALL = 9
    • PIPE_W = 68
    • PIPE_GAP = 180
    • PIPE_SPEED = 2.6
    • PIPE_SPACING = 220
  • A entrada suporta mouse, toque e teclado com Space, ArrowUp e Enter
  • Esse exemplo de jogo é apresentado no contexto de que também funcionou bem com quantização de 1 bit, inclusive com som funcionando normalmente

Contexto longo e KV cache quantization

  • Para aproveitar contexto longo no llama.cpp, é preciso reduzir o uso de memória com KV cache quantization
  • O llama.cpp adicionou recentemente técnicas para maior precisão na quantização do KV cache; o PR relacionado é https://github.com/ggml-org/llama.cpp/pull/21038
  • Os tipos de dado suportados para KV cache são os seguintes
    • f32
    • f16
    • bf16
    • q8_0
    • q4_0
    • q4_1
    • iq4_nl
    • q5_0
    • q5_1
  • O padrão é f16
  • Como q4_0 usa cerca de 4,5 bits por weight, ele permite multiplicar o comprimento de contexto por 16 / 4.5, ou seja, cerca de 3,5x
    • Por exemplo, um modelo que antes suportava 10K pode passar a entrar na faixa de 35K
  • O q4_1 adiciona um shifting parameter, o que pode torná-lo melhor, e com 5 bits por weight oferece cerca de 3,2x mais contexto
  • O exemplo de execução com KV cache quantization especifica o modelo GLM-5.2 GGUF e os parâmetros de sampling
    • Caminho do modelo: unsloth/GLM-5.2-GGUF/UD-IQ2_M/GLM-5.2-UD-IQ2_M-00001-of-00006.gguf
    • --temp 1.0
    • --top-p 0.95
    • --min-p 0.01
    • --cache-type-k q4_1
    • --cache-type-v q4_1

Números visíveis na tabela de benchmarks

  • A documentação segue com uma tabela de benchmarks do GLM-5.2, mas no conteúdo fornecido faltam os cabeçalhos de coluna, então não dá para confirmar a que modelo ou configuração cada número corresponde
  • Os benchmarks de reasoning incluem as seguintes linhas e valores
    • HLE: 40.5, 49.8*, 41.4*, 45, 31, 41.4, 37, 37.7
    • AIME 2026: 99.2, 95.7, 98.3, 98.2, 95.3, 97, -, 94.6
    • GPQA-Diamond: 91.2, 93.6, 93.6, 94.3, 86.2, 90, 93, 90.1
  • Os benchmarks de coding incluem as seguintes linhas e valores
    • SWE-bench Pro: 62.1, 69.2, 58.6, 54.2, 58.4, 60.6, 59, 55.4
    • NL2Repo: 48.9, 69.7, 50.7, 33.4, 42.7, 47.2, 42.1, 35.5
    • Terminal Bench 2.1 (Terminus-2): 81.0, 85, 84, 74, 63.5, 75, 65, 64
  • Os benchmarks agentic incluem as seguintes linhas e valores
    • MCP-Atlas (Public Set): 76.8, 77.8, 75.3, 69.2, 71.8, 76.4, 74.2, 73.6
    • Tool-Decathlon: 48.2, 59.9, 55.6, 48.8, 40.7, -, -, 52.8

1 comentários

 
GN⁺ 4 시간 전
Comentários do Hacker News
  • Estou rodando Q4_K_XL. Para chegar a cerca de 6 tk/s, basta ter 512 GB de RAM e 2 RTX 3090 com llama.cpp -cmoe
    No momento estou limitado por uma DDR4 ruim de 2400 MHz, mas com 3200 MHz provavelmente subiria para algo em torno de 9 tk/s. A CPU também é um EPYC de 32 núcleos, então já é decente, mas com um modelo melhor de 64 núcleos parece plausível chegar a 11 tk/s
    Montei tudo com foco em orçamento antes que o preço do hardware ficasse insano, e me arrependo todos os dias, mas mesmo assim é incrível poder rodar esse modelo em casa. É ótimo para planejamento ou para juntar todo o contexto necessário e mandar em um prompt de uma vez só
    O custo total do hardware foi de 2.400 dólares na época da montagem, e com alguma pesquisa dá para encontrar um jeito de rodar modelos assim em casa. Muita gente pergunta por que fazer isso, ou quanto se economizaria usando uma API em nuvem, mas acho que o caso da Fable mostrou o valor de operar de forma independente
    Obrigado ao time da unsloth, e o Q4_K_XL é sólido. Se você for baixar um modelo quantizado, vale pegar a variante K_XL se ela couber

    • Palmas para quem empurra os limites do possível com esse tipo de experimento caseiro. Assim como cripto, IA também está soterrada por barulho de vendedores, mas quase não se fala em resiliência
      Os pesquisadores que tentam enfiar modelos open source em escovas de dente elétricas ou em um Tamagotchi também são incríveis
    • Mantendo essa carga rodando o tempo todo, dá pelo menos 600 W, o que dá cerca de 14 kWh por dia. A 0,2 dólar por kWh, isso dá 2,80 dólares por dia, ou algo como 1.000 dólares por ano só de eletricidade
      A menos que privacidade ou a satisfação de possuir tudo diretamente sejam realmente essenciais, pagar um hyperscaler sai mais barato, é mais prático e entrega muito mais tokens por segundo
      Ainda assim, gosto da direção e estou curioso para ver que hardware de self-hosting teremos daqui a 2 anos
    • Tenho praticamente a mesma configuração. 2 RTX 3090, 512 GB de DDR4 um pouco mais rápida e um EPYC de 64 núcleos [0]
      Estou usando com bastante satisfação e quero muito testar esse modelo também
      Além de rodar modelos locais, uso essa máquina como minha principal plataforma de desenvolvimento remoto. Agora rodo todas as sessões do Claude Code lá dentro com tmux
      É ótimo não precisar mais ficar mexendo em um notebook sempre quente. Meus dedos agradecem. Também ajuda o fato de o Claude Code devorar bateria
      [0] https://medium.com/@rathko/i-built-an-epyc-64-core-512gb-ram...
    • Dizer que “é isso que precisa para rodar” pode até fazer sentido se foi comprado por 2.400 dólares, mas hoje o preço total está muito mais perto de 10 mil dólares
      Só a RAM custa quase 5.000 dólares, e cada GPU sai por algo em torno de 2.000 dólares, então pelos preços atuais é um hardware bem caro
    • Pelo que entendi, a implementação deste modelo no llama.cpp ainda não tem suporte para atenção esparsa DSA, então está bem incompleta
      Por isso, o modelo acaba rodando com outros mecanismos que não foram usados no treinamento, e houve resultados mostrando piora de qualidade e desempenho
      De qualquer forma, acho que o GLM 5.2 não é tão interessante quanto a linha DeepSeek V4 em vários aspectos. O DeepSeek V4 usa um mecanismo de atenção mais avançado, que pode economizar bastante memória de cache KV, especialmente em contexto longo
      Como resultado, ele permite lotes maiores até em plataformas de consumo. O GLM não tem isso e, em termos de arquitetura base de desempenho, parece em grande parte semelhante ao Kimi 2.6. Ambos são um pouco pesados demais para rodar com qualidade total em hardware comum de forma razoável
  • Quase deu. Minha máquina tem 192 GB de RAM + RTX 3090 de 24 GB e eu quase consegui rodar isso
    Dizem que para offloading de MoE são necessários 24 GB de VRAM e 256 GB de RAM
    https://unsloth.ai/docs/models/glm-5.2#usage-guide
    Em um tópico anterior, alguém disse que o hardware custaria 500 mil dólares
    https://news.ycombinator.com/item?id=48629970

    • 500 mil dólares é um enorme exagero. Isso até pode fazer sentido se a meta for alta concorrência em FP8 ou BF16
      Com NVFP4, dá para conseguir velocidade razoável, algo como 120 tok/s, com concorrência por algo entre 80 mil e 90 mil dólares nos preços atuais, talvez até menos
      Com esse valor, dá para comprar 6 RTX 6000 PRO Blackwell, uma CPU decente, placa-mãe e fonte. Isso dá 576 GB de VRAM
      Se 40 tok/s na decodificação e cerca de 1200 tok/s no prefill já estiver bom, dá para ficar abaixo de 50 mil dólares
    • Em 2 bits é difícil conseguir bons resultados. Para código, a faixa ideal é pelo menos Q8
    • Espero que este boom reacenda uma evolução do hardware de computação como a dos anos 90
      Tenho a sensação de que um dos motivos para o hardware ter ficado relativamente estagnado nos últimos 20 anos é que faltavam casos de uso que justificassem as empresas trocarem suas máquinas
      Nos últimos 15 anos, a maior parte do dinheiro e da energia foi para o mobile
      Inferência local barata pode acabar sendo a fonte de receita que fabricantes de servidores, desktops e notebooks precisam para voltar a acelerar
    • Tenho RAM, mas não tenho VRAM. Com uma 3090 com 24 GB de RAM, que velocidade ou tok/s eu poderia esperar?
      Estou um pouco tentado a comprar uma GPU com 24 GB de RAM
    • Perguntei ao Gemini por diversão, e ele respondeu que seriam 500 mil dólares para obter uma taxa de processamento decente sem quantização
  • Quando dizem que “cabe”, querem dizer que cabe em 256 GB de RAM, mas em um estado fortemente quantizado e ainda assim vai rodar muito devagar
    O número da manchete não é a velocidade de geração de tokens, e sim a velocidade de processamento do prompt
    Se der 10 tok/s e a API der 20~30 tok/s, superficialmente talvez não pareça tão ruim, mas em um Mac Studio ou em máquinas que não coloquem tudo na GPU, o processamento de prompt é de 20 a 50 vezes mais lento do que em uma configuração puramente com GPU
    No fim, é isso que torna o uso inviável na prática a menos que você gaste US$ 50 mil em GPU. E, mesmo assim, você ainda acaba usando um modelo fortemente quantizado

    • Equipamentos como o Spark da Nvidia têm 128 GB de RAM unificada
      Também existe uma versão de porta dupla para esse tipo de equipamento: https://www.nvidia.com/content/dam/en-zz/Solutions/networkin...
      Ou seja, são portas de 2 x 100 GB/s, e talvez até 2 x 200 GB/s. Quando eu tiver isso em mãos, talvez descubra mais
      Esse tipo de equipamento também pode ser colocado em cluster. Com 2 ou 3 máquinas, usando 2 sub-redes IP, isso parece bem direto. Com 4 ou mais, talvez seja preciso um switch, dependendo de quanto a latência de rede impactar
      A Apple parece ter esquecido da linha M com muita RAM. Não consigo achar na Apple Store configurações com mais de 96 GB de RAM unificada, e mesmo isso custa um rim
  • Estão avançando em várias frentes ao mesmo tempo: o novo desktop de IA com GB10 é relativamente barato e, com clustering, dá para montar 1 TB de VRAM
    Nvidia, AMD, Intel, Cerebras e outras estão empurrando hardware novo, e modelos open source como o GLM 5.2 estão ficando absurdamente bons
    Modelos flash como o DeepSeek V4 Flash também estão melhorando muito, e a quantização continua avançando
    Também está ficando viável ter um harness que use modelos diferentes, como modelos grandes para tarefas difíceis e modelos pequenos para tarefas mais simples
    Então, quem quer sair das APIs espera em breve poder hospedar em casa um cluster de desktops de IA com preço razoável e usar desempenho de nível Opus

    • Aqui, a palavra “relativamente” está fazendo bastante trabalho. Se um GB10 custa cerca de US$ 4 mil, então um cluster de 1 TB sai por US$ 36 mil
      É barato em comparação com um H200 equivalente, mas ainda está fora do alcance de homelabs sem financiamento vindo de RSUs da OpenAI ou da Anthropic
  • Parece que a lacuna está diminuindo até o ponto de já dar para rodar localmente modelos bons o bastante, inclusive para programação, e imagino que algumas empresas devam estar ficando um pouco nervosas. Estou errado?

    • Se não fosse a limitação atual de RAM/GPU, essas empresas estariam ainda mais nervosas do que já estão
      Mas, no momento, pouquíssimas pessoas conseguem bancar o hardware necessário para rodar esse tipo de modelo com eficiência. Não parece que isso vá mudar muito nos próximos anos
      Se a Z.ai lançar uma versão focada em código, como uma GLM-5.2 Flash especializada em programação, na faixa de 80B de parâmetros, os laboratórios de ponta dos EUA teriam mais motivos para se preocupar
      No geral, as empresas chinesas de IA estão mostrando como fazer a mesma coisa com menos recursos, às vezes com muito menos recursos, e se essa tendência continuar, isso vai preocupar os laboratórios de fronteira
      Dito isso, as empresas chinesas de IA também vão tentar proteger seu fosso ao não divulgar modelos muito menores, mas ainda poderosos, do que seus modelos principais atuais
      A Alibaba Qwen parece estar nessa posição agora. Ficou relativamente quieta ultimamente, e seu modelo mais recente, de 395B, é grande demais para a maioria das pessoas rodar em casa. Também não há sinais de que vá lançar um modelo menor desta vez
    • Eu diria que não. É fácil imaginar uma empresa decidindo hospedar e rodar esse tipo de modelo para uso interno de desenvolvimento
      Se a equipe de desenvolvimento tiver umas 10 pessoas, um investimento único de US$ 50 mil em um servidor de LLM pode ser uma opção bem atraente
      Você ganha tokens ilimitados, desempenho aceitável, opções de upgrade e possibilidade de integração ao produto
      Em geral, para empresas que querem colocar LLMs em seus produtos, a abordagem com LLM local parece ainda mais atraente. Mesmo modelos meio burrinhos são bons o suficiente para muitos dos usos que as pessoas integram em produtos
    • Para ser uma ameaça, nem precisa necessariamente rodar localmente. Muitas empresas estão olhando para a possibilidade de pagar terceiros para hospedar esses modelos, e os preços são de apenas uma fração dos cobrados pelos laboratórios de fronteira
    • As exigências de RAM ainda doem bastante
    • Rodar localmente não é algo econômico. É ótimo para privacidade e um hobby divertido
      Mas as opções são ou um build de CPU absurdamente lento com US$ 10 mil em RAM, ou US$ 90 mil em GPU, ou então um modelo fortemente quantizado cuja qualidade é difícil de comparar
      Dá para montar algo por diversão, mas isso por si só não muda a viabilidade econômica. Ainda assim, é interessante que seja possível
  • OpenAI e Anthropic provavelmente não gostaram do timing do lançamento do GLM 5.2
    Isso mostra bem que não havia um fosso mágico, e sim apenas uma vantagem de largada

  • Dá para usar um Mac Studio com 192 GB de RAM, mas isso ainda fica abaixo da RAM mínima declarada
    Especialmente por ser MoE, será que daria para fazer funcionar de algum jeito com swap em disco rápido?

    • Forçar tanto swap assim parece uma ótima maneira de consumir o TBW do SSD NVMe e reduzir bastante a vida útil dele
      E o desempenho também seria desastroso, na faixa de 0,1 tok/s
  • Tenho muito respeito pelo trabalho que a unsloth fez para ajudar milhões de pessoas a começar com IA local, mas esse post parece um pouco caça-cliques de download
    Fazer offload de camadas demais para a CPU simplesmente não funciona bem. Já tentei várias vezes e, no fim, tive que dar rm -rf em pastas pesadas de cache do Hugging Face
    Também duvido que rodar uma quantização de 1 bit ou 2 bits do GLM 5.2 majoritariamente fora da VRAM seja mais útil, na prática, do que um Qwen3.6-27B Q8_0 totalmente carregado na VRAM

  • Independentemente do que o post diga, acho que quem tentar rodar isso em uma máquina com 256 GB de RAM não vai ter uma experiência boa
    Um mínimo muito mais realista é 512 GB
    Felizmente, tenho no home office duas workstations dual Xeon com 512 GB de RAM, compradas barato antes da alta de preços, então talvez eu consiga experimentar um pouco