sgl-project/sglang · error · ValueError

Unknown gemm type: {gemm_type}

Error message

Unknown gemm type: {gemm_type}

What it means

humming_moe_runner_core_run dispatches GEMMs by a gemm_type string and raises ValueError for any unrecognized value. Only the specific gemm types handled above the else branch (grouped/masked/indexed variants) are supported.

Source

Thrown at python/sglang/srt/layers/moe/moe_runner/humming.py:142

        return runner._run_grouped_contiguous_gemm(
            hidden_states=hidden_states,
            topk_ids=topk_ids,
            topk_weights=topk_weights,
            hidden_states_scale=hidden_states_scale,
            apply_routed_scaling_factor=apply_routed_scaling_factor,
        )
    elif gemm_type == "grouped_masked":
        assert expected_m is not None and expert_num_tokens is not None
        return runner._run_grouped_masked_gemm(
            hidden_states=hidden_states,
            topk_ids=topk_ids,
            topk_weights=topk_weights,
            expected_m=expected_m,
            expert_num_tokens=expert_num_tokens,
            hidden_states_scale=hidden_states_scale,
        )
    else:
        raise ValueError(f"Unknown gemm type: {gemm_type}")


class HummingRunnerCore(MoeRunnerCore):
    runner_cores: WeakValueDictionary = WeakValueDictionary()

    def __init__(self, config: MoeRunnerConfig):
        super().__init__(config)
        assert config.num_local_experts is not None
        assert config.num_experts is not None
        self.num_experts = config.num_local_experts
        self.global_num_experts = config.num_experts
        self.activation = config.activation
        self.swiglu_limit = config.swiglu_limit
        self.layer: torch.nn.Module | None = None
        self.humming_gemm_configs = {}
        HummingRunnerCore.runner_cores[id(self)] = self

    @property

View on GitHub (pinned to 0132848349)

Solutions

1. Check the dispatch branches above the else in humming.py:142 for the accepted gemm_type values and use one of them
2. Align sglang version with the humming integration that produced the caller
3. If adding a new gemm type, extend the dispatcher with an explicit branch

SUPPORTED_GEMMS = {'grouped_contiguous', 'grouped_masked', 'indexed'}  # per dispatch branches
assert gemm_type in SUPPORTED_GEMMS, f'gemm_type must be one of {SUPPORTED_GEMMS}'

def is_supported_gemm(g: str) -> bool:
    return g in {'grouped_contiguous', 'grouped_masked', 'indexed'}

When it happens

Trigger: Calling humming_moe_runner_core_run with a gemm_type string not in the supported set — typically from custom code or a version mismatch between sglang and the humming kernel integration where a new gemm type name was added on one side.

Common situations: Mixing sglang versions with custom humming patches; passing a typo'd or renamed gemm type from a fork; upgrading one component without the other.

Understand the failure class

Background: Invalid enum value errors: "Unknown type", "Invalid scope", "must be one of" — when a string is not on the library's allowed list — this error's family across 23 libraries.

Related errors

• Unsupported activation: {self.activation}
• cannot found moe_block_size for shape {valid_shape_m}
• DeepEP returned FP8 input while Humming is configured for BF
• Humming expected DeepEP FP8 hidden states and group-128 scal
• DeepSeekV4 CP supports moe_a2a_backend in {supported_a2a_bac

AI-assisted analysis of sgl-project/sglang@0132848349 (2026-08-28). Data as JSON: /api/errors/9d6a4aa8b3213c0e. Report an issue: GitHub.