Analysis of Deployment Patterns for Edge Hosted Multimodal AI in Cloud–Edge Robotic Systems Utilizing ROS 2

Abstract

Cloud-edge robotics combines on-board computing with cloud services to enhance the intelligence and scalability of robotic systems. However, professionals still lack guidance on how to package and deploy AI components. This article presents a comparative evaluation of four ROS 2 deployment patterns for cloud-edge robotic AI: monolithic containers, microservices, dynamic module loading and overlay workspaces. All AI inference components run on the edge node in every pattern, so the comparison characterises the packaging and lifecycle mechanics of an edge-hosted, orchestrated, delivered, and observed multimodal workload. The four patterns are deployed on a K3s cluster combining an NVIDIA Jetson AGX Orin edge node with two amd64 cloud nodes, and run an identical workload combining perception (YOLOv8-nano), visual reasoning (LLaVA-1.5-7B) and voice interaction (Voxtral-Mini-3B), with a deterministic LLaVA trigger ensuring identical contention across patterns. Deployment cost is measured under three explicit regimes, warm restart, image cache cold start and fully clean deployment, with means and 95 per cent confidence intervals over replicated campaigns, and runtime behaviour is characterised with queue wait and frame drop instrumentation together with a sensitivity sweep of the reasoning trigger period from 30 to 300 seconds and of the camera input rate. The results reveal a clear trade-off. The dynamic pattern hot swaps a module in the live process in 0.78 to 31.10 seconds depending on the module, which is about two orders of magnitude faster than the rebuild and redeploy cycle for the lightweight nodes but only about one order of magnitude faster for the two model heavy nodes, and it collapses the real-time perception path when several AI nodes share a single Python interpreter, a degradation that a controlled hybrid experiment and a GPU utilisation control attribute to single interpreter serialisation rather than to the reasoning schedule or to accelerator contention. The overlay pattern restarts an operating point on par with the monolithic baseline yet is the slowest to provision from scratch or to update because of its coarse layer granularity, while the process isolated monolithic and microservices patterns trade update agility for runtime robustness. The results show that no pattern dominates. The overlay pattern offers an operating point restart on par with the monolithic warm baseline and, once its per layer carrier is activated, the smallest recurring update payload, but the slowest fully clean deployment of the four patterns, and the runtime collapse of dynamic loading is specific to the evaluated all Python single process composition and persists across the whole range of trigger periods, so it reflects the composition rather than the workload intensity. Fleet-scale benefits discussed for the overlay pattern are extrapolations from a single-edge testbed rather than measured results.