GLM-4V

The GLM-4V architecture is well-documented in the official technical report 'GLM-4.5V and GLM-4.1V-Thinking'. It utilizes a vision-native approach consisting of a modified Vision Transformer (ViT) encoder (AIMv2-Huge), an MLP adapter, and a GLM-based language decoder. The documentation explicitly details the use of 3D-RoPE for spatial-temporal understanding and the integration of a 'thinking' mechanism for chain-of-thought reasoning. The transition from previous versions (CogVLM2) is clearly explained, providing a strong lineage of architectural evolution.

While the technical reports mention training on 10B+ curated image-text pairs and 220 million images for specific tasks (like OCR), the exact breakdown of the full pre-training corpus is not publicly disclosed. General categories such as synthetic document images (LAION-based), natural scene text (Paddle-OCR), and academic documents (arXiv/LaTeXML) are named, but precise proportions and specific source lists for the primary 10 trillion token text corpus remain opaque, falling into the 'moderate' transparency range.

The tokenizer is publicly accessible via the official Hugging Face repository and GitHub. It uses a byte-level BPE algorithm with a vocabulary size of 151,552 tokens, extended from TikToken's CL100k_base. Documentation specifies the inclusion of special tokens for multimodal tasks (e.g., <|vision_start|>, <|video_start|>). The alignment between the tokenizer's design and its bilingual (Chinese/English) focus is well-verified by technical specifications and implementation code.

The model's parameter density is clearly stated for the 9B variant (GLM-4V-9B). While the larger GLM-4.5V and 4.6V models utilize a Mixture-of-Experts (MoE) architecture (e.g., 106B total with ~12B active), the 9B variant is a dense model. The documentation provides a clear distinction between the vision encoder and the language decoder parameters, though a granular layer-by-layer parameter breakdown is not provided in standard documentation.

Information regarding training compute is extremely limited. While the hardware type (GPUs/TPUs) is implied by the scale of the model, the official reports do not disclose total GPU hours, specific hardware cluster configurations used for the final training run, or the carbon footprint. This lack of environmental and resource transparency is a significant gap, relying on vague 'large-scale' descriptors.

The technical report provides results across 42 public benchmarks (MMStar, MathVista, etc.) and includes some evaluation settings like temperature and top_p. However, the full evaluation code and the exact prompts used for every benchmark are not consistently provided in a single reproducible package. While some third-party verification exists on leaderboards, the reliance on internal evaluation scripts for certain 'thinking' mode benchmarks limits full independent reproducibility.

The model demonstrates high identity consistency, correctly identifying itself as part of the GLM-4 series in system prompts and documentation. It maintains clear versioning (4.1V, 4.5V, 4.6V) and is transparent about its multimodal capabilities and the distinction between 'thinking' and 'non-thinking' modes. There are no documented cases of the model claiming to be a competitor's product.

The GLM-4V-9B weights are released under a permissive MIT License, which is clearly stated on the Hugging Face model card and GitHub repository. This allows for broad commercial and research use. Some ambiguity exists regarding the licensing of the larger 100B+ variants which may have different terms, but for the open-weights 9B variant, the licensing is explicit and standard.

Hardware requirements are well-documented by both the developers and the community. Official documentation and community wrappers (like vLLM and ComfyUI) provide specific VRAM estimates for FP16 (~18-20GB for 9B) and quantized versions (INT4/INT8). Scaling behavior for context lengths up to 128K is also discussed in technical updates, providing users with realistic deployment expectations.

The project maintains a clear versioning history (4.1V -> 4.5V -> 4.6V) with associated 'News' updates on GitHub. However, detailed changelogs for minor weight updates or silent alignment shifts are less frequent. While major releases are well-documented, the lack of a granular, commit-linked changelog for the model weights themselves makes tracking subtle performance drift difficult for end-users.