Capordia明确日历应保护的内容
先从无法再等待的决策入手：结果评审、移交给其他团队，或租用期结束。为每个项目指定有权验收其结果的负责人。交付日期不仅仅是计算结束的日期：审阅和文件取回也必须在这之前安排妥当。
然后区分机器的可用时间和人员的可用时间。计算有时可以在夜间推进，但您的团队可能需要在首次启动或验证时到场。请写明这一约束，而不要把套餐的所有小时数都当作可互换的工作小时。日历是需经确认的内部约定，而非 Capordia 的供应承诺。
收集一份可用的估算及其来源
对于每项工作，记录预期输入、它们实际就绪的时间、同时使用的显卡数量、每张显卡的显存以及传输需求。补充一项从加载开始到释放为止的资源占用估算。把可以在该占用之前完成的准备任务分离出来：这样可以避免在等待行政审批期间一直占用显卡。
说明该估算是来自可比的试验、外推，还是单纯的假设。以往的耗时时长只有在数据、版本、设置和可用资源足够接近时才具有可比性。在没有实测记录的情况下，标记一个待验证的区间；不要显示精确到分钟的数字，以免让人误以为这是实测结果。当某项试验的结果会改变进度安排的选择时，预留一次小规模的验证试验。
从总工作量过渡到可执行的时间段
把预计的占用时长相加，以发现明显的超载，然后把每项工作放到时间轴上。一段不可分割的四小时处理无法塞进两个两小时的空档，除非中断和恢复已经过验证。即使还有一张空闲显卡，两项同时需要同一块磁盘或同一个人的工作也可能相互干扰。
Slurm 的文档说明了为什么时间段的填充取决于所请求的时长和资源：优先级较低的任务只要不推迟优先级较高任务的预定开始时间，就可以启动。这一逻辑有助于理解你的计划；它并不表示 Capordia 的任何方案中包含 Slurm。使用任何调度器都以其实际配置为前提，并需要由你的团队制定策略。
虚构示例：两个工作日内的三个项目
在这个练习中，虚构团队「Bureau des tracés」在两个工作日 J1 和 J2 的 9 时至 17 时只有一张可用显卡。任何处理都不共享该显卡，每次占用都包含加载、计算和导出。以下时长为教学假设：它们既不来自目录中的任何 GPU，也不来自任何基准测试。共同准备在 J1 开始时占用一小时。
Atlas 需要四小时，必须在 J2 13 时前提交。Balise 需要三小时；其输入在 J1 11 时到达，计划在 J1 18 时提交。Cadastre 需要五小时；它在 J2 9 时就绪，必须在 18 时前提交。需求为 4 + 3 + 5 = 12 小时。加上一小时的共同准备和三小时的留空，该计划用满了十六小时的开放时间。
| 时间段 | 预计占用 | 时长 | 条件 |
|---|---|---|---|
| J1，9 时–10 时 | 共同准备与检查 | 1 小时 | 输入与版本可用 |
| J1，10 时–14 时 | Atlas | 4 小时 | 工作在 10 时就绪 |
| J1，14 时–17 时 | Balise | 3 小时 | 输入在 11 时收到 |
| J2，9 时–14 时 | Cadastre | 5 小时 | 输入在 9 时收到 |
| J2，14 时–17 时 | 未分配的预留 | 3 小时 | 余量仅在 J2 可用 |
把余量放在它所需要吸收的风险之前
三小时的留空占十二小时工作量的 25%。然而这个百分比并不足以为 Balise 提供保障：它的余量出现在提交日的次日。如果 Atlas 用五小时而不是四小时，Balise 就无法在允许的时间窗内于 17 时前完成。该计划纸面上成立，但它的第一天依然脆弱。这种解读比单纯的均匀填充率更有用。
团队只有在约束允许时，才能把 Atlas 部分或全部移到另一个时间窗，或者争取一个额外的时间窗，或者缩减已接受的范围。第二张显卡是一个值得考察的选项，而不是自动得出的结论：它必须可用、兼容，并配备所需的主机资源。如果没有经过验证的解决方案，负责人应在启动前修改项目承诺，而不是把无法使用的预留美其名曰「余量」。
依据事先公布的规则来裁决冲突
在两位负责人争抢同一时段之前，先把仲裁规则准备好。一条简单的规则可以优先考虑已确认的外部截止时间，其次是输入已就绪的工作，最后是需求的提出时间。请明确谁可以破例，以及由哪个团队承担顺延。一项紧急任务必须对计划有明确的影响，而不能成为其提出者新的长期优先事项。
保留基准日程以及变更的原因：输入到达较晚、实际耗时更长或范围扩大。关于任务队列的指南处理的是下一次启动的决策；而日程保护的是多个项目的截止时间。将两者结合起来，就能解释为什么一张暂时空闲的显卡并不一定能用于长时间的额外处理。
检查计划，并用正确的偏差进行修订
按时间段逐一推演一整天。每次启动都必须具备可用的输入、访问权限、内存容量和负责人。在交付前检查最终传输和审阅时间。然后模拟最有可能发生的延迟，核实哪部分余量能够真正吸收它。如果仅一次偏差就会错过重要的截止时间，就把该计划表述为有条件的。
在一次实际执行之后，区分启动前的等待、显卡占用时间以及到结果被接受为止的时长。用这种拆分来修正下一次的估算。传输延迟本身并不足以成为使用更强大显卡的理由；被遗忘的人工准备工作也无法通过增加计算余量来弥补。跟踪应当有助于消除偏差的成因，而不是根据一个孤立的总额去寻找责任人。
将日程与套餐对应，同时不混淆单位
在此示例中，八小时的一天是一个组织时间窗口，而不是八小时的资费。Capordia 目录提供 3 天、7 天或 30 天的固定周期，以及按整批计算的价格。请分别核对租用时长、批次中的显卡数量和工作日程。额外增加一张显卡既不能省去准备工作，也不能省去人工校验。
有价值的交付物是一份已获批的日程，其中包含其假设、预留的余量以及出现偏差时的决策。它仍需结合实际提供的资源和一次有代表性的试运行来确认。不要将演练中的十六小时或其储备百分比变成有保障的期限或通用的容量规划规则。
决策要点
我可以将预计小时数除以 GPU 数量吗？
只有当工作可以并行推进且其他资源允许时才可以。不可分割的处理、依赖关系或复核环节都可能限制日程。在将总小时数换算为显卡数量之前，请先明确这些约束。
应预留多少余量？
余量取决于可能出现偏差的程度及其在日程中的位置。示例中的三小时是虚构的，并不能保障所有截止节点。请在你需要保障的交付节点之前预留缓冲，并用你的实际观察结果来证明其合理性。
排期是否取代机器验收？
不。它假定资源和应用程序均可用。接收方必须先验证这一假设，才能将时段视为可执行。若某项条件仍未知，则日程应保持临时状态并保留回退决策。