GLM-4.5 Enterprise Deployment: A Practical On-Prem Guide
GLM-4.5 is Zhipu AI's mixture-of-experts flagship, built with a particular strength in agentic coding tasks: multi-file code generation, tool-integrated debugging, and long-horizon coding agent workflows. It ships in two sizes: the full GLM-4.5 at roughly 355B total parameters with about 32B active, and GLM-4.5-Air, a smaller variant designed for lighter hardware footprints without giving up most of the agentic coding capability. Both are released under the MIT license, giving enterprises full commercial and fine-tuning rights without a usage threshold. This guide covers the architecture and license, hardware sizing at each quantization, serving stack setup, fine-tuning options, regulated-industry considerations, and when Netray recommends GLM-4.5 over another coding-capable alternative.
What GLM-4.5 Is: Architecture, Sizes, and License
GLM-4.5's roughly 355B total parameters with about 32B active per token position it between Qwen3's 235B-A22B and DeepSeek's 671B-parameter models in total footprint, with training specifically weighted toward agentic coding benchmarks: writing, running, debugging, and iterating on multi-file codebases through tool use rather than single-shot code generation. GLM-4.5-Air trims the total and active parameter count meaningfully while retaining much of the coding-agent capability, aimed at teams that want the coding-focused training without the full model's hardware cost. Both sizes ship under the MIT license, matching DeepSeek and Kimi K2 in license permissiveness: full commercial use, fine-tuning, and redistribution rights with no threshold or field-of-use restriction.
- GLM-4.5: roughly 355B total parameters, approximately 32B active, MoE architecture
- GLM-4.5-Air: smaller variant, reduced total and active parameters, retains most agentic coding capability
- Training specifically weighted toward multi-file, tool-integrated agentic coding workflows
- MIT license across both sizes, full commercial and fine-tuning rights, no usage threshold
Hardware Requirements at Different Quantizations
The full GLM-4.5 at FP8 needs roughly 355GB of GPU memory, requiring 4-5x H100 80GB or 3x H200; at INT4/AWQ that drops to roughly 180GB, feasible on 2-3x H100 80GB. GLM-4.5-Air's smaller footprint typically needs roughly 60-80GB at FP8 depending on the exact configuration, fitting a single H100 80GB or H200 comfortably, or dropping to single-GPU territory at INT4 with room for solid concurrency. For coding-agent workloads specifically, budget extra KV cache headroom beyond typical chat sizing, since multi-file code context and iterative tool-call transcripts accumulate substantially more tokens per session than a standard chat interaction.
- GLM-4.5 full model at INT4: approximately 180GB, 2-3x H100 80GB
- GLM-4.5 full model at FP8: approximately 355GB, 4-5x H100 80GB or 3x H200
- GLM-4.5-Air at FP8: approximately 60-80GB, single H100 80GB or H200
- Coding-agent sessions need extra KV cache headroom for accumulated multi-file context and tool-call transcripts
Serving Stack Setup
vLLM and SGLang both support GLM-4.5's MoE architecture, and SGLang's prefix caching is particularly valuable here given how much shared context, repeated codebase snippets, tool schemas, and system prompts, accumulates across a coding agent's session. For coding-agent deployments specifically, plan the serving stack alongside a code execution sandbox and version control integration layer, since the model's value is realized through the tool-use loop, not the raw inference endpoint alone. GLM-4.5-Air's smaller footprint also makes it a reasonable llama.cpp/Ollama target for developer workstation deployment during pilot and evaluation phases before committing to server infrastructure.
Fine-Tuning and Customization Options
LoRA and QLoRA fine-tuning on GLM-4.5, particularly the Air variant, is well supported through Axolotl and LLaMA-Factory, and is a realistic path for adapting the model to a specific codebase's conventions, internal API patterns, or proprietary framework usage that generic training data would not capture. Full fine-tuning of the full 355B model requires a substantial GPU cluster and is rarely justified over LoRA for coding-agent customization specifically, since most of the value in domain adaptation comes from teaching the model your codebase's patterns and tool schemas rather than fundamentally altering its coding capability. DPO is useful for reducing unnecessary tool calls and tightening the agent's decision to stop iterating once a task is genuinely complete, a common production tuning need for coding agents.
Security and License Considerations for Regulated Industries
The MIT license removes legal friction, though as with DeepSeek and Kimi K2, some defense-adjacent clients apply additional internal review on training data provenance given GLM's origin as a China-based lab, independent of the license terms. Coding-agent deployments introduce a specific security consideration beyond standard model deployment: code execution sandboxes need the same isolation and least-privilege scoping as any production code execution environment, and an agent with source code repository access needs audit logging on every commit, branch, and file modification it makes, treated with the same rigor as a human developer's access. On-prem deployment is particularly relevant here for defense and aerospace clients whose source code itself may be export-controlled or CUI, since no code ever needs to leave the network for the agent to operate.
When Netray Recommends GLM-4.5 vs Alternatives
We recommend GLM-4.5, typically the Air variant first, when a client's primary use case is agentic coding: automated bug fixing, test generation, or multi-file refactoring tied into their existing SyteLine, LN, or M3 customization codebase. Against gpt-oss and Qwen3, GLM-4.5's specific training emphasis on tool-integrated coding workflows tends to show up as fewer wasted tool calls and better multi-step task completion on real coding-agent benchmarks, though we validate this against the client's own codebase rather than published scores before recommending a build-out. Where the workload is general text rather than coding-specific, a general-purpose model from earlier in this guide series is usually the better fit.
Frequently Asked Questions
What is GLM-4.5-Air and how is it different from GLM-4.5?
GLM-4.5-Air is a smaller mixture-of-experts variant of the full GLM-4.5 model, with reduced total and active parameter counts, designed to retain most of the agentic coding capability on a substantially smaller hardware footprint. It typically fits on a single H100 80GB or H200 card at FP8, versus the full model's multi-GPU requirement, making it the practical starting point for most enterprise pilots.
Is GLM-4.5 good for coding tasks specifically?
Yes, GLM-4.5 was trained with a specific emphasis on agentic coding workflows: multi-file code generation, tool-integrated debugging, and long-horizon coding agent tasks, rather than general chat quality alone. It tends to perform well on benchmarks measuring multi-step task completion and tool-call efficiency in coding contexts, though results should be validated against your own codebase before committing to a production deployment.
What GPU setup does GLM-4.5-Air need on-prem?
GLM-4.5-Air typically needs roughly 60-80GB of GPU memory at FP8 quantization, fitting comfortably on a single H100 80GB or H200 card, or dropping into single-GPU territory with strong concurrency at INT4 quantization. This makes it accessible to enterprises without a multi-GPU fleet, unlike the full GLM-4.5 model which requires several H100-class cards.
Is GLM-4.5 free for commercial and internal enterprise use?
Yes, GLM-4.5 and GLM-4.5-Air are both released under the MIT license, permitting full commercial use, fine-tuning, and redistribution with no usage threshold or field-of-use restriction. As with other China-developed open models, some defense-adjacent clients apply additional internal review on training data provenance independent of the license terms themselves.
Key Takeaways
- 1What GLM-4.5 Is: Architecture, Sizes, and License: GLM-4.5's roughly 355B total parameters with about 32B active per token position it between Qwen3's 235B-A22B and DeepSeek's 671B-parameter models in total footprint, with training specifically weighted toward agentic coding benchmarks: writing, running, debugging, and iterating on multi-file codebases through tool use rather than single-shot code generation. GLM-4.5-Air trims the total and active parameter count meaningfully while retaining much of the coding-agent capability, aimed at teams that want the coding-focused training without the full model's hardware cost.
- 2Hardware Requirements at Different Quantizations: The full GLM-4.5 at FP8 needs roughly 355GB of GPU memory, requiring 4-5x H100 80GB or 3x H200; at INT4/AWQ that drops to roughly 180GB, feasible on 2-3x H100 80GB. GLM-4.5-Air's smaller footprint typically needs roughly 60-80GB at FP8 depending on the exact configuration, fitting a single H100 80GB or H200 comfortably, or dropping to single-GPU territory at INT4 with room for solid concurrency.
- 3Serving Stack Setup: vLLM and SGLang both support GLM-4.5's MoE architecture, and SGLang's prefix caching is particularly valuable here given how much shared context, repeated codebase snippets, tool schemas, and system prompts, accumulates across a coding agent's session. For coding-agent deployments specifically, plan the serving stack alongside a code execution sandbox and version control integration layer, since the model's value is realized through the tool-use loop, not the raw inference endpoint alone.
Put this into numbers
Free interactive tools for exactly this problem. No signup to use them.
GLM-4.5 On-Prem Sizing Calculator
Size VRAM, GPU count, and capital cost for GLM-4.5 or the smaller GLM-4.5-Air, both mixture-of-experts models tuned for agentic and coding workloads.
Free Toolgpt-oss Hardware Sizing Calculator
Size VRAM, GPU count, and capital cost for OpenAI's Apache 2.0 licensed gpt-oss-20b or gpt-oss-120b, both natively quantized to MXFP4 for single-GPU deployment.
Free ToolQwen3 Deployment Sizing Calculator
Size VRAM, GPU count, and capital cost across the Qwen3 family, from the 235B-A22B mixture-of-experts flagship down to the dense 8B model.
Terms used in this article
Building a coding agent against your SyteLine, LN, or M3 codebase? Netray will benchmark GLM-4.5 against your actual repository and tool-use patterns before you size the deployment.
Related Resources
Kimi K2 Enterprise Deployment: An On-Prem Guide
Deploy Kimi K2 on-prem: 1T-parameter MoE architecture, modified MIT license, GPU sizing at quantization, serving setup, and when agentic workloads justify it.
AI & AutomationCode Generation Models On-Prem: Qwen3-Coder, Devstral, and More
Deploy code generation models on-prem: Qwen3-Coder, Devstral, Codestral, and StarCoder2 compared for enterprise coding assistants and hardware sizing.
AI & AutomationDeepSeek V3 Enterprise Deployment Guide
Deploy DeepSeek V3 on-prem: 671B MoE architecture, MIT license, GPU sizing by quantization, vLLM serving setup, fine-tuning options, and when to use it.