与 HAMi 的对比

从架构、隔离、弹性、成本归集、实测开销到许可，按十一个维度对比 TensorFusion 与 HAMi，以及各自适合的场景

HAMi（Heterogeneous AI Computing Virtualization Middleware）是 Kubernetes 上的开源异构算力共享中间件，也是 CNCF 孵化（Incubating）项目。在本系列对比的方案里，它和 TensorFusion 重合最多：两者都按算力和显存为容器切分 GPU，都在容器里加载一个库来执行限额，也都自带 GPU 感知调度器。

简要结论：

HAMi 更强的地方：加速卡覆盖（十多家厂商）、开放程度（全部组件 Apache 2.0，由 CNCF 治理）、社区规模，以及与 Kubernetes 现有约定的贴合（标准扩展资源、ResourceQuota、Volcano、Kueue、Koordinator、KAI Scheduler，以及 DRA 驱动）。
TensorFusion 更强的地方：切分之外的部分。请求与限额分开设置并带 QoS 等级、运行中调整限额、进程级和跨节点隔离、GPU-over-IP、通过 Karpenter 自动伸缩 GPU 节点、按用量自动调整规格，以及按工作负载的成本数据。

关于 TensorFusion 的描述以当前版本为准；关于 HAMi 的描述来自其公开文档和发布说明，核对于 2026 年 10 月，来源见参考资料。

一览

维度	TensorFusion	HAMi
架构与安装	一个 controller（webhook、调度器、CRD 控制器在同一进程）、带自有 device plugin 的 hypervisor DaemonSet，以及存放指标的 GreptimeDB。	Mutating webhook、与 kube-scheduler 并行的 scheduler extender，每家厂商一个 device plugin。
隔离	四种模式：`shared`、`soft`（进程内 limiter）、`hard`（独立 worker 进程）、`partitioned`（MIG、昇腾 vNPU）。远程模式再加一层节点边界。	HAMi-core：进程内拦截 CUDA 调用的库。NVIDIA 上支持动态 MIG。
切分粒度与资源模型	算力用 TFLOPS 或百分比，显存用字节；请求与限额分开设置。	显存用 MiB 或百分比，算力用百分比，另有设备数量；每种资源只有一个值。
调度	基于 kube-scheduler 的自有调度器：紧凑装箱或负载均摊、NUMA 与 GPU 互联拓扑、Gang 调度、命名空间配额、四级 QoS。	Scheduler extender：节点级和 GPU 级的 binpack、spread、mutex 策略，拓扑与 NUMA 感知，GPU 显存的 `ResourceQuota`，PodGroup Gang 调度（v2.10）。队列通过 Volcano、Kueue 或 KAI Scheduler。
弹性	通过 Karpenter 或云厂商 API 增减 GPU 节点、节点压缩、按用量调整请求与限额、按资源池超额分配算力和显存。	未内置节点供给和规格调整（Cluster Autoscaler 支持处于设计阶段）。设备显存缩放比例可大于 1（实验特性）。
远程 GPU 与虚拟机	CPU 节点上的 Pod 通过网络使用 GPU（GPU-over-IP）；宿主机 GPU 共享给虚拟机（HyperGPU），支持 Windows 客户机，限计算类 API。	不支持。
硬件覆盖	NVIDIA 支持全部模式；华为昇腾、摩尔线程、阿里 PPU 支持部分模式。	NVIDIA、AMD Instinct、昇腾、寒武纪、海光、天数智芯、昆仑芯、沐曦、摩尔线程、燧原、AWS Neuron、壁仞、瀚博；各厂商能力不同。
可观测性与成本	每个工作负载的算力与显存用量、告警规则、按 QoS 等级和 GPU 型号设置单价、用于分摊与展示的成本指标、可选云端控制台。	Prometheus 指标、Grafana 看板、HAMi-WebUI。没有成本归集。
性能开销	`soft` 不设限时与原生相差 1% 以内（T4 实测）。API 远程化（`hard`、远程）随工作负载变化，见下文。	上游基准：A100 上的 vLLM，v2.9 延迟比原生高约 1–3%。
兼容与迁移	可与 NVIDIA GPU Operator 共存；可以接管申请 `nvidia.com/gpu` 的 Pod。	依赖 NVIDIA container toolkit；在其管理的节点上取代 NVIDIA device plugin。
许可与支持	controller、调度器、hypervisor 为 Apache 2.0。各厂商 limiter 与远程 client/worker 不开源，10 卡以下免费。NexusGPU 提供商业支持。	全部组件 Apache 2.0。2026 年 7 月起为 CNCF 孵化项目。Dynamia 提供企业版和支持。

功能清单

这份清单是本页早期版本功能矩阵的更新版。“部分”的含义见各维度对应章节。

