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
- Set seq_pooling_type explicitly when constructing the config for direct use.
- In model code, obtain PoolerConfig via ModelConfig (model_config.pooler_config) so resolution has run.
- 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
- Always obtain PoolerConfig from ModelConfig, never construct it standalone in model code.
- Check .seq_pooling_type is not None before calling the getter in tests.
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
- tok_pooling_type is not set; it should be resolved by ModelC
- tool response messages require a tool_call_id; use ChatMessa
- request `{request_id}` is already in flight
- engine-core client is closed: {message}
- generate request `{request_id}` has an empty prompt_token_id
AI-assisted analysis of vllm-project/vllm@c794754062 (2026-08-14).
Data as JSON: /api/errors/6ca2313ec8523b8f.
Report an issue: GitHub.