SEVA सेवा
Shared Execution via Voluntary Acceleration
Distributed NPU/GPU compute sharing across the mesh — selfless service for AI inference.
v3.0.0The Gift That Returns Tenfold
In the Himalayas, seva is selfless service — freely given, expecting nothing. A sherpa carries a stranger’s load. A village shares its harvest. In yakmesh, SEVA is the same principle applied to silicon: nodes with NPU or GPU capacity freely process inference requests for peers who lack acceleration. No payment, no debt — just capability shared across the mesh. The reputation system ensures good seva is remembered, and abusers are naturally excluded.
Overview
सेवा (seva) = selfless service. SEVA enables yakmesh nodes to share their NPU/GPU compute capacity with peers who lack hardware acceleration. A node with an AMD XDNA NPU or NVIDIA GPU can process inference requests on behalf of CPU-only peers.
The protocol is opt-in, rate-limited, reputation-gated, and limited to pre-defined model slots — no arbitrary code execution. Parameters are validated to contain only numeric values.
Security by Design
SEVA accepts numbers only as parameters and routes them to fixed model slots. There is no eval, no script injection, no dynamic code path. The worst a malicious request can do is waste a few milliseconds of inference time — which is rate-limited and reputation-gated.
Protocol Flow
- Opt-in — Node enables SEVA and broadcasts its capability advertisement (available slots, NPU/GPU type, current load).
- Broadcast — Capabilities are re-broadcast every 60 seconds with a 180-second TTL.
- Request — A peer needing compute calls
requestWork(slot, params). SEVA finds the best available provider and sends a directedseva:request. - Execute — The provider validates the request (numbers-only, valid slot),
runs inference, and returns the result via
seva:response. - Verify — With 5% probability, the requester re-runs the inference locally
and compares results (
seva:verify).
Message Types
| Type | Direction | Description |
|---|---|---|
seva:capability |
Broadcast | Available slots, hardware type, current load |
seva:request |
Peer → Provider | Model slot + numeric parameters |
seva:response |
Provider → Peer | Inference result |
seva:verify |
Peer → Provider | Spot-check verification request (5% probability) |
seva:verify:ack |
Provider → Peer | Verification acknowledgment |
Model Slots
SEVA only accepts requests for pre-defined model slots. Currently 5 slots are registered, all used by C2C (Core to Cosmos):
| Slot | Purpose |
|---|---|
planet-variation |
Generate planet variations from metadata (8-float parameter vector) |
planet-heightmap |
Generate terrain heightmaps for procedural planets |
planet-superres |
Super-resolution upscaling of planet textures |
faction-brain |
AI faction decision-making (scoring, actions, diplomacy) |
combat-predict |
Combat outcome prediction for battle resolution |
Peer Selection
When requesting work, SEVA scores available providers using a priority system:
Configuration
| Setting | Default | Description |
|---|---|---|
maxConcurrent |
10 | Max simultaneous jobs per peer |
rateLimit |
30/min/peer | Request rate limit per peer |
timeout |
5000 ms | Max time before request times out |
verifyProbability |
0.05 (5%) | Spot-check probability |
capabilityTTL |
180s | Capability advertisement expiry |
Version History
| Version | Changes |
|---|---|
| v3.0.0 | Full SEVA module: SevaMeshHandler, 5-slot registry, capability broadcast, peer selection, rate limiting, 5% spot-check verification, C2C integration. |