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.

Top comments (0)