EAI Device-Edge-Cloud Collaboration Research: How to Deliver After Layering, Summary of the Ranking for 12 Robot Manufacturers

China’s shipments of humanoid robots are projected to reach 50,000 units in 2026; Morgan Stanley, which initially forecast only 14,000 units at the start of the year, raised its projection to 50,000 units in June - the second such upward revision this year. According to the report, approximately 80% of humanoid robots in 2025 were used for education, exhibitions, and data collection, while only 4% for industrial logistics, indicating that growth in shipments is not aligned with demand for productive applications. Goldman Sachs predicted in August 2026 that the average BOM cost of global humanoid robots will decrease by about 7% annually from 2025 to 2035. Based on this calculation, the cost of a single robot will drop from approximately USD27,700 in 2025 to approximately USD13,500 in 2035. The cost reduction provides conditions for the calculation of payback period, but the reliability of robots, delivery time and on-site integration still need to be independently verified.

Standards are also being tightened. GB/T 48317.1–.5 released in September 2026 will be implemented in April 2027. Latency, network outage, and reliability will follow a unified testing basis. Over the next two years, the focus will be on establishing an end-to-end engineering loop at the device level; deployment at the edge will scale in tandem with fleet density, while investment in the cloud will expand as meaningful data flows back.

Layout of 12 manufacturers: two paradigms at devices and three approaches at edge

Productive demand has yet to reach a significant scale. According to industry statistics, industrial logistics accounted for only 4% in 2025, while education, exhibitions, and data acquisition combined made up approximately 80%—implying that investment in the "device-edge-cloud" continuum still lacks a stable source of return. The differences in the layout of 12 manufacturers essentially reflect their respective judgments regarding where specific use cases lie and when they will reach maturity.

The layer at which inference runs determines latency and performance during network outages; the source of on-site computing power dictates delivery and replication costs; and the infrastructure supporting training and data determines whether capabilities can undergo continuous iteration. The three items combined constitute the actual layout of a manufacturer.

Among the 12 companies, 6 focus on device-side autonomy and 6 on hierarchical deployment, establishing these as the two dominant paradigms. Meanwhile, the paradigms of cloud-led orchestration and dynamic runtime partitioning—where tasks are distributed in real-time across edge, fog, and cloud resources based on current workloads—are not currently adopted by any of these manufacturers. The primary cause of differentiation lies in latency. Real-time control loops vary in cycle duration from 1 to 20 milliseconds: joint servo and whole-body control operate within 1–2 milliseconds, vision-motor strategies within 5–20 milliseconds, and the closed-loop motion control systems presented in various examples typically fall within the 4–10 millisecond range; in contrast, a single-step inference for a VLA model operates in hundreds of milliseconds. Millisecond-level planning and control cannot rely on public APIs, and non-real-time planning can only be deployed in the cloud or edge.

In addition to latency, it also depends on the capability to disconnect from the network. Of the 12 companies, 8 have already incorporated offline-operation capabilities into their architecture; for those relying entirely on cloud-based solutions, the only options during a network outage are to switch to a degraded mode or perform a safe shutdown. It should be clarified that "layering"—referring to whether the cloud or the edge participates in slow reasoning, planning, and multi-machine scheduling—is a distinct concept from the division of labor between the "cerebrum" and "cerebellum" within an entity (where the cerebrum handles high-level cognition and planning, while the cerebellum manages motor coordination). With the two paradigms each accounting for half, it is clear that keeping real-time closed-loop processes on the device has become an industry consensus; the only point of disagreement lies in which specific tasks should be delegated to the cloud or the edge.

Model architectures can be categorized into three types—proprietary foundation models, embodied layers built upon open-source foundation models, and external integration—each governed by a distinct set of trade-off considerations:

Proprietary foundation models: Weights and deployment locations can be flexibly configured, allowing world models and VLA models to be deployed either on the device or in the cloud, depending on the specific scenario. The trade-off is a significantly higher investment in pre-training, specialized talent, and computational resources—but this also yields the highest potential performance ceiling.

