O que é GLM-OCR?
O GLM-OCR é o modelo aberto de OCR da Zhipu AI, lançado no início de 2026 sob a licença MIT, com um relatório técnico em 11 de março de 2026. A Zhipu o descreve como tendo 0,9 bilhão de parâmetros, um encoder de visão CogViT de 0,4B e um decoder GLM de 0,5B; o checkpoint contado pelo Hugging Face tem 1,33 bilhão. Ele lê texto, fórmulas e tabelas e preenche um esquema JSON fornecido por você para extração de informações-chave, em oito idiomas, entre eles chinês, inglês, francês, alemão e japonês.
O parsing de páginas inteiras roda como um pipeline. O SDK oficial encontra as regiões com o PP-DocLayoutV3 da Baidu e depois as reconhece em paralelo. O treinamento acrescenta predição de múltiplos tokens: o modelo aprende a propor dez tokens por passo e aceita 5,2 em média na inferência, o que segundo a Zhipu aumenta o throughput em cerca de 50%.
A Zhipu também o vende como API, a US$ 0,03 por milhão de tokens de entrada ou saída no Z.ai, e os pesos tiveram cerca de 1,74 milhão de downloads no último mês no Hugging Face.
GLM-OCR vale a pena?
O GLM-OCR é o modelo de OCR pequeno padrão para equipes que querem tanto pesos abertos quanto uma alternativa hospedada. Suas pontuações foram verificadas fora da Zhipu: o ranking OmniDocBench v1.6 da OpenDataLab o lista com 95,22, atrás do OvisOCR2, com 96,47, do PaddleOCR-VL-1.6, com 96,34, e do MinerU2.5-Pro, com 95,75, e à frente do Qianfan-OCR, com 93,90. O destaque do próprio card, 94,62 e primeiro lugar, é na versão mais antiga v1.5, então não deve ser comparado com números da v1.6.
A velocidade é o argumento mais forte. A Zhipu informa 1,86 página de PDF por segundo e 0,67 imagem por segundo com concorrência única, contra 1,22 e 0,39 do PaddleOCR-VL-1.5, embora não diga qual é a GPU. O teste separado da OpenBMB em uma RTX 5090 o colocou em 1,179 página por segundo, logo atrás das 1,217 do MiniCPM-OCR 1.0 e à frente das 0,818 do PaddleOCR-VL-1.6. São números de dois fornecedores, não neutros, mas apontam na mesma direção.
O pipeline traz os custos de sempre. O relatório da Zhipu avisa que caixas de layout erradas estragam o reconhecimento que vem depois, que a ordem de leitura pode se quebrar em páginas irregulares com várias colunas e entre quebras de página, e que quebras de linha e espaços variam de uma execução para outra. O SDK cobre só o parsing; a extração de campos roda contra o modelo puro e funciona só tão bem quanto o esquema que você escrever. O relatório do OvisOCR2, da Alibaba, acrescenta evidência externa do problema de layout: no seu teste de tabelas complexas, o GLM-OCR deixou passar 17,26% das tabelas, contra 7,96% do OvisOCR2.
O preço hospedado é o que o separa da maioria dos rivais abertos. O artigo da Zhipu diz que 1 RMB na tarifa chinesa cobre cerca de 2.000 digitalizações A4 ou 200 PDFs de dez páginas, e a API internacional aceita PDFs de até 100 páginas e 50 MB. As equipes podem prototipar na API e levar o mesmo modelo para on-premises depois.
Nossa opinião: o GLM-OCR é o parser com o qual medir os outros. Um rival precisa superá-lo nos seus próprios documentos por uma margem que justifique uma stack mais pesada, e pelos números públicos só o OvisOCR2 e o PaddleOCR-VL-1.6 passam dessa marca em páginas avulsas.
Onde ele se destaca
Um líder de automação de back-office em uma empresa de logística europeia
Extrair os campos de destinat ário, endereço e peso de guias de entrega digitalizadas para JSON
Envie cada página ao modelo puro com um prompt de modelo JSON, como o card mostra para documentos de identidade. A Zhipu informa 93,7 no Nanonets-KIE; teste com os seus próprios formulários, já que campos com limites vagos podem voltar incompletos.
Uma startup de duas pessoas construindo um produto de busca em documentos
Processar os PDFs dos clientes antes de comprar GPUs
Comece pela API do Z.ai a US$ 0,03 por milhão de tokens com arquivos de até 100 páginas e depois passe aos mesmos pesos sob vLLM ou SGLang quando o volume justificar hardware. O formato de saída continua o mesmo.
Um engenheiro de dados em uma corretora chinesa que processa documentos regulatórios com carimbos e listagens de código
Converter grandes lotes de PDFs em Markdown em servidores próprios
Rode o SDK do GLM-OCR com o PP-DocLayoutV3 na frente de um servidor vLLM e paralelize as regiões. Nas 1,86 página por segundo da Zhipu, uma réplica processa cerca de 6.700 páginas por hora antes da concorrência.
Antes de decidir
- Configuração
- Instale com pip o SDK do GLM-OCR a partir do GitHub, que inclui o PP-DocLayoutV3, e aponte-o para um servidor vLLM ou SGLang local; as receitas estão nos cookbooks do vLLM e do SGLang, e o suporte no Transformers é nativo.
- Integrações
- vLLM, SGLang, Ollama e Transformers; builds comunitários em GGUF, MLX e ONNX no Hugging Face; LLaMA-Factory para fine-tuning; APIs do Z.ai e do BigModel que aceitam JPG, PNG e PDF.
- Dados e privacidade
- Os pesos são MIT; o modelo de layout é Apache 2.0, então as duas licenças valem para o pipeline completo. Auto-hospedado, os documentos ficam no seu hardware; a página da API não informa os termos de retenção.
- Custo em escala
- O checkpoint em BF16 tem cerca de 2,7 GB, então uma GPU de consumo o serve. Na API, a própria estimativa da Zhipu é de cerca de 2.000 digitalizações A4 por 1 RMB na tarifa chinesa.
- Limites
- Os arquivos da API são limitados a 10 MB por imagem, 50 MB por PDF e 100 páginas. Só três prompts de parsing (texto, fórmula, tabela) mais a extração por esquema são suportados; digitalizações de baixa resolução, tabelas densas e irregulares e idiomas sub-representados pioram o resultado, segundo o relatório.
O que é bom
- 95,22 no OmniDocBench v1.6, medido de forma independente pela OpenDataLab
- 1,86 página de PDF por segundo com concorrência única, segundo a Zhipu
- Licença MIT; API a US$ 0,03 por milhão de tokens
- Extração de campos em JSON guiada por esquema no mesmo modelo
O que não é
- Atrás do OvisOCR2 e do PaddleOCR-VL-1.6 em precisão em páginas avulsas
- O parsing de páginas inteiras depende de um modelo de layout separado
- A extração de campos fica fora do SDK e é sensível à redação do esquema
- Só oito idiomas; a GPU do teste de throughput não é revelada
Ideal para
Equipes que querem um modelo de OCR rápido e com licença permissiva que possam rodar elas mesmas ou alugar por token do mesmo fornecedor.
Alternativas ao GLM-OCR
GLM-OCR: perguntas frequentes
- GLM-OCR vale a pena?
- O GLM-OCR já não é o parser mais preciso, mas é o que tem menos motivos para um não: pequeno, com licença MIT, pontuado de forma independente e barato de alugar. Damos nota 4.3 de 5.
- Quanto custa GLM-OCR?
- Gratuito sob a licença MIT. API do Z.ai a US$ 0,03 por milhão de tokens, entrada e saída; BigModel (China) 0,2 RMB por milhão de tokens.
- Quais são as desvantagens de GLM-OCR?
- Atrás do OvisOCR2 e do PaddleOCR-VL-1.6 em precisão em páginas avulsas; o parsing de páginas inteiras depende de um modelo de layout separado; a extração de campos fica fora do SDK e é sensível à redação do esquema; só oito idiomas; a GPU do teste de throughput não é revelada.
- Para quem GLM-OCR é indicado?
- Equipes que querem um modelo de OCR rápido e com licença permissiva que possam rodar elas mesmas ou alugar por token do mesmo fornecedor.
- Quanto custa GLM-OCR para uma equipe ou em produção?
- O checkpoint em BF16 tem cerca de 2,7 GB, então uma GPU de consumo o serve. Na API, a própria estimativa da Zhipu é de cerca de 2.000 digitalizações A4 por 1 RMB na tarifa chinesa.
- GLM-OCR é seguro para dados da empresa?
- Os pesos são MIT; o modelo de layout é Apache 2.0, então as duas licenças valem para o pipeline completo. Auto-hospedado, os documentos ficam no seu hardware; a página da API não informa os termos de retenção.
- Quais são as melhores alternativas ao GLM-OCR?
- As alternativas mais próximas que analisamos são PaddleOCR-VL-1.6, OvisOCR2, MiniCPM-OCR 1.0 e Qianfan-OCR.
Respostas verificadas em 2 de nov. de 2026.
Você faz o GLM-OCR? Mostre esta nota no seu site
