Tightly coupled compute
- Training a frontier model
- Tensor-parallel serving over NVLink
- Interactive chat at the lowest possible latency
Keep doing that on GPUs. The swarm is what you put next to them.
Liskov AI
Every Acurast processor becomes an independent AI worker: a complete open-weight model, a task, a result. Point a batch, an evaluation, or a training loop at the swarm and let scale do the rest.
Early access We are building this with the first teams now.
01 — Built for scale-out
The most valuable AI work of the next few years is not one enormous forward pass. It is millions of independent ones: generate, evaluate, attempt, verify. That is work a swarm does better than a rack.
Keep doing that on GPUs. The swarm is what you put next to them.
Horizontal scale, cheap hardware, and a bill that reads in results.
02 — Workloads
Classify, extract, summarise, filter, rerank, and moderate across queues of any size. Spread the batch over as many replicas as it deserves and collect the results.
Throughput without a queueQuestion–answer pairs, reasoning traces, alternative solutions, adversarial and preference examples, generated wide and filtered by a verifier or a stronger judge.
Generate wide, filter hardRun benchmarks, grade outputs, and score candidates across millions of samples, each one independent, each one a number you can trust.
Millions of samples, one billEmbed whole corpora with a small open-weight encoder on every worker, and get vectors back keyed to the input that produced them.
Wide and cheapCoding, maths, data, and browser agents attempt tasks in isolated environments. Every attempt is a trajectory; a separate verifier scores it. Millions of them feed your training loop.
Experience generation for RLSplit a larger model across a handful of processors that measure close to each other on the network, so the swarm reaches models no single phone can hold.
Topology-aware, measured firstEach workload lands with a listed Marketplace offering, published example code, and a recorded run behind it. See the release sequence →
03 — Experience at scale
Reinforcement learning has two halves: expensive, synchronous weight updates and cheap, asynchronous experience generation. Liskov takes the second half and gives your training cluster a world of workers to learn from.
Backpropagation, optimiser steps, checkpoints.
Independent workers, each with the model, a task, an environment, and a budget.
Reward is computed where the worker has no say.
04 — Four ways in
Use the swarm the way your team already works: a Marketplace launch, a repository you own, or an endpoint your existing client already speaks.
Configure a model, a task source, and a result sink, then launch as many replicas as the batch needs. Pull-based, so your endpoints stay yours and no worker needs a door opened to it.
The worker, the client that submits tasks and collects results, and a walkthrough from a forked repository to a completed batch. Copy it, change the model, ship.
One Liskov URL in front of a replica fleet, usable from any client that already speaks the OpenAI API. Point your batch at it and the swarm does the rest.
Every paid result is checked before it is charged, so what you pay for is work that actually happened. Verification is part of the product, not a premium tier.
05 — Priced by result
The swarm does not compete on FLOPS. It competes on what a batch, an evaluation, or a verified trajectory actually costs you, with failures, retries, and verification already inside the number.
Commodity hardware, no idle capacity to amortise, and work that never waits on a neighbour. That is the cost curve we are building toward, and the one we will publish.
cost / million useful tokenscost / million evaluated samplescost / verified trajectorycost / passing coding taskcost / GPU-hournot the metric06 — Open by design
The swarm is built for the open-weight era: models you can distribute freely and data you are happy to run anywhere. That is where its scale is unbeatable, and we are clear about where it stops.
Openly licensed models, or your own where sharing them is fine. Published once, versioned by content address, cached on every worker that needs them.
Public datasets, synthetic tasks, open-source repositories, and any inputs you are comfortable running on an independent processor.
Fine-tunes and adapters whose weights are the product stay on infrastructure you control.
Personal and regulated data belongs on a path built for it. A worker on the swarm sees what it runs.
The full picture of what a workload exposes is in the trust and data boundaries →
Early access
We are onboarding the first teams now. Tell us the model, the task shape, and the volume, and we will build the first offerings around what you actually run.