Physical AI 推动硬件逼近极限

Key Takeaways:

• More compute alone won’t solve physical AI’s bottlenecks. Processing capability must be matched by memory bandwidth, efficient interfaces, sufficient power, and heat removal.
• Physical AI needs system architectures tailored to its end function and environment.
• Real-world deployment depends on rigorous validation that covers corner cases, understands behavior, and verifies safety.

The race is on to develop physical AI fit for widespread use, but building these sensor-powered systems will require engineering teams to address a variety of technical challenges concurrently and continuously.

Analysts predict significant market growth for physical AI, with the promise that autonomous systems will fundamentally reshape industries spanning transportation, manufacturing, medicine, energy, and more. PwC’s Strategy& projects that the global physical AI market could reach approximately €430 billion by 2030, reflecting the potential commercial impact of autonomous systems across multiple industries.

“Physical AI systems are expanding beyond automotive to robotics and drones, and the bottlenecks for development of these applications cover the entire system,” said Licinio Sousa, senior director of Interface IP for Automotive and Physical AI at Synopsys. “AI is expanding from the data center to the edge, and with machines such as robots, drones, and vehicles, all driven by the need for autonomy, privacy, personalization, faster response, and less reliance on the cloud.”

The list of technical challenges that need to be addressed is long and intertwined. Memory capacity and bandwidth need to be increased, latency and power consumption need to be decreased, product lifespans need to be stretched, and safety needs to be verified. And if that isn’t hard enough, addressing any one of these can create problems elsewhere.

Specialized architectures
Solving these system-wide bottlenecks requires highly specialized hardware and software that are optimized for specific use cases.

“We need to start talking about optimized, more tailored compute that you build for the specific workload, and this is where physical AI gets more interesting,” said Michal Siwinski, executive vice president and chief product and marketing officer, and general manager for Security Solutions at Arteris. “That workload needs to be highly optimized for the hardware. We’re basically going back to ASICs in the traditional sense of what ASICs were supposed to be — very application-specific, extremely optimized, versus more generic. Some of that is already starting. It will be interesting to see how the more nimble systems evolve for very specific applications between the software and the hardware and the workload, and keep evolving because the models are moving way faster.”

Autonomous robotics systems share some of the same technology found in self-driving vehicles, particularly in perception and control, but each physical AI use case adds unique challenges.

“Robotics is not a new AI stack,” Vasanthan Karunanithy, staff systems architect for Automotive at Micron Technology, said at the recent JEDEC Automotive Forum. “From an ADAS system, the robot inherits real-time perception, path planning, and motion control. From an intelligent cabinet, robotics inherits natural language understanding, contextual reasoning, and personal interaction. In embodied intelligence, the bigger challenge is running these two workloads together and then exchanging information at the end. So that is the commonality between these two segments. But there is also a difference that tells the scale of the channel. An autonomous vehicle operates in a relatively structured road environment and draws power from a larger source — the vehicle battery. But when you look at robots, they operate in an unstructured 3D environment. [A robot] also needs to maintain multiple degrees of freedom. It has to manipulate objects and maintain balance, and it has to understand the commands in the instructions. It has to do all this with a limited power source compared to automotive.”

Those distinctions vary considerably across applications. Autonomous vehicles operate within established transportation infrastructure, but they must respond to unpredictable road conditions. Mobile and humanoid robots, in contrast, may need to navigate less structured environments, coordinate manipulation and balance, and operate within much more restrictive power budgets. Meanwhile, industrial robots may operate in controlled environments with fixed electrical power. These differences make it hard to optimize a single architecture for every form of physical AI.

Source: Synopsys.

Designers must build system architecture with these requirements in mind from the start.

“As workloads and models evolve, we are already seeing purpose-built silicon designed to meet the specific needs of each class of machine,” Sousa said. “Our customers continue to address the need for advanced VLA (vision-language-action) models. In the hardware world, this translates to more intensive compute and AI engines. At the same time, the spectrum of use cases makes it harder for a single monolithic architecture, leading to a transition to chiplets where compute, AI, memory, and I/Os can be scaled using a UCIe interface based on specific use cases.”

