What problem does it solve? Swapping the vision-language model in the NVIDIA VSS Alerts Blueprint is error-prone because three separate services (rtvi-vlm, vlm-as-verifier, and vss-agent) each hold their own VLM configuration, so changing one environment variable silently leaves the other consumers pointing at the old endpoint. ## Core Features & Use Cases - Two deployment methods: Configure RTVI-VLM against an external OpenAI-compatible endpoint (NIM, vLLM, OpenAI) or run vLLM inside the RTVI container with NGC or Hugging Face model paths. - Three-consumer coverage: Guides updates to RTVI_VLM_* variables, the vlm-as-verifier config.yml, and vss-agent VLM_MODEL_TYPE/VLM_NAME/VLM_BASE_URL settings so no consumer is left stale. - Rigorous health checks: Verifies container status, absence of warm-up error lines, readiness, advertised model identity per method, and a real /v1/chat/completions inference rather than trusting misleading log lines. - Use Case: An engineer repoints the Alerts Blueprint to a host-side NIM at http://host.docker.internal:30082 and needs every VLM consumer, credential mapping, and verification step handled correctly. ## Quick Start Ask the agent to point the VSS Alerts Blueprint at your OpenAI-compatible VLM endpoint and verify all three consumers with health checks.