NVIDIA China Developer Day 2026: Physical AI and Open Models

NVIDIA China Developer Day 2026: Unlocking Physical AI and Open-Source Models

NVIDIA China Developer Day 2026 offered a comprehensive look at the technologies shaping the next generation of artificial intelligence, from Physical AI and World Models to open-source foundation models and accelerated computing infrastructure. Held in Suzhou, the event attracted more than 2,000 developers for technical discussions covering robotics, synthetic data generation, model training, inference optimization, and production deployment.

China has more than 1.7 million registered NVIDIA developers, representing approximately one-fifth of NVIDIA’s global registered developer community. Over the preceding year, the number of active developers reached 300,000, making NVIDIA China Developer Day a valuable vantage point for understanding the evolution of the regional AI ecosystem.

Two themes stood out: World Models provide a foundation for training intelligent systems in simulated physical environments, while full-pipeline open models give developers greater control over how AI systems are trained, evaluated, customized, and deployed.

Together, these developments point toward a more integrated AI engineering stack in which compute infrastructure, training data, simulation environments, model architectures, and deployment tools operate as a cohesive system.

🌐 Physical AI and World Models: Learning Before Acting

#

Traditional large language models primarily process digital information, including text, images, and code. Physical AI extends intelligence into the real world, enabling systems to perceive their surroundings, understand physical interactions, make decisions, and execute actions.

Representative applications include robots, autonomous vehicles, drones, and industrial robotic arms. Unlike purely digital applications, however, Physical AI must operate under real-world physical constraints, where actions can damage equipment, consume resources, and introduce safety risks.

The central challenge is the cost of trial and error. Training a robot to manipulate unfamiliar objects directly in the physical world may require extensive hardware access, repeated experiments, and months of engineering work. Failures can damage equipment, while collecting enough diverse examples to support robust behavior remains expensive.

World Models address this challenge by learning representations of how physical environments evolve. Rather than requiring every experiment to occur in reality, developers can train agents to predict outcomes, evaluate candidate actions, and refine their policies inside simulated or generated environments.

Understanding Physical Laws and Predicting State Transitions

#

A useful World Model must do more than generate visually convincing scenes. It needs to capture meaningful physical relationships and predict how an environment changes in response to actions.

Three capabilities are particularly important:

1. Physical understanding: The model learns regularities governing object permanence, gravity, fluid motion, collisions, and other physical interactions.
2. State prediction: Given the current environment and a potential action, the model predicts a plausible future state.
3. Action planning: An agent evaluates alternative action sequences, estimates their consequences, and selects a promising trajectory before executing it in the physical world.

These capabilities allow developers to move part of the learning and planning process into a virtual environment. Instead of relying exclusively on repeated physical experiments, a robot can evaluate candidate behaviors through simulation, identify promising strategies, and transfer validated policies to real hardware.

The effectiveness of this approach depends on model fidelity, uncertainty estimation, and the degree to which simulated conditions reflect deployment environments. A visually realistic simulation is not necessarily physically accurate, so reliable transfer requires explicit validation.

Synthetic Data as a Core Capability

#

One of the most significant bottlenecks in Physical AI is the shortage of high-quality, action-labeled training data.

The internet contains enormous volumes of text, images, and video, but relatively little robotic manipulation data paired with precise action annotations, sensor measurements, and synchronized state information. Collecting these datasets requires specialized hardware, controlled environments, and substantial engineering effort.

Real-world data also tends to reflect scenarios that are easiest to observe. Rare objects, unusual interactions, extreme weather, and safety-critical edge cases may appear too infrequently to support robust training.

Synthetic data generation offers a way to expand this limited distribution.

NVIDIA Cosmos, a family of world foundation models and related development tools, supports Physical AI development through world modeling, simulation-related workflows, and synthetic data generation. By learning patterns from video and other training data, generative models can help construct diverse environments and plausible physical scenarios.

Engineers can vary scene configurations, lighting conditions, object properties, camera viewpoints, and environmental conditions to generate large numbers of training examples. When the generation pipeline is integrated with simulation and ground-truth extraction, these examples can include labels and state information that would be difficult or expensive to obtain through manual annotation.

