Como rodar o GLM-5.3-Flash local: pesos no Hugging Face, SGLang, vLLM e TokenSpeed

Quando os pesos de um modelo de fronteira aparecem no Hugging Face sob licença MIT, a pergunta deixa de ser "qual API eu chamo" e vira "eu consigo hospedar isso aqui dentro?"

Fala aí, beleza? A Z.ai lançou o GLM-5.3-Flash em 26 de agosto de 2026 e, no mesmo anúncio, revelou que o stealth model que circulava anonimamente como "Ox Alpha" era ele o tempo todo 🙂

Este post é pra quem avalia infraestrutura, não pra quem só quer plugar a API e seguir a vida. A ideia aqui é olhar o que está publicado, quais runtimes declaram suporte e quais perguntas você precisa responder ANTES de tentar subir um bicho desse porte

O que significa ter os pesos do GLM-5.3-Flash publicados sob MIT

Os pesos estão no repositório oficial zai-org/GLM-5.3-Flash, no Hugging Face, sob MIT License, com os arquivos disponíveis em /tree/main

MIT é licença permissiva, então o caminho de deployment próprio está aberto: você baixa, roda na sua infra, versiona o checkpoint que quiser

Agora, licença aberta não paga conta de GPU, beleza? Vale entender exatamente o que você estaria hospedando

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 116 aulas
• 4 projetos
• 9h 23min

Conhecer formação

A ficha técnica do que você vai subir:

• Arquitetura: MoE 320B-A18B, ou seja, 320 bilhões de parâmetros totais com 18 bilhões ativos por token
• Atenção: formato híbrido de atenção esparsa + linear, pensado pra reduzir o custo de contexto longo
• Nome da arquitetura no código: essa combinação é registrada com o identificador glm5_next, e é esse nome que o runtime de inferência precisa reconhecer pra conseguir carregar o checkpoint
• Contexto: 1.048.576 tokens
• Saída: até 131.072 completion tokens por resposta
• Multimodal nativo: entrada de texto, imagem e vídeo, saída em texto
• Pesos: FP8 nativos, com MTP (multi-token prediction) disponível a partir do checkpoint base

Segura esse detalhe do glm5_next, porque ele volta lá embaixo e é o motivo de um travamento bem chato no vLLM

E tem um ponto que chamou atenção no anúncio: a Z.ai afirma que o modelo rodou o treino inteiro em chips de IA chineses ("running entirely on Chinese AI chips")

Em posicionamento de qualidade, o GLM-5.3-Flash marca 57 pontos no Artificial Analysis Intelligence Index

Que hardware o GLM-5.3-Flash exige para rodar local

Aqui vem a parte que decide o post inteiro, então vou ser bem direto com o que é dado e com o que é estimativa

Uma estimativa de terceiros aponta que o checkpoint FP8 ocupa cerca de 306 GiB, com mínimo estimado de 4x H200 ou 8x H100 de 80 GB

Repare no "estimativa de terceiros": isso não é requisito oficial publicado pela Z.ai, é conta de blog externo. Trate como ordem de grandeza pra dimensionar, não como especificação de fabricante

O que dá pra afirmar com mais segurança é o hardware que aparece nas receitas dos runtimes:

• O SGLang publica receitas separadas para H100, H200, B200, B300, GB200 e GB300
• As imagens Docker do vLLM citam H100, B200 e GB200 como hardware verificado

E o que NÃO aparece em lugar nenhum dessas receitas: placa de consumo. O hardware documentado é datacenter, do começo ao fim

Se a sua referência de "rodar local" é aquele fluxo de baixar um modelo e chamar num comando, tipo quando a gente viu rodar o DeepSeek localmente, ajuste a régua: aqui o assunto é rack, não notebook

SGLang, vLLM e TokenSpeed: qual runtime está pronto hoje

O model card declara suporte de deployment em SGLang, vLLM e TokenSpeed, com mais frameworks previstos

Mas "declarar suporte" e "ter receita pronta hoje" são coisas diferentes, e essa diferença muda o seu plano de deploy

Um ponto que vale registrar: o TokenSpeed vive no repositório github.com/lightseekorg/tokenspeed, sob a organização LightSeek Foundation, e não sob a Z.ai

Ou seja, é uma terceira via de motor de inferência que aparece na lista de suporte, mas mora fora da casa de quem treinou o modelo. Isso não é defeito, só é uma informação que muda como você avalia risco de manutenção

Como subir o GLM-5.3-Flash com SGLang

Hoje o SGLang é o caminho com mais coisa escrita, então vamos por ele

1. Aponte para o repositório oficial dos pesos

O --model-path do comando usa direto zai-org/GLM-5.3-Flash, o mesmo repo do Hugging Face que citei lá em cima

O erro comum deste passo: apontar pra um mirror ou pra uma quantização de terceiro achando que é o checkpoint oficial. São artefatos diferentes, com builds diferentes

2. Abra a receita da SUA GPU no cookbook

O cookbook do SGLang traz receitas separadas para H100, H200, B200, B300, GB200 e GB300

O erro comum deste passo: copiar a receita de outra placa porque "é parecido". Não é, e valores de paralelismo dependem de quantas GPUs você realmente tem na máquina

3. Suba o serviço com o comando documentado

sglang serve \
  --model-path zai-org/GLM-5.3-Flash \
  --tp-size 4 \
  --ep-size 4 \
  --attention-backend dsa \
  --linear-attn-backend triton \
  --quantization fp8 \
  --moe-runner-backend deep_gemm \
  --speculative-algorithm NEXTN \
  --host 0.0.0.0 \
  --port 30000