Chiplets offer one potential path to scalable physical AI platforms, particularly when heterogeneous compute, memory, and I/O requirements justify advanced packaging. However, they also can ratchet up costs and complexity due to customized packaging, thermal management, and die-to-die communication. Monolithic SoCs may be preferable for smaller, highly integrated systems where power, size, and cost are constrained.

Those constraints apply to both hardware and software. “The sensors are going to be much more focused on use cases, and you need to make sure that you have good use cases, and it’s customized, and you need to have a software layer on top of it as well,” said Sathish Balasubramanian, head of product for EDA AI & Solido at Siemens EDA. “I always joke that everything involved in the real world is analog and we are trying to abstract it to digital, so one of the most important things is redundancy. Sensors have gotten pretty good. We can sense in terms of visual, thermal, pressure, anything. We have gotten good in terms of radar and everything else. What’s more important is making sure that the sensors can operate in the environment, and that environment needs to be captured in a way that it doesn’t make it doesn’t really degrade, or you have redundancy built in.”

Still, the effectiveness of redundancy can vary, depending on whether components can fail independently and whether the system can identify and respond to faults. Adding sensors alone doesn’t guarantee reliable operation, especially when environmental conditions can affect multiple sensors at once.

Tailoring the compute architecture to the workload or use case introduces tradeoffs, as well. “There is the question of how close the intelligence needs to be to the actual origination of where the sensing is happening, and there’s a push-pull,” said Yasmine King, corporate vice president and head of Automotive at Analog Devices. “If you have intelligence distributed throughout a system, that makes it more complicated to update. Centralizing allows one point of over-the-air updates, easy to patch and fix, but it can create latency issues when you need to react quickly to this data. In a vehicle, if a pedestrian runs out in front of your car, you need to be able to respond extremely quickly. So where you locate your intelligence is based on what sensory information you’re trying to gather, and how quickly you need to respond.”

Analog Devices’ Yasmine King speaks at Reuters Automotive 2026 Oct. 27, 2026.

The placement of intelligence is an architectural decision involving more than compute performance. It requires balancing response time, communication bandwidth, power consumption, updateability, as well as coordination of distributed components. Centralized compute may simplify management, while local processing can reduce communication delays and preserve essential functionality when connectivity is interrupted.

Physical AI’s memory wall
Memory capacity, bandwidth, latency, and energy consumption stand out as key chokepoints for physical AI, alongside potential supply constraints for some memory technologies. The challenge is designing a memory subsystem capable of feeding increasingly demanding AI workloads within tight power and thermal limits, not just adding a sufficient number of memory components.

“The billions of associated model parameters also need to be stored and transported across storage, memory, and processing elements,” Sousa said. “Today, this is referred to as the memory wall. As memory footprint continues to grow, DRAM needs an ultra-fast interface, such as LPDDR6, to no longer be a bottleneck to processing.”

Performance also depends on access patterns, latency, data reuse, cache capacity, memory-controller efficiency, and the energy required to move data. Increasing raw bandwidth may provide limited benefit if workloads are constrained by other parts of the memory hierarchy.

Workload-specific system design can help offset some memory burdens. “Coming up with right-sized memory, right-sized compute and redundancy, everything that needs to fit into your thermal and power envelope is going to be very key,” said Balasubramanian. “The most important thing is that size matters. You don’t need a 100-gallon tank in your Prius. You need a 10-gallon tank. That’s the analogy I use in terms of memory. You can manage it in a way that you don’t need a huge DRAM, but you have a pretty good cache and an SRAM built in. It can always store critical requirements in DRAM, but you can move everything else to flash or SRAM when needed. The memory path, in terms of cache coherency from DRAM to SRAM, to the actual compute, and to making the actual physical AI, is going to be very key.”

