Stable Horde

Distributes Stable Diffusion image generation requests across a decentralized network of volunteer GPU workers rather than centralizing computation on company-owned infrastructure. Workers register with the Horde, receive queued generation tasks, execute them locally, and return results through a coordinator service that handles load balancing, worker health tracking, and request routing based on worker availability and capability.

Allows GPU owners to register as workers in the Horde by running a local daemon that advertises hardware capabilities (VRAM, GPU type, supported models, max batch size) to the coordinator. The registration system maintains worker identity via API keys, tracks worker uptime/reliability metrics, and enables workers to specify which Stable Diffusion models they can serve (e.g., 1.5, 2.1, XL variants).

Provides a web dashboard displaying real-time worker status (online/offline, current load, uptime), performance metrics (average generation time, success rate), and earnings/rewards. Workers can view their own metrics and rankings, while administrators can monitor overall network health. The dashboard uses WebSocket or polling to update metrics in real-time.

Implements API key-based authentication where clients obtain keys from the Horde website and use them in request headers. The system enforces per-key rate limits (requests per minute/hour) and quota limits (total requests per billing period). Different key tiers (free, paid) have different limits, with optional quota upgrades. Rate limit headers are returned in API responses to inform clients of remaining quota.

Implements a coordinator service that maintains request queues, matches incoming generation requests to available workers based on model support and hardware capability, and handles backpressure when worker capacity is exhausted. The system uses a priority queue mechanism where requests are assigned to workers with matching model support, with fallback logic for workers running compatible model variants (e.g., routing to a 2.1 worker if 1.5 is unavailable).

Maintains a registry of Stable Diffusion model variants (1.5, 2.0, 2.1, XL, etc.) and implements fallback logic that routes requests to compatible workers when the exact requested model is unavailable. For example, a request for Stable Diffusion 1.5 can be served by a worker running 1.5-base or 1.5-pruned, and requests for unavailable models may be routed to the closest compatible variant with quality degradation warnings.

Tracks worker performance metrics (uptime, generation success rate, average generation time, user ratings) and uses this data to influence request routing and worker priority. Workers with higher reputation scores receive more requests, while unreliable workers are deprioritized. The system maintains a reputation ledger that persists across sessions and influences worker earnings/rewards.

Provides REST API endpoints for submitting generation requests and polling for results using long-polling or callback mechanisms. Clients submit a request with prompt/parameters, receive a request ID, and then poll a status endpoint until the generation completes. The API supports both synchronous (wait for result) and asynchronous (submit and check later) workflows, with optional webhook callbacks for result notification.

Exposes fine-grained control over Stable Diffusion generation parameters including sampler selection (Euler, DPM++, DDIM, etc.), guidance scale, number of steps, seed, image dimensions, and model-specific parameters. Clients can specify exact sampling algorithms and hyperparameters to control generation quality, speed, and reproducibility, with parameter validation to prevent invalid combinations.

Supports submitting multiple generation requests in a single API call with shared parameters (model, sampler, guidance scale) and varying prompts. The coordinator groups these requests and routes them to the same worker when possible to reduce overhead, with optional sequential or parallel execution modes. Clients receive a batch ID and can poll for individual result status or wait for all results.

Integrates optional post-processing steps (upscaling, face restoration, background removal) that can be chained after image generation. Clients can request upscaling via RealESRGAN or similar models, face restoration via GFPGAN, or other transformations as part of the generation workflow. These post-processing steps are executed by workers that support them, with fallback to generation-only if post-processing is unavailable.

Supports negative prompts (text describing what NOT to generate) and prompt weighting syntax that allows clients to specify relative importance of different prompt components. Clients can use syntax like '(important concept:1.5) (less important:0.8)' to control which parts of the prompt influence generation most strongly. The coordinator validates prompt syntax and passes it to workers that support weighted prompts.