Open-source foundation models: By skipping the pre-training of the base model, resources can be redirected toward the embodiment layer, world models, and physical robot data. This offers a better balance between cost-effectiveness and controllability, though the pace of iteration remains subject to the release cycles of the underlying open-source foundation models.

External integration: Leveraging third-party foundational models to augment semantic understanding and interaction capabilities, while focusing in-house development on the embodied layer and engineering adaptation. This approach offers the fastest deployment, though semantic capabilities, API usage costs, and data closed-loop processes remain constrained by the third-party providers.

Regarding on-site deployment, the 12 manufacturers follow four distinct approaches: 4 manufacturers build their own edge clusters, 3 focus on on-site system integration, 1 procures network connectivity services from carriers, and 4 do not implement a separate edge layer. Self-built clusters require investment in data centers, dedicated networks, and maintenance; system integration is delivered on a project-by-project basis, connecting to warehouse management systems (WMS) or manufacturing execution systems (MES), without providing computing power; carrier packages guarantee bandwidth, slicing, and latency; and those without an edge layer rely on edge autonomy, network backhaul, and cloud-based training. The investment and replication costs differ among the four approaches, as does the pace of capability deployment.

The differentiation between training and data is reflected not only in the way of obtaining computing power, but also in the accumulation of data assets. According to public reports, XPeng has leveraged the Fuyao Intelligent Computing Center jointly built with Alibaba Cloud through a long-term exclusive agreement. AI2 Robotics has used 1,000-GPU computing power clusters since its establishment and established ecosystem cooperation with Baidu AI Cloud. Leju Robotics, Galaxea AI, and X Square Robot Technology adopt public clouds. UBTECH, AGIBOT, Galaxy, Unitree, and the Beijing Innovation Center of Humanoid Robotics focus more on physical robot data, synthetic data, and open source ecosystem.

The device determines which capabilities must remain in the robot, and also determines how much can be done on the edge and in the cloud.

Device: computing power determines the upper limit, and disconnection determines the lower limit

The device must handle two tasks simultaneously. Servoing, balancing, and obstacle avoidance, plus safe shutdown cannot rely on external links. VLA performs real-time inference on the device itself, without entering the millisecond-level action loop in the cloud. The price is that every time the computing power increases, power consumption, heat dissipation, battery and structural costs increase simultaneously. Mobile models also have to make a trade-off between intelligent capabilities and range - the upper limit of computing power is determined by the hardware, and the available time is determined by energy consumption. The two squeeze each other out.

Among the 12 samples, device computing power ranges from 100 to 2250 TOPS, and device model sizes span 250M to 13B parameters. There is no fixed scaling ratio between the two ranges. The same hardware can run at 250M or 13B; similarly, a 3B to 13B cerebrum can achieve 275 TOPS or 560 TOPS. The feasibility of deployment is determined by compression ratio, effective frame rate, single-step latency, and power consumption; the number of parameters is just one variable, and a larger number is not necessarily better.

Device computing power can be divided into three levels according to tasks. 100~200 TOPS: a 250M-4B cerebrum performs high-frequency execution and single-step crawling, and has limited open task generalization and multi-step deduction. 275~560 TOPS, a 3B-13B cerebrum and a 100M cerebellum represent the primary range for industrial cerebrum-cerebellum layering. The 13B cerebrum is near the hosting limit of 275 TOPS, with trade-offs manifesting in VRAM footprint, quantization processing and robot regression validation. 1035~2250 TOPS: multi-model concurrency and device slow inference are included, so that power consumption, heat dissipation and procurement costs increase accordingly.

Chip sources are highly concentrated. Of the 12 companies, the vast majority use NVIDIA Orin or Thor, while some resort to domestic AI platforms such as Horizon Robotics and Huixi. Rockchip is mostly used for motion control cores, and XPeng adopts itself self-developed AI chip. The main differences lie in domain controller design, computing power levels, and model compression levels.

