Overview

How TensorFusion compares with HAMi, NVIDIA MIG/MPS/time-slicing, NVIDIA vGPU, NVIDIA Run:ai and VirtAI OrionX, and when each one is the better choice

This page compares TensorFusion with five other ways to share GPUs, and says when each one fits better. Every solution has a detailed page linked below.

Statements about TensorFusion describe the current open source release. Statements about other products come from their public documentation, checked in October 2026. Each detailed page lists its sources. Products change, so confirm anything that matters to your decision against the vendor's own docs.

Solutions covered

Solution	What it is	Source and license
TensorFusion	A Kubernetes operator for GPU pooling: fractional GPUs, remote GPU sharing, a GPU-aware scheduler, and autoscaling.	Controller, scheduler, and hypervisor are Apache 2.0. The vendor limiter libraries used by `soft` mode, and the client and worker behind remote GPU sharing and `hard` isolation, are closed source. See Licensing.
HAMi	Kubernetes middleware that shares GPUs and other accelerators from more than ten vendors. A CNCF Incubating project.	Apache 2.0.
MIG, MPS, time-slicing	GPU sharing mechanisms built into NVIDIA's driver and exposed in Kubernetes by the NVIDIA device plugin and GPU Operator.	No extra license. The device plugin and GPU Operator are open source.
NVIDIA vGPU	Hypervisor-level GPU virtualization that gives each virtual machine a virtual GPU.	Proprietary, licensed per product edition.
NVIDIA Run:ai	An AI workload platform on Kubernetes: scheduler, GPU fractions, projects and quotas, UI and CLI. Part of NVIDIA since December 2024.	Proprietary platform. Its scheduler is open source as KAI Scheduler (Apache 2.0).
VirtAI OrionX	GPU pooling software with fractional and remote GPU, from VirtAI Tech (趋动科技).	Closed source. A free community edition and a commercial edition.

Summary

	TensorFusion	HAMi	MIG / MPS / time-slicing	NVIDIA vGPU	NVIDIA Run:ai	VirtAI OrionX
Runs in	Kubernetes Pods	Kubernetes Pods	Bare metal or Pods	Virtual machines	Kubernetes Pods	Containers and VMs
Fractional GPU	Compute and VRAM, per Pod	Compute and memory, per container	MIG: fixed profiles. MPS: per-client limits. Time-slicing: no limits	Fixed vGPU types per VM	GPU memory fractions	Yes
Hardware-level isolation	With `partitioned` mode (MIG, Ascend vNPU)	With dynamic MIG, and vendor partitions such as Ascend vNPU	MIG only	VM boundary, optionally MIG-backed	MIG, but not on the same node as fractions	Not documented publicly
Remote GPU over the network	Yes, mainly NVIDIA	No	No	No	No	Yes
Oversubscription	Compute and VRAM, set per pool	Memory scaling (experimental)	Time-slicing only, without limits	No, frame buffer is reserved	Dynamic fractions and GPU memory swap	Stated by the vendor
Own GPU-aware scheduler	Yes	Yes (scheduler extender)	No, uses the default scheduler	No, uses the hypervisor's placement	Yes	Yes (scheduler plugin)
Autoscaling	Workload GPU resources and GPU nodes	Not built in (on its roadmap)	No	No	Inference replicas, including scale to zero	Not documented publicly
Non-NVIDIA accelerators	Ascend, Moore Threads, Alibaba PPU, in a subset of modes	The widest list of the six	No	No	No	Stated by the vendor
Fully open source	Partly	Yes	Tooling yes, driver no	No	Scheduler only	No

How to choose

You run on virtual machines, or need virtual desktops and graphics workstations. Use NVIDIA vGPU. TensorFusion targets containers and has no VM-level virtual GPU.
You need a hardware boundary between untrusted tenants, and a few fixed slice sizes are enough. MIG alone does this with nothing else to install. TensorFusion can schedule MIG partitions too, through partitioned mode.
Your accelerators are from vendors TensorFusion does not support, such as Cambricon, Hygon, or MetaX, or you require an end-to-end open source stack under foundation governance. Use HAMi.
You want one vendor-supported platform that also covers projects, departments, workspaces, and training and inference workflows on NVIDIA GPUs. Look at NVIDIA Run:ai.
You want fractional GPUs with separate requests and limits, Pods on CPU nodes that use GPUs remotely, oversubscription, and GPU node autoscaling in one Kubernetes operator. This is what TensorFusion is built for.

What TensorFusion does not do

Weigh these before you decide:

Vendor coverage is narrower than HAMi's. NVIDIA is supported in every mode. Huawei Ascend, Moore Threads, and Alibaba PPU work in a subset of modes. AMD is not supported. See the support matrix.
Remote GPU sharing and hard isolation depend on closed-source components. hard isolation works on NVIDIA GPUs only, and remote sharing is verified mainly on NVIDIA.
soft isolation is not a security boundary. Its limiter runs inside the application process. For workloads you do not trust, use hard or partitioned.
No VM-level vGPU. You can call a host GPU from inside a VM through the remote client, but TensorFusion does not present a virtual PCI device to a guest OS.
GPU live migration is a commercial feature and is not part of the open source release.

Detailed comparisons

Next steps

Overview: what TensorFusion does and when not to use it.
Architecture: components and isolation modes.
Deploy in Kubernetes: install TensorFusion and run a first workload.

Overview