功能	TensorFusion	HAMi
共享
GPU 切分：显存限额	✅	✅
GPU 切分：算力限额	✅	✅
请求与限额分开（可突发到请求量以上）	✅	❌
Pod 运行中调整限额	✅	❌
进程级隔离（GPU 调用在应用进程外执行）	✅ `hard`	❌
硬件分区（MIG 等）	✅ MIG、昇腾 vNPU	✅ 动态 MIG、厂商模板
单个 Pod 使用多张 GPU	✅	✅
超额分配	✅ 算力和显存	部分，显存缩放（实验特性）
主机内存或磁盘计入可调度显存	✅	❌
远程 GPU（GPU-over-IP）	✅ 以 NVIDIA 为主	❌
虚拟机使用宿主机 GPU	✅ 计算类 API，Linux 与 Windows	❌
调度
GPU 感知调度器	✅ 内置	✅ extender
紧凑装箱与负载均摊	✅	✅
GPU 拓扑感知	✅	✅
Gang 调度	✅ 内置	✅ PodGroup（v2.10），或通过 Volcano
命名空间 GPU 配额	✅ `GPUResourceQuota`	✅ 针对显存和算力的 `ResourceQuota`
QoS 等级与优先级	✅ 四级	部分，NVIDIA 上两级优先级
动态资源分配（DRA）	❌	✅ 独立的 HAMi-DRA 驱动
运维
GPU 节点自动伸缩（Karpenter、云 API）	✅	❌
节点压缩与碎片整理	✅	❌
按用量自动调整 GPU 限额	✅	❌
指标与看板	✅	✅
告警规则	✅ 内置	部分，需自行编写 Prometheus 规则
按工作负载的成本归集	✅	❌
Web 控制台	✅ 可选云端控制台	✅ HAMi-WebUI
GPU 热迁移	商业版	❌
平台
NVIDIA 以外的厂商	部分，三家	✅ 十多家
完全开源	部分	✅
基金会治理	❌	✅ CNCF

HAMi 沿用 Kubernetes 已有的扩展点。它的 Helm chart 安装一个 mutating webhook、一个与 kube-scheduler 并行运行的 scheduler extender、每家启用厂商的 device plugin，以及导出容器级指标的监控组件。GPU 节点打上 gpu=on 标签才会纳管；NVIDIA 节点需要把 NVIDIA container runtime 设为默认运行时（或使用 CDI）。除此之外没有其他依赖，安装量小、容易理解。对于转向动态资源分配（DRA）的集群，HAMi 另外提供独立的 DRA 驱动和 webhook（HAMi-DRA，需要 Kubernetes 1.34 及以上）。

TensorFusion 自己承担的部分更多。一个 Helm chart 部署：

controller：单个进程，包含 CRD 控制器、Pod webhook，以及基于 kube-scheduler 的调度器（GPU Pod 使用它，其他 Pod 仍用默认调度器）；
每个 GPU 节点上的 hypervisor DaemonSet：发现设备、运行 TensorFusion 自己的 device plugin、写入每个 Pod 的限额；
存放指标和日志的 GreptimeDB 与 Vector，以及可选的、把集群接入云端控制台的 agent。

多出来的组件承载的正是 HAMi 交给其他项目的功能：节点供给、自动伸缩、指标和成本数据。如果只需要本地 GPU 切分，HAMi 要运维的东西更少。

隔离

两者都用容器内的库执行软件限额，区别在这个库周围的机制。

	TensorFusion	HAMi
显存	所有模式都按 Pod 限制。`soft` 模式下，limiter 拒绝超出限额的分配。	由 HAMi-core 拦截 CUDA 显存分配调用，超出限额时返回显存不足。NVML 同样被拦截，容器内 `nvidia-smi` 显示的是限额。
算力	`soft`：limiter 内的令牌桶，由节点 hypervisor 中跟踪设备忙碌时间的控制环路补充令牌。`hard`：worker 给工作负载分配固定份额的 SM。	HAMi-core 用令牌桶节流 `cuLaunchKernel`；后台线程采样 GPU 利用率并补充令牌，使用量收敛到算力百分比。
运行时调整限额	支持。hypervisor 改写共享内存中的配额，自动伸缩、定时规则和 QoS 都依赖它。	不支持，限额在容器启动时确定。
故障与安全隔离	`soft` 不是安全边界。`hard` 把 GPU 调用放到独立的 worker 进程；远程模式把 worker 放到另一个节点；`partitioned` 提供硬件边界。	HAMi-core 在进程内；其文档把限额描述为软限制、噪声隔离为尽力而为，直接调用驱动可以绕过。动态 MIG 在 Ampere、Hopper、Blackwell 上提供硬件边界。
镜像要求	`soft` 需要基于 glibc 的镜像（limiter 通过 `/etc/ld.so.preload` 加载）。	HAMi-core 同样通过 `/etc/ld.so.preload` 加载，要求相同。

