Measure GPU startup to the first usable result

What does ready mean?

This method note presents an original synthetic example. Its event times are invented. It contains no new GPU measurements or provider comparison.

A worker can be reachable before CUDA is ready. A kernel can produce an output before that output passes validation. A validated output can exist before the caller can read its durable artifact. Each milestone answers a different question.

For kernel-data production, we propose measuring elapsed caller time from a funded, authenticated submission to the first independently accepted artifact that is durably readable. Preserve the earlier milestones as well: they help explain where time went.^[1]

This endpoint is a proposed end-to-end metric. It does not replace every platform's definition of cold start. A comparison needs to name which endpoint it measures.

Bind the endpoint to the output

The template records the planned attempt, declared coldness class, submission, worker readiness, first CUDA result, validation, and readable-artifact acknowledgment. The acceptance event and the read acknowledgment must refer to the same artifact digest.^[1][2]

A declaration that a machine is ready is insufficient to fill in the accepted-artifact timestamp. Missing validation stays missing. A failed attempt stays in the record. An output that becomes readable after the fixed deadline can be valid while still missing that deadline.^[2][3]

The example checks consistency between declared events. It does not authenticate the events, run a real validator, test storage durability, or establish that a GPU existed.^[2]

A worked example with fictional times

In the fresh-instance example, the worker is ready after 1 second, the first CUDA result appears after 2 seconds, and validation is declared at 7 seconds. The accepted artifact becomes readable at 12 seconds. It misses the predeclared 10-second deadline even though the earlier milestones looked fast. These are invented values, not observations from Nodus or another provider.^[3]

Another example has a readable object at 3 seconds but no validation. Follow-up ends at 5 seconds against a 10-second cutoff. The report keeps it unresolved; it cannot turn that object into an accepted result or declare an eventual failure.^[3]

A retained-state example has a 1.4–1.8-second accepted-read interval around a 1.5-second deadline. Its deadline outcome stays unknown. In a separate example, the caller measures an exact 3-second endpoint while the worker stage offsets remain unknown.^[3]

All seven fictional attempts remain in the downloadable output, including the explicit failure and timeout. The different coldness classes stay separate. Their invented numbers cannot establish that one start mode or provider is faster.^[3]

Keep the clocks attached

The caller's monotonic clock can measure submission to the caller's read acknowledgment within one clock instance. A worker's local timestamps can describe its own stages. Subtracting timestamps from unrelated clock instances does not establish elapsed time.^[1][2]

Where a trace declares a mapping into a shared time basis, keep its uncertainty. Report an interval when that is all the evidence supports. If the interval straddles the deadline, deadline success remains unknown. Without a usable mapping, retain the event and leave the cross-clock duration unknown.^[2][3]

Stage intervals can overlap. Adding them can double-count work, so the end-to-end duration comes from its own defined endpoints.

Show every planned attempt

The report starts with the complete planned-attempt list. It distinguishes accepted outputs, explicit failures, pending observations, and missing evidence. These categories are not interchangeable.^[3]

An observation that ends before the deadline cannot tell us whether an unfinished attempt will eventually succeed. A missing timestamp cannot be converted into zero seconds. Reporting only completed successes would remove the very attempts that matter when testing startup reliability.^[2][3]

The worked example reports individual fictional observations. It does not estimate a fleet percentile, a failure probability, or a cost per usable artifact.

Keep coldness and cost explicit

Record whether the attempt begins on a fresh instance, starts a fresh process on a warm host, or restores retained state. Declare cache, image, model, and compilation conditions. Group observations under those conditions before drawing conclusions.^[1]

For a real cost comparison, retain acquisition, execution, validation, transfer, storage, cleanup, and failed-attempt charges. A missing settled charge remains unknown. Snapshot preparation also belongs in the relevant accounting boundary when evaluating restore economics.

Our earlier controlled replacement case is a separate measured artifact about retaining state. It is not a measurement of the fictional cases in this note.^[5]

Use the template on your workload

Download the source, fictional fixtures, recorded output, and blank template. Choose an acceptance contract, observation cutoff, coldness classes, and clock relationship before collecting real attempts. Keep enough raw evidence to audit the exact endpoint you report.^[4][1]

The public example makes the measurement rule inspectable. A real Nodus evaluation still requires authenticated observations, unchanged correctness criteria, complete attempts, and settled costs before performance or economic claims.