Rtvi Vlm Customize Model

VLM Customization — VSS Alerts Blueprint

When to use

Use this skill when the user wants to:

• repoint the VSS Alerts Blueprint to a different VLM endpoint,
• run rtvi-vlm standalone with either an OpenAI-compatible endpoint or the in-container vLLM path,
• fix the assumption that changing one VLM config automatically updates rtvi-vlm, vlm-as-verifier, and vss-agent.

Do not use this skill for CV detector swaps inside vss-rt-cv; use rtvi-cv-customize-model for those.

Instructions

• Treat rtvi-vlm, vlm-as-verifier, and vss-agent as three separate VLM consumers. Do not imply that changing only RTVI_VLM_* automatically repoints the verifier or the agent UI.
• Treat all paths in this skill as relative to a checkout of the public VSS Blueprint repository. Blueprint deployment files live under deploy/docker/...; customer-accessible RT-VLM source and standalone deployment files live under services/rtvi/rt-vlm/.... None of these paths resolve inside the DeepStream repository.
• For blueprint-side OpenAI-compatible routing, cover all three surfaces: RTVI_VLM_* env vars, ${VSS_PROFILE_DIR}/vlm-as-verifier/configs/config.yml, and the vss-agent VLM_MODEL_TYPE / VLM_NAME / VLM_BASE_URL settings, then mention force-recreate plus log checks.
• For standalone vllm-compatible, set VLM_MODEL_TO_USE=vllm-compatible, point MODEL_PATH at the weights source, mention HF_TOKEN only when the model actually needs auth. Do not treat a log line as proof of a working deployment: v3.2.1 logs Warmup VlmProcess-0 done even when warm-up raised an exception. Require the absence of an Error during warmup line, readiness, and one successful /v1/chat/completions response.
• Never paste credentials into chat or logs; capture with a silent prompt (read -rsp), chmod 600 the env file, and never commit generated.env.

Examples

• "Point the VSS Alerts Blueprint at a host-side NIM on http://host.docker.internal:30082 for all RTVI-VLM calls."
• "Run rtvi-vlm standalone with Qwen3-VL-8B-Instruct served inside the container."
• "I changed only RTVI_VLM_ENDPOINT in generated.env. That should repoint vlm-as-verifier and vss-agent too, right?"

Source locations

This skill is documentation-only — no VSS sources ship here. Use a VSS v3.2.1 or compatible checkout and run every command from its root. Clone/LFS, Alerts profile paths, RT-VLM tree, pinned images, and VSS_* vars: references/vss-source-layout.md.

Which modes this applies to

VLM customization applies to both modes. Three services each make their own VLM calls with separate configuration:

All three can point at the same model endpoint — they don't have to.

alert-bridge and vss-agent are closed-source; their pinned images (and the rtvi-vlm image tag) are listed in references/vss-source-layout.md.

RTVI-VLM: Two Deployment Methods

The implementation is selected by VLM_MODEL_TO_USE (standalone) or RTVI_VLM_MODEL_TO_USE (VSS blueprint).

Method A: OpenAI-Compatible Endpoint (openai-compat)

The RTVI container makes HTTP calls to an external inference server; it does not load the model itself. This covers local or remote NIM, external vLLM, and OpenAI.

Method B: vLLM Inside the RTVI Container (vllm-compatible)

The container downloads and serves the model using its bundled vLLM engine. No external inference server is needed.

Hard constraint: The model architecture must be supported by the vLLM version shipped in the selected RTVI image. Check the supported-model guidance in services/rtvi/rt-vlm/README.md. If the model requires a newer vLLM, use Method A with an external container instead.

Configuring RTVI-VLM via VSS Blueprint

The VSS blueprint .env / generated.env maps most RTVI_VLM_* variables to container-native names. The model or deployment identifier is the important exception: v3.2.1 maps VLM_NAME to VIA_VLM_OPENAI_MODEL_DEPLOYMENT_NAME. RTVI_VLM_PORT is also exceptional: it is required by Compose to publish the service and must be explicitly supplied when generated.env does not contain it.

Required port configuration — all Blueprint workflows

Add RTVI_VLM_PORT and update the two hardcoded 8018 lines in the Alerts profile .env, then rerun dev-profile.sh. Edit .env, not generated.env — the generator overwrites it.

# ${VSS_PROFILE_DIR}/.env
RTVI_VLM_PORT=8018                                        # add this line
RTVI_VLM_BASE_URL=http://${HOST_IP}:${RTVI_VLM_PORT}     # update: was http://${HOST_IP}:8018
RTVI_VLM_ENDPOINT=http://${HOST_IP}:${RTVI_VLM_PORT}/v1  # update: was http://${HOST_IP}:8018/v1

