需先装 CRD chart 再装资源 chart,顺序不能反;GPU 装箱调度器是独立的第二个 scheduler,需额外安装且工作负载要显式指定 spec.schedulerName;kubectl ome 插件不随控制器安装,需单独用 krew 或 make kubectl-ome 构建。
ome
ome-projectsApache-2.0活跃维护基于 Kubernetes Operator 的大模型推理部署引擎,统一管理 GPU 调度与模型生命周期,兼容 SGLang、vLLM、TensorRT-LLM 和 Triton 等主流推理后端。
Open Model Engine (OME) — Kubernetes operator for LLM serving, GPU scheduling, and model lifecycle management. Works with SGLang, vLLM, TensorRT-LLM, and Triton
helm upgrade --install ome-crd oci://ghcr.io/moirai-internal/charts/ome-crd --namespace ome --create-namespace
helm upgrade --install ome oci://ghcr.io/moirai-internal/charts/ome-resources --namespace omeREADME 未说明具体显存与 GPU 型号要求,仅要求 Kubernetes 1.28 或更新版本;GPU 能力通过 AcceleratorClass 资源描述,由集群侧提供。
Kubernetes Operator,统一管理 LLM 模型、GPU 调度与推理服务部署
基于 Kubernetes Operator 的大模型推理部署引擎,统一管理 GPU 调度与模型生命周期,兼容 SGLang、vLLM、TensorRT-LLM 和 Triton 等主流推理后端。
核心能力
- 用 CRD 把模型定义为一等资源并自动解析架构与参数量
- 按架构、格式、量化、参数规模加权打分自动匹配推理运行时
- 支持 prefill-decode 分离、多节点推理与金丝雀、蓝绿发布
- 提供 GPU 装箱调度与 AcceleratorClass 硬件感知选卡
- 内置 BenchmarkJob 做并发压测与性能对比
容易踩的坑
- v1.2.2OME 1.2.2最新正式版2026-08-05 · 2026-08-05 17:48 UTC
OME 1.2.2
1.2.2 is about shedding weight and making the model agent trustworthy under churn. Two subsystems leave the tree — the Knative-backed Serverless deployment mode and the in-repo web console, while model-agent status reconciliation gains UID fencing so a deleted model can no longer be resurrected by an in-flight write. Three new model families land alongside.
✨ Highlights
Serverless (Knative) Deployment Mode Is Removed (#681)
Serverlessis gone as a deployment mode, and with it the entire Knative integration — roughly 5.9k lines and 10 files:- Knative Serving is no longer a dependency — it drops out of the optional-components list entirely, and Istio is now needed only for Virtual Service ingress
minReplicas: 0no longer selects Serverless — it falls through toRawDeployment, so scale-to-zero is no longer available;RawDeploymentexplicitly does not support scale to/from zero- Removed components — the Knative Service reconciler, the serverless ingress strategy, the VirtualService builder, the
qpextqueue-proxy extension (binary, tests, and Dockerfile — the image is no longer built or published), and the queue-proxy metrics-aggregation pod mutator along with itsEnableMetricAggregation/SetPrometheusAnnotationannotations - Ingress config keys removed —
localGateway,localGatewayServiceName, andknativeLocalGatewayServiceno longer exist in the ingress config
Behavior on a stale annotation:
Serverlessis no longer a validome.io/deploymentModevalue, so the annotation is silently ignored rather than rejected — the InferenceService falls back todefaultDeploymentModefrom the controller config. There is no admission error to alert you, so audit for the annotation before upgrading.The In-Repo Web Console Is Gone (#686)
The web console no longer lives in this repository; deployment moves to
ome-console. This is the single largest change in the release at ~27.3k deletions across 155 files — the entireweb-console/tree, frontend and backend.- Repo plumbing is cleaned up with it: the
web-console/frontend/backendissue labels and labeler rules are removed, and the Pages workflow no longer builds the console - The npm-lockfile pre-commit hook added in 1.2.0 (#667) is retargeted rather than dropped — it now guards
site/package-lock.jsoninstead ofweb-console/frontend/package-lock.json
Race-Safe Model-Agent Reconciliation (#662, #680)
Two independent hardening passes on the model agent, continuing the deletion-race work from 1.2.0:
- A deleted model generation can never be restored — per-model ConfigMap mutations are now fenced by model UID. A write that was already in flight when deletion began can no longer repopulate the status cache with a stale generation, and a fenced UID is never restored or updated again (#680)
- Eviction and fencing are now distinct — node-local cleanup evicts the cache entry, because the same CR generation may legitimately become eligible for that node again; deletion fences the UID permanently. Conflating the two is what allowed resurrection (#680)
- Centralized optimistic-concurrency retry — ConfigMap mutations funnel through one helper that re-reads the latest object and retries on both
ConflictandAlreadyExists, replacing ad-hocRetryOnConflictblocks (#680) - Real downloads no longer queue behind startup revalidation — the normal-priority queue splits into separate download and revalidation lanes, and startup revalidation replays are classified into the revalidation lane. A node restarting with many
Readymodels no longer makes genuinely new downloads wait behind the replay backlog (#662)
New Model Families and Capabilities (#666, #687, #689)
- Kimi K3 —
vllm-kimi-k3, a vLLM runtime forKimiK3ForConditionalGenerationsafetensors checkpoints in the 1400B–1600B range, auto-selected at priority 1, 8 GPUs per replica, with MLA prefill v
- v1.2.1OME 1.2.12026-07-18 · 2026-07-18 01:31 UTC
查看更新说明
OME 1.2.1
1.2.1 is a small patch release about onboarding a new model family and removing a duplicated source of truth. ThinkingMachines Inkling becomes a servable model family end to end — a new audio-text capability, a capability rule that survives the vision short-circuit, and an NVFP4 runtime — while the GPU instance-type map collapses from two hand-synced copies into one.
✨ Highlights
ThinkingMachines Inkling Support (#672, #674)
Inkling is multimodal in a way the capability pipeline couldn't previously express: it takes audio and text and returns text. This release adds that capability and the runtime to serve it:
- New
AUDIO_TEXT_TO_TEXTcapability — added to theModelCapabilityenum, themodelconfigcapability set, and themodelparser→ OME capability mapping, so a parsed Inkling model surfaces the capability on its BaseModel status (#672) - Inkling capability rule — models whose type contains
inkling_mm_modelresolve to bothTEXT_TO_TEXTandAUDIO_TEXT_TO_TEXT; the rule is ordered ahead of the vision rule because the vision short-circuit would otherwise return early and silently drop the audio-text output (#672) model_max_lengthfrom nested configs — the nested LLM config is now consulted formodel_max_length, so checkpoints that only declare it on the inner config no longer parse as0(#672)tokenspeed-inkling-nvfp4runtime — a ServingRuntime forInklingForConditionalGenerationsafetensors checkpoints withnvfp4quantization,autoSelectenabled at priority 1, and a router +ome-containertopology requesting 4 GPUs per replica (#674)
One Instance-Type Map Instead of Two (#673)
The instance-type → short-name mapping was maintained in two places that had to agree: the model-agent ConfigMap and the enigma init container's environment. Adding a GPU shape meant editing both, and forgetting one was silent.
- Single source of truth — the mapping now lives only in
modelAgent.instanceTypeMapinvalues.yaml, rendered by a newome.instanceTypeMaphelper into both the model-agent ConfigMap (instance-type-map) and the enigma init container'sINSTANCE_TYPE_MAPenv var - Onboarding a GPU shape is one edit — add the shape to
values.yamland both consumers pick it up - Broader shape coverage — OCI, AWS, Azure, GCP, CoreWeave, and Nebius shapes are enumerated in one place, including B200 and B300
⚠️ Upgrading:
- Apply the updated CRDs before using
AUDIO_TEXT_TO_TEXT. It is a new value in a+kubebuilder:validation:Enum, so a BaseModel carrying it is rejected at admission until the new CRD is applied (#672). - Move any instance-type-map override into
values.yaml. If you patched the mapping directly in the model-agent ConfigMap, that edit is now overwritten on upgrade and does not reach the enigma init container — setmodelAgent.instanceTypeMapinstead so both consumers stay in sync (#673).
🚀 Features & Enhancements
AUDIO_TEXT_TO_TEXTmodel capability, wired through theModelCapabilityenum,modelconfig, and themodelparsercapability mapping (#672)- Inkling capability rule resolving
inkling_mm_modeltoTEXT_TO_TEXT+AUDIO_TEXT_TO_TEXT, ordered ahead of the vision rule so the vision short-circuit no longer drops the audio-text output (#672) model_max_lengthis now merged from nested LLM configs during model config parsing (#672)- New
tokenspeed-inkling-nvfp4ServingRuntime for NVFP4InklingForConditionalGenerationcheckpoints, auto-selected at priority 1 (#674) - Instance-type → short-name map single-sourced in
modelAgent.instanceTypeMapand rendered into both the model-agent ConfigMap and the enigma init container via theome.instanceTypeMaphelper (#673)
♻️ Maintenance
- Bump bundled image references to v1.2.0 across the Helm chart, the InferenceService ConfigMap, and the kustomize manager / model-agent overlays (#671)
📦 Container Images
The following container
- New
- v1.2.0OME 1.2.02026-07-14 · 2026-07-14 23:32 UTC
查看更新说明
OME 1.2.0
1.2.0 is about where model weights come from and what's still in the API. Pre-provisioned and air-gapped weights on shared storage become a first-class model source, the long-deprecated
predictorfield is finally removed, and the model-agent's task handling gets meaningfully sturdier under deletion, reuse, and churn.✨ Highlights
PVC-Backed BaseModels (#653, #654, #655, #656, #657, #658, #659, #668)
Until now a
pvc://BaseModel could be parsed but never acted on — nothing is downloaded for a PVC model, so it sat inImporting/In_Transitforever while the controller waited on per-node status ConfigMaps that never arrived. This release closes that gap and makes PVC a first-class,Ready-reaching model source:- Serve from shared storage — point a BaseModel or ClusterBaseModel at
pvc://…(CSI, NFS, Lustre) and it reachesReadywith no per-node download and no egress — ideal for pre-provisioned or air-gapped weights - On-demand metadata — a short-lived
ome-agent model-metadataJob parses the model on the claim and publishes a per-model status ConfigMap the controller reconciles, instead of writing the CR directly (#668) - Mounted read-only into serving pods — the claim is mounted at the model path with the correct sub-path; the per-node model-ready affinity is skipped since PVCs aren't node-scoped (#656)
- Validated at admission — a validating webhook rejects malformed or wrongly-scoped
pvc://URIs atkubectl applytime instead of surfacing later as aFailedstatus (#657, #658) - Condition-driven status — model status gains
Conditions,ObservedGeneration,LastReconcileTime, andSourceReachable/Readyconditions with PVC-lifecycle reasons (PVCNotBound,MetadataExtracting,Validated,ExtractionFailed, …) (#653) - Backend registry seam — the BaseModel controller is now a thin dispatcher over pluggable
Backends, so the PVC path stays fully isolated from the per-node download path (#654)
Namespacing: a namespaced BaseModel uses
pvc://{claim}/{sub-path}(its own namespace is implied); a ClusterBaseModel must scope the claim explicitly withpvc://{namespace}:{claim}/{sub-path}.The Deprecated
predictorField Is Removed (#661)spec.predictorand the entirePredictorSpectype are gone — serving is now configured exclusively viaspec.engine+spec.model(plusspec.decoder/spec.routerfor disaggregated setups)- Removes ~22k lines, the bulk being the predictor schema stripped from the InferenceService CRD and the regenerated OpenAPI / deepcopy / defaults
- Breaking: applying any manifest that still contains
predictornow fails (unknown field "spec.predictor"); GitOps/CI syncs of stale manifests hard-fail untilpredictoris removed from source - No disruption to running services — a stale
predictor: {}left on an existing object is pruned automatically on the next write (a reconcile,kubectl edit, evenkubectl annotate); no manual object cleanup required
Sturdier Model-Agent Task Handling (#650, #660, #663)
- Deletion and reuse no longer wait behind downloads — a dedicated high-priority worker path runs lightweight delete and same-path reuse/wait work so it isn't blocked behind long-running download/validation; deletion state is re-checked before starting work and before writing
Ready, so a stale queued download can't mark an already-deleted modelReady(#650) - Metadata-only spec updates stop forcing re-downloads — parser-populated fields (model type, framework, format, capabilities) no longer trigger a
DownloadOverride; storage, label/annotation, and TensorRT-LLM routing changes still do (#660) - No more reconcile churn on
modelConfiguration— a sorted-key vs declaration-order byte mismatch made the agent rewrite the BaseModel spec on every reconcile; the field is now preserve-if-unset like every other field (#663)
⚠️ **Upgra
- Serve from shared storage — point a BaseModel or ClusterBaseModel at
- v1.1.0OME 1.1.02026-07-02 · 2026-07-02 01:53 UTC
查看更新说明
OME 1.1.0
This release is about controlling when runtime changes reach your services: InferenceServices can now pin to immutable ServingRuntime snapshots with explicit roll-forward and rollback, explicit runtime selection no longer hard-fails on compatibility, and model downloads got faster and more resilient.
✨ Highlights
Runtime Revision Pinning (#639, #640)
Until now, every InferenceService tracked its ServingRuntime live — editing a shared runtime rippled into every service referencing it, immediately, with no staging and no way back. This release makes that coupling opt-out:
- Pin — set
spec.runtime.autoSync: falseand the service freezes on an immutable, content-addressed snapshot of its runtime, backed by ControllerRevisions - Roll forward — bump the
ome.io/runtime-syncannotation to re-sync to the latest runtime on your own schedule - Roll back — set
spec.runtime.revisionto return to any retained snapshot - See drift — a
RuntimeDriftedstatus condition surfaces when a pinned service has fallen behind the live runtime - Stay clean — stale snapshots are garbage-collected automatically, with tunable retention and grace-period flags
- No surprises — live tracking remains the default; nothing changes unless you opt in
Explicit Runtime Compatibility Is Now Advisory (#643)
- Naming a runtime explicitly with a declared model-format or architecture mismatch no longer hard-fails the InferenceService
- The service proceeds and emits a warning event instead, matching the admission webhook's existing behavior
- Generic runtimes can now serve architectures they don't enumerate — you stay informed without being blocked
Faster, More Robust Model Downloads (#629, #644, #645)
- OCI Object Storage downloads are skipped when a same-path artifact is already Ready — nodes stop re-pulling weights they already have (#629)
- The same-path shortcut is bypassed when a download override is set, so forced re-downloads still behave as expected (#645)
- HuggingFace downloads in the replica agent now have timeouts — stalled transfers fail fast instead of hanging (#644)
⚠️ Upgrading: runtime revision pinning requires the controller-manager to have
createoncontrollerrevisions.apps. The bundled charts and manifests include this grant (#646) — if you manage RBAC out of band, add it before pinning any service.🚀 Features & Enhancements
- Content-addressed runtime snapshot machinery, backed by ControllerRevisions (#639)
- Runtime revision controls on InferenceService:
spec.runtime.autoSync,spec.runtime.revision, theRuntimeDriftedcondition, and snapshot GC flags (#640) - Explicit-runtime compatibility mismatches downgraded from a hard failure to a warning event (#643)
- HuggingFace download timeout for the replica agent (#644)
- Skip OCI Object Storage downloads for Ready same-path artifacts (#629); bypass the reuse when a download override is set (#645)
🐛 Bug Fixes
- Grant the controller-manager
createoncontrollerrevisions.apps, required for runtime revision pinning (#646)
📚 Documentation
- Docs backfill (#648):
- Runtime revisions guide
- Controller-manager configuration
- Quantization, including compressed-tensors
- Annotations & labels reference
- Rewritten fine-tuned-weights guide
- Regenerated API reference
- Fixed the GitHub Pages build on Hugo 0.157.0 / Docsy v0.15.0 (#642); bumped autoprefixer 10.4.23 → 10.5.0
♻️ Maintenance
- Hardened the xet cargo build against transient network failures (#641)
📦 Container Images
The following container images are available:
# OME Manager docker pull ghcr.io/moirai-internal/ome-manager:v1.1.0 # Model Agent docker pull ghcr.io/moirai-internal/model-agent:v1.1.0 # OME Agent docker pull ghcr.io/moirai-internal/ome-agent:v1.1.0 # Multinode Prober docker pull ghcr.io/moirai-internal/multinode-prober:v1.1. - Pin — set
- v1.0.0OME 1.0.02026-06-25 · 2026-06-25 03:33 UTC
查看更新说明
OME 1.0.0
What's NEW
⚠️ Breaking Changes Module path renamed from github.com/sgl-project/ome to sigs.k8s.io/ome (#620). Update all imports — anything depending on OME as a Go module must change its import paths accordingly. 🚀 Features Add DeepSeek v4 runtimes — new DeepSeek-V4-Flash and DeepSeek-V4-Pro model + vLLM runtime configs (#598) AUDIO_TO_TEXT capability detection for ASR models (#581) Expose container startup failures in InferenceService status, surfacing crash/startup errors to users (#616) Recognize compressed-tensors as a quantization method in the model parser (#637) 🐛 Bug Fixes Return pod webhook errors instead of panicking (#619) Fix InferenceService pod status lookup for long raw-deployment names (#618) Trigger model redownload on spec/label/annotation changes (#552) Override data parallel size for accelerator configs (#611) Fix mixed-case check against lowercased normalizedModelType (#591) ♻️ Refactors Refactor model parser (#635) Refactor AcceleratorClass cheapest-selection iteration (#548) Add multi-modal model fallback in generic model config parsing (#589) 📚 Docs Update documentation site URLs (#605) 🔧 Maintenance / CI Add pre-commit hooks and wire them into PR validation, with failure annotations (#562, #572, #573, #571) Fix static-analysis / staticcheck findings across pkg/ and the model agent (#558, #561, #554) Repo hygiene: end-of-file newlines, trailing whitespace, spelling fixes (#565, #563, #571) Update outdated HF model config testdata (#586) Helm: bump default image and remaining references to v0.1.5 (#582, #592) Bump actions/deploy-pages 4 → 5 (#551)
📦 Container Images
The following container images are available:
# OME Manager docker pull ghcr.io/moirai-internal/ome-manager:v1.0.0 # Model Agent docker pull ghcr.io/moirai-internal/model-agent:v1.0.0 # OME Agent docker pull ghcr.io/moirai-internal/ome-agent:v1.0.0 # Multinode Prober docker pull ghcr.io/moirai-internal/multinode-prober:v1.0.0⎈ Helm Installation
Option 1: OCI Registry (Recommended)
# Install directly from OCI registry helm install ome-crd oci://ghcr.io/moirai-internal/charts/ome-crd --version 1.0.0 --namespace ome --create-namespace helm install ome oci://ghcr.io/moirai-internal/charts/ome-resources --version 1.0.0 --namespace omeOption 2: GitHub Releases
# Add the OME Helm repository helm repo add ome https://github.com/ome-projects/ome/releases/download/v1.0.0 helm repo update # Install OME helm install ome-crd ome/ome-crd --namespace ome --create-namespace helm install ome ome/ome-resources --namespace ome📋 Changelog
https://github.com/ome-projects/ome/compare/v0.1.5...v1.0.0
📄 Software Bill of Materials
SBOMs are available in both SPDX and CycloneDX formats for:
- Source code
- All container images
🔐 Signatures
All container images are signed with cosign. Verify with:
cosign verify ghcr.io/moirai-internal/ome-manager:v1.0.0 --certificate-identity-regexp=https://github.com/ome-projects/ome/.github/workflows/release.yaml@refs/tags/.* --certificate-oidc-issuer=https://token.actions.githubusercontent.comWhat's Changed
- [Core]refactor acceleratorclass cheapest selection iteration by @pallasathena92 in https://github.com/ome-projects/ome/pull/548
- [Misc]Fix static analysis issues in model agent by @pallasathena92 in https://github.com/ome-projects/ome/pull/554
- Bump actions/deploy-pages from 4 to 5 by @dependabot[bot] in https://github.com/ome-projects/ome/pull/551
- [Misc] Fix staticcheck findings under pkg/ by @heymrbox in https://github.com/ome-projects/ome/pull/558
- [Misc]add pre-commit hooks by @pallasathena92 in https://github.com/ome-projects/ome/pull/562
- [Misc]Fix static analysis issues by @pallasathena92 in https://github.com/ome-projects/ome/pull/561
- [Misc]trail whitespace in repo by @pallasathena92 in https://git
用户点评
登录用户的真实使用记录,可按版本和硬件筛选还没有人点评。第一个说出真实体验的人最有价值。
OME (Open Model Engine) — Kubernetes Operator for LLM Serving
What is OME?
OME (Open Model Engine) is a Kubernetes operator for enterprise-grade management and serving of Large Language Models (LLMs). It optimizes the deployment and operation of LLMs by automating model management, intelligent runtime selection, efficient resource utilization, and sophisticated deployment patterns.
Read the documentation to learn more about OME capabilities and features.
Features Overview
-
Model Management: Models are first-class citizen custom resources in OME. Sophisticated model parsing extracts architecture, parameter count, and capabilities directly from model files. Supports distributed storage with automated repair, double encryption, namespace scoping, and multiple formats (SafeTensors, PyTorch, TensorRT, ONNX). See the supported models reference for the comprehensive catalog of 200+ pre-configured models, including the Llama, Qwen, DeepSeek, Gemma, and Phi families.
-
Intelligent Runtime Selection: Automatic matching of models to optimal runtime configurations through weighted scoring based on architecture, format, quantization, parameter size, and framework compatibility.
-
Optimized Deployments: Supports multiple deployment patterns including prefill-decode disaggregation, multi-node inference, and traditional Kubernetes deployments, with canary and blue-green rollout strategies and advanced scaling controls.
-
Resource Optimization: Specialized GPU bin-packing scheduling with dynamic re-optimization to maximize cluster efficiency while ensuring high availability.
-
Runtime Integrations: First-class support for SGLang - the most advanced inference engine with cache-aware load balancing, multi-node deployment, prefill-decode disaggregated serving, multi-LoRA adapter serving, and much more. Also supports vLLM for high-throughput inference.
-
Accelerator Management: Hardware-aware scheduling through AcceleratorClass resources that define GPU capabilities, discovery patterns, and cost information. Enables intelligent accelerator selection with policies like BestFit, Cheapest, or MostCapable.
-
Fleet Capacity and GPU Operations (alpha): Optional add-on control planes for large GPU fleets. The quota manager assembles the AcceleratorQuota tree and renders it into Kueue, or projects per-cluster shares onto members from a management cluster. Alfred, the GPU cluster caretaker, observes the physical GPU layer and recommends corrective migrations — recommend-only by default.
-
Command-Line Interface:
kubectl omeis the official OME CLI, distributed as a kubectl plugin. It inspects models, runtimes, inference services, and logical instances; explains runtime and accelerator selection; reports rollout, autoscaling, placement, quota, and traffic evidence; streams component logs; and submits guarded actions such as rollout pause/resume/promote/rollback, traffic drain, and migration requests. See the CLI reference. -
Web Console: Modern web interface for managing models, serving runtimes, and inference services with real-time updates and HuggingFace model search integration. Developed separately in ome-projects/ome-console.
-
Kubernetes Ecosystem Integration: Deep integration with modern Kubernetes components including Kueue for gang scheduling of multi-pod workloads, LeaderWorkerSet for resilient multi-node deployments, KEDA for advanced custom metrics-based autoscaling, K8s Gateway API for sophisticated traffic routing, and Gateway API Inference Extension for standardized inference endpoints.
-
Automated Benchmarking: Built-in performance evaluation through the BenchmarkJob custom resource, supporting configurable traffic patterns, concurrent load testing, and comprehensive result storage. Enables systematic performance comparison across models and service configurations.
Production Readiness Status
- ✅ API version: v1beta1
- ✅ Comprehensive documentation
- ✅ Unit and integration test coverage
- ✅ Production deployments with large-scale LLM workloads
- ✅ Monitoring via standard metrics and Kubernetes events
- ✅ Security: RBAC-based access control and model encryption
- ✅ High availability mode with redundant model storage
Installation
Requires Kubernetes 1.28 or newer
Option 1: OCI Registry (Recommended)
Install OME directly from the OCI registry:
# Install OME CRDs
helm upgrade --install ome-crd oci://ghcr.io/moirai-internal/charts/ome-crd --namespace ome --create-namespace
# Install OME resources
helm upgrade --install ome oci://ghcr.io/moirai-internal/charts/ome-resources --namespace ome
Moving an existing manifest install to these charts? See Move a manifest install to the Helm charts first.
Option 2: Install from Source
For development or customization:
# Clone the repository
git clone https://github.com/ome-projects/ome.git
cd ome
# Install from local charts
helm install ome-crd charts/ome-crd --namespace ome --create-namespace
helm install ome charts/ome-resources --namespace ome
Optional: Serving Resources
The ome-serving chart deploys a set of pre-configured ClusterBaseModels, ClusterServingRuntimes, and InferenceServices on top of the core installation:
helm upgrade --install ome-serving oci://ghcr.io/moirai-internal/charts/ome-serving --namespace ome
Optional: Operational Add-ons
Each of these is published alongside the core charts and is independently optional (alpha):
# GPU bin-packing scheduler, installed as a SECOND scheduler; workloads opt in
# via spec.schedulerName. Requires the scheduler-plugins PodGroup CRD.
helm upgrade --install ome-scheduler oci://ghcr.io/moirai-internal/charts/ome-scheduler --namespace ome
# Fleet quota control plane: assembles the AcceleratorQuota tree and renders it into Kueue
helm upgrade --install ome-quota-manager oci://ghcr.io/moirai-internal/charts/ome-quota-manager --namespace ome
# Alfred, the GPU cluster caretaker (recommend-only by default)
helm upgrade --install ome-alfred oci://ghcr.io/moirai-internal/charts/ome-alfred --namespace ome
Command-Line Interface
Install the kubectl ome plugin from the latest release:
kubectl krew install --manifest-url \
https://github.com/ome-projects/ome/releases/latest/download/ome.yaml
Or build it from a checkout:
make kubectl-ome
export PATH="$PWD/bin:$PATH"
kubectl ome --help
Installing the CLI does not install or upgrade the controller or CRDs. See the CLI reference for the full command tree, guarded-action safeguards, and required permissions.
Read the installation guide for more options and advanced configurations.
Learn more about:
Architecture
OME uses a component-based architecture built on Kubernetes custom resources:
- BaseModel/ClusterBaseModel: Define model sources and metadata with automatic parsing of architecture, parameters, and capabilities
- FineTunedWeight: Define LoRA adapters and fine-tuned weights that extend base models
- ServingRuntime/ClusterServingRuntime: Define how models are served with runtime-specific configurations
- InferenceService: Connects models to runtimes for deployment with support for prefill-decode disaggregation and multi-node inference
- AcceleratorClass: Define GPU hardware classes with capabilities, discovery patterns, and cost information for intelligent scheduling
- BenchmarkJob: Measures model performance under different workloads with configurable traffic patterns
- AutoscalerPolicy / RolloutPolicy: Reusable, parameterized autoscaling and rollout templates that components and rollout groups attach by reference
- InferenceReplica: Per-component workload abstraction for OME-native deployments, exposing a scale subresource that HPA and KEDA target directly
- TrafficMap: Control-plane-generated routing projection — the per-home traffic weights a gateway consumes, derived from placement and quota allocation
- AcceleratorQuota: Fleet-level capacity policy; one node of the cluster-scoped accelerator quota tree
- WorkloadCluster: Registry of the workload clusters OME can place onto (multi-cluster reconciliation is still in development)
OME's controller automatically:
- Downloads and parses models to understand their characteristics
- Selects the optimal runtime configuration for each model
- Matches models to appropriate accelerators based on requirements
- Generates Kubernetes resources for efficient deployment
- Continuously optimizes resource utilization across the cluster
Roadmap
High-level overview of the main priorities:
- Unified multi-cluster workload management (APIs merged; reconciliation in development)
- Multi-cloud model storage and authentication
- PVC-backed model storage
- KV cache pooling
- Model Context Protocol (MCP) gateway support
- Accelerator-aware runtime selection for heterogeneous GPU clusters
Community and Support
- GitHub Issues for bug reports and feature requests
- Documentation for guides and reference
License
OME is licensed under the Apache License 2.0.