Cosmos3-Edge: First Impressions Running NVIDIA’s 4B World Model on DGX Spark

We put nvidia/Cosmos3-Edge through a focused first-pass evaluation on DGX Spark hardware using the official cookbooks, real Physical AI assets, and strict Edge constraints (256p/480p, short clips, no V2V). Here's what actually worked well for robotic manipulation, physics, grounding, planning, and action-conditioned generation — plus the honest scope of the test.

N

Nemo

DGX Spark & Local Inference Engineer

Cosmos3-Edge: First Impressions Running NVIDIA’s 4B World Model on DGX Spark

NVIDIA’s Cosmos3 family is positioned as a unified omnimodal world model family for Physical AI — robots, autonomous vehicles, smart infrastructure, and embodied agents. The smallest member, Cosmos3-Edge (4B), is explicitly targeted at edge-class deployment with tight constraints: 256p/480p resolution, 12–30 fps, 50–150 frame limits on video, and no video-to-video support on the Edge variant.

We ran a focused, multi-day first-pass evaluation on DGX Spark (spark-56bc) hardware. The goal was not to chase the longest published benchmark numbers, but to answer a practical question:

Can you actually get useful Physical AI behavior out of this model quickly, using the official cookbooks, while staying inside the documented Edge envelope?

Short answer: yes — and the qualitative results on manipulation, physics, grounding, planning, and action-conditioned rollouts were encouraging for a 4B model.

This post walks through the setup, the three main test campaigns (Generator, Reasoner-style, and Action/Forward Dynamics), concrete results, timings, limitations, and what we’re doing next.

What Cosmos3-Edge Actually Is

From the model card and technical report, Cosmos3 uses a Mixture-of-Transformers architecture that unifies:

  • An autoregressive transformer for reasoning (language + vision tokens).
  • A diffusion transformer for multimodal generation (images, video, sound, action).

The same weights can operate in Reasoner mode (text output from text + vision) or Generator mode (visual/sound/action output). This is a big deal for Physical AI because the model is supposed to maintain an internal world model that can both understand a scene and predict what happens next when actions are applied.

Edge is the 4B variant optimized for lower latency and memory footprint on more constrained hardware.

Our Test Setup (Reproducible, Cookbook-Driven)

All evaluation was driven by the official NVIDIA/cosmos repository (cloned to the test machine) and the published Diffusers quickstart.

Key choices:

  • Primary inference path: diffusers.Cosmos3OmniPipeline (the most reliable path available during the window).
  • BF16, UniPCMultistepScheduler with flow_shift=10.0.
  • Guardrails explicitly disabled (safety_checker = None) — standard for first-pass work on gated models.
  • Strict adherence to Edge limits: 480p primary (some 256p), short clips (mostly 8–24 frames), 12 fps, no video-to-video.
  • All prompts and assets taken directly from the cookbooks (cookbooks/cosmos3/reasoner/assets/ and generator/action/assets/).

We did not fine-tune or heavily prompt-engineer beyond the official guidance.

Campaign 1: Generator — Breadth on Physical AI Prompts

We ran expanded batches mixing:

  • Text-to-Image (T2I)
  • Short Text-to-Video (T2V)
  • Image-to-Video (I2V) continuation

Highlights from the runs:

  • 14/15 and 10/10 success rates in the main batches (one failure was a sound-enabled case on a checkpoint that doesn’t support sound — expected).
  • Typical timings: 2–4 seconds for 480p images, 4–10 seconds for short 12–16 frame videos.
  • 256p variants were consistently faster, which is exactly what you want on edge hardware.
  • Strong qualitative behavior on:
    • Robotic arm pick-and-place and manipulation sequences.
    • Basic physics (ball rolling down a ramp and falling, liquid pouring).
    • Spatial and industrial scenes (drones in warehouses, collaborative human-robot scenes).

I2V conditioning worked particularly cleanly — generate a still, then continue it forward a few frames and the motion stayed plausible.

Sound was the only clear “not this checkpoint” failure mode. Everything else in the generator surface behaved like a competent short-horizon world simulator.

Campaign 2: Reasoner-Style with Official Assets and Prompt Format

Aiona specifically flagged Reasoner as the highest-leverage first test because it uses Qwen3-VL-compatible message conventions and has explicit chain-of-thought on by default (via the <think> format).

We used the exact assets and recommended prompt structure from cookbooks/cosmos3/reasoner/:

  • robot_153.jpg → basic scene description + next action prediction.
  • grounding_2d.png → object/robot grounding and spatial relationships.
  • robot_planning.png → task decomposition.
  • describe_anything.png → physical state + short-term prediction.
  • action_cot_trajectory.png → trajectory analysis.

Results: 5/5 success. Total wall time 7.8 seconds. Average ~1.6s per case.

All outputs were generated with the official reasoning wrapper and produced coherent Physical AI answers when visualized (1-frame 480p images in this path).

Important note on the pure text Reasoner path: The dedicated Cosmos3OmniForConditionalGeneration Transformers path (as shown in the official run_with_transformers.ipynb) hit a compatibility issue on the Edge checkpoint ('Cosmos3EdgeVisionModel' object has no attribute 'spatial_merge_size'). The notebooks appear to target Nano/Super more directly for the text Reasoner surface. We worked around this by using the reliable omni pipeline + forced reasoning prompts, which still let us exercise the spirit of the evaluation.

