NVIDIA Cosmos 3 RL Rollout Is Coming to SGLang: What We Know So Far

An open pull request in the SGLang inference server would quietly turn NVIDIA Cosmos 3 — the open-weights world model NVIDIA announced at GTC Taipei on June 1, 2026 — into something it is not today: an RL rollout engine. The PR, "[diffusion] RL rollout support for the Cosmos3 pipeline (rework of #30486)," was opened in the sgl-project/sglang repository on August 10, 2026. It is unmerged, its CI is failing on both test tracks, and the code lives only on the main branch. This is a what-we-know-so-far piece about an early signal, not a launch announcement: treat every rollout capability described below as unverified until the PR merges and a stable SGLang release carries it.

If you have not been following physical AI, here is the two-sentence version. NVIDIA Cosmos 3 is a Mixture-of-Transformers model family with a reasoning tower and a diffusion generator tower, released with open weights under the OpenMDW-1.1 license. SGLang already serves it for image, video, and — per the current SGLang docs — action generation. What the new PR adds is the other half of the story: the training-side loop in which a world model generates rollouts that a reinforcement-learning algorithm learns from.

What NVIDIA Cosmos 3 actually is

Cosmos 3 is NVIDIA's "open frontier foundation model for physical AI," unveiled during Jensen Huang's GTC Taipei keynote at COMPUTEX 2026. It consolidates what used to be separate models — scene reasoning, world generation, and action generation — into one omnimodal system. The architecture is a Mixture-of-Transformers with two towers: an autoregressive reasoner that interprets scenes and causal structure, and a diffusion-based generator that produces physically grounded images, video, sound, and action trajectories. Three sizes have been named: Cosmos3-Edge (4B), Cosmos3-Nano (16B), and Cosmos3-Super (64B), plus post-trained robot policies Cosmos3-Nano-Policy-DROID (16B) and Cosmos3-Edge-Policy-DROID (4B).

The model supports three action modes: forward dynamics (predict video from actions), inverse dynamics (predict actions from video), and policy mode (joint video-and-action prediction). NVIDIA's own figures — vendor-reported and not yet independently reproduced — include roughly 767 million images, 348 million videos, and 8 million action samples in the training mix, and a claim to the top spot among open models on seven leaderboards including Physics-IQ, RoboLab, and RoboArena. The company also reported that starting from the omni checkpoint raised RoboLab success from 28.1% to 36.8% versus starting from the base checkpoint. Those are NVIDIA's numbers, not verified results.

The gap SGLang is filling: serving versus RL training

Day-one SGLang support for Cosmos 3 covered the generation side: text-to-image, text-to-video, and image-to-video through OpenAI-compatible endpoints, using the native Cosmos3OmniDiffusersPipeline. The current SGLang cookbook also lists action serving — policy, forward dynamics, and inverse dynamics via the async /v1/videos endpoint — and lists Cosmos3-Nano-Policy-DROID among supported checkpoints, with one stated limit: action generation does not yet support CFG or sequence parallelism.

Serving action inference is not the same as training with RL. A policy being trained on robot or driving data needs a world model to generate rollouts — imagined future states the learning algorithm can treat as experience. NVIDIA's Cosmos-RL framework spelled out that architecture explicitly: policy replicas act as training instances, rollout replicas act as generation engines, and a single controller coordinates them with weight-sync, rollout, and evaluate messages over dynamic NCCL process groups. NVIDIA has said Cosmos-RL is no longer under active development because Cosmos 3 supersedes it — which makes the SGLang rollout path the practical way that loop gets built on open infrastructure.

What PR #34197 actually adds

