On November 4, at the Robotics and Embodied Intelligence Forum of the 2026 World Internet Conference Wuzhen Summit, Cao Peng, chairman of JD.com's technology committee, delivered a keynote address. His assessment: physical AI has begun to deploy at scale, and the focus of industry competition is shifting toward three areas — computing power, data and use cases.

That shift deserves a closer look. For the past two years, the star of every embodied-intelligence launch event has been the robot body itself — how many degrees of freedom, how fast it can run, what kind of backflip it can pull off. Cao ranked his three priorities, put computing power at the top, and left the hardware body off the list altogether.

Computing Power Comes First Among the Three

Computing power tops the list, according to Cao, because once robots move into large-scale deployment, demand for both training and inference accelerates at the same time.

That logic differs from the demo stage. When a single robot shows off a capability, the compute cost is a one-off: train the model once, then load it onto the machine and let it run. But when hundreds or thousands of robots work simultaneously across different settings, each one continuously generates data that needs processing. Inference becomes a standing cost, and one that scales with the number of units deployed.

He noted that domestic computing power clusters are maturing and cloud-edge-device coordination keeps improving, providing physical AI with a low-latency, high-reliability cloud foundation. The key word there is foundation — meaning computing power is no longer something a single company solves behind closed doors, but a layer of infrastructure the whole industry shares. A robotics company can hardly build its own cluster, and the kind of shared computing power available to it directly determines how large its models can get and how fast it can iterate.

Why Robots Need Compute Across Cloud, Edge and Device

Cao's reference to cloud-edge-device coordination maps onto something quite concrete in robotics.

The cloud handles training, model iteration and fleet-wide orchestration. That workload is compute-heavy but latency-tolerant: what one robot learns today can be aggregated and trained overnight, then pushed to every robot tomorrow. The edge handles inference that demands real-time response but moderate compute, such as deciding where to move next based on the current camera feed. The device handles the minimum safety-critical judgments — if the network drops or the edge node fails, the robot still has to be able to stop itself.

All three layers are necessary because latency and compute each impose hard limits. Push every decision to the cloud and the round trip arrives too late for the robot to raise an arm and dodge an obstacle. Push everything onto the device and you run into caps on onboard compute and power draw: large models will not fit, and the judgments the robot can make stay narrow. So the three tiers are not design redundancy. They are a division of labor forced by physics.

That also explains why computing power lands first among the competitive priorities. A company controls its own hardware performance and costs. Cloud-edge-device coordination, by contrast, touches chips, networks, cluster scheduling and deployment density — not something any single robot maker can close on its own.

The Hard Part of the Data Loop Is Where the Data Comes From

The second subject Cao addressed was data and models. He described a closed loop: use cases generate data, data trains models, models return to the use cases, and the system keeps evolving from there.

The framing itself is not new. The difficulty is the first link in the loop. Models in the internet era enjoyed a ready-made windfall — web pages, code, books, text data sitting there waiting to be scraped. Embodied intelligence gets no such windfall. How a robot grips, releases, or adjusts its force mid-slip in the real world is not recorded in any corpus. That data has to be collected on site.

JD.com's embodied intelligence data collection center aims to gather more than 10 million hours of high-quality video of real human activity within two years, alongside more than 1 million hours of data from robots themselves. The tenfold gap between those two figures is itself informative: human video teaches the robot how to do something, while robot data calibrates how well it does it. Watching a person move a box reveals the sequence of motions, but not how heavy that box is, how slick the floor is, or at which angle the motor starts to shudder. Only the machine's own runs reveal that.

He also said the effort is being carried out jointly by JD.com's frontline staff and partners in its data ecosystem, with all collection conducted in strict accordance with laws and regulations to ensure it is lawful, compliant, secure and trustworthy. That caveat is not a formality. Filming on-site video means faces, workstations and operating procedures end up in frame; collecting robot data means plugging into a customer's production line. Neither escapes compliance costs, and both set the ceiling on how fast the data effort can scale.

Moving from Demos to Task Delivery Is a Question of Worst-Case Performance

The third subject was hardware, use cases and the supply chain. One line stood out for its practicality: robots need to move from functional demos to task delivery.

Demos and delivery are not graded on the same metric. A demo tests the ceiling — can it pull the task off once? If it works, the footage goes in the video. Delivery tests the floor — run it ten thousand times in a row, how often does it fail, can it recover on its own, and could it hurt someone. Warehouses are especially unforgiving on that floor: one missed grab might just drop goods on the ground, but one misjudged position could mean hitting a worker standing nearby.

That is why the phrase task delivery says more than deployment. Deployment can mean nothing more than wheeling a machine onto the floor. Delivery means owning the outcome — accounting for yield, uptime and maintenance costs. Cao talked about replicating these capabilities across tens of thousands of warehouses, factories, stores and homes. The hard part in that sentence is not building tens of thousands of units; it is getting every single one to run reliably on site.

Within the Supply Chain, Repair Is a Hard Requirement

The full chain he laid out runs: design, manufacturing, sales, delivery, repair. Most people discussing robots think of the first four. The fifth usually gets skipped.

Singling out repair lands precisely on the biggest difference between embodied intelligence and a pure software business. When software breaks, you ship a version remotely. When a robot breaks, it is a worn reducer in a joint, a loosened wiring harness, a degraded battery pack — someone has to show up with the spare part and swap it out. That requires spare parts inventory, service locations and response-time commitments, the full apparatus that traditional industrial equipment companies spent a century building.

So the real constraint on replicating across tens of thousands of warehouses, factories, stores and homes is not production capacity. It is the service network. A robot stranded 300 kilometers from the nearest service point, waiting three days for a part, breaks the customer's math immediately. That also explains why Cao framed the competition as a contest of systemic capability: point technologies can be bought, service networks cannot.

What a Three-Million-Unit Order Implies

The talk closed with a set of figures: over the next five years, JD Logistics plans to purchase 3 million robots, 1 million autonomous vehicles and 100,000 drones to meet robotics demand across logistics, offline retail, health care, industrial parks and other areas.

The word plans sets the boundary on those numbers; how much materializes in five years depends on whether the economics pencil out for each category of robot in its own setting. But even partial deployment would change the logic of procurement. At the pilot stage, suppliers compete on whether they can build the thing at all. At volume, they compete on yield, consistency and the cost curve. The first depends on R&D, the second on production lines and supply chain management. Those are entirely different competencies.

Cao stated his conclusion plainly: competition in physical AI is not just a contest of individual models or robot bodies, but a contest of systemic capability. The real advantage lies in whether a company can organize all these pieces so they run reliably, keep improving, and ultimately add up to productivity at scale — which takes sustained investment over time, and commitment from across the industry.

Read that line back against the three subjects he covered and the logic holds together: computing power is the foundation, data is the fuel, the supply chain is the outlet. None of the three sits inside any one company, and all of them have to be strung together through organizational capability. Whether that capability can support 3 million units within five years has no answer yet, but at least the question is now on the table.