Most AI data centers now run heterogeneous GPU fleets, with several GPU generations side by side and often across different sites. Static schedulers place a job once and leave it there, even as GPUs heat up, degrade, or sit half idle. A single failing card can stall a weeks-long run, while underused servers keep drawing power.
kMotion is part of Federator.ai Cortex, ProphetStor’s full-stack AIOps platform for AI factories. Federator.ai Cortex predicts how every GPU, link, and facility will behave next. kMotion acts on those predictions, placing, rebalancing, and live-migrating training workloads across heterogeneous GPUs and data centers. It works hand in hand with the Megatron-LM integration, which adapts each training job to the GPUs it runs on, so jobs keep running without manual tuning or restarts.
ERIC-Aware Placement: The Right Place for AI Jobs
kMotion’s placement decisions are built on ProphetStor’s ERIC (Efficient Resource Interchange through Computation) Theorem. ERIC treats every placement as a trade-off between local computation and cross-network communication, and finds the lowest-cost option that still meets the job’s throughput, latency, and memory requirements. Before kMotion places or moves a workload, it weighs four costs at every candidate destination:
Computation
GPU generation, memory capacity, and current load, so work lands where it can run at full speed.
Communication
Thermal
Available thermal headroom at the destination, so jobs avoid hot spots and GPUs stay clear of throttling.
Sustainability
Carbon intensity of each site’s power supply, so flexible workloads can shift toward cleaner, more efficient capacity.
kMotion also spreads work across failure domains, so a single fault cannot halt an entire run. Each score combines a map of the site’s hardware with continuously updated telemetry, and the weights shift by workload type: a bandwidth-hungry training job and a compute-dense batch job will intentionally land in different places.
How kMotion Works
Continuous Hardware Awareness
kMotion maps every node’s GPU model, interconnect, and network capacity at deployment. Lightweight agents then stream live utilization and thermal data, so decisions reflect what the hardware is doing right now.
Rebalancing on the Fly
When some GPUs fall behind and others wait at sync points, kMotion detects the imbalance and has the Megatron-LM integration resize each GPU’s work, so no slow card holds back the job
Energy-Aware Consolidation
When utilization drops, kMotion consolidates workloads onto the most efficient GPUs and hibernates idle servers. If ERIC finds a lower-cost option in another data center, the job can move there over high-speed links.
Elastic Scaling During Training
GPUs can join or leave a running job. kMotion detects the change and notifies the Megatron-LM integration, which rebuilds the parallel groups and redistributes the model, so training continues with minimal interruption.
Predictive Live Migration
Every GPU Keeps Earning
GPU investments shouldn’t expire when the next generation ships. kMotion keeps mixed fleets busy by placing and moving work where each GPU runs it best, so older systems keep contributing alongside the newest racks. To train a single model across GPU generations, kMotion works with Adaptive Distributed Parallelism.
Frequently Asked Questions
What is ProphetStor’s kMotion?
kMotion is a Federator.ai Cortex solution for live workload migration across heterogeneous GPUs. It places, rebalances, and live-migrates LLM training workloads across GPU generations and multiple data centers, guided by predictive analytics, and works with the Megatron-LM integration to keep each job matched to the GPUs it runs on.
Can one LLM be trained across different GPU generations?
Yes. In Federator.ai Cortex, the Megatron-LM integration gives each GPU a share of the model and data matched to its speed and memory, so newer and older GPUs can train the same model. kMotion handles the orchestration: placing the job, rebalancing it as conditions change, and moving work off GPUs that are about to fail. See Adaptive Distributed Parallelism for details.
What is ProphetStor's ERIC framework for workload placement?
What happens when a GPU fails during training?
Federator.ai Cortex predicts most GPU failures 12 to 72 hours before they occur by watching for early warning signs such as rising temperatures, memory errors, and throughput anomalies. Once migration conditions are configured in advance, Martin FSD acts on its own when those conditions are met: kMotion migrates the affected workload to healthy hardware, the Megatron-LM integration rebuilds the training topology, and the job resumes from its saved state.
Can kMotion move workloads between data centers?
Yes. When Federator.ai Cortex detects that a site is underused or running inefficiently, ERIC weighs the cost of running the job elsewhere, for example where capacity is idle or power is cleaner. If another data center comes out ahead, kMotion snapshots the workload’s state, transfers it over high-speed links, and restores it at the destination site. Multi-data center orchestration is handled by AboveCloud.