T4 实测（2026 年 10 月）：soft 算力限额 50% 时设备忙碌时间为 53%，25% 时为 26%；把运行中的 Pod 从 100% 调到 30%，在定时窗口内生效，窗口结束后恢复。吞吐与忙碌时间不是线性关系，50% 限额下的吞吐可能高于满载的 50%，见性能开销。

切分粒度与资源模型

HAMi 沿用 Kubernetes 标准资源写法：nvidia.com/gpu 表示设备数量，nvidia.com/gpumem 或 nvidia.com/gpumem-percentage 表示显存，nvidia.com/gpucores 表示算力百分比。认识扩展资源的工具照常可用，ResourceQuota 也能统计它们。

TensorFusion 用 Pod 注解或 WorkloadProfile 描述资源：

算力可以用 TFLOPS 表示。调度器知道每种 GPU 型号的 FP16 TFLOPS，所以“10 TFLOPS”在 T4 和 A100 上是同样的计算量，而“30%”不是。也支持百分比。
每种资源都有请求和限额。调度器按请求装箱，limiter 按限额执行，与 Kubernetes 对 CPU 和内存的处理一致。
工作负载换到另一种 GPU 型号时不必改数值。

调度

	TensorFusion	HAMi
接入方式	基于 kube-scheduler 加 GPU 插件构建的自有调度器（`tensor-fusion-scheduler`）。	由 kube-scheduler 调用的 scheduler extender（`hami-scheduler`）；另有 Volcano 的 vGPU device plugin、Kueue 集成，以及 KAI Scheduler 的资源隔离组件。
放置策略	按资源池选择紧凑装箱或负载均摊，节点级和 GPU 级。	节点和 GPU 分别设置 `binpack` 或 `spread`，可按 Pod 指定；`mutex` 独占一张卡。
拓扑	多卡 Pod 按 NUMA 和 GPU 互联选择。	NVIDIA 上基于 `nvidia-smi topo` 的拓扑策略，昆仑芯、燧原、沐曦的厂商拓扑，可选的 CPU/GPU NUMA 对齐（v2.10）。
Gang 调度	内置。	v2.10 起支持 PodGroup；队列与公平性通过 Volcano 或 Kueue。
配额	按命名空间的 `GPUResourceQuota`，以 TFLOPS 和显存计。	`ResourceQuota` 中的 `limits.nvidia.com/gpumem` 等，由 webhook 校验。
优先级	四级 QoS，对应 PriorityClass 和空闲算力的分配比例。	`nvidia.com/priority`：同一张卡上，高优先级任务会暂停低优先级任务。
设备选择	厂商、GPU 型号、隔离模式、资源池。	通过注解指定 GPU 类型和 UUID。

如果集群已经用 Volcano、Kueue 或 KAI Scheduler 管理队列和公平性，HAMi 可以直接接入。TensorFusion 的调度器则是替换这一层（对 GPU Pod 而言），而不是接入它。

弹性

这是两者差别最大的地方。

GPU 节点自动伸缩。 Pod 处于 Pending 时，TensorFusion 通过 Karpenter NodeClaim 或云厂商 API 创建 GPU 节点，并释放被压缩腾空的节点。在阿里云 ACK + Karpenter + T4 的测试中，三个 20% 的 Pod 只拉起一个节点而不是三个，成本比整卡方案低 72%。HAMi 没有节点供给，使用你或 Cluster Autoscaler 提供的节点；v2.10 加入了 Cluster Autoscaler 扩容模拟的设计文档，自动伸缩在其路线图上。
垂直伸缩。 TensorFusion 根据历史用量推荐并应用 GPU 请求与限额，也支持在某个时间窗口内调整限额的定时规则，原地生效，不重启 Pod。HAMi 的限额在容器生命周期内固定。
超额分配。 TensorFusion 按资源池设置算力超卖倍数，并可把主机内存和磁盘计入可调度显存。HAMi 支持大于 1 的设备显存缩放比例，标注为实验特性。

远程 GPU 与虚拟机

TensorFusion 可以让 Pod 运行在没有 GPU 的节点上，由 GPU 节点上的 worker 执行它的 GPU 调用（GPU-over-IP）。同一套 client 和 worker 也能让虚拟机在不直通的情况下使用宿主机 GPU，支持 Linux 和 Windows 客户机，覆盖 CUDA 和 NVML，不包括图形 API。这些路径基于 API 远程化，调用密集的工作负载会有性能损失，见性能开销。

HAMi 只在 GPU 所在节点上的容器之间共享。

硬件与厂商覆盖

HAMi 明显领先。其设备列表包括 NVIDIA、AMD Instinct、华为昇腾、寒武纪、海光 DCU、天数智芯、昆仑芯、沐曦、摩尔线程、燧原、AWS Neuron、壁仞和瀚博。多数厂商支持显存和算力限额（昆仑芯只限显存，AWS Neuron 按核心分配，壁仞和瀚博按整卡共享），部分通过厂商自身的分区实现，例如昇腾 vNPU 模板。只有 NVIDIA 支持一个任务同时使用多张卡的切分份额。

