sgl-project/sglang · error · ValueError

Invalid Pi05 precision: {precision}

Error message

Invalid Pi05 precision: {precision}

What it means

to_selected_dtype moves the Pi05 policy model to a chosen dtype, accepting only 'bfloat16' or 'float32' (bf16 is the default; some vision-tower weights are deliberately kept in fp32 via the keep_fp32 list). Any other precision string raises. It runs from model __init__, so the bad value comes from a config/CLI argument.

Source

Thrown at python/sglang/multimodal_gen/runtime/models/vlas/pi05_core.py:1041

                use_bidirectional_attention=True,
                adarms_cond_dim=(action_expert_config.width if use_adarms[1] else None),
            )
            self.gemma_expert = PiGemmaForCausalLM(
                config=action_config_hf,
                tensor_parallel=False,
            )
            self.gemma_expert.lm_head = None
            self.gemma_expert.model.embed_tokens = None
        self.to_selected_dtype(precision)

    def to_selected_dtype(
        self, precision: Literal["bfloat16", "float32"] = "bfloat16"
    ) -> None:
        if precision == "float32":
            self.to(dtype=torch.float32)
            return
        if precision != "bfloat16":
            raise ValueError(f"Invalid Pi05 precision: {precision}")
        self.to(dtype=torch.bfloat16)
        keep_fp32 = [
            "vision_tower.embeddings.patch_embedding.weight",
            "vision_tower.embeddings.patch_embedding.bias",
            "vision_tower.embeddings.position_embedding.weight",
            "vision_tower.vision_model.embeddings.patch_embedding.weight",
            "vision_tower.vision_model.embeddings.patch_embedding.bias",
            "vision_tower.vision_model.embeddings.position_embedding.weight",
            "input_layernorm",
            "post_attention_layernorm",
            "model.norm",
        ]
        for name, param in self.named_parameters():
            if any(selector in name for selector in keep_fp32):
                param.data = param.data.to(dtype=torch.float32)

    def set_prefix_output_device(self, device: torch.device) -> None:
        self.prefix_output_device = torch.device(device)

View on GitHub (pinned to 0132848349)

Solutions

1. Set precision to 'bfloat16' (default) or 'float32' exactly as a string
2. If you passed a torch dtype, convert: precision='bfloat16' instead of torch.bfloat16
3. fp16/fp8 are unsupported for this policy — retrain/quantize elsewhere or keep fp32
4. Normalize user-facing dtype names to the two accepted literals before constructing the model

Example fix

# before
policy = Pi05Policy.from_pretrained(path, precision="fp16")

# after
policy = Pi05Policy.from_pretrained(path, precision="float32")

from typing import Literal, get_args
Pi05Precision = Literal["bfloat16", "float32"]
assert precision in get_args(Pi05Precision), f"precision must be one of {get_args(Pi05Precision)}"

from typing import Literal, get_args
Pi05Precision = Literal["bfloat16", "float32"]

def is_valid_pi05_precision(p: object) -> bool:
    return isinstance(p, str) and p in get_args(Pi05Precision)

try:
    policy = Pi05Policy.from_pretrained(path, precision=precision)
except ValueError as e:
    if "Invalid Pi05 precision" in str(e):
        policy = Pi05Policy.from_pretrained(path, precision="bfloat16")  # safe default
    else:
        raise

When it happens

Trigger: Constructing the Pi05 policy with precision set to anything except 'bfloat16' or 'float32' — e.g. 'fp16', 'float16', 'fp8', 'bf16', or a torch dtype object instead of a string.

Common situations: Copying a vLLM/sglang server flag like --dtype fp16 or half into the Pi05 policy config; passing a torch.bfloat16 object where the Literal string is expected; mixing up naming conventions between checkpoints ('bf16' vs 'bfloat16').

Related errors

• Unsupported Pi05 dtype: {dtype_name}
• Unknown Pi05 Gemma variant: {variant}
• VLA action expert should not share the prefix TP layout. Use
• This browser cannot encode H.264 MP4
• H.264 encoder did not return MP4 decoder config

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