DEV Community: J hin

EverSpark Forge V2 — Building a Distributed AI OS

J hin — Wed, 07 Oct 2026 15:28:08 +0000

EverSpark Forge V2 — Building a Distributed AI OS

EverSpark Forge V2 is now available.

This release marks a major architectural shift for the project.

EverSpark Forge is now a Distributed AI OS where Archon acts as the control layer, while different Forge modules can run on registered nodes across different machines, GPUs, and regions.

The core idea is simple:

AI capabilities should not be tied to one machine, one GPU, or one location.

Why I rebuilt the architecture

Early versions of EverSpark Forge were much more local.

That worked well enough for proving the basic idea, but it also created an obvious limitation: every capability depended too heavily on the machine it was running on.

That becomes a problem quickly when different AI workloads have very different hardware requirements.

Image generation may need one GPU.

Audio generation may need another environment.

LLM workloads may run somewhere else entirely.

So V2 moves away from treating the machine as the center of the system.

Instead, the system is built around distributed Forge modules.

The V2 architecture

At the center of the current architecture is Archon / Orchestrator.

Archon acts as the control layer.

Remote machines run as Pods and actively register with the main system through a Tailscale-based virtual network.

Once a node is registered, Forge modules can be deployed to that node.

A deployment can look like this:

Archon running on the main machine
Concept Forge running on one remote node
Image Forge running on another GPU node
Audio Forge running on a different machine or region

The important part is that these modules no longer need to live on the same physical system.

Remote node workflow

The current V2 node workflow includes:

Active remote node registration
Tailscale-based networking
Remote Forge deployment
Node health checks
Bandwidth testing
Region-aware node usage

Bandwidth testing is especially useful for remote GPU nodes.

A powerful GPU is not very useful if the network connection is too slow to make the node practical.

So EverSpark Forge can test the network performance of a Pod before using it as part of the distributed system.

Concept Forge

Concept Forge handles LLM interaction and task understanding.

It is designed to support different model backends and external APIs instead of depending on one provider.

Concept Forge is already part of EverSpark Forge V2's end-to-end automated orchestration workflow. It interprets natural-language requests, decomposes them into executable tasks, generates task lists, and helps determine which Forge modules are required before Archon / Orchestrator dispatches those tasks for execution.

Image Forge

Image Forge runs as an independent image-generation capability.

In V2, Image Forge can run on a remote node instead of being tied to the main machine.

Generated results can then be accessed directly from the remote node by the WebUI.

This avoids routing large image files back through the main control machine when that transfer is unnecessary.

Audio Forge

V2 also introduces Audio Forge.

The current implementation integrates VoxCPM2 and supports independent text-to-speech generation.

The current generation modes include:

Image only
Audio only
Image + audio

Like Image Forge, Audio Forge can run remotely and expose generated results directly from its node.

What is already working

The important milestone for V2 is not just that these components exist independently.

The distributed control and deployment loop is now working end to end.

That means the system can:

Connect remote nodes
Register them
Test them
Deploy Forge modules
Run AI workloads remotely
Access generated results through the wider system

This means EverSpark Forge V2 already supports end-to-end automated orchestration across distributed Forge modules, from natural-language request processing to task decomposition, Forge selection, dispatch, and execution.

What comes next

EverSpark Forge V2 already implements the full automated orchestration path:

Natural-language request → Concept Forge task decomposition → Task list generation → Automatic Forge selection → Archon / Orchestrator dispatch → Forge execution

With that foundation already in place, the next stage is not basic orchestration itself, but making the system more capable and more intelligent.

Future development will focus on:

More advanced planning
Better scheduling strategies
Fault tolerance
Stronger multi-Forge coordination
Broader capability expansion

In other words, V2 already delivers the distributed and automated orchestration foundation, while future work focuses on making that orchestration more powerful, flexible, and resilient.

Demo

I recorded a V2 demo showing the current distributed workflow, including remote deployment, Image Forge, and Audio Forge.

YouTube:

https://youtu.be/yhaUHmxdNIA?si=rtGutyw_0o5Po1IS

Source code

EverSpark Forge is open source.

GitHub:

https://github.com/jhinforge/EverSpark-Forge

The demo reflects the system at the time of recording.

For the latest functionality and implementation details, the repository is the source of truth.

The distributed loop is now running.

I am Jhin.

And Jhin has done this.

I built EverSpark Forge: a modular AI creation and orchestration system

J hin — Sat, 26 Sep 2026 14:20:23 +0000

EverSpark Forge is a modular AI creation and orchestration system.

I started building it because I was tired of repeatedly setting up the same AI environment whenever I switched machines, rented a new cloud GPU, or rebuilt a workspace.

At first, it was just a collection of deployment and automation scripts.

Over time, it gradually became a larger system for connecting AI models, workflows, execution backends, runtime environments, storage, and management tools behind one unified architecture.

What EverSpark Forge does

The main goal is to make different AI capabilities work together without tightly coupling the entire system to one model provider, one image backend, or one machine.

Current capabilities include:

a unified WebUI
local Ollama model backends
OpenAI-compatible model backends
ComfyUI image execution
Diffusers image execution
natural-language-to-image workflows
reusable character templates
model and backend switching
runtime and service management
cloud GPU deployment workflows
configuration workflows
storage, backup, and recovery tools

The system is still under active development, and new modules are being added continuously.

The orchestration idea

One of the most important parts of EverSpark Forge is the orchestration layer.

The Orchestrator is not supposed to know how every backend works internally.

It should not care whether a task is ultimately executed by Ollama, an OpenAI-compatible API, ComfyUI, Diffusers, or something else.

Its job is to decide what needs to happen and send standardized tasks to the appropriate module.

The backend-specific modules handle their own protocols, request formats, execution logic, and responses.

This means that if a provider changes its API, or if I want to add another execution backend, I should only need to modify or add the corresponding module instead of redesigning the whole system.

That separation is one of the core architectural ideas behind EverSpark Forge.

Modular by design

I want the major parts of the system to remain replaceable.

For example:

Concept Forge handles language-model-related tasks
Image Forge handles image-generation execution
Runtime handles service and environment state
Storage handles persistence, backup, and recovery
the Orchestrator connects these capabilities together

The exact implementation behind each module can change without requiring the rest of the system to understand every implementation detail.

EverSpark Forge is also self-hostable and open source, but I see those as properties of the system rather than its entire identity.

Demo

I recorded a full demo showing the core workflow, including deployment, WebUI usage, natural-language image generation, character templates, model switching, and configuration flows.

The project has continued evolving since the demo was recorded, so the video does not include every feature currently available.

For the latest functionality, the repository and documentation should be treated as the source of truth.

Demo:
[YouTube link]

GitHub:
[GitHub repository link]

Why I’m sharing it now

For a long time, I kept adding “just one more feature” before publishing it.

Eventually I realized that if I kept waiting for the system to feel completely finished, I might never actually release it.

So I’m publishing EverSpark Forge while it is still actively evolving.

I’d especially appreciate feedback on:

the overall system architecture
the orchestration layer
backend abstraction boundaries
deployment workflows
how replaceable the individual modules feel
what you would expect from a system like this

Thanks for taking a look.