优化GPU效率

本页给出 TensorFusion 集群的 GPU / NPU 效率优化流程。目标不是单纯提高利用率数字，而是在业务延迟、稳定性和成本之间取得可控平衡。

不要只按平均利用率调低资源。在线推理至少要同时观察 p95 / p99 延迟、限流次数、显存峰值和调度失败事件。

先定位浪费类型

常见浪费分为四类：

类型	现象	优化方向
请求过大	Pod 申请的 TFLOPs / VRAM 长期高于实际使用	下调 request，或启用自动资源推荐
限制过松	limit 远高于业务峰值，影响装箱密度	下调 limit，保留必要峰值余量
资源碎片	多个节点剩余少量 VRAM / TFLOPs，但无法满足新 Pod	调整规格、减少硬性约束、启用碎片整理
空闲节点	GPU 节点无业务或长期低利用率	缩容、节点池压缩、保留合理 warm capacity

查看资源池状态

kubectl get gpupool
kubectl get gpunode,gpu -o wide
kubectl get tensorfusionworkload -A

如果已接入 GreptimeDB，可以查询指标表定位使用差异：

SELECT
  namespace,
  workload,
  worker,
  max(compute_tflops) AS peak_tflops,
  max(memory_bytes) AS peak_vram_bytes
FROM tf_worker_usage
WHERE ts > now() - INTERVAL '1 hour'
GROUP BY namespace, workload, worker
ORDER BY peak_vram_bytes DESC;

资源表和字段说明参考监控指标定义。

调整工作负载规格

优先从 request 开始优化，再调整 limit。request 决定调度和装箱，limit 决定运行时上限。

metadata:
  labels:
    tensor-fusion.ai/enabled: "true"
  annotations:
    tensor-fusion.ai/inject-container: python
    tensor-fusion.ai/tflops-request: "20"
    tensor-fusion.ai/tflops-limit: "30"
    tensor-fusion.ai/vram-request: 8Gi
    tensor-fusion.ai/vram-limit: 10Gi

建议：

在线推理先保证 p95 / p99 延迟，再逐步下调 request。
批处理任务可以接受更低 request 和更高排队概率。
不要给所有工作负载都指定 gpu-index 或固定 gpu-model，除非业务确实依赖特定设备。
多卡任务需要同节点或拓扑亲和时，再使用对应注解；否则会降低装箱空间。

更多注解示例参考最佳实践：工作负载注解。

启用自动资源推荐

TensorFusion 可以基于历史指标给出资源推荐，并按配置自动调整 TFLOPs / VRAM：

metadata:
  annotations:
    tensor-fusion.ai/auto-resources: "true"
    tensor-fusion.ai/auto-scale-target-resource: all

更细的百分位、边界和 cron 规则可通过 WorkloadProfile 配置，参考配置自动扩缩容。

上线建议：

先只生成推荐值，不自动应用。
对比推荐值和业务峰值。
小流量启用自动调整。
观察一到两个业务周期后再扩大范围。

选择合适隔离模式

不同隔离模式的效率和隔离强度不同：

模式	效率	隔离	建议场景
`soft`	高	中	默认推理、开发测试、多租户共享
`hard`	中	高	对算力上限要求严格的生产业务
`shared`	高	低	可信业务共享整卡能力
`partitioned`	中	高	MIG 或厂商硬切分场景

如果 Pod 没有声明虚拟化模式，默认按 soft 处理。MIG 的前提是 GPU 支持并且节点上已经开启 MIG，配置时对应 partitioned 模式。

启用节点碎片整理

碎片整理会在维护窗口中迁移低利用率节点上的 TensorFusion Worker，让资源更集中，便于缩容或承载大规格 Pod。

apiVersion: tensor-fusion.ai/v1
kind: TensorFusionCluster
metadata:
  name: tensor-fusion
spec:
  gpuPools:
    - name: shared
      specTemplate:
        nodeManagerConfig:
          nodeCompaction:
            period: 5m
            defrag:
              enabled: true
              schedule: "0 3 * * *"
              timezone: Asia/Shanghai
              maxDuration: 2h
              utilizationThresholdPercent: 40

开启前请确认业务可被安全驱逐和重建，并避开高峰期。

使用 warmResources 控制冷启动

如果启用了自动扩容 / 缩容，warmResources 可以保留一部分热容量，减少扩容等待时间。值过高会降低节省成本的效果，值过低会增加冷启动。

capacityConfig:
  warmResources:
    tflops: "100"
    vram: 80Gi

建议按业务峰谷设置：

白天高峰前提高 warm capacity。
夜间低峰降低 warm capacity。
对延迟敏感业务保留至少一个副本可用的 TFLOPs 和 VRAM。

验收指标

优化后至少观察以下指标：

tf_worker_usage: 业务实际 TFLOPs、VRAM、限流次数
tf_worker_resources: request / limit 与实际使用差异
tf_pool_metrics: 资源池总分配率和虚拟容量占比
tf_gpu_usage: 单卡温度、显存、算力、功耗
调度失败事件和业务 p95 / p99 延迟

如果调低资源后出现 WorkerTFlopsThrottled、显存切换频繁、业务延迟升高，应回退到上一档规格，再结合业务峰值重新估算。

目录