vllm-project/vllm · error · LogprobsError

{parameter} must be non-negative or -1, got {value}

Error message

{parameter} must be non-negative or -1, got {value}

What it means

Logprobs count validation (rust/src/text/src/lower/logprobs.rs:113) rejects any negative value for `logprobs` / `prompt_logprobs` (and the server's `max_logprobs` limit) other than the `-1` sentinel, which expands to the full vocabulary size for bounds checks. Message: `{parameter} must be non-negative or -1, got {value}`.

Source

Thrown at rust/src/text/src/lower/logprobs.rs:15

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

//! Python-compatible validation for logprobs sampling params.
//!
//! `-1` is expanded only for bounds checks. The original request values are
//! passed through to engine-core.

use thiserror::Error;

use crate::backend::SamplingLimits;

#[derive(Debug, Error)]
pub enum LogprobsError {
    #[error("{parameter} must be non-negative or -1, got {value}")]
    InvalidCount { parameter: &'static str, value: i32 },
    #[error(
        "requested {parameter} of {requested}, which is greater than max allowed: {max_allowed}"
    )]
    TooManyCount {
        parameter: &'static str,
        requested: usize,
        max_allowed: usize,
    },
    #[error(
        "requested logprob_token_ids of length {requested}, \
         which is greater than max allowed: {max_allowed}"
    )]
    TooManyTokenIds {
        requested: usize,
        max_allowed: usize,
    },
    #[error(

View on GitHub (pinned to c794754062)

Solutions

  1. Use -1 exactly for 'all logprobs', or a non-negative integer for the top-K count
  2. Omit logprobs/prompt_logprobs entirely when you do not want them

Example fix

// before
request.logprobs = -2;

// after
request.logprobs = -1; // all
// or
request.logprobs = 20;  // top-20
Defensive patterns

Strategy: validation

Validate before calling

for (name, v) in [("logprobs", logprobs), ("prompt_logprobs", prompt_logprobs)] {
    if let Some(v) = v {
        assert!(v == -1 || v >= 0, "{name} must be non-negative or -1, got {v}");
    }
}

Type guard

fn is_invalid_count(e: &Error) -> bool {
    matches!(e, Error::Logprobs(LogprobsError::InvalidCount { .. }))
}

Try / catch

match err {
    Error::Logprobs(LogprobsError::InvalidCount { parameter, value }) =>
        bad_request(format!("{parameter} must be non-negative or -1, got {value}")),
    _ => /* ... */
}

Prevention

When it happens

Trigger: Sending `logprobs: -5` or `prompt_logprobs: -2` in a request; configuring the server with a negative `max_logprobs` limit. Only exactly -1 is accepted as 'all tokens'.

Common situations: Clients from OpenAI-compat ecosystems sending 0/-1 style flags with other negative numbers; config generation that defaults unset ints to -1 but occasionally emits -2; confusion between 'disabled' (omit the field) and -1 (everything).

Related errors


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