Como executar o GLM-5.3-Flash localmente

Resumo

Você pode executar o GLM-5.3-Flash localmente porque a Z.ai lançou os pesos do modelo sob a licença MIT. A ressalva é a memória: o modelo tem cerca de 320B de parâmetros totais, embora apenas 18B fiquem ativos por token. Pesos nativos em FP8 ocupam aproximadamente 306 GiB antes da sobrecarga de runtime e KV-cache, enquanto quantizações GGUF comuns variam de cerca de 93 GB em 1 bit a 200 GB em Q4 e 341 GB em Q8.

Para serviço em GPU em produção, vLLM ou SGLang é o caminho mais direto. Para uma estação de trabalho com muita RAM e uma ou várias GPUs de consumidor, KTransformers é projetado para inferência heterogênea CPU-GPU. Para o experimento local mais fácil, use um build GGUF com llama.cpp ou Ollama. Uma GPU comum de 24 GB ou 32 GB não comporta o modelo completo sozinha; o uso local em GPU única depende da RAM do sistema, offloading e/ou quantização.

O que é GLM-5.3-Flash?

Para uma visão completa do modelo e interpretação de benchmarks, veja o What Is GLM-5.3-Flash? da CometAPI. Este guia de implantação mantém apenas os dados de dimensionamento necessários aqui: o GLM-5.3-Flash é um MoE multimodal 320B / 18B treinado em um corpus de 30T tokens.

O repositório oficial lista uma janela de contexto de 1.048.576 tokens, pesos com licença MIT e caminhos suportados para serviço local. A tabela abaixo é a referência de implantação; o restante deste artigo foca em instalação, memória, verificação e solução de problemas.

Por que o GLM-5.3-Flash é mais eficiente do que seu tamanho sugere

Um modelo de 320B soa como um modelo denso convencional de 320B, mas não é assim que o GLM-5.3-Flash gasta computação. O roteador MoE ativa apenas uma fração da capacidade de especialistas para cada token, enquanto o redesenho da atenção reduz o custo de reter e recuperar estado de longo contexto.

A Z.ai relata reduções em computação de atenção e uso de KV-cache em comparação com o GLM-5.3. Isso importa porque o KV-cache cresce com o comprimento do contexto e a concorrência; um modelo que carrega com sucesso em 8K de contexto ainda pode ficar sem memória quando você exige que ele atenda conversas muito mais longas.

Fonte: Anúncio oficial da Z.ai

Quão bom é o GLM-5.3-Flash?

A tabela abaixo mantém os resultados de primeira mão mais relevantes para implantação. A Z.ai relata resultados de benchmark mais altos para o GLM-5.3-Flash versus o GLM-5.2; veja a visão geral do modelo da CometAPI para uma interpretação mais completa. Aqui, a conclusão prática é se os ganhos justificam o hardware local e o custo operacional.

O padrão é especialmente relevante para autohospedagem: os casos de uso mais fortes do modelo não são bate-papos casuais, mas agentes de código, automação orientada a ferramentas, trabalho com documentos de longo contexto e fluxos multimodais em que residência de dados ou controle de infraestrutura podem justificar o esforço de implantação.

Quanta RAM ou VRAM o GLM-5.3-Flash precisa?

O planejamento de memória é a parte mais importante deste guia. A receita oficial do vLLM afirma que o checkpoint nativo em FP8 possui cerca de 306 GiB de pesos FP8. O KTransformers, portanto, recomenda reservar pelo menos 350 GB de memória do sistema disponível para seu caminho nativo FP8 CPU-GPU.

Se você usar GGUF, a Unsloth publica quantizações de 1 bit a BF16. O tamanho do arquivo não é o mesmo que a memória total em runtime: você ainda precisa de folga para o runtime, metadados do modelo, buffers de computação, componentes multimodais e KV-cache.

A terceira coluna é orientação de planejamento de implantação, não uma especificação oficial de hardware mínimo. O ajuste real depende do comprimento de contexto, tamanho de lote, runtime, offload para GPU e implementação da quantização.

Qual runtime local você deve usar?

