One engine, three platforms. AI Platform is the third Ænix platform. It runs on the same substrate as Public Cloud Platform and Private Cloud Platform and combines with either: a provider sells GPU capacity through the billing surface it already has, and a regulated enterprise runs its own inference inside the tenant boundary its auditor already reviewed.
Infrastructure for inference, fine-tuning and RAG on your own GPUs: multi-tenant GPU scheduling, model serving, vector databases, object storage and air-gapped deployment, built on a CNCF Kubernetes AI Conformance platform. For AI-heavy organizations and regulated AI deployments.
What’s included
GPU allocation
NVIDIA data-centre GPUs through the NVIDIA GPU Operator:
| Mode | How it works | Status |
|---|---|---|
| Whole GPU to a virtual machine | PCI passthrough into a KubeVirt VM | Shipping |
| NVIDIA vGPU for VMs | Mediated vGPU devices in KubeVirt VMs; requires your NVIDIA vGPU licence | Shipping since Cozystack 1.5 |
| Whole GPU to a container | NVIDIA GPU Operator device plugin | Shipping |
| MIG partitions (tenant Kubernetes, GPU Operator) | Hardware partitions of a MIG-capable card, exposed as schedulable resources | Shipping (addon) |
| Time-sliced sharing (tenant Kubernetes, HAMi) | Containers share one card, with memory and compute limits per workload and oversubscription | Shipping (addon) |
Per-tenant GPU quotas, RBAC and observability. GPU usage is measured per tenant; charging happens in your billing system.
Blueprints
Patterns for common AI workload types, adapted to your estate during the engagement:
- Single-tenant inference cluster — one team, one workload class
- Multi-tenant inference fleet — shared GPU pool with tenant isolation
- Inference + fine-tuning + RAG — full-stack pattern with heterogeneous GPU pools
- Air-gapped deployment — for isolated industrial, sovereign-cloud and regulated customers
(See the Sovereign AI Decision Guide for blueprint detail.)
Models, databases and storage
Open-weight models (Llama, Mistral, Qwen, DeepSeek, Phi, Gemma families) deployed for your workloads. Vector databases (pgvector via the PostgreSQL operator, or Qdrant). Managed databases (PostgreSQL, MariaDB, Valkey, ClickHouse) and message brokers (Kafka, RabbitMQ). S3-compatible object storage for training data and model checkpoints.
Serving and fine-tuning
Inference with vLLM-compatible serving by default (Triton supported), fine-tuning jobs, embedding generation and RAG retrieval, set up as multi-tenant platform services rather than a bespoke build per workload.
Sovereignty controls
Hardware and data in your jurisdiction. Air-gapped deployment supported. Encryption and key handling designed with you during the build. Ænix engineers work on your environment only with your approval.
GPU sizing
Sizing for common workload profiles (7B to 405B-parameter models, single-card, multi-card and multi-node configurations) and capacity planning for sustained workloads, as part of the engagement. Network fabric design for multi-node training (InfiniBand, RoCE) is scoped in the assessment for your hardware, not sold as a packaged feature.
Observability for AI workloads
Inference latency and throughput, GPU utilisation per tenant and model-serving SLOs in VictoriaMetrics and VictoriaLogs, exportable to an existing Prometheus, Datadog or Splunk estate.
Moving off hyperscaler AI APIs
Migration planning from AWS Bedrock, Azure OpenAI Service or GCP Vertex AI to self-hosted inference, for organizations whose sustained inference no longer fits per-token pricing.
Deployments we have written up
| Case | What happened |
|---|---|
| 8×H100 inference on your own bare metal | A mobile photo/video app moved GPU inference off a rented GPU cloud onto its own 8×H100 server: about two months to production, KubeVirt passthrough |
| From public cloud to bare metal | A European academic-computing SaaS moved to owned bare metal and cut GPU cost about five times |
| Cozystack as a universal installer | A telecom operator and integrator built a corporate AI platform with RAG on Qdrant and NVIDIA Dynamo inference, then shipped it into its end customer’s environment |
| An internal data and AI platform | GPU pools with per-tenant quotas and usage metrics that feed billing, in rollout |
Who buys AI Platform
| Buyer | Typical engagement |
|---|---|
| AI-native company at scale | Self-hosted inference fleet, replacing hyperscaler API spend |
| Regulated AI deployment (bank / public sector / healthcare) | AI infrastructure inside the regulated perimeter |
| GPU-heavy product company | Multi-tenant GPU platform with strict cost discipline |
| Telco / large enterprise running AI | Internal AI platform shared across business units |
| Data centre or GPU cloud selling capacity | GPU tenancy combined with Public Cloud Platform billing and portal |
Why AI Platform over alternatives
| Vs. | Why AI Platform |
|---|---|
| Hyperscaler AI APIs (Bedrock, Azure OpenAI, Vertex) | You control weights, data and operations. Sustained-utilization economics typically beat per-token API pricing. You own fine-tuned models. |
| Building it yourself on Kubernetes and GPU drivers | GPU scheduling, tenancy, storage, observability and blueprints arrive together instead of as a long platform-engineering project. |
| Closed-source MLOps platforms | Open-source foundation (Cozystack, Apache 2.0) — no per-engineer or per-model licensing, and the substrate stays yours if the contract ends. |
| Run:ai (NVIDIA) | Run:ai is a GPU scheduler and quota layer that assumes a Kubernetes platform already exists underneath — cluster lifecycle, storage, networking, tenancy and the VM estate are still yours to build and run. AI Platform brings the platform itself: fractional GPU sharing, KubeVirt for workloads that never containerized, LINSTOR/DRBD storage, tenant isolation. It is also Apache 2.0 with no per-GPU subscription. If you already run a mature Kubernetes platform and only need scheduling, Run:ai is a narrower and reasonable purchase. |
| Kubeflow | Kubeflow is an ML toolchain — pipelines, notebooks, training operators, serving — not an infrastructure platform. AI Platform supplies what Kubeflow assumes: multi-tenant GPU scheduling, managed databases and vector stores, object storage, observability, isolation per team. Teams run Kubeflow, Dynamo or plain vLLM as tenant workloads on top. |
Pricing
Project plus optional managed retainer, quoted per RFP after a discovery call. GPU nodes are not priced from the published support list, which covers Public Cloud Platform and self-run Cozystack.
Engagement structure
- Discovery call (30 minutes, free)
- Platform Readiness Assessment (14 or 28 days, fixed price) — workload profile, GPU sizing, architecture and roadmap, using the Sovereign AI Decision Guide framework
- Build (3-12 months, depending on scope) — often starting with a defined slice: one workload class, one tenant, one model family
- Managed retainer (optional, ongoing) — Ænix runs the AI platform under SLA
Combine it with the other platforms
The three Ænix platforms are one engine with different surfaces switched on. AI Platform is not a separate installation — it is GPU tenancy, model serving and the data services around them, running on the same substrate as everything else you operate.
- Private Cloud Platform — the usual pairing for regulated buyers. The DORA- and NIS2-aligned architecture, encryption and audit logging designed for the private cloud cover the AI estate too, and GPU workloads sit inside the tenant boundary the auditor already reviewed.
- Public Cloud Platform — for providers selling GPU capacity. Billing, the WHMCS integration and the customer portal come from that side; GPU scheduling and HAMi sharing come from this one, with GPU usage measured per tenant. Providers commonly start with VMs and databases and switch GPU on when demand appears. How a data centre or GPU cloud sells this capacity is described on GPU as a service platform.
How to start
Book a discovery call. Bring your AI workload profile (steady inference / training / fine-tuning / RAG / mix), regulatory scope and target deployment model.
Ænix AI Platform is built on Cozystack — a CNCF project Ænix created and maintains with maintainers from other companies (currently CNCF Sandbox; CNCF Incubating application in due diligence). Apache 2.0.