Keep the value at 8018 unless that port is unavailable. Variable ownership, the VLM_BASE_URL generator overwrite, and the patch required for any other port are in references/port-and-url-wiring.md.

Method A — OpenAI-compatible endpoint

In the v3.2.1 blueprint Compose file, these host variables map as follows:

After applying the shared port configuration above, configure the active profile environment:

# ${VSS_PROFILE_DIR}/.env
RTVI_VLM_MODEL_TO_USE=openai-compat
RTVI_VLM_ENDPOINT=http://host.docker.internal:30082/v1
VLM_NAME=<model-or-deployment-id>
OPENAI_API_KEY=<your-api-key>     # client fallback/default credential
RTVI_VLM_API_KEY=<your-api-key>   # mapped to preferred VIA_VLM_API_KEY
# RTVI_VLM_IMAGE_TAG=3.2.1    # pin to a specific image tag; defaults to 3.2.1

For an authenticated Method A endpoint, set OPENAI_API_KEY and RTVI_VLM_API_KEY to the same endpoint-specific credential. The stock Compose file maps RTVI_VLM_API_KEY to VIA_VLM_API_KEY, and the OpenAI-compatible client prefers VIA_VLM_API_KEY over OPENAI_API_KEY. Leave both unset only when the endpoint intentionally accepts unauthenticated requests.

Examples:

# NIM on the Docker host. Stock Compose maps this name through host-gateway.
RTVI_VLM_ENDPOINT=http://host.docker.internal:30082/v1
VLM_NAME=nvidia/cosmos-reason2-8b

# NVIDIA API catalog (set keys via silent prompt)
RTVI_VLM_ENDPOINT=https://integrate.api.nvidia.com/v1
VLM_NAME=nvidia/cosmos-reason2-8b
OPENAI_API_KEY=<your-nvidia-api-key>
RTVI_VLM_API_KEY=<your-nvidia-api-key>

# OpenAI (set keys via silent prompt)
RTVI_VLM_ENDPOINT=https://api.openai.com/v1
VLM_NAME=gpt-4o
OPENAI_API_KEY=<your-openai-api-key>
RTVI_VLM_API_KEY=<your-openai-api-key>

Migrating from Method B: Replace RTVI_VLM_API_KEY before recreating rtvi-vlm; do not leave the previous NGC credential in that variable. If RTVI_VLM_API_KEY is empty, stock Compose falls back to NGC_CLI_API_KEY when populating VIA_VLM_API_KEY. Because the client prefers VIA_VLM_API_KEY, a stale NGC key would be sent to the new Method A endpoint instead of OPENAI_API_KEY. This is both an authentication failure and a credential-disclosure risk.

RTVI_VLM_OPENAI_MODEL_DEPLOYMENT_NAME is not consumed by the public v3.2.1 blueprint Compose file. Use VLM_NAME unless the deployed Compose file has been intentionally customized.

Verify the configured model identifier from inside the RTVI container. The conditional Authorization header keeps keyless local endpoints working while authenticating endpoints such as OpenAI and the NVIDIA API Catalog. Endpoints may advertise multiple models, so confirm the configured ID appears anywhere in the /models response:

ALERTS_ENV=developer-profiles/dev-profile-alerts/generated.env

# Container-native name for `VLM_NAME`.
EXPECTED_MODEL="$(docker compose --env-file "${ALERTS_ENV}" exec -T rtvi-vlm \
  printenv VIA_VLM_OPENAI_MODEL_DEPLOYMENT_NAME | tr -d '\r')"
test -n "${EXPECTED_MODEL}"

docker compose --env-file "${ALERTS_ENV}" exec -T rtvi-vlm sh -lc \
  'set --
   if [ -n "${VIA_VLM_API_KEY:-}" ]; then
     set -- -H "Authorization: Bearer ${VIA_VLM_API_KEY}"
   fi
   curl -fsS "$@" "${VIA_VLM_ENDPOINT%/}/models"' \
  | jq -e --arg model "${EXPECTED_MODEL}" 'any(.data[]; .id == $model)' \
  || { echo "Endpoint does not advertise '${EXPECTED_MODEL}'" >&2; exit 1; }

jq -e exits non-zero when the assertion is false, so the check passes only when the configured model appears somewhere in the list. To see which models the endpoint offers, drop the jq filter and read the raw response.

Treat HTTP 401 from this request as an authentication failure. Only treat a successful response that fails the jq assertion as a model-name mismatch.