Skip to main content

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:

  1. Never scale on thin evidence. Fewer than min_samples observations means hold.
  2. Respect the bounds. The target is clamped to [min_nodes, max_nodes].
  3. Honour the cooldown. After a change, wait cooldown_s. Elastic scaling without a cooldown oscillates.
  4. Queue-bound means scale up. If 20% or more of the step was spent waiting for a worker, the job needs more workers.
  5. Idle means scale down. If the step is well inside target_step_s and nobody is waiting, the current size is more than enough.
  6. 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_fraction caps 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)

Source distribution for elasticgrid 0.2.0
File Size Uploaded Provenance
elasticgrid-0.2.0.tar.gz 34.1 kB Without provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for elasticgrid 0.2.0
File Interpreter ABI Platform
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.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page