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
- Use -1 exactly for 'all logprobs', or a non-negative integer for the top-K count
- 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
- Use exactly -1 for 'all', non-negative for top-K; omit otherwise
- Centralize logprobs-count handling in one client helper instead of per-call literals
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
- max_logprobs must be non-negative or -1, got {}
- max_logprobs must be non-negative or -1
- requested {parameter} of {requested}, which is greater than
- requested logprob_token_ids of length {requested}, which is
- when both logprobs and logprob_token_ids are set, logprobs m
AI-assisted analysis of vllm-project/vllm@c794754062 (2026-08-14).
Data as JSON: /api/errors/7ff8e1f18ab2088a.
Report an issue: GitHub.