6.1 TOPs 核心概念

6.1 TOPs 核心概念

本节摘要：TOPs 的世界只有四种东西：work item（任务单元）、item 上的属性（任务的参数与上下文）、依赖边（先后关系）、调度器（在哪执行）。本节用三个节点的迷你产线走一遍模型，重点理解"属性随任务流动"这一与 SOP 最相似也最不同的设计。

迷你产线：三节点走通

在 TOPs（Tasks 上下文）里搭：

1. Wedge（ wedge count 设 10）——产下 10 个 work item，每个带不同的 wedgenum、seed 等属性。右键节点选 Generate——不需要跑任何模拟，先"纸面生成"任务清单；
2. ROP Geometry Output（TOP 版）——上游接 Wedge 后，它为每个 item 生成一个"调用 SOP 网络出几何"的任务；在其参数里把 SOP 侧的 seed 参数用 @seed 表达式绑定——每个 item 用自己的种子；
3. 调度：顶部 Scheduler 设为 Local Scheduler，点 Cook。10 个 bgeo 按核数并行落盘。

图 6.1-1 TOP 的四要素模型

属性流动：TOP 与 SOP 的镜像

TOP 最妙的设计是 item 属性与 SOP 属性同构：Wedge 写的 @seed 在下游任何 TOP 的参数栏里可引用；HDA Processor / ROP 类节点再把 item 属性注入到 SOP 侧参数（参数映射里写 @seed）。于是产生一条链：

Wedge 属性 → TOP item 参数 → 注入 SOP 网络的参数 → 影响几何 → 产物差异
​

对比 2.3 你手工 copyTo 改种子的脚本——TOP 做的是同一件事，但加了依赖、调度与缓存三个工业件。

Generate 与 Cook：两段式执行

TOP 节点有两个状态按钮，理解它们是排错的第一课：

• Generate（生成）：只算出任务清单（多少 item、各自属性），不执行。用来审查产线——先看看会跑 1000 个还是 10 个任务；
• Cook（烹煮）：真正执行。调度器介入，产物落盘。

⚠️ 常见坑：直接 Cook 一个动态产 task 的网络（如按文件列表展开），任务数比预期多一个量级，农场费用爆炸。习惯：先 Generate 看清单，确认后 Cook。

💡 关键直觉：SOP 图里流动的是几何，TOP 图里流动的是任务。你依然在"写规则"，只是规则的产品变成了"要做的事"。

本节要点回顾

• 四要素：work item / item 属性 / 依赖边 / 调度器；
• 属性同构：@seed 从 TOP 参数直通 SOP 参数，变体生成因此丝滑；
• Generate 先行：先审清单再烹煮；
• 缓存按 item 记账：失败重跑只补失败项；
• 换调度器不改网络——逻辑与执行解耦是能上云的前提。

模型清楚了，下一节把整条山体产线架起来。

廕伸：从 SOP 到 TOP 的映射表

TOP 的心智模型是"SOP 的任务版"：SOP 处理点，TOP 处理工作项（Work Item）；SOP 的属性对应 Work Item 属性；Cook 即执行。映射表一张即可上手：

[SOP -> TOP 概念映射]
点/图元       -> Work Item(一次可调度的计算单元)
属性(@)       -> Work Item Attribute(@分隔两类: 上游几何/任务数据)
节点Cook      -> Work Item Schedule(本地/农场/云端)
Copy/ForEach  -> Partition/Merge(合并与分组调度)
缓存(display) -> Cook 遗留产物(.pdg目录下按workitem落盘)
​

第一个 TOP 网络的黄金实验是 CSV 驱动批量变体：ROP Geometry TOP 设 @pdg_index 为随机种子，上游用 @pdg_index 替换 fit01(rand(seed)) 中的种子——一百个建筑变体即变成一百个可并行、可断点续算、可农场分发的工作项。

廕伸：依赖图与调度器的调优

[调度三问]
1. 工作项之间有无隐式串行?(上游缺 Wedge/Partition 造成的伪依赖)
2. 单项耗时是否均衡?(过小项应 Partition 合并, 减少调度开销)
3. 失败项的重试语义?(Top Nodes 的 retry 策略与失败缓存清理)
诊断: PDG Graph UI 的 Timeline 视图看并行度瀑布图
     —— 理想形态是满宽的带状, 出现长锯齿=串行瓶颈
​

再给一个从 SOP 思维切换到 TOP 思维的口诀："把 foreach 循环变成网络图"。SOP 里 For-Each 节点在单进程内串行迭代，TOP 把每次迭代展开为图上的独立节点（工作项），从而获得天然的并行与缓存。经验法则：迭代次数少于十次且每次很重时，For-Each 更简单；迭代上百次、或需要农场算力、或需要断点续算时，TOP 的额外复杂度开始回本。PDG 学习曲线陡峭的表象下，核心概念其实只有这一个映射，想通它，剩下的节点都是这个映射的变体。

还有一个 TOP 学习期的典型陷阱需要点名：不要在第一天就试图把整个现有场景搬进 TOP。PDG 的正确切入点是"最小的完整闭环"——CSV 十行、Wedge 五个变体、本地调度、一个输出目录。跑通这个二十分钟的闭环，理解工作项的生命周期与缓存路径规律，再逐步扩容。从大场景开始改造的尝试，几乎都卡在调度配置与路径权限的泥潭里，然后得出"PDG 太复杂"的错误结论——复杂的不是 PDG，是入口选错了。

关于工作项的粒度选择再给一条经验法则：单个工作项的合理耗时下限约十秒——低于此值时调度与文件系统的开销占比过高，应当用 Partition 合并（如把逐变体合并为逐批次）；上限则由重试成本决定，超过一小时的项应考虑内部再分段。粒度调优的观察工具就是 Timeline 瀑布图：项太小呈细碎锯齿、项太大呈稀疏立柱，调到连续带状即健康。这条法则让"任务拆多细"从玄学变成有图表支撑的工程判断。

最后用一个数字锚定 TOP 概念的投入产出：学习 PDG 的入门成本约为一到两周（以每天两小时计），而在真实生产中一次中等规模的需求变更（改两百个资产的地块参数），手动操作与 TOP 重算的时间差是一小时对五分钟，且后者可无人值守。按一个项目的变更高频度折算，两周学习投入通常在第一个月内回本；这个估算本身也可以写成一行 Python 给管理者看——用数据说服而不是用酷炫截图，是程序化 TD 在组织里的正确姿态。