CapordiaDefine what the schedule must protect
Start with the decision that can no longer wait: a results review, a handoff to another team, or the end of the rental period. For each project, name the person authorized to accept its result. A delivery date is not simply a computation end date: review and file retrieval must already have their place in it.
Then distinguish machine availability from people availability. A computation can sometimes run overnight, but your team may require someone present for a first launch or a validation. Write down this constraint instead of counting all the plan's hours as interchangeable working hours. The schedule is an internal convention to be confirmed, not a supply commitment from Capordia.
Collect a usable estimate, along with its source
For each job, note the expected inputs, the time they will actually be ready, the number of simultaneous cards, the memory per card and the transfer requirements. Add an estimate of resource occupancy from the start of loading until its release. Separate the preparation tasks that can be done before that occupancy: this avoids reserving a card during an administrative wait.
State whether the estimate comes from a comparable trial, an extrapolation or a simple assumption. An old duration is only comparable if the data, versions, settings and useful resources are sufficiently close. In the absence of a record, mark a range to be validated; do not display a precision to the minute that would suggest a measurement. Reserve a small qualification trial when its result changes the choice of schedule.
Going from total volume to feasible slots
Add up the planned occupancies to spot an obvious overload, then place each job on a timeline. An indivisible four-hour process does not fit into two two-hour gaps, unless an interruption and restart have been validated. Two jobs that simultaneously require the same disk or the same person can also get in each other's way even when a card is still available.
Slurm documentation shows why slot filling depends on the durations and resources requested: a lower-priority job can start if it does not delay the scheduled start of a higher-priority job. This logic helps you read your plan; it does not announce the presence of Slurm in a Capordia offering. Any use of a scheduler assumes its actual configuration and a policy decided by your team.
Fictional example: three projects across two days
The fictional team "Bureau des tracés" has, for this exercise, a single usable GPU from 9 a.m. to 5 p.m. over two days, D1 and D2. No processing shares the GPU, and each occupation includes loading, computation and export. The following durations are teaching assumptions: they come neither from a GPU in the catalog nor from a benchmark. The common preparation takes one hour at the start of D1.
Atlas requires four hours and must be delivered before D2 at 1 p.m. Balise requires three hours; its inputs arrive on D1 at 11 a.m. and its delivery is scheduled for D1 at 6 p.m. Cadastre requires five hours; it becomes ready on D2 at 9 a.m. and must be delivered before 6 p.m. The total need is 4 + 3 + 5 = 12 hours. With one common hour and three hours left free, the plan uses the sixteen open hours.
| Slot | Planned occupancy | Duration | Condition |
|---|---|---|---|
| D1, 9 a.m.–10 a.m. | Common preparation and checks | 1 h | Inputs and versions available |
| D1, 10 a.m.–2 p.m. | Atlas | 4 h | Job ready at 10 a.m. |
| D1, 2 p.m.–5 p.m. | Balise | 3 h | Inputs received at 11 a.m. |
| D2, 9 a.m.–2 p.m. | Cadastre | 5 h | Inputs received at 9 a.m. |
| D2, 2 p.m.–5 p.m. | Unallocated reserve | 3 h | Margin available only on D2 |
Place the margin before the risk it must absorb
The three free hours represent 25% of the twelve hours of work. That percentage is not enough, however, to secure Balise: its margin lies on the day after its delivery. If Atlas takes five hours instead of four, Balise cannot finish before 5 p.m. within the allowed window. The plan holds on paper, but its first day remains fragile. This reading is more useful than a simple average utilization rate.
The team can then move Atlas in part or in full to another window only if its constraints allow it, obtain an additional window or reduce an accepted scope. A second card is an option to examine, not the automatic conclusion: it must be available, compatible and accompanied by the necessary host resources. Without a validated solution, the manager changes the project commitment before launch, rather than labeling an unusable reserve as "margin".
Arbitrating a conflict with a stated rule
Prepare the arbitration before two owners claim the same slot. A simple rule can prioritize a confirmed external deadline first, then work whose inputs are ready, then how long the request has been waiting. Specify who can make exceptions to this rule and which team will absorb the shift. An emergency must have an explicit consequence for the plan, and not become a new permanent priority for the person requesting it.
Keep the reference schedule and the reason for the changes: input arrived late, observed duration was longer, or scope increased. The guide on the work queue handles the decision of what to launch next; the schedule, in turn, protects the deadlines of several projects. Their interplay helps explain why a momentarily free card is not necessarily available for a long additional job.
Check the plan and revise it with the right variances
Review a day by moving from slot to slot. Each start must have its inputs, its access, its memory capacity and its owner available. Check the final transfer and the review time before delivery. Then simulate the most plausible delay and verify which margin actually absorbs it. If a single deviation causes a key deadline to be missed, present the plan as conditional.
After an actual run, separate waiting before start, card occupancy and time to the accepted result. Correct the next estimate using this breakdown. A transfer delay alone does not justify a more powerful card; forgotten manual preparation is not fixed by increasing the compute margin. Tracking should help eliminate the cause of the variance, not look for someone to blame based on an isolated total.
Link the schedule to the package without confusing units
An eight-hour day in this example is an organizational window, not an eight-hour rate. The Capordia catalog offers fixed periods of 3, 7 or 30 days and prices per full package. Check the rental duration, the number of cards in the package and the work schedule separately. An additional card eliminates neither preparation nor human validation.
The useful deliverable is an approved schedule with its assumptions, its placed margins and its decisions in case of variance. It still needs to be confirmed with the resources actually provided and a representative trial. Do not turn either the sixteen hours of the exercise or its reserve percentage into a guaranteed lead time or a universal sizing rule.
Questions to decide
Can I divide the planned hours by the number of GPUs?
Only if the tasks can proceed in parallel and if the other resources allow it. An indivisible process, a dependency or a review step can limit the schedule. Surface these constraints before converting total hours into a number of cards.
How much margin should be reserved?
The margin depends on the plausible variances and where they fall in the schedule. The three hours in the example are fictional and do not protect every deadline. Place a reserve before the delivery it must safeguard, then justify it with your observations.
Does the schedule replace the machine acceptance?
No. It assumes resources and an application that are usable. Acceptance must verify this assumption before the slots can be considered workable. If a condition remains unknown, the schedule must keep a provisional status and a fallback decision.