Soulstone Disciplines

In plain words: Local model runtime families

Operator validation 1 min read 4 glossary terms 9 connected pages
The short version written for the Snayu team

A short map of the built-in local model runtimes: vLLM (Kinetic), SGLang (Radix) and llama.cpp (Titan), plus how loading a model in a running server differs from restarting it.

Why read it: Read this to pick a runtime family and understand the lore nicknames used for each engine.
  1. 1vLLM and SGLang serve a pinned model via an OpenAI-compatible API.
  2. 2llama.cpp supports single-model and router modes with dynamic model loading.
  3. 3Dynamic loading is not a restart; the Stage Manager owns both, and callers never bypass it.

Operator validation Adapters tested in repo; real engine/GPU runs await proof.

Words on this page, decoded click one for its card

The original text Underlined words open their plain-English card.

Each runtime needs its own knowledge of how to start, declare capabilities, report readiness, and—where supported—activate a model inside the running service. A discipline is that adapter knowledge applied to a SoulstoneLocal Model RuneService Config File. Soulstone Engines indexes the detailed contracts. The short names and historical anchors below remain the vocabulary used by the Lexicon.

I. The Kinetic (vLLM)

The Kinetic serves a pinned model through an OpenAI-compatible surface. Continue to the vLLM engine contract for its exact live-inventory readiness rule, runtime defaults, and outstanding operator receipt. These are adapter-specific obligations.

II. The Radix (SGLang)

The SGLang engine page owns the detailed adapter contract. SGLang also presents an OpenAI-compatible service; LychD does not require its sgl.gen DSL. Its live runtime receipt remains operator validation.

III. The Titan (llama.cpp)

The llama.cpp engine page owns its single-model and router startup shapes, deterministic argument precedence, and dynamic activation contract.

Dynamic Activation Is Not Restart

The Orchestrator owns supported activation. A running router can load a model without a systemd transaction; reclaiming a conflicting physical runtime still uses the serialized target switch. Callers never invoke a runtime control API as a side route around the DispatcherTraffic Controller.

Repository tests cover llama.cpp planning, discovery, capability derivation, and model loading. Model unloading is not a separate adapter operation; OrchestratorStage Manager shuts down whole runtimes. A real engine/GPU/model result remains operator validation. ExLlamaV3 uses a separate dynamic contract described in ExLlamaV3 through TabbyAPI.