GPU 显存分片

GPU 显存分片

GPU 显存分片解决一个具体而普遍的问题：一张 80GB 的 GPU 跑一个只用 4GB 显存的推理服务，95% 的显存被白白占住。HeteroFlow v2 的分片体系把一张物理 GPU 按显存 / 算力配额分给多个任务复用——任务声明 gpu_memory_mb（显存上限）与 gpu_compute_ratio（算力比例），平台记账准入防止一张卡被超卖，NVIDIA 卡上额外通过 MPS 下发运行时限额，MIG 能力已启用的卡上则执行真正的硬件切分。

先说清这条能力的产品边界：分片是同一租户内部（或同一共享租户组内）的显存与算力复用能力，它防"善意超用"（申请少用多、配置失误），不防恶意抢占；"分片"与"隔离"是两回事，平台按三级技术路线（硬件级 / 驱动级 / 软件记账）如实区分每一档的隔离强度，组外跨租户禁止共卡由平台强制。

典型场景：AI 推理服务（同一租户）

分片前：A100 80GB 只跑一个 4GB 任务，利用率 5%
分片后：16GB 推理 A + 32GB 训练 B + 32GB 推理 C 共用一张卡，显存记账 100% 有主

功能总览

三级分片技术路线

分片体系按"边界由谁强制"分三级。落到一台节点上是哪一级，不由请求方决定，而由节点上报的 GPU 能力自动推导。

gold：硬件级切分（NVIDIA MIG）

原理：MIG（Multi-Instance GPU）在芯片级把一张物理卡切成多个具备独立显存、算力与缓存的硬件实例，每个实例对操作系统的呈现与一块独立 GPU 无异。平台走指令通道真实执行：调度器按显存需求从官方档位表选出 profile（如 1g.10gb、3g.40gb），在 CAS 认领任务后向 agent_slice_requests 表下一条创建指令；任务在设备标识回报之前不会被下发（刻意拦截）；节点 agent 轮询认领，先核对 GPU UUID 与档位可用性，再执行 nvidia-smi mig -cgi 创建分区并回报 MIG-<uuid>/<gi>/<ci> 设备标识；控制面把标识写进任务标签放行下发，容器以 --runtime=nvidia + NVIDIA_VISIBLE_DEVICES=<MIG设备标识> 启动——容器内的 nvidia-smi -L 只能看到分到的分区。任务释放时自动下发销毁指令（-dci / -dgi）。

隔离强度：硬件强制。一个分片的致命错误不影响其他分片，容器内无从越界——这是分片体系里唯一可称"隔离"的一级。

当前平台状态：软件链路（创建 + 销毁）已接通，并于 2026-09-02 在真实 NVIDIA A800-SXM4-80GB 上完成全套矩阵真机验证：基础创建/销毁闭环、多分片并发（1g.10gb + 1g.20gb + 3g.40gb 三容器同时运行互不干扰）、超额请求边界（账本正确拒绝、agent 二次核验兜底）、清场全部 PASS，CUDA 探针实测证实是硬件级显存隔离而非软件限流。真机验证撞出的 3 个 P1 中 2 个已修复（重复 destroy 虚假告警、创建路径 GPU UUID 漂移防护——后者的代码链路已补齐、完整真机端到端验证待补），剩 1 个未修复（destroy 与容器停止之间的竞态窗口，超时可能产生真孤儿分区）；另有一条已知限制：MIG 模式的卡与普通整卡任务不能共存，调度器暂不感知这层状态。生产启用前需评估这些缺口。

工程约束：启用 MIG mode 需要 GPU reset + root 权限，平台不做远程启用（节点需一次性人工准备）；MIG 不支持 NCCL/P2P，切片后只能跑推理、无法多卡训练；profile 是固定几何档位，不能自定义任意显存值。

silver：驱动级限额（NVIDIA MPS）

