Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Use this skill when deploying standalone RT-VLM dense captioning or calling its REST API (uploads, captions, streams, chat-completions, Kafka). Not for VSS profile deploy or video-search ingestion.
.claude/skills/nvidia-vss-deploy-dense-captioning/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-13 | ✗→✓ | ▲ Improved | -26% | 0% |
| case-02 | ✗→✓ | ▲ Improved | 238% | 0% |
| case-03 | ✗→✓ | ▲ Improved | 95% | 0% |
| case-05 | ✗→✓ | ▲ Improved | 412% | 0% |
| case-06 | ✗→✓ | ▲ Improved | 132% | 0% |
Stand up the RT-VLM dense-captioning microservice on its own and exercise every endpoint it exposes (file upload, generate_captions, stream add/delete, chat-completions, Kafka topics).
For standalone RT-VLM deployment:
$NGC_CLI_API_KEY for docker login nvcr.io,image pulls, and local NGC model/artifact downloads.
curl, jq, and any writable working directory for the standalone compose copy.For API calls against an existing service:
$BASE_URL.$RTVI_VLM_API_KEY or $NGC_CLI_API_KEY, depending on how theservice was configured.
For full VSS profile deployment:
../vss-deploy-profile/SKILL.md; this skill does not deploy full VSS profiles.Follow the routing tables and step-by-step workflows below. Each section that ends in workflow, quick start, or flow is intended to be executed top-to-bottom. Detailed reference material lives in references/; execute the documented workflows directly unless a future revision names a concrete helper.
Worked end-to-end examples are kept under evals/ (each *.json manifest contains a runnable scenario) and inline in the per-workflow curl blocks below. Run a Tier-3 evaluation with nv-base validate <this-skill-dir> --agent-eval to replay them.
existing RT-VLM service reachable from the caller.
NGC_CLI_API_KEY, RTVI_VLM_API_KEY, and rtvi-vlm.env files out of git and out of logs; do not echo credential values or include them in final responses.sudo are effectively root-level privileges. Use the non-interactive sudo -n guard in the deploy reference and stop for host-owner action when passwordless sudo is unavailable./docs or /health; redeploy via vss-deploy-profile or the matching vss-deploy-* skill.NGC_CLI_API_KEY. Solution: docker login nvcr.io and re-export the key before retrying.docker compose down.RT-VLM is NVIDIA's real-time vision-language microservice: decode video (file or RTSP), segment it into chunks, run a VLM (cosmos-reason1, cosmos-reason2, cosmos-reason3, or any OpenAI-compatible model), stream dense captions back over SSE/HTTP, and publish captions, incident alerts, and errors to Kafka. Use this skill to deploy the standalone RT-VLM service when a full VSS profile is not already running, then call its /v1/... API for caption generation, file upload, live-stream management, health checks, NIM-compatible chat completions, or Prometheus metrics. API reference: <https://docs.nvidia.com/vss/latest/real-time-vlm-api.html>.
If the user asks to deploy a full VSS profile, use ../vss-deploy-profile/SKILL.md. That skill owns profile routing, generated.env, resolved.yml, multi-service sizing, and full-stack deploy/teardown.
If the user asks for standalone RT-VLM dense captioning, or no VSS profile is already running, use the standalone RT-VLM flow in references/deploy-rt-vlm-service.md before calling the API. This follows the same compose-centric pattern as vss-deploy-profile: gather context, run preflights, work from a local copy, dry-run with docker compose config, review, deploy, then wait for health.
Always follow this sequence. Never skip the dry-run.
bash# 1. Copy deploy/docker/services/rtvi/rtvi-vlm/rtvi-vlm-docker-compose.yml # into any writable standalone working directory. # 2. Derive RTVI_VLM_IMAGE_TAG from that compose copy. # 3. Strip the standalone-only dangling depends_on block from the copy. # 4. Create a gitignored rtvi-vlm.env with the required RT-VLM values. # 5. Prepare host bind paths such as $VSS_DATA_DIR/data_log/vst/clip_storage. # Use `sudo -n` for ownership fixes; if passwordless sudo is unavailable, # stop and ask the host owner to run the printed command manually. # 6. docker compose --env-file rtvi-vlm.env -f rtvi-vlm-docker-compose.yml config --quiet # 7. docker pull the exact RT-VLM image tag. # 8. docker compose ... up -d rtvi-vlm, wait for ready, then smoke test.
Run preflights before any pull or up; stop and fix failures here before debugging RT-VLM itself:
bashnvidia-smi --query-gpu=index,name --format=csv,noheader nvidia-container-cli info docker compose version docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi
For standalone single-file deployments, do not run the raw deploy/docker/services/rtvi/rtvi-vlm/rtvi-vlm-docker-compose.yml directly: it contains depends_on references to sibling VLM/NIM services that are only defined in the full VSS/met-blueprints compose project. The standalone reference shows how to copy the compose file, derive the current image tag from it, strip the depends_on block, and validate the result before up.
For agent-driven validation, never let sudo prompt interactively. Before any privileged ownership or Docker operation, use the non-interactive guard in references/deploy-rt-vlm-service.md: prefer plain docker; otherwise use sudo -n docker; if sudo -n fails, stop with the exact manual command for the host owner instead of retrying with interactive sudo or weakening permissions.
If docker pull fails with a containerd snapshotter/unpack error on Docker 28+, apply the /etc/docker/daemon.json containerd-snapshotter=false fix in the standalone reference before retrying.
Minimum standalone rtvi-vlm.env values:
| Host env var | Required when | Purpose | |---|---|---| | NGC_CLI_API_KEY | Standalone deploy path | NGC registry image pull and NGC model/artifact download | | RTVI_VLM_API_KEY or NGC_CLI_API_KEY | Authenticated API calls | RT-VLM bearer auth after the service is running | | RTVI_VLM_PORT | Always | Host API port mapped to container 8000 | | HOST_IP | Always | Kafka bootstrap host (${HOST_IP}:9092) | | VSS_DATA_DIR | Always | Required clip-storage bind mount | | RTVI_VLM_MODEL_TO_USE | Always for standalone | Backend selector; use cosmos-reason3 for the default local model or openai-compat for a remote/sibling endpoint | | RTVI_VLM_MODEL_PATH | Local self-hosted model | Source-backed Cosmos Reason3 Nano BF16 path: ngc:nim/nvidia/cosmos3-nano-reasoner:bf16-final | | RTVI_VLM_ENDPOINT | RTVI_VLM_MODEL_TO_USE=openai-compat | Remote/sibling OpenAI-compatible VLM endpoint | | VLM_NAME | RTVI_VLM_MODEL_TO_USE=openai-compat | Model/deployment name exposed by that endpoint |
bashexport BASE_URL="http://localhost:${RTVI_VLM_PORT:-8018}" # host-side RT-VLM port export API_KEY="${NGC_CLI_API_KEY:-${RTVI_VLM_API_KEY:-}}" # bearer token used by host-side curl commands : "${API_KEY:?Set NGC_CLI_API_KEY or RTVI_VLM_API_KEY before calling authenticated endpoints}"
Every request below uses Authorization: Bearer $API_KEY. Health endpoints (/v1/health/*, /v1/ready, /v1/live, /v1/startup) typically work without auth.
Smoke test before use:
bashcurl -fsS "$BASE_URL/v1/health/ready" MODEL_ID="$(curl -fsS "$BASE_URL/v1/models" -H "Authorization: Bearer $API_KEY" | jq -r '.data[0].id // .id')" curl -fsS "$BASE_URL/openapi.json" | jq -r '.paths | keys[]' | sort
When a task or eval names RTSP_SAMPLE_URL, treat that exact environment variable as a required input. Verify it is set and non-empty before probing or registering any stream; if it is missing, stop with a clear failure message. Do not derive a substitute from NvStreamer, VIOS, sample-data bundles, or any other fallback, because that validates a different stream than the caller requested.
bash: "${RTSP_SAMPLE_URL:?Set RTSP_SAMPLE_URL to a reachable RTSP sample stream before RTSP validation}" case "$RTSP_SAMPLE_URL" in rtsp://*) ;; *) echo "RTSP_SAMPLE_URL must be an rtsp:// URL, got: $RTSP_SAMPLE_URL" >&2; exit 1 ;; esac if command -v ffprobe >/dev/null 2>&1; then ffprobe -v error -rtsp_transport tcp \ -select_streams v:0 -show_entries stream=codec_type \ -of csv=p=0 "$RTSP_SAMPLE_URL" | grep -qx video elif command -v gst-discoverer-1.0 >/dev/null 2>&1; then gst-discoverer-1.0 "$RTSP_SAMPLE_URL" | grep -qi 'video' else echo "Install ffprobe or gst-discoverer-1.0 before RTSP validation." >&2 exit 1 fi
bash# 1. Upload the video, capture its file id FILE_ID=$(curl -fsS -X POST "$BASE_URL/v1/files" \ -H "Authorization: Bearer $API_KEY" \ -F "file=@/path/to/warehouse.mp4" \ -F "purpose=vision" \ -F "media_type=video" | jq -r '.id') # 2. Generate captions + alerts (SSE stream of chunked responses) curl -N -X POST "$BASE_URL/v1/generate_captions" \ -H "Authorization: Bearer $API_KEY" \ -H "Content-Type: application/json" \ -d "{ \"id\": \"$FILE_ID\", \"prompt\": \"Write a concise dense caption for each 10-second segment of this warehouse video.\", \"model\": \"$MODEL_ID\", \"chunk_duration\": 10, \"stream\": true }"
Use the live OpenAPI as the source of truth before calling optional endpoints:
bashcurl -fsS "$BASE_URL/openapi.json" | jq -r '.paths | keys[]' | sort
Core paths for VSS 3.2 are:
POST /v1/files for multipart media upload; pass the returned file id intocaption generation and delete the file when finished.
POST /v1/generate_captions for file or stream captioning. Use the exactmodel id returned by GET /v1/models; aliases such as cosmos-reason2 or cosmos-reason3 are backend selectors, not request model ids.
POST /v1/streams/add, GET /v1/streams/get-stream-info, andDELETE /v1/streams/delete/{stream_id} for RTSP lifecycle. Parse stream ids from results[0].id.
POST /v1/chat/completions for OpenAI-compatible text and multimodal calls.Current 26.05 builds return HTTP 400 for text-only /v1/completions; treat that as expected when validating legacy behavior.
GET /v1/health/ready, /v1/models, /v1/assets/stats, and /v1/metricsfor service probes. Do not assume /v1/license exists unless OpenAPI lists it.
Detailed endpoint schemas, response shapes, CV-style singular stream endpoints, and 26.05 compatibility notes live in references/api-surface-26.05.md.
POST /v1/files, call/v1/generate_captions with the returned file id, use stream=true for SSE, then delete the file to release storage.
RTSP_SAMPLE_URL, use thatexact URL and run the RTSP Sample Stream Guard before registration. Do not derive a replacement stream from NvStreamer or VIOS when RTSP_SAMPLE_URL is empty; fail fast instead. Require an actual video stream/caps entry before registration; add the stream, caption it, then unregister it.
Anomaly Detected: Yes/No line.Kafka publication is server-side config, additive to HTTP responses, and documented in references/kafka-workflows.md.
vss-rtvi-vlm environment for topic names.In a full VSS alerts real-time profile, use the existing VSS Kafka container mdx-kafka for CLI checks and final incident-consumer commands. For standalone validation, use a broker that advertises ${HOST_IP}:9092; never stop or replace a pre-existing broker without user confirmation.
Common causes: 400 for invalid request shape or model id, 401/403 for missing or wrong bearer token, 404 for deleted files/streams or unsupported endpoints, 413 for oversized uploads, 422 for schema validation, 429 for too much concurrency, 500 for inference/runtime failures, and 503 while startup is still in progress. Inspect docker logs vss-rtvi-vlm for service-side failures.
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-13 | fail→pass | 24,539 | 3,896 | -84% | 1 | 1 | 0% | 6,197 | 4,563 | -26% | 0 | 0 | — |
case-01 | fail→fail | 18,336 | 12,612 | -31% | 1 | 1 | 0% | 3,715 | 6,681 | +80% | 0 | 0 | — |
case-02 | fail→pass | 7,977 | 5,679 | -29% | 1 | 1 | 0% | 1,486 | 5,016 | +238% | 0 | 0 | — |
case-03 | fail→pass | 13,389 | 9,207 | -31% | 1 | 1 | 0% | 2,998 | 5,859 | +95% | 0 | 0 | — |
case-04 | fail→fail | 20,568 | 4,119 | -80% | 1 | 1 | 0% | 1,067 | 4,586 | +330% | 0 | 0 | — |
case-05 | fail→pass | 4,509 | 1,904 | -58% | 1 | 1 | 0% | 805 | 4,119 | +412% | 0 | 0 | — |
case-06 | fail→pass | 12,014 | 7,280 | -39% | 1 | 1 | 0% | 2,274 | 5,267 | +132% | 0 | 0 | — |
case-07 | fail→pass | 8,296 | 5,281 | -36% | 1 | 1 | 0% | 1,519 | 4,957 | +226% | 0 | 0 | — |
case-08 | fail→pass | 10,672 | 4,570 | -57% | 1 | 1 | 0% | 1,966 | 4,693 | +139% | 0 | 0 | — |
case-09 | fail→pass | 8,396 | 4,466 | -47% | 1 | 1 | 0% | 1,655 | 4,618 | +179% | 0 | 0 | — |
case-10 | fail→pass | 5,565 | 3,390 | -39% | 1 | 1 | 0% | 937 | 4,370 | +366% | 0 | 0 | — |
case-11 | pass→pass | 8,091 | 2,725 | -66% | 1 | 1 | 0% | 1,452 | 4,232 | +191% | 0 | 0 | — |
case-12 | fail→pass | 6,783 | 2,273 | -66% | 1 | 1 | 0% | 1,192 | 4,160 | +249% | 0 | 0 | — |
case-14 | fail→pass | 8,237 | 3,536 | -57% | 1 | 1 | 0% | 1,657 | 4,335 | +162% | 0 | 0 | — |
case-15 | fail→pass | 7,565 | 2,334 | -69% | 1 | 1 | 0% | 1,263 | 4,146 | +228% | 0 | 0 | — |
case-16 | fail→pass | 12,112 | 5,737 | -53% | 1 | 1 | 0% | 2,036 | 4,688 | +130% | 0 | 0 | — |
case-17 | pass→pass | 7,554 | 2,140 | -72% | 1 | 1 | 0% | 1,391 | 4,186 | +201% | 0 | 0 | — |
case-18 | fail→pass | 7,757 | 4,505 | -42% | 1 | 1 | 0% | 1,482 | 4,628 | +212% | 0 | 0 | — |
case-19 | fail→pass | 13,078 | 5,162 | -61% | 1 | 1 | 0% | 2,358 | 4,677 | +98% | 0 | 0 | — |
case-20 | fail→fail | 7,147 | 2,960 | -59% | 1 | 1 | 0% | 1,391 | 4,359 | +213% | 0 | 0 | — |
case-21 | pass→pass | 3,270 | 2,000 | -39% | 1 | 1 | 0% | 612 | 4,051 | +562% | 0 | 0 | — |
case-22 | pass→pass | 2,407 | 1,625 | -32% | 1 | 1 | 0% | 419 | 3,952 | +843% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted, and 21 counted toward the lift figure. The other 1 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +68 percentage points is the difference between those two pass rates over the 21 comparable cases.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.