2. GPU集群资源模型与计量体系
在GPU集群治理中，最容易被忽视却最致命的问题，是“口径不一致”。运维团队按物理卡数报容量，调度团队按可分配GPU数报容量，财务团队按采购合同金额分摊成本，而业务团队只关心“我提交的任务能不能跑起来”。四套口径各自成立，却无法拼成一张可对账的账本。要解决这个问题，必须先把GPU资源从物理对象抽象为可计量、可分配、可计价的统一模型。
一、从物理卡到调度单元：资源模型的四层抽象
一张物理GPU卡进入集群后，会经历四次“身份转换”，每一层都对应不同的计量口径：
- 物理设备层：以PCIe/NVLink地址标识的实体卡，关注型号、显存容量、算力峰值、功耗、故障域。这是采购与资产管理的口径。
- 节点资源层：操作系统与驱动识别到的GPU设备，叠加CPU、内存、本地NVMe、RDMA网卡，形成“节点规格”。这是装机与健康检查的口径。
- 调度单元层：Kubernetes等调度器将GPU注册为扩展资源，按“卡”或“显存切片”分配。这是任务排队与占用的口径。
- 配额与计量层：面向租户/项目/团队的额度与用量，按GPU·小时、显存·小时或折算算力单位计费。这是成本分摊与预算控制的口径。
四层之间不是简单映射。例如一张80GB显存的A100，在调度层可能被切成两个40GB的MIG实例，在计量层则可能按“1/2卡·小时”计价。如果账本只记录物理卡数，MIG切片带来的利用率提升就无法体现；如果只记录调度单元，又无法回溯到具体硬件故障。统一账本的关键，是让每一层都有唯一标识，并建立可追溯的映射关系。
二、计量口径：三种常见单位与选择依据
计量单位决定了成本分摊的公平性和资源使用的导向性。实践中常见三种口径：
| 计量口径 | 计算方式 | 适用场景 | 风险 |
|---|---|---|---|
| 整卡·小时 | 占用卡数 × 时长 | 独占训练任务、大模型预训练 | 小任务浪费严重，利用率低 |
| 显存·小时 | 分配显存GB × 时长 | 推理服务、MIG切片、共享GPU | 算力占用未体现，可能被低算力任务占满 |
| 折算算力单位 | 按型号算力系数 × 时长 | 异构集群、跨型号公平调度 | 系数设定主观，需定期校准 |
选择依据不是“哪个先进”，而是“哪个能引导正确行为”。如果集群主要跑大训练任务，整卡·小时最直观；如果推理服务占主导，显存·小时更能反映真实占用；如果集群混有A100、H100、L40S等多种型号，折算算力单位才能避免“用旧卡占便宜”。实际落地中，可以主口径加辅助口径：主口径用于计费，辅助口径用于容量规划。
三、互联拓扑：被低估的容量维度
GPU集群的容量不只是“有多少卡”，还包括“卡之间怎么连”。同样8张A100，NVLink全互联与PCIe交换的可用算力差异可达数倍。拓扑信息必须进入资源模型，否则调度器可能把需要AllReduce的分布式任务分配到跨节点慢链路上，导致实际吞吐远低于预期。
关键拓扑参数包括：节点内GPU互联方式（NVLink/NVSwitch/PCIe）、节点间网络（InfiniBand/RoCE带宽与拓扑）、GPU与网卡的亲和性（哪张卡离哪张网卡近）。在调度单元层，这些参数应作为“拓扑约束”参与打分，而不是事后补救。例如，一个8卡分布式训练任务，调度器应优先选择NVLink域内8卡全互联的节点，或至少保证同一Rail下的节点组合。
四、配额模型：从“限额”到“预算+优先级”
传统配额是硬上限：团队A最多用32卡。这种模型简单，但无法应对突发需求和优先级差异。更实用的配额模型应包含三个维度：
- 保障额度：团队随时可用的最低资源，对应预算中的“固定成本”。
- 弹性上限：空闲时可借用的最大资源，对应“可变成本”，需记录借用时长与归还。
- 优先级权重：高优任务可抢占低优任务的弹性部分，但不可抢占保障额度。
计量系统需要记录每次分配的资源量、时长、归属、是否被抢占、是否使用弹性额度。这些记录汇总后，才能生成“谁用了多少、该付多少、预算还剩多少”的账本。
五、统一账本的最小可行结构
统一账本不需要一开始就大而全。一个可运行的最小结构包含五张表：资源注册表（物理卡与切片）、节点拓扑表（互联关系）、分配记录表（谁在何时占了什么）、用量聚合表（按租户/项目/小时的汇总）、价格表（型号单价与折扣规则）。五张表通过resource_id和tenant_id关联，即可支撑“容量查询、成本分摊、预算预警”三个核心场景。
建立账本的过程，本质是把分散在运维、调度、财务三处的口径对齐。对齐之后，容量不再是“大概有多少卡”，成本也不再是“月底看账单”，而是可以按天、按项目、按任务追溯的确定性数据。这是后续所有治理动作——超卖、回收、调价、扩容——的基础。