sgl-project/sglang · error · ValueError

InklingBatchDenseMLPWithLoRA is ineligible: {joined problems

Error message

InklingBatchDenseMLPWithLoRA is ineligible: {joined problems}

What it means

initialize_lora runs an eligibility audit for InklingBatchDenseMLPWithLoRA and, if any problems were collected (backend is not Triton for multi-slot dense LoRA, or the shared sink does not use linearized BF16 weights), raises a ValueError joining all problems. It means the current serving configuration is incompatible with the Inkling multi-slot dense LoRA path, not that weights are corrupt.

Source

Thrown at python/sglang/srt/models/inkling_common/lora.py:24

from sglang.srt.models.inkling_common.dense_mlp import InklingBatchDenseMLP


class InklingBatchDenseMLPWithLoRA(InklingBatchDenseMLP):
    """LoRA layer for Inkling's dense shared-expert sink."""

    is_shared_fused_moe = True

    def initialize_lora(self, lora_backend: BaseLoRABackend) -> None:
        problems = []
        if (
            lora_backend.max_loras_per_batch > 1
            and getattr(lora_backend, "name", None) != "triton"
        ):
            problems.append("multi-slot dense LoRA requires the Triton backend")
        if not self._linearized_bf16_enabled:
            problems.append("the shared sink does not use linearized BF16 weights")
        if problems:
            raise ValueError(
                "InklingBatchDenseMLPWithLoRA is ineligible: " + "; ".join(problems)
            )

        self.lora_backend = lora_backend
        self.set_lora = False
        self.experts_shared_outer_loras = False
        self.register_buffer("_w1_delta", None, persistent=False)
        self.register_buffer("_a_cat", None, persistent=False)
        self._lora_routing_cache = {}
        lora_backend.is_moe_lora = True

    def set_lora_info(
        self,
        gate_up_lora_a_weights: torch.Tensor,
        gate_up_lora_b_weights: torch.Tensor,
        down_lora_a_weights: torch.Tensor,
        down_lora_b_weights: torch.Tensor,
    ) -> None:

View on GitHub (pinned to 0132848349)

Solutions

1. Set the LoRA backend to Triton, e.g. --lora-backend triton (multi-slot dense LoRA requires it)
2. Enable linearized BF16 weights for the shared sink (load the model in bfloat16 with linearization enabled; check the flag controlling _linearized_bf16_enabled)
3. Read the joined problem list in the message — fix every listed item, not just the first

Example fix

# before
python -m sglang.launch_server --model inkling --lora-backend flashinfer
# after
python -m sglang.launch_server --model inkling --lora-backend triton --dtype bfloat16

ok = (getattr(lora_backend, 'name', None) == 'triton') and module._linearized_bf16_enabled
if ok:
    module.initialize_lora(lora_backend)

def inkling_lora_eligible(module, backend) -> bool:
    return getattr(backend, 'name', None) == 'triton' and bool(module._linearized_bf16_enabled)

try: module.initialize_lora(backend)
except ValueError as e: if 'ineligible' in str(e): downgrade/disable dense LoRA or switch backend; else: raise

When it happens

Trigger: Calling init_lora_modules/_new_sink -> initialize_lora when lora_backend.name != 'triton' while multi-slot dense LoRA is requested, and/or self._linearized_bf16_enabled is False (weights not loaded as linearized BF16).

Common situations: Selecting the FlashInfer or CUDA (cutlass) LoRA backend instead of triton; serving with dtype/quantization that disables linearized BF16 sinks (e.g. fp16, FP8 checkpoint, --enable-torch-compile paths); mixing flags after an upgrade that changed defaults.

Related errors

• Inkling shared-sink LoRA requires four 4D MoE buffers
• Inkling shared-sink LoRA outer factors must have expert dime
• Inkling shared-sink gate-up A and down B must use the same e
• Inkling shared-sink LoRA expert count does not match
• Inkling shared-sink LoRA rank dimensions do not match

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