TensorFusion 在 NVIDIA 上支持全部模式，华为昇腾、摩尔线程、阿里 PPU 支持部分模式。AMD 只有骨架实现，尚不支持；寒武纪、海光、沐曦不支持。具体组合见支持矩阵。

可观测性、计量与成本归集

HAMi 导出设备和容器的显存、算力用量 Prometheus 指标，提供 Grafana 看板，并有 HAMi-WebUI 展示集群视图。

TensorFusion 把 GPU、节点、资源池和工作负载指标写入集群内的 GreptimeDB，并评估内置告警规则。它还为用量定价：按 QoS 等级设置单价、按 GPU 型号设置小时成本，记录每个工作负载和节点的成本，用于内部分摊和展示。它不开发票，也不强制预算。见配置 QoS 与计费。

性能开销

两个项目都没有在同一硬件上发布过对照测试，我们也没有自己测过 HAMi。下面两组数字来自不同的 GPU 和工作负载，只能作量级比较。

HAMi，来自其基准测试页：A100 40GB 上用 vLLM 服务 Qwen3-8B，batch 1，以 NVIDIA device plugin 为基线。HAMi v2.9.0 的首 token 时间和每 token 延迟增加约 1–3%（v2.8.0 为约 8–13%）。该页没有给出争用场景下的结果，也没有给出算力限额的准确度。

TensorFusion soft 隔离，阿里云 ACK、NVIDIA T4，2026 年 10 月，限额设为 100%，与不使用 TensorFusion 的同一工作负载比较：

工作负载	吞吐相对原生
vLLM，Qwen3-0.6B，8 路并发流式请求	−0.4%，每输出 token 时间相同
ONNX Runtime，resnet50 / MiniLM	−0.2% / −0.3%
TorchBench，resnet50 / bert_base / tiny_mlp	−0.8% / −0.6% / +0.3%

设了限额后，吞吐随份额变化但不是线性的：50% 限额下 vLLM 保留 74% 的吞吐；两个 50% 租户同在一张 T4 上，合计吞吐达到单个租户独占时的 115%。仍有两个未解决的问题：50% 限额下长卷积 kernel 的尾延迟增长超过比例；在矩阵乘循环上，25% 限额的吞吐比份额低约 15%。

API 远程化（hard 隔离和远程 GPU）对每次 GPU 调用都有固定开销。在已发布的基准测试（2025 年 7 月，TorchBench 推理）中，worker 作为同节点的独立进程时，损耗随模型在约 1% 到 38% 之间，平均 12%。加入 0.3 ms 和 1 ms 网络延迟后，平均损耗升到 41% 和 128%；GPU 调用少而长的模型（BERT_pytorch、hf_clip、hf_distil_whisper）即使在 1 ms 下也在 11% 以内。依赖远程模式前，请先测自己的工作负载。

兼容与迁移

HAMi 在其管理的节点上取代 NVIDIA device plugin，并依赖 NVIDIA container toolkit。迁移到 HAMi 需要给节点打标签、修改 Pod 中的资源名。

TensorFusion 可以与 NVIDIA GPU Operator 共存（节点上有其校验文件时设置 controller.compatibleWithNvidiaContainerToolkit: true），并能通过 Helm values 接管申请 nvidia.com/gpu 的 Pod，无需修改清单。推荐先按整卡迁移，再缩到实际用量对应的份额。见迁移现有工作负载。

在 HAMi 和 TensorFusion 之间迁移，要改的是 Pod 申请 GPU 的方式：HAMi 用 resources.limits 中的扩展资源，TensorFusion 用标签和注解。两者可以在同一集群的不同节点组上同时运行。

许可、治理与支持

	TensorFusion	HAMi
开源部分	controller、调度器、hypervisor 和 CRD：Apache 2.0，位于 NexusGPU/tensor-fusion。	全部组件，包括 HAMi-core：Apache 2.0。
闭源部分	`soft` 模式使用的各厂商 limiter 库，以及 `hard` 和远程模式的 client 与 worker。以公开镜像分发；client 和 worker 对 GPU 总数少于 10 张的组织免费，需要 license 文件。	无。
治理	由 NexusGPU 开发。	2024 年 8 月进入 CNCF Sandbox，2026 年 7 月成为孵化项目；维护者来自 Dynamia、NVIDIA 和独立贡献者。GitHub 约 4,700 星。
商业	NexusGPU：商业许可、热迁移、技术支持。	Dynamia 销售基于 HAMi 的企业版并提供支持。

总拥有成本

