Pode executar um modelo GLM localmente porque os pesos estão genuinamente publicados, e não fechados atrás de um formulário de pedido ou de um endpoint alojado. Esta página cobre as quatro coisas que decidem se uma implementação local funciona: a licença sob a qual está a operar, onde vivem os pesos, que frameworks de serviço são suportadas e como dimensionar o hardware para o comprimento de contexto de que realmente precisa, e não apenas para a contagem de parâmetros. Nenhuma delas é difícil isoladamente; acertar nas quatro ao mesmo tempo é o que separa uma implementação funcional de um fim de semana a depurar.
A razão para o fazer é simples. Um modelo GLM open source a correr no seu próprio hardware mantém todos os prompts dentro da sua rede, não pode ser descontinuado debaixo dos seus pés e pode ser ajustado por fine-tuning com dados que nunca enviaria a terceiros. São essas propriedades que levam as equipas a escolher pesos abertos mesmo quando um modelo alojado pontua alguns pontos acima.
Os pesos principais dos modelos GLM são disponibilizados sob licença MIT, sem restrições regionais. A MIT é praticamente tão permissiva quanto o licenciamento de software consegue ser: usar, modificar, distribuir e implementar comercialmente, com atribuição e sem garantia. Não existe qualquer cláusula separada de uso aceitável a estreitar o que a licença de outro modo concede, nem cláusula geográfica a decidir onde a pode servir.
Isso importa mais nos modelos do que no software comum, porque muitos lançamentos nominalmente abertos trazem cláusulas que tornam a implementação em produção juridicamente ambígua. Confirme o ficheiro de licença que acompanha o checkpoint específico que descarregar — é o texto autoritativo, e leva cerca de trinta segundos a ler.
Os pesos estão publicados no HuggingFace e no ModelScope. Ambos alojam os checkpoints completos, e não adaptadores ou lançamentos parciais, pelo que os pode obter com as ferramentas padrão de qualquer das plataformas. Espelhar o checkpoint no seu próprio repositório de artefactos antes do lançamento é boa prática pela mesma razão que o é com imagens de contentor: a sua implementação não deve depender de um alojamento externo estar acessível no momento em que precisa de escalar.
Os autores do modelo indicam suporte para cinco stacks de inferência que, entre si, cobrem essencialmente todos os formatos de implementação local, de uma única estação de trabalho a um cluster multi-nó.
A implementação de referência. É a mais lenta para serviço em produção, mas a forma mais fácil de confirmar que um checkpoint carrega e gera corretamente antes de investir numa stack mais rápida. Comece por aqui quando estiver a depurar.
A opção habitual em produção. A atenção paginada e o batching contínuo tornam-no forte sob carga concorrente, e é geralmente o caminho mais rápido de um checkpoint descarregado até um endpoint compatível com a OpenAI no seu próprio hardware.
Otimizado para geração estruturada e reutilização intensiva de prefixos. Vale a pena escolhê-lo quando muitos pedidos partilham um longo prompt de sistema ou um prefixo de documento comum, que é exatamente a forma da maioria das cargas de trabalho com agentes.
Um caminho de serviço adicional suportado e listado pelos autores do modelo, útil quando as suas características de implementação se adequam melhor à sua infraestrutura do que as alternativas.
Vocacionado para inferência heterogénea em CPU e GPU, que é o que o torna interessante para hardware limitado: consegue descarregar partes do modelo para a memória do sistema e manter utilizável um modelo grande numa máquina que de outro modo não o suportaria.
O erro mais comum em implementações locais é orçamentar memória para os pesos e esquecer a KV-cache. A contagem de parâmetros define um mínimo, mas a cache escala com o comprimento do contexto e com a concorrência, e em contexto longo é ela que domina. É o mesmo muro contra o qual os autores do modelo embateram ao servir o modelo emblemático: passadas algumas centenas de milhares de tokens, o estrangulamento deixa de ser a computação e passa a ser a capacidade da cache, a eficiência dos kernels e o overhead do CPU.
A consequência prática é que deve dimensionar para a sua distribuição real de contexto, e não para o máximo que o modelo suporta. Correr o GLM-5.2 com uma janela de 128K é uma proposta de hardware muito diferente de o correr com o milhão completo, e a maioria das cargas de trabalho nunca se aproxima do teto. Se o hardware está apertado, os níveis leves GLM-4.7-Flash e GLM-4.5-Air, ou o GLM-5.1 com contexto de 200K, cabem onde o modelo emblemático não cabe.
Adeque o modelo à máquina. Num único acelerador de estação de trabalho, o GLM-4.7-Flash de 30B ou o GLM-4.5-Air são as opções realistas e são perfeitamente capazes para classificação, extração, sumarização e edições de código de rotina. Num nó multi-GPU sério, o GLM-5.1 dá-lhe uma janela de 200.000 tokens a um custo de cache muito menor do que o do modelo emblemático. Num cluster, o GLM-5.2 dá-lhe o contexto completo de 1M, níveis de esforço explícitos e a coluna de benchmarks publicada mais forte da família. Para voz para texto em vez de geração, o GLM-ASR trata da etapa de transcrição sob a mesma licença.
Todos os valores desta página são resultados tal como publicados pelos autores do modelo. O glmmodel.com apenas os reporta; não executa estas avaliações.
Leia os benchmarks do modelo GLM e depois ponha um modelo real a trabalhar. O playground acima é gratuito e não exige nada de si; se quiser um conjunto de ferramentas de IA mais completo, o plano gratuito do nosso parceiro começa aqui.