Escolha vLLM quando throughput e compatibilidade com o ecossistema importarem mais. Escolha SGLang quando quiser avaliar serviço agentic, de saída estruturada ou multimodal. Escolha KTransformers quando o modelo não couber na memória da GPU, mas você tiver centenas de gigabytes de RAM do sistema. Escolha llama.cpp ou Ollama quando a facilidade de experimentação local importar mais do que corresponder ao checkpoint nativo.

Como executar o GLM-5.3-Flash com pesos nativos

Executar com vLLM

O vLLM é a opção mais voltada a produção se você tiver aceleradores de classe servidor. A receita oficial atual suporta múltiplas estratégias de paralelização e documenta serviço nativo em FP8. Trate as configurações publicadas como setups de referência, não como promessa de que toda combinação de GPUs funcionará com as mesmas flags.

Etapa 1: Prepare o ambiente

Use Linux com uma pilha NVIDIA compatível, memória de GPU agregada suficiente para o checkpoint mais overhead de runtime e um build recente do vLLM ou o contêiner recomendado pela receita atual. Comece com uma janela de contexto menor ao validar a implantação em vez de alocar imediatamente a janela completa de um milhão de tokens.

Etapa 2: Inicie o servidor

pip install vllm

vllm serve "zai-org/GLM-5.3-Flash" \
  --tensor-parallel-size 8 \
  --served-model-name zai-org/GLM-5.3-Flash

Para implantações avançadas, a receita oficial do vLLM documenta KV cache em FP8 em sistemas Blackwell compatíveis, decodificação especulativa MTP, parsing de chamadas de ferramentas, parsing de raciocínio e desagregação de prefill/decodificação. Verifique a receita atual do vLLM antes de copiar flags para produção porque o suporte pode mudar rapidamente.

Etapa 3: Teste o endpoint compatível com OpenAI

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "zai-org/GLM-5.3-Flash",
    "messages": [
      {"role": "user", "content": "Reply with OK"}
    ]
  }'

Executar com SGLang

O SGLang é outra rota de serviço de primeira classe listada no card oficial do modelo. Vale especialmente testar para agentes de alta concorrência, geração estruturada, requisições multimodais e aplicações pesadas em ferramentas.

Etapa 1: Instale o SGLang

pip install sglang

Etapa 2: Inicie o servidor do modelo

python3 -m sglang.launch_server \
  --model-path "zai-org/GLM-5.3-Flash" \
  --host 0.0.0.0 \
  --port 30000

Etapa 3: Verifique o endpoint

curl -X POST "http://localhost:30000/v1/chat/completions" \
  -H "Content-Type: application/json" \
  --data '{
    "model": "zai-org/GLM-5.3-Flash",
    "messages": [{"role": "user", "content": "Give me three local deployment checks."}]
  }'

O card do modelo no Hugging Face também fornece exemplos de requisições multimodais para SGLang. Se você precisar de tool calling, use as flags de parser recomendadas pela receita atual do SGLang em vez de supor que flags de um lançamento mais antigo do GLM permaneçam inalteradas.

Executar com KTransformers

O KTransformers é a opção mais importante para quem interpreta “local” como uma estação de trabalho e não como um servidor com oito GPUs. Sua implementação do GLM-5.3-Flash lê diretamente os pesos oficiais em FP8 e realiza inferência heterogênea de especialistas entre CPU e GPU.

O tutorial atual diz que o modelo em FP8 ocupa aproximadamente 306 GiB e recomenda 350 GB de memória do sistema. Ele suporta GPUs NVIDIA SM89 e SM120, incluindo hardware das séries RTX 40 e 50, além de kernels de especialistas em FP8 para CPU com AVX-512. O tutorial inclui configurações de inicialização com quatro GPUs e GPU única.

Uma única RTX 4090 ou RTX 5090 pode participar da inferência, mas isso não transforma o GLM-5.3-Flash em um modelo de 24–32 GB. A maior parte do modelo ainda fica fora da VRAM, então a capacidade e a largura de banda da memória do sistema tornam-se centrais para o desempenho.

Etapa 1: Crie um ambiente Python limpo

conda create -n glm53flash python=3.11 -y
conda activate glm53flash

Etapa 2: Instale o KTransformers

pip install "ktransformers[sglang]"

Etapa 3: Baixe os pesos oficiais

Baixe o zai-org/GLM-5.3-Flash do Hugging Face para o armazenamento local. Garanta espaço em disco suficiente para o checkpoint e RAM suficiente para a configuração ativa do servidor.

