type
status
date
slug
summary
tags
category
icon
password
priority
Roofline model是高性能计算领域用来分析程序性能瓶颈的一个直观模型，因为画出来像一个屋顶形状而得名。如下图，横坐标是算法的计算强度Flop/Byte（算法的浮点计算数除以内存访问量），纵坐标是算力Flop/s，它描述的是如果算法计算强度提升算力线性提升（Memory-Bound），直到算数强度超过硬件的拐点，之后算力逼近硬件的上限（Compute-Bound）。它核心回答了：你的程序到底受什么限制——计算能力还是内存带宽？应该优化哪里？
这是一个令人印象深刻的模型，它简单而睿智。但我想讲的并不是高性能计算，而是算法团队人才、计算资源（尤其是GPU）及产出之间的Roofline，我称之为Talent Dilution Roofline。
有几个条件：
- 假设一个算法业务、团队一段时间内的总的计算资源（GPU）总量不变且相对有限。
- 算法的核心产出是依靠计算资源（GPU）的训练和一定转化率的实验Launch支撑的。
在这几个条件下，以团队的人数为横坐标，以产出的量为纵坐标，可以画出一个Roofline曲线。
产出↑
| /‾‾‾‾‾‾‾‾‾
| /
| /
‾‾‾‾‾‾‾‾‾→ 人数
先画个潦草的markdown图吧，它描述的过程是，随着人数上升，总资源量充足，业务产出随着团队人数正向增长，可以称之为“people-bound”；直到人均的GPU计算量低于一个阈值，总的产出量完全受限于总的GPU量，那么产出将不会上升，对应称之为“resource-bound”。
讲一个更形象的故事，团队里有80块GPU，一个任务训练任务要8块，一个人有能力研究3组策略，团队有1个人的时候，产出是N，有两个人的时候，产出是2N，有3个人的时候，如果预期3N的产出，要有90块GPU，80块GPU产出就是2.67N，4个人，5个人，到100个人，产出都是2.67N。实际情况就是当他要做训练任务的时候，得排队！
实际的情况可能更加复杂，没法这样简化，但是它的直到意义是，我们得大概估计出这个拐点的阈值，弄清楚人均多少GPU是这个拐点，如果团队人数是固定的，低于这个阈值，要去加机器资源。如果团队GPU资源是固定的，不要盲目的加人，要保障人均资源在阈值之上的加人才是有效的。
算法产出不够好，不一定是人不够多，可能是计算资源不够多！先搞清楚是people-bound，还是resource-bound。
到这还没结束，更加恐怖的问题还没有揭示出来，我们再增加几个条件：
- 产出服从二八定律，团队的80%产出是20%的“Talent”贡献的，即每个人使用资源量到业务产出的转化率有高低区别。
- 资源不足时，团队采用公平的计算资源（GPU）分配方式，如排队等待分配。
那么能画出下面这个曲线（示意图，莫深究）：
它描述的过程是：
- 随着人数上升，总资源量充足，业务产出随着团队人数正向增长。人数太少，任务并行度不够。
- 人均 GPU 降低到有效训练的最小值，加人不再提升总业务产出。
- 最有趣的来了，由于公平地团队GPU分配制度，“核心产出贡献者”的人均资源量不断下降，总业务产出下降！本质是，平庸成员贡献不抵损失，人才密度稀释造成“负边际贡献”。
如果资源充足，人够不，加人能提升总产出。无论是招聘高潜还是一般的人，都能增加总产出。如果资源开始不足，增加高潜人才才可能提升业务总产出，增加一般人力只会拉低业务总产出。
一块H100一年折旧大概2万刀，使用16块就可能比人贵了，再加上供应稀缺。那么大概率会出现招人的速度快过了资源采买的速度。想提升业务产出，朴素的思想是加人！按照上面的Talent Dilution Roofline，GPU资源比人涨的慢，人越多可能产出越低! 然后继续加人！
要破除这个恶性循环，首先要判断是“people-bound”还是“resource-bound”，识别清楚人均计算资源拐点。加人还是加资源，判断清楚！
然后，增加人才密度而不是增加人数。算法本来就是一个产出二八分化的职业，在模型变大，GPU资源稀缺下，只会变得更加严重，少数人驱动大收益（这里的少数人，未必是具体人，是指每一个时间段下，产出是都不是均匀的）。
“resource-bound”下，公平的资源分配制度，不利于团队的总产出增加！要在公平和效率下做出抉择，也需要足够的判断力，把核心项目、核心人力的资源给够！