AI workloads run on customer compute.
Limit Platform schedules and executes AI workloads on customer-procured infrastructure. GPU and CPU. Batch and interactive. Single-host, cluster, or edge. The platform handles the orchestration; the hardware stays customer-owned.
// compute · customer compute · inside the perimeter
Customer compute, managed workloads.
AI workloads need real compute: GPUs for inference at scale, CPUs for data preparation, edge hardware for plant-floor or on-vessel deployment. The compute lives in the customer environment. The orchestration that manages it is the platform layer customers buy.
Limit Runtime schedules inference, jobs, agents, evaluations, and fine-tuning across the compute the customer has. Limit Deploy handles the rollout of those workloads and the platform itself across single-site, multi-site, and air-gapped environments. Workload identity ties back to Limit Core. Resource usage flows into Limit Trace.
Scheduling, isolation, observability.
- 01
Workload scheduling across heterogeneous compute
Inference, batch, evaluation, and fine-tuning workloads are scheduled across GPU and CPU pools, single-host or cluster, central or edge. Customer-defined priorities and quotas determine placement.
- 02
Tenant and workload isolation
Workloads are isolated by platform identity and by infrastructure boundaries. Single-customer deployments isolate by application, matter, or product. Cross-customer isolation is by deployment, not by tenant boundary.
- 03
Resource accounting in the evidence trail
Every workload's resource consumption, runtime, and outcome lands in the evidence store. Cost attribution, capacity planning, and incident review all read from the same data.
- 04
Edge and on-vessel execution
Workloads that need to run at the edge (plant floor, vessel, remote site) execute on edge hardware coordinated by the central scheduler when connectivity permits, autonomously when it does not.
The scheduler runs where the compute is.
Scheduler and worker components deploy inside the customer perimeter. Compute pools are customer-procured: bare metal, virtual machines, customer-managed Kubernetes. The platform does not bring its own cloud infrastructure.
For edge and disconnected operation, edge workers operate autonomously with periodic synchronization to the central scheduler when available. Failure of the central component does not halt edge execution.
- Compute pools
- GPU and CPU. Bare metal, virtual, or container. Customer-procured.
- Workload types
- Inference (interactive and batch), data preparation, evaluation, fine-tuning, agent execution.
- Isolation
- By identity and by infrastructure boundary. Cross-customer isolation is by deployment.
- Disconnected operation
- Edge workers operate autonomously; reconcile with central when connectivity returns.
This capability is one layer of the operating system. Every application uses it. Every customer perimeter that runs Limit Platform gets it. See the full architecture →
See it in your environment.
Walk us through the systems already in place. We'll show you how this layer fits.