Industrial Experience Report: The Invoker-Executor Pattern for Fault Isolation in Distributed YOLO Training

Persistent daemon processes that execute PyTorch training loops directly in their own address space are vulnerable to memory leaks, shared-memory exhaustion, and kernel OOM kills that cascade into host instability. This industrial experience report documents an observational design study of the Invoker-Executor pattern as implemented in the wyoloservice2 stack: a persistent Celery daemon (Invoker) that never imports CUDA, and ephemeral Docker containers (Executors) spawned per task with hard OS-level limits on memory (mem_limit), CPU (nano_cpus), and shared memory (shm_size). We qualitatively compare this pattern against direct execution, Ray, Kubernetes Jobs, containerd CRI, Kata Containers, gVisor, and Firecracker. The Invoker-Executor configuration successfully contained all memory failures over our production observations, logging cgroup OOM events without daemon interruption. Container boot latency was measured at a median of 440.0 ms (P95: 457.4 ms, sigma=12.8 ms; n=100), well below KVM microVM and Kubernetes baselines reported in the literature. The pattern is not a novel architectural invention; its contribution lies in the operational integration into a lightweight Celery-based MLOps stack that yields a pragmatic, low-overhead solution for GPU cluster stability.