小规模、仅本地共享。 如果团队熟悉 Kubernetes、Prometheus 和 GPU 节点运维，HAMi 开源版很合适，没有许可费用。TensorFusion 的开源组件也覆盖这一场景。
规模更大或在云上。 节省主要不来自切分本身，而来自少用节点：把切分后的工作负载装到更少的 GPU 上、释放空节点、按用量调整限额。TensorFusion 自动完成这个闭环；用 HAMi 则需要结合 Cluster Autoscaler、自建监控和人工调优来实现。
需要远程或虚拟机访问，或 hard 隔离。 只有 TensorFusion 提供，且依赖其闭源组件，超过 10 卡需要许可。

申请 GPU 的写法

HAMi：

spec:
  containers:
    - name: app
      image: pytorch/pytorch:2.6.0-cuda12.4-cudnn9-runtime
      resources:
        limits:
          nvidia.com/gpu: 1        # GPU 数量
          nvidia.com/gpumem: 4096  # 每张卡的显存，单位 MiB
          nvidia.com/gpucores: 30  # 每张卡的算力百分比

TensorFusion：

metadata:
  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

如果要按单卡百分比而不是 TFLOPS 申请算力，使用 tensor-fusion.ai/compute-percent-request 和 tensor-fusion.ai/compute-percent-limit。全部注解见创建工作负载。

如何选择

以下情况选 HAMi：

使用 TensorFusion 尚未支持的加速卡，或一个集群里有多家厂商。
要求全部组件开源，或希望项目由 CNCF 治理。
已经在用 Volcano、Kueue、Koordinator 或 KAI Scheduler，或正在转向 DRA，希望 GPU 共享直接接入。
只需要固定限额的本地 GPU 切分，并且希望组件尽量少。

以下情况选 TensorFusion：

在云上运行，希望少用 GPU 节点：紧凑装箱、通过 Karpenter 自动伸缩节点、释放空节点。
希望根据实际用量调整 GPU 限额，并且不重启 Pod。
希望 GPU 算力有请求和限额，由 QoS 等级决定空闲算力归谁。
CPU 节点上的 Pod 或虚拟机需要使用其他机器上的 GPU。
需要按工作负载的成本数据做内部分摊。

参考资料

TensorFusion 的测量数据：NexusGPU/tensor-fusion 中的端到端测试（e2e/ack/TEST-SUMMARY.md，2026 年 10 月）和基准测试页。

HAMi，核对于 2026 年 10 月：

HAMi README：功能、支持的设备、前置条件。
HAMi 发布说明：核对时最新版本为 v2.10.0（2026 年 8 月）。
HAMi-core：显存和算力限额的实现方式。
HAMi 配置说明：资源名、调度策略、设备显存缩放。
支持的设备和基准测试。
HAMi-DRA 与 HAMi-WebUI。
HAMi becomes a CNCF incubating project，CNCF 博客，2026 年 7 月。

简要结论：

HAMi 更强的地方：加速卡覆盖（十多家厂商）、开放程度（全部组件 Apache 2.0，由 CNCF 治理）、社区规模，以及与 Kubernetes 现有约定的贴合（标准扩展资源、ResourceQuota、Volcano、Kueue、Koordinator、KAI Scheduler，以及 DRA 驱动）。
TensorFusion 更强的地方：切分之外的部分。请求与限额分开设置并带 QoS 等级、运行中调整限额、进程级和跨节点隔离、GPU-over-IP、通过 Karpenter 自动伸缩 GPU 节点、按用量自动调整规格，以及按工作负载的成本数据。

关于 TensorFusion 的描述以当前版本为准；关于 HAMi 的描述来自其公开文档和发布说明，核对于 2026 年 10 月，来源见参考资料。

一览