原理：MPS（Multi-Process Service）让同卡多个 CUDA 客户端进程共享一个 daemon，平台把分片配额翻译为运行时限额变量注入容器：CUDA_MPS_PINNED_DEVICE_MEM_LIMIT（显存上限）与 CUDA_MPS_ACTIVE_THREAD_PERCENTAGE（SM 算力百分比），并挂通 MPS 管道。限额分两层：daemon 侧整卡显存兜底上限（容器内改不掉）挡"整卡被超卖"；客户端侧变量表达该分片自己的配额。

隔离强度：部分约束。只约束接入 MPS daemon 的"善意"客户端，容器内仍可改小/清除限额变量（按 NVIDIA 文档只能收紧、放宽无效）；一个客户端的致命错误会通知同卡所有客户端退出。对外只称"资源配额 / QoS 限额"，不称隔离。

适用卡型：仅 Volta 及以上（CC ≥ 7.0）的 NVIDIA 卡——显存上限与 per-client 算力配额都是 Volta 引入的能力；pre-Volta 卡（P100/K80/P40）上 MPS daemon 虽能启动但零限额，平台不再为其上报 mps_capable，一律落 bronze。

当前平台状态：管道（pipe 目录挂载 + --ipc=host）已在真实 L20 节点挂通；per-client 限额已于 2026-09-12 用真实 CUDA 工作负载真机验证生效——双容器各挂独立限额并发运行，MPS daemon 的客户端列表与容器进程 PID 精确对应；算力限额真机实测 25% 对 100% 吞吐约 3 倍压制。daemon 侧整卡显存兜底上限已生效但未经真机验证。MPS daemon 由 agent 用 systemd-run 托管到独立 unit（heteroflow-mps），与 agent 生命周期解耦，重启 agent 不会连坐杀掉全节点 GPU 容器。daemon 不可用时 agent 不注入假管道、心跳不再上报能力；调度器已按 silver 承诺而 daemon 拉不起来时，任务判失败而不是静默降级。

bronze：软件记账

原理：只有平台侧账本——每张卡维护总显存与已记账显存，新分片申请经容量检查（防超卖）与跨租户共卡检查后记账，容器内没有任何运行时限额。

隔离强度：不隔离。任务实际用量可超过申请量（申请 8GB 用 20GB 不会被拦），同卡任务互相影响；边界只在"准入"这一层——一张卡的记账总量不会超过物理容量。

适用场景：所有不具备上述两级能力的节点，以及开发测试、低优先级任务、可信的同租户内部负载。

GPU 分片支持矩阵（如实版）

下表按卡型给出每一级路线的支持情况与平台当前真实状态。矩阵中厂商切分能力的描述来自各厂商官方文档（2026-09-01 核对）；平台状态列是交付口径。

NVIDIA 逐代

国产卡逐家

这张矩阵的口径底线：节点 agent 的心跳只为 NVIDIA 卡生成分片能力条目（mig_capable / mps_capable 两个能力位），其余厂商的判定输入在服务端属预留字段——因此所有国产卡节点在当前生产上一律落 bronze（软件记账），上表"官方切分能力"列描述的是硬件本身的潜力，不是平台的已交付能力。国产卡中昇腾 vNPU 适配器已按华为官方文档整体重写（含逐型号档位表与软件/硬件虚拟化判别位），但未接执行通道、无真机验证；海光现有适配器的历史代码使用了与真实 hy-smi 不符的命令语法，接线前必须按厂商文档重写。容器化节点（agent 本身跑在容器里的节点）无论什么卡一律强制 bronze——容器内无法执行硬件/驱动级手段。

QoS：三档语义与自动推导

QoS（gold / silver / bronze）是对节点分片能力的如实标注，不是调用方可选的服务等级：创建任务的请求体里不存在 qos 字段（传了会被 400 明确拒绝），档位在调度落到具体节点后按硬件能力推导，主调度路径与补偿路径共用同一份推导逻辑。

自动降级的触发条件（gold→silver→bronze 逐级收敛，而非请求协商）：

1. 能力实探降级：mps_capable / mig_capable 由 agent 每次心跳实探上报——宿主机 MPS daemon 挂掉、MIG mode 被关闭，下一次心跳即不再声称，该节点新分片自动落 bronze。不存在"注册时报过一次就永远算数"。

