* Split mode graph for GLM4MoE MTP in split_mode_tensor_parallel
Analogous to what was done for Qwen35 dense MTP in PR 2027:
- ctx_for_layer_split(): return buft_matrix for GLM4_MOE MTP tail
layers instead of buft, so split tensor preparation uses the
correct split context.
- create_glm4_moe_tensors(): remove the ctx_split = ctx_layer
override for MTP tail layers. ctx_for_layer_split(i) now
returns buft_matrix for GLM4_MOE MTP tails, so regular layer
tensors (attn, ffn) are created in the split context. NextN
tensors (eh_proj, enorm, hnorm, shared_head_head,
shared_head_norm) stay monolithic via ctx_for_layer().
- create_tensors(): add LLM_ARCH_GLM4_MOE to the MTP tail
layer splitting exclusion so split processing visits them.
- build_glm4_moe_mtp(): pass inp_out_ids to build_std_attention
instead of post-processing with ggml_get_rows. Use build_output
for the output projection to properly handle split mode.
- build_output(): add LLM_ARCH_GLM4_MOE to the is_qwen_mtp
check to ensure MTP output is properly materialized.
* Skip loading shared_head_head for GLM4MoE MTP
Add TENSOR_SKIP flag to shared_head_head so it is never loaded, even
when present in the GGUF file. The graph code already falls back to
model.output when shared_head_head is nullptr (line 375-376), which
frees ~306 MiB on CUDA0 for models that include this tensor (e.g.,
GLM-Steam-106B). The 355B GLM-4.6 model does not have this tensor and
already uses the same fallback path.
* cuda-graph: GLM4_MOE - Don't load layer.nextn.embed_tokens
---------
Co-authored-by: Nexesenex <124105151+Nexesenex@users.noreply.github.com>
Samuel Oliveira Alves
Kawrakow