From AI That Answers to AI That Acts
From AI That Answers to AI That Acts
AMD notes that AI is moving from the cloud into the physical world, and performance evaluation must shift from peak TOPS compute to end-to-end, system-level measurement from sensor input to physical action; average latency is not enough, as tail latency and jitter matter just as much. Robots need to hand perception and reasoning to GPU/NPU, real-time control to FPGA/adaptive SoC, and system coordination to CPU, building a distributed real-time architecture like the human body.
AI had its first big moment in the cloud. The next phase is in the real world.
The transition from cloud AI to physical AI is forcing enterprises to rethink their assumptions about performance. Metrics built for training and inference tell only part of the story when AI must perceive, reason and control machines operating around people. In these systems, performance becomes a system-level problem, reshaping how robots are measured, how they are designed and, ultimately, what computing architectures will power them.
AMD has a rich heritage in robotics spanning two decades inside industrial arms, autonomous mobile robots, surgical systems and aerospace platforms. Across these systems, we’ve delivered machine vision, sensor fusion, deterministic motor control and functional safety. AI builds on that foundation.
Changing Definition of Performance
Physical AI systems do not just produce answers. They take actions. That changes what matters: responsiveness, predictability, power, safety and the ability to operate reliably under real-world conditions. Timing is central to all of it.
A control decision that arrives late is not a performance issue. It’s a failure condition that can cause collision, instability or unsafe behavior.
With humanoids, this is especially clear. They are being deployed in industrial settings earlier than most of us anticipated and, increasingly, they are working near people.
In my conversations with robotics OEMs, the requirement I hear most often is not peak compute. It’s the ability to run advanced AI models alongside deterministic, real-time control – combining intelligence with time-bounded, predictable response at the system level. In the physical world, missing a timing window is not a delay – it’s an unsafe outcome.
Measuring the Wrong Thing
The industry is still optimizing for the wrong number. TOPS (trillions of operations per second) is an incomplete metric for physical AI. It tells you how much compute can be applied. It does not tell you whether a system can sense an event, make a decision and take the right action within a defined window of time.
That requires compute engines, memory, networking, sensors and software to work as one orchestrated system – with enough memory bandwidth to keep data moving where and when it’s needed. A fast model on one processor doesn’t make a fast system if data movement, scheduling or another stage causes it to miss its deadline.
That’s why physical AI needs to be measured end to end – from sensor input to physical action. Average latency isn’t enough. Tail latency and jitter matter because a single spike can destabilize a control loop.
Model benchmarks have the same limitation. You can plan all day, but if the robot misses the window to act, the quality of the plan is irrelevant. What often blows the timing budget isn’t the model. It’s everything between the stages: the queuing, scheduling, memory copies and data movement.
One Machine, Different Workloads
Physical AI is not a single workload. Perception and reasoning are throughput-oriented and map well to GPUs and NPUs. Real-time control is deadline-driven and requires deterministic execution, where FPGAs and adaptive SoCs excel. CPUs handle system coordination that keeps everything synchronized.
From the body to the brain, these workloads run simultaneously, but they solve fundamentally different problems that require different compute architectures.
Routing every sensor stream and control decision through one processor creates limits in bandwidth, energy and latency. Those are system-level limits.
Build Like a Body
Put the right compute on the right workload, close to the data and close to the action.
In practice, that means building a robot the way you would describe a human body. A brain that perceives, reasons and plans. A spine that carries time-sensitive communication across the system. Joints that execute motion deterministically. Hands that manage complex dexterity. Sensors at the edges.
The result is a distributed, real-time system composed of coordinated nodes rather than a single processing unit.
Safety Is a Property of the System
Whether these functions are centralized or distributed, safety depends on how the whole system behaves and, most importantly, how it responds when something fails.
That changes design decisions from the beginning: where decisions happen, how faults are contained and which functions must respond within strict real-time deadlines.
Redundancy. Graceful degradation. Local decision-making under global constraints. These capabilities help a system maintain controlled behavior, reach a safe state and, in many cases, remain operational even when its main AI compute fails.
This is an industry challenge, extending across robotics, automotive and industrial automation. It requires hardware, software and system architecture to work together. Safety doesn’t sit on top of the system; it defines how the system is built.
AMD helps designers build these architectures across adaptive SoCs and x86 platforms. Adaptive SoCs provide dedicated lock-step real-time processing and programmable logic for deterministic monitoring and control, supported by safety-certified silicon, according to IEC61508, ISO26262 and ISO13849, and certified design flows. Emerging work such as ISO/CD 25785-1 underscores the growing focus on system-level safety for dynamically stable industrial robots. These systems require predictable behavior across sensing, compute, control and fault response, making system architecture a foundational safety decision from the start.
On AMD x86 platforms, Xen, a lightweight hypervisor that isolates workloads from one another, can support mixed-criticality architectures by separating workloads with different safety requirements and providing controlled boundaries around memory, devices and shared compute resources.
AMD and the Xen community are advancing Xen toward safety certification on both AMD x86 and Arm platforms. These contributions extend beyond isolation to the requirements, testing, fault injection and evidence needed to support certification. Safety concept approval has been completed, and the work is progressing toward final certification.
What We Built
This system-level view is what shaped the AMD Kria™ AI solution for robotics, offering a portfolio of scalable system-on-modules:
Kria AI SOM and a robotics carrier card, powered by AMD Ryzen™ AI Embedded X100 Series processors.
AMD Kria™ AI Robotics Developer Platform, an open, integrated platform combining CPU, GPU, NPU and FPGA compute.
AMD Robotics Software Suite and the open AMD Robotics Partner Network.
Kria AI in the brain. AMD Versal™ adaptive SoCs in the spine. AMD Zynq™ SoCs in the joints and hands. AMD Spartan™ FPGAs at the sensors. Foundation Robotics and Generative Bionics are building with these today.
Third-party testing and analysis reinforce our belief that physical AI systems should be measured at the system level. The Kria AI SOM sustains 8,000 control decisions per second while delivering AI reasoning in under 100 milliseconds.1 In representative robotics workloads, AMD Ryzen AI Embedded configurations deliver up to 3.4x better real-time reliability for on-time control2 and up to 1.6x higher spare compute capacity3 compared with NVIDIA Jetson T5000. Separate analysis from mimik found support for up to 2.3x more concurrent agents.4
In robotics, “open” has to mean more than a standard on paper. The AMD Robotics Software Suite is an open, portable stack built on the AMD ROCm™ platform and the ROS 2 operating system, with support for PyTorch, ONNX and MoveIt. The Kria developer platform hardware specifications are open as well, giving customers the flexibility to use ODM partners and build around AMD silicon in the form factor their product requires without vendor lock-in.
Peak compute matters, but it only tells part of the story. Developers who optimize the whole system and map each workload to the right compute engine will build robots that perform reliably where it counts. Peak compute can make an impressive demo. System-level performance is what turns it into a product.
Source: AMD Chips and Compute · newsroom.amd.com