UBTECH and Leju Robotics use Orin, Thor and domestic computing platforms in different models and solutions, which can cover multiple types of tasks. At the same time, they need to maintain multi-model adaptation and supply chain solutions. Galaxea Ai’s G0 Tiny 250M has achieved up to 10 Hz inference on Orin of R1 Pro.

The network disconnection strategy is divided into three states: 1. Full autonomy: the complete VLA resides on the robot. Ongoing tasks continue upon disconnection, while the scope of executable actions is restricted. 2. Degraded operation: the local cerebellum and pre-deployed skills are retained; new-task learning is suspended, and data is backlogged for upload once connectivity resumes. 3. Safe shutdown: real-time inference relies on external links; the robot enters a safe stop state immediately after losing network connection. Simply stating “offline-capable” does not constitute a strategy. It must specify which tasks continue, which degrade, and which must halt to assess real-world usability.

A single robot completes the real-time closed loop and only solves the first layer of problems. Multi-robot dispatching, visual review, and disconnection to keep alive require edge capabilities; whether to build an edge depends on fleet density first, and then combined with task cadence, data boundaries, and existing system judgments.

Edge: whether to build it depends on the density, how to build it depends on the form

The edge is the computing power layer close to the robot operation site. It can be deployed in factories, warehouses or stores, or can be placed in zone nodes by carriers. It should be distinguished that Leju Robotics' "Embodied Wing Link" 5G-A connection package provides network slicing, uplink bandwidth and latency guarantee. This counts as connectivity investment and shall be accounted for separately from edge computing capacity — the two feature different cost structures and must not be conflated.

Whether to build edge nodes mainly depends on four conditions: fleet density, task cadence, data boundaries and existing system.
Fleet density: The higher the density, the easier it is for the fixed investment of edge nodes to be diluted; when the fleet size is insufficient, the shared cost of a single unit will increase significantly.
Task cadence: The shorter the task beat and the more frequent cross-robot collaboration, the clearer the value of zone scheduling.
Data boundaries: When the original image is not allowed to leave the customer's site or a designated zone, local reasoning, desensitization, and caching become necessary.
Existing system: When there is an existing MES, WMS or computer room, the existing system should be connected first to avoid duplicative construction of computing power.

The reference benchmark is approximately eight robots per factory. Below this density, device-cloud two-layer or servitization nodes are more economical; above this density, the fixed investment in self-built clusters begins to be diluted. Node costs are dominated by fixed investment; the smaller the fleet, the higher the amortized cost per robot. This figure is derived from sample statistics within the report and serves as an evaluation baseline rather than an industry standard. Actual assessment further depends on task cadence and data boundaries.

Once you determine the required on-site computing power, you choose an investment model:
On-prem cluster: classified as CAPEX. It delivers all capabilities, yet site survey and joint commissioning are required for cross-factory replication.
Edge all-in-one: purchased by unit for fast deployment; a supporting platform is still needed for unified management.
Carrier multi-access edge computing (MEC): service-based billing; CAPEX converted to OPEX, suited for sites without machine rooms and multi-location deployment.

In addition to edge computing power, system integration and network connectivity are invested separately. System integration handles equipment and business system access, and communication packages provide connection and scheduling guarantee. Neither of them provides edge computing power. Manufacturers that do not have an independent edge layer rely on device autonomy and cloud training, and cross-robot scheduling and zone offline resilience are relatively limited.

On-site deployment involves five approaches: UBTECH, AGIBOT, and Zhejiang Humanoid Robot Innovation Center build their own edge clusters; Galaxea AI uses G-Fleet to manage physical robot clusters; ROBOTERA, AI2 Robotics, and Beijing Innovation Center of Humanoid Robotics focus on on-site system integration; Leju Robotics purchases network connection services from carriers; Galaxy, Unitree, XPeng, and X Square Robot Technology do not have independent edge layers.

