---
title: Concepts
description: "Learn how OME's parts fit together: its architecture, OMENative, scheduling, models, runtimes, serving, rollouts and traffic."
---
New to OME? Read [How OME works](architecture/how-ome-works.md) first; the other pages build on it.
## Architecture
- **[How OME works](architecture/how-ome-works.md)**
How the OME manager, the model agent and OME's custom resources turn a model and a runtime into serving pods.
- **[Deployment modes and OMENative](architecture/deployment-modes.md)**
OME runs InferenceService components as Kubernetes Deployments or on OMENative, which creates, updates, repairs and moves each replica as one unit. Opt in to OMENative, see how OME picks a component's mode, and read what OMENative creates and reports.
## OMENative
- **[OMENative overview](omenative/overview.md)**
OMENative runs each replica of an InferenceService component as an Instance, one pod or a leader and its workers, that OME creates, updates, repairs, moves and removes as one unit. Multi-node engines and decoders use it by default, and any component can opt in.
- **[Instances](omenative/instances.md)**
An Instance is one replica of an OMENative component, a single pod or a leader and its workers, whose identity, phase, operation and failures OME records on the component's InferenceReplica.
- **[OMENative update strategies](architecture/omenative-update-strategies.md)**
Choose how an OMENative rollout replaces an Instance's pods, by starting new ones first, recreating them or updating them in place, and pace it with partition, maxSurge and maxUnavailable.
- **[Instance restart policy](omenative/instance-restart-policy.md)**
Choose whether OMENative repairs only a failed pod or rebuilds its whole Instance, and see how a restart runs.
- **[Migration and transient scale](omenative/migration-and-transient-scale.md)**
OMENative moves an Instance to another node by starting its replacement first, and can run more or fewer Instances for a while without an edit to the InferenceService.
## Scheduling and capacity
The OME scheduler and Alfred are alpha. Their configuration and behavior can change between releases. The scheduler needs Kubernetes 1.35.
- **[Gang scheduling](serving/gang-scheduling.md)**
With the scheduler-plugins PodGroup CRD installed, OME creates a PodGroup for each multi-pod OMENative Instance, so a gang-aware scheduler places its leader and workers together or not at all.
- **[The OME scheduler](scheduling/ome-scheduler.md)**
An alpha second scheduler that places each gang of pods in one accelerator domain, and binds its pods only when the whole gang fits.
- **[Alfred](scheduling/alfred.md)**
Alfred, OME's alpha GPU cluster caretaker, recommends Instance moves when free GPUs fragment or a node turns unhealthy and, when you let it, asks OMENative to carry them out.
- **[Alfred policies](scheduling/alfred-policies.md)**
How Alfred's defragmentation and node-health policies find Instances to move, and how its arbiter and safety bounds decide which become recommendations or migration requests.
To divide a cluster's GPUs among teams with AcceleratorQuota, see [Set accelerator quotas](../guides/operate-ome/accelerator-quota.md).
## Models
- **[Base models](models/base-models.md)**
BaseModel and ClusterBaseModel tell OME where a model's weights live and which nodes get them; OME parses the model's architecture, size and capabilities.
- **[Fine-tuned weights](models/fine-tuned-weights.md)**
Serve weights fine-tuned from a base model, such as a LoRA adapter, from a zip file in OCI Object Storage.
## Runtimes
- **[Serving runtimes](runtimes/serving-runtimes.md)**
A ServingRuntime or ClusterServingRuntime describes how to run a model server: its pods, and optionally the models it supports, so OME can choose it for an InferenceService.
- **[Runtime inheritance](runtimes/runtime-inheritance.md)**
Write one runtime per engine, and keep what differs for each model or GPU in small child runtimes that inherit from it.
- **[Runtime revisions and pinning](runtimes/runtime-revisions.md)**
Pin an InferenceService to a snapshot of its runtime, choose when runtime changes reach it, and roll back to an earlier snapshot.
- **[Accelerator classes](runtimes/accelerator-classes.md)**
An AcceleratorClass names one type of GPU and the nodes that have it, so an InferenceService can run its engine and decoder on that type, picked by name or by policy.
## Serving
- **[InferenceService](serving/inference-services.md)**
An InferenceService names a model, a serving runtime or both, and declares the engine, decoder and router components that OME turns into workloads.
- **[Component autoscaling](serving/component-autoscaling.md)**
Each InferenceService component can carry its own autoscaler block, which picks HPA, KEDA, External or None and the metrics or triggers to scale on.
- **[Autoscaler policy](serving/autoscaler-policy.md)**
An AutoscalerPolicy is an alpha, reusable set of KEDA or HPA autoscaling settings that InferenceService components share by name.
- **[Benchmarks](serving/benchmarks.md)**
A BenchmarkJob runs genai-bench against an InferenceService with the traffic scenarios you choose, and stores the results.
## Rollouts and traffic
- **[Rollout groups](rollouts-and-traffic/rollout-groups.md)**
Rollout groups roll an InferenceService's OMENative components out as one, so prefill and decode change together, by canary, blue-green or rolling update, with metric-gated canary steps.
- **[Rollout policy](rollouts-and-traffic/rollout-policy.md)**
A RolloutPolicy is an alpha, reusable canary, blue-green or rolling-update progression that InferenceService rollout groups attach by reference.
- **[Ingress and external access](rollouts-and-traffic/ingress.md)**
How clients outside the cluster reach an InferenceService: the Service that OME creates by default, or the Kubernetes Ingress or Gateway API HTTPRoutes it creates when you turn on ingress.
- **[Traffic policy](rollouts-and-traffic/traffic-policy.md)**
Set an InferenceService's load balancing, session affinity and endpoint override in spec.traffic. OME writes them into the gateway's backend policy and reports the result in status.
- **[Traffic map](rollouts-and-traffic/traffic-map.md)**
A TrafficMap is the alpha routing table that OME writes for a multi-cluster InferenceService: each workload cluster's share of the requests, and the reasons behind it.