Industrial Scaling of Physical AI: Why Deepx Says Open Workflows Decide Adoption Beyond TOPS

For industrial teams trying to move AI into cameras, robots, drones and connected machines, a successful demo is only the beginning. The harder test is whether the model can be engineered, manufactured, powered, supplied and maintained inside products that already have fixed power, thermal, cost and safety limits. In an interview with EE Times Asia, Lokwon Kim, founder and CEO of Deepx, argued that hardware remains the entry point, while software, ecosystem tools and production support determine whether a physical AI platform can scale.

Case lens: a three-stage market sequence

Deepx frames its strategy around a staged transition from first customer choice to a durable developer ecosystem. Kim said: “We see the physical AI semiconductor business developing in three stages. First, differentiated hardware performance must earn the customer’s initial selection. Second, a company must expand design wins and mass production, commercialize at scale, and build a defensible position through a strong portfolio of foundational IP. The third stage is to create an ecosystem in which developers can continuously build and deploy AI models and software using tools that are already familiar and broadly adopted,” Kim told EE Times Asia.

For industrial buyers, that sequence separates technical appeal from operational durability: a strong first selection does not automatically create repeatable mass production or a self-reinforcing developer community.

Why physical AI is not simply cloud AI at the edge

Cloud workloads often operate in comparatively standardized compute environments. Physical AI must work across cameras, robots, vehicles, drones, industrial equipment and other systems with widely varied power, thermal, sensor, operating-system and real-time requirements.

“Physical AI semiconductors do not yet have an undisputed incumbent with that level of ecosystem dominance. That makes this period particularly important. Whoever succeeds in building an open developer ecosystem and establishing a de facto standard early can shape the market for years to come,” Kim said.

Deepx’s response is not to rely on raw accelerator specifications alone. The company connects its NPUs to frameworks and platforms developers already use, including Ultralytics YOLO, Baidu PaddlePaddle and Raspberry Pi, while working on support for Nvidia Isaac applications. The company cites Nvidia and CUDA as an example of how hardware performance can be extended by a development environment, and states that its objective is to reduce the number of times software must be rebuilt as applications move from experiment to production.

Production reality: four major barriers

For many physical AI programs, proving that a model runs is the opening step, not the end state. Production introduces engineering requirements that can eliminate an otherwise attractive device.

A system must operate consistently across thousands or millions of units, meet a defined power budget, stay within thermal limits, support the required models, meet cost targets and provide predictable long-term supply and software support. Deepx groups the obstacles into four major barriers: power and thermal constraints, model compatibility, total system cost and production readiness.

Kim described the first obstacle as non-negotiable: “The first is power and thermal constraints. Physical AI products such as cameras, robots, and drones cannot accommodate data-center-class power consumption or cooling systems. If power and heat exceed the physical limits of the product, no other advantage can compensate. This is a non-negotiable constraint,” Kim said.

Model compatibility can also turn benchmark success into engineering friction. If converting and optimizing customer models reduces accuracy or forces extensive software redevelopment, the hardware advantage may disappear. Total system cost matters because customers review the complete bill of materials, including memory, host processors, power management, cooling and other components, not the NPU price alone. Production readiness requires dependable supply, manufacturing yield, quality control, long-term software support and evidence from actual production and field deployment.

“A semiconductor vendor therefore cannot stop at supplying a chip and demonstrating performance. It must help the customer run the required models, reduce system-level power and cost, and work alongside them from software integration and pilot production through quality validation and volume manufacturing,” Kim said.

Developer experience case: portability from prototype to industrial hardware

Physical AI projects rarely begin on the final production platform. Developers often start with a familiar model, a camera and an accessible development board. When the application is validated, the work moves to industrial hardware, and platform changes can create substantial engineering effort.

Deepx describes the Raspberry Pi collaboration as a way to reduce that transition: developers can validate vision models on accessible hardware, then move to industrial cameras, robots, gateways and production systems using the same Deepx execution environment. The company summarizes three lessons from early developer engagement: the entry point must be simple, with documentation, installation procedures, familiar workflows and technical support carrying major weight; hardware decisions can be influenced during prototyping, well before production; and an easy development platform is not enough unless developers can carry their models and software into industrial validation and production.

This gives portability a broader meaning. It is not simply moving an application between two boards, but keeping the developer's initial software investment intact throughout the product lifecycle.

Ecosystem architecture: multiple de facto standards rather than one platform

Deepx does not expect physical AI to settle on a single software platform in the way Android became a dominant smartphone operating system. A robot's hardware and operating requirements differ from those of a camera, vehicle, drone or medical device. Kim expects convergence around several de facto standards at different layers.

