TensorFusion 架构
组件、隔离模式,以及 Pod 如何拿到 GPU
TensorFusion 由三部分组成:管理 GPU 资源池并调度 Pod 的 controller、运行在每个 GPU 节点上负责执行限额的 hypervisor,以及可选的云端控制台。本页介绍各个组件、Pod 使用 GPU 的两种方式、四种隔离模式,以及从 kubectl apply 到工作负载跑起来中间发生了什么。
第一次接触 TensorFusion 的话,建议先读概览。
系统整体架构
| 层次 | 组件 | 运行形态 | 职责 |
|---|---|---|---|
| 池化调度层 | Controller | Deployment,容器名 controller | 协调 TensorFusion 的各类自定义资源,通过准入 webhook 改写 Pod,并内嵌一个名为 tensor-fusion-scheduler 的 kube-scheduler 及 GPU 调度插件。节点伸缩、自动伸缩和告警计算也在这里。 |
| 池化调度层 | Vector | controller 和 hypervisor Pod 里的 sidecar | 把指标送入 GreptimeDB。 |
| 池化调度层 | GreptimeDB | chart 安装的单机实例,或自备实例 | 存储 tf_* 指标表。 |
| 池化调度层 | Alertmanager | chart 安装的 StatefulSet | 分发 controller 触发的告警。 |
| 虚拟化层 | Hypervisor | 每个 GPU 节点一个 Pod | 通过厂商 accelerator 库发现设备,上报 GPU 和 GPUNode 资源,向 kubelet 注册 device plugin,并执行每个 Pod 的算力和显存限额。 |
| 虚拟化层 | Limiter | 预加载到应用容器里的动态库 | soft 隔离使用。在进程内拦截 GPU API 调用,按 hypervisor 下发的限额限流。 |
| 虚拟化层 | Client | 注入到应用容器里的动态库 | 远程模式和 hard 隔离使用。把 GPU API 调用转发给 worker。 |
| 虚拟化层 | Worker | sidecar 容器,或 GPU 节点上的独立 Pod | 在物理 GPU 上执行转发过来的调用。 |
| 控制层 | Cluster agent | controller Pod 里的可选 sidecar | 把集群接入云端控制台。 |
| 控制层 | 云端控制台 | 托管在 app.tensor-fusion.ai | 用网页管理集群、资源池和工作负载。 |
本地 GPU 模式
Pod 运行在为它提供 GPU 的节点上。除非资源池设置了 defaultUsingLocalGPU: false,否则默认使用这种模式。

远程 GPU 模式
Pod 可以运行在任意节点上,包括没有 GPU 的节点。Pod 里的 client 通过网络把 GPU 调用转发给 GPU 节点上的 worker Pod。在 Pod 上设置 tensor-fusion.ai/is-local-gpu: "false" 即可启用。