The practical benefit is not simply a larger dataset. It is the ability to control the training distribution, systematically explore underrepresented scenarios, and generate targeted examples for specific failure modes.

Combining Real Data, Physics Simulation, and Generative Models

#

No single data source is sufficient for every Physical AI workload. A robust development pipeline combines real-world observations, conventional simulation, and generative world models, using each where it is strongest.

An effective engineering workflow uses these approaches as complementary components rather than competing alternatives.

Generative models can expand the diversity and realism of simulated scenarios. Physics-based simulation can impose explicit constraints and test whether generated behaviors are physically plausible. Real-world data can calibrate assumptions and validate the resulting policies against actual hardware.

The resulting loop can be expressed as:

1. Collect real-world observations to establish realistic operating conditions.
2. Build and calibrate simulation environments using physical constraints.
3. Generate additional scenarios with world models and synthetic data pipelines.
4. Train agents and evaluate candidate policies across a broad scenario distribution.
5. Validate promising policies in controlled physical experiments.
6. Feed observed failures back into the simulation and data-generation pipeline.

This approach can reduce the number of physical experiments required during development, improve coverage of long-tail scenarios, and accelerate the transition from simulation to real-world deployment.

However, synthetic data does not automatically eliminate sim-to-real gaps. Differences in contact dynamics, friction, sensor noise, actuator response, and environmental conditions must still be measured and addressed.

Simulation Infrastructure as the Foundation of Physical AI

#

The growing importance of simulation extends beyond individual robotics projects. It is becoming a foundational infrastructure layer for embodied intelligence.

In conventional AI development, the primary scaling constraints have included compute capacity, model parameters, and training tokens. Physical AI introduces another major constraint: the availability of diverse, reproducible interaction data.

Robots must learn contact dynamics, force propagation, balance, manipulation, spatial relationships, and environmental responses. These experiences cannot be obtained simply by collecting more text or static images.

Simulation provides a controllable environment in which agents can repeatedly interact with objects, encounter failures, and evaluate alternative behaviors. It also enables parallel execution, deterministic replay, and systematic testing of scenarios that would be expensive or dangerous to reproduce using physical hardware.

This shift is explored in the KAD article How Newton Is Becoming the CUDA of Physical AI Simulation.

The article examines why simulation is becoming a critical scaling layer for robotics, how GPU-accelerated physics engines support large-scale training, and why interoperability across simulation tools matters for the broader Physical AI ecosystem.

The underlying engineering principle is straightforward: simulation must evolve from an isolated research tool into a repeatable data-generation and evaluation system.

Newton and the Evolution of Robotics Simulation

#

A persistent challenge in robotics development is the fragmentation of simulation technologies. Different systems specialize in rigid-body dynamics, contact modeling, GPU acceleration, robot control, or complex articulated mechanisms.

This fragmentation complicates asset reuse, reproducibility, and the transfer of training pipelines across environments.

Newton is an open-source physics simulation initiative associated with NVIDIA, Google DeepMind, and Disney Research. It aims to bring together capabilities from different simulation technologies and provide a shared foundation for robotics and Physical AI workflows.

Its broader significance lies in the potential to improve interoperability between simulation environments, physics solvers, and GPU-accelerated training systems.

For engineering teams, the relevant questions extend beyond simulation speed:

• Can simulation assets be reused across tools?
• Are physical parameters represented consistently?
• Can the environment reproduce failure conditions deterministically?
• Does the simulator support the required robot dynamics and control interfaces?
• Can training results be evaluated consistently across simulation and real hardware?

These capabilities directly affect the scalability of synthetic data pipelines and the reliability of sim-to-real transfer.

As simulation infrastructure matures, standardized interfaces and reusable assets may become as important to Physical AI as optimized GPU programming frameworks have been to deep learning.

Closing the Sim-to-Real Gap

#

Simulation-based training is most useful when developers can measure how well simulated behavior transfers to physical systems.

A practical workflow should therefore combine:

• Physics calibration: Adjusting contact models, friction, mass properties, and other parameters to reflect observed behavior.
• Domain randomization: Varying selected environmental and physical parameters during training to improve robustness.
• Scenario diversity: Generating different object configurations, camera viewpoints, lighting conditions, and task variations.
• Systematic evaluation: Measuring success rates, collision frequency, task completion time, and robustness across representative conditions.
• Real-world validation: Testing trained policies on physical hardware under controlled conditions before broader deployment.