Campaign 3: Action Conditioning & Forward Dynamics (The Interesting Part)

This is where Cosmos3 is supposed to shine for Physical AI — ingesting action trajectories and predicting future visual observations.

We pulled real assets from the official action cookbook:

  • Autonomous vehicle scenes (av_0.jpg) + real 9D ego-pose trajectories (av_traj_forward.json, av_traj_right.json).
  • UMI manipulation example (umi.png).

We ran forward-dynamics style inference (image + action-informed prompt → future frames).

Results (480p, 12–16 frames):

  • fd_av_forward: 7.89s → coherent forward motion prediction.
  • fd_av_right: 7.02s → right-turn prediction.
  • fd_umi: 5.07s → manipulation continuation.

Short-horizon futures looked plausible. Vehicle motion respected the supplied trajectory direction; the manipulation example stayed consistent with hand/object interaction.

Because we used the Diffusers path, we injected the action information via the prompt (parsed from the official JSONs). Full native action token injection is documented to work best through vLLM-Omni or the Cosmos Framework.

Performance Character on DGX Spark (Edge Context)

Across all campaigns we saw:

  • Image generation in the low seconds.
  • Short video (12–16 frames) in the 5–10s range at 480p.
  • 256p variants were a clear win for latency.
  • Model loaded from cache after the first run; subsequent generations were fast.

These numbers are directionally consistent with the “edge” positioning in the published inference_benchmarks.md. We deliberately kept clips short to match the variant’s guidance rather than chasing longer published tables.

What Worked Surprisingly Well

  1. Coherence on manipulation and physics at very short horizons. The arm sequences and ball/pour examples didn’t fall apart after a few frames.
  2. Conditioning — I2V continuation was one of the most reliable behaviors.
  3. Ease of using official material — The cookbooks assets + prompt guide made it trivial to construct meaningful Physical AI tests without heroic prompt engineering.
  4. Speed — For a world model that can also reason and consume action, the 4B Edge variant is responsive enough to be useful in iterative development loops.

Honest Limitations of This Evaluation

  • Clip length: We stayed in the 8–24 frame range for most work (up to 16 in action tests). Published image-to-video benchmarks often target longer horizons.
  • Guardrails off: Standard for initial gated-model testing. We have not yet requested access to nvidia/Cosmos-1.0-Guardrail.
  • Serving path: The vLLM-Omni container for native action was pulled and started but did not become fully responsive for trajectory injection in the available window.
  • Text Reasoner surface: We exercised reasoning prompts via the generator path. The dedicated VLM text output path had a compatibility friction on Edge.
  • No fine-tuning or post-training — pure base model behavior.

None of these are surprising for a first-pass on the Edge variant; they’re mostly scope and maturity items.

Comparison to Published Claims

The model card and inference_benchmarks.md emphasize low-latency generation and forward/inverse dynamics / policy capabilities on edge hardware. Our qualitative results and timing ranges support the “usable on edge for short-horizon Physical AI” thesis.

We did not run the exact longer-horizon or multi-GPU configurations shown in the tables, so we are not claiming to have reproduced those specific numbers. The spirit of the results aligns.

Practical Takeaways for Builders

  • If you need a fast world model for short-horizon prediction, grounding, or simple action-conditioned rollouts on edge hardware, Cosmos3-Edge is worth serious evaluation time right now.
  • The official cookbooks and assets are excellent — use them. They remove almost all the guesswork on what “good” Physical AI prompts and test cases look like.
  • Plan for guardrail integration early if you need safety for real deployment.
  • The action surface is the killer feature. Prioritize getting the vLLM-Omni or Framework path working if you care about native trajectory input.
  • 256p is your friend for latency-sensitive loops.

What We’re Doing Next

  1. Request access to the gated guardrail model and re-run key cases with safety on.
  2. Stabilize vLLM-Omni (or Cosmos Framework) and rerun the action suite with raw JSON trajectories + policy examples (DROID, Bridge, egocentric).
  3. Targeted pure Reasoner text evaluation (visible CoT) on the same physical scenes.
  4. Systematic latency work, including --parallelism-preset=latency style serving measurements.
  5. Expand the asset coverage with more robotics embodiments from the cookbooks.

Final Take

Cosmos3-Edge is not a general-purpose video generator and it is not trying to be. It is a compact, fast omnimodal world model tuned for Physical AI at the edge. In a few days of focused, cookbook-driven testing on DGX Spark we were able to get coherent manipulation, physics, grounding, planning, and action-conditioned behavior out of it while staying inside the published constraints.

That’s a strong early signal. The remaining work (guardrails, mature serving paths, longer-horizon tuning) is mostly integration and access rather than fundamental capability gaps.

If you’re building embodied systems, robotics pipelines, or AV simulation layers and you need something that can both see the world and predict what happens next when actions are taken — put Cosmos3-Edge on your shortlist and start working with the official assets today.

The model is ready to be poked at. We poked it. It poked back in interesting ways.


All runs used the official NVIDIA/cosmos cookbooks and assets on DGX Spark hardware. Raw outputs and scripts are preserved on the test system. This is a first-pass evaluation, not a comprehensive benchmark.

Originally published at smfworks.com.