UBTECH, AGIBOT, and Zhejiang Humanoid Robot Innovation Center have different edge deployment methods. UBTECH deploys edge clusters in the factory and connects to MES; AGIBOT uses OpenYurt to carry out edge management; Zhejiang Humanoid Robot Innovation Center focuses on order dismantling and multi-robot dispatch. Galaxea AI's G-Fleet is mainly responsible for policy distribution, parallel rollout, data feedback, automatic evaluation and version release. It is not considered that it has built its own in-factory edge computing cluster.

Leju Robotics adopts carrier network connectivity services. The "Embodied Wing Link" is billed on a monthly basis: the Standard Edition (RMB599) delivers a peak uplink of 300 Mbps with 200 GB high?speed uplink traffic; the Enhanced Edition (RMB999) offers a peak uplink of 500 Mbps and 500 GB high?speed uplink traffic, plus dynamic network slicing. The latency metric of 20ms@95% applies under the agreed service conditions for the Enhanced Edition. This method cuts upfront investment for private network deployment. If on-site edge compute is required, additional configuration remains necessary, together with assessment of carrier coverage, SLA (Service Level Agreement) and data isolation conditions.

Cloud: excluded from millisecond-level loops, its value hinges on data feedback

The cloud does not enter the action loop and is mainly responsible for tasks that can be queued, parallelized, and require long-term accumulation, including foundation training and post-training, world model creation and simulation, long-term evaluation and regression, as well as version and cross-factory operations. Together, these four functions form the basis for model operations.

There are four ways to invest in the cloud:
1.Self-built training clusters suit scenarios with stable long-term training demand, high sustainable cluster utilization, and data sovereignty requirements; they entail CAPEX, depreciation and O&M costs.
2.Platform subscription leases data, training, simulation and versioning tools from cloud providers. It fits prototype validation, standardized tasks, limited call volumes and use cases where data can leave the local domain.
3.Models/API services directly invoke pre-trained cloud model endpoints. This fits hundred-robot pilot deployments or standardized, infrequently changing tasks with low marginal investment, yet imposes stricter constraints on data egress and compliance.
4.Cloud providers, robot companies and system integrators divide responsibilities on a project basis. Joint delivery applies to governments, enterprises or single-scenario projects, with responsibilities, acceptance criteria and payment terms to be clarified upfront.

Training computing power can be built in-house or obtained through dedicated hosting or public cloud. According to public information, the Fuyao Intelligent Computing Center was jointly built by XPeng and Alibaba Cloud. Alibaba Cloud holds the hardware assets and XPeng uses the center exclusively thanks to a long-term exclusive agreement, with a scale of 30,000 physical cards and 10 EFLOPS; Leju Robotics and X Square Robot Technology have reached in-depth cooperation with Huawei Cloud and Alibaba Cloud. Galaxea AI has also publicly disclosed the application of Baidu Baige. Dedicated hosting and public cloud reduce the infrastructure investment of robot companies, focusing on effective computing power, utilization and engineering efficiency.

UBTECH has a total of approximately 11 million physical robot data entries, more than 80% of which comes from industrial scenarios; Maniformer (AGIBOT's subsidiary) has accumulated more than 1 million hours of robot-free real collection data through terminals such as MEgo (AGIBOT Maniformer's data collection terminal); Unitree WLA-1.0 uses approximately 2,500 hours of physical robot data; Galbot follows a training route based mainly on synthetic data and calibrated with a small amount of real data, and has proposed a configuration concept of 99% synthetic data and 1% real data, and has formed a dataset consisting of tens of billions of data entries.

However, massive data does not mean continuous model improvement. A closed loop has seven links: collection → cleaning → annotation → simulation → training → evaluation → distribution. If any link is interrupted, it will be difficult for the model to iterate with the scenario data. Breakpoints occur not only during collection, but also during authorization, caliber marking, and rollback after release.

