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.1

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.1
File Size Uploaded Provenance
elasticgrid-0.2.1.tar.gz 34.5 kB Without provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for elasticgrid 0.2.1
File Interpreter ABI Platform
elasticgrid-0.2.1-py3-none-any.whl Python 3 none any Details

Total release size: 65.3 kB

Release files / elasticgrid-0.2.1.tar.gz

Download URL elasticgrid-0.2.1.tar.gz
Size 34.5 kB
Tags Source
SHA-256 checksum
How to use checksums
b09b7eb176cc8a817d83e488d271bd9c6d509275b9ecba1eb21e5274c13d9963
BLAKE2b-256 checksum
How to use checksums
a15e6fa5842f070664e73d0a5cbdd9d6d9889acd271bc2519f61bb2f559aa8d1
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.1-py3-none-any.whl

Download URL elasticgrid-0.2.1-py3-none-any.whl
Size 30.8 kB
Tags Python 3
SHA-256 checksum
How to use checksums
4c5f53637edcda6a0c5dfaf1db16ccbffc66190d9a72b97b2ba8e13d0d6070b9
BLAKE2b-256 checksum
How to use checksums
4da914366ce511157fcb494246a878f76b86be43950e54a3dc29cc2bc40829f9
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.1

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