云原生 AI 成本归因：GPU 账单要能落到工作负载

云原生 AI 成本归因：GPU 账单要能落到工作负载

一、GPU 账单不能只到集群级别

AI 平台成本里，GPU 往往占大头。如果账单只停留在集群或节点池级别，团队很难知道是谁用了资源、哪个模型最贵、哪个租户毛利异常。云原生 AI 平台必须做成本归因。

成本归因不是为了追责，而是为了让资源使用和业务价值对齐。

二、归因维度要从工作负载开始

flowchart TD
  A[GPU 节点成本] --> B[Pod 使用]
  B --> C[工作负载]
  C --> D[租户]
  C --> E[模型]
  C --> F[任务类型]

节点成本要分摊到 Pod，再关联工作负载、租户、模型和任务类型。在线推理、批推理、训练任务的计费方式可能不同。

只按运行时长分摊还不够，还要考虑 GPU 类型、显存占用、独占还是共享。

三、成本事件要结构化

type GpuCostRecord = {
  namespace: string
  workload: string
  tenantId: string
  gpuType: string
  gpuHours: number
  costCents: number
}

如果有 MIG 或共享 GPU，还需要更细粒度的使用记录。否则小任务和大任务被平均分摊，会让成本失真。

gpu_cost_policy:
  require_tenant_label: true
  require_model_label: true
  split_by_gpu_type: true
  alert_unlabeled_workload: true

标签是成本归因的基础。没有标签的工作负载，应被告警或阻塞。

四、成本要回到调度策略

成本数据不能只给财务看。调度器可以根据成本和优先级，把低价值批任务放到便宜资源，把核心在线服务放到保底资源。

还要识别浪费。GPU Pod 长时间空闲、Job 完成后不退出、模型副本过多，都会造成无效成本。

成本归因还要处理共享组件。推理网关、模型缓存、日志系统、向量数据库可能服务多个租户，不能简单归到某一个工作负载。可以按请求量、token 数、存储量或固定比例分摊。

shared_cost_allocation:
  inference_gateway: "request_count"
  model_cache: "model_size_and_access"
  observability: "log_volume"
  vector_store: "storage_gb"

成本标签要在准入阶段校验。没有 tenant、model、task_type 标签的 GPU 工作负载，不应该进入生产集群。事后补标签通常补不全。

还要给用户展示成本反馈。比如某个批推理任务预计消耗多少 GPU 小时，是否可以选择低优先级队列降低成本。资源意识越早暴露，平台越少被动控费。

最后，成本数据要进入容量规划。某类模型长期高成本且高价值，可以考虑专用节点池；低价值任务长期占用昂贵 GPU，就应该降级或排队。

成本归因要和准入控制联动。没有标签的工作负载如果还能进入集群，后面再做报表只是在补洞。生产 GPU namespace 应该强制要求成本标签，并把缺失原因反馈给提交方。

cost_label_admission:
  required_labels:
    - tenant
    - model
    - task_type
    - cost_center
  reject_unlabeled_gpu_pod: true
  allow_temporary_exception_hours: 24

临时例外也要有过期时间。否则例外会变成常态，成本报表里永远有一块“未知”。未知成本越多，平台越难推动优化，因为没人能对那部分资源负责。

更进一步，可以把成本趋势接入发布评审。新模型上线前，不只看效果指标，也看单位请求成本、峰值 GPU 占用和扩容影响。这样成本不是事后账单，而是架构决策的一部分。

五、总结

云原生 AI 成本归因要把 GPU 节点成本分摊到 Pod、工作负载、租户、模型和任务类型。

GPU 账单能落到工作负载，平台才有机会同时优化成本和稳定性。