与 NVIDIA Run:ai 对比

TensorFusion 与 NVIDIA Run:ai 在定位、GPU 共享、调度和许可上的差异，以及各自适合的场景

NVIDIA Run:ai（原 Run.AI）是在 Kubernetes 上运行 AI 工作负载的商业平台，NVIDIA 于 2024 年 12 月完成对它的收购。两个产品在 GPU 切分和 GPU 感知调度上有重合，但面向的层次不同：Run:ai 是给数据科学团队用的完整平台，有项目、部门、工作空间，以及自己的 UI 和 CLI；TensorFusion 是基础设施层的 operator，尽量保持原生 Kubernetes 的用法，在此之上提供算力限额、远程 GPU 共享和 GPU 节点自动伸缩。

一览

	TensorFusion	NVIDIA Run:ai
许可	controller、调度器、hypervisor 为 Apache 2.0；各厂商 limiter 库以及远程 client 与 worker 不开源。	平台为专有软件；调度器已开源为 KAI Scheduler（Apache 2.0）。
部署方式	在集群里安装 Helm chart；云端控制台可选。	控制面可选 SaaS 或自托管，另在每个 Kubernetes 集群里安装集群组件。
加速卡	NVIDIA，以及支持部分模式的华为昇腾、摩尔线程、阿里 PPU。	NVIDIA GPU。
Pod 如何申请 GPU	在 Pod 模板上加标签和注解，或引用 `WorkloadProfile`。	通过 Run:ai 的 UI、CLI 或 API；普通 Pod 可以用 `gpu-fraction` 等注解，并设置 `schedulerName: runai-scheduler`。
GPU 切分：显存	每个 Pod 设置显存请求和限额。	按 GPU 显存的比例或 MiB 数值切分，按工作负载强制执行；使用 dynamic fraction 时可分别设置请求和限额。
GPU 切分：算力	以 TFLOPS 或百分比设置请求和限额，由 `soft` 或 `hard` 模式执行。	fraction 只切分显存。算力通过时间片共享：默认用 NVIDIA 的 Time-slicing，也可以用 Run:ai 自己的实现。
硬件分区	`partitioned` 模式：NVIDIA MIG 和昇腾 vNPU。	支持 MIG，但不能和 fraction 用在同一节点。
通过网络远程使用 GPU	支持，以 NVIDIA GPU 为主，见支持矩阵。	不支持。
超额分配	按资源池设置：算力超卖倍数，以及主机内存、磁盘计入可调度显存的比例。	dynamic fraction 把空闲显存借给工作负载，最多到限额；GPU memory swap 把工作负载的显存换出到预留的主机内存。
调度	紧凑装箱或负载均摊、GPU 拓扑感知、Gang 调度、命名空间配额、四级 QoS。	项目和部门之间公平共享、工作负载优先级、Gang 调度、层级队列。
自动伸缩	根据用量调整 GPU 请求与限额；通过 Karpenter 或云厂商 API 增减 GPU 节点。	推理工作负载自动伸缩副本数，可以缩到零。
平台功能	指标、告警规则、可选的云端控制台。	Jupyter Notebook 等工作空间、训练与推理流程、角色与策略，以及与主流 ML 框架的集成。

主要差异

定位

Run:ai 覆盖的流程更长。研究人员通过它的 UI 或 CLI 提交 Notebook、训练任务和推理服务，管理员把集群资源划分给部门和项目。如果想用一个产品管起这一整套，并由 NVIDIA 提供支持，Run:ai 能做到，TensorFusion 不能。

TensorFusion 只做到基础设施层。你仍然用 Deployment、Job、Helm 或自己的平台部署应用，TensorFusion 只改变这些 Pod 获得 GPU 的方式。

GPU 共享

两者都会按工作负载强制限制显存，区别在算力：

Run:ai 的 fraction 切分的是显存，同一张 GPU 上的工作负载靠时间片共享算力。
TensorFusion 还为每个工作负载设置算力请求和限额，都繁忙时，小服务抢不走大服务应得的算力。