Etapa 4: Inicie o servidor com GPU única

MODEL_PATH=/path/to/GLM-5.3-Flash

CUDA_VISIBLE_DEVICES=0 python -m sglang.launch_server \
  --model-path "$MODEL_PATH" \
  --kt-weight-path "$MODEL_PATH" \
  --served-model-name GLM-5.3-flash \
  --host 0.0.0.0 \
  --tp-size 1 \
  --context-length 501025 \
  --mem-fraction-static 0.65 \
  --chunked-prefill-size 2048 \
  --kt-method FP8 \
  --kt-cpuinfer 64 \
  --kt-threadpool-count 2 \
  --kt-num-gpu-experts 0 \
  --kt-gpu-prefill-token-threshold 2048 \
  --cuda-graph-bs 1 2 4 \
  --limit-mm-data-per-request '{"image":8,"video":1}' \
  --mm-process-config '{"image":{"max_pixels":1254400}}' \
  --tool-call-parser glm47 \
  --reasoning-parser glm45

O tutorial usa uma configuração validada de 501.025 tokens, embora o modelo suporte até 1M de contexto. Isso é um lembrete útil: configure o contexto de que você realmente precisa, não o máximo de marketing, porque a folga de contexto tem custo direto de memória.

Etapa 5: Verifique o servidor

curl http://localhost:30000/v1/models

O endpoint de chat compatível com OpenAI é texto simples: http://localhost:30000/v1/chat/completions.

Como executar um modelo GGUF GLM-5.3-Flash quantizado

Executar GLM-5.3-Flash com llama.cpp

Se você não quiser executar o checkpoint nativo em FP8, o GGUF torna o alvo de memória mais flexível. A Unsloth publica múltiplas quantizações GGUF do GLM-5.3-Flash e fornece comandos diretos para llama.cpp. O build Q4_K_XL tem cerca de 200 GB, então mesmo essa rota “amigável ao consumidor” ainda pressupõe um sistema com muita memória.

Instale no macOS ou Linux

curl -LsSf https://llama.app/install.sh | sh

Instale no Windows

winget install llama.cpp

Inicie um servidor local com Q4_K_XL

llama serve -hf unsloth/GLM-5.3-Flash-GGUF:UD-Q4_K_XL

Execute diretamente no terminal

llama cli -hf unsloth/GLM-5.3-Flash-GGUF:UD-Q4_K_XL

Se sua máquina não comportar Q4_K_XL, existem arquivos menores de 3, 2 e 1 bit. Não escolha a menor largura de bits apenas porque cabe: quantização agressiva pode alterar a confiabilidade do raciocínio, a formatação de chamadas de ferramentas, a qualidade de código e o comportamento multimodal. Valide o build exato no seu próprio conjunto de testes.

Executar GLM-5.3-Flash com Ollama

O Ollama é o caminho de linha de comando mais curto se você já o usa para modelos locais. A Unsloth documenta o carregamento direto do Hugging Face para seus builds GGUF do GLM-5.3-Flash.

ollama run hf.co/unsloth/GLM-5.3-Flash-GGUF:UD-Q4_K_XL

A conveniência do Ollama não muda o tamanho subjacente do modelo. Q4_K_XL ainda tem cerca de 200 GB, e versões de menor bit trocam memória por qualidade. Se você tem apenas 32–64 GB de RAM do sistema, o GLM-5.3-Flash não é um alvo local sensato; use um modelo menor ou uma API hospedada.

Escolha uma quantização GGUF

Escolha a quantização de maior qualidade que caiba com folga suficiente para runtime e KV-cache. Comece com Q4_K_XL quando você tiver cerca de 256 GB ou mais de memória do sistema; considere builds de menor bit apenas quando os limites de hardware exigirem e valide raciocínio, geração de código, chamadas de ferramentas e comportamento multimodal contra uma referência nativa ou hospedada antes da implantação.

Como verificar sua implantação local

Um log de inicialização bem-sucedido não é suficiente. Teste os comportamentos de que sua aplicação realmente dependerá. Uma sequência de aceitação útil é: geração básica de texto, seu comprimento real de contexto, chamadas de ferramentas com seus esquemas, entrada multimodal se necessário e throughput sob concorrência realista.