The objective is not to make simulation perfectly reproduce every physical event. It is to build a training and evaluation environment that captures the factors relevant to the target task and provides reliable evidence about policy performance.

For developers building robotics systems, integrating generative models, physics simulation, and real-world feedback is a practical way to reduce development costs while maintaining engineering discipline.

🔓 Open-Source Models: Why the Full Pipeline Matters

#

A second major theme at NVIDIA China Developer Day 2026 was the evolution of open AI models toward greater end-to-end transparency.

Bryan Catanzaro, NVIDIA’s Vice President of Applied Deep Learning Research, discussed the company’s approach to open models and the Nemotron model family. Nemotron is an important part of NVIDIA’s model ecosystem, particularly for developers interested in reasoning, synthetic training data, and model customization.

The distinction between releasing model weights and opening the full development pipeline is fundamental.

A conventional model release may provide downloadable weights and a basic inference interface. Although this enables local deployment and fine-tuning, it does not necessarily reveal how the model was constructed, what data shaped its behavior, which training methods were applied, or how its capabilities were evaluated.

A more comprehensive approach exposes five layers: architecture, training data, model weights, post-training recipes, and evaluation.

Architecture: Understanding the Model Design

#

Architecture determines how a model processes information and allocates computational resources.

Publishing architectural specifications, technical reports, and implementation details enables developers to understand design decisions and evaluate trade-offs involving latency, memory consumption, throughput, and capability.

For example, Grouped-Query Attention (GQA) allows multiple query heads to share key-value heads. Compared with conventional multi-head attention, this design can reduce key-value cache memory requirements and improve inference efficiency while retaining much of the model’s representational capacity.

For production systems, architectural transparency helps engineers assess whether a model is suitable for their hardware constraints and workload characteristics.

It also supports reproducibility: researchers can investigate design choices, compare implementations, and develop alternatives without relying entirely on undocumented assumptions.

Training Data: Making Data Pipelines More Transparent

#

Training data strongly influences model capabilities, domain coverage, and failure modes. Yet data transparency remains challenging because large-scale training pipelines may involve multiple sources, filtering stages, synthetic examples, and quality-control procedures.

A full-pipeline release can document data composition, processing methods, synthetic data generation, and filtering strategies to the extent permitted by privacy, licensing, and other constraints.

Synthetic data is particularly relevant to Nemotron-related development workflows. Larger models can generate candidate training examples, which are then filtered or verified before being used to train or improve other models.

This approach can increase the availability of structured reasoning examples, coding tasks, mathematical problems, and domain-specific instructions.

However, synthetic data quality depends on the generation and verification pipeline. Unfiltered synthetic examples may reproduce errors, introduce distributional biases, or amplify weaknesses in the models used to generate them.

For developers, access to the data-generation methodology is therefore as important as access to the final dataset. It enables controlled experimentation with filtering, quality thresholds, data mixtures, and task-specific coverage.

Model Weights: Enabling Local Deployment and Customization

#

Model weights are the most visible component of an open-model release because they allow developers to run inference, fine-tune parameters, and integrate models into existing applications.

The Nemotron ecosystem includes models designed for different capability and resource requirements. Model selection should account for parameter count, supported precision, memory footprint, inference throughput, context length, and deployment hardware rather than relying on model size alone.

Smaller models can be attractive for edge computing, robotics, and latency-sensitive applications where connectivity, power consumption, and memory are constrained. Larger models may be better suited to complex reasoning, knowledge-intensive workloads, and centralized inference.

Access to weights also enables organizations to maintain greater control over deployment architecture and sensitive data. Depending on licensing terms and operational requirements, inference can run within private infrastructure rather than sending every request to an external service.

It is important to distinguish open weights from unrestricted open-source licensing. Downloadable parameters do not automatically grant unrestricted rights to modify, redistribute, or commercially deploy a model. Developers should review each model’s license and usage conditions.

Post-Training Recipes: Reproducing and Improving Model Behavior

#