维度	TensorFusion	HAMi
架构与安装	一个 controller（webhook、调度器、CRD 控制器在同一进程）、带自有 device plugin 的 hypervisor DaemonSet，以及存放指标的 GreptimeDB。	Mutating webhook、与 kube-scheduler 并行的 scheduler extender，每家厂商一个 device plugin。
隔离	四种模式：`shared`、`soft`（进程内 limiter）、`hard`（独立 worker 进程）、`partitioned`（MIG、昇腾 vNPU）。远程模式再加一层节点边界。	HAMi-core：进程内拦截 CUDA 调用的库。NVIDIA 上支持动态 MIG。
切分粒度与资源模型	算力用 TFLOPS 或百分比，显存用字节；请求与限额分开设置。	显存用 MiB 或百分比，算力用百分比，另有设备数量；每种资源只有一个值。
调度	基于 kube-scheduler 的自有调度器：紧凑装箱或负载均摊、NUMA 与 GPU 互联拓扑、Gang 调度、命名空间配额、四级 QoS。	Scheduler extender：节点级和 GPU 级的 binpack、spread、mutex 策略，拓扑与 NUMA 感知，GPU 显存的 `ResourceQuota`，PodGroup Gang 调度（v2.10）。队列通过 Volcano、Kueue 或 KAI Scheduler。
弹性	通过 Karpenter 或云厂商 API 增减 GPU 节点、节点压缩、按用量调整请求与限额、按资源池超额分配算力和显存。	未内置节点供给和规格调整（Cluster Autoscaler 支持处于设计阶段）。设备显存缩放比例可大于 1（实验特性）。
远程 GPU 与虚拟机	CPU 节点上的 Pod 通过网络使用 GPU（GPU-over-IP）；宿主机 GPU 共享给虚拟机（HyperGPU），支持 Windows 客户机，限计算类 API。	不支持。
硬件覆盖	NVIDIA 支持全部模式；华为昇腾、摩尔线程、阿里 PPU 支持部分模式。	NVIDIA、AMD Instinct、昇腾、寒武纪、海光、天数智芯、昆仑芯、沐曦、摩尔线程、燧原、AWS Neuron、壁仞、瀚博；各厂商能力不同。
可观测性与成本	每个工作负载的算力与显存用量、告警规则、按 QoS 等级和 GPU 型号设置单价、用于分摊与展示的成本指标、可选云端控制台。	Prometheus 指标、Grafana 看板、HAMi-WebUI。没有成本归集。
性能开销	`soft` 不设限时与原生相差 1% 以内（T4 实测）。API 远程化（`hard`、远程）随工作负载变化，见下文。	上游基准：A100 上的 vLLM，v2.9 延迟比原生高约 1–3%。
兼容与迁移	可与 NVIDIA GPU Operator 共存；可以接管申请 `nvidia.com/gpu` 的 Pod。	依赖 NVIDIA container toolkit；在其管理的节点上取代 NVIDIA device plugin。
许可与支持	controller、调度器、hypervisor 为 Apache 2.0。各厂商 limiter 与远程 client/worker 不开源，10 卡以下免费。NexusGPU 提供商业支持。	全部组件 Apache 2.0。2026 年 7 月起为 CNCF 孵化项目。Dynamia 提供企业版和支持。

功能清单

这份清单是本页早期版本功能矩阵的更新版。“部分”的含义见各维度对应章节。

功能	TensorFusion	HAMi
共享
GPU 切分：显存限额	✅	✅
GPU 切分：算力限额	✅	✅
请求与限额分开（可突发到请求量以上）	✅	❌
Pod 运行中调整限额	✅	❌
进程级隔离（GPU 调用在应用进程外执行）	✅ `hard`	❌
硬件分区（MIG 等）	✅ MIG、昇腾 vNPU	✅ 动态 MIG、厂商模板
单个 Pod 使用多张 GPU	✅	✅
超额分配	✅ 算力和显存	部分，显存缩放（实验特性）
主机内存或磁盘计入可调度显存	✅	❌
远程 GPU（GPU-over-IP）	✅ 以 NVIDIA 为主	❌
虚拟机使用宿主机 GPU	✅ 计算类 API，Linux 与 Windows	❌
调度
GPU 感知调度器	✅ 内置	✅ extender
紧凑装箱与负载均摊	✅	✅
GPU 拓扑感知	✅	✅
Gang 调度	✅ 内置	✅ PodGroup（v2.10），或通过 Volcano
命名空间 GPU 配额	✅ `GPUResourceQuota`	✅ 针对显存和算力的 `ResourceQuota`
QoS 等级与优先级	✅ 四级	部分，NVIDIA 上两级优先级
动态资源分配（DRA）	❌	✅ 独立的 HAMi-DRA 驱动
运维
GPU 节点自动伸缩（Karpenter、云 API）	✅	❌
节点压缩与碎片整理	✅	❌
按用量自动调整 GPU 限额	✅	❌
指标与看板	✅	✅
告警规则	✅ 内置	部分，需自行编写 Prometheus 规则
按工作负载的成本归集	✅	❌
Web 控制台	✅ 可选云端控制台	✅ HAMi-WebUI
GPU 热迁移	商业版	❌
平台
NVIDIA 以外的厂商	部分，三家	✅ 十多家
完全开源	部分	✅
基金会治理	❌	✅ CNCF

架构与安装

TensorFusion 自己承担的部分更多。一个 Helm chart 部署：

controller：单个进程，包含 CRD 控制器、Pod webhook，以及基于 kube-scheduler 的调度器（GPU Pod 使用它，其他 Pod 仍用默认调度器）；
每个 GPU 节点上的 hypervisor DaemonSet：发现设备、运行 TensorFusion 自己的 device plugin、写入每个 Pod 的限额；
存放指标和日志的 GreptimeDB 与 Vector，以及可选的、把集群接入云端控制台的 agent。

多出来的组件承载的正是 HAMi 交给其他项目的功能：节点供给、自动伸缩、指标和成本数据。如果只需要本地 GPU 切分，HAMi 要运维的东西更少。