In that view, PyTorch, Ultralytics and PaddlePaddle are positioned around model development; ExecuTorch can support lightweight edge deployment; llama.cpp is becoming relevant for generative AI; and ROS 2 and Nvidia Isaac provide important assets for robotics development.

“The central question is not who owns every layer of the stack. It is who can connect different models, frameworks, and hardware platforms to actual silicon and production products with the least friction. Developers will not accept having to rewrite their software for every new processor,” Kim said.

The company’s stated goal is not to own every software layer. Instead, it wants its NPU and execution environment to act as a common hardware foundation across several ecosystems.

Channel case: 27 distributors and engineering support

Deepx’s ecosystem plan includes distribution. As it began mass production of its first commercial product, the company established partnerships with 27 distributors, including Avnet, WPG, Macnica and DigiKey, plus regional partners across several markets.

Kim argues that the distributor role changes as AI moves into industrial applications. Distribution is no longer limited to inventory, logistics and sales. Partners increasingly provide technical support, identify customers, engage in engineering and support design-in activity. Different applications also require different channels: robotics, machine vision, factory automation, security and healthcare have distinct procurement structures and technical-support requirements.

Market sequence: intelligent vision first, smart manufacturing next, robotics later

Among physical AI applications, intelligent vision appears closest to large-scale commercialization. Part of the reason is installed base. Security, video surveillance, transportation, retail, factory monitoring and machine vision already have extensive camera deployments, while many of the AI models used in these applications are comparatively mature.

The economic case can also be relatively direct. AI can automate continuous video monitoring or visual inspection, reduce labor requirements and identify incidents or defects faster. In many cases, companies can add an edge AI processor without replacing the entire camera or infrastructure.

Smart manufacturing is another near-term opportunity. Asia-Pacific's position within global manufacturing and electronics supply chains, combined with labor shortages and pressure to improve quality, is driving adoption in machine-vision inspection, worker safety, predictive maintenance and logistics automation.

Robotics may eventually represent the largest physical AI market, but it is considerably more difficult. A vision system mainly needs to perceive and analyze. A robot must perceive its environment, decide and execute physical action in real time, so an incorrect perception can become an incorrect movement or a safety event.

That raises the requirements for reliability, model robustness and system integration. Kim identifies real-world model reliability, power and thermal constraints, system cost, software compatibility, connectivity and safety as major remaining barriers. Physical AI models must maintain performance despite changes in lighting, vibration, weather, camera angles and obstacles.

The resulting architecture cannot depend entirely on cloud connectivity. A robot or industrial machine must keep making immediate decisions when network connectivity is lost or cloud responses are delayed. Data privacy can also keep sensitive industrial or personal information on the device. For these reasons, on-device inference is an architectural requirement, not merely an alternative to cloud computing.

Fleet operations: Federated AI and device management

In Kim's view, the next stage will require something resembling MLOps for distributed devices. Cloud AI benefited from mature workflows connecting model training, deployment, monitoring and updates. Physical AI remains more fragmented, with deployment and operational management often handled independently for individual devices and projects. That model will not scale when AI is deployed across millions of cameras, robots and industrial machines.

Kim identifies five requirements: secure cloud-device communication; a reliable fleet-wide model; software deployment with rollback mechanisms; simple tools for managing field equipment; and unified monitoring of device status, performance, power, errors and model accuracy.

Deepx describes the architecture as Federated AI, while distinguishing it from federated learning. Under this model, the data center handles training and centralized management, edge devices perform inference and control where latency, security and energy efficiency matter, and gateways connect the two where necessary. The company is working with AWS IoT Greengrass toward an environment where models trained in the data center can be securely deployed to devices, run locally on Deepx NPUs and managed centrally as a fleet.

The emphasis is less on moving all AI out of the cloud than on dividing workloads where computation makes the most sense.

Infrastructure and resource efficiency: the data points cited

That division matters because AI infrastructure is hitting physical constraints. Kim points to a widening gap between the pace of AI model development and the time required to build data centers and energy infrastructure. AI models can advance in months, while new power capacity and large data-center projects take years to build. He argues this mismatch will push more inference to the edge.