How TensorFusion compares with HAMi, NVIDIA MIG/MPS/time-slicing, NVIDIA vGPU, NVIDIA Run:ai and VirtAI OrionX, and when each one is the better choice

This page compares TensorFusion with five other ways to share GPUs, and says when each one fits better. Every solution has a detailed page linked below.

Solutions covered

Solution	What it is	Source and license
TensorFusion	A Kubernetes operator for GPU pooling: fractional GPUs, remote GPU sharing, a GPU-aware scheduler, and autoscaling.	Controller, scheduler, and hypervisor are Apache 2.0. The vendor limiter libraries used by `soft` mode, and the client and worker behind remote GPU sharing and `hard` isolation, are closed source. See Licensing.
HAMi	Kubernetes middleware that shares GPUs and other accelerators from more than ten vendors. A CNCF Incubating project.	Apache 2.0.
MIG, MPS, time-slicing	GPU sharing mechanisms built into NVIDIA's driver and exposed in Kubernetes by the NVIDIA device plugin and GPU Operator.	No extra license. The device plugin and GPU Operator are open source.
NVIDIA vGPU	Hypervisor-level GPU virtualization that gives each virtual machine a virtual GPU.	Proprietary, licensed per product edition.
NVIDIA Run:ai	An AI workload platform on Kubernetes: scheduler, GPU fractions, projects and quotas, UI and CLI. Part of NVIDIA since December 2024.	Proprietary platform. Its scheduler is open source as KAI Scheduler (Apache 2.0).
VirtAI OrionX	GPU pooling software with fractional and remote GPU, from VirtAI Tech (趋动科技).	Closed source. A free community edition and a commercial edition.

Summary

	TensorFusion	HAMi	MIG / MPS / time-slicing	NVIDIA vGPU	NVIDIA Run:ai	VirtAI OrionX
Runs in	Kubernetes Pods	Kubernetes Pods	Bare metal or Pods	Virtual machines	Kubernetes Pods	Containers and VMs
Fractional GPU	Compute and VRAM, per Pod	Compute and memory, per container	MIG: fixed profiles. MPS: per-client limits. Time-slicing: no limits	Fixed vGPU types per VM	GPU memory fractions	Yes
Hardware-level isolation	With `partitioned` mode (MIG, Ascend vNPU)	With dynamic MIG, and vendor partitions such as Ascend vNPU	MIG only	VM boundary, optionally MIG-backed	MIG, but not on the same node as fractions	Not documented publicly
Remote GPU over the network	Yes, mainly NVIDIA	No	No	No	No	Yes
Oversubscription	Compute and VRAM, set per pool	Memory scaling (experimental)	Time-slicing only, without limits	No, frame buffer is reserved	Dynamic fractions and GPU memory swap	Stated by the vendor
Own GPU-aware scheduler	Yes	Yes (scheduler extender)	No, uses the default scheduler	No, uses the hypervisor's placement	Yes	Yes (scheduler plugin)
Autoscaling	Workload GPU resources and GPU nodes	Not built in (on its roadmap)	No	No	Inference replicas, including scale to zero	Not documented publicly
Non-NVIDIA accelerators	Ascend, Moore Threads, Alibaba PPU, in a subset of modes	The widest list of the six	No	No	No	Stated by the vendor
Fully open source	Partly	Yes	Tooling yes, driver no	No	Scheduler only	No

How to choose

You run on virtual machines, or need virtual desktops and graphics workstations. Use NVIDIA vGPU. TensorFusion targets containers and has no VM-level virtual GPU.
You need a hardware boundary between untrusted tenants, and a few fixed slice sizes are enough. MIG alone does this with nothing else to install. TensorFusion can schedule MIG partitions too, through partitioned mode.
Your accelerators are from vendors TensorFusion does not support, such as Cambricon, Hygon, or MetaX, or you require an end-to-end open source stack under foundation governance. Use HAMi.
You want one vendor-supported platform that also covers projects, departments, workspaces, and training and inference workflows on NVIDIA GPUs. Look at NVIDIA Run:ai.
You want fractional GPUs with separate requests and limits, Pods on CPU nodes that use GPUs remotely, oversubscription, and GPU node autoscaling in one Kubernetes operator. This is what TensorFusion is built for.

What TensorFusion does not do

Weigh these before you decide:

Vendor coverage is narrower than HAMi's. NVIDIA is supported in every mode. Huawei Ascend, Moore Threads, and Alibaba PPU work in a subset of modes. AMD is not supported. See the support matrix.
Remote GPU sharing and hard isolation depend on closed-source components. hard isolation works on NVIDIA GPUs only, and remote sharing is verified mainly on NVIDIA.
soft isolation is not a security boundary. Its limiter runs inside the application process. For workloads you do not trust, use hard or partitioned.
No VM-level vGPU. You can call a host GPU from inside a VM through the remote client, but TensorFusion does not present a virtual PCI device to a guest OS.
GPU live migration is a commercial feature and is not part of the open source release.

Detailed comparisons

Next steps

Overview: what TensorFusion does and when not to use it.
Architecture: components and isolation modes.
Deploy in Kubernetes: install TensorFusion and run a first workload.

Solutions covered

Summary

How to choose

What TensorFusion does not do

Detailed comparisons

Next steps

Table of Contents

Overview

Solutions covered

Summary

How to choose

What TensorFusion does not do

Detailed comparisons

Next steps

Table of Contents