隔离

两者都用容器内的库执行软件限额，区别在这个库周围的机制。

	TensorFusion	HAMi
显存	所有模式都按 Pod 限制。`soft` 模式下，limiter 拒绝超出限额的分配。	由 HAMi-core 拦截 CUDA 显存分配调用，超出限额时返回显存不足。NVML 同样被拦截，容器内 `nvidia-smi` 显示的是限额。
算力	`soft`：limiter 内的令牌桶，由节点 hypervisor 中跟踪设备忙碌时间的控制环路补充令牌。`hard`：worker 给工作负载分配固定份额的 SM。	HAMi-core 用令牌桶节流 `cuLaunchKernel`；后台线程采样 GPU 利用率并补充令牌，使用量收敛到算力百分比。
运行时调整限额	支持。hypervisor 改写共享内存中的配额，自动伸缩、定时规则和 QoS 都依赖它。	不支持，限额在容器启动时确定。
故障与安全隔离	`soft` 不是安全边界。`hard` 把 GPU 调用放到独立的 worker 进程；远程模式把 worker 放到另一个节点；`partitioned` 提供硬件边界。	HAMi-core 在进程内；其文档把限额描述为软限制、噪声隔离为尽力而为，直接调用驱动可以绕过。动态 MIG 在 Ampere、Hopper、Blackwell 上提供硬件边界。
镜像要求	`soft` 需要基于 glibc 的镜像（limiter 通过 `/etc/ld.so.preload` 加载）。	HAMi-core 同样通过 `/etc/ld.so.preload` 加载，要求相同。

切分粒度与资源模型

TensorFusion 用 Pod 注解或 WorkloadProfile 描述资源：

算力可以用 TFLOPS 表示。调度器知道每种 GPU 型号的 FP16 TFLOPS，所以“10 TFLOPS”在 T4 和 A100 上是同样的计算量，而“30%”不是。也支持百分比。
每种资源都有请求和限额。调度器按请求装箱，limiter 按限额执行，与 Kubernetes 对 CPU 和内存的处理一致。
工作负载换到另一种 GPU 型号时不必改数值。

调度

	TensorFusion	HAMi
接入方式	基于 kube-scheduler 加 GPU 插件构建的自有调度器（`tensor-fusion-scheduler`）。	由 kube-scheduler 调用的 scheduler extender（`hami-scheduler`）；另有 Volcano 的 vGPU device plugin、Kueue 集成，以及 KAI Scheduler 的资源隔离组件。
放置策略	按资源池选择紧凑装箱或负载均摊，节点级和 GPU 级。	节点和 GPU 分别设置 `binpack` 或 `spread`，可按 Pod 指定；`mutex` 独占一张卡。
拓扑	多卡 Pod 按 NUMA 和 GPU 互联选择。	NVIDIA 上基于 `nvidia-smi topo` 的拓扑策略，昆仑芯、燧原、沐曦的厂商拓扑，可选的 CPU/GPU NUMA 对齐（v2.10）。
Gang 调度	内置。	v2.10 起支持 PodGroup；队列与公平性通过 Volcano 或 Kueue。
配额	按命名空间的 `GPUResourceQuota`，以 TFLOPS 和显存计。	`ResourceQuota` 中的 `limits.nvidia.com/gpumem` 等，由 webhook 校验。
优先级	四级 QoS，对应 PriorityClass 和空闲算力的分配比例。	`nvidia.com/priority`：同一张卡上，高优先级任务会暂停低优先级任务。
设备选择	厂商、GPU 型号、隔离模式、资源池。	通过注解指定 GPU 类型和 UUID。

弹性

这是两者差别最大的地方。

GPU 节点自动伸缩。 Pod 处于 Pending 时，TensorFusion 通过 Karpenter NodeClaim 或云厂商 API 创建 GPU 节点，并释放被压缩腾空的节点。在阿里云 ACK + Karpenter + T4 的测试中，三个 20% 的 Pod 只拉起一个节点而不是三个，成本比整卡方案低 72%。HAMi 没有节点供给，使用你或 Cluster Autoscaler 提供的节点；v2.10 加入了 Cluster Autoscaler 扩容模拟的设计文档，自动伸缩在其路线图上。
垂直伸缩。 TensorFusion 根据历史用量推荐并应用 GPU 请求与限额，也支持在某个时间窗口内调整限额的定时规则，原地生效，不重启 Pod。HAMi 的限额在容器生命周期内固定。
超额分配。 TensorFusion 按资源池设置算力超卖倍数，并可把主机内存和磁盘计入可调度显存。HAMi 支持大于 1 的设备显存缩放比例，标注为实验特性。

