Logits Processing
For general vLLM features and configuration, see the Reference Guide.
Logits processors let you modify the next-token logits at every decoding step (e.g., to apply custom constraints or sampling transforms). Dynamo provides a backend-agnostic interface and an adapter for vLLM so you can plug in custom processors.
How it works
- Interface: Implement
dynamo.logits_processing.BaseLogitsProcessor, which defines__call__(input_ids, logits)and modifieslogitsin-place. - Shared spec layer: The engine declares a backend-neutral
LogitsProcessorSpec(seedynamo.common.backend.engine). The sharedlogits_processors_for_requesthelper owns the generation-stage gating (activate only onAGGREGATED/DECODE) and the per-request freshness policy. - vLLM mechanism: Unlike TRT-LLM, vLLM cannot accept a live per-request callable. Its custom logits processors are engine-loaded: a class is registered at engine init and instantiated once, then called for every batch. Per-request activation rides on
SamplingParams.extra_args(vLLM’svllm_xargs). Dynamo’s adapter lives atdynamo.vllm.logits_processing.adapter.
Quick test: HelloWorld processor
DYN_ENABLE_TEST_LOGITS_PROCESSOR=1 is a built-in test hook (not a production processor loader) that forces the model to respond with “Hello world!”. It verifies the callback path without modifying your model or engine code:
Send a normal chat/completions request; the response should contain “Hello world!”.
Disaggregated caveat
The quick test targets aggregated deployments. In disaggregated mode the prefill worker emits one token before decode resumes, and the test processor has per-request state. The unified backend skips the test hook on the prefill role (the shared generation-stage gating returns no entries there), but the decode-side output can still be affected by the prefill-produced leading token. Use aggregated mode to verify the wiring.
How the unified backend wires this up
The unified vLLM engine threads logits processors through the shared spec layer in dynamo.common.backend.engine and the per-backend realizer at dynamo.vllm.logits_processing.adapter:
start()registers the engine-loaded adapter (DynamoVllmLogitsProcessor) ontoengine_args.logits_processorsbefore building the engine config — but only when the env hook is on and the worker is a generation role (AGGREGATED/DECODE). Production paths leavelogits_processorsuntouched. After the engine (and tokenizer) is up, it resolves aLogitsProcessorSpeconce viaresolve_test_logits_processor_spec, tokenizing"Hello world!"into aForcedTokenSequenceSpecwith the token IDs already resolved.Nonewhen the env var is off or on a non-generation role.generate()callslogits_processors_for_request(spec, disaggregation_mode=...)to get the per-request entry list (empty on PREFILL or when spec isNone), thenactivate_logits_processors(sampling_params, entries)serializes the entries intosampling_params.extra_args["dynamo_logits"].DynamoVllmLogitsProcessor.new_req_logits_processor(params)(called once per request by vLLM) readsextra_args["dynamo_logits"], realizes a fresh per-requestForcedSequenceLogitsProcessor, and returns a request callable that applies it. Requests with no activation returnNone, so vLLM skips them.
The same shared layer hosts the TRT-LLM and SGLang slices; each backend translates the same LogitsProcessorSpec into its native shape. The public config-driven loader (when it lands) plugs in by resolving a LogitsProcessorSpec from CLI/config instead of from this env var; no engine code changes.
Current limitations
- The env hook ships only
ForcedTokenSequenceSpec(pre-resolved token IDs). Arbitrary DynamoBaseLogitsProcessorinstances and a public import-string/plugin loader are deferred follow-ups (see the design doc). PythonProcessorSpec(the TRT-LLM in-process escape hatch wrapping a live callable) is not serializable, so the vLLM adapter rejects it.- Processors must modify the per-request 1-D logits vector in-place.