huggingface/transformers · error · ValueError

Received multiple types, therefore expected the first type t

Error message

Received multiple types, therefore expected the first type to indicate an array.

What it means

GGUF metadata values can carry multiple types (when a field was read with multiple readers); in that case _gguf_parse_value requires the first type code to be 9 (GGUF's ARRAY type), treating the second as the element type. If the type list has length > 1 but does not start with 9, the structure is not an array-with-element-type and the parser cannot disambiguate, so it raises ValueError.

Source

Thrown at src/transformers/integrations/ggml.py:390

    },
    "minimax_m2": {
        # MiniMax-M2 uses routing bias (e_score_correction_bias) for MoE expert selection,
        # but this is not stored in GGUF metadata. Set it as default so the model weights
        # (which include e_score_correction_bias tensors) are loaded correctly.
        "use_routing_bias": True,
    },
}


def _gguf_parse_value(_value, data_type):
    if not isinstance(data_type, list):
        data_type = [data_type]
    if len(data_type) == 1:
        data_type = data_type[0]
        array_data_type = None
    else:
        if data_type[0] != 9:
            raise ValueError("Received multiple types, therefore expected the first type to indicate an array.")
        data_type, array_data_type = data_type

    if data_type in [0, 1, 2, 3, 4, 5, 10, 11]:
        _value = int(_value[0])
    elif data_type in [6, 12]:
        _value = float(_value[0])
    elif data_type == 7:
        _value = bool(_value[0])
    elif data_type == 8:
        _value = array("B", list(_value)).tobytes().decode()
    elif data_type == 9:
        _value = _gguf_parse_value(_value, array_data_type)
    return _value


class GGUFTokenizerSkeleton:
    def __init__(self, dict_):
        for k, v in dict_.items():

View on GitHub (pinned to a597f97485)

Solutions

Re-export or re-download the GGUF with an official/known-good converter (llama.cpp conversion tooling)
Inspect the file's metadata (e.g. `gguf-dump` from gguf-py) and fix or strip the offending field
If the file is fine, upgrade transformers — newer GGUF type handling may accept it

Defensive patterns

Strategy: try-catch

Try / catch

try:
    model = AutoModelForCausalLM.from_pretrained("model.gguf")
except ValueError as e:
    if "expected the first type to indicate an array" in str(e):
        raise RuntimeError("Malformed GGUF metadata — re-convert with llama.cpp tooling") from e
    raise

Prevention

Produce GGUF files only with well-tested converters (llama.cpp convert scripts)
Validate third-party GGUFs with gguf-dump before loading into transformers

When it happens

Trigger: Loading a .gguf file where a metadata field resolves to a multi-type entry whose first type code is not 9 — typically a malformed/nonstandard GGUF produced by third-party tools, or a partially corrupted header.

Common situations: Converting weights with community GGUF converters that emit nonstandard metadata fields; hand-edited GGUF files; version skew between the GGUF writer and transformers' reader (new type codes).

Related errors

tokens and scores need to be passed for a LLaMa tokenizer wi

AI-assisted analysis of huggingface/transformers@a597f97485 (2026-08-14). Data as JSON: /api/errors/6c9bfcb29c8a5301. Report an issue: GitHub.