GPU集群还有空闲显存，任务却一直Pending，不一定是调度器没看到资源。总量够用，不等于每张卡上都放得下；单个worker能启动，也不等于一组分布式worker能同时就位。排查时先区分配额、放置和作业组约束，比盯着一个集群利用率数字更有效。

Run:ai开源让这些调度能力更容易被检查和组合，但不会抹去容量与拓扑限制。下面用两张虚构GPU的装箱例子，把“还有资源”拆成几个可以验证的问题。Read in English。

先把新闻日期与开源范围说清

Google News收录了Konsulteer在10月15日的报道。它对应的是NVIDIA在10月13日公布的Run:ai开源消息，不是今天才发生的新发布。官方提供完整平台源码，也允许分别采用四个模块：KAI Scheduler、GPU Fractioning Operator、KAI Resource Management、Workload Map。

这四个名字不代表同一层。调度器处理工作负载放到哪里；资源管理表达团队份额；GPU共享组件提供共享能力的集成；Workload Map描述不同作业类型的结构。下面的容量推演是原创教学模型，不是Run:ai内部算法复刻，也不评价某款GPU的实测性能。

总显存之和为什么会骗人

设只有两张虚构的卡，每张可用于本例任务的容量为10 GiB。四个任务分别需要4、4、6、6 GiB；总需求20 GiB，恰好等于总容量。如果按顺序把任务放到第一张能容纳它的卡上，前两个4会占据卡A，第三个6放到卡B。最后一个6没有位置。

此时A还剩2，B还剩4，总空闲恰好也是6。然而一个需要6的任务不能把自己的单卡内存需求拆成2+4；它需要一张满足约束的卡。将任务重排成A放4+6、B放4+6，四个任务则都能容纳。这里比较的是启动前的可行布局；已经运行的任务不能假定可以零成本挪动，迁移或重启需要计算状态保存与恢复代价。

这说明某次贪心放置失败，不等于这批任务不存在可行放置；反过来，总量相等也不保证当前布局可行。这里暂时忽略计算资源、驱动保留、运行开销和拓扑，目的只在于单独展示内存碎片。真实任务必须测量峰值需求，而不是照抄这组数字。

六个断言复现碎片与可行性

下面先运行最简单的first-fit，再用穷举判断这个小例子是否存在放置。穷举不修改传入容量，也不真正分配GPU；它不是建议在大型集群中遍历所有方案。任务必须是正数、容量非负，本文输入已满足这些教学前提。对n个任务、m个候选设备，这个直接搜索最坏会探索m的n次方量级的分支；它只适合这里的小构造。

# Fictional memory capacities in GiB; no GPU or scheduler is run.
def first_fit(jobs, capacity):
    free = list(capacity)
    for need in jobs:
        for i in range(len(free)):
            if free[i] >= need:
                free[i] -= need
                break
        else:
            return False, free
    return True, free

def feasible(jobs, capacity):
    # Exhaustive search for this tiny example; not a production scheduler.
    free = list(capacity)
    def place(k):
        if k == len(jobs):
            return True
        for i in range(len(free)):
            if free[i] >= jobs[k]:
                free[i] -= jobs[k]
                if place(k+1):
                    return True
                free[i] += jobs[k]
        return False
    return place(0)

jobs, capacity = [4,4,6,6], [10,10]
ok, left = first_fit(jobs,capacity)
assert not ok and left == [2,4]
assert sum(left) == 6  # enough in total for the remaining 6, but fragmented
assert feasible(jobs,capacity)
assert first_fit([6,6,4,4],capacity)[0]
assert not feasible([6,6,6,4],capacity)
assert capacity == [10,10]  # planning did not mutate external capacity
print("6 placement checks passed")

本地执行通过六项检查：原顺序放不下、失败时总空闲仍有6、存在其他可行方案、换一种顺序可放下、超总量的一组无解、调用者容量未被改写。两个函数只考虑一维容量；输出没有证明调度公平、性能隔离或真实吞吐量。