2. 容器化节点强制降级：节点本身容器化时，无论推导出 gold 还是 silver，一律强制降为 bronze（容器内无法执行硬件/驱动级手段）。

3. pre-Volta 卡不声称 silver：算力低于 7.0 的卡即使 MPS daemon 存活也不上报能力位，直接落 bronze——那种卡上 MPS 没有任何限额能力，报了就是假承诺。

4. silver 兑现失败即失败，不静默降级：调度器基于能力位承诺了 silver 而节点拉不起 MPS daemon 时，任务被判失败，而不是偷偷按 bronze 跑完。

5. 框架层的请求式降级链（请求 gold 而硬件只到 silver 则降 silver）属预留的适配器框架能力，未接入生产路径——生产上任务没有"请求某个档位"的入口。

如何观察实际档位：GET /api/v1/slices 返回的 qos_level 字段、容器内环境变量 HETEROFLOW_SLICE_QOS。MIG 任务另有一条硬判据：任务标签里的 heteroflow.mig_device_id（形如 MIG-<uuid>/<gi>/<ci>）——有它才代表卡上真的建出了硬件分区。

分片生命周期

分片账本状态刻意保持简单：allocated（占用该卡的显存/算力额度，任务运行中）→ releasing → 回收（额度归还该卡）。触发回收的三条路径：任务进入终态自动释放、管理员经 DELETE 接口手动释放、孤儿分片 GC 兜底回收。

• 创建：调度器 Bind 阶段 CAS 认领任务后分配分片——推导 QoS、Best-Fit 选卡、跨租户共卡检查、注入环境变量（HETEROFLOW_SLICE_ID / HETEROFLOW_GPU_INDEX / HETEROFLOW_SLICE_QOS，NVIDIA 卡另含 CUDA_MPS_* 限额）、账本落库；任何一步失败则释放分片、剥离环境变量、回滚认领，任务留在 pending 重试。
• 挂载：任务下发 agent，agent 完成钉卡与 MPS 管道接入（MIG 任务则等硬件分区回报后放行）。补偿路径：agent 上报 running 时若任务尚无分片，只补记账本（容器已启动，环境变量注入已来不及），账本钉在容器实际使用的卡上。
• 环境变量一致性：任务被重排回 pending 再绑定前，平台统一剥掉旧的全部分片变量再注入新的一组，避免容器钉到的卡与限额指向的分片对不上；分片任务总是注入 agent 自己的 GPU 可见性变量。
• 回收与重启恢复：服务重启后账本自动从数据库回填（含租户归属归一化与分片 ID 计数器顶高，防重启后 ID 撞车与跨租户约束失效）；多实例部署升主时同样以数据库为准补齐账本。

分片账本与调度

• 单卡剩余显存检查：每张卡维护总显存与已记账额度，新分片须同时通过容量检查（gpu_memory_mb 不超过单卡余量，且不超过集群内最大单卡显存的 90%）与算力记账（gpu_compute_ratio 缺省按 0.5 记账）。账本经 400 步随机分配/释放序列的属性测试验证自洽无超卖。
• Best-Fit 选卡：满足请求的候选卡中选余量最小的，把"已经开了口的卡"塞满，保住整卡余量给大请求——这也是最主要的防碎片手段。
• 跨租户共卡约束：新分片必须与卡上每一个已占用租户"同租户或同共享租户组"（fail-closed）；组外租户的任务不会被记到同一张物理卡上。报错会明确写出有多少张卡因跨租户约束被排除——这种情况加显存无用。
• 判定丢失的卡不接新分片：心跳路径判定某张卡丢失后（GPU_LOST 告警），分片池随心跳同步该状态，选卡与容量检查都跳过它；已分配在它上面的分片不动（不释放、不迁移），卡恢复后随下一拍心跳重新可分配。
• 孤儿分片 GC：每 60 秒对账一次——跳过最近 60 秒内创建的分片（避免误杀刚分配的），检查其余分片关联任务的状态，任务已终态而分片仍占用时自动回收，防止"僵尸额度"永久占卡制造假碎片。
• MIG 指令的运维接口（平台管理员）：GET /api/v1/slice-requests?node_id= 查看硬件分片指令行状态（排障主入口）；僵死指令会明确标注 HARDWARE STATE UNKNOWN，须人工上机核对。
• API 面：GET /api/v1/slices（列表，支持按节点/卡过滤）、GET /api/v1/slices/{id}（详情，非属主返回 404）、GET /api/v1/slices/stats（统计）、GET /api/v1/slices/history（操作历史，分页）；手工建/删分片（POST / DELETE）仅限平台管理员或 tenant-admin，定位调试运维用途。统计与历史接口对租户主体严格按本租户收窄（共享组的邻居也看不到），判不出身份时按最窄处理。

