vllm-project/vllm · error · SamplingParamsError

{parameter} must be in {expected}, got {value}

Error message

{parameter} must be in {expected}, got {value}

What it means

Range validation in rust/src/text/src/lower/sampling.rs: temperature must be [0, 2]; top_p in (0, 1]; min_p [0, 1]; frequency_penalty and presence_penalty [-2, 2]; repetition_penalty (0, inf). The message names the parameter, its value, and the expected interval. Request-validation error.

Source

Thrown at rust/src/text/src/lower/sampling.rs:11

// SPDX-License-Identifier: Apache-2.0
// SPDX-FileCopyrightText: Copyright contributors to the vLLM project

use thiserror::Error;
use vllm_engine_core_client::protocol::sampling::EngineCoreSamplingParams;

#[derive(Debug, Error, PartialEq)]
pub enum SamplingParamsError {
    #[error("{parameter} must be a finite number, got {value}")]
    NotFinite { parameter: &'static str, value: f32 },
    #[error("{parameter} must be in {expected}, got {value}")]
    OutOfRange {
        parameter: &'static str,
        value: f32,
        expected: &'static str,
    },
}

fn validate_frequency_penalty(value: f32) -> Result<(), SamplingParamsError> {
    validate_closed_range("frequency_penalty", value, -2.0, 2.0, "[-2, 2]")
}

fn validate_presence_penalty(value: f32) -> Result<(), SamplingParamsError> {
    validate_closed_range("presence_penalty", value, -2.0, 2.0, "[-2, 2]")
}

fn validate_temperature(value: f32) -> Result<(), SamplingParamsError> {
    validate_finite("temperature", value)?;
    validate_closed_range("temperature", value, 0.0, 2.0, "[0, 2]")

View on GitHub (pinned to c794754062)

Solutions

  1. Clamp each parameter to its stated interval before sending (temperature [0,2], top_p (0,1], min_p [0,1], penalties [-2,2], repetition_penalty > 0)
  2. For greedy decoding use temperature=0.0, not top_p=0
  3. For no penalty/repetition effect use 0.0 penalties and repetition_penalty=1.0

Example fix

# before
temperature = 3.0
top_p = 0

# after
temperature = 0.0  # greedy
top_p = 1.0        # disabled
Defensive patterns

Strategy: validation

Validate before calling

fn in_range(v: f32, lo: f32, hi: f32) -> bool { v >= lo && v <= hi }
assert!(in_range(temperature, 0.0, 2.0));
assert!(top_p > 0.0 && top_p <= 1.0);
assert!(in_range(min_p, 0.0, 1.0));
assert!(in_range(frequency_penalty, -2.0, 2.0));
assert!(in_range(presence_penalty, -2.0, 2.0));
assert!(repetition_penalty > 0.0);

Type guard

fn is_out_of_range(e: &Error) -> bool {
    matches!(e, Error::SamplingParams(SamplingParamsError::OutOfRange { .. }))
}

Try / catch

match err {
    Error::SamplingParams(SamplingParamsError::OutOfRange { parameter, value, expected }) =>
        bad_request(format!("{parameter}={value} not in {expected}")),
    _ => /* ... */
}

Prevention

When it happens

Trigger: Sending temperature=3.0, top_p=0.0 or 1.5, min_p=1.2, frequency/presence_penalty outside [-2,2], or repetition_penalty=0.0/negative in a request. Note top_p=0 is rejected (open lower bound) and repetition_penalty must be strictly positive.

Common situations: Copying 'greedy' configs that use top_p=0 (should be temperature=0 instead); penalty values scaled from a -5..5 convention; unit mismatches (percent 50 vs 0.5 for min_p).

Related errors


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