Build the Inference Stack Platform on Modelplane Docs

Define Hardware Classes

API: modelplane.ai/v1alpha1 · InferenceClass

An InferenceClass is a tested recipe for a GPU node pool. It bundles:

Devices: the node’s hardware as a list of Dynamic Resource Allocation (DRA) style devices, each with a driver, count, typed attributes, and capacity. The scheduler matches a member’s nodeSelector against these devices, and GPUs bind to pods through DRA.
Provisioning (optional): how to create a node pool of this class on a specific cloud. Classes without provisioning are for existing clusters where the pool already exists.

Different clouds and GPU types imply different classes. A GKE L4 pool is gke-l4-1x-g2. A bare-metal H100 pool is h100-8x-byo (no provisioning).

Register a Cluster

API: modelplane.ai/v1alpha1 · InferenceCluster

An InferenceCluster represents a Kubernetes cluster configured for model serving. Platform teams create these to provide GPU capacity.

Each cluster has:

A cluster source: GKE, EKS, AKS, Nebius, Vultr or Civo (Modelplane provisions the full cluster) or Existing (bring a cluster you manage yourself). See Supported Providers for the clouds and neoclouds Modelplane runs on.
One or more node pools, each referencing an InferenceClass for its hardware capabilities and provisioning recipe.
Labels for organizational metadata: tier, region, provider. These are the matching surface for ModelDeployment.clusterSelector.

Modelplane installs a serving stack on every cluster it manages, including existing clusters, which it assumes are solely for its use.

Set Up the Gateway

API: modelplane.ai/v1alpha1 · InferenceGateway

The InferenceGateway is the front door for inference requests: the address a caller sees. It speaks the OpenAI and Anthropic APIs and routes each request on to a cluster serving the model it asked for.

It runs on an InferenceCluster, named by spec.clusterName. The cluster it names can serve models too, or run the gateway alone.

Create as many as you need, one per cluster. A second gateway naming a cluster that already has one reports ClusterAlreadyHasGateway and doesn’t become ready. A gateway is where a request enters your fleet, so run one per place requests should enter from. spec.serviceSelector decides which ModelServices each one serves. Left unset, a gateway serves every service. Scoping a gateway to a region is how you express residency: label a service for the EU and it reaches only EU gateways, and from there only the endpoints it selects.

Drain a Cluster

API: modelplane.ai/v1alpha1 · InferenceCluster · ModelDeployment

Taking a cluster out of service, for maintenance or decommissioning, means telling Modelplane to stop scheduling there and, when you can’t wait for work to finish, to move what’s already running. You do this by tainting the InferenceCluster. It’s the fleet-level counterpart to kubectl drain on a node. Modelplane reschedules the affected replicas onto other clusters whose hardware fits, the same way it placed them to begin with.

Monitor the Fleet

Modelplane runs an OpenTelemetry collector on every inference cluster. It collects from every component Modelplane installs. This includes the inference server engine, inference gateway and Envoy proxy, router, and the GPU exporter your cloud provides. It renames each component’s series to a single modelplane_* vocabulary and exports them to wherever you say - any backend the collector has an exporter for, not only OTLP.

Supported Providers

Modelplane is built on Crossplane and shares its infrastructure providers, so the set of clouds and neoclouds it reaches grows alongside Crossplane itself. This page shows where Modelplane runs today and where it’s headed.

A provider can show up here in three ways:

Note

Provisioning supported. Modelplane creates and manages the whole cluster from an InferenceCluster, selected through provisioning.provider. GKE, EKS, AKS, Nebius mk8s, Vultr VKE, Civo K3s work this way today.
Bring your own supported. Register a cluster you already run with source: Existing. This works on any provider whose Kubernetes meets Modelplane’s requirements (Dynamic Resource Allocation and a recent Kubernetes version), so you can run on the providers below now, ahead of native provisioning.
Crossplane provider exists. A Crossplane provider is published for the cloud. That provider is the path by which native provisioning lands, so it marks where Modelplane can grow next.

Clouds and neoclouds

Listed alphabetically, spanning hyperscalers and GPU-specialist neoclouds. Each runs a managed Kubernetes service with GPU node pools, so the bring-your-own path covers them all today. Where a Crossplane provider exists, it’s the path to native provisioning.