Post-training is often where the greatest practical differences between models emerge. Pre-training establishes broad representations, while subsequent stages shape instruction following, reasoning behavior, task performance, and alignment with deployment requirements.

NVIDIA’s open-model efforts emphasize sharing more of these training methods, including approaches involving supervised fine-tuning, reinforcement learning, synthetic reasoning data, and distillation.

One relevant technique is reinforcement learning with verifiable rewards (RLVR). In tasks where correctness can be checked automatically, such as many mathematical problems and coding benchmarks, a verifier can evaluate model outputs and provide reward signals during training.

This creates a more direct optimization target than relying exclusively on subjective preference labels. Nevertheless, the method is most effective when the task provides reliable verification signals. A test suite, for example, can confirm that code passes specified tests, but it cannot necessarily establish that the code is secure, maintainable, or correct under every possible condition.

Distillation provides another route to more efficient deployment. A smaller student model learns from a stronger teacher model, potentially reproducing useful capabilities at lower inference cost.

When training recipes are documented and released, developers can inspect hyperparameters, reproduce experiments, compare optimization strategies, and adapt the methods to their own domains. This is especially valuable when a production workload requires behavior that differs from the assumptions of a general-purpose model.

Evaluation: Making Model Comparisons Reproducible

#

Model benchmarks are only meaningful when evaluation procedures and results are sufficiently transparent.

A comprehensive release should document benchmark selection, evaluation protocols, inference settings, and known limitations. Where possible, it should also provide scripts or datasets that allow independent researchers to reproduce the reported results.

For enterprise deployment, evaluation should extend beyond headline benchmark scores. Relevant dimensions include latency, throughput, memory consumption, robustness, tool-use reliability, domain-specific accuracy, and behavior under distribution shift.

Developers should also distinguish between benchmark performance and production readiness. A model that performs well on a public reasoning benchmark may still fail to meet an application’s requirements for data privacy, reliability, or predictable execution costs.

Transparent evaluation makes it easier to compare models on workload-specific criteria rather than relying on marketing claims or isolated performance figures.

Why Full-Pipeline Openness Matters to Enterprises

#

The value of open models extends beyond experimentation. Transparency can improve auditability, support internal governance, and enable deeper customization of AI systems.

Three considerations are especially important.

Transparency and reproducibility: Access to architectural details, training methodology, and evaluation procedures enables researchers to scrutinize model behavior and investigate failure modes.

Compliance and auditability: Organizations in regulated sectors may need documented development processes, controlled data flows, and evidence supporting their risk assessments. Open development artifacts can help, although they do not by themselves guarantee regulatory compliance.

Production customization: Organizations can adapt models to specialized terminology, proprietary workflows, internal datasets, and deployment constraints. Local inference can also reduce dependence on external services and provide greater control over sensitive information.

These benefits are particularly relevant to Physical AI, biology, scientific computing, and industrial automation, where proprietary data, latency constraints, and domain-specific requirements often make generic cloud-based inference insufficient.

A small model might serve as a local planning component for a robot, while a larger model handles complex reasoning or supports research workflows in protein analysis and materials science. In both cases, the ability to control the model, training process, and inference environment can be as important as the model’s raw capabilities.

NVIDIA’s GPU platforms and CUDA software stack provide the underlying compute infrastructure for these workloads, connecting model development with accelerated training and inference.

⚙️ AI Infrastructure: From Model Training to Production Inference

#

Beyond Physical AI and open models, NVIDIA China Developer Day 2026 covered large-model training and inference, open-source runtimes, robotics, and AI infrastructure.

Technical discussions included Mixture of Experts (MoE), key-value cache compression, Cosmos 3, Isaac Lab, and NVIDIA Dynamo. These technologies address different parts of the AI development and deployment lifecycle, from model architecture and simulation to inference efficiency and orchestration.

MoE and Inference Efficiency

#

Mixture of Experts architectures route each input through a subset of specialized model components. This can increase total parameter capacity without activating every parameter for each token.

The trade-off is greater complexity in routing, memory management, and distributed execution. Effective deployment depends on workload characteristics, hardware topology, communication overhead, and the balance between active computation and model storage.

KV Cache optimization addresses another major inference bottleneck. Autoregressive models retain key and value tensors from previous tokens so they do not need to recompute the entire attention history for every new token.