Smoke test básico

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "zai-org/GLM-5.3-Flash",
    "messages": [
      {"role": "user", "content": "Return exactly: LOCAL_OK"}
    ],
    "reasoning_effort": "low"
  }'

O card do modelo define níveis de reasoning_effort e o padrão é max. Para reprodução de benchmarks, mantenha max; para uma estação de trabalho lenta, low ou high podem tornar o teste iterativo muito mais prático.

Depois, adicione verificações específicas da carga de trabalho:

• Contexto longo: envie um documento ou prompt do tamanho de um repositório próximo ao seu comprimento pretendido em produção, não ao máximo de 1M por padrão.
• Chamadas de ferramentas: verifique JSON de argumentos, seleção de ferramenta, recuperação após erros de ferramenta e chamadas repetidas.
• Multimodal: teste os formatos de imagem ou vídeo e as faixas de resolução que você usará na prática.
• Concorrência: meça latência e memória enquanto várias solicitações estiverem ativas.
• Quantização: compare o mesmo conjunto de prompts com uma referência nativa ou hospedada antes de aprovar um build GGUF de baixo bit.

Como reduzir o uso de memória do GLM-5.3-Flash

Use uma janela de contexto menor

O modelo suporta até 1M de tokens, mas a maioria dos fluxos locais não precisa de tanto contexto em cada requisição. Reduza o máximo configurado até que corresponda à sua aplicação. Isso reduz a pressão do KV-cache e pode transformar uma implantação instável em utilizável.

Quantize os pesos

Mover de BF16 para Q8, Q6, Q4 ou GGUF de menor bit pode cortar dramaticamente a memória de pesos. O trade-off é a qualidade de saída e, às vezes, a compatibilidade de runtime, então trate o nível de quantização como uma escolha de modelo, não apenas de armazenamento.

Use offload para CPU

KTransformers e llama.cpp podem mover grande parte do estado do modelo para a RAM do sistema. Este é o principal motivo pelo qual a inferência do GLM-5.3-Flash em GPU única é plausível, mas também desloca o gargalo de desempenho para a capacidade da CPU e a largura de banda da memória.

Reduza a concorrência

Cada requisição simultânea de longo contexto consome cache adicional e buffers de runtime. Uma implantação em estação de trabalho frequentemente desempenha melhor com um alvo de concorrência pequeno e uma fila explícita do que com paralelismo estilo servidor.

Como melhorar a latência interativa

Para uso local interativo, reduzir o reasoning_effort pode diminuir o comprimento do raciocínio gerado, a latência de resposta e o consumo de tokens. Isso não reduz a memória necessária para carregar os pesos do modelo; pode apenas reduzir indiretamente o uso de cache no tempo de requisição ao encurtar a sequência gerada. Use low para iteração rápida e mude para high ou max quando uma tarefa exigir raciocínio mais profundo ou comportamento comparável a benchmarks.

Você deve executar o GLM-5.3-Flash localmente ou usar uma API?

Autohospedagem é atraente quando privacidade, residência de dados, operação offline, configurações de inferência personalizadas ou hardware ocioso próprio importam. É menos atraente quando você precisa de acesso ocasional ao modelo sem manter centenas de gigabytes de memória e uma pilha de serviço complexa.

Se a implantação local não for um requisito, você pode acessar o GLM-5.3-Flash via fluxo de chat-completions compatível com OpenAI usando o ID de modelo glm-5.3-flash. Isso é útil como endpoint de referência para comparar seu build quantizado local com uma implementação hospedada ou como fallback de produção enquanto você testa a autohospedagem.

from openai import OpenAI
import os

client = OpenAI(
    base_url="https://api.cometapi.com/v1",
    api_key=os.environ["COMETAPI_KEY"],
)

response = client.chat.completions.create(
    model="glm-5.3-flash",
    messages=[{"role": "user", "content": "Reply with OK"}],
)

print(response.choices[0].message.content)

Problemas comuns ao executar o GLM-5.3-Flash localmente

O modelo carrega e depois falha com um prompt longo

Geralmente significa que você dimensionou para os pesos, mas não para o KV-cache. Reduza o comprimento do contexto e a concorrência, depois aumente gradualmente monitorando a memória da GPU e do sistema.

Um arquivo Q4 cabe no disco, mas não na RAM