The PR rebuilds an earlier, now-stale rollout attempt (#30486) on top of current main, incorporating pieces that have since landed separately — a sigma snapshot mechanism, a msgpack transport, and the fused-kernel migration that made an old shim obsolete. What remains is the Cosmos3-specific rollout support, reworked around SGLang's per-request rollout scheduler. Concretely, the PR introduces:

• A per-request rollout scheduler, bound through a new Cosmos3TimestepPreparationStage. By default the rollout scheduler inherits the serving sigma grid, so rollout noise levels match serving exactly; an explicit flow_shift selects a shifted grid instead, and grids are passed as explicit sigmas with shift set to 1.0 to avoid double-warping.

• Rollout denoising through a RolloutDenoisingMixin in the Cosmos3DenoisingStage: an SDE step driven by the request generator, per-step diffusion-trajectory capture, denoising-environment collection, and rollout postprocessing. The rollout path is text-to-video and text-to-image only — image-to-video and video-to-video conditioned-frame re-blending, plus action and sound modalities, are explicitly rejected for rollout.

• Trajectory plumbing: Cosmos3LatentPreparationStage stashes a seeded generator on the batch, and Cosmos3DecodingStage propagates rollout_trajectory_data to the output batch.

• Two WeightsUpdater fixes that matter beyond Cosmos 3. The first passes the param-mapping merge index as the shard ID so fused parameters like to_qkv and gate_up_proj do not narrow out of bounds — the PR notes Cosmos3 is the first fused-param model through the tensor-update path. The second adds a torch.cuda.ipc_collect() after tensor updates to avoid OOM when syncing large volumes, relevant for the 128 GB Cosmos3-Super weight-sync case.

There are new unit tests (test_cosmos3_rollout.py), and the PR reports the existing Cosmos3, scheduler-rollout, rollout-API, and disaggregated-role suites passing. None of that is proof of correctness — it is the author's own report on an unreviewed PR.

What is still unverified

This is a leak piece, so here is the honest ledger. The PR is open and not merged; both CI runs (Base and Extra) are failing; six code owners are listed for review and none have approved. All of the rollout behavior above is described in the PR, not demonstrated in a release. SGLang's stable install does not include it. The Cosmos 3 benchmark claims quoted earlier remain vendor-reported with no independent reproduction, and the SGLang docs still state that action generation lacks CFG and sequence parallelism. If you are deciding whether to build on this, the answer today is: do not wire a production training loop to it yet — treat it as a signal that the rollout path is coming, not as something that is here.

How you would actually use this today

Cosmos 3 is open weights: you pull nvidia/Cosmos3-Nano or nvidia/Cosmos3-Super from Hugging Face and serve it yourself with the SGLang main branch (pip install -e "python[diffusion]") or through NVIDIA NIM microservices. For action-mode serving, the current SGLang cookbook and the vLLM-Omni examples are where the working recipes live. Cosmos 3 is not something OrcaRouter hosts — it is self-hosted open weights, not an LLM-style API — so this article will not point you to a hosted endpoint that does not exist.

That said, most physical-AI stacks are not pure world model. A robot or vehicle system typically pairs Cosmos 3 with a frontier LLM that turns sensor context into goals and turns rollouts into decisions — the "imagine, then plan, then act" loop has an LLM in the middle. That planner half is the part you can already call as an API, and it is where a router earns its keep: one key for 200+ models, provider list price passed through with zero markup so a vendor price cut is live the same day, automatic failover if a planner degrades mid-run, and a routing DSL if you want several models answering as one. When the model you depend on is bleeding-edge, being able to swap the stable half of the stack without a code change is the de-risking move.

接下来看什么

The single highest-signal thing to watch is the merge status of #34197 and whether its CI goes green — that is what separates "SGLang can do rollout" from "SGLang is about to do rollout." Beyond that, the interesting threads are whether the rollout scheduler survives code review unchanged, whether vLLM-Omni's proposed World Models Memory Semantics for batched and forked rollouts becomes the standard way these loops are scheduled, and NVIDIA's Cosmos3-Edge push toward 15 Hz real-time control on Jetson Thor. If you are building a physical-AI training stack, this is the infrastructure that decides whether your world model is a demo or a training engine.

常见问题

When will Cosmos 3 RL rollout land in a stable SGLang release?

Unknown. The PR was opened on August 10, 2026, is unmerged, and has two failing CI runs. It does not exist in any stable install yet. Watch PR #34197 for review approvals and a green CI; those are the necessary first steps before a release could carry it.

Does the rollout path mean Cosmos 3 trains policies by itself?

No. The world model generates the rollouts — the imagined futures and trajectories that serve as training experience — but the policy update still happens in your RL framework. The SGLang work is the data-generation side of that loop, not the learning side.

Can I call Cosmos 3's action generation through a hosted API today?

You can self-host it through SGLang or trial it through NVIDIA's own NIM path, but it is not a standard hosted LLM-style endpoint, and no router we know of carries it. Cosmos 3 is open weights you run, not an API you subscribe to.