Model lineup improvement: add an accessible GLM-5.2 candidate and reconsider MiniMax-M2.7 as default #1408
Model lineup improvement: add an accessible GLM-5.2 candidate and reconsider the default model
Problem
At the moment, the network appears to have very limited active capacity for GLM-5.2.
Most hosts are concentrated on MiniMaxAI/MiniMax-M2.7, while only a smaller number are serving Kimi-K2.6. GLM-5.2 adoption is still very low, even though GLM-5.2 is currently one of the most attractive open models for coding, long-context tasks, tool usage, and Chinese/English developer workloads.
The current official GLM-5.2 model is:
https://huggingface.co/zai-org/GLM-5.2-FP8
However, its resource requirements are high, which may reduce host willingness to serve it.
This creates a market mismatch:
- users may want GLM-5.2 inference
- but not enough hosts are willing or able to serve the current FP8 version
- as a result, the network cannot fully capture demand for this model
Proposal 1: Add one quantized GLM-5.2 candidate
I suggest evaluating one of the following two non-GGUF, production-style GLM-5.2 quantized models.
Option A: canada-quant/GLM-5.2-W4A16-MTP
https://huggingface.co/canada-quant/GLM-5.2-W4A16-MTP
Why it is interesting:
- vLLM-oriented
- non-GGUF production-style checkpoint
- W4A16 / INT4 quantization
- includes MTP / speculative decoding direction
- lower resource requirements than the current FP8 model
- may increase host willingness to serve GLM-5.2
Option B: PhalaCloud/GLM-5.2-W4AFP8
https://huggingface.co/PhalaCloud/GLM-5.2-W4AFP8
Why it is interesting:
- non-GGUF production-style checkpoint
- based on
zai-org/GLM-5.2-FP8 - much smaller than the FP8 release
- tested with SGLang
- keeps the full GLM-5.2 parameter count
- designed for long-context GLM-5.2 inference
- may provide strong practical throughput and user experience
Important note:
PhalaCloud/GLM-5.2-W4AFP8 is currently documented mainly for SGLang. If Gonka requires vLLM for MLNode integration, vLLM compatibility should be tested before adding it to the active model lineup.
Suggested implementation path
I do not suggest immediately replacing the current zai-org/GLM-5.2-FP8.
A safer path would be:
- Add one quantized GLM-5.2 candidate as an optional model.
- Give it a bootstrap period.
- Measure:
- host adoption
- PoC stability
- validation consistency
- inference speed
- long-context stability
- real user demand
- If the results are good, increase its role in the model lineup.
The goal is to make GLM-5.2 more accessible to hosts and increase real GLM-5.2 availability on the network.
Proposal 2: Reconsider MiniMaxAI/MiniMax-M2.7 as the default model
Currently, MiniMaxAI/MiniMax-M2.7 is the default model / initial_model_id.
It may be useful as a low-barrier operational model, but it does not seem strong enough as the main default model for attracting real inference demand.
I suggest evaluating:
https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash
as a possible replacement or successor for MiniMaxAI/MiniMax-M2.7 in the default / fallback model role.
Why DeepSeek-V4-Flash may be a better default candidate:
- lower resource requirements than many large MoE models
- strong DeepSeek brand recognition
- more attractive to developers than MiniMax-M2.7
- better fit for coding and agentic workloads
- likely to generate more real user demand
- can help keep the default model useful, not just easy to run
Expected benefit
This would separate the model strategy into two layers:
- A stronger default / fallback model:
-
consider
deepseek-ai/DeepSeek-V4-Flashinstead ofMiniMaxAI/MiniMax-M2.7 -
A more accessible GLM-5.2 option:
- choose between
canada-quant/GLM-5.2-W4A16-MTPandPhalaCloud/GLM-5.2-W4AFP8
This may improve both sides of the network:
- more hosts willing to serve useful models
- more users willing to send real inference requests
- better utilization of the network
- stronger demand for GNK-based inference
Request
Please consider:
- Testing vLLM / MLNode compatibility for
canada-quant/GLM-5.2-W4A16-MTP. - Testing vLLM / MLNode compatibility for
PhalaCloud/GLM-5.2-W4AFP8. - Adding one of them as an optional GLM-5.2 candidate if validation is stable.
- Evaluating
deepseek-ai/DeepSeek-V4-Flashas a better default / fallback model thanMiniMaxAI/MiniMax-M2.7.
💬 Comments (3)
I support evaluating DeepSeek-V4-Flash as a Gonka default or optional production model.
I am evaluating Gonka as an API provider for real AI products, including coding agents and prompt-processing applications. The current focus on MiniMax reduces the commercial attractiveness of the network because model quality and developer demand matter just as much as low hardware requirements.
DeepSeek would make Gonka substantially more attractive for:
- coding and agentic workloads;
- tool calling;
- structured output;
- developer-facing API products;
- real production traffic rather than only PoC participation.
Could the maintainers clarify the next concrete step for Issue #1408?
In particular:
- Who can run the initial vLLM and MLNode compatibility test?
- What benchmark and validation criteria are required?
- How many Hosts must commit capacity before bootstrap?
- What is needed to convert this discussion into an on-chain governance proposal?
If DeepSeek-V4-Flash becomes available with acceptable latency and stability, I would be interested in testing it through a Gonka gateway and providing real usage feedback.
🔄 Auto-synced from Issue #1408 every hour.
Additional note on
PhalaCloud/GLM-5.2-W4AFP8:This option may be especially promising. In practical use, its quality may be very close to, or in some cases even better than, the official FP8 release, while also providing very high token generation speed.
However, the main uncertainty is vLLM compatibility. The model card currently documents SGLang usage, but it is not fully clear whether it can run reliably under vLLM in Gonka's MLNode environment.
Since SGLang and vLLM share many important production inference capabilities, this model still seems worth testing. If it can be made compatible with Gonka's serving stack, it may be one of the best GLM-5.2 candidates for increasing host adoption and real user demand.