Skip to main content

awswarm

Sub-layer fragment placement for GPUs too small to hold one full transformer layer — plus the parts that decide whether a pool of them is worth trying at all.

Why

The most mature prior art in heterogeneous-GPU swarm inference (shard/c0mpute — see .RESEARCH/INTAKE/shard/DOSSIER.md in the AitherOS monorepo) explicitly rejects any node that can't hold at least one whole layer: "a node that can hold only ~2 layers forces a 62-layer model into ~31 stages... rejected for the ring." That's the right call for a whole-layer pipeline-parallel design. awswarm exists for the case just past that boundary: consumer GPUs, none able to hold a full layer alone, that can be split proportional to capacity so they jointly compute that layer's output.

The splitting math is proven here. A prior physical run of this shape exists but its data was not recovered, so nothing in this repo reproduces it — see docs/ROADMAP.md for gate-by-gate status.

How the modules fit together

Six pieces, each usable alone, in the order an orchestrator would call them:

from awswarm import (
    WorkerRegistry, assess, split_column_parallel, encode, decode,
    aggregate_results, require_physical,
)

# 1. Who is in the pool — and did they PROVE it?  A declared capacity is a claim.
reg = WorkerRegistry()
reg.register("volunteer-1", capacity=8, availability=0.6)   # UNVERIFIED
reg.verify_and_activate("volunteer-1", measured_capacity=8) # ACTIVE, or it never joins

# 2. Will enough of them be present AT ONCE?  Exact, not simulated.
report = assess(total_units=24, workers=reg.volunteer_workers())
if report.probability < 0.5:
    return report.summary()      # refuse before spending on an acquisition

# 3. Cut the layer to each worker's capacity.
fragments = split_column_parallel(weight, capacities)

# 4. Ship the activation traffic.  Corruption RAISES; it never decodes to garbage.
payload = encode(fragment_tensor, meta)
tensor, meta = decode(payload)

# 5. Did the worker compute the right thing?  Identity is not integrity.
vote = aggregate_results(replica_results, tolerance=1e-4)

# 6. Refuse to RECORD the run as real hardware unless it was.
require_physical(workers, controller_address)

A runnable version of exactly this is examples/end_to_end.py.

What's actually here

module answers
fragment how do I split a layer across workers too small to hold it?
acquire will this pool ever be present at once? — exact probability
protocol SWARMT01 envelope for the activation traffic, checksummed and chunked
integrity did the worker compute the right thing? — replica consensus
registry who is in the pool, and was their capacity measured or claimed?
physical is this really distributed hardware, or one box wearing hats?

Run the proof yourself — every number is measured on the run, never quoted:

pip install -e .[dev]
pytest -q -s          # 173 tests; prints measured deviations, not claimed ones

Two results worth knowing before you build on this:

  • Assembly probability is exact. It convolves the per-worker availability distribution rather than sampling it, and the tests check it against brute-force enumeration of all 2^N worlds — measured deviation 0.000e+00.
  • Capacity on paper is not capacity. Six 8-unit volunteers at 25% availability hold 48 units and assemble a 40-unit layer 0.46% of the time — 215 attempts on average. A capacity-only view calls that pool fine.

What's honestly NOT here

  • No orchestrator. Nothing here decides when to reassign work, retry an acquisition, or spend money. That caller is deliberately somebody else's — these are the primitives it would reuse, not a controller.
  • No GPU kernels, no model runtime. Correctness is shown on tensors, not against a real checkpoint (Kimi K3, Deepseek, or otherwise). Gates 1 and 3 in the roadmap are PARTIAL for exactly this reason.
  • No live pool data. Availability, churn and correlation-of-failures have never been measured on a real volunteer pool. Every probability assumes independence, which real pools violate — evening gaming, regional outages, a driver update. That makes every number here a ceiling, never a floor: useful for refusing a plan, not sufficient for promising one.
  • No network cost accounting. The protocol proves byte-fidelity; it does not measure transport latency or compare it against the compute gain.
  • No reproduction of any prior physical run. The hardware proof lives outside this repository.

Volunteer compute is closer in substrate, not in deployment readiness. This package is the reusable, honest foundation an orchestrator can stand on.

License

Apache-2.0. The SWARMT01 wire format is adapted from swarm-inference-lab (Apache-2.0, 2026) with attribution recorded in awswarm/protocol.py.

Metadata

Release files for awswarm 0.1.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 awswarm 0.1.0
File Size Uploaded Provenance
awswarm-0.1.0.tar.gz 59.7 kB Without provenance Details

Built distribution (wheel)

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

Total release size: 101.6 kB

Release files / awswarm-0.1.0.tar.gz

Download URL awswarm-0.1.0.tar.gz
Size 59.7 kB
Tags Source
SHA-256 checksum
How to use checksums
bdec6037f1a0cb1b8dc0da29a5a2e1f173d58b1a791e97c09e2c0f50683d0f46
BLAKE2b-256 checksum
How to use checksums
59f76161a98d5895385adc8e4deb3a454b0d01890886a6ff9709554da7c09c2c
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.12.3

Release files / awswarm-0.1.0-py3-none-any.whl

Download URL awswarm-0.1.0-py3-none-any.whl
Size 41.9 kB
Tags Python 3
SHA-256 checksum
How to use checksums
9745d1f343c6e086961af11672239128121fd8b76e1f1a6d4561bebd14c049a7
BLAKE2b-256 checksum
How to use checksums
e41bdca1e35f0ce818e184f379ff24d032ea2da50556cee4020d73542cce2204
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.12.3

Security for awswarm 0.1.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.

Release history Release notifications | RSS feed

This release

0.1.0 This release

2 release files No provenance

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