Compute Profiles
Benchmarking CPU, GPU, memory, I/O, data, and verification before launch.
Principle
“How much does it cost to run?” is a first-class product field.
Every launch configuration should expose resource measurements and estimated runway before a Launcher spends capital.
Working classes
| Class | Typical profile |
|---|---|
| C1 — Lightweight | browser/basic CPU, small state |
| C2 — Standard | server CPU, moderate state/data |
| C3 — Advanced | GPU, large state, or larger active dataset |
| C4 — Research/HPC | multi-GPU, distributed, or specialist infrastructure |
These are working workload labels, not protocol prices. Cost estimates must come from a reproducible benchmark for the exact Blueprint, configuration, provider, region, and verification policy. Spawn should not publish universal dollar ranges that imply false precision.
Current evidence gap
Spawn has not yet published a canonical reference benchmark. The first benchmark release should attach a named Blueprint and configuration to a reproducible command and report, for example, the measured cost of 10,000 deterministic simulation runs on disclosed hardware. Until then, no dollar figure should be treated as a platform price or performance claim.
What actually drives cost
dataset size ≠ compute cost.
A 5 TB historical archive may be inexpensive to store but cheap or expensive to simulate depending on how much of it is accessed, transformed, and computed per tick. Runtime should measure CPU-seconds, GPU-seconds, peak RAM, I/O, bandwidth, checkpointing, and verification overhead.
Required launch display
- Compute class.
- Reference benchmark hardware.
- p50/p95/p99 tick time.
- Estimated cost/tick.
- Initial funded ticks.
- Estimated calendar runway under configured cadence.
- Data storage footprint and estimated recurring cost.
- Verification multiplier/cost.
- Minimum required runtime battery.
- Break-even activity if fees replenish runtime.