How Does Aviz ONES 4.2 Enable High-Density, Multi-Tenant GPU Environments Beyond Server-Level Isolation?
May 1, 2026
ONES & SONiC
TL;DR
Aviz ONES 4.2 replaces rigid server-level GPU allocation with a decoupled model that allows multi-tenant compute VM sharing while keeping GPUs strictly isolated per tenant. This improves resource utilization, increases workload density, and reduces infrastructure costs without compromising performance or security.
Introduction
As GPU infrastructure scales to support modern AI and PaaS-driven workloads, traditional deployment models are being re-evaluated. Historically, GPU servers were allocated to a single tenant, with all compute, network, and GPU resources tightly bound together. While this ensured strong isolation, it also led to underutilization and reduced flexibility. Aviz ONES 4.2 addresses this challenge by introducing multi-tenant compute VM sharing with fine-grained GPU allocation, enabling more efficient use of GPU fabrics without compromising isolation.
What Are the Limitations of Server-Level Isolation in GPU Infrastructure?
In conventional GPU fabric deployments:
- A physical server is dedicated to a single tenant
- All GPUs on that server are exclusively assigned to that tenant
- Network isolation is enforced at the port level using constructs such as Virtual Routing and Forwarding (VRF)
While simple to operate, this model introduces several inefficiencies:
- Compute resources (CPU and memory) are often underutilized
- GPUs remain idle or partially consumed
- Workload placement lacks flexibility
- Infrastructure costs increase due to low density
These limitations are particularly evident in shared AI platforms and PaaS environments where workloads are dynamic and heterogeneous.
How Does ONES Decouple Compute and GPU Resources for Better Efficiency?
Aviz ONES introduces a decoupled resource model that separates compute and GPU allocation:
How Does Multi-Tenant Compute Sharing Improve Utilization?
ONES enables multiple tenants to run compute-only virtual machines on the same physical server, improving overall server utilization and workload density.
How Is Fine-Grained GPU Allocation Managed Without Compromising Isolation?
At the same time, GPUs are managed independently:
- Each GPU is allocated at the individual device level
- GPU ownership is strictly bound to a single tenant
- Cross-tenant GPU sharing is not permitted
This approach allows operators to maximize compute efficiency while maintaining strict isolation for GPU workloads.
Figure 1: Tenant Control
How Does the Network Architecture Evolve to Support Multi-Tenant Compute Sharing?
Supporting multi-tenant compute sharing requires moving beyond traditional port-based isolation toward a fabric-wide logical segmentation model.
Aviz ONES leverages its network virtualization capabilities using EVPN VXLAN and VRF to provide scalable, end-to-end tenant isolation.
Key architectural elements include:
- VLAN-based tagging for tenant traffic segmentation
- Consistent propagation of segmentation across the fabric during provisioning
- VLAN termination at the leaf layer with mapping to tenant-specific routing domains
This design ensures complete isolation across both Layer 2 and Layer 3, enabling secure multi-tenant operation on shared physical infrastructure.
Figure 2: Multi-Tenant GPU Allocation
How Does GPU-Aware Orchestration Ensure Efficient and Isolated Workload Placement?
ONES incorporates GPU-aware orchestration to ensure intelligent workload placement and strict adherence to isolation policies:
- Validates server eligibility based on GPU allocation
- Enforces separation between compute-only and GPU workloads
- Ensures placement adheres to tenant boundaries
This results in higher resource utilization, increased workload density, reduced costs, and consistent tenant isolation across shared infrastructure.
What Makes ONES a New Model for Scalable GPU Infrastructure?
Aviz ONES redefines GPU infrastructure consumption by eliminating the constraints of rigid, server-level isolation. By enabling multi-tenant compute VM sharing alongside strict GPU ownership, ONES strikes a critical balance between efficiency and control.
This model allows organizations to significantly increase infrastructure utilization while maintaining predictable performance and strong tenant isolation. Operators can dynamically adapt to evolving workload demands, improve resource efficiency, and reduce overall infrastructure costs.
As AI and PaaS platforms continue to scale, ONES provides a flexible and future-ready foundation for building high-density, multi-tenant GPU environments with confidence.
Conclusion
Aviz ONES 4.2 introduces a more flexible and efficient approach to GPU infrastructure by separating compute and GPU resources. By enabling shared compute environments alongside strict GPU ownership, it solves the inefficiencies of traditional single-tenant server models. This allows organizations to scale AI and PaaS workloads more effectively while maintaining strong isolation, predictable performance, and optimized infrastructure usage.
Frequently Asked Questions
1. What problem with GPU infrastructure does Aviz ONES 4.2 actually fix?
Old-school GPU setups gave one whole server to one tenant. That meant the CPU and memory on that server sat mostly idle while the GPUs ran hot. ONES 4.2 breaks that rigid one-server-one-tenant rule so multiple tenants can share compute resources on the same server while each one still owns their GPUs exclusively. More work gets done on the same hardware.
2. How does ONES 4.2 keep GPU workloads isolated when multiple tenants share a server?
Compute VMs can be shared across tenants but GPUs never are. Each GPU gets assigned to one tenant at the individual device level and that binding is strict. No tenant can touch another tenant's GPU no matter what is running on the shared compute layer above it. Sharing happens at the CPU and memory level only.
3. What networking tech does ONES use to keep tenants separated across the fabric?
ONES uses EVPN VXLAN and VRF to segment tenant traffic across the whole fabric. Each tenant's traffic gets tagged at the VLAN level, stays consistent as it moves through the network, and terminates at the leaf layer into its own routing domain. Tenants stay isolated at both Layer 2 and Layer 3 even when sharing the same physical switches.
4. How does GPU-aware orchestration in ONES decide where to place workloads?
Before placing any workload, ONES checks whether a server actually has the right GPU allocation available for that tenant. It keeps compute-only workloads and GPU workloads on separate paths and makes sure nothing lands outside its tenant boundary. The result is that GPUs stay busy with the right work and no tenant accidentally steps on another one's resources.
5. What does separating compute and GPU resources mean for infrastructure costs?
When one tenant owns a whole server, you are paying for all that CPU and memory sitting idle most of the day. Running multiple tenants on the compute layer means that overhead gets shared and you fit more workloads onto fewer servers. Less hardware to buy, less power to run, lower cost per AI job without touching performance.
6. Why did single-tenant server allocation become a problem as AI workloads scaled up?
AI and PaaS workloads are not steady and predictable. They spike, pause, and shift constantly. Locking an entire server to one tenant meant lots of idle capacity sitting around waiting for a workload that was not always there. At scale that idle capacity adds up to serious wasted spend and makes it hard to fit more workloads into a fixed amount of hardware.
7. Can operators change how workloads are placed without disrupting existing tenant isolation?
Yes. The whole point of decoupling compute and GPU is that operators can move compute workloads around dynamically as demand shifts without touching GPU assignments. GPU ownership stays locked to a tenant regardless of what happens on the compute side. Operators get flexibility where they need it and firm boundaries where security demands it.
8. Is the ONES multi-tenant GPU model suited for shared AI platforms and PaaS providers?
That is exactly the environment it was built for. PaaS providers and shared AI platforms have lots of tenants with unpredictable workloads running on the same infrastructure. ONES gives them the density they need to stay profitable, the isolation tenants expect, and the flexibility to handle workloads that change constantly without spinning up new dedicated hardware every time.
Explore how Aviz ONES 4.2 can optimize your GPU infrastructure and improve resource efficiency
