From e9a833d82dd97f5ebd047d19f70da78d8c3755ce Mon Sep 17 00:00:00 2001 From: Hongsheng Liu Date: Sat, 8 Aug 2026 15:59:41 +0800 Subject: [PATCH] docs: simplify configuration resolution diagram Signed-off-by: Hongsheng Liu --- docs/design/architecture_overview.md | 39 ++++++++++------------------ 1 file changed, 13 insertions(+), 26 deletions(-) diff --git a/docs/design/architecture_overview.md b/docs/design/architecture_overview.md index 0efa45294..d3271107a 100644 --- a/docs/design/architecture_overview.md +++ b/docs/design/architecture_overview.md @@ -128,31 +128,18 @@ once into a complete, transport-safe configuration before runtime processes are started. This keeps stage topology and model capabilities distinct from deployment placement and from process-local engine objects. +The figure shows only the primary hand-off object for each layer; the detailed +inputs, fields, and ownership rules are described below. + ```mermaid flowchart TB - subgraph authoring["Layer 1: Authoring inputs"] - pipeline["PipelineConfig
frozen stage topology and execution types
model capabilities and stage relationships"] - deploy["DeployConfig
placement, replicas, devices, and environment
deploy-time defaults and connector definitions"] - overrides["CLI / Python overrides"] - metadata["HF or diffusion model metadata"] - legacy["Legacy YAML adapter
migration-only input; removed after model parity"] - end + layer1["Layer 1 · Authoring inputs
PipelineConfig + DeployConfig"] + layer2["Layer 2 · Resolve once
OmniConfigResolveRequest
resolve_omni_config()"] + layer3["Layer 3 · Transport-safe control plane
VllmOmniConfig"] + layer4["Layer 4 · Runtime launch planning
StageRuntime"] + layer5["Layer 5 · Engine materialization
VllmConfig / OmniDiffusionConfig"] - request["Layer 2: OmniConfigResolveRequest"] - resolve["resolve_omni_config()
selects exactly one source path
loads model metadata once
applies precedence and stage overrides once
resolves connectors, requests, runtime placement, and engine specs
validates the complete pipeline"] - resolved["Layer 3: Resolved and transport-safe control-plane config
VllmOmniConfig
pipeline_config: PipelineConfig
orchestrator_config: VllmOmniOrchestratorConfig
stage_configs: tuple[VllmOmniStageConfig, ...]
stage_pipeline_config · runtime_config · connector_config · request_config · engine_spec"] - launch["Layer 4: Runtime-only launch planning
StageRuntime
replica expansion · device allocation · local or remote launch
ReplicaInitPlan remains private runtime state"] - materialize["Layer 5: Owning-process materialization
materialize_engine_config(stage)"] - ar_config["VllmConfig
vLLM-backed engine"] - diffusion_config["enriched OmniDiffusionConfig
diffusion engine"] - - authoring --> request - request --> resolve - resolve --> resolved - resolved --> launch - launch --> materialize - materialize --> ar_config - materialize --> diffusion_config + layer1 --> layer2 --> layer3 --> layer4 --> layer5 ``` The resolver names in this diagram describe the intended single resolution @@ -166,10 +153,10 @@ migrated to `PipelineConfig` and `DeployConfig`. In the typed path, the common `VllmOmniStageConfig` slot in the diagram is realized by `VllmOmniARStageConfig`, `VllmOmniGenerationStageConfig`, or `VllmOmniDiffusionStageConfig`. The -diagram's request and engine-spec fields describe the control-plane boundary; -the current implementation stores their equivalent projections in the -structured stage configuration and materializes backend-specific engine -objects during stage initialization. +request and engine-spec fields belong to the control-plane boundary; the +current implementation stores their equivalent projections in the structured +stage configuration and materializes backend-specific engine objects during +stage initialization. The important ownership rules are: