vllm-project/vllm · error · ValueError

seq_pooling_type is not set; it should be resolved by ModelC

Error message

seq_pooling_type is not set; it should be resolved by ModelConfig before calling get_seq_pooling_type()

What it means

PoolerConfig.get_seq_pooling_type() raises when seq_pooling_type is still None at call time. The field is meant to be populated either explicitly by the user or by ModelConfig's resolution step (which maps pooling_type and task defaults into seq/tok fields). Seeing None means resolution never ran — an internal contract violation, not a user config error in most cases.

Source

Thrown at vllm/config/pooler.py:164

                logger.debug(
                    "Resolved `pooling_type=%r` to `seq_pooling_type=%r`.",
                    pooling_type,
                    pooling_type,
                )
                self.seq_pooling_type = pooling_type  # type: ignore[assignment]
            elif pooling_type in TOK_POOLING_TYPES:
                logger.debug(
                    "Resolved `pooling_type=%r` to `tok_pooling_type=%r`.",
                    pooling_type,
                    pooling_type,
                )
                self.tok_pooling_type = pooling_type  # type: ignore[assignment]
            else:
                raise NotImplementedError(pooling_type)

    def get_seq_pooling_type(self) -> SequencePoolingType:
        if self.seq_pooling_type is None:
            raise ValueError(
                "seq_pooling_type is not set; it should be resolved by"
                " ModelConfig before calling get_seq_pooling_type()"
            )
        return self.seq_pooling_type

    def get_tok_pooling_type(self) -> TokenPoolingType:
        if self.tok_pooling_type is None:
            raise ValueError(
                "tok_pooling_type is not set; it should be resolved by"
                " ModelConfig before calling get_tok_pooling_type()"
            )
        return self.tok_pooling_type

    def compute_hash(self) -> str:
        """
        WARNING: Whenever a new field is added to this config,
        ensure that it is included in the factors list if
        it affects the computation graph.

View on GitHub (pinned to c794754062)

Solutions

  1. Set seq_pooling_type explicitly when constructing the config for direct use.
  2. In model code, obtain PoolerConfig via ModelConfig (model_config.pooler_config) so resolution has run.
  3. For vLLM contributors: call the resolution path (ModelConfig initialization) before get_seq_pooling_type().

Example fix

# before
cfg = PoolerConfig()
type_ = cfg.get_seq_pooling_type()  # raises

# after
cfg = PoolerConfig(seq_pooling_type='MEAN')
type_ = cfg.get_seq_pooling_type()
Defensive patterns

Strategy: validation

Validate before calling

def get_seq_type_or_default(cfg, default: str = "MEAN") -> str:
    return cfg.seq_pooling_type if cfg.seq_pooling_type is not None else default

Type guard

def has_seq_pooling(cfg) -> bool:
    return cfg.seq_pooling_type is not None

Try / catch

try:
    ptype = cfg.get_seq_pooling_type()
except ValueError:
    ptype = "MEAN"  # or run ModelConfig resolution first

Prevention

When it happens

Trigger: Calling pooler_config.get_seq_pooling_type() on a hand-constructed PoolerConfig that was never processed by ModelConfig/_resolve_pooling; or model-loading code paths that skip the ModelConfig resolution step.

Common situations: Custom model implementations or tests instantiating PoolerConfig directly and calling getters; internal refactors that call the getter before ModelConfig.__post_init__ resolution.

Related errors


AI-assisted analysis of vllm-project/vllm@c794754062 (2026-08-14). Data as JSON: /api/errors/6ca2313ec8523b8f. Report an issue: GitHub.