AI infrastructure is expensive, complex, and rarely one-size-fits-all.
Some tenants need maximum isolation. Others need faster onboarding, lower cost, and efficient access to GPU capacity. Some workloads are experimental. Others are sensitive, regulated, or business-critical.
This creates an important question for platform teams:
Should every tenant get a dedicated cluster, or should multiple tenants share the same cluster?
In OICM, the answer is simple: both models should be supported.
OICM allows organizations to run tenants on either a dedicated cluster or a shared cluster with isolated tenant nodes. This gives platform teams the flexibility to choose the right operating model for each tenant, without creating separate platforms or inconsistent management processes.
These clusters can run on-premises, in fully air-gapped environments, in the cloud, or across hybrid infrastructure. This means OICM gives platform teams flexibility not only in how tenants are isolated, but also in where the infrastructure is deployed.
Shared cluster vs dedicated cluster in OICM.
The Real Problem Is Not Shared vs Dedicated
Many platforms force organizations into one model.
Either everything is shared, which is efficient but may not satisfy every security or compliance requirement.
Or everything is dedicated, which gives strong isolation but can quickly become expensive, inefficient, and harder to manage.
Neither extreme works for every tenant.
A small internal AI team may not need a full dedicated cluster. They may only need a few nodes, clear quotas, and fast access to GPU resources.
A regulated department, government project, or premium external customer may need stronger isolation and full cluster ownership.
The platform should not force both tenants into the same model.
The Two Cluster Models in OICM
OICM gives platform teams two ways to assign infrastructure to tenants:
- Dedicated Cluster
- Shared Cluster with Isolated Tenant Nodes
Both models are valid. The right choice depends on the tenant’s security, compliance, cost, and operational needs.
Option 1: Dedicated Cluster
With a dedicated cluster, the tenant gets the entire cluster.
All nodes in that cluster belong to one tenant. No other tenant uses that cluster.
This model is useful when the tenant needs the highest level of separation, stronger control over the environment, or a simpler compliance story.
A dedicated cluster is usually the right choice when:
- The tenant handles sensitive, regulated, or mission-critical workloads
- A customer contract requires dedicated infrastructure
- The organization needs a clear physical or operational boundary
- The tenant needs predictable access to all cluster resources
- The tenant has enough usage to justify full cluster ownership
One tenant owns the cluster. All nodes, GPUs, and cluster-level resources are assigned to that tenant.
This makes the environment easier to explain to security teams, auditors, customers, and internal stakeholders.
The tradeoff is cost and operational efficiency. If every tenant receives a dedicated cluster, the platform team may end up managing many clusters, duplicating operational work, and leaving expensive GPU capacity underused.
Option 2: Shared Cluster with Isolated Tenant Nodes
A shared cluster in OICM does not mean that tenants share the same nodes.
This distinction is important.
In a shared cluster, multiple tenants can exist in the same cluster, but each tenant receives its own dedicated nodes. Workloads from different tenants are not placed on the same node.
For example:
Tenant | Assigned Nodes | Shares Nodes With Other Tenants? |
Tenant A | Node 1, Node 2 | No |
Tenant B | Node 3 | No |
Tenant C | Node 4, Node 5 | No |
The cluster is shared. The nodes are not.
This gives organizations a practical middle ground. They can improve infrastructure efficiency while still giving each tenant clear compute boundaries.
OICM keeps tenants separated through controls such as:
- Tenant-level resource assignment
- Node ownership boundaries
- Scheduling rules that prevent workloads from different tenants running on the same node
- Network policies that restrict communication between tenant environments
- Storage and quota boundaries
- Auditing and usage visibility per tenant
This allows platform teams to operate shared clusters in a governed way, without mixing tenant workloads on the same nodes.
Why Shared Clusters Are Useful
Shared clusters are often the best default model for many AI platforms.
They allow platform teams to onboard tenants faster, make better use of infrastructure, and avoid creating a new cluster for every team or customer.
This is especially important for GPU infrastructure, where capacity is expensive and often limited.
A shared cluster with isolated tenant nodes can help organizations:
- Reduce operational overhead
- Improve infrastructure utilization
- Onboard tenants faster
- Avoid unnecessary cluster sprawl
- Keep management centralized
- Support smaller tenants without over-provisioning
- Maintain strong tenant boundaries without dedicating a full cluster
For many tenants, this model is enough. They do not need a full cluster. They need dedicated nodes, clear quotas, secure boundaries, and reliable access to the resources assigned to them.
Where Shared Clusters Are Not Enough
Shared clusters are efficient, but they are not always the right answer.
Some tenants need stronger separation for business, security, compliance, or customer trust reasons.
Even if the shared cluster model has strong controls, some organizations may still require a dedicated cluster because of internal policy, regulatory expectations, or commercial commitments.
This can happen when:
- A tenant handles highly sensitive datasets
- A customer contract requires dedicated infrastructure
- A government or regulated project requires stronger separation
- A workload is mission-critical
- A tenant wants full control over cluster-level policies
- The organization wants to reduce any perceived shared-environment risk
In these cases, OICM can place the tenant on a dedicated cluster while keeping the same platform experience and management model.
The platform team does not need to operate a completely different system for dedicated tenants. They can still manage tenants, resources, workloads, quotas, and visibility through OICM.
Dedicated vs Shared Cluster in OICM
Area | Dedicated Cluster | Shared Cluster with Isolated Nodes |
Cluster ownership | One tenant owns the full cluster | Multiple tenants use the same cluster |
Tenant isolation | Highest isolation | Strong isolation in between nodes |
Cost efficiency | Lower | Higher |
Operational overhead | Higher | Lower |
Tenant onboarding | Slower | Faster |
Best for | Highly regulated, sensitive, premium, or large tenants | Standard tenants, internal teams, smaller workloads, scalable onboarding |
Main advantage | Maximum control and separation | Efficient use of infrastructure with clear tenant boundaries |
A Simple Way to Think About It
Dedicated clusters are best when maximum isolation is the priority.
Shared clusters with isolated nodes are best when efficiency, faster onboarding, and centralized management matter, while still maintaining clear tenant boundaries.
Both models are correct. They solve different problems.
The mistake is forcing every tenant into the same model.
Conclusion
AI infrastructure should not force every tenant into the same isolation model.
Some tenants need full cluster ownership. Others need dedicated nodes, clear quotas, and secure access inside a shared cluster.
OICM supports both models in one platform, allowing organizations to stay efficient where they can, strict where they must, and consistent across both.
This is the real value of OICM: one platform, multiple isolation models, and the flexibility to support AI infrastructure as tenant requirements evolve.
Bruno Lopes
Senior Product Manager
