[wkutak]

DO NOT MERGE

Summary

• Reasoner notebook: add --trust-request-mm-kwargs to the Cosmos3-Super-FP8 launch on vllm/vllm-openai:v0.31.0. Video requests send media_io_kwargs (num_frames, fps), and without this flag the server rejects every one with HTTP 400. Image requests were not affected.
• Quantization cookbook: pin nvidia-modelopt[torch]==0.44.0 in the README and the three notebooks instead of installing whatever is latest.

Follow-up to #329.

Why

A run of the Reasoner notebook on the published nvidia/Cosmos3-Super-FP8 with vllm/vllm-openai:v0.31.0 at TP=4, launch command as written, passed all image cells but failed all 10 video cells with HTTP 400. The server needs --trust-request-mm-kwargs to accept per-request media kwargs.

Validation

• Ran the Reasoner notebook against nvidia/Cosmos3-Super-FP8 at TP=4 on 4 B200 GPUs with vllm/vllm-openai:v0.31.0. All code cells ran without errors, the 12 video requests returned content, and the server log had no 400s.
• That run used a pre-merge copy of the notebook. The launch cell in main is built differently (MOUNTS array, $FP8_MODEL_DIR) but has identical vLLM arguments, and I applied the same one-line edit. It has not been re-run on the merged notebook.
• The modelopt pin has not been run. The saved outputs in the quantization notebooks still show 0.45.0 / 0.46.0 and need a re-run.

Notes

• Only the Super-FP8 launch cell is changed. The Edge and bf16 Super cells use the vllm/vllm-openai:cosmos3 image, which I did not test with the flag.

[lfengad]

Thanks for fixing the video-request compatibility issue. Could we please make the trusted-client requirement explicit next to this flag and bind the local notebook example to 127.0.0.1:8001:8000? vLLM documents this flag as appropriate only for trusted API clients, since per-request media/preprocessing overrides can increase CPU/GPU/memory consumption. The current -p 8001:8000 publishes on all host interfaces, with no API authentication configured in this launch command; if that port is reachable by untrusted clients, they can use those overrides too. The notebook requests already target localhost, so loopback-only publication plus a short trusted-client note would retain the intended fix without widening access by default. Remote serving could remain a separately documented, explicitly access-controlled option. Thank you!

[lfengad]

Following up on the existing inline note: leaving this unmerged while it is Draft and explicitly marked DO NOT MERGE. Please address the trusted-client/local-port boundary above, and clarify which validation results apply to the pinned ModelOpt 0.44.0 environment before lifting the hold; the description currently says the pin was not run and the saved outputs reflect other versions. This is not a claim of a demonstrated 0.44.0 API incompatibility, and no additional test file is being requested. Thank you!