Your robot cannot be intelligent, rapid, and unrestricted all at once. Evolution has already addressed that.

      Here is a constraint that few individuals involved in the construction of physical AI openly acknowledge, despite the fact that they are all grappling with it in silence. A robot's intelligence aspires to achieve three simultaneous goals: it wants to be intelligent, meaning it possesses reasoning abilities akin to a frontier model in unfamiliar situations; it seeks to be swift, meaning it reacts within the precise and deterministic timing required by a physical control loop; and it desires to be autonomous, meaning it continues to operate when the network fails, the warehouse Wi-Fi disconnects, or when the machine operates in areas without signal coverage. You can only choose two of these on a single piece of computing hardware.

      In specific terms, bounded autonomy is achievable. Industrial arms, drones, and limited autonomy systems can operate swiftly and offline because their tasks are sufficiently narrow. The trilemma challenges frontier models: integrating frontier-scale general reasoning, real-time deterministic responses, and full offline autonomy into a single power-constrained system is unfeasible for the same control loop.

      A frontier-scale model is intelligent, and if it streams its sensory data to a data center, it can also process data quickly, but it becomes dependent on a network and thus loses its autonomy. By reducing that model to fit within a 15-watt embedded module, it becomes both fast and autonomous, but sacrifices its level of intelligence. Running a large model in the cloud and querying it occasionally provides intelligence and autonomy, but lacks speed. There are three corners, but only two can be chosen at any given time. I have come to refer to this dilemma as the embodied trilemma, which I believe is the fundamental reason the edge/cloud question represents the most challenging architectural decision in robotics. Many teams regard it as a deployment detail, but it is more akin to a law.

      This trilemma is not merely a trend or a fleeting hardware restriction that can be waited out; it arises directly from principles of physics and power capacities. Currently, frontier reasoning quality resides in models that require tens of gigabytes of memory and datacenter-class processing units. Such hardware cannot be powered by a battery that a mobile robot can carry. Consequently, striving for "intelligence" entails making a choice: either transporting the data center to the robot via a network link, sacrificing autonomy, or accepting a smaller onboard model, compromising intelligence.

      Real-time control is even less negotiable. A wide-area network round trip introduces a latency of 30 to 100 milliseconds, and the variance in latency is more significant than the average. A control loop that is mostly fast but occasionally stalls is more problematic than one that is consistently average because controllers are calibrated for predictable timing. Once "speed" becomes reliant on a network, you forfeit "autonomy," as the network is now embedded in your control loop whether intended or not.

      Thus, the triangle remains intact. Techniques like quantization, distillation, and improved processing units may shift the corners, but they do not eliminate them. Anyone suggesting otherwise is often concealing which corner they have sacrificed.

      Now, let's put numbers to the triangle. It is useful to quantify the constraint, for once you articulate the timing, the corners cease to be abstract.

      Begin by examining latency. The total delay for a perception-to-action decision made in the cloud is the sum of several components:

      Lcloud = tcapture + tencode + tuplink + tinference + tdownlink + tdecode

      Conversely, when making the decision onboard, most of these components vanish:

      Ledge = tcapture + tinference,local

      The disparity between these two is not in inference time, which can actually be shorter in the cloud with superior hardware. The difference lies in the network latency, represented by tuplink + tdownlink, and more critically, its variance. An evaluated cloud-robotics setup over a high-speed wired connection exhibited round trips of roughly 30 milliseconds, while real-world applications often operate within 100 to 300 milliseconds, and wireless connections can yield even greater delays. On the other hand, edge processing reduces round trips down to approximately 1 to 5 milliseconds, as no data leaves the machine.

      Now, establish the rule that determines where a loop can be executed. A control loop with a timing budget of Lbudget can function on a specific computing path only if

      Lpath + k·σjitter ≤ Lbudget

      where σjitter represents the standard deviation of that path's latency, and k is the safety factor required for determinism. The k·σjitter term is a silent threat. Studies of teleoperation reveal that a link consistently holding a steady 100 milliseconds is manageable, but one fluctuating between 30 and 200 milliseconds results in erratic and unpredictable movements because the controller cannot anticipate unanticipated delays. The reflex loop’s budget is 1 to 10 milliseconds. No wide-area path meets this criterion. The mathematics, and not the architecture, prohibits it.

      Here’s a summary of the