Data reference	Context in the interview	Industrial relevance
about a 100-fold improvement	Deepx says its internal comparison of data center GPU systems with on-device AI systems across power, servers, cooling and network resources found potential for about a 100-fold improvement in resource efficiency in some applications and system configurations.	Suggests architectural leverage when workloads are placed on devices rather than always on central infrastructure.
100-billion-parameter model simulation	In an internal architecture-level simulation involving a 100-billion-parameter mixture-of-experts model, with approximately 10% of parameters active at any one time, Deepx identified the potential for a single 5-W-class AI accelerator to generate more than 10 tokens per second.	Illustrates that larger models may operate in lower-power settings under defined conditions.
100-billion-parameter class workloads	Deepx’s workload research suggests that models at or below the 100-billion-parameter class could potentially handle more than 80% of inference requests in the physical AI scenarios it targets.	Under that scenario, the data center would handle remaining, more complex workloads, potentially allowing existing central infrastructure to serve more users or devices.

The company notes that the 5-W figure applies to the chip itself, while total system power varies with memory capacity, configuration and operating conditions. These figures are not presented as universal benchmarks.

In this architecture, billions of devices stop being simple endpoints waiting for instructions from centralized infrastructure and become distributed computing nodes.

The next computing layer: local inference and agent behavior

Kim sees the transition as analogous to the move from desktop computing to mobile computing. Low-power CPUs moved computation into handheld devices and created a mobility-focused computing model. Deepx expects ultra-low-power AI semiconductors to make a similar transition possible for AI, moving inference from centralized data centers into machines and objects operating in the physical world.

The company describes this emerging class of devices as Free-Token Machines, not because token generation is literally free, but because local inference can occur without a data-center charge for every interaction and without continuous dependence on network connectivity. As models become capable enough and power-efficient enough to run locally, cameras, robots and industrial systems can become agentic machines that perceive their surroundings, make decisions and act.

That does not eliminate data centers. It changes their responsibilities. The cloud remains the center of frontier-model training and large-scale computation, while local devices absorb workloads where latency, privacy, power efficiency and connectivity make centralized processing less practical.

Common misconceptions to avoid

• That TOPS and performance per watt settle the adoption decision. The article argues they remain meaningful but are not sufficient for physical AI.
• That a strong benchmark score automatically converts into a production product. If model conversion reduces accuracy or requires redevelopment, the advantage can vanish.
• That a working evaluation board equals production readiness. Customers also need supply, yield, quality control, long-term support and field evidence.
• That portability only means moving software between two boards. The broader issue is preserving developer investment across the product lifecycle.
• That physical AI simply moves all AI away from the cloud. The described architecture divides workloads between training in data centers and inference or control on devices.

Action guidance for managers, engineers and procurement teams

1. Map vendor claims to the three-stage sequence: initial selection, mass-production scale and ecosystem durability.
2. Measure the product envelope before comparing accelerators: confirm power, heat, real-time behavior and the physical limits of cameras, robots or drones.
3. Test model compatibility early. Track accuracy after conversion, optimization, latency, and the software redevelopment required.
4. Evaluate total system cost. Include memory, host processors, power management, cooling and integration work in the bill of materials review.
5. Require production evidence. Ask for supply continuity, manufacturing yield, quality-control processes, long-term software support and actual field deployment data.
6. Plan for fleet operations. Specify secure cloud-device communication, rollback-capable deployment, field-device management and unified monitoring before scale-up.
7. Choose channels that match the application. Robotics, machine vision, factory automation, security and healthcare have different procurement and support patterns.

FAQ

What does Deepx say is the main obstacle for physical AI?

The company points to fragmentation across power, thermal, sensor, operating-system and real-time needs. For Deepx, that fragmentation is one of the biggest obstacles to moving AI past proof of concept.

Why is intelligent vision the near-term use case?

Extensive camera installed base in security, video surveillance, transportation, retail, factory monitoring and machine vision, comparatively mature models and a direct economic case make intelligent vision closer to commercialization.

What is the relationship between edge inference and the cloud?

In the described model, the data center handles training and centralized management, edge devices perform inference and control where latency, security and energy efficiency matter, and gateways connect the two where necessary.

Why are distributors part of the story?

The article presents distributors as partners that can provide technical support, identify customers, engage in engineering and support design-in activity, especially as different industrial applications require distinct channels.

What is Free-Token Machines?

Deepx uses Free-Token Machines to describe local inference that can occur without a data-center charge for every interaction and without continuous dependence on network connectivity.

Final industrial perspective

The article’s broader point for WorldIndustrialWeekly readers is that physical AI will be judged less by isolated specifications and more by the practical distance between a developer workflow and a production line. For industrial systems, a device, a model, a bill of materials, a distributor relationship and a fleet-management process all have to fit together. If that path is too fragmented, physical AI remains a series of isolated projects; if it becomes repeatable, the operational consequences may extend from factory floors to robotics and distributed infrastructure.