elasticgrid
Cross-cloud elastic training grid for variable-size workloads, built on iroh-tinker.
elasticgrid is the control plane in front of iroh-tinker's multi-cloud launch layer. It answers two questions:
- How big should this job be right now? A rolling window of training steps (step time, queue time, throughput) feeds a scheduler that grows the job when workers are waiting and shrinks it when the job is comfortably faster than the target, with bounds, a cooldown and a deadline rule.
- Where should the nodes run? A placement plan spreads the nodes over the
available providers, respects a spot/on-demand budget, costs the placement
and renders it as an iroh-tinker
LaunchSpec.
Nothing here provisions anything by itself: the placement is a plan, and
iroh-tinker's JobManager executes it.
The control plane (P3.x) adds a job store (SQLite), tenant API-key auth with
quota accounting, a supervised worker, spot-preemption with resume-from-
checkpoint, and an HTTP service (elasticgrid[serve]). The service runs on
TurboAPI when Python 3.14+ (Zig HTTP
core, ~14-20x faster than FastAPI) and falls back to FastAPI otherwise.
Install
pip install elasticgrid
pip install "elasticgrid[serve]" # HTTP service (TurboAPI on 3.14+, else FastAPI)
pip install -e ".[dev]" # from a checkout
elasticgrid depends on the public iroh-tinker surface only.
Built on the iroh-tinker public surface
| API | Used for |
|---|---|
iroh_tinker.cloud.spec.LaunchSpec / ResourcesSpec / RendezvousSpec |
the launch spec a placement renders into |
iroh_tinker.cloud.job.JobManager |
executing the plan |
iroh_tinker.hw.HardwareContext / infer_topology / select_topology_params |
topology hints for the placement |
iroh_tinker.AllreduceAlgorithm is not exported from the top-level
package; it lives in iroh_tinker.comm. elasticgrid does not depend on it.
CLI
elasticgrid providers # the configured grid
elasticgrid plan --nodes 64 # placement + cost
elasticgrid plan --nodes 64 --max-spot-fraction 0.5
elasticgrid spec --nodes 64 --name my-job # the iroh-tinker launch spec
elasticgrid simulate --samples steps.json # what the scheduler would do
Every command accepts --json.
The scale decision
The scheduler reads a window of step samples and applies the rules in order:
- Never scale on thin evidence. Fewer than
min_samplesobservations means hold. - Respect the bounds. The target is clamped to
[min_nodes, max_nodes]. - Honour the cooldown. After a change, wait
cooldown_s. Elastic scaling without a cooldown oscillates. - Queue-bound means scale up. If 20% or more of the step was spent waiting for a worker, the job needs more workers.
- Idle means scale down. If the step is well inside
target_step_sand nobody is waiting, the current size is more than enough. - Do not scale up past the deadline. Workers that cannot finish before the deadline cost money and save nothing.
Every decision carries the signals it was based on, so it can be replayed and reviewed:
{
"action": "scale_up",
"current_nodes": 8,
"target_nodes": 16,
"reason": "80% of the step was spent waiting for a worker; scaling up 8 -> 16",
"signals": {"queue_fraction": 0.8, "mean_step_s": 10.0, "...": "..."}
}
The placement
GridPlanner.plan(nodes) returns a placement: how many nodes each provider
takes, what it costs per hour, and the ordered infra references that
iroh-tinker fails over through.
The policy is explicit:
- providers are filled cheapest first;
max_spot_fractioncaps the share of nodes on spot capacity;- if the spot budget cannot hold the job, the remaining nodes are placed anyway, because a job that cannot start is worse than a job that breaks the policy;
- the placement is a pure function of (nodes, providers, policy), so the same plan always gives the same answer.
Tests
pip install -e ".[dev]"
pytest
The suite is credential-free: the planner and the scheduler are pure functions and are tested directly.
Layout
src/elasticgrid/
metrics.py step samples and the rolling window of signals
scheduler.py the scale decision (bounds, cooldown, deadline)
grid.py providers, placement, cost, launch spec
cli.py elasticgrid providers | plan | spec | simulate
Licence
Apache-2.0. elasticgrid is a separate project from iroh-tinker, which stays MIT OR Apache-2.0.
Metadata
Release files for elasticgrid 0.2.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| elasticgrid-0.2.0.tar.gz | 34.1 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| elasticgrid-0.2.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 64.8 kB
Release files / elasticgrid-0.2.0.tar.gz
| Download URL | elasticgrid-0.2.0.tar.gz |
|---|---|
| Size | 34.1 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
22b52c203545121e1e5d03e7f8188d04640099e7f736a6db13805e8d219a2f3f
|
|
BLAKE2b-256 checksum How to use checksums |
4b2f4ca47d7fbbbec4ec1a9fd9f4c70f5417604cf97da16b6b4b3aad911d48d2
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.14.4
|
Release files / elasticgrid-0.2.0-py3-none-any.whl
| Download URL | elasticgrid-0.2.0-py3-none-any.whl |
|---|---|
| Size | 30.7 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
cf5c16486079527382778be318d3c4b888b5ebe79d2912b94a7b8ea101949c13
|
|
BLAKE2b-256 checksum How to use checksums |
c5937e0eac9cda4a8281e5ab93c1ee0893007490b0cc208b723461bb7870573c
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.14.4
|
Security for elasticgrid 0.2.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.