The trade-offs between these memory technologies are significant. On-chip SRAM and caches can provide fast access to frequently used data, but their capacity is limited by silicon area and cost. External DRAM offers greater capacity, while flash provides nonvolatile storage for models, software, and other information that doesn’t need to remain in active memory.

Moving information among these tiers can reduce some capacity requirements, but it adds transfer overhead and latency. Cache coherency, meanwhile, focuses on keeping copies of data consistent across caches and memory, rather than simply moving information between storage technologies, but that adds more overhead. So engineers must consider the working set, data locality, and access frequency when determining how much memory belongs at each level.

Automotive memory innovations will likely loom large in how the issue is addressed for physical AI.

“It’s very closely coupled to our automotive range at the moment, and we see the majority of requirements from the robotics side coming directly from the automotive side,” said Rob Fisher, senior director of product management at Imagination Technologies. “A lot of automotive players will now present their chips as automotive and robotics platforms, so the 4-, 6-, and 8-bit support are really going to benefit memory bandwidth and memory footprint of embedded edge-type applications. It’s less of a concern in data centers, but the impact is different. You can probably have a bigger model in a data center by using a smaller bit width on your words. In an automotive application and a robotics application, you’ll probably take the other side of that benefit, which is a smaller memory footprint. You’ll constrain your model to do exactly what you need it to do, and then you’ll reduce the amount of memory and bandwidth you have available to contain it.”

Lower-precision representations can reduce model storage and memory bandwidth requirements, making them particularly attractive for embedded AI. But the benefits depend on whether the accelerator efficiently supports the chosen numerical format and whether quantization preserves the application’s required accuracy. Formats such as 6-bit representations can also introduce packing or implementation overhead, limiting the gains achievable on hardware not designed for them.

Flash storage also plays play a critical role in managing memory for autonomous systems.

“DRAM is constrained in capacity, power, and availability,” Sousa said. “Faster storage bandwidth shortens load time, so the same DRAM budget can support larger models. These systems run continuously on batteries and often without active cooling, so every data transfer costs power and adds delay, making it necessary for each component — mechanical, electronic, and software — to limit power consumption and improve efficiency. Interfaces such as MIPI, UFS, LPDDR, PCIe, etc., have techniques built in to ensure fast transmission of bursty data and then transitioning to long low-power idle modes.”

Faster non-volatile storage can shorten model-loading delays and, when paired with appropriate model partitioning or weight-streaming techniques, allow systems with limited DRAM to execute workloads whose total model footprint exceeds available active memory. However, storage bandwidth alone does not increase the amount of data that can be kept in DRAM at any point in time.

The interfaces used to move that data also differ in their power-management mechanisms and operating characteristics. Their efficiency depends on the particular specification, implementation, transfer patterns, and opportunities to enter low-power states.

Physical AI’s memory demands could eventually justify new memory technologies or variants of existing ones, provided the market becomes large enough to support the investment.

“Memory is a critical technology, and it’s going to be needed in all the physical AI that’s out there,” said Steven Woo, fellow and distinguished inventor at Rambus. “What’s different about these markets is some of them are going to just leverage the memories that are out there, but it’s possible some of them could become so big in terms of market sizes that they may warrant their own type of memory or some variant of an existing memory. We saw that with HBM, for example. People were using other kinds of memories, and suddenly the market got big. And if you go back before LPDDR, phones were just using binned, carefully selected DDR parts that just happened to be low power. The market got big enough, and people said, ‘Well, let’s just make a special part.’ Physical AI has the potential to become a big enough market on its own, so that if the requirements vary enough, there could be another kind of memory.”

Whether such specialization occurs will depend on the scale and consistency of demand. Unlike data centers, physical AI spans applications with widely differing requirements for cost, capacity, endurance, bandwidth, temperature, and energy efficiency. That diversity may favor adaptations of existing memory technologies in some markets and purpose-built solutions in others.