As context lengths and concurrent requests increase, KV Cache memory can become a significant constraint. Compression, quantization, cache management, and memory-aware scheduling can improve serving capacity, although the achievable gains depend on model architecture, precision, sequence length, and workload.

For production systems, these optimizations should be evaluated together. Increasing model capacity does not guarantee better throughput if memory bandwidth, interconnect overhead, or cache pressure becomes the limiting factor.

Cosmos and Isaac Lab for Physical AI Development

#

Cosmos supports world-model-based development workflows, including the creation and use of synthetic environments and data for Physical AI. Isaac Lab provides a framework for robot learning and simulation-oriented workflows built around NVIDIA’s robotics simulation ecosystem.

Together with compatible simulators, datasets, and training infrastructure, these tools can help developers create repeatable experiments, train policies in parallelized environments, and evaluate behavior before deploying it to physical systems.

The engineering challenge is to maintain consistency across the entire workflow: simulation parameters, robot descriptions, control interfaces, sensor models, training objectives, and deployment configurations must remain sufficiently aligned.

A successful simulation pipeline should also incorporate systematic validation rather than treating simulated success as proof of real-world reliability.

NVIDIA Dynamo and Production Inference

#

Inference infrastructure becomes increasingly important as models move from research environments into high-throughput production services.

NVIDIA Dynamo is designed to support distributed inference serving for AI workloads. Systems in this category must coordinate request scheduling, GPU resources, model execution, and memory utilization while meeting latency and throughput requirements.

For developers, the practical objective is to move beyond optimizing an isolated model invocation and instead optimize the end-to-end serving system. That includes request routing, batching, cache behavior, parallel execution, and the interaction between compute and networking.

The appropriate configuration depends on the deployment target, model architecture, concurrency profile, and service-level objectives.

CUDA as the Compute Foundation

#

CUDA remains a central component of NVIDIA’s accelerated computing ecosystem, providing programming interfaces and tools for GPU-accelerated workloads.

The combination of GPUs, CUDA libraries, optimized inference runtimes, simulation frameworks, and model-development tools creates a software stack that supports multiple stages of AI development.

At the event, CUDA 13.4 was highlighted as part of the broader development ecosystem. Developers should consult the official release documentation for compatibility requirements, supported hardware, and upgrade considerations before integrating a new toolkit version into production environments.

Version compatibility across drivers, CUDA libraries, frameworks, model runtimes, and simulation tools is an important operational concern. Reproducible environments and explicit dependency management help reduce integration failures and simplify debugging.

For additional technical context, see KAD’s article Why NVIDIA CUDA Powers Modern Deep Learning. It explains how CUDA connects NVIDIA GPU hardware with deep learning frameworks, parallel computation, transformer workloads, and accelerated inference.

Understanding this software foundation is useful when evaluating how GPU compute supports both conventional model development and emerging Physical AI pipelines.

🚀 Conclusion: Toward a More Complete AI Development Pipeline

#

NVIDIA China Developer Day 2026 highlighted two complementary directions in AI engineering.

World Models and synthetic data address a fundamental limitation of Physical AI: the difficulty and expense of learning through real-world interaction. By combining generative models, physics-based simulation, and real-world validation, developers can expand training coverage, investigate rare scenarios, and reduce dependence on costly physical experiments.

The Nemotron model family and NVIDIA’s emphasis on full-pipeline openness address a different challenge: the need for greater control over how AI models are developed and deployed. Access to architecture, training data, weights, post-training methods, and evaluation procedures gives developers more opportunities to reproduce results, customize behavior, and build systems around specific operational constraints.

Meanwhile, advances in MoE architectures, KV Cache optimization, robotics simulation, inference infrastructure, and CUDA-based acceleration help connect these capabilities to production systems.

The broader lesson is that modern AI development increasingly depends on the integration of compute, data, models, simulation, and deployment infrastructure. No single model or tool solves every problem. The strongest engineering workflows combine these components into a measurable, reproducible pipeline that can be optimized for real application requirements.

As Physical AI matures and open-model ecosystems continue to evolve, developers will have more opportunities to build systems that learn in simulated environments, operate under real-world constraints, and remain adaptable throughout their deployment lifecycle.