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 d