碎片问题：现状如实说明

碎片化指"集群总余量足够，但没有任何一张卡能装下新请求"。当前软件记账模型下碎片体现在卡与卡之间（每卡余量分散），主要来源是规格混布、任务生命周期错配，以及跨租户不共卡的刻意取舍（某租户占 2GB，整卡对其他租户即不可见——隔离性优先于利用率）。

当前生效的是防碎片机制：Best-Fit 选卡、分配失败留 pending 随任务周转自愈、终态自动回收、孤儿 GC。观测碎片用现有接口组合：/slices/stats 显示总余量充足、而分片任务持续 pending 且报 insufficient GPU memory 或 no GPU available for tenant，就是碎片（或租户占卡）在起作用。需要控制碎片时用运营手段：同批节点跑同规格分片、大任务错峰提交、按租户规划节点容量。

碎片"整理"的设计方案未上线（代码在库、无生产入口）：不存在碎片整理 API、不存在自动整理服务，请勿对接任何 defrag 类接口。设计形态供参考——触发条件为节点碎片率超过阈值（可用余量充足但最大单卡可分配片偏小）；整理过程为生成迁移建议、识别可驱逐分片、DryRun 预览、按 Best-Fit 重新集中分配；对运行任务的影响是只驱逐显式标记 preemptible=true 的可抢占分片、长任务不被动手，整理过程可取消、失败不留半截状态。该方案主要服务于 MIG/vNPU 这类固定档位切分带来的"硬碎片"，随硬件切分一起处于待接线状态，何时上线属产品决策。

隔离性：必须说清的边界

平台文档有一句反复强调的历史教训：分片不等于隔离。MPS/记账路线只承诺"资源配额与记账准入"；需要硬边界承诺的场景（金融政企、严格多租户），当前只有 NVIDIA MIG 落地并完成真机验证（生产启用前仍需评估前述已知缺口），昇腾 vNPU 等其余硬件切分技术未上线、不可对外承诺。

使用示例

创建分片任务（推荐路径）——分片需求是任务的顶层字段，gpu_required 不要填（填了 >0 表示占整卡，不走分片）：

curl -X POST http://your-server:3333/api/v1/tasks \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "name": "inference-service",
    "image": "pytorch/pytorch:2.0.0-cuda11.7-cudnn8-runtime",
    "command": "python serve.py",
    "gpu_type": "nvidia",
    "gpu_memory_mb": 4096,
    "gpu_compute_ratio": 0.5
  }'

取值约束：gpu_compute_ratio 须在 (0, 1]（越界 400 并带回原因；算力按四舍五入取整成 1-100 的百分比）；gpu_memory_mb 若设置须 ≥ 32 MB。请求体中的未知顶层字段直接 400（防拼错字段静默失效），qos / qos_level 这类字段同样会被拒绝——QoS 只能靠选节点拿到。

前端：创建任务页提供"GPU 分配方式"单选（整卡 / GPU 分片），分片模式下显存最小 32MB 且须为 32MB 整数倍、算力为 1-100 整数百分比（留空 = 不限算力），输入不合法在表单内直接报错；/slices 分片页展示全部分片与粒度能力卡。

查询与观测：

curl -H "Authorization: Bearer $TOKEN" "http://your-server:3333/api/v1/slices?node_id=node-1"   # 列表与 qos_level
curl -H "Authorization: Bearer $TOKEN" http://your-server:3333/api/v1/slices/stats              # 记账统计
curl -H "Authorization: Bearer $TOKEN" "http://your-server:3333/api/v1/slices/history?limit=20" # 操作流水

