sgl-project/sglang · error · ValueError

experimental_sgl_marlin LoRA requires --lora-backend triton

Error message

experimental_sgl_marlin LoRA requires --lora-backend triton

What it means

Startup validation: the experimental SGLang Marlin LoRA path requires --lora-backend triton, because its temporary dense/sink kernels consume Triton SGEMM batch metadata directly and other global LoRA backends are not adapted. Raised when cfg.lora_backend != 'triton' with LoRA enabled on this runner.

Source

Thrown at python/sglang/srt/lora/marlin_lora_temp/policy.py:39

    if resolved_args.ep_size > 1 and resolved_args.moe_a2a_backend != "none":
        raise ValueError("experimental_sgl_marlin EP requires --moe-a2a-backend none")

    # A provided adapter path implicitly enables LoRA later unless it was
    # explicitly disabled. No-LoRA delegates to the stock Marlin fused path.
    lora_enabled = bool(resolved_args.enable_lora) or (
        resolved_args.enable_lora is None and bool(cfg.lora_paths)
    )
    if not lora_enabled:
        return

    if not cfg.lora_use_virtual_experts:
        raise ValueError(
            "experimental_sgl_marlin LoRA requires --lora-use-virtual-experts"
        )
    if cfg.lora_backend != "triton":
        # The temporary dense/sink kernels consume Triton SGEMM batch metadata
        # directly; other global backends are not adapted in this tree.
        raise ValueError("experimental_sgl_marlin LoRA requires --lora-backend triton")
    if resolved_args.ep_size <= 1:
        return

    if (
        cfg.init_expert_location != "trivial"
        or cfg.ep_num_redundant_experts != 0
        or cfg.enable_eplb
        or cfg.elastic_ep_backend is not None
        or cfg.enable_elastic_expert_backup
        or cfg.elastic_ep_rejoin
    ):
        raise ValueError(
            "experimental_sgl_marlin EP requires trivial expert placement "
            "without redundancy, EPLB, or elastic EP"
        )


def validate_experimental_sgl_marlin_contract(

View on GitHub (pinned to 0132848349)

Solutions

1. Set --lora-backend triton explicitly
2. Keep --lora-use-virtual-experts enabled as well (sibling check)
3. If you need a different LoRA backend, use the non-experimental MoE runner

Example fix

# before
--enable-lora --lora-backend flute
# after
--enable-lora --lora-backend triton --lora-use-virtual-experts

lora_enabled = bool(server_args.enable_lora) or bool(server_args.lora_paths)
if lora_enabled:
    assert server_args.lora_backend == 'triton', 'experimental_sgl_marlin LoRA needs --lora-backend triton'

When it happens

Trigger: Launching with the experimental sgl_marlin runner, LoRA enabled, and --lora-backend set to something other than triton (e.g. the default or another backend name).

Common situations: Carrying over a server config tuned for another LoRA backend (e.g. a marlin/flute LoRA backend) to the experimental MoE runner.

Related errors

• experimental_sgl_marlin LoRA requires --lora-use-virtual-exp
• experimental_sgl_marlin LoRA requires --lora-use-virtual-exp
• experimental_sgl_marlin EP requires --moe-a2a-backend none
• experimental_sgl_marlin EP requires trivial expert placement
• experimental_sgl_marlin configuration is unsupported: + ";

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