O erro comum deste passo: colar o comando com --tp-size 4 --ep-size 4 numa máquina que não tem esse número de placas. Esses valores descrevem a topologia da receita, não são constante universal

4. Entenda o que cada flag está fazendo (pelo menos as óbvias)

Algumas flags se explicam sozinhas quando você olha a ficha do modelo:

• --quantization fp8 conversa com os pesos FP8 nativos do checkpoint
• --speculative-algorithm NEXTN liga o MTP, que vem disponível a partir do checkpoint base
• --attention-backend dsa e --linear-attn-backend triton atendem os dois lados da atenção híbrida, esparsa e linear
• --tp-size e --ep-size são os controles de paralelismo, e é por eles que a receita muda de GPU pra GPU

O erro comum deste passo: mexer em flag por tentativa e erro sem entender o que ela endereça. Aí quando quebra, você não sabe se foi topologia, backend ou quantização

5. Para o resto, vá na doc oficial em vez de chutar

A receita completa tem mais flags do que esse recorte, e cada variação de GPU traz os seus próprios ajustes

O erro comum deste passo: seguir tutorial de terceiro (inclusive este) como se fosse a receita completa. A página do cookbook é a fonte que você abre na hora de subir

Os dois travamentos mais previsíveis (e como contornar)

Caso 1: o vLLM não reconhece a arquitetura glm5_next

Sintoma: você instala o vLLM, aponta pro checkpoint e ele simplesmente não sabe o que fazer com o identificador de arquitetura glm5_next que vem na config do modelo

Causa: o suporte a esse identificador está in-flight na PR vllm-project/vllm#53906 e não veio no release v0.28.0

Solução: usar as imagens Docker específicas por modelo, com as tags vllm/vllm-openai:glm53-flash*, publicadas em 26/08/2026, que é justamente o caminho que a receita do vLLM indica enquanto a PR não é integrada

Prevenção: antes de desenhar o deploy, confira qual versão do vLLM está instalada aí e se ela já traz a PR integrada. Planejar em cima de "deve estar na main já" é como você perde uma tarde inteira 😀

Caso 2: o checkpoint não cabe nas suas GPUs

Sintoma: o download termina e nada sobe, ou sobe e morre na alocação de memória

Causa: são cerca de 306 GiB em FP8, contra o piso estimado de 4x H200 ou 8x H100 de 80 GB

Solução: ou você entra com mais placas dentro desse piso estimado, ou olha as quantizações publicadas por terceiros no Hugging Face, como unsloth/GLM-5.3-Flash-FP8 e LibertAIDAI/GLM-5.3-Flash-NVFP4, essa última voltada aos tensor cores FP4 das GPUs NVIDIA Blackwell

Aviso honesto: são builds de terceiros, não o checkpoint oficial da Z.ai, e paridade de qualidade não é coisa que se assume. Se você for por aí, valide no seu caso de uso

Prevenção: dimensione a VRAM ANTES de puxar 306 GiB pela rede. Tome cuidado, porque esse é o tipo de download que você não quer refazer

Quando self-host se paga (e quando a API resolve melhor)

Antes de comprar briga com hardware, responde três perguntas pra você mesmo:

1. Você precisa que os dados NÃO saiam da sua infra?
2. Você precisa travar a versão do modelo, sem depender de mudança do provedor?
3. Ou você só quer token barato?

Se a resposta for a terceira, a conta raramente fecha. Na API, o GLM-5.3-Flash custa US$ 0,075 por milhão de tokens de entrada, US$ 0,25 por milhão de saída e US$ 0,015 por milhão em cache read

Coloca isso do lado do custo de operar 4x H200 ou 8x H100 e o desenho fica bem claro pra quem não tem exigência de dado local

Tem ainda o caminho de assinatura: o modelo foi liberado para todos os usuários do GLM Coding Plan, com o triplo da cota do GLM-5.3

Essa discussão de infra própria contra fatura de API é a mesma de sempre, só que em outra escala, e já rolou por aqui no papo sobre IA local com Ollama contra API

E pra máquina pessoal existe um meio termo: o LM Studio adicionou suporte ao GLM-5.3-Flash na versão Bionic desde 26 de agosto de 2026, com entrada de imagem e contexto de 1M tokens

Vídeo: rodando modelo local com um comando

Pra começar do zero na ideia de deployment próprio, esse vídeo do canal mostra como rodar o Codex 100% local com Ollama, em um comando

Conclusão

Resumo sem maquiagem: os pesos do GLM-5.3-Flash estão abertos no Hugging Face sob MIT, o SGLang é o caminho com receita pronta e variação por GPU, o vLLM depende de imagem Docker específica enquanto a PR #53906 não entra, e o TokenSpeed é a terceira via, hospedada sob a organização LightSeek Foundation, por fora da Z.ai

Próximo passo concreto, na ordem:

1. Meça a VRAM que você tem hoje contra os ~306 GiB estimados do checkpoint FP8
2. Abra a receita da sua GPU no cookbook do SGLang e confira os valores de paralelismo
3. Se o número não fechar, comece pela API ou pelo GLM Coding Plan antes de queimar orçamento em hardware

Modelo aberto é liberdade, não é desconto automático, e essa diferença é o que separa um deploy planejado de um prejuízo caro

até o próximo post! 😀