Chapter 5. vLLM arguments reference
When you deploy models using Distributed Inference with llm-d, the vLLM runtime handles inference requests. Red Hat AI Inference Server provides comprehensive documentation for vLLM runtime arguments and advanced configuration that you can apply to your llm-d deployments.
5.1. Common use cases for vLLM arguments Copy linkLink copied to clipboard!
Configure vLLM runtime arguments to achieve the following goals:
- Optimize resource usage
-
Reduce GPU memory consumption to fit larger models or enable more concurrent requests. For example, using
--gpu-memory-utilization=0.85leaves headroom for system operations and prevents out-of-memory errors. -
Adjust context length limits to match your application’s requirements. For example, use
--max-model-len=8192for smaller context length to reduce memory requirements.
-
Reduce GPU memory consumption to fit larger models or enable more concurrent requests. For example, using
- Improve performance
-
Minimize latency in production by disabling verbose logging. For example, using
--disable-uvicorn-access-logreduces I/O overhead from logging every HTTP request. -
Enable faster text generation using speculative decoding. For example,
--speculative-model=<draft-model>and--use-v2-block-manageruse a smaller draft model to predict tokens, which is verified by the main model.
-
Minimize latency in production by disabling verbose logging. For example, using
- Support specific model requirements
-
Enable tool calling with custom models. For example, using
--enable-auto-tool-choiceand--tool-call-parser=hermesto enable the model to select tools automatically and parse tool calls using model-specific formats. - Support custom chat templates for models that require specific formatting.
-
Enable prefix caching to speed up requests with repeated prompts using
--enable-prefix-caching.
-
Enable tool calling with custom models. For example, using
- Meet operational needs
-
Configure trust settings for custom or private model sources using
--trust-remote-code. - Reduce log volume in production environments by disabling access logs.
-
Configure trust settings for custom or private model sources using
5.2. Argument reference Copy linkLink copied to clipboard!
- Argument reference
- Advanced features
5.3. Configure vLLM arguments for llm-d deployments Copy linkLink copied to clipboard!
You can configure vLLM runtime arguments to optimize inference performance by using the standard Kubernetes container args field to control memory allocation, request handling, and model behavior without redeploying or rebuilding containers.
Prerequisites
- You have OpenShift AI 3.4 EA2 or later installed.
- You have deployed a model using Distributed Inference with llm-d for distributed inference or single-GPU deployments.
- You have stored a model in S3, a persistent volume claim (PVC), an OCI container registry, or HuggingFace.
-
You have access to the OpenShift CLI (
oc) or the OpenShift web console.
Procedure
- Identify the vLLM arguments you want to configure. For the complete argument reference, see Red Hat AI Inference Server vLLM Server Arguments.
Create or edit the
LLMInferenceServicecustom resource to include theargsfield underspec.template.containersfor the container namedmain.Example vLLM argument configuration:
apiVersion: serving.kserve.io/v1alpha2 kind: LLMInferenceService metadata: name: my-vllm-service namespace: <my_namespace> spec: replicas: 2 model: uri: hf://RedHatAI/Qwen3-8B-FP8-dynamic name: RedHatAI/Qwen3-8B-FP8-dynamic router: route: {} gateway: {} scheduler: {} template: containers: - name: main args: - --disable-uvicorn-access-log - --max-model-len=10000 resources: limits: cpu: '4' memory: 32Gi nvidia.com/gpu: "1" requests: cpu: '2' memory: 16Gi nvidia.com/gpu: "1"where:
-
--disable-uvicorn-access-log: Disables HTTP access logs to reduce log volume. --max-model-len=10000: Sets the maximum context length to 10,000 tokens.NoteThe arguments that you specify are merged with the default arguments provided by the system. If you specify the same argument as a default, your value takes precedence. This allows you to override specific defaults without affecting other default arguments.
-
Apply the custom resource.
$ oc apply -f -n <my_namespace> llminferenceservice.yamlExample output
llminferenceservice.serving.kserve.io/my-vllm-service configured
Verification
Verify that the arguments are applied correctly.
Check that the
LLMInferenceServiceis running:$ oc get llminferenceservice my-vllm-service -n <my_namespace>Example output
NAME READY AGE my-vllm-service True 5mThe READY column shows
True.Verify your custom arguments appear in the pod specification:
Get the pod name:
$ oc get pods -n <my_namespace> -l app.kubernetes.io/name=my-vllm-serviceInspect the container arguments:
$ oc describe pod <pod_name> -n <my_namespace> | grep -A 5 "Args:"Example output
Args: --disable-uvicorn-access-log --max-model-len=10000Your custom arguments should appear in this list.
Test that inference requests work with your configured arguments:
Get the route URL:
$ oc get llmisvc -n <my_namespace> my-vllm-service -o jsonpath='{.status.url}'Send a test request:
$ curl -X POST https://<route_url>/v1/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $(oc whoami -t)" \ -d { "model": "RedHatAI/Qwen3-8B-FP8-dynamic", "prompt": "Explain what Red Hat OpenShift AI is in one sentence.", "max_tokens": 100 }A successful response confirms that your vLLM service is running with the configured arguments.
Additional resources
5.4. vLLM uvicorn access logs Copy linkLink copied to clipboard!
You can control vLLM uvicorn access log behavior based on your debugging and monitoring needs. In Red Hat OpenShift AI 3.4, uvicorn access logs are disabled by default for vLLM deployments that use Distributed Inference with llm-d. This change prevents infrastructure overload caused by high-frequency health checks.
The default LLMInferenceServiceConfig template hardcodes the --disable-uvicorn-access-log flag in the vLLM startup command. Because this flag is embedded in the container startup command rather than the args list, re-enabling access logs requires overriding the entire command field.
Disabling uvicorn access logs does not affect metrics collection. The /metrics endpoint continues to function normally, and Prometheus can still scrape metrics regardless of access log configuration. Metrics provide aggregated performance data, while access logs provide request-level details.
When to re-enable access logs
You might need to re-enable uvicorn access logs in the following scenarios:
- Debugging API usage patterns to understand which endpoints are being called and how frequently
- Monitoring traffic patterns for capacity planning or usage analysis
- Troubleshooting request and response issues that are not visible in metrics alone
- Investigating unexpected API behavior or error conditions
- Analyzing response times and latency patterns across different endpoints
When you enable access logs, you must balance the need for visibility with the infrastructure impact. Consider enabling logs temporarily during active debugging sessions and disabling them again when troubleshooting is complete.
For vLLM 0.16 or later, endpoint-specific log filtering provides a better alternative that maintains visibility into actual API usage while filtering noisy health check logs.
5.5. Enable vLLM uvicorn access logs Copy linkLink copied to clipboard!
You can enable vLLM uvicorn access logs to debug API usage patterns and troubleshoot request issues. Enabling access logs generates significant log volume that can overwhelm the OpenShift web console and log aggregation infrastructure. vLLM uvicorn access logs are disabled by default.
Enabling uvicorn access logs requires overriding the container startup command because the --disable-uvicorn-access-log flag is hardcoded in the default command, not in the args list. Overriding the command field is an advanced configuration that replaces the entire default startup behavior.
Enabling access logs generates significant log volume due to frequent health check and metrics polling (approximately every 200 milliseconds).
The default LLMInferenceServiceConfig template includes a RoCE auto-detection prelude in the command field for high-performance multi-node deployments. The minimal override shown in this procedure drops that prelude, which is appropriate for the typical access-log debugging audience with single-node deployments. If your deployment relies on RoCE auto-detection, copy the full command block from the upstream LLMInferenceServiceConfig template at opendatahub-io/kserve config-llm-template.yaml and remove only the line containing --disable-uvicorn-access-log rather than using the minimal override below.
Prerequisites
-
You have installed the OpenShift CLI (
oc). -
You have logged in as a user with
cluster-adminprivileges. -
You have deployed an
LLMInferenceServiceCR.
Procedure
Edit the
LLMInferenceServiceCR to override the container command.The following example shows how to override the startup command to exclude the
--disable-uvicorn-access-logflag:apiVersion: serving.kserve.io/v1alpha1 kind: LLMInferenceService metadata: name: my-vllm-service namespace: <namespace> spec: replicas: 2 model: uri: hf://RedHatAI/Qwen3-8B-FP8-dynamic name: RedHatAI/Qwen3-8B-FP8-dynamic router: route: {} gateway: {} scheduler: {} template: containers: - name: main command: - /bin/bash - -c - | vllm serve "$@" - -- args: - /mnt/models - --served-model-name=RedHatAI/Qwen3-8B-FP8-dynamic - --port=8000 - --max-model-len=10000 - --gpu-memory-utilization=0.9 # Remove the following three lines if your deployment does not use TLS - --enable-ssl-refresh - --ssl-certfile=/var/run/kserve/tls/tls.crt - --ssl-keyfile=/var/run/kserve/tls/tls.key resources: limits: cpu: '4' memory: 32Gi nvidia.com/gpu: "1" requests: cpu: '2' memory: 16Gi nvidia.com/gpu: "1"-
command: Overrides the default startup command with a minimal bash wrapper that callsvllm serveand forwards the contents ofargsto it as positional arguments via"$@". The--separator after the script body is required for bash to treat subsequent entries as positional parameters rather than bash options. -
args: Contains the vLLM server arguments. The first entry,/mnt/models, is the required model path that the storage initializer mounts into the container. The remaining entries are vLLM CLI flags. Replace the--served-model-namevalue with the value ofspec.model.namefrom yourLLMInferenceService.
NoteWhen you override the
commandfield, you replace all default command-level behavior, including the--disable-uvicorn-access-logflag that is normally applied. By omitting this flag in your custom command, uvicorn access logs are enabled.-
Apply the custom resource:
$ oc apply -f llminferenceservice.yaml -n <namespace>
Verification
Verify that the
LLMInferenceServiceis running:$ oc get llminferenceservice <service_name> -n <namespace>The output shows the service status:
NAME READY AGE my-vllm-service True 5mView the pod logs to confirm that access log entries appear:
$ oc logs <POD_NAME> -n <NAMESPACE> | grep "HTTP/1.1"-
<POD_NAME>is the name of one of the vLLM pods.
The output shows HTTP access log entries:
INFO: 172.30.45.2:54321 - "GET /metrics HTTP/1.1" 200 OK INFO: 172.30.45.2:54322 - "GET /health HTTP/1.1" 200 OK INFO: 172.30.45.2:54323 - "POST /v1/completions HTTP/1.1" 200 OKVerify the log format includes the HTTP method, endpoint path, and status code.
-
5.6. Example usage for Distributed Inference with llm-d Copy linkLink copied to clipboard!
These examples show how to use Distributed Inference with llm-d in common scenarios.
5.6.1. Single-node GPU deployment Copy linkLink copied to clipboard!
Use single-GPU-per-replica deployment patterns for development, testing, or production deployments of smaller models, such as 7-billion-parameter models.
For examples using single-node GPU deployments, see Single-Node GPU Deployment Examples.
5.6.2. Multi-node deployment Copy linkLink copied to clipboard!
For examples using multi-node deployments, see DeepSeek-R1 Multi-Node Deployment Examples.
5.6.3. Intelligent inference scheduler with KV cache routing Copy linkLink copied to clipboard!
You can configure the scheduler to track key-value (KV) cache blocks across inference endpoints and route requests to the endpoint with the highest cache hit rate. This configuration improves throughput and reduces latency by maximizing cache reuse.
For an example, see Precise Prefix KV Cache Routing.