远程模式要求 client Pod 能访问 worker 所在的节点。
隔离模式
注解 tensor-fusion.ai/isolation 决定工作负载与同一张 GPU 上其他负载的隔离方式,默认值是 soft。
| 模式 | 工作方式 | 注入内容 | 适用情况 |
|---|---|---|---|
shared | Pod 拿到整张 GPU,不执行任何限额,进程之间靠 GPU 自带的时间片共享。 | 无 | 只需要池化和调度,不需要切分限额。 |
soft | 应用进程内的 limiter 用反馈控制器对算力限流,并限制显存上限。hypervisor 通过共享内存更新限额。 | Limiter | 默认模式。需要 GPU 切分、QoS 等级和自动伸缩,且工作负载可信。 |
hard | GPU 调用由应用进程之外的 worker 执行,算力上限通过给工作负载分配固定比例的 GPU 计算单元(NVIDIA 上是 SM)来实现。 | Client,外加 worker sidecar(本地)或 worker Pod(远程) | 需要更强的性能隔离,或工作负载不可信。 |
partitioned | hypervisor 创建硬件分区(如 NVIDIA MIG 实例、昇腾 vNPU)并分配给 Pod。 | 无 | GPU 支持硬件切分,且需要完全隔离。此模式无法超额分配。 |
选择之前需要知道:
soft要求该 GPU 厂商有对应的 limiter。厂商没有 limiter 时,webhook 会拒绝soft请求。- 本地 GPU 上的
hard总是在同一个 Pod 里运行一个 worker sidecar。 - chart 默认设置
controller.isolationModePolicy: dynamic。每张 GPU 的模式由第一个落到它上面的 Pod 决定,最后一个 Pod 离开后恢复为未指定,因此同一个节点上的不同 GPU 可以分别承载soft、hard和shared的 Pod。这种策略不支持partitioned。 - 设置
controller.isolationModePolicy: static时,每个节点只运行一种模式,由资源池的nodeManagerConfig.defaultIsolationMode和isolationModeRules决定。使用partitioned时请选这种策略。
各厂商对每种模式的支持情况见支持矩阵。
核心概念
资源与单位
- TFLOPS:GPU 算力的单位。TensorFusion 以每个型号的 FP16 TFLOPS 作为它的算力容量,申请和限制算力时用同一个单位。
- 算力百分比(compute percent):TFLOPS 之外的另一种写法,表示单张 GPU 的百分比。用百分比申请会绕过命名空间配额检查,所以启用了配额或集群里有多种 GPU 型号时,建议用 TFLOPS。
- VRAM:显存,按 Kubernetes 资源量的写法填写,例如
4Gi。 - vGPU:Pod 看到的那一份 GPU。对应用来说,它和普通 GPU 设备没有区别。
- QoS:
low、medium、high、critical四级。每一级有各自的成本核算单价;high和critical的 Pod 如果没有自行指定 PriorityClass,会被设置为优先级更高的 PriorityClass。
资源层级
- TensorFusionCluster:最顶层的对象,通常对应一个 Kubernetes 集群,包含一个或多个 GPU 资源池。
- GPUPool:一组 GPU 节点,共用容量上下限、超额分配比例、QoS 定价和调度策略。Pod 在单个资源池内调度。
- GPUNode:由资源池纳管的、带 GPU 的 Kubernetes 节点。
- GPU:一个物理设备,记录它的 TFLOPS 和显存的总量与可用量。
文档中用到的全部术语见术语解释。
部署拓扑
用默认 values 安装 Helm chart 后,集群里会有:
- 一个 controller Deployment,位于 release 所在的命名空间(安装文档中为
tensor-fusion-sys)。Pod 里有controller容器和vectorsidecar。只有设置了agent.agentId,才会加上cluster-agentsidecar。 greptimedb命名空间里的一个 GreptimeDB 单机实例,以及一个 Alertmanager StatefulSet。- 一个默认的
TensorFusionCluster,带一个GPUPool、一个SchedulingConfigTemplate和 NVIDIA 的ProviderConfig。 - 每个匹配资源池节点选择器的节点上有一个 hypervisor Pod。默认的选择器是标签
nvidia.com/gpu.present=true。没有匹配节点的集群也能正常安装,只是在有节点匹配之前不会启动 hypervisor。
没有 TensorFusion 时,每个应用挂载整张 GPU:

部署 TensorFusion 后,应用按需获得本节点或其他节点上的一份 GPU:

Pod 如何拿到 GPU
- 给 Pod 加标签和注解。 标签
tensor-fusion.ai/enabled: "true"用来启用 TensorFusion,tensor-fusion.ai/tflops-request、tensor-fusion.ai/vram-limit等注解描述资源需求。见工作负载注解。 - webhook 改写 Pod。 它确定资源池(没有指定时用默认池),补全默认值,把
schedulerName设为tensor-fusion-scheduler,并创建或更新一个TensorFusionWorkload。然后按模式注入内容:soft注入 limiter,本地hard注入 client 和 worker sidecar,远程模式只注入 client。 - 调度器选择位置。 GPU 调度插件按可用 TFLOPS 和显存、厂商、型号、配额和隔离模式过滤节点与 GPU,再按资源池的放置策略给候选打分,并预留选中的 GPU。远程模式下,controller 为工作负载创建 worker Pod,拿到 GPU 的是这些 worker Pod。
- hypervisor 执行限额。 在选中的节点上,hypervisor 的 device plugin 把 Pod 绑定到它的 GPU。
soft模式下,hypervisor 把限额写入共享内存文件,由 limiter 读取;hard模式下由 worker 执行限额;partitioned模式下由 hypervisor 创建分区。 - 远程 client 找到自己的 worker。 controller 创建一个
TensorFusionConnection,把 client Pod 和一个 worker 配对。client 向 controller 查询 worker 地址后建立连接。 - 记录用量。 hypervisor 和 controller 把指标写入 GreptimeDB,自动伸缩、告警和控制台都从这里读取数据。
远程模式的调用路径
在远程模式和 hard 隔离下,GPU API 调用离开应用进程,在 worker 里执行:

自定义资源
TensorFusion 的全部配置都通过 tensor-fusion.ai/v1 API 组下的自定义资源完成。
| 资源 | 作用域 | 用途 |
|---|---|---|
TensorFusionCluster | 集群 | 顶层配置,拥有各个 GPU 资源池。 |
GPUPool | 集群 | 容量、超额分配、节点管理、QoS 与定价、组件镜像。 |
GPUNode | 集群 | 一个 GPU 节点及其汇总容量。 |
GPU | 集群 | 一个设备:厂商、型号、容量、可用资源和当前隔离模式。 |
GPUNodeClaim | 集群 | 一次新增 GPU 节点的请求,由云厂商或 Karpenter 完成创建。 |
GPUNodeClass | 集群 | TensorFusion 自行创建节点时使用的实例模板。 |
ProviderConfig | 集群 | 按厂商区分的配置:镜像、GPU 型号及其 TFLOPS、分区模板。 |
SchedulingConfigTemplate | 集群 | 放置策略、自动伸缩规则和 hypervisor 调度参数。 |
GPUResourceQuota | 命名空间 | 命名空间的 GPU 总量上限、单个工作负载上限,以及默认的请求和限额。 |
TensorFusionWorkload | 命名空间 | 共用同一份资源规格的一组 Pod 或 worker,通常由 webhook 创建。 |
WorkloadProfile | 命名空间 | 可复用的资源规格,Pod 按名称引用。 |
TensorFusionConnection | 命名空间 | 远程模式下把 client Pod 和 worker 配对,由系统创建。 |
字段级说明见自定义资源定义。
节点管理
资源池通过 nodeManagerConfig.provisioningMode 选择获得节点的方式,共三种:
| 模式 | 行为 |
|---|---|
AutoSelect | 默认值。资源池纳管匹配节点选择器的现有节点。如果这些节点属于某个 Karpenter NodePool,当 Pod 因 GPU 不足而 Pending 时,controller 会创建 Karpenter NodeClaim,节点的回收交给 Karpenter。 |
Karpenter | TensorFusion 创建 GPUNodeClaim,让资源池保持在 capacityConfig 规定的范围内,由 Karpenter 拉起实例。空节点由 TensorFusion 自己回收。 |
Provisioned | TensorFusion 调用云厂商 API 创建实例,实例规格由 GPUNodeClass 描述。 |
节点合并会释放空节点,碎片整理按计划把 worker 从利用率低的节点上迁走。两者都在资源池的 nodeManagerConfig 里配置。见对接云厂商和优化 GPU 效率。
云端控制台连接
控制台是可选的。使用时需要设置 agent.agentId 和 agent.enrollToken,这两个值由控制台的接入向导生成。设置后,chart 会在 controller Pod 里加上 cluster-agent sidecar。
- agent 主动向
agent.cloudEndpoint建立 WebSocket 连接,默认地址是wss://app.tensor-fusion.ai。集群不需要开放入站访问。 - 控制台通过这条连接读写集群资源,使用的是 controller 的 ServiceAccount 权限。
- 指标不出集群。控制台画图时,由 agent 在集群内的 GreptimeDB 上执行查询。
TensorFusion 文档