两者都能让分配量超过物理 GPU：Run:ai 靠 dynamic fraction 和 memory swap，TensorFusion 靠资源池级别的超卖比例。让没有 GPU 的节点上的 Pod 使用其他节点的 GPU，只有 TensorFusion 支持。

开放程度

Run:ai 的调度器已经开源为 KAI Scheduler，包含 GPU 共享、Gang 调度和层级队列。平台的其余部分，包括控制面和 UI，是专有软件。

TensorFusion 的 controller、调度器和 hypervisor 开源，远程 GPU 的 client 和 worker 不开源。无论选哪一个，都要先列出自己需要的功能，再看它们落在开源还是闭源的部分。

申请 GPU 的写法

Run:ai，使用普通 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: app
  annotations:
    gpu-fraction: "0.5"   # 一张 GPU 显存的一半
spec:
  schedulerName: runai-scheduler
  containers:
    - name: app
      image: pytorch/pytorch:2.6.0-cuda12.4-cudnn9-runtime

TensorFusion：

apiVersion: v1
kind: Pod
metadata:
  name: app
  labels:
    tensor-fusion.ai/enabled: "true"
  annotations:
    tensor-fusion.ai/tflops-request: "10"
    tensor-fusion.ai/tflops-limit: "20"
    tensor-fusion.ai/vram-request: "4Gi"
    tensor-fusion.ai/vram-limit: "4Gi"
spec:
  containers:
    - name: app
      image: pytorch/pytorch:2.6.0-cuda12.4-cudnn9-runtime

使用 TensorFusion 时不用自己写 schedulerName，webhook 看到标签后会自动设置。全部注解的说明见创建工作负载。

怎么选

以下情况选 NVIDIA Run:ai：

想要一个面向数据科学团队的完整平台，而不只是 GPU 共享。
组织需要按部门和项目划分资源并在它们之间公平共享，而且要在 UI 上管理。
只使用 NVIDIA GPU，并希望软件和支持来自同一家厂商。
可以接受商业授权，以及 SaaS 或自托管的控制面。

以下情况选 TensorFusion：

已经有自己的部署方式，只想加几条注解就用上 GPU 共享。
不只要限制显存，还要限制 GPU 算力。
需要 CPU 节点上的 Pod 远程使用 GPU，或者需要 GPU 节点随需求伸缩。
使用 TensorFusion 已支持的非 NVIDIA 加速卡。
希望控制链路（调度器、controller、hypervisor）是开源的。

如果只需要一个带 GPU 共享和队列的开源调度器，也可以单独评估 KAI Scheduler。

参考资料

核对时间为 2026 年 10 月：

NVIDIA Run:ai 文档：平台概览、部署方式。
GPU fractions、Dynamic GPU fractions 和 GPU memory swap。
NVIDIA open sources Run:ai Scheduler：KAI Scheduler。

一览

	TensorFusion	NVIDIA Run:ai
许可	controller、调度器、hypervisor 为 Apache 2.0；各厂商 limiter 库以及远程 client 与 worker 不开源。	平台为专有软件；调度器已开源为 KAI Scheduler（Apache 2.0）。
部署方式	在集群里安装 Helm chart；云端控制台可选。	控制面可选 SaaS 或自托管，另在每个 Kubernetes 集群里安装集群组件。
加速卡	NVIDIA，以及支持部分模式的华为昇腾、摩尔线程、阿里 PPU。	NVIDIA GPU。
Pod 如何申请 GPU	在 Pod 模板上加标签和注解，或引用 `WorkloadProfile`。	通过 Run:ai 的 UI、CLI 或 API；普通 Pod 可以用 `gpu-fraction` 等注解，并设置 `schedulerName: runai-scheduler`。
GPU 切分：显存	每个 Pod 设置显存请求和限额。	按 GPU 显存的比例或 MiB 数值切分，按工作负载强制执行；使用 dynamic fraction 时可分别设置请求和限额。
GPU 切分：算力	以 TFLOPS 或百分比设置请求和限额，由 `soft` 或 `hard` 模式执行。	fraction 只切分显存。算力通过时间片共享：默认用 NVIDIA 的 Time-slicing，也可以用 Run:ai 自己的实现。
硬件分区	`partitioned` 模式：NVIDIA MIG 和昇腾 vNPU。	支持 MIG，但不能和 fraction 用在同一节点。
通过网络远程使用 GPU	支持，以 NVIDIA GPU 为主，见支持矩阵。	不支持。
超额分配	按资源池设置：算力超卖倍数，以及主机内存、磁盘计入可调度显存的比例。	dynamic fraction 把空闲显存借给工作负载，最多到限额；GPU memory swap 把工作负载的显存换出到预留的主机内存。
调度	紧凑装箱或负载均摊、GPU 拓扑感知、Gang 调度、命名空间配额、四级 QoS。	项目和部门之间公平共享、工作负载优先级、Gang 调度、层级队列。
自动伸缩	根据用量调整 GPU 请求与限额；通过 Karpenter 或云厂商 API 增减 GPU 节点。	推理工作负载自动伸缩副本数，可以缩到零。
平台功能	指标、告警规则、可选的云端控制台。	Jupyter Notebook 等工作空间、训练与推理流程、角色与策略，以及与主流 ML 框架的集成。