Three types of governance determine whether data can be transformed into capabilities. Data governance defines requirements for data feedback, de-identification and usage. For industrial customers mandating raw data to remain within the park boundary, local de-identification, feature upload and private training become prerequisites. Evaluation governance unifies metrics for success rate, task cadence and on-site acceptance criteria. A given success rate must be tied to consistent definitions of materials, shifts and tasks. Version governance enables canary rollout, anomaly monitoring and rollback. The device retains weights and configurations of the previous release, so rollback does not rely on external networks.

World models shall also be split by functional responsibility: models for pre-action prediction must meet latency requirements aligned with motion cycles and are typically deployed on the device or on-site edge; models for data generation, long-horizon reasoning and offline evaluation are better suited for cloud deployment.

Four of the 12 companies have two routes running in parallel. The route selection depends on whether the tasks are converged and whether the fleet sustains continuous data feedback, independent of model naming. Once the device-edge-cloud three-layer stack is functional, commercial matters remain to be addressed: how these capabilities are documented in contracts and how acceptance is performed.

Acceptance: task cadence, offline operation and rollback are being incorporated into contracts.

In 2026, a large number of standards and policy documents were released. The Humanoid Robot and Embodied Intelligence Standards System (2026) was released in February. The 15th Five-Year Plan Outline, issued in March, proposes “advancing the coordinated development of cloud-edge-device”. In August, the ITU Telecommunication Standardization Sector approved a new project for the cloud-edge-device collaborative architecture standard. GB/T 48317.1–.5 was published in September and will take effect in April 2027, covering environmental perception, decision-making and planning, motion control, and manipulation. Additionally, requirements for embodied AI cloud protocols and technical specifications for cloud-edge-device collaborative systems are currently under development.

These documents reshape procurement criteria: buyers may contractually specify latency, offline continuity, line-level task cadence, MTBF (Mean Time Between Failures) and rollback time, with re-verification under real operating conditions.

Standards define how acceptance is performed. Scaled deployment requires three conditions to be satisfied simultaneously: production-grade demand, delivery capacity, and reliability.

Demand is the first threshold. For productive demand to be considered valid, industrial logistics needs to increase its share from 4% to 15%-20% and generate contracts with terms of three years or more. When demand remains unstable, edge and cloud investment should be aligned with confirmed orders, actual uptime and the volume of data feedback.

The second threshold is stable delivery. In 2025, only a small number of manufacturers could sustain a monthly output of 100 units for three consecutive months. To ship 50,000 units in 2026, the industry also should improve the consistency, production yield and continuous delivery capabilities of robots.

The third threshold is reliability. The entry-level MTBF target for robots is 500 hours, while high-end production lines require 8,000 hours — roughly a 16× gap.

Investment in edge and cloud should only be carried out after the scenario requirements are clear. If you build the edge first and then find the scenario, the nodes will be idle for a long time, and it is difficult to reduce the amortization of a single unit; if you rent the cloud first and then wait for data feedback, the training resources will be idle for a long time, but subscription fees will continue to be incurred. A common mistake over the past two years is to pay in advance for scale that has not yet arrived.

Investment should be carried out in three steps: first, run through the device closed loop, form a list of payable scenarios, and clarify requirements for task latency, cadence, offline resilience and accuracy; second, add edge capacity based on fleet density and finalize node and SLA templates; third, scale cloud investment against valid data feedback and prepare budgets for training and version management. Each step supports the next layer with returns from the previous layer.

The full life cycle cost of a single site includes at least six items: robot and device, edge and network, data assets, training and simulation, integration and replication, operation and version. Costs easily overlooked include data collection and annotation, site surveying and rework costs during site changes, and manpower costs for version maintenance. Customers opting for one-time investment often want to configure the device, edge, and cloud all at once, which can easily lead to over-configuration.

Robot companies must establish a regression testing mechanism and manage models, configurations, and map versions in a unified manner; cloud providers and carriers must complement deployment and operation and maintenance capabilities, and clarify on-site SLA; scenario customers must accept tasks based on task indicators and not just look at demonstration results. Whether an architecture is effective ultimately depends on whether robots can continue to complete measurable, acceptable, and replicable work.