财务管理

事前约束，而非事后追责

预算控制的核心并非“算清花了多少”，而是在资源申请阶段设定明确边界，防止超支。一次训练任务可能消耗数万元，若等到月度账单出具再干预，损失已无法挽回。因此，必须将控制点前移至“资源创建前”——所有 GPU 实例、存储空间、推理服务等关键资源的创建，必须关联有效预算配额，否则自动拒绝。

以项目/团队为单位，粒度适中

预算单元不宜过细（如按模型版本），也不宜过粗（如全公司一个池子）。推荐以业务项目或技术团队为最小预算主体，既能满足责任归属需求，又避免管理开销过大。在缺乏历史数据的初期，可通过合理配额建立基本约束，防止资源被个别团队垄断或滥用。

配额与预算联动，软硬结合

• 硬管控：对关键资源（如 A100 卡数、存储容量）设置硬性上限；

• 软管控：对总成本设置预警阈值（如 80%），触发通知但不中断服务，兼顾灵活性与风险控制。

优先引导使用预付费资源，提升预算可预测性

在满足业务需求的前提下，鼓励团队优先选择预付费资源（如 PAI 计算资源组）。尽管其灵活性低于后付费资源（如 PAI 公共资源组），无法完全按需伸缩，但因其成本固定、无突发账单风险，更利于预算编制与执行管控。对于训练任务或稳定推理服务，预付费是更优的治理选择。

以使用方为成本责任主体

成本归属不以“资源归属”为唯一依据，而是根据谁发起使用行为划分责任：

• 模型开发/训练阶段：由资源申请者（或所属项目）承担全部成本，资源标签在创建时绑定；

• 模型推理阶段：由调用方（如业务系统、应用服务）按实际调用量（如输入/输出 token 数）分摊成本，而非由模型所有者承担。

训练资源标签必须统一且一致

所有模型开发、训练任务、微调作业等操作，在提交时必须指定 project、team 等归属标签，并确保关联资源（如向量数据库、对象存储）的标签保持一致，避免归属割裂。

推理成本按调用方拆分，支持多模型混合调用

当一个业务请求调用多个模型（如先调用 Embedding 模型，再调用 LLM），平台需记录每个子调用的 token 消耗，并将总成本按比例拆分至各调用方（或统一归属至发起请求的顶层应用）。

示例：某客服系统一次对话调用 Model-A（1000 tokens）和 Model-B（500 tokens），则总推理成本按 2:1 拆分至该客服系统名下（或进一步拆至两个子服务）。

这种“谁受益、谁承担”的机制，能有效提升团队成本意识，促使其主动优化 prompt、启用缓存或选择更经济的模型。

杜绝无标签资源，平台强制校验

及时发现任何未携带完整归属标签的资源（训练或推理）。即使前期不实施 Chargeback，清晰的调用链与归属数据也能为后续的模型服务定价、跨团队结算或 ROI 评估提供可靠基础，避免“历史数据不可用”的窘境。

追踪到可解释的最小业务单元

成本数据不仅展示“花了多少钱”，还需关联可理解的业务行为，例如：

• 训练任务：模型名称、训练时长、GPU 类型、数据集版本；

• 推理调用：调用方应用、模型名称、输入/输出 token 数、请求时间、是否缓存命中；

• 存储费用：绑定模型 ID 或项目名，标注存储类型（权重、日志、缓存）及保留周期。

确保每一笔费用都能回答：“为什么会产生这笔钱？”

保留原始计量数据，支持双向追溯

平台需同时保存两类数据：

• 原始计量数据：如 GPU 小时数、token 消耗量、存储 GB·天；

• 转换后成本数据：基于单价计算出的金额。

运营人员可从“金额”反查“用量”，财务人员可验证“单价 × 用量 = 总价”，实现高效对账。

与云账单对齐，支持外部核验

内部成本数据的粒度与时间范围应能与阿里云账单对齐。当出现差异时，可快速定位是平台计量偏差、标签缺失，还是资源未纳管。

提供多维下钻视图，满足不同角色需求

• 管理层：按项目/团队查看月度趋势；

• 运营人员：按模型/服务分析调用量与成本关系；

• 财务人员：按成本科目（如“AI-训练”“AI-推理”）导出对账明细。

所有视图共享同一套底层数据，确保口径一致。

保留历史快照，支持审计与回溯

成本数据每日自动归档，保留至少 12 个月。即使资源已释放、标签已变更，仍可还原任意时间点的成本构成，满足内审或合规要求。

只有知道“Model-A 的推理成本中 70% 来自长输出”，才能针对性优化；只有知道“某项目 80% 成本在 dev 环境”，才能推动资源清理。成本追踪是优化的前提。