Cosmos3 Nano Reasoner
Compare round-robin routing with per-video session affinity on eight H200 GPUs.
Deploy NVIDIA Cosmos3 Nano Reasoner as eight FP8 aggregated workers. Two matched targets isolate routing behavior: pure round robin and round robin with a 300-second per-video session-affinity TTL.
Each worker starts through the Cosmos3 NIM entrypoint. NIM profile selection
reads NIM_MODEL_TYPE=reasoner, NIM_MODEL_SIZE=nano, and
NIM_PRECISION=fp8, picks the matching model profile for the detected GPU,
and then launches dynamo.vllm because NIM_DYNAMO_WORKER=true. The FP8 Nano
model fits on one H200, so every GPU runs an independent replica. Each replica
keeps its own multimodal processor cache, which makes routing the only
difference between the two targets: it decides whether a video’s questions
reach a worker that has already processed that video.
Choose a routing profile
In a matched eight-H200 benchmark, per-video session affinity improved throughput at every tested concurrency (36% to 76% more requests/s) and latency at higher concurrency. See Measured performance.
Prerequisites
- A Kubernetes cluster with the Dynamo platform installed.
- Eight available H200 GPUs and a ReadWriteMany model-cache volume.
- An NGC API key with access to the Cosmos3 model artifacts.
Run commands from the repository root:
Cluster-specific settings
The manifests contain no credentials or node placement, and most clusters need no changes. Add a private Kustomize overlay only when you see one of these symptoms after deploying:
Both images are public on nvcr.io, so an image-pull Secret is only needed when
the cluster pulls through a private registry mirror. In that case, create it
for the mirror:
Copy the profile’s deploy.yaml into a directory outside the repository and
add a kustomization.yaml next to it. The patches apply only to the Worker
(spec.components[1]); keep only the ones you need:
Use your cluster’s GPU node label if it differs. In the deploy step, apply the
overlay with apply -k <overlay-dir> instead of apply -f .../deploy.yaml.
Populate the model cache
The model-download Job and serving workers use the same pinned image and
shared cache. If shared-model-cache already exists, keep it; PVC storage
class and access mode fields are immutable.
For a new cache, first replace the placeholder storageClassName in
model-cache.yaml
with a ReadWriteMany-capable storage class. Then run:
Deploy
Choose one profile and deploy it. If you created an overlay in
Cluster-specific settings, use apply -k instead
of apply -f:
The round-robin manifest does not set a session-affinity flag. The session-affinity manifest sets a 300-second TTL.
Verify
Forward the frontend Service and check that it serves the model:
Run curl in a second terminal. The response lists
nvidia/cosmos3-nano-reasoner.
Smoke test
The smoke test generates one synthetic 30-second video with FFmpeg, exposes it to the workers through an in-cluster Service, and validates a non-empty multimodal completion:
The final log line starts with Smoke test passed and includes the model’s
description of the video.
Benchmark
The AIPerf workflow
generates 200 synthetic 30-second, 2 FPS videos with FFmpeg before the
measured sweep, so no external dataset or credentials are needed. It then sends
20 questions for each video at every concurrency level: 4,000 requests with
exactly 128 output tokens each. For session affinity, AIPerf sends one
X-Dynamo-Session-ID value, generated per video, on all 20 questions about
that video; pure round robin sends no session-affinity header.
On eight H200 workers, the full sweep takes about 70 minutes for round robin and about 55 minutes for session affinity. Each concurrency level prints its AIPerf summary to the log when it finishes.
Measured performance
These are single-run AIPerf measurements from the eight-H200 deployments in this recipe. Each row represents 4,000 successful requests with no errors. Both profiles used the same 200 synthetic videos, 20 questions per video, and 128 output tokens.
At concurrency 16, session affinity produced 4,822 output tokens/s versus 2,738 for round robin. Request-latency p50 fell from 674 ms to 409 ms, and TTFT p95 fell from 760 ms to 134 ms. Each worker processes a video the first time it sees it and reuses it for later questions. Round robin spreads a video’s 20 questions across up to eight workers, so the video is processed on each of them, while session affinity processes it once.
The complete TTFT, request-latency, ITL, and throughput sweep is available in the benchmark README.