规格规划经验：推理任务显存按模型大小 × 1.5、算力 0.25-0.5；训练任务显存按模型大小 × 3（含梯度与优化器）、算力 0.5-1.0；预留 10-20% 显存余量避免 OOM。

部署要点

MPS（silver，NVIDIA Volta+）：

• Linux + NVIDIA 驱动 450+，nvidia-cuda-mps-control 随驱动安装；Docker + NVIDIA Container Toolkit。
• 节点侧无任何分片配置项——agent 检测到 GPU 后自动上报，daemon 由 agent 自动拉起并托管到独立 systemd unit。
• 验证：节点 gpu_capabilities 含 mps_capable=true 后提交分片任务，/api/v1/slices 里 qos_level 应为 silver。

MIG（gold，需一次性人工准备）：

• GPU 型号必须在 MIG 支持矩阵内（A100/A800/A30/H100/H800/H20/H200/B200 等；A10/L4/L40/T4 等没有 MIG 电路）。
• 必须先在节点上手工启用 MIG mode（nvidia-smi -i 0 -mig 1，需 root + GPU reset，会打断该卡在跑任务）——平台不会替你启用，也只在 MIG mode Enabled 时上报能力位。
• 启用后务必清掉卡上残留旧实例，否则平台按"整卡空闲"记账会超卖。
• Server ≥ v2.6.29、Agent ≥ v2.6.8（更早版本带 MIG 容器 100% 启动失败的已知缺陷）；指令通道依赖 PostgreSQL 存储（非 PG 部署下相关接口返回 503）。
• MIG 卡不建议与普通整卡任务混跑同一张卡（调度器暂不感知互斥状态）。

已知边界与路线

1. MIG 现存已知问题：destroy 与容器停止之间的竞态窗口未修复（可能产生真孤儿分区，出现 MIG_PARTITION_ORPHANED 告警需人工核对）；创建路径的 GPU UUID 漂移防护代码链路已补齐、完整真机端到端验证待补；MIG 模式卡与整卡任务互斥未被调度器感知；MIG 档位选型只看显存不看算力。首次在新型号 MIG 卡上启用建议按检查单核对档位表。

2. MPS 的边界：daemon 侧整卡显存兜底上限未经真机验证；算力百分比是粗粒度软限流而非严格配额；32MB / 1% 级小粒度限额的容器内真实强制效果尚未真机复测（前端已如实标注）。

3. 国产卡硬件切分属路线图：昇腾 vNPU（已按官方文档重写）/ 寒武纪 MIM / 燧原 DRS / 壁仞 SVI / 沐曦 sGPU / 海光 vDCU（第一阶段指令通道与 agent 执行层已通，待调度器接入与真机验证）/ 摩尔线程 / 昆仑芯——均为"适配开发中"，不承诺时间；生产环境统一软件记账（bronze）。控制面到 agent 的指令通道已与厂商无关地建好，接一家厂商需要在 agent 侧加执行分支并按厂商真实文档重写命令语法。

4. 碎片整理：整理（迁移重排）方案未实施，当前靠防碎片机制与运营手段。

5. 容器化节点与 pre-Volta 卡：一律 bronze，这是能力边界的如实结果，不是配置项。

<!-- 状态标注说明：本文能力状态口径——"真机验证"指在真实 GPU 节点端到端运行并确认结果（MIG：2026-09-02 A800-SXM4-80GB 全套矩阵，含 CUDA 探针硬件隔离实证；MPS：L20 双节点管道 + 2026-09-12 真实 CUDA 负载限额生效验证，算力约 3 倍压制；daemon 侧显存兜底上限未真机验证）；"生产生效"指代码合入、有测试钉住并在开发环境长期运行；"适配开发中"指检测/适配代码按厂商官方文档对齐但无真机端到端验证，生产环境统一软件记账（bronze），不构成硬件切分已交付的承诺。国产卡硬件切分矩阵中"官方切分能力"描述的是硬件潜力，非平台已交付能力。 -->