AI Infrastructure II: Cluster Platform & OrchestrationAI-Infra-Platform，集群平台与调度

几张卡、一个团队时够用。但卡数或用卡的人一多，SSH 模式立刻失控：抢卡、空转、互相踩踏。平台层的价值就是把这笔浪费收回来——同一批卡，利用率量级能翻上去。

无管理集群常年 10–20% 利用率，上调度和配额后翻倍很常见——等于「不花钱多买了一倍的卡」，是整个 AI 投资里 ROI 最高的一环。

下一步　四问体检任何 GPU 环境：谁在用哪张卡？利用率多少？作业挂了会怎样？训练崩了能自动恢复吗？

依据　裸机之痛

默认调度器没有 gang scheduling，会造成「半个作业占着卡启动不了」的死锁。跑分布式训练必须上 Volcano/KAI 这类支持成组调度的——不是优化项，是能不能正确跑起来的问题。

选型别问「哪个最好」，问「准入配额用什么、成组放置用什么」—— Kueue + Volcano/KAI 分层叠用是 2026 共识。

下一步　利用率上不去先查碎片和缺抢占——bin-packing + 配额 + 抢占三件套通常明显改善。

依据　gang 与分层

看隔离要求：MIG 硬件切分最多 7 个隔离实例，适合互不信任的多租户；软件方式（时间片/HAMi）可以更多但隔离弱，适合内部可信任务。

三把尺子（显存隔离/故障隔离/灵活度）定切法：生产用 MIG、内部榨利用率用时间片、非 MIG 卡用 HAMi——先问租户彼此信任吗。

下一步　切分对「小而多」的推理场景立竿见影（15% → 70%+）；大训练反而要把多张卡合成一张用。

依据　四种切法

有公开数据：Llama 3 在 1.6 万卡上 54 天中断 466 次、约八成硬件问题——平均每天好几次。这是万卡尺度的物理规律，不是某家运气差。

容错不是加分项，是有效算力的乘数：坏了 30 分钟恢复 vs 3 分钟自动恢复，一个月下来 goodput 差一大截。

下一步　用客户自己的规模算账：中断次数 × 人工恢复时长 vs 自愈时长——客户往往低估频率、高估恢复速度。

依据　故障必然

大概率有：那只是活跃率（有 kernel 在跑），不代表有效。真正的指标是 MFU——大规模训练 40% 就算优秀；90% 活跃率背后往往藏着一半浪费。

三层口径（占用/活跃/有效）能差好几倍；四大黑洞按序排查：数据管线 → 通信重叠 → 碎片 → 容错。

下一步　三层体检表 + 四黑洞清单做免费利用率诊断——先量出浪费，方案自然就有了；配 chargeback 让浪费有主。

依据　三层口径

引擎把单个模型跑快，平台把它变成能扛生产的服务：多副本高可用、按流量弹性、灰度发版、KV 感知路由。能跑 demo 和能扛百万请求，差的就是这一层。

推理扩缩看队列/TTFT/KV 而非 CPU；冷启动分钟级所以要提前预测、留热备——这是和无状态 Web 最大的运维差异。

下一步　训练推理同集群混部：推理保基线 SLA、训练填谷做低优——一套集群两种节奏，利用率最高。

依据　引擎与货架

三问定档：有没有专职基础设施团队、负载类型、上线速度。没团队或要快 → 托管集群/ API；有团队、负载稳定、压长期成本 → 自建。多数成熟客户是混合。

自建的隐藏成本 = 调度/切分/容错/观测四列活，尤其容错自愈最难——托管的溢价买的正是这些。

下一步　用定档器把三问过一遍；演进按责任递交线渐进，底层用 DRA 等开源标准防锁定。

依据　责任递交线

「翻一倍」是量级说法，不是能签的承诺值——写进合同的应该是口径、基线和相对改善，不是一个绝对百分比。三件事把它变成可签的：先定口径，训练写 MFU、生产写 goodput，并注明不采信 nvidia-smi 的活跃率；先测基线，用他自己的集群和作业跑一版现状，没有起点就没有「提升多少」；承诺动作而不是数字，四大黑洞按序排查，写清这次堵哪个洞、堵完怎么复测。至于本页那组 10–20% → 50%+，是「无管理」与「上了调度 + 配额 + 抢占」两种状态下的量级区间，讲趋势够用，进合同就要换成他自己那台机器上的基线数。

绝对值承诺一定输在两个地方：口径——客户拿 nvidia-smi 的 90% 说自己早就达标了，或者反过来逼你去堆一个错觉指标；工况——换一批作业、换一批数据，同一套平台就是另一个数。还有一句护身的：MFU 40% 已经是行业顶尖（Llama 3 也在这个量级），谁承诺得比这高出一截，不是口径不同就是没干过。

下一步　把「先测一版基线」写成签约前的一道工序，别等验收时补：基线一测完，双方争的就不再是百分比，而是「下一个洞怎么堵」——把利用率写成能签的话那张表可以直接当条款骨架。

依据　三层口径与承诺口径　·　裸机之痛

先拆成两段再报，混着报一定失真。「搭起来」是一次性的——托管 K8s、GPU Operator、选调度器、配切分、接监控，起手式走完就能提交作业；「管得住」是长期的——坏节点救火与自愈值守、配额与优先级评审、组件跟着上游走的版本升级、利用率看板与分摊账单的日常运营。而且周期和人数不是常数，是档位定的：托管把调度、切分、容错、观测这四列活替你扛掉几列，你就少养几列的人。

这题答成「装完 K8s 就好了」，后面所有的怨气都从这里长出来。压垮自建决心的通常不是搭建，是容错自愈——万卡尺度上中断是物理规律、平均每天好几次，值班表是天天要排的。把两段当着客户的面分开，既显得你真干过，也让他自己把托管的溢价算明白。

下一步　让他先过一遍定档器，再拿自建隐藏工作量那四列逐列问「这列谁来做、谁值班」——问完范围和人力自己就浮出来了，比你报一个总人天可信得多。整体成本别只报卡价：人力是姊妹册 TCO 四件套里的一件。

依据　自建的隐藏工作量与三问定档　·　自愈循环

别签功能清单，签演练加记录：每一项职责都要有一个当面演给他看的动作，外加一份事后翻得出来的记录。调度——提交一个必须成组的训练作业，看它是整批拿到卡，还是半个作业卡在那里；切分——按定好的切法和份数跑满，看隔离是不是真的；容错——当场拔掉一个节点，掐表看检测、驱逐、替换、续训走完要多久，这一条最有说服力；观测——看板能不能当场指出「今天漏得最多的是哪个洞」。再加治理面一条：四条控制链每条都要有拦得住的闸和留得下的记录，策略文档不等于控制生效。

功能清单签完是各说各话：客户买的是「不再抢卡、不再半夜断」，你交的是一堆组件，验收当天对不上。换成可演练、可复现的证据，争议在验收当天就关掉了。而且拔节点这类演练必须事前写进验收项——事后再提，没人敢配合。

下一步　验收清单和启动会一起签，三样齐了再开工：一份基线利用率（同口径、同工况）、每项职责的演练与通过判据、发布可追溯那张图上要留的证据字段。

依据　自愈循环　·　四条控制链　·　发布要可追溯