Soulstone Engines

In plain words: Local model engines index

2 min read 7 glossary terms 17 connected pages
The short version written for the Snayu team

Index of supported inference engines for local services: vLLM, SGLang, llama.cpp, ExLlamaV3 via TabbyAPI, ComfyUI and audio.cpp, and which app or plug-in area owns each kind of output.

Why read it: Read this to choose an engine and find which domain owns its results (images, speech, music and so on).
  1. 1One local model service = engine + adapter + config file + Quadlet + resources.
  2. 2One engine can back several separate services with different models or GPUs.
  3. 3Being listed here does not mean the adapter is delivered; each engine page states its status.

Words on this page, decoded click one for its card

In this section 6 pages

vLLM Engine: vLLM How LychD runs vLLM as a local model server: you supply the full launch command, and a model is only marked ready when the live /models list contains its exact id. Includes a standalone probe for a first reply. open → SGLang Engine: SGLang Short page on running SGLang as a local model server through the generic OpenAI-compatible adapter, with the full launch command supplied in the config file. open → llama.cpp Engine: llama.cpp How LychD runs llama.cpp in single-model or router mode, with strict rules on launch arguments, model sources, context allocation, readiness and dynamic model loading. open → ExLlamaV3 through TabbyAPI Engine: ExLlamaV3 via TabbyAPI How LychD runs ExLlamaV3 through its TabbyAPI server as a dynamically loaded local model, using Tabby's lifecycle API to load models and verify the active one. open → ComfyUI Engine: ComfyUI Design for running ComfyUI as a local graph engine for image, video and audio work, where each admitted preset pins the exact graph, nodes, models and allowed parameters. open → audio.cpp Engine: audio.cpp Short candidate page for using audio.cpp as a local engine for music, source separation and speech, with output meaning owned by Voice (Echo), the music app or another owner. open →
The original text Underlined words open their plain-English card.

Choose an engine for the execution it can supply, then give it a local body through a SoulstoneLocal Model adapter, RuneService Config File, Quadlet, and declared resources. The upstream engine alone is neither the SoulstoneLocal Model instance nor a model or semantic extension.

engine + adapter + Rune + Quadlet + resources = one local Soulstone instance

The engine pages own runtime-specific launch shape, connector dialect, readiness and activation, resource placement, containment, and evidence. Choose an engine below for that adapter's requirements, then use the common Soulstone contract to bind its local instance, admit work through DispatcherTraffic Controller, and request OrchestratorStage Manager transitions. Each engine page states its delivery boundary; an entry in this map does not establish a delivered adapter.

Engine Primary shape Use
vLLM resident OpenAI-compatible model server Kinetic model serving
SGLang resident OpenAI-compatible model server Radix model serving
llama.cpp single-model server or in-process router Titan model serving and dynamic activation
ExLlamaV3 through TabbyAPI dynamically activated model service strict TabbyAPI-backed model serving
ComfyUI queued graph/workflow engine image, video, spatial, and exact audio-capable profiles
audio.cpp audio inference with an independently managed service or worker lifecycle bounded music, separation, and speech profiles

The same engine may manifest several SoulstonesLocal Models with different model sets, graphs, GPUs, conflict domains, and capability profiles. comfy-qwen, comfy-ltx, and comfy-music3, for example, may use one ComfyUI image while remaining separate managed service instances.

Qualify the particular work you intend to run on that engine. Model, graph, node set, quantization, license, and hardware placement belong to an exact capability profile. The selected adapter and owning extension or CompositionApp must admit them; an engine's name cannot establish these facts for every model or workflow it can load.

Engine versus technical contract and semantic owner

The engine performs a bounded execution. Choose the technical contract and consuming owner for each returned facet:

Returned facet Continue to
image, video, visual observation, spatial form, or structured motion Prism for the exact technical interface and Atelier or another named consuming CompositionApp for adoption
speech transcription, synthesis, cloning, or delivery Echo and the requesting owner
music, musical vocal, production effect, or musical cue map Riffmaw
timed-language dialogue, narration, or caption edition Language Edition, using its exact EchoVoice and Translation operations
picture-bound effect, foley, room tone, or ambience Broadcast
game-event, state, space, listener, or runtime sound Foundry
final audiovisual assembly Broadcast's pinned renderer and timeline

PrismVision & Media settles technical results, Core owns any ServiceJobAttempt@1, and each consuming owner independently admits its facet. For model-native video with sound, follow compound-facet admission before selecting the profile.

An engine that can emit more than one modality does not absorb those domains. The exact RuneService Config File and capability profile determine which operations may execute; each application facet still needs its own semantic admission receipt.