O tamanho do arquivo GGUF não é a pegada completa em runtime. Deixe uma folga significativa para buffers do runtime, cache e o sistema operacional.

KTransformers com GPU única está extremamente lento

Isso pode ser esperado quando a maioria do trabalho dos especialistas é atendido da memória da CPU. Verifique o posicionamento NUMA, a largura de banda da memória, o suporte de instruções da CPU, o comportamento de armazenamento durante o carregamento e se sua carga ficaria melhor com um modelo menor quantizado.

Chamadas de ferramentas retornam JSON malformado

Confirme que seu runtime usa o parser recomendado para a integração atual do GLM-5.3-Flash. Flags de parser podem mudar entre versões de framework, então não reutilize cegamente um comando de inicialização escrito para um modelo GLM mais antigo.

Ollama ou llama.cpp começam a baixar centenas de gigabytes

Isso é normal para esta família de modelos. Verifique a tag de quantização antes de iniciar o download, confirme o espaço livre em disco e confira o tamanho correspondente no repositório GGUF primeiro.

FAQ

Posso executar o GLM-5.3-Flash em uma RTX 4090?

Sim, uma RTX 4090 pode participar da inferência heterogênea CPU-GPU do KTransformers, mas os 24 GB de VRAM estão muito aquém de comportar o checkpoint completo. O caminho oficial em FP8 do KTransformers ainda exige cerca de 350 GB de memória do sistema disponível.

Posso executar o GLM-5.3-Flash em uma RTX 5090?

Sim, GPUs da série RTX 50 estão explicitamente incluídas na lista de suporte atual do KTransformers. Como na 4090, a principal restrição é o restante do sistema: capacidade de RAM, largura de banda de memória, suporte da CPU e a quantidade de contexto que você aloca.

Posso executar o GLM-5.3-Flash com 128 GB de RAM?

Apenas as quantizações GGUF mais agressivas se aproximam dessa faixa: Q2_K_XL tem cerca de 109 GB e IQ2_XXS cerca de 102 GB. Uma vez incluídos overhead de runtime e KV-cache, 128 GB é um alvo muito apertado. Não é a configuração a escolher se você quer qualidade previsível ou longo contexto.

O GLM-5.3-Flash pode rodar no Ollama?

Sim. A Unsloth documenta o carregamento direto no Ollama para seus builds GGUF, incluindo UD-Q4_K_XL.

Quanta VRAM o GLM-5.3-Flash precisa?

Não há um número único correto de VRAM. A implantação nativa de servidor distribui o checkpoint entre aceleradores; o KTransformers combina VRAM de GPU com centenas de gigabytes de RAM do sistema; o llama.cpp pode fazer offload de um GGUF quantizado entre CPU e GPU. Planeje conforme o runtime e a quantização que pretende usar.

O GLM-5.3-Flash é open source?

A formulação mais segura é pesos abertos sob a licença MIT. O repositório oficial no Hugging Face lista explicitamente a licença MIT e fornece checkpoints para download.

O GLM-5.3-Flash local é mais barato do que a API?

Não automaticamente. Hospedagem local pode fazer sentido quando você já possui hardware adequado, mantém alta utilização de forma consistente ou precisa manter dados dentro da sua infraestrutura. Para workloads intermitentes, o acesso hospedado geralmente evita um grande custo fixo de hardware e operações.

Conclusão

O GLM-5.3-Flash é incomumente eficiente para um modelo com aproximadamente 320B de parâmetros totais, mas “Flash” não deve ser confundido com “pequeno”. Seu design MoE com 18B de parâmetros ativos reduz a computação, enquanto a atenção híbrida linear e esparsa torna o longo contexto substancialmente mais barato, mas os pesos ainda exigem centenas de gigabytes a menos que você use quantização agressiva.

A decisão prática de implantação é, portanto, direta: use vLLM ou SGLang para infraestrutura de GPU de classe servidor; use KTransformers quando você tiver uma estação de trabalho com muita memória do sistema e quiser inferência nativa FP8 CPU-GPU; use llama.cpp ou Ollama quando quantização GGUF e facilidade de experimentação forem mais importantes. Se nenhum desses perfis de hardware corresponder à sua máquina, use um endpoint hospedado do GLM-5.3-Flash em vez de forçar um modelo de 320B em um setup local inadequado.