Run:ai 的 fraction 切分的是显存，同一张 GPU 上的工作负载靠时间片共享算力。
TensorFusion 还为每个工作负载设置算力请求和限额，都繁忙时，小服务抢不走大服务应得的算力。

开放程度

Run:ai 的调度器已经开源为 KAI Scheduler，包含 GPU 共享、Gang 调度和层级队列。平台的其余部分，包括控制面和 UI，是专有软件。

申请 GPU 的写法

Run:ai，使用普通 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: app
  annotations:
    gpu-fraction: "0.5"   # 一张 GPU 显存的一半
spec:
  schedulerName: runai-scheduler
  containers:
    - name: app
      image: pytorch/pytorch:2.6.0-cuda12.4-cudnn9-runtime

TensorFusion：

apiVersion: v1
kind: Pod
metadata:
  name: app
  labels:
    tensor-fusion.ai/enabled: "true"
  annotations:
    tensor-fusion.ai/tflops-request: "10"
    tensor-fusion.ai/tflops-limit: "20"
    tensor-fusion.ai/vram-request: "4Gi"
    tensor-fusion.ai/vram-limit: "4Gi"
spec:
  containers:
    - name: app
      image: pytorch/pytorch:2.6.0-cuda12.4-cudnn9-runtime

使用 TensorFusion 时不用自己写 schedulerName，webhook 看到标签后会自动设置。全部注解的说明见创建工作负载。

怎么选

以下情况选 NVIDIA Run:ai：

想要一个面向数据科学团队的完整平台，而不只是 GPU 共享。
组织需要按部门和项目划分资源并在它们之间公平共享，而且要在 UI 上管理。
只使用 NVIDIA GPU，并希望软件和支持来自同一家厂商。
可以接受商业授权，以及 SaaS 或自托管的控制面。

以下情况选 TensorFusion：

已经有自己的部署方式，只想加几条注解就用上 GPU 共享。
不只要限制显存，还要限制 GPU 算力。
需要 CPU 节点上的 Pod 远程使用 GPU，或者需要 GPU 节点随需求伸缩。
使用 TensorFusion 已支持的非 NVIDIA 加速卡。
希望控制链路（调度器、controller、hypervisor）是开源的。

如果只需要一个带 GPU 共享和队列的开源调度器，也可以单独评估 KAI Scheduler。

参考资料

核对时间为 2026 年 10 月：

NVIDIA Run:ai 文档：平台概览、部署方式。
GPU fractions、Dynamic GPU fractions 和 GPU memory swap。
NVIDIA open sources Run:ai Scheduler：KAI Scheduler。

一览

主要差异

定位

GPU 共享

开放程度

申请 GPU 的写法

怎么选

参考资料

目录

与 NVIDIA Run:ai 对比

一览

主要差异

定位

GPU 共享

开放程度

申请 GPU 的写法

怎么选

参考资料

目录