整组任务为什么不能只启动一半

分布式作业可能要求多个worker共同参与。若一个需要两份资源的作业只拿到一份，先启动的worker可能等待同伴，同时占着本可给其他作业使用的资源。只看“已有Pod运行”会掩盖整组尚不可用的事实。

KAI Scheduler项目列出批调度、装箱、队列和公平策略；官方公告也说明其gang scheduling会对多Pod作业做整组放置。这里的核心是按作业约束判断能否一起就位，而不是承诺所有Pod在同一个物理时刻开始执行。

可用教学例子来思考：假设整组必须同时安排完四个任务，原顺序first-fit的部分放置不能直接提交。先在计划副本中验证整组可行，再对真实资源执行有一致性保护的预留；若并发调度期间资源变化，应重试或撤销预留。本文函数只完成计划可行性部分，没有实现集群中的并发事务。

配额足够，仍可能因为位置排队

配额回答“允许这个团队消费多少”，放置回答“当前哪些具体设备能承载”。一个团队有20 GiB额度，不意味着它能在任何时刻取得两块各10 GiB连续的设备容量。其他团队的既有任务、节点选择条件、GPU类型和通信拓扑，都可能缩小可用集合。

不要为了消除Pending立即扩大配额。先看等待原因对应哪一层：被队列策略挡住、单卡显存不足、整组资源不齐，还是设备与节点条件不符。只有前一种明确与额度有关时，调整额度才直接针对问题；后几种需要重排、等待、缩小需求或改变允许的放置范围。

公平和吞吐也可能冲突。把小任务塞满空隙有助于利用率，却可能让较大的整组作业长期等待。评估策略时要同时记录等待时间分布、完成作业数、抢占和重启代价；只保留平均利用率，无法看见谁被持续推迟。

GPU份额不能直接换算成请求性能

共享容量的大小不直接等于服务能力。显存限制、计算时间、带宽、模型加载和请求长度影响不同；“半张卡”不保证一半吞吐，也不保证延迟按比例变化。共享机制允许哪些隔离、支持哪些硬件与软件组合，需要按对应组件文档核对。

对于在线推理，观察首token延迟、后续token间隔、尾延迟、并发与错误率；对于离线训练，还要记录有效训练进度和重启损失。负载与统计窗口保持一致，再比较独占和共享。本文没有运行GPU测试，所以不提供性能改善百分比。

站内KV cache显存文章讨论推理中会随请求变化的内存部分。把这类峰值纳入任务需求估计，比只根据模型权重大小申请份额更接近实际；调度器无法靠装箱弥补低报的峰值。

先用最小范围验证，再决定采用哪些组件

开源的直接价值是可以查看接口、约束和实现，按需求采用模块；它不等于团队已经具备生产运维能力。官方说明社区产品不要求付费Run:ai订阅，但不包含企业支持，源码与分发产物各有适用条款。评估社区版本时仍需核对所用组件的版本、支持边界和升级路径。

一个合适的试验起点是非生产环境：准备已知峰值的几类任务，保留原调度基线，分别制造总量不足、碎片、整组不齐与队列额度不足，再检查调度事件和等待原因能否解释结果。先验证哪一层行为解决了哪一种等待，再谈统一替换平台。

若现有平台只缺GPU感知放置，未必需要一次引入完整控制面；若缺的是团队配额语义，也不能仅靠更紧凑的装箱补齐。以问题选择组件，能让后续故障归因和回退保持清晰。

来源与补发说明

新闻发现来自Google News收录的10月15日报道，原始发布为10月13日官方公告；可检查KAI Scheduler与Run:ai平台源码。两幅图、容量构造和代码为原创。本文10月16日补发，保留原计划11:30文章日期；新闻来源早于该时段。

如果装箱反例和排查顺序帮你分清了任务究竟在等配额还是等位置，欢迎通过文末支持区自愿支持。