Validating the edge cases
Ensuring a system behaves safely, including under rare and unexpected conditions, is another major challenge. Solving the validation problem is especially important as physical AI developers target integration into heavy machinery, medical devices, and other safety-critical technologies.

“The validation loop that we need to bring physical AI into before we get into any production is paramount, and I would say is the most important thing we need to do,” said Siemens’ Balasubramanian. “What happens if there is a huge power cut or there’s an earthquake, and your fiber optic cable is cut from the outside world, or there’s a power cut? How do you manage that kind of a scenario on the edge? Having some kind of compute, some kind of memory, and some kind of intelligence close to the sensor is going to be very key, and the way people do that is by coming up with what they determine is the most important thing given use-case needs. In an industrial environment, when do I need to stop the assembly line? When do I need to know that I need to phone back or start the siren or anything else? Those are some of the things that need to be handled within a given sensor.”

These scenarios illustrate why safety-critical functions cannot always depend on continuous cloud connectivity or centralized decision-making. Local processing may be necessary to recognize faults, trigger protective actions, or place equipment into a defined safe state when communications or power systems fail.

But verification and validation address different parts of the problem. Verification establishes whether a design satisfies specified requirements, while validation examines whether the system behaves appropriately in its intended operating environment. Safety assurance may additionally require hazard analysis, fault-injection testing, evaluation of common-cause failures, and evidence of compliance with applicable standards.

Systems must therefore be designed to establish and verify trust throughout the relevant hardware and software stack, with assurance requirements matched to each use case.

“When we’re designing something for a wheelchair, we have specific needs, like any physical AI application,” said Owen Kent, co-founder of assistive robotics startup ATDev. “You have to be able to really put this hardware through the wringer in your quality management system and your third-party electromagnetic compatibility testing. Whatever hardware you use, whether it’s custom or not, you have to be able to verify safety.”

For developers, that means evaluating whether components function correctly in normal operation, as well as how the complete system responds to degraded sensors, communication failures, unexpected inputs, and other foreseeable hazards. Passing component-level tests is necessary in many applications, but it does not by itself establish system-level safety.

Conclusion
Physical AI’s practical limits extend across the entire path from sensing to action. Designers must match models and hardware to the task, move data within available energy and thermal budgets, and validate how machines behave when conditions or connections change. Increasing compute capacity only helps when the rest of the system can support it.

“Start with standards-based, low-power and proven interfaces along the whole path, from sensor to processor to actuator,” said Balasubramanian. “They give designers predictable behavior, ecosystem interoperability, and silicon-proven building blocks.”

A relevant example is the MIPI Camera Security Framework, which combines the Camera Service Extensions (CSE) 2.0 specification with complementary security specifications. CSE 2.0 supports data-integrity protection and optional encryption of CSI-2 camera data, while the broader framework addresses authentication of imaging-system components and secure-session establishment.

“It provides end-to-end security for camera data, covering integrity, authentication, and confidentiality from the image sensor to the SoC,” he said. “It also gives designers flexible options to minimize compute and traffic overhead, power, and latency, so security can be matched to the application rather than designed for the worst case.”

The distinction matters because confidentiality is optional, and the level of protection depends on the security services and configurations implemented. The broader framework lets developers balance protection against processing overhead, power consumption, and latency, rather than applying identical protections to every data stream.

It’s not enough to make autonomous machines more capable. They also must be dependable within real-world constraints. For physical AI, the architecture choices that conserve memory, power, and bandwidth must also support predictable behavior, resilience, and the safety assurance that widespread deployment demands.

Related Articles
Why Physical AI Is So Hard To Engineer
Integrating sensors, compute, and actuators into autonomous systems adds new challenges for chip design.

Scaling Data Movement For Physical AI
One size does not fit all.

Redefining Roles For Edge And Cloud AI
The race is on for localized intelligence.