工作负载	吞吐相对原生
vLLM，Qwen3-0.6B，8 路并发流式请求	−0.4%，每输出 token 时间相同
ONNX Runtime，resnet50 / MiniLM	−0.2% / −0.3%
TorchBench，resnet50 / bert_base / tiny_mlp	−0.8% / −0.6% / +0.3%

兼容与迁移

HAMi 在其管理的节点上取代 NVIDIA device plugin，并依赖 NVIDIA container toolkit。迁移到 HAMi 需要给节点打标签、修改 Pod 中的资源名。

许可、治理与支持

	TensorFusion	HAMi
开源部分	controller、调度器、hypervisor 和 CRD：Apache 2.0，位于 NexusGPU/tensor-fusion。	全部组件，包括 HAMi-core：Apache 2.0。
闭源部分	`soft` 模式使用的各厂商 limiter 库，以及 `hard` 和远程模式的 client 与 worker。以公开镜像分发；client 和 worker 对 GPU 总数少于 10 张的组织免费，需要 license 文件。	无。
治理	由 NexusGPU 开发。	2024 年 8 月进入 CNCF Sandbox，2026 年 7 月成为孵化项目；维护者来自 Dynamia、NVIDIA 和独立贡献者。GitHub 约 4,700 星。
商业	NexusGPU：商业许可、热迁移、技术支持。	Dynamia 销售基于 HAMi 的企业版并提供支持。

总拥有成本

小规模、仅本地共享。 如果团队熟悉 Kubernetes、Prometheus 和 GPU 节点运维，HAMi 开源版很合适，没有许可费用。TensorFusion 的开源组件也覆盖这一场景。
规模更大或在云上。 节省主要不来自切分本身，而来自少用节点：把切分后的工作负载装到更少的 GPU 上、释放空节点、按用量调整限额。TensorFusion 自动完成这个闭环；用 HAMi 则需要结合 Cluster Autoscaler、自建监控和人工调优来实现。
需要远程或虚拟机访问，或 hard 隔离。 只有 TensorFusion 提供，且依赖其闭源组件，超过 10 卡需要许可。

申请 GPU 的写法

HAMi：

spec:
  containers:
    - name: app
      image: pytorch/pytorch:2.6.0-cuda12.4-cudnn9-runtime
      resources:
        limits:
          nvidia.com/gpu: 1        # GPU 数量
          nvidia.com/gpumem: 4096  # 每张卡的显存，单位 MiB
          nvidia.com/gpucores: 30  # 每张卡的算力百分比

TensorFusion：

metadata:
  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

如果要按单卡百分比而不是 TFLOPS 申请算力，使用 tensor-fusion.ai/compute-percent-request 和 tensor-fusion.ai/compute-percent-limit。全部注解见创建工作负载。

如何选择

以下情况选 HAMi：

使用 TensorFusion 尚未支持的加速卡，或一个集群里有多家厂商。
要求全部组件开源，或希望项目由 CNCF 治理。
已经在用 Volcano、Kueue、Koordinator 或 KAI Scheduler，或正在转向 DRA，希望 GPU 共享直接接入。
只需要固定限额的本地 GPU 切分，并且希望组件尽量少。

以下情况选 TensorFusion：

在云上运行，希望少用 GPU 节点：紧凑装箱、通过 Karpenter 自动伸缩节点、释放空节点。
希望根据实际用量调整 GPU 限额，并且不重启 Pod。
希望 GPU 算力有请求和限额，由 QoS 等级决定空闲算力归谁。
CPU 节点上的 Pod 或虚拟机需要使用其他机器上的 GPU。
需要按工作负载的成本数据做内部分摊。

参考资料

TensorFusion 的测量数据：NexusGPU/tensor-fusion 中的端到端测试（e2e/ack/TEST-SUMMARY.md，2026 年 10 月）和基准测试页。

HAMi，核对于 2026 年 10 月：

HAMi README：功能、支持的设备、前置条件。
HAMi 发布说明：核对时最新版本为 v2.10.0（2026 年 8 月）。
HAMi-core：显存和算力限额的实现方式。
HAMi 配置说明：资源名、调度策略、设备显存缩放。
支持的设备和基准测试。
HAMi-DRA 与 HAMi-WebUI。
HAMi becomes a CNCF incubating project，CNCF 博客，2026 年 7 月。

一览

功能清单

架构与安装

隔离

切分粒度与资源模型

调度

弹性

远程 GPU 与虚拟机

硬件与厂商覆盖

可观测性、计量与成本归集

性能开销

兼容与迁移

许可、治理与支持

总拥有成本

申请 GPU 的写法

如何选择

参考资料

目录

与 HAMi 的对比

一览

功能清单

架构与安装

隔离

切分粒度与资源模型

调度

弹性

远程 GPU 与虚拟机

硬件与厂商覆盖

可观测性、计量与成本归集

性能开销

兼容与迁移

许可、治理与支持

总拥有成本

申请 GPU 的写法

如何选择

参考资料

目录