What is GLM-4.7-REAP-218B-A32B?
GLM-4.7-REAP-218B-A32B is a sparse mixture-of-experts, or MoE, causal language model published by Cerebras. It is not a separately trained model family in the usual sense; it is a compressed derivative of Z.ai's GLM-4.7. Cerebras applied its Router-weighted Expert Activation Pruning method to remove experts that were considered redundant in the source model.
The name describes the resulting configuration. The model contains 218 billion parameters in total, but only 32 billion are active for each token. In an MoE model, a router chooses a subset of specialist subnetworks, called experts, for each input token. Because most experts are not used on every token, the active parameter count is more relevant to per-token computation than the total parameter count, although the full checkpoint still has substantial memory requirements.
Cerebras lists the checkpoint as an open-weight model under the MIT license. The model card identifies it as a BF16/F32 checkpoint, and the supplied research describes it as a current open-weight model checkpoint released on January 12, 2026. It is available through the Cerebras model catalog on Hugging Face rather than as a model with published hosted Cerebras pricing.
Where it fits in Cerebras's catalog
GLM-4.7-REAP-218B-A32B is best understood as a deployment-oriented companion to the full GLM-4.7 model, not as a general Cerebras API product or a replacement for every model in the catalog. Its purpose is to preserve much of the source model's intended behavior while reducing the number of experts that must be stored and made available.
The reduction is significant but not equivalent to turning the model into a small model. The original source model is described in the supplied research as having approximately 355 billion parameters, while the REAP checkpoint has 218 billion total parameters. The compressed model still requires substantial multi-GPU capacity, especially in BF16 or F32 formats. Its practical advantage is relative: it should be less demanding than the uncompressed source model, rather than lightweight in the way a small dense or compact MoE model would be.
Core specifications
| Specification | GLM-4.7-REAP-218B-A32B |
|---|---|
| Provider | Cerebras |
| Model family | GLM-4.7 |
| Architecture | Sparse mixture-of-experts causal language model |
| Total parameters | 218 billion |
| Active parameters per token | 32 billion |
| Experts | 96 total, with 8 activated per token |
| Context window | 202,752 tokens |
| Layers | 92 |
| Attention heads | 96 query-attention heads and 8 key/value heads |
| License | MIT |
| Input and output | Text input and text output |
The 202,752-token context window is one of the model's clearest practical features. It allows a single request to contain much more source material than is possible with a conventional short-context model, making the checkpoint relevant to large codebases, lengthy technical documents, multi-step agent traces, and other tasks where context must remain available. The supplied research does not specify a maximum output-token limit, so users should not assume that the full context window can be used simultaneously for input and generated output.
Capabilities and strengths
Coding and reasoning
The model is positioned for coding and reasoning rather than image, audio, or video work. Its intended uses include code generation, code analysis, technical problem-solving, and multi-step tasks that require the model to maintain a chain of decisions. The research describes editorial assessments of 9 out of 10 for coding and 8 out of 10 for reasoning. These are approximate editorial scores, not provider-published benchmark results. In particular, the BF16 model card's evaluation results were listed as pending, while results were available for a separate FP8 variant.
That distinction matters when evaluating the checkpoint. The architecture and stated use cases support testing for coding and reasoning, but the supplied sources do not establish a verified benchmark score for this exact BF16 checkpoint. Teams should measure performance on their own repositories, prompts, languages, and reasoning workloads before treating the model as a substitute for another system.
Tool calling and agentic workflows
GLM-4.7-REAP-218B-A32B supports function-calling and tool-oriented workflows. The model card describes direct deployment with current vLLM using the glm45 reasoning parser, the glm47 tool-call parser, automatic tool choice, and expert parallelism. These details are useful for users who want to connect the model to external actions such as search, code execution, data retrieval, or application-specific functions.
Tool support does not mean that the model independently accesses the web or performs actions without an application around it. A host application still needs to define available tools, validate arguments, execute approved calls, and return results to the model. The supplied data specifically marks web search as unsupported as a native capability, so external search should be treated as an application-integrated tool rather than an intrinsic model feature.
Long-context processing
The model's context capacity makes it suitable for tasks such as reviewing a large collection of files, comparing long specifications, maintaining a detailed agent history, or working through extended documentation. Long context is most useful when the task genuinely requires retaining information across a large input. It does not automatically guarantee equally strong attention to every token, and it can increase memory use and latency as prompts grow.
Deployment, performance, and cost trade-offs
REAP's main trade-off is between model capacity and deployment requirements. Compared with the full approximately 355-billion-parameter source model, the 218-billion-parameter checkpoint removes a substantial number of parameters and activates only 32 billion per token. This can make it a more practical local or research deployment target than the uncompressed model. However, 218 billion total parameters remains a large checkpoint, particularly when using BF16 or F32 weights and accounting for runtime memory, context storage, and multi-GPU communication.
The supplied editorial assessment gives the model a speed score of 6 out of 10 and a cost score of 8 out of 10. These scores are subjective evaluations based on its compressed architecture and intended positioning, not published Cerebras measurements. The model is therefore not automatically the fastest choice. A smaller dense model or a much smaller MoE model may provide lower latency and simpler hardware requirements, while a larger uncompressed model may offer a different quality or capability profile at a higher deployment cost.
No hosted input or output price is supplied for this checkpoint. It is not deployed through a Hugging Face Inference Provider in the supplied research, and there is no published Cerebras API price associated with this model record. The MIT license concerns the checkpoint's licensing terms; it should not be interpreted as a guarantee that hosting, GPUs, storage, electricity, or engineering work will be free.
Supported modalities and limitations
This is a text-only model. It accepts text input and produces text output. The supplied specifications do not indicate native image, audio, video, music, speech, embedding, or other non-text output. It should not be selected for image understanding, image generation, speech interaction, video analysis, or multimedia creation without separate systems that handle those modalities.
There are also several deployment limitations to consider:
- The checkpoint is large despite its pruning. It is intended for substantial multi-GPU environments, not ordinary consumer hardware by default.
- The available research does not provide a maximum output-token value.
- Fine-tuning, caching, streaming, batch API, and structured-output support are not verified in the supplied specifications.
- Native web search is not supported; search requires an external tool and orchestration layer.
- Evaluation results for the BF16 checkpoint were pending in the cited model-card information, so the separate FP8 results should not be presented as direct BF16 results.
- There is no authoritative knowledge-cutoff date identified for this exact REAP checkpoint.
When to choose this model
Choose GLM-4.7-REAP-218B-A32B when you need an open-weight model with a long context window and strong intended coverage of coding, reasoning, tool calling, and agentic workflows, but want a compressed alternative to the full GLM-4.7 checkpoint. It is particularly relevant for research teams and infrastructure owners that can operate a multi-GPU deployment and value local control over a hosted service.
It is also a reasonable candidate when the workload benefits from a large model's breadth but the uncompressed source model is too demanding for the available infrastructure. Expert parallelism and the documented vLLM parser configuration may help users build a practical serving setup, although actual throughput and memory use must be tested on the chosen hardware and quantization or precision configuration.
Another option may be more appropriate when low latency, low memory use, or predictable hosted pricing is the priority. A smaller model can be easier to deploy and may deliver better cost or speed for routine extraction, classification, short-form generation, or simple coding tasks. A hosted API may also be preferable for teams that do not want to manage GPUs, model serving, tool security, and operational maintenance. Conversely, a different large model may be better if verified benchmark results, a documented knowledge cutoff, native multimodal input, or guaranteed structured-output behavior is essential.
Bottom line
GLM-4.7-REAP-218B-A32B is a substantial but deliberately compressed open-weight MoE model. Its defining value is not that it is small; it is that REAP reduces the original GLM-4.7 parameter footprint while retaining a 32-billion-parameter active pathway and a 202,752-token context window. The result is aimed at serious local and research deployments involving code, reasoning, long documents, and tools.
Its strongest case is for users who can support multi-GPU inference and want more control than a hosted endpoint provides. Its main weaknesses are the remaining hardware burden, the absence of published hosted pricing, incomplete verification of some serving features, and the lack of confirmed BF16 benchmark results in the supplied research. Treating it as a compressed, text-only GLM-4.7 derivative rather than as a lightweight general-purpose model gives the most accurate picture of where it fits.