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

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.85 leaves 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=8192 for smaller context length to reduce memory requirements.
Improve performance
  • Minimize latency in production by disabling verbose logging. For example, using --disable-uvicorn-access-log reduces 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-manager use a smaller draft model to predict tokens, which is verified by the main model.
Support specific model requirements
  • Enable tool calling with custom models. For example, using --enable-auto-tool-choice and --tool-call-parser=hermes to 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.
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.

5.2. Argument reference

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

  1. Identify the vLLM arguments you want to configure. For the complete argument reference, see Red Hat AI Inference Server vLLM Server Arguments.
  2. Create or edit the LLMInferenceService custom resource to include the args field under spec.template.containers for the container named main.

    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.

      Note

      The 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.

  3. Apply the custom resource.

    $ oc apply -f -n <my_namespace> llminferenceservice.yaml

    Example output

    llminferenceservice.serving.kserve.io/my-vllm-service configured

Verification

  1. Verify that the arguments are applied correctly.

    1. Check that the LLMInferenceService is running:

      $ oc get llminferenceservice my-vllm-service -n <my_namespace>

      Example output

      NAME               READY   AGE
      my-vllm-service    True    5m

      The READY column shows True.

    2. 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-service

      Inspect 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=10000

      Your custom arguments should appear in this list.

    3. 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.

5.4. vLLM uvicorn access logs

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.

Note

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

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).

Note

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-admin privileges.
  • You have deployed an LLMInferenceService CR.

Procedure

  1. Edit the LLMInferenceService CR to override the container command.

    The following example shows how to override the startup command to exclude the --disable-uvicorn-access-log flag:

    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 calls vllm serve and forwards the contents of args to 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-name value with the value of spec.model.name from your LLMInferenceService.
    Note

    When you override the command field, you replace all default command-level behavior, including the --disable-uvicorn-access-log flag that is normally applied. By omitting this flag in your custom command, uvicorn access logs are enabled.

  2. Apply the custom resource:

    $ oc apply -f llminferenceservice.yaml -n <namespace>

Verification

  1. Verify that the LLMInferenceService is running:

    $ oc get llminferenceservice <service_name> -n <namespace>

    The output shows the service status:

    NAME              READY   AGE
    my-vllm-service   True    5m
  2. View 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 OK

    Verify the log format includes the HTTP method, endpoint path, and status code.

These examples show how to use Distributed Inference with llm-d in common scenarios.

5.6.1. Single-node GPU deployment

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

For examples using multi-node deployments, see DeepSeek-R1 Multi-Node Deployment Examples.

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.

Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

Legal Notice

Theme

© 2026 Red Hat
Back to top