Enterprise AI without assembling the stack — or surrendering your data.
A managed OpenDataHub platform — the open-source project behind Red Hat OpenShift AI — running on GRN’s Kubernetes. The full ML lifecycle on one platform: notebook to pipeline to distributed training to served model, on NVIDIA GPU nodes. We run the platform, the GPUs and the storage; you keep your notebooks, your models and your data. It is open source on standard Kubernetes, so nothing here locks you in — and your training data never leaves the EU. This is Sovereign AI.
Managed AI/ML Platform
OpenDataHub on Kubernetes · up to 99.99% SLA
- PlatformOpenDataHub on Kubernetes (open source)
- NotebooksJupyterHub workbenches
- PipelinesKubeflow Pipelines
- ServingKServe / ModelMesh
- GPUNVIDIA — MIG-partitionable
- DataS3 / Ceph — EU-resident
- SLAUp to 99.99% (tier-dependent)
NVIDIA GPU acceleration
EU data residency
No US Cloud Act exposure
100% renewable-powered
Built on three guarantees
The same three guarantees behind every GRN product — here, applied to an AI/ML platform. On AI the first one carries the most weight: where your training data and models actually live, and whose law reaches them.
Sovereign AI — secure by jurisdiction
Training datasets, model weights and inference traffic stay on EU-owned infrastructure under Dutch jurisdiction — not a US hyperscaler’s “European region”, which remains subject to the US Cloud Act however the data is encrypted. No Cloud Act reach over your datasets, EU-only residency, and a signed Data Processing Agreement. Your data is your competitive moat — it should not transit a jurisdiction you do not control.
Affordable & transparent
GPU is the cost centre of any AI programme. You get published €/GB-month storage, GPU partitioned by MIG so a whole card is not stranded on one notebook, and 10% off on annual commitment. No per-feature surcharges, and no egress tax on moving your own datasets and checkpoints around. Verify egress
Sustainable
GPU training is power-hungry — so it matters where the power comes from. Hosted in the Netherlands on 100% renewable solar energy, with server heat reused to warm nearby buildings and peak-shaving to ease grid congestion. Sustainability with a mechanism behind it, not a logo.
A managed AI platform, not a managed black box
OpenDataHub is the open-source upstream of Red Hat OpenShift AI — a curated set of best-of-breed ML tools (JupyterHub, Kubeflow Pipelines, KServe, distributed training operators) integrated into one platform on Kubernetes. We operate that platform, the GPU layer and the storage so your data scientists are not also a platform team. But every component is open source on standard Kubernetes, so nothing about the deal traps you here. Here is exactly where the line sits.
What GRN operates
Run and on-call for the platform, GPU and storage layers — the undifferentiated heavy lifting.
- The OpenDataHub platform: install, integration, upgrades and the operator that reconciles it
- JupyterHub, Kubeflow Pipelines, the serving stack and training operators, kept healthy and patched
- The GPU layer: NVIDIA GPU Operator, drivers, MIG/time-slicing config and node pools
- Storage and data plumbing: Ceph (S3/block/file), OpenEBS NVMe, snapshots and Velero backup
- The Kubernetes substrate underneath and the control-plane SLA of up to 99.99% on dedicated tiers
What you operate
The data science itself, fully in your hands — the part that is actually your IP.
- Your notebooks, code, experiments and the frameworks you import (PyTorch, TensorFlow, …)
- Your pipelines, training jobs, hyperparameters and the models they produce
- Your datasets, feature engineering, data-quality and labelling decisions
- Which models you serve, how you evaluate them, and your acceptance and governance thresholds
- The decision to leave: export models, pipelines and data and run them on any Kubernetes
Open source, portable by construction. OpenDataHub, Kubeflow, KServe, JupyterHub and the NVIDIA GPU Operator are all open-source projects running on standard, conformant Kubernetes. There is no proprietary training API and no closed model format to unwind. Your notebooks, pipeline definitions and model artifacts move to any other Kubernetes running the same stack — on-prem or another cloud — without a rewrite. Sovereignty over your data and portability of your platform are the same property, viewed from two angles.
Why an enterprise AI platform is hard to stand up
The hard part of enterprise AI is rarely the model. It is everything around it: assembling a coherent platform, getting GPUs at a sane price, keeping the training data in jurisdiction, and being able to reproduce and govern what you shipped. These are the pains this platform removes.
- Stack assembly is a project in itselfNotebooks, pipelines, distributed training, model serving, a registry and GPU scheduling normally have to be chosen, integrated and maintained by hand — before any model ships. OpenDataHub is that integration, already done.
- GPU scarcity and stranded costGPUs are expensive and hard to source, and a single card pinned to an idle notebook is money burned. MIG partitioning and time-slicing let many workloads share a card; queueing keeps it busy.
- Data gravity and sovereigntyTraining data is large, sensitive and slow to move — and once it sits with a US-owned provider it is within reach of the US Cloud Act. Keeping the platform where the data already lives, in the EU, solves both at once.
- Reproducibility and governance gaps“Which data, which code, which hyperparameters produced this model?” is the question audits turn on. Pipelines, experiment tracking and a model registry make a run reproducible instead of folklore.
- Lock-in to proprietary AI APIsBuild on a hyperscaler’s managed AI service and your pipelines, notebooks and model formats bind to APIs that exist nowhere else. Open source on Kubernetes keeps the exit open.
- The gap between a notebook and productionA model in a notebook is not a served endpoint. KServe turns a registered model into an autoscaling inference service — the same platform carries it from experiment to production.
Platform architecture
A layered, open stack — data scientists and notebooks at the top, sovereign renewable-powered storage at the bottom. Every layer is a named, portable open-source component you could reproduce on another Kubernetes; none of it is a black box you can only run here.
Per-user JupyterHub workbenches with curated PyTorch / TensorFlow / CUDA images — where exploration, feature work and model development happen, with GPUs and data connections attached on demand.
Kubeflow Pipelines for reproducible DAGs; the Training Operator and Ray / CodeFlare for multi-GPU, multi-node distributed training and tuning, with job queueing across the cluster. Pending validation
KServe and ModelMesh expose registered models as autoscaling, scale-to-zero inference endpoints; a model registry versions what is trained and promoted. Pending validation
NVIDIA GPU worker pools managed by the GPU Operator — drivers, device plugin, MIG partitioning and time-slicing — so cards are scheduled, shared and accounted for rather than stranded.
Datasets, checkpoints and artifacts on Ceph (S3 / block / file) and local NVMe via OpenEBS, on EU-owned hosts in the Netherlands powered by 100% renewable solar — the data never leaves the jurisdiction.
Every layer uses standard, open-source, portable components — nothing proprietary you cannot reproduce on another conformant Kubernetes.
The ML lifecycle on one platform
From a blank notebook to a monitored production endpoint without leaving the platform or changing tools — each stage is a named open-source component, and the artifacts hand off cleanly between them.
Explore
Spin up a JupyterHub workbench with a curated image, attach a GPU and a data connection, and develop interactively.
Build pipeline
Promote notebook code into a reproducible Kubeflow Pipeline — a versioned DAG of data, training and evaluation steps.
Train
Run distributed, multi-GPU training via the Training Operator or Ray / CodeFlare, queued across the GPU pool.
Track & register
Log metrics and parameters to experiment tracking; register the chosen model and its version in the model registry.
Serve
Deploy the registered model with KServe as an autoscaling, scale-to-zero endpoint, with canary rollout.
Monitor
Watch latency, drift and — optionally — bias and explainability via TrustyAI, then loop back to retrain.
Honest about the loop. The platform provides the stages and the hand-offs; you provide the data, the model code and the decision of what “good” means at each gate. We do not train your model for you — we make sure that when you do, it is reproducible, observable and portable. Optional components (experiment tracking back-end, TrustyAI) are part of the standard ODH stack; confirm with us which are enabled on your platform.
Where the data science actually starts
A workbench is a per-user, GPU-attachable Jupyter environment managed by the Notebook Controller and JupyterHub — isolated, reproducible from a curated image, and wired to your data on day one.
Curated, versioned images
Start from maintained images with PyTorch, TensorFlow and CUDA already matched to the GPU drivers — no dependency archaeology before you can train.
Per-user isolation
Each workbench runs in its own namespace-scoped pod with its own RBAC, resources and persistent volume — one user’s runaway job cannot starve another.
Attach a GPU on demand
Request a full GPU or a MIG slice from the workbench — interactive development gets accelerated compute without holding a whole card hostage.
Data connections built in
Mount S3 / Ceph buckets and DataVolumes as data connections — the same datasets your pipelines and training jobs read, with no copy out of the EU.
Bring your own image
Push a custom OCI image with your own framework versions and internal libraries; the platform runs it as a workbench like any curated one. Confirm
Reproducible by default
An image plus a pipeline definition plus a data connection is a reproducible experiment — not “it worked on my laptop”.
From interactive code to repeatable, distributed runs
Notebooks are for exploring; pipelines are for doing it the same way twice. Kubeflow Pipelines turns a workflow into a versioned DAG, and the training operators scale it across many GPUs and nodes when one card is not enough.
Kubeflow Pipelines
Compose data prep, training, evaluation and registration into a DAG that runs identically every time, with each step containerised and cached. Pipeline definitions are versioned artifacts you can review, diff and roll back — the unit of reproducibility. Pending validation
Distributed training
The Kubeflow Training Operator (PyTorchJob / TFJob) and Ray / CodeFlare spread a single training run across many GPUs and nodes, with gang scheduling and a job queue so large jobs do not deadlock the cluster. Pending validation
- Reproducible DAGs — same inputs, same containers, same result, every run
- Multi-GPU / multi-node data- and model-parallel training
- Gang scheduling and job queueing so large runs schedule atomically
- Hyperparameter tuning sweeps parallelised across the GPU pool
- Checkpoints written to NVMe / Ceph so a pre-empted run resumes, not restarts
- Pipeline runs triggered from CI or GitOps, not only by hand
GPU, scheduled like a shared resource — not stranded
A GPU pinned to one idle notebook is the most expensive idle resource in the building. The NVIDIA GPU Operator manages drivers, the device plugin and partitioning so a card can be sliced, shared and scheduled like any other Kubernetes resource.
| Function | Implementation |
|---|---|
| Driver & runtime lifecycle | NVIDIA GPU Operator (driver, container toolkit, device plugin, DCGM) |
| Hard partitioning | MIG — a single GPU split into isolated instances with dedicated memory and compute |
| Soft sharing | Time-slicing — several pods share a GPU’s cycles for bursty / interactive work |
| Scheduling & accounting | Kubernetes device plugin requests / limits; per-team GPU quotas |
| Job queueing | Gang scheduling + queue so multi-GPU jobs schedule atomically Confirm |
| High-throughput data path | GPUDirect / RDMA to feed GPUs from NVMe / Ceph without CPU bottleneck Pending validation |
| Node pools | Dedicated NVIDIA worker pools, separate from CPU pools, on VPC or single-tenant DPC |
| Monitoring | DCGM GPU metrics into the platform observability pipeline |
MIG and time-slicing are configured per node pool to match your workload mix. Exact NVIDIA GPU models Confirm models — ask us what is currently available for your region and tier.
Why partitioning matters to the bill. MIG turns one large GPU into several isolated smaller ones, each with its own memory and SMs — so an inference endpoint, a tuning sweep and three notebooks can share a card with hard boundaries instead of each demanding a whole one. Time-slicing oversubscribes a GPU for bursty interactive work where isolation matters less. Between them, utilisation goes up and stranded-GPU cost comes down.
From a registered model to a live endpoint
Training produces an artifact; serving makes it useful. KServe and ModelMesh turn a registered model into an autoscaling inference service — the bridge from experiment to production, on the same platform.
KServe inference endpoints
Serve a model as a standard, versioned inference service that autoscales on request load and scales to zero when idle — you pay for GPU only while it is actually serving. Pending validation
ModelMesh for density
Where you serve many smaller models, ModelMesh multiplexes them onto shared serving pods instead of one pod per model — high model density without a GPU per endpoint. Optional
Canary & rollback
Shift a percentage of traffic to a new model version, watch the metrics, and promote or roll back — the same health-gated discipline as application deploys.
Model registry & versioning
Register each trained model with its version, lineage and stage (dev / staging / prod) so what is in production is always traceable to the run that produced it. Pending validation
Standard runtimes
Serve common formats — ONNX, PyTorch, TensorFlow, scikit-learn, plus vLLM-class runtimes for LLMs — through standard serving runtimes, not a proprietary format. Confirm runtimes
EU-resident inference
Endpoints run on the same sovereign infrastructure as training — prompt and inference data stay in the EU, outside US Cloud Act reach.
Reproducible, observable, governable — or it does not ship
For regulated AI, “the model works” is not enough; you have to show how it was built and prove what it does. The platform treats models and pipelines as versioned artifacts under the same GitOps discipline as the rest of your estate.
- GitOps for models and pipelines — Argo CD / Flux reconcile what is deployed from Git
- Experiment tracking — metrics, parameters and artifacts logged per run Confirm back-end
- Model registry lineage — every prod model traces to its run, data and code
- Pipeline versioning — reproduce a six-month-old result from the committed DAG
- Audit logging of who trained, registered, promoted and served what
- Bias, fairness & explainability via TrustyAI Optional
- Drift and serving-quality monitoring on live endpoints
- RBAC and approval gates between dev, staging and production model stages
On the EU AI Act, the honest version. The platform is designed to support your governance obligations — data residency in the EU, lineage from data to deployed model, audit trails, and TrustyAI bias and explainability tooling. That gives your compliance team the technical evidence the AI Act expects. It does not make your system compliant on its own: classification, risk assessment and conformity remain your obligations, subject to your use case. We will tell you precisely what the platform attests to and what stays with you — we do not claim AI Act “certification”.
Datasets and checkpoints, priced per GB — in the EU
AI workloads are storage workloads: large datasets, fat checkpoints, growing artifact stores. The platform mounts them as data connections through standard CSI on Ceph and OpenEBS — software-defined, expandable, and billed transparently per GB-month.
| Storage class | Implementation (CSI) | Best for | Price |
|---|---|---|---|
| Local NVMe | OpenEBS LocalVolume | Training throughput — hot datasets, checkpoints, shuffle | € 0.044 / GB-mo |
| Block (RWO) | Rook Ceph RBD | Workbench home volumes, single-writer datasets | € 0.044 / GB-mo |
| Shared file (RWX) | Rook Ceph FS | Datasets shared across distributed training pods | € 0.044 / GB-mo |
| S3 object (data connection) | Ceph ObjectBucketClaim |
Data lakes, dataset versions, model artifact store | € 0.044 / GB-mo |
| Cross-region replication | Ceph VolumeReplication |
Geo-redundancy / DR for datasets and registries | € 0.0465 / GB-mo |
| Backup & snapshots | Velero + CSI snapshots | Scheduled backup of datasets, registries and pipelines | € 0.008 / GB-mo |
All classes are dynamically provisioned and expandable; mounted into workbenches, pipelines and serving as data connections / DataVolumes. NVMe-oF with configurable IOPS on dedicated tiers. Prices in EUR, ex VAT; 10% discount on annual commitment. Verify on the pricing page before quoting.
Many teams, one platform, hard boundaries
A shared AI platform only works if one team’s data, GPUs and models are genuinely walled off from another’s. Isolation is enforced with the Kubernetes primitives your security team already audits — per-team projects, RBAC, network policy and GPU quotas — not proprietary bolt-ons.
- Per-team data science projects (namespaces) with their own RBAC and quotas
- RBAC across workbenches, pipelines, models and the registry, with audit logging
- Identity via OAuth / OIDC — bring your own IdP for SSO
- Default-deny network policy between projects and to data connections
- Isolated GPU quotas — a team cannot starve another’s training of cards
- Secrets and data-connection credentials encrypted at rest; external stores supported
- MIG hardware partitioning for memory isolation between tenants on a shared GPU
- Hardware & kernel isolation on single-tenant DPC node pools for sensitive data
On compliance, the honest version. The platform runs under EU-only data residency with a signed DPA and no US Cloud Act exposure — the substantive part of most regulated AI requirements. We will support healthcare, finance and government deployments on dedicated, isolated infrastructure and help you produce the technical evidence the EU AI Act expects — but we do not claim certifications we do not hold. Tell us your compliance scope and we will tell you precisely what we can and cannot attest to.
Against the managed AI clouds, on the axes that matter
An objective comparison against the major managed ML platforms and against assembling it yourself on Kubernetes. Subjective claims (“easier”, “smarter”) are left out — only things you can check.
| Capability | GRN OpenDataHub | AWS SageMaker | Azure ML | Google Vertex AI | DIY on K8s |
|---|---|---|---|---|---|
| Open source platform | Yes (OpenDataHub) | Proprietary | Proprietary | Proprietary | Yes (your stack) |
| Lock-in / portability | Portable — standard K8s | Proprietary APIs | Proprietary APIs | Proprietary APIs | Portable |
| Genuine EU sovereignty (non-US-owned) | Yes (Netherlands) | US-owned | US-owned | US-owned | Depends on your DC |
| Data residency for training data | EU-only, signed DPA | ~ configurable region | ~ configurable region | ~ configurable region | Depends on your DC |
| GPU cost transparency / egress | Published €; no egress tax Verify | Complex + egress | Complex + egress | Complex + egress | Your cost |
| Full lifecycle on one platform | Notebook → serve | Yes | Yes | Yes | ~ you integrate it |
| Kubernetes-native | Yes (standard K8s) | ~ managed service | ~ managed service | ~ managed service | Yes |
| Governance / audit / lineage | Registry, audit, TrustyAI | Yes | Yes | Yes | ~ you build it |
| Platform assembly effort | Managed — pre-integrated | Managed | Managed | Managed | High — you own it all |
| 100% renewable-powered | Yes | ~ varies by region | ~ varies by region | ~ varies by region | Depends on your DC |
Compiled from public product & pricing pages, June 2026; competitor features change — verify before quoting. Yes = supported, ~ = partial/conditional, No = not available.
Technical specifications
The detail a platform or ML engineer actually evaluates. Items tagged for review are confirmed against a live platform before publishing — we would rather leave a value open than print one we cannot stand behind.
- PlatformOpenDataHub on Kubernetes (upstream of OpenShift AI)
- NotebooksJupyterHub + Notebook Controller, curated & custom images
- PipelinesKubeflow Pipelines (DAG, versioned) Confirm
- Distributed trainingTraining Operator (PyTorchJob/TFJob), Ray / CodeFlare Pending validation
- ServingKServe + ModelMesh, scale-to-zero Confirm
- Model registryVersioning + lineage + stages Pending validation
- Experiment trackingPer-run metrics / params / artifacts Confirm back-end
- GovernanceTrustyAI bias / explainability Optional
- Frameworks
PyTorch,TensorFlow,scikit-learn, ONNX, vLLM-class Confirm - GPU layerNVIDIA GPU Operator, MIG partitioning, time-slicing
- GPU modelsNVIDIA, model line per region/tier Confirm models
- Storage classesOpenEBS NVMe, Ceph block / file / S3
- Data connectionsS3 / Ceph buckets, DataVolumes, RWX datasets
- Backup / DRVelero, CSI snapshots, cross-region replication
- TenancyPer-team projects; shared-HW (VPC) or bare-metal (DPC)
- API accessStandard Kubernetes API + ODH dashboard + GitOps
- Control-plane SLAUp to 99.99% (tier-dependent)
- RegionNetherlands (EU), 100% renewable-powered
What teams build on it
Each is well-served because it is the standard open ML stack — the same components you would run anywhere, on infrastructure that happens to be sovereign and renewable.
LLM fine-tuning & RAG
Fine-tune open models on distributed GPUs and serve RAG inference with KServe / vLLM-class runtimes — prompts and training data stay in the EU. Confirm runtimes
Computer vision
GPU-accelerated training and batch / real-time inference for image and video models, with high-throughput NVMe data paths.
Regulated AI
Health, finance and government models on EU-sovereign, single-tenant infrastructure with lineage and audit — subject to your compliance scope. Review
Research & HPC-AI
Multi-node, multi-GPU training for research groups, with job queueing and reproducible pipelines instead of ad-hoc scripts.
Internal AI platform
A golden-path platform for many data science teams — self-service workbenches, shared GPUs and governed model promotion on one cluster.
MSP-hosted AI
Operate or resell isolated AI platforms for your own customers on sovereign, renewable infrastructure — with per-tenant projects and quotas.
The questions an engineer actually asks
What is OpenDataHub, and how does it relate to OpenShift AI?
Is it really open source and portable?
Where does my training data actually live?
What GPUs do you offer, and what is MIG?
How are multiple users and teams isolated?
Can I bring my own notebook images?
Are Kubeflow Pipelines and KServe supported?
Do you provide a model registry and experiment tracking?
Can I run GitOps for models and pipelines?
Does this make me EU AI Act compliant?
How does the cost compare to SageMaker or Vertex AI?
What is the SLA, and who operates the platform?
Can I move off the platform later?
Do you train the model for me?
Sovereign AI — the open ML platform, on EU soil.
Run the full ML lifecycle on managed OpenDataHub and NVIDIA GPUs — notebook to served model — with your training data inside the EU and your platform portable by construction. Talk to our engineers about standing it up for your teams.
Open source · NVIDIA GPU · EU data residency · No US Cloud Act exposure · No vendor lock-in
