[Diffusion] Register runtime cache for direct DLO H2D

Avoid recurrent mmap-to-pinned packing in no-AllGather DLO by registering transform-complete runtime-cache mappings under an explicit per-worker budget. Copy mapped tensors directly into the rotating device buffers while preserving bounded-staging fallback and ordered shutdown cleanup. Signed-off-by: Hongsheng Liu <liuhongsheng4@huawei.com>
[Diffusion] Document runtime cache hardware tradeoffs
2026-08-17 11:50:32 +08:00 · 2026-08-17 00:43:06 +08:00 · 2026-08-16 23:26:25 +08:00 · 2026-08-16 23:15:48 +08:00
1001 changed files with 33409 additions and 85469 deletions
@@ -17,7 +17,7 @@ steps:
        - export VLLM_ROCM_USE_AITER=0
        # ignore test_teacache_extractors.py because it use rocm gemm kernel from vLLM
        # that is not supported on CPU
-        - "pytest -sv tests/model_executor -m 'core_model and cpu' --num-shards=$$BUILDKITE_PARALLEL_JOB_COUNT --shard-id=$$BUILDKITE_PARALLEL_JOB"
+        - "pytest -sv tests/model_executor -m 'core_model and cpu' --num-shards=$$BUILDKITE_PARALLEL_JOB_COUNT --shard-id=$$BUILDKITE_PARALLEL_JOB --cov=vllm_omni --cov-report=term-missing:skip-covered --cov-report=xml:coverage-model-executor-$$BUILDKITE_PARALLEL_JOB.xml"

    - label: "Simple · Diffusion Test · Shard %N/%t"
      agent_pool: mi300_1
@@ -29,7 +29,7 @@ steps:
        - export VLLM_ROCM_USE_AITER=0
        # ignore test_teacache_extractors.py because it use rocm gemm kernel from vLLM
        # that is not supported on CPU
-        - "pytest -sv tests/diffusion -m 'core_model and cpu' --ignore=tests/diffusion/cache/test_teacache_extractors.py --num-shards=$$BUILDKITE_PARALLEL_JOB_COUNT --shard-id=$$BUILDKITE_PARALLEL_JOB"
+        - "pytest -sv tests/diffusion -m 'core_model and cpu' --ignore=tests/diffusion/cache/test_teacache_extractors.py --num-shards=$$BUILDKITE_PARALLEL_JOB_COUNT --shard-id=$$BUILDKITE_PARALLEL_JOB --cov=vllm_omni --cov-report=term-missing:skip-covered --cov-report=xml:coverage-diffusion-$$BUILDKITE_PARALLEL_JOB.xml"

    - label: "Simple · Engine&Entrypoints Test"
      agent_pool: mi300_1
@@ -38,7 +38,7 @@ steps:
      grade: Blocking
      commands:
        - export VLLM_ROCM_USE_AITER=0
-        - "pytest -sv tests/entrypoints tests/engine -m 'core_model and cpu'"
+        - "pytest -sv tests/entrypoints tests/engine -m 'core_model and cpu' --cov=vllm_omni --cov-report=term-missing:skip-covered --cov-report=xml"

    - label: "Simple · Other Test"
      agent_pool: mi300_1
@@ -49,7 +49,7 @@ steps:
        - export VLLM_ROCM_USE_AITER=0
        # ignore test_teacache_extractors.py because it use rocm gemm kernel from vLLM
        # that is not supported on CPU
-        - "pytest -sv tests/ -m 'core_model and cpu' --ignore=tests/diffusion --ignore=tests/model_executor --ignore=tests/entrypoints --ignore=tests/engine  --ignore=tests/diffusion/cache/test_teacache_extractors.py"
+        - "pytest -sv tests/ -m 'core_model and cpu' --ignore=tests/diffusion --ignore=tests/model_executor --ignore=tests/entrypoints --ignore=tests/engine  --ignore=tests/diffusion/cache/test_teacache_extractors.py --cov=vllm_omni --cov-report=term-missing:skip-covered --cov-report=xml"

 - group: ":card_index_dividers: Diffusion Test"
  steps:
@@ -17,7 +17,7 @@ steps:
        - export VLLM_ROCM_USE_AITER=0
        # ignore test_teacache_extractors.py because it use rocm gemm kernel from vLLM
        # that is not supported on CPU
-        - "pytest -sv tests/model_executor -m 'core_model and cpu' --num-shards=$$BUILDKITE_PARALLEL_JOB_COUNT --shard-id=$$BUILDKITE_PARALLEL_JOB"
+        - "pytest -sv tests/model_executor -m 'core_model and cpu' --num-shards=$$BUILDKITE_PARALLEL_JOB_COUNT --shard-id=$$BUILDKITE_PARALLEL_JOB --cov=vllm_omni --cov-report=term-missing:skip-covered --cov-report=xml:coverage-model-executor-$$BUILDKITE_PARALLEL_JOB.xml"

    - label: "Simple · Diffusion Test"
      agent_pool: mi300_1
@@ -28,7 +28,7 @@ steps:
        - export VLLM_ROCM_USE_AITER=0
        # ignore test_teacache_extractors.py because it use rocm gemm kernel from vLLM
        # that is not supported on CPU
-        - "pytest -sv tests/diffusion -m 'core_model and cpu'  --ignore=tests/diffusion/cache/test_teacache_extractors.py"
+        - "pytest -sv tests/diffusion -m 'core_model and cpu'  --ignore=tests/diffusion/cache/test_teacache_extractors.py --cov=vllm_omni --cov-report=term-missing:skip-covered --cov-report=xml"

    - label: "Simple · Engine&Entrypoints Test"
      agent_pool: mi300_1
@@ -37,7 +37,7 @@ steps:
      grade: Blocking
      commands:
        - export VLLM_ROCM_USE_AITER=0
-        - "pytest -sv tests/entrypoints tests/engine -m 'core_model and cpu'"
+        - "pytest -sv tests/entrypoints tests/engine -m 'core_model and cpu' --cov=vllm_omni --cov-report=term-missing:skip-covered --cov-report=xml"

    - label: "Simple · Other Test"
      agent_pool: mi300_1
@@ -48,7 +48,7 @@ steps:
        - export VLLM_ROCM_USE_AITER=0
        # ignore test_teacache_extractors.py because it use rocm gemm kernel from vLLM
        # that is not supported on CPU
-        - "pytest -sv tests/ -m 'core_model and cpu' --ignore=tests/diffusion --ignore=tests/model_executor --ignore=tests/entrypoints --ignore=tests/engine  --ignore=tests/diffusion/cache/test_teacache_extractors.py"
+        - "pytest -sv tests/ -m 'core_model and cpu' --ignore=tests/diffusion --ignore=tests/model_executor --ignore=tests/entrypoints --ignore=tests/engine  --ignore=tests/diffusion/cache/test_teacache_extractors.py --cov=vllm_omni --cov-report=term-missing:skip-covered --cov-report=xml"

 - label: "Custom Pipeline Test"
  agent_pool: mi300_1
@@ -16,11 +16,6 @@
 # At least one of --offline/--online is required, so a job with only one mode runs
 # just that half. Total runtime is bounded by the step's timeout_in_minutes.
 #
-# Coverage + artifact upload run only on scheduled weekly E2E sweeps
-# (WEEKLY=1 and BUILDKITE_BRANCH=main — same gate as bootstrap --e2e).
-# All other invocations (PR merge-test, regular main merge, local) run the
-# same combined pytest as the job used before coverage was added.
-#
 # Exits non-zero if any half or the upload failed.
 set -uo pipefail

@@ -49,17 +44,6 @@ if ((${#OFFLINE[@]} == 0 && ${#ONLINE[@]} == 0)); then
    exit 2
 fi

-_should_run_coverage() {
-    [[ "${WEEKLY:-}" == "1" && "${BUILDKITE_BRANCH:-}" == "main" ]]
-}
-
-if ! _should_run_coverage; then
-    PATHS=("${OFFLINE[@]}" "${ONLINE[@]}")
-    echo "--- pytest (no coverage): ${MODEL_ID}"
-    pytest -s -v "${PATHS[@]}" "${PYTEST_ARGS[@]}"
-    exit $?
-fi
-
 # Two steps can test the same model, and artifacts are scoped to the build (a
 # nightly one carries the ready, merge and nightly tiers at once), so unsuffixed
 # reports would share a path -- a glob download then races to rename onto one file.
@@ -1,6 +1,5 @@
 #!/usr/bin/env python3
 # SPDX-License-Identifier: Apache-2.0
-# SPDX-FileCopyrightText: Copyright contributors to the vLLM-Omni project
 """Render and optionally upload Buildkite pipeline YAML with diff-aware logic.

 Bootstrap mode (``bootstrap-upload-steps.yml``):
@@ -59,12 +58,11 @@ BOOTSTRAP_UPLOAD_IF_KEYS = {
 E2E_GROUP_MARKER = "E2E Test"
 CI_MIRROR_HARDWARES_PATH = ROOT / ".buildkite/common/ci_mirror_hardwares.yml"

-# Bootstrap Buildkite ``if`` expressions.
-# ``*_MAIN_IF``: main + env schedule. ``*_LABEL_IF``: PR label (and/or composed with MAIN).
-# ``*_UPLOAD_IF``: full gate for uploading that child pipeline.
-NIGHTLY_MAIN_IF = 'build.branch == "main" && build.env("NIGHTLY") == "1"'
-NIGHTLY_LABEL_IF = (
-    f"({NIGHTLY_MAIN_IF}) || "
+CUDA_NIGHTLY_ONLY = (
+    '(build.pull_request.labels includes "nightly-test") || (build.branch == "main" && build.env("NIGHTLY") == "1")'
+)
+NPU_NIGHTLY_ONLY = (
+    '(build.branch == "main" && build.env("NIGHTLY") == "1") || '
    '(build.branch != "main" && ('
    'build.pull_request.labels includes "nightly-test" || '
    'build.pull_request.labels includes "omni-test" || '
@@ -73,19 +71,6 @@ NIGHTLY_LABEL_IF = (
    'build.pull_request.labels includes "diffusion-x2v-test"'
    "))"
 )
-WEEKLY_E2E_IF = 'build.branch == "main" && build.env("WEEKLY") == "1"'
-WEEKLY_MAIN_IF = 'build.branch == "main" && (build.env("WEEKLY") == "1" || build.env("NON_CRITICAL") == "1")'
-WEEKLY_LABEL_IF = f'({WEEKLY_MAIN_IF}) || (build.branch != "main" && build.pull_request.labels includes "weekly-test")'
-READY_LABEL_IF = 'build.branch != "main" && build.pull_request.labels includes "ready"'
-MERGE_LABEL_IF = 'build.branch != "main" && build.pull_request.labels includes "merge-test"'
-MERGE_MAIN_IF = (
-    'build.branch == "main" && build.env("NIGHTLY") != "1" && '
-    'build.env("WEEKLY") != "1" && build.env("NON_CRITICAL") != "1"'
-)
-READY_UPLOAD_IF = f"({WEEKLY_E2E_IF}) || ({READY_LABEL_IF})"
-MERGE_UPLOAD_IF = f"({WEEKLY_E2E_IF}) || (({MERGE_MAIN_IF}) || ({MERGE_LABEL_IF}))"
-BOOTSTRAP_DISABLED_IF = "false"
-BOOTSTRAP_ENABLED_IF = "true"


 # --- Logging ---
@@ -117,47 +102,74 @@ def _format_bootstrap_if(expr: str) -> str:


 def _compute_bootstrap_if_exprs(*, decision, platform: str) -> dict[str, str]:
+    disabled = "false"
+    nightly_main = 'build.branch == "main" && build.env("NIGHTLY") == "1"'
+    nightly_only = NPU_NIGHTLY_ONLY if platform == "npu" else CUDA_NIGHTLY_ONLY
+
    if platform == "npu":
-        ready_upload = READY_LABEL_IF
-        merge_upload = BOOTSTRAP_DISABLED_IF
-        weekly_label_if = BOOTSTRAP_DISABLED_IF
+        ready_pr = (
+            'build.branch != "main" && ('
+            'build.pull_request.labels includes "npu-test" || '
+            'build.pull_request.labels includes "ready"'
+            ")"
+        )
+        nightly_label_if = nightly_only
+        weekly_label_if = disabled
+        merge_base = disabled
    else:
-        ready_upload = READY_UPLOAD_IF
-        merge_upload = MERGE_UPLOAD_IF
-        weekly_label_if = WEEKLY_LABEL_IF
+        ready_pr = 'build.branch != "main" && build.pull_request.labels includes "ready"'
+        merge_main = 'build.branch == "main" && build.env("NIGHTLY") != "1" && build.env("WEEKLY") != "1"'
+        merge_pr = 'build.branch != "main" && build.pull_request.labels includes "merge-test"'
+        nightly_label_if = (
+            '(build.branch == "main" && build.env("NIGHTLY") == "1") || '
+            '(build.branch != "main" && ('
+            'build.pull_request.labels includes "nightly-test" || '
+            'build.pull_request.labels includes "omni-test" || '
+            'build.pull_request.labels includes "tts-test" || '
+            'build.pull_request.labels includes "diffusion-x2iat-test" || '
+            'build.pull_request.labels includes "diffusion-x2v-test"'
+            "))"
+        )
+        weekly_label_if = (
+            '(build.branch == "main" && build.env("WEEKLY") == "1") || '
+            '(build.branch != "main" && build.pull_request.labels includes "weekly-test")'
+        )
+        merge_base = f"({nightly_main}) || (({merge_main}) || ({merge_pr}))"
+
+    ready_base = f"({nightly_main}) || ({ready_pr})"
+    weekly_main = 'build.branch == "main" && build.env("WEEKLY") == "1"'

    if decision.skip_all:
        # Docs / skip-mark only: no PR-label escape hatch. Main scheduled
-        # NIGHTLY=1 still runs L4; WEEKLY=1 / NON_CRITICAL=1 still run L5.
-        # main+WEEKLY=1 also uploads L2/L3 (those steps then pass --e2e).
-        image_expr = f"({NIGHTLY_MAIN_IF}) || ({WEEKLY_MAIN_IF})" if platform == "cuda" else NIGHTLY_MAIN_IF
-        ready_expr = WEEKLY_E2E_IF if platform == "cuda" else BOOTSTRAP_DISABLED_IF
-        merge_expr = WEEKLY_E2E_IF if platform == "cuda" else BOOTSTRAP_DISABLED_IF
-        nightly_expr = NIGHTLY_MAIN_IF
-        weekly_expr = WEEKLY_MAIN_IF if platform == "cuda" else BOOTSTRAP_DISABLED_IF
+        # NIGHTLY=1 still runs L4 + L2/L3 (--e2e); WEEKLY=1 still runs L5.
+        image_expr = f"({nightly_main}) || ({weekly_main})" if platform == "cuda" else nightly_main
+        ready_expr = nightly_main
+        merge_expr = nightly_main if platform == "cuda" else disabled
+        nightly_expr = nightly_main
+        weekly_expr = weekly_main if platform == "cuda" else disabled
    elif decision.skip_l2_l3:
        l2_enabled = decision.is_run("npu", "l2") if platform == "npu" else decision.is_run("cuda", "l2")
        l3_enabled = platform == "cuda" and decision.is_run("cuda", "l3")

-        ready_expr = ready_upload if l2_enabled else BOOTSTRAP_DISABLED_IF
-        merge_expr = merge_upload if l3_enabled else BOOTSTRAP_DISABLED_IF
-        nightly_expr = NIGHTLY_LABEL_IF
-        weekly_expr = weekly_label_if if platform == "cuda" else BOOTSTRAP_DISABLED_IF
+        ready_expr = ready_base if l2_enabled else disabled
+        merge_expr = merge_base if l3_enabled else disabled
+        nightly_expr = nightly_label_if
+        weekly_expr = weekly_label_if if platform == "cuda" else disabled

-        image_parts = [f"({NIGHTLY_LABEL_IF})"]
+        image_parts = [f"({nightly_label_if})"]
        if platform == "cuda":
            image_parts.append(f"({weekly_label_if})")
        if l2_enabled:
-            image_parts.insert(0, f"({ready_upload})")
+            image_parts.insert(0, f"({ready_base})")
        if l3_enabled:
-            image_parts.insert(1 if l2_enabled else 0, f"({merge_upload})")
+            image_parts.insert(1 if l2_enabled else 0, f"({merge_base})")
        image_expr = " || ".join(image_parts)
    else:
-        image_expr = BOOTSTRAP_ENABLED_IF
-        ready_expr = ready_upload
-        merge_expr = merge_upload if platform == "cuda" else BOOTSTRAP_DISABLED_IF
-        nightly_expr = NIGHTLY_LABEL_IF
-        weekly_expr = weekly_label_if if platform == "cuda" else BOOTSTRAP_DISABLED_IF
+        image_expr = "true"
+        ready_expr = ready_base
+        merge_expr = merge_base if platform == "cuda" else disabled
+        nightly_expr = nightly_label_if
+        weekly_expr = weekly_label_if if platform == "cuda" else disabled

    return {
        "image": _format_bootstrap_if(image_expr),
@@ -8,28 +8,28 @@ steps:
    agents:
      queue: "cpu_queue_premerge"

-  # L2 Test — PR ready label (diff-aware) or main+WEEKLY=1 (--e2e, full E2E group)
+  # L2 Test — PR ready label (diff-aware) or main+NIGHTLY=1 (--e2e, full E2E group)
  - label: "Upload Ready Pipeline"
    depends_on: image-build
    key: upload-ready-pipeline
    commands:
      - |
        EXTRA=""
-        if [ "${WEEKLY:-}" = "1" ] && [ "${BUILDKITE_BRANCH}" = "main" ]; then
+        if [ "${NIGHTLY:-}" = "1" ] && [ "${BUILDKITE_BRANCH}" = "main" ]; then
          EXTRA="--e2e"
        fi
        python3 .buildkite/common/scripts/upload_pipeline.py --upload $$EXTRA .buildkite/cuda/test-ready.yml
    agents:
      queue: "cpu_queue_premerge"

-  # L3 Test — PR merge-test label (diff-aware) or main+WEEKLY=1 (--e2e, full E2E group)
+  # L3 Test — PR merge-test label (diff-aware) or main+NIGHTLY=1 (--e2e, full E2E group)
  - label: "Upload Merge Pipeline"
    depends_on: image-build
    key: upload-merge-pipeline
    commands:
      - |
        EXTRA=""
-        if [ "${WEEKLY:-}" = "1" ] && [ "${BUILDKITE_BRANCH}" = "main" ]; then
+        if [ "${NIGHTLY:-}" = "1" ] && [ "${BUILDKITE_BRANCH}" = "main" ]; then
          EXTRA="--e2e"
        fi
        python3 .buildkite/common/scripts/upload_pipeline.py --upload $$EXTRA .buildkite/cuda/test-merge.yml
@@ -45,7 +45,7 @@ steps:
    agents:
      queue: "cpu_queue_premerge"

-  # L5 Test — main+WEEKLY=1 / NON_CRITICAL=1 (scheduled), or PR with weekly-test label
+  # L5 Test — main+WEEKLY=1 (scheduled), or PR with weekly-test label
  - label: "Upload Weekly Pipeline"
    depends_on: image-build
    key: upload-weekly-pipeline
@@ -9,27 +9,23 @@ steps:
    depends_on: upload-merge-pipeline
    steps:
      - label: "Simple · Model Executor Test"
-        timeout_in_minutes: 20
        commands:
-          - "pytest -sv tests/model_executor -m 'core_model and cpu'"
+          - "timeout 20m pytest -sv tests/model_executor -m 'core_model and cpu' --cov=vllm_omni --cov-report=term-missing:skip-covered --cov-report=xml"
        mirror_hardwares: l4_1

      - label: "Simple · Diffusion Test"
-        timeout_in_minutes: 20
        commands:
-          - "pytest -sv tests/diffusion -m 'core_model and cpu'"
+          - "timeout 20m pytest -sv tests/diffusion -m 'core_model and cpu' --cov=vllm_omni --cov-report=term-missing:skip-covered --cov-report=xml"
        mirror_hardwares: l4_1

      - label: "Simple · Engine&Entrypoints Test"
-        timeout_in_minutes: 20
        commands:
-          - "pytest -sv tests/entrypoints tests/engine -m 'core_model and cpu'"
+          - "timeout 20m pytest -sv tests/entrypoints tests/engine -m 'core_model and cpu' --cov=vllm_omni --cov-report=term-missing:skip-covered --cov-report=xml"
        mirror_hardwares: l4_1

      - label: "Simple · Other Test"
-        timeout_in_minutes: 20
        commands:
-          - "pytest -sv tests/ -m 'core_model and cpu' --ignore=tests/diffusion --ignore=tests/model_executor --ignore=tests/entrypoints --ignore=tests/engine"
+          - "timeout 20m pytest -sv tests/ -m 'core_model and cpu' --ignore=tests/diffusion --ignore=tests/model_executor --ignore=tests/entrypoints --ignore=tests/engine --cov=vllm_omni --cov-report=term-missing:skip-covered --cov-report=xml"
        mirror_hardwares: l4_1

  - group: ":card_index_dividers: Diffusion Test"
@@ -123,8 +119,6 @@ steps:
        source_file_dependencies:
          - tests/e2e/offline_inference/test_qwen3_omni.py
          - tests/e2e/online_serving/test_qwen3_omni.py
-          - tests/helpers/runtime.py
-          - vllm_omni/entrypoints/openai/serving_chat.py
          - vllm_omni/model_executor/models/qwen3_omni/
          - vllm_omni/model_executor/models/common/qwen3_code_predictor.py
          - vllm_omni/model_executor/models/common/snake_activation.py
@@ -83,12 +83,38 @@ steps:
          - export BENCHMARK_DIR=tests/dfx/perf/results
          - |
            set +e
-            pytest -s -v tests/dfx/perf/scripts/run_benchmark.py --test-config-file tests/dfx/perf/tests/test_qwen3_omni_async_chunk.json -m "H100 and full_model"
+            pytest -s -v tests/dfx/perf/scripts/run_benchmark.py --test-config-file tests/dfx/perf/tests/test_qwen3_omni_async_chunk.json
            EXIT=$$?
            buildkite-agent artifact upload "tests/dfx/perf/results/*.json"
            exit $$EXIT
        mirror_hardwares: h100_2

+      - label: ":full_moon: Omni · Perf Test · vLLM Text"
+        key: nightly-omni-performance-vllm-text
+        timeout_in_minutes: 180
+        commands:
+          - export BENCHMARK_DIR=tests/dfx/perf/results
+          - |
+            set +e
+            pytest -s -v tests/dfx/perf/scripts/run_benchmark.py --test-config-file tests/dfx/perf/tests/test_qwen3_omni_vllm_text.json
+            EXIT=$$?
+            buildkite-agent artifact upload "tests/dfx/perf/results/*.json"
+            exit $$EXIT
+        mirror_hardwares: h100_2
+
+      - label: ":full_moon: Omni · Perf Test · Multi-Replica"
+        key: nightly-omni-performance-multi-replicas
+        timeout_in_minutes: 180
+        commands:
+          - export BENCHMARK_DIR=tests/dfx/perf/results
+          - |
+            set +e
+            pytest -s -v tests/dfx/perf/scripts/run_benchmark.py --test-config-file tests/dfx/perf/tests/test_qwen3_omni_multi_replicas.json
+            EXIT=$$?
+            buildkite-agent artifact upload "tests/dfx/perf/results/*.json"
+            exit $$EXIT
+        mirror_hardwares: h100_3
+
      - label: ":full_moon: Omni · MiniCPM-o 4.5 · Perf Test"
        key: nightly-omni-performance-minicpmo-4-5
        timeout_in_minutes: 180
@@ -133,7 +159,19 @@ steps:
          - export VLLM_ALLOW_LONG_MAX_MODEL_LEN="1"
          - export VLLM_USE_DEEP_GEMM="0"
          - export VLLM_MOE_USE_DEEP_GEMM="0"
-          - pytest -s -v tests/e2e/ -m "full_model and L4 and tts" --run-level "full_model" --ignore=tests/e2e/accuracy
+          - pytest -s -v tests/e2e/ -m "full_model and L4 and tts" --run-level "full_model" --ignore=tests/e2e/accuracy --ignore=tests/e2e/online_serving/test_voxcpm2_tts_expansion.py
+        mirror_hardwares: l4_1
+
+      - label: ":full_moon: TTS · Accuracy Test · VoxCPM2"
+        timeout_in_minutes: 30
+        commands:
+          - |
+            timeout 30m bash -c "
+              export VLLM_LOGGING_LEVEL=DEBUG
+              export VLLM_WORKER_MULTIPROC_METHOD=spawn
+              export VLLM_ALLOW_LONG_MAX_MODEL_LEN=1
+              pytest -s -v tests/e2e/online_serving/test_voxcpm2_tts_expansion.py -m 'full_model and cuda and tts' --run-level 'full_model'
+            "
        mirror_hardwares: l4_1

      - label: ":full_moon: TTS · Perf Test"
@@ -150,6 +188,35 @@ steps:
            exit $$EXIT
        mirror_hardwares: h100_2

+      - label: ":full_moon: TTS · VoxCPM2 · Perf Test"
+        key: nightly-tts-performance-voxcpm2
+        timeout_in_minutes: 180
+        commands:
+          - export BENCHMARK_DIR=tests/dfx/perf/results
+          - export VLLM_ALLOW_LONG_MAX_MODEL_LEN="1"
+          - |
+            set +e
+            pytest -s -v tests/dfx/perf/scripts/run_benchmark.py --test-config-file tests/dfx/perf/tests/test_voxcpm2.json
+            EXIT=$$?
+            buildkite-agent artifact upload "tests/dfx/perf/results/*.json"
+            exit $$EXIT
+        mirror_hardwares: h100_1
+
+      - label: ":full_moon: TTS · Higgs-Audio-V3 · Perf Test"
+        key: nightly-tts-performance-higgs-audio-v3
+        timeout_in_minutes: 180
+        commands:
+          - export BENCHMARK_DIR=tests/dfx/perf/results
+          - export VLLM_USE_DEEP_GEMM="0"
+          - export VLLM_MOE_USE_DEEP_GEMM="0"
+          - |
+            set +e
+            pytest -s -v tests/dfx/perf/scripts/run_benchmark.py --test-config-file tests/dfx/perf/tests/test_higgs_audio_v3.json
+            EXIT=$$?
+            buildkite-agent artifact upload "tests/dfx/perf/results/*.json"
+            exit $$EXIT
+        mirror_hardwares: h100_1
+
  - group: ":card_index_dividers: Tiny Model Tests [Multi-GPU]"
    key: nightly-tiny-model-test-group
    depends_on: upload-nightly-pipeline
@@ -179,7 +246,8 @@ steps:
      build.pull_request.labels includes "nightly-test" ||
      build.pull_request.labels includes "diffusion-x2iat-test"
    steps:
-      # Use explicit file shards so single-card cases do not reserve 2+ GPUs.
+      # Use explicit file shards so single-card cases do not reserve 2+ GPUs,
+      # and Bagel feature coverage is not duplicated via a broad tests/e2e sweep.

      - label: ":full_moon: Diffusion X2I(&A&T) · Function Test with H100 · Single-GPU"
        timeout_in_minutes: 120
@@ -187,6 +255,15 @@ steps:
          - >-
            pytest -sv
            tests/e2e/online_serving/test_qwen_image_expansion.py
+            tests/e2e/online_serving/test_qwen_image_edit_expansion.py
+            tests/e2e/online_serving/test_qwen_image_layered_expansion.py
+            tests/e2e/online_serving/test_boogu_image.py
+            tests/e2e/online_serving/test_boogu_image_edit.py
+            tests/e2e/online_serving/test_boogu_image_expansion.py
+            tests/e2e/online_serving/test_boogu_image_edit_expansion.py
+            tests/e2e/online_serving/test_bagel_expansion.py
+            tests/e2e/online_serving/test_krea2_expansion.py
+            tests/e2e/offline_inference/test_krea2_expansion.py
            -m "full_model and diffusion and H100 and not distributed_cuda"
            --run-level "full_model"
        mirror_hardwares: h100_1
@@ -197,14 +274,47 @@ steps:
          - >-
            pytest -sv
            tests/e2e/online_serving/test_qwen_image_expansion.py
+            tests/e2e/online_serving/test_qwen_image_edit_expansion.py
+            tests/e2e/offline_inference/test_krea2_expansion.py
            -m "full_model and diffusion and H100 and distributed_cuda"
            --run-level "full_model"
        mirror_hardwares: h100_2

+      - label: ":full_moon: Diffusion X2I(&A&T) · Function Test with H100 · Multi-GPU Layered/LongCat/FLUX"
+        timeout_in_minutes: 90
+        commands:
+          - >-
+            pytest -sv
+            tests/e2e/online_serving/test_qwen_image_layered_expansion.py
+            -m "full_model and diffusion and H100 and distributed_cuda"
+            --run-level "full_model"
+        mirror_hardwares: h100_2
+
+      - label: ":full_moon: Diffusion X2I(&A&T) · Function Test with H100 · Multi-GPU Bagel"
+        timeout_in_minutes: 120
+        commands:
+          - >-
+            pytest -sv
+            tests/e2e/online_serving/test_bagel_expansion.py
+            -m "full_model and diffusion and H100 and distributed_cuda"
+            --run-level "full_model"
+        mirror_hardwares: h100_2
+
+      - label: ":full_moon: Diffusion X2I(&A&T) · GLM-Image Function Test with H100"
+        timeout_in_minutes: 120
+        commands:
+          - >-
+            pytest -sv
+            tests/e2e/online_serving/test_glm_image_expansion.py
+            tests/e2e/offline_inference/test_glm_image_autoround_w4a16_expansion.py
+            -m "full_model and diffusion and H100"
+            --run-level "full_model"
+        mirror_hardwares: h100_2
+
      - label: ":full_moon: Diffusion X2I(&A&T) · Function Test with L4"
        timeout_in_minutes: 120
        commands:
-          - pytest -sv tests/e2e/ -k "not test_wan and not hunyuan" -m "full_model and diffusion and L4" --run-level "full_model" --ignore=tests/e2e/accuracy
+          - pytest -sv tests/e2e/ -k "not test_wan and not test_bagel_expansion and not hunyuan" -m "full_model and diffusion and L4" --run-level "full_model" --ignore=tests/e2e/accuracy
        mirror_hardwares: l4_4

      - label: ":full_moon: Diffusion X2I(&A&T) · Doc Test"
@@ -217,7 +327,7 @@ steps:
        timeout_in_minutes: 180
        commands:
          - export VLLM_HTTP_TIMEOUT_KEEP_ALIVE=120
-          - pytest -s -v tests/e2e/accuracy/test_qwen_image.py --run-level full_model
+          - pytest -s -v tests/e2e/accuracy/test_qwen_image*.py --run-level full_model
          - pytest -s -v tests/e2e/accuracy/test_diffusers_backend_similarity.py -k '2i_matches_diffusers' -m full_model --run-level full_model
        mirror_hardwares: h100_1

@@ -229,12 +339,6 @@ steps:
          - pytest -s -v tests/e2e/accuracy/test_hunyuan_image3_pixel_accuracy.py -m full_model --run-level full_model
        mirror_hardwares: h100_4

-      - label: ":full_moon: HiDream-O1-Image · Accuracy Test"
-        timeout_in_minutes: 180
-        commands:
-          - pytest -s -v tests/e2e/accuracy/test_hidream_o1_image.py -m full_model --run-level full_model
-        mirror_hardwares: h100_2
-
      - label: ":full_moon: Diffusion X2I(&A&T) · Perf Test · Qwen-Image"
        key: nightly-diffusion-x2iat-performance-qwen-image
        timeout_in_minutes: 180
@@ -251,6 +355,70 @@ steps:
            exit $$EXIT
        mirror_hardwares: h100_4

+      - label: ":full_moon: Diffusion X2I(&A&T) · Perf Test · Qwen-Image-Edit"
+        key: nightly-diffusion-x2iat-performance-qwen-image-edit
+        timeout_in_minutes: 180
+        commands:
+          - export DIFFUSION_BENCHMARK_DIR=tests/dfx/perf/results
+          - export DIFFUSION_ATTENTION_BACKEND=FLASH_ATTN
+          - export CACHE_DIT_VERSION=1.5.0
+          - |
+            set +e
+            pytest -s -v tests/dfx/perf/scripts/run_diffusion_benchmark.py --test-config-file tests/dfx/perf/tests/test_qwen_image_edit_vllm_omni.json
+            EXIT=$$?
+            buildkite-agent artifact upload "tests/dfx/perf/results/diffusion_result_*.json"
+            buildkite-agent artifact upload "tests/dfx/perf/results/logs/*.log"
+            exit $$EXIT
+        mirror_hardwares: h100_4
+
+      - label: ":full_moon: Diffusion X2I(&A&T) · Perf Test · Qwen-Image-Edit-2511"
+        key: nightly-diffusion-x2iat-performance-qwen-image-edit-2511
+        timeout_in_minutes: 180
+        commands:
+          - export DIFFUSION_BENCHMARK_DIR=tests/dfx/perf/results
+          - export DIFFUSION_ATTENTION_BACKEND=FLASH_ATTN
+          - export CACHE_DIT_VERSION=1.5.0
+          - |
+            set +e
+            pytest -s -v tests/dfx/perf/scripts/run_diffusion_benchmark.py --test-config-file tests/dfx/perf/tests/test_qwen_image_edit_2511_vllm_omni.json
+            EXIT=$$?
+            buildkite-agent artifact upload "tests/dfx/perf/results/diffusion_result_*.json"
+            buildkite-agent artifact upload "tests/dfx/perf/results/logs/*.log"
+            exit $$EXIT
+        mirror_hardwares: h100_4
+
+      - label: ":full_moon: Diffusion X2I(&A&T) · Perf Test · Qwen-Image-Layered"
+        key: nightly-diffusion-x2iat-performance-qwen-image-layered
+        timeout_in_minutes: 120
+        commands:
+          - export DIFFUSION_BENCHMARK_DIR=tests/dfx/perf/results
+          - export DIFFUSION_ATTENTION_BACKEND=FLASH_ATTN
+          - export CACHE_DIT_VERSION=1.5.0
+          - |
+            set +e
+            pytest -s -v tests/dfx/perf/scripts/run_diffusion_benchmark.py --test-config-file tests/dfx/perf/tests/test_qwen_image_layered_vllm_omni.json
+            EXIT=$$?
+            buildkite-agent artifact upload "tests/dfx/perf/results/diffusion_result_*.json"
+            buildkite-agent artifact upload "tests/dfx/perf/results/logs/*.log"
+            exit $$EXIT
+        mirror_hardwares: h100_1
+
+      - label: ":full_moon: Diffusion X2I(&A&T) · Perf Test · BAGEL"
+        key: nightly-diffusion-x2iat-performance-bagel
+        timeout_in_minutes: 180
+        commands:
+          - export DIFFUSION_BENCHMARK_DIR=tests/dfx/perf/results
+          - export DIFFUSION_ATTENTION_BACKEND=FLASH_ATTN
+          - export CACHE_DIT_VERSION=1.5.0
+          - |
+            set +e
+            pytest -s -v tests/dfx/perf/scripts/run_diffusion_benchmark.py --test-config-file tests/dfx/perf/tests/test_bagel_vllm_omni.json
+            EXIT=$$?
+            buildkite-agent artifact upload "tests/dfx/perf/results/diffusion_result_*.json"
+            buildkite-agent artifact upload "tests/dfx/perf/results/logs/*.log"
+            exit $$EXIT
+        mirror_hardwares: h100_1
+
  - group: ":card_index_dividers: Diffusion X2V Model Test"
    key: nightly-diffusion-x2v-group
    depends_on: upload-nightly-pipeline
@@ -272,6 +440,12 @@ steps:
          - pytest -s -v tests/e2e/online_serving/test_wan22_expansion.py -k "i2v" -m "full_model and cuda" --run-level "full_model"
        mirror_hardwares: h100_2

+      - label: ":full_moon: Diffusion X2V · LingBot Video MoE Function Test"
+        timeout_in_minutes: 90
+        commands:
+          - pytest -s -v tests/e2e/online_serving/test_lingbot_video_moe.py -k "video_generation" -m "full_model and cuda" --run-level "full_model"
+        mirror_hardwares: h100_1
+
      - label: ":full_moon: Diffusion X2V · Doc Test"
        timeout_in_minutes: 60
        commands:
@@ -282,8 +456,15 @@ steps:
        timeout_in_minutes: 90
        commands:
          - pytest -s -v tests/e2e/offline_inference/test_wan22_autoround_w4a16_expansion.py -m "full_model and cuda" --run-level "full_model"
+          - pytest -s -v tests/e2e/online_serving/test_wan_2_1_vace_expansion.py tests/e2e/online_serving/test_ltx.py -m "full_model and cuda" --run-level "full_model"
        mirror_hardwares: h100_2

+      - label: ":full_moon: Diffusion X2V · LTX-2.5 Online Test"
+        timeout_in_minutes: 60
+        commands:
+          - pytest -s -v tests/e2e/online_serving/test_ltx25.py -m "full_model and cuda" --run-level "full_model"
+        mirror_hardwares: h100_1
+
      - label: ":full_moon: Diffusion X2V · Wan2.2 Accuracy Test"
        timeout_in_minutes: 180
        commands:
@@ -302,8 +483,23 @@ steps:
        commands:
          - pytest -s -v tests/e2e/accuracy/hunyuanvideo15_t2v/test_hunyuanvideo15_t2v_video_similarity.py -m full_model --run-level full_model
          - pytest -s -v tests/e2e/accuracy/hunyuanvideo15_i2v/test_hunyuanvideo15_i2v_video_similarity.py -m full_model --run-level full_model
+          - pytest -s -v tests/e2e/accuracy/test_video_streaming_output_similarity.py -m full_model --run-level full_model
        mirror_hardwares: h100_2

+      - label: ":full_moon: Diffusion X2V · LTX Accuracy Test"
+        timeout_in_minutes: 180
+        commands:
+          - pytest -s -v 'tests/e2e/accuracy/ltx/test_ltx_official_similarity.py::test_ltx_matches_official[ltx2_3_i2v]' -m full_model --run-level full_model
+          - pytest -s -v 'tests/e2e/accuracy/ltx/test_ltx_official_similarity.py::test_ltx_matches_official[ltx23_two_stage_layer_fused_i2v]' -m full_model --run-level full_model
+        mirror_hardwares: h100_1
+
+      - label: ":full_moon: Diffusion X2V · LTX-2.5 Official Parity Test"
+        timeout_in_minutes: 180
+        commands:
+          - pytest -s -v tests/e2e/accuracy/ltx/test_ltx25_official_similarity.py::test_ltx25_distilled_two_stage_matches_official -m full_model --run-level full_model
+          - pytest -s -v tests/e2e/accuracy/ltx/test_ltx25_official_similarity.py::test_ltx25_full_matches_official -m full_model --run-level full_model
+        mirror_hardwares: h100_1
+
      - label: ":full_moon: Diffusion X2V · Perf Test"
        key: nightly-diffusion-x2v-performance
        timeout_in_minutes: 180
@@ -375,10 +571,20 @@ steps:
      - label: ":full_moon: Diffusion · Quantization Test with L4"
        timeout_in_minutes: 60
        commands:
-          - pip install "vllm-gguf-plugin==0.0.4"
+          - pip install "vllm-gguf-plugin>=0.0.3"
          - pytest -sv tests/diffusion/quantization -m 'full_model and cuda and L4' --run-level "full_model"
        mirror_hardwares: l4_1

+  - label: ":bar_chart: Testcase Statistics"
+    key: nightly-testcase-statistics
+    timeout_in_minutes: 120
+    depends_on: upload-nightly-pipeline
+    if: build.env("NIGHTLY") == "1"
+    commands:
+      - python tools/nightly/buildkite_testcase_statistics.py -o tests/dfx/perf/results/buildkite_testcase_statistics.html
+      - buildkite-agent artifact upload "tests/dfx/perf/results/*.html"
+    mirror_hardwares: h100_1
+
  # NOTE: ":email: Nightly Collection & Email" is deprecated and will be removed soon.
  # Do not add new depends_on entries or extend this step.
  - label: ":email: Nightly Collection & Email"
@@ -386,19 +592,35 @@ steps:
    depends_on:
      - nightly-omni-performance-no-async-chunk
      - nightly-omni-performance-async-chunk
+      - nightly-omni-performance-vllm-text
+      - nightly-omni-performance-multi-replicas
      - nightly-tts-performance
+      - nightly-tts-performance-higgs-audio-v3
      - nightly-diffusion-x2iat-performance-qwen-image
+      - nightly-diffusion-x2iat-performance-qwen-image-edit
+      - nightly-diffusion-x2iat-performance-qwen-image-edit-2511
+      - nightly-diffusion-x2iat-performance-qwen-image-layered
+      - nightly-diffusion-x2iat-performance-bagel
      - nightly-diffusion-x2v-performance
+      - nightly-testcase-statistics
    if: build.env("NIGHTLY") == "1" && build.env("EMAIL_DISTRIBUTION") == "1"
    commands:
      - pip install openpyxl
      - export DEFAULT_INPUT_DIR=tests/dfx/perf/results
      - export DEFAULT_OUTPUT_DIR=tests/dfx/perf/results
      - buildkite-agent artifact download "tests/dfx/perf/results/*.json" . --step nightly-tts-performance
+      - buildkite-agent artifact download "tests/dfx/perf/results/*.json" . --step nightly-tts-performance-higgs-audio-v3
      - buildkite-agent artifact download "tests/dfx/perf/results/*.json" . --step nightly-omni-performance-no-async-chunk
      - buildkite-agent artifact download "tests/dfx/perf/results/*.json" . --step nightly-omni-performance-async-chunk
+      - buildkite-agent artifact download "tests/dfx/perf/results/*.json" . --step nightly-omni-performance-vllm-text
+      - buildkite-agent artifact download "tests/dfx/perf/results/*.json" . --step nightly-omni-performance-multi-replicas
      - buildkite-agent artifact download "tests/dfx/perf/results/*.json" . --step nightly-diffusion-x2iat-performance-qwen-image
+      - buildkite-agent artifact download "tests/dfx/perf/results/*.json" . --step nightly-diffusion-x2iat-performance-qwen-image-edit
+      - buildkite-agent artifact download "tests/dfx/perf/results/*.json" . --step nightly-diffusion-x2iat-performance-qwen-image-edit-2511
+      - buildkite-agent artifact download "tests/dfx/perf/results/*.json" . --step nightly-diffusion-x2iat-performance-qwen-image-layered
+      - buildkite-agent artifact download "tests/dfx/perf/results/*.json" . --step nightly-diffusion-x2iat-performance-bagel
      - buildkite-agent artifact download "tests/dfx/perf/results/*.json" . --step nightly-diffusion-x2v-performance
+      - buildkite-agent artifact download "tests/dfx/perf/results/*.html" . --step nightly-testcase-statistics
      - python tools/nightly/generate_nightly_perf_excel.py
      - python tools/nightly/generate_nightly_perf_html.py
      - python tools/nightly/send_nightly_email.py --report-file "tests/dfx/perf/results/*.xlsx, tests/dfx/perf/results/*.html"
@@ -9,27 +9,23 @@ steps:
    depends_on: upload-ready-pipeline
    steps:
      - label: "Simple · Model Executor Test"
-        timeout_in_minutes: 20
        commands:
-          - "pytest -sv tests/model_executor -m 'core_model and cpu'"
+          - "timeout 20m pytest -sv tests/model_executor -m 'core_model and cpu' --cov=vllm_omni --cov-report=term-missing:skip-covered --cov-report=xml"
        mirror_hardwares: l4_1

      - label: "Simple · Diffusion Test"
-        timeout_in_minutes: 20
        commands:
-          - "pytest -sv tests/diffusion -m 'core_model and cpu'"
+          - "timeout 20m pytest -sv tests/diffusion -m 'core_model and cpu' --cov=vllm_omni --cov-report=term-missing:skip-covered --cov-report=xml"
        mirror_hardwares: l4_1

      - label: "Simple · Engine&Entrypoints Test"
-        timeout_in_minutes: 20
        commands:
-          - "pytest -sv tests/entrypoints tests/engine -m 'core_model and cpu'"
+          - "timeout 20m pytest -sv tests/entrypoints tests/engine -m 'core_model and cpu' --cov=vllm_omni --cov-report=term-missing:skip-covered --cov-report=xml"
        mirror_hardwares: l4_1

      - label: "Simple · Other Test"
-        timeout_in_minutes: 20
        commands:
-          - "pytest -sv tests/ -m 'core_model and cpu' --ignore=tests/diffusion --ignore=tests/model_executor --ignore=tests/entrypoints --ignore=tests/engine"
+          - "timeout 20m pytest -sv tests/ -m 'core_model and cpu' --ignore=tests/diffusion --ignore=tests/model_executor --ignore=tests/entrypoints --ignore=tests/engine --cov=vllm_omni --cov-report=term-missing:skip-covered --cov-report=xml"
        mirror_hardwares: l4_1

  - group: ":card_index_dividers: Diffusion Test"
@@ -80,7 +76,7 @@ steps:

      - label: "Tiny Model Tests · Diffusion (base)"
        commands:
-          - timeout 15m pytest -sv -n 4 tests/model_tests/diffusion -m 'core_model and cuda' --run-level "core_model"
+          - timeout 15m pytest -sv tests/model_tests/diffusion -m 'core_model and cuda' --run-level "core_model"
        mirror_hardwares: l4_1

  - label: "Engine&Model Executor Test"
@@ -125,8 +121,32 @@ steps:
          - vllm_omni/outputs/
        commands:
          - timeout 20m pytest -s -v tests/e2e/features/custom_pipeline/ -m "core_model"
-        mirror_hardwares: l4_1
-
+        agents:
+          queue: "gpu_1_queue"
+        plugins:
+          - docker#v5.2.0:
+              image: public.ecr.aws/q9t5s3a7/vllm-ci-test-repo:$BUILDKITE_COMMIT
+              always-pull: true
+              propagate-environment: true
+              # vLLM 0.27 added a pre-flight capacity check in
+              # distributed/device_communicators/shm_broadcast.py. Without this
+              # the container gets Docker's 64 MiB default and every test in
+              # this step dies at engine start with
+              #   RuntimeError: Insufficient space in /dev/shm:
+              #                 240 MiB required, 64 MiB available
+              # (9 failed in 8.7s on build #2949). vLLM 0.26 had no such check
+              # and allocated regardless, so this step passed on main while
+              # being under-provisioned the whole time — 0.27 turned a silent
+              # risk into an explicit error.
+              #
+              # This is the only inline docker plugin block in .buildkite/cuda/;
+              # every other step inherits common/ci_mirror_hardwares.yml, which
+              # already sets 8gb. Matching that rather than inventing a value.
+              shm-size: "8gb"
+              environment:
+                - "HF_HOME=/fsx/hf_cache"
+              volumes:
+                - "/fsx/hf_cache:/fsx/hf_cache"

      - label: "RLHF · VeRL-Omni E2E Test"
        source_file_dependencies:
@@ -148,8 +168,6 @@ steps:
      - label: "Omni · Qwen3-Omni Test"
        source_file_dependencies:
          - tests/e2e/online_serving/test_qwen3_omni.py
-          - tests/helpers/runtime.py
-          - vllm_omni/entrypoints/openai/serving_chat.py
          - vllm_omni/model_executor/models/qwen3_omni/
          - vllm_omni/model_executor/models/common/qwen3_code_predictor.py
          - vllm_omni/model_executor/models/common/snake_activation.py
@@ -5,104 +5,59 @@ env:
  HF_HUB_ETAG_TIMEOUT: 60

 steps:
-  - label: "Simple · CPU Coverage Test"
-    key: weekly-simple-cpu-coverage
+
+  - label: "Reliability Test - qwen3-omni"
+    timeout_in_minutes: 180
    depends_on: upload-weekly-pipeline
-    if: build.env("WEEKLY") == "1"
-    timeout_in_minutes: 60
+    if: build.env("WEEKLY") == "1" || build.pull_request.labels includes "weekly-test"
    commands:
-      - |
-        set +e
-        REPORT="coverage-core-model-cpu-$${BUILDKITE_STEP_ID:-local}.xml"
-        pytest -sv tests/ -m 'core_model and cpu' --cov=vllm_omni --cov-report=term-missing:skip-covered --cov-report=xml:$${REPORT}
-        EXIT=$$?
-        gzip -9 -f "$${REPORT}"
-        buildkite-agent artifact upload "$${REPORT}.gz"
-        exit $$EXIT
+      - pytest -s -v tests/dfx/reliability/test_reliability_qwen3_omni.py -m "slow"
+    mirror_hardwares: h100_2
+
+  - label: "Reliability Test - wan22"
+    timeout_in_minutes: 180
+    depends_on: upload-weekly-pipeline
+    if: build.env("WEEKLY") == "1" || build.pull_request.labels includes "weekly-test"
+    commands:
+      - pytest -s -v tests/dfx/reliability/test_reliability_wan22.py -m "slow"
+    mirror_hardwares: h100_2
+
+  - label: "Reliability Test - hunyuan-image"
+    timeout_in_minutes: 180
+    depends_on: upload-weekly-pipeline
+    if: build.env("WEEKLY") == "1" || build.pull_request.labels includes "weekly-test"
+    commands:
+      - pytest -s -v tests/dfx/reliability/test_reliability_hunyuan_image.py -m "slow"
+    mirror_hardwares: h100_4
+
+  - label: "Reliability Test - voxcpm2"
+    timeout_in_minutes: 180
+    depends_on: upload-weekly-pipeline
+    if: build.env("WEEKLY") == "1" || build.pull_request.labels includes "weekly-test"
+    commands:
+      - pytest -s -v tests/dfx/reliability/test_reliability_voxcpm2.py -m "slow"
    mirror_hardwares: l4_1

-  - group: "Reliability Test"
+  - group: "Reliability Test - Invalid parameters Test"
    depends_on: upload-weekly-pipeline
    if: build.env("WEEKLY") == "1" || build.pull_request.labels includes "weekly-test"
    steps:

-      - label: "Reliability Test · qwen3-omni"
-        timeout_in_minutes: 180
-        commands:
-          - pytest -s -v tests/dfx/reliability/test_reliability_qwen3_omni.py -m "slow"
-        mirror_hardwares: h100_2
-
-      - label: "Reliability Test · wan22"
-        timeout_in_minutes: 180
-        commands:
-          - pytest -s -v tests/dfx/reliability/test_reliability_wan22.py -m "slow"
-        mirror_hardwares: h100_2
-
-      - label: "Reliability Test · hunyuan-image"
-        timeout_in_minutes: 180
-        commands:
-          - pytest -s -v tests/dfx/reliability/test_reliability_hunyuan_image.py -m "slow"
-        mirror_hardwares: h100_4
-
-      - label: "Reliability Test · Invalid parameters · H100"
+      - label: "Invalid parameters Test · H100"
        timeout_in_minutes: 120
        commands:
          - pytest -s -v tests/dfx/reliability/invalid_param_test/ -m "slow and H100"
        mirror_hardwares: h100_2

-      - label: "Reliability Test · Invalid parameters · L4"
+      - label: "Invalid parameters Test · L4"
        timeout_in_minutes: 120
        commands:
          - pytest -s -v tests/dfx/reliability/invalid_param_test/ -m "slow and L4"
        mirror_hardwares: l4_1

-  - group: "Perf Test"
-    depends_on: upload-weekly-pipeline
-    if: build.env("WEEKLY") == "1" || build.pull_request.labels includes "weekly-test"
-    steps:
-
-      - label: ":full_moon: Omni · Perf Test · vLLM Text"
-        key: weekly-omni-performance-vllm-text
-        timeout_in_minutes: 180
-        commands:
-          - export BENCHMARK_DIR=tests/dfx/perf/results
-          - |
-            set +e
-            pytest -s -v tests/dfx/perf/scripts/run_benchmark.py --test-config-file tests/dfx/perf/tests/test_qwen3_omni_vllm_text.json
-            EXIT=$$?
-            buildkite-agent artifact upload "tests/dfx/perf/results/*.json"
-            exit $$EXIT
-        mirror_hardwares: h100_2
-
-      - label: ":full_moon: Omni · Perf Test · Async Chunk · Random"
-        key: weekly-omni-performance-async-chunk-random
-        timeout_in_minutes: 180
-        commands:
-          - export BENCHMARK_DIR=tests/dfx/perf/results
-          - |
-            set +e
-            pytest -s -v tests/dfx/perf/scripts/run_benchmark.py --test-config-file tests/dfx/perf/tests/test_qwen3_omni_async_chunk.json -m "H100 and slow"
-            EXIT=$$?
-            buildkite-agent artifact upload "tests/dfx/perf/results/*.json"
-            exit $$EXIT
-        mirror_hardwares: h100_2
-
-      - label: ":full_moon: Omni · Perf Test · Multi-Replica"
-        key: weekly-omni-performance-multi-replicas
-        timeout_in_minutes: 180
-        commands:
-          - export BENCHMARK_DIR=tests/dfx/perf/results
-          - |
-            set +e
-            pytest -s -v tests/dfx/perf/scripts/run_benchmark.py --test-config-file tests/dfx/perf/tests/test_qwen3_omni_multi_replicas.json
-            EXIT=$$?
-            buildkite-agent artifact upload "tests/dfx/perf/results/*.json"
-            exit $$EXIT
-        mirror_hardwares: h100_3
-
  - group: ":card_index_dividers: E2E Tests"
    depends_on: upload-weekly-pipeline
-    if: build.env("NON_CRITICAL") == "1"
+    if: build.env("WEEKLY") == "1" || build.pull_request.labels includes "weekly-test"
    steps:

      - label: "Omni · L4"
@@ -128,7 +83,7 @@ steps:
        mirror_hardwares: h100_2

      - label: "TTS · L4"
-        timeout_in_minutes: 120
+        timeout_in_minutes: 90
        commands:
          - export VLLM_ALLOW_LONG_MAX_MODEL_LEN="1"
          - export VLLM_USE_DEEP_GEMM="0"
@@ -179,7 +134,7 @@ steps:
        mirror_hardwares: l4_4

      - label: "Diffusion · H100 · Single-GPU"
-        timeout_in_minutes: 150
+        timeout_in_minutes: 120
        commands:
          - >-
            pytest -sv
@@ -194,4 +149,4 @@ steps:
            pytest -sv
            tests/e2e/ -m "slow and diffusion and H100 and distributed_cuda"
            --run-level "full_model"
-        mirror_hardwares: h100_4
+        mirror_hardwares: h100_2
@@ -69,67 +69,12 @@ steps:
          VLLM_ALLOW_LONG_MAX_MODEL_LEN: "1"
          HF_TOKEN: "${HF_TOKEN}"
        commands:
-          # Pin the Seed-TTS scorer to the second card: _get_eval_device() otherwise
-          # auto-picks npu:0, which the omni server under test already fills with its
-          # KV cache, so Whisper OOMs on `.to(device)` and every clip reports
-          # "ASR / WER failed".
-          - export SEED_TTS_WER_EVAL=1
-          - export SEED_TTS_EVAL_DEVICE=npu:1
          - |
            set +e
            pytest -s -v tests/e2e/accuracy/minicpmo_4_5/test_minicpmo_4_5.py -m "full_model and npu and A3" --run-level full_model
            EXIT=$$?
            buildkite-agent artifact upload "tests/e2e/accuracy/minicpmo_4_5/results/*.json"
            exit $$EXIT
-      - label: ":full_moon: Omni · MiniCPM-o 4.5 · Perf Test"
-        key: nightly-omni-performance-minicpmo-4-5-npu
-        timeout_in_minutes: 180
-        mirror_hardwares: a3_npu_2
-        env:
-          VLLM_WORKER_MULTIPROC_METHOD: spawn
-          VLLM_ALLOW_LONG_MAX_MODEL_LEN: "1"
-          HF_TOKEN: "${HF_TOKEN}"
-        commands:
-          - export BENCHMARK_DIR=tests/dfx/perf/results
-          - |
-            set +e
-            pytest -s -v tests/dfx/perf/scripts/run_benchmark.py -m "npu and A3" --test-config-file tests/dfx/perf/tests/test_minicpmo_4_5.json
-            EXIT=$$?
-            buildkite-agent artifact upload "tests/dfx/perf/results/*.json"
-            exit $$EXIT
-      - label: ":full_moon: Omni · MiniCPM-o 4.5 · Perf Test (A2)"
-        key: nightly-omni-performance-minicpmo-4-5-npu-a2
-        timeout_in_minutes: 180
-        mirror_hardwares: a2b3_npu_1
-        env:
-          VLLM_WORKER_MULTIPROC_METHOD: spawn
-          VLLM_ALLOW_LONG_MAX_MODEL_LEN: "1"
-          HF_TOKEN: "${HF_TOKEN}"
-          HF_HUB_OFFLINE: "1"
-        commands:
-          - export BENCHMARK_DIR=tests/dfx/perf/results
-          - |
-            set +e
-            pytest -s -v tests/dfx/perf/scripts/run_benchmark.py -m "npu and A2" --test-config-file tests/dfx/perf/tests/test_minicpmo_4_5.json
-            EXIT=$$?
-            buildkite-agent artifact upload "tests/dfx/perf/results/*.json"
-            exit $$EXIT
-      - label: ":full_moon: Omni · MiniCPM-o 4.5 · Duplex Seed-TTS Perf Test"
-        key: nightly-omni-performance-minicpmo-4-5-duplex-seed-tts-npu
-        timeout_in_minutes: 180
-        mirror_hardwares: a3_npu_2
-        env:
-          VLLM_WORKER_MULTIPROC_METHOD: spawn
-          VLLM_ALLOW_LONG_MAX_MODEL_LEN: "1"
-          HF_TOKEN: "${HF_TOKEN}"
-        commands:
-          - export BENCHMARK_DIR=tests/dfx/perf/results
-          - |
-            set +e
-            pytest -s -v tests/dfx/perf/scripts/run_benchmark.py -m "npu and A3" --test-config-file tests/dfx/perf/tests/test_minicpmo_4_5_duplex_seed_tts.json
-            EXIT=$$?
-            buildkite-agent artifact upload "tests/dfx/perf/results/*.json"
-            exit $$EXIT
  - group: ":card_index_dividers: TTS Model Test"
    key: nightly-tts-test-group
    depends_on: upload-nightly-pipeline
@@ -151,6 +96,33 @@ steps:
            EXIT=$$?
            buildkite-agent artifact upload "tests/dfx/perf/results/*.json"
            exit $$EXIT
+  - group: ":card_index_dividers: Diffusion X2I(&A&T) Model Test"
+    key: nightly-diffusion-x2iat-group
+    depends_on: upload-nightly-pipeline
+    if: >-
+      build.env("NIGHTLY") == "1" ||
+      build.pull_request.labels includes "nightly-test" ||
+      build.pull_request.labels includes "diffusion-x2iat-test"
+    steps:
+      - label: ":full_moon: Diffusion X2I(&A&T) · Perf Test · Qwen-Image-Edit-2511"
+        key: nightly-diffusion-x2iat-performance-qwen-image-edit-2511
+        timeout_in_minutes: 180
+        mirror_hardwares: a3_npu_8
+        env:
+          VLLM_WORKER_MULTIPROC_METHOD: spawn
+          VLLM_ALLOW_LONG_MAX_MODEL_LEN: "1"
+          HF_TOKEN: "${HF_TOKEN}"
+          DIFFUSION_ATTENTION_BACKEND: TORCH_SDPA
+        commands:
+          - export DIFFUSION_BENCHMARK_DIR=tests/dfx/perf/results
+          - export CACHE_DIT_VERSION=1.5.0
+          - |
+            set +e
+            pytest -s -v tests/dfx/perf/scripts/run_diffusion_benchmark.py -m npu --test-config-file tests/dfx/perf/tests/test_qwen_image_edit_2511_vllm_omni.json
+            EXIT=$$?
+            buildkite-agent artifact upload "tests/dfx/perf/results/diffusion_result_*.json"
+            buildkite-agent artifact upload "tests/dfx/perf/results/logs/*.log"
+            exit $$EXIT
  - group: ":card_index_dividers: Diffusion I2I Model Test"
    key: nightly-HunyuanImage3-x2i-test-group
    depends_on: upload-nightly-pipeline
@@ -1,15 +1,4 @@
 steps:
-  - label: "Platforms Test"
-    key: ready-platforms-test
-    depends_on: upload-ready-pipeline
-    mirror_hardwares: a3_npu_2
-    commands:
-      - >-
-        pytest -s -v
-        tests/platforms/npu/test_minicpmo_code2wav_npugraph.py
-        -m 'core_model and npu and A3 and omni'
-        --run-level 'core_model'
-
  - group: ":card_index_dividers: Omni Model Test"
    key: ready-omni-group
    depends_on: upload-ready-pipeline
@@ -43,7 +32,7 @@ steps:
    depends_on: upload-ready-pipeline
    steps:
      - label: ":sound: TTS · Qwen3-TTS CustomVoice Test"
-        mirror_hardwares: a3_npu_2
+        mirror_hardwares: a2b3_npu_1
        env:
          VLLM_WORKER_MULTIPROC_METHOD: spawn
          VLLM_ALLOW_LONG_MAX_MODEL_LEN: "1"
@@ -610,24 +610,6 @@ See the [Profiling Single-Stage Diffusion](../../../docs/contributing/profiling.

 ---

-## Pre-commit conventions
-
-New library files must pass the local gates in
-[docs/contributing/README.md](../../../docs/contributing/README.md#linting).
-That page is the full hook list (SPDX, forbidden imports including Hugging Face
-Hub / Triton / pickle, `torch.cuda`, mypy, test marks, markdownlint, Buildkite,
-shellcheck). In particular:
-
- SPDX copyright is `vLLM-Omni project` (stale `vLLM project` is rewritten).
- Use `import regex as re` and `pybase64` in `vllm_omni/`; do not import stdlib
-  `re` or `base64`. Hugging Face Hub downloads go through
-  `vllm.transformers_utils.repo_utils`.
- Do not add `torch.cuda.*` call sites; use `current_omni_platform`.
- New `tests/**/test_*.py` files need a CI level mark and a hardware mark.
- Do not expand `CHECK_IMPORTS[*].allowed_files` or `ALLOWED_FILES` without review.
- GitHub Actions skips SPDX/shellcheck/mypy-3.10/test-marks/markdownlint; run
-  `pre-commit` locally.
-
 ## Iterative Development Tips

 1. **Start minimal**: Basic generation first, no parallelism/caching
@@ -138,12 +138,9 @@ A shared buffer silently corrupts audio across concurrent requests — the sympt
   - Load codec weights (may need lazy loading from separate checkpoint)
   - Implement `forward()`: codec codes -> audio waveform
   - Return `OmniOutput` with `multimodal_outputs`
-5. **Define and register the pipeline topology** in
-   `vllm_omni/model_executor/models/<model>/pipeline.py`
-6. **Create the deploy YAML** under `vllm_omni/deploy/` for placement,
-   memory sizing, connectors, and runtime overrides
-7. **Create stage input processor** for prompt building and inter-stage handoff
-8. **Write end2end.py** test script
+5. **Create stage config YAML** defining both stages, memory allocation, and model paths
+6. **Create stage input processor** for prompt building
+7. **Write end2end.py** test script

 ### Critical Parameters to Get Right

@@ -177,7 +174,7 @@ These bugs appear in almost every new TTS PR. Check all before the first push. S
 - **All return paths must emit `model_outputs`** — if any early-return branch skips setting `model_outputs`, the serving layer silently drops that step's audio (fish speech: `fix: ensure ALL return paths emit model_outputs`)
 - **Per-request state isolation** — for batched concurrent requests, key all state by request ID; a shared buffer corrupts audio across requests (fish speech: `fix: per-request vocode + delta emission`)
 - **Codec tensor device** — move codec codes to the codec decoder's device before calling decode; mismatches cause silent CPU fallback or crashes (fish speech: `fix: use model device for CUDA stream`)
- **AR stage `max_num_seqs`** — set to at least 4 in production deploy configs; for single-stage models this is the only stage. For two-stage models, Stage 0 (AR) needs `max_num_seqs ≥ 4` to pipeline concurrent requests; Stage 1 (codec decoder) is model-specific and may intentionally use `max_num_seqs: 1`. Defaulting the AR stage to 1 causes audio gaps under concurrency because the codec window round-robins across requests (RFC #2568)
+- **AR stage `max_num_seqs`** — set to at least 4 in production configs; for single-stage models this is the only stage. For two-stage models, Stage 0 (AR) needs `max_num_seqs ≥ 4` to pipeline concurrent requests; Stage 1 (codec decoder) typically uses `max_num_seqs: 1` intentionally. Default of 1 everywhere causes audio gaps under concurrency because the codec window round-robins across requests (RFC #2568)

 ### Optional Dependency Handling

@@ -193,18 +190,18 @@ pattern, signature constraints, and MOSS-TTS-Nano reference.
 When the upstream model cannot be cleanly split into an AR stage and a
 separate decoder, run the full pipeline inside a single AR worker and
 stream audio through a per-request `inference_stream()` generator keyed by
-`_omni_req_id`. Define one `StagePipelineConfig` with
-`execution_type=StageExecutionType.LLM_AR`, `engine_output_type="audio"`,
-`final_output=True`, and `owns_tokenizer=True`. Set `async_chunk: false` in
-the deploy YAML. Only extract params from
+`_omni_req_id`. Stage config must set `worker_type: ar`,
+`engine_output_type: audio`, `final_output: true`, `is_comprehension: true`,
+and `async_chunk: false` at the top level. Only extract params from
 `additional_information` that you actually forward, or pre-commit fails
 `ruff F841`.

 Full walkthrough with the complete `forward()` / `_create_stream_gen()`
-skeleton plus pipeline/deploy definitions:
+skeleton and stage-config fields:
 [references/single-stage-ar.md](references/single-stage-ar.md). For an
 in-tree reference, look for any single-stage AR model under
-`vllm_omni/model_executor/models/`, such as MOSS-TTS-Nano.
+`vllm_omni/model_executor/models/` — e.g. the MOSS-TTS-Nano integration when
+it lands.

 **VoxCPM2 is a different pattern** and should not reuse this skeleton — it
 runs the base LM under vLLM PagedAttention with external side-computation.
@@ -213,8 +210,7 @@ See `plan/voxcpm2_native_ar_design.md`.
 ### Deliverables

 - Model files in `vllm_omni/model_executor/models/<model_name>/`
- Registered `pipeline.py` topology
- Deploy YAML under `vllm_omni/deploy/`
+- Stage config YAML
 - Working `end2end.py` at `examples/offline_inference/text_to_speech/<model>/end2end.py`
 - New section in `examples/offline_inference/text_to_speech/README.md` (table row + per-model section). Do **not** create a top-level `examples/offline_inference/<model>/` dir or a per-model `README.md` inside `text_to_speech/<model>/` — the hub README is the documented surface and the mkdocs `generate_examples` hook only descends one level into `examples/<category>/`.

@@ -345,8 +341,8 @@ Heavier scenarios in the same file use **`advanced_model` only** (streaming, ext
@pytest.mark.tts
@hardware_test(res={"cuda": "L4"}, num_cards=1)
@pytest.mark.parametrize("omni_server", tts_server_params, indirect=True)
-def test_voice_clone_en_non_streaming_001(omni_server, online_client) -> None:
-    online_client.send_audio_speech_request({...})
+def test_voice_clone_en_non_streaming_001(omni_server, openai_client) -> None:
+    openai_client.send_audio_speech_request({...})
 ```

 **L4 consolidation:** Prefer parametrized `OmniServerParams` rows (`default`, `async_chunk`, feature flags) in one expansion module rather than many merge-only files ([#1832](https://github.com/vllm-project/vllm-omni/issues/1832)).
@@ -363,8 +359,8 @@ def test_voice_clone_en_non_streaming_001(omni_server, online_client) -> None:

 | Path | Fixture | Call |
 |------|---------|------|
-| Online `/v1/*` | `online_client` | `online_client.send_*_request(request_config)` |
-| Offline inference | `offline_client` | `offline_client.send_*_request(request_config)` |
+| Online `/v1/*` | `openai_client` | `openai_client.send_*_request(request_config)` |
+| Offline inference | `omni_runner_handler` | `omni_runner_handler.send_*_request(request_config)` |

 1. **Grep `runtime.py` first** — reuse `send_omni_request`, `send_diffusion_request`, `send_audio_speech_request` (online + offline Qwen-style TTS), `send_single_stage_tts_request` (Coqui XTTS / MOSS-TTS-Nano offline), etc.
 2. **No matching helper** → add `send_<feature>_request` (or `send_<route>_http_request` for negative/dfx) in **`runtime.py`** with general `assert_*` bundled inside, **then** call it from the test.
@@ -396,7 +392,7 @@ See [vllm-omni-test skill](../vllm-omni-test/SKILL.md) § **Runtime send helpers
  `/health` return non-200 until you're actually ready.
 - **Mark tests per the CI Levels table** — baseline smoke: `core_model` + `advanced_model`; heavier cases: `advanced_model` only; L4 expansion: `full_model`
 - **No per-model helper modules** — do not create `tests/helpers/{slug}.py`; keep constants and `request_config` payloads in the test file
- **Online and offline e2e go through `runtime.py`** — `online_client.send_audio_speech_request` (online); `offline_client.send_audio_speech_request` (Qwen-style offline) or `send_single_stage_tts_request` (single-stage offline). Add a new `send_*_request` in `runtime.py` when none fits; do not embed `omni.generate` or HTTP in tests
+- **Online and offline e2e go through `runtime.py`** — `openai_client.send_audio_speech_request` (online); `omni_runner_handler.send_audio_speech_request` (Qwen-style offline) or `send_single_stage_tts_request` (single-stage offline). Add a new `send_*_request` in `runtime.py` when none fits; do not embed `omni.generate` or HTTP in tests

 ## Phase 4: Async Chunk (Streaming)

@@ -404,29 +400,21 @@ See [vllm-omni-test skill](../vllm-omni-test/SKILL.md) § **Runtime send helpers

 ### Steps

-1. **Update the pipeline topology** so the producing stage declares its async
-   handoff processor with `async_chunk_process_next_stage_input_func`.
-2. **Update the deploy YAML** to enable async chunk and configure the connector:
+1. **Update stage config YAML**:
   ```yaml
   async_chunk: true
-
-   connectors:
-     connector_of_shared_memory:
-       name: SharedMemoryConnector
-       extra:
-         codec_streaming: true
-         codec_chunk_frames: 25
-         codec_left_context_frames: 25
+   codec_chunk_frames: 25      # frames per chunk
+   codec_left_context_frames: 25  # overlap for smooth boundaries
   ```
-3. **Implement chunk handling in Stage 1**:
+2. **Implement chunk handling in Stage 1**:
   - Accept partial input (chunk of codec codes)
   - Handle left context for smooth audio boundaries
   - Return partial audio in `OmniOutput`
-4. **Test streaming**:
+3. **Test streaming**:
   - Verify audio quality matches non-streaming output
   - Check for artifacts at chunk boundaries
   - Measure TTFA (time to first audio)
-5. **Update online serving** to support `stream=true` with PCM output
+4. **Update online serving** to support `stream=true` with PCM output

 ### Streaming Architecture

@@ -447,8 +435,7 @@ Stage 0 (AR)                    Stage 1 (Decoder)

 ### Deliverables

- Updated pipeline async handoff processor and deploy config with
-  `async_chunk: true`
+- Updated stage config with async_chunk enabled
 - Smooth streaming audio without boundary artifacts
 - TTFA metrics

@@ -520,15 +507,14 @@ Use this checklist when integrating a new TTS model:
 - [ ] Config classes created with `model_type` registration
 - [ ] Stage 0 (AR) implemented and generates correct tokens
 - [ ] Stage 1 (Decoder) produces correct audio from tokens — dtype float32 for codec decoder
- [ ] AR stage `max_num_seqs` ≥ 4 in the production deploy config unless the model has a tested lower limit
+- [ ] Stage 1 `max_num_seqs` ≥ 4 in production config (default 1 causes gaps under concurrency)
 - [ ] Optional dependency fallbacks handled at `load_weights()` time (torchaudio/soundfile/etc.)
 - [ ] Streaming: codec codes accumulated across AR steps (not reset per step)
 - [ ] Streaming: delta audio emitted per chunk, not full re-decoded waveform
 - [ ] Streaming: all `forward()` return paths emit `model_outputs`
 - [ ] Streaming: per-request state keyed by request ID (not shared across requests)
 - [ ] Streaming: codec tensors moved to codec decoder device before decode
- [ ] Pipeline topology defined in `pipeline.py` and registered in `OMNI_PIPELINES`
- [ ] Deploy YAML created under `vllm_omni/deploy/`
+- [ ] Stage config YAML created
 - [ ] `end2end.py` produces audio matching reference quality
 - [ ] README.md written

@@ -545,8 +531,7 @@ Use this checklist when integrating a new TTS model:
 - [ ] Documentation added (offline + online docs, nav, supported models)

 ### Phase 4: Async Chunk
- [ ] Pipeline declares the async handoff processor
- [ ] Deploy config sets `async_chunk: true` and connector chunk parameters
+- [ ] Stage config updated with `async_chunk: true`
 - [ ] Stage 1 handles partial chunks correctly
 - [ ] No audio artifacts at chunk boundaries
 - [ ] Streaming via API (`stream=true`) works
@@ -563,7 +548,7 @@ Use this checklist when integrating a new TTS model:
 - [ ] `pre-commit run --files <changed>` passes before every push
 - [ ] Every commit has `Signed-off-by` matching the author email (`git commit -s`)
 - [ ] `git config user.email` matches the email registered on your GitHub account
- [ ] Hook list, failure table, and DCO recovery: [references/precommit-dco.md](references/precommit-dco.md)
+- [ ] Details and failure-recovery commands: [references/precommit-dco.md](references/precommit-dco.md)

 ## References

@@ -30,18 +30,6 @@ but the changes are correct — stage the modified files and re-commit.
 | `ruff F841` | Variable extracted but never forwarded to model call | Remove the extraction or wire it through |
 | `ruff E402` | Import added below function definitions | Move to top-level import block |
 | `ruff format` | Line length, spacing, quote style | Accept auto-fix, stage, re-commit |
-| `check-spdx-header` | Missing header, or copyright still says `vLLM project` | Two-line Omni header (`vLLM-Omni project`); restage the rewrite |
-| `check-forbidden-imports` | Stdlib `re`/`base64`, pickle, Hugging Face Hub API, or direct Triton/TileLang | `import regex as re` and `pybase64`; use `vllm.transformers_utils.repo_utils`. Do **not** add the file to `allowed_files` without review |
-| `check-torch-cuda-call` | New `torch.cuda.*` call site | Use `current_omni_platform` / `OmniPlatform`; do not grow `ALLOWED_FILES` without review |
-| `check-tts-adapter-migration` | New `self._tts_model_type` branch in `serving_speech.py` | Put per-model logic in `tts_adapters/`. Lower `MAX_MODEL_TYPE_BRANCHES` when removing branches; do not raise it without review |
-| `check-test-ci-coverage` | New `tests/**/test_*.py` missing level or hardware mark | Add `core_model`/`advanced_model`/… plus `cpu`/`cuda`/`hardware_test(` |
-| `mypy-3.10` | Type error on changed `vllm_omni/` files | Fix the types; model trees are excluded. Extra versions: `pre-commit run --hook-stage manual mypy-3.12` |
-| `markdownlint-cli2` | Docs/README markdown lint | Accept auto-fix under `docs/` / `recipes/` / root README |
-| `check-buildkite` | Invalid `.buildkite/*.yml` | Fix the YAML; do not grow `SKIP_FILES` without review |
-| `shellcheck` | No `shellcheck` on PATH, or script warning | `apt-get`/`dnf`/`brew install shellcheck`, or `shellcheck.exe` on Windows PATH |
-
-Canonical policy, CI `SKIP` list, and allowlist locations:
-[docs/contributing/README.md](../../../docs/contributing/README.md#linting).

 ## DCO sign-off

@@ -86,51 +86,12 @@ class YourModelForCausalLM(nn.Module):
 - Handle both `"audio"` (incremental) and `"result"` (final combined) event
  types from upstream models.

-## Pipeline and deploy config
+## Stage config

-Define the fixed single-stage topology in `pipeline.py`:
-
-```python
-from vllm_omni.config.stage_config import (
-    PipelineConfig,
-    StageExecutionType,
-    StagePipelineConfig,
-)
-
-YOUR_TTS_PIPELINE = PipelineConfig(
-    model_type="your_model_name",
-    default_deploy_config_name="your_model_name.yaml",
-    model_arch="YourModelForCausalLM",
-    stages=(
-        StagePipelineConfig(
-            stage_id=0,
-            model_stage="your_model_name",
-            execution_type=StageExecutionType.LLM_AR,
-            input_sources=(),
-            owns_tokenizer=True,
-            engine_output_type="audio",
-            final_output=True,
-            final_output_type="audio",
-        ),
-    ),
-)
-```
-
-Register it in `vllm_omni/config/pipeline_registry.py`. Keep placement and
-runtime sizing in `vllm_omni/deploy/your_model_name.yaml`:
-
-```yaml
-async_chunk: false
-
-stages:
-  - stage_id: 0
-    devices: "0"
-    max_num_seqs: 4
-    gpu_memory_utilization: 0.8
-```
-
-Do not move `execution_type`, output ownership, tokenizer ownership, or model
-architecture into the deploy YAML; those are pipeline topology.
+Single stage with `worker_type: ar`, `engine_output_type: audio`,
+`final_output: true`, `is_comprehension: true`, and `async_chunk: false` at
+the top level. Omitting any of these causes silent misclassification in the
+serving layer.

 ## Lint discipline

@@ -140,5 +101,8 @@ pre-commit.

 ## Reference implementation

-Use `vllm_omni/model_executor/models/moss_tts_nano/pipeline.py` and
-`vllm_omni/deploy/moss_tts_nano.yaml` as the in-tree reference.
+Look for any single-stage AR model under
+`vllm_omni/model_executor/models/` — e.g. `moss_tts_nano/` when its
+integration lands. If none is in tree yet, follow the skeleton above and
+cross-check against the `is_comprehension: true` / `async_chunk: false`
+dispatch in `vllm_omni/entrypoints/openai/serving_speech.py`.
@@ -1,135 +0,0 @@
---
-name: find-simplifications
-description: Find evidence-backed simplification candidates in vLLM-Omni and, when requested, turn them into focused proposals or code changes. Use for audits of dead, duplicated, speculative, over-generalized, unnecessarily defensive, or hand-rolled code. Use review-pr for ordinary correctness review and diffusion-perf-opt for performance-first optimization.
---
-
-# Find vLLM-Omni Simplifications
-
-Find a small number of well-proven ways to reduce code, state, APIs, or maintenance cost without weakening supported behavior. Treat this as an architecture and ownership audit, not a dead-code search or style cleanup.
-
-The default deliverable is a read-only report. Do not add TODOs, design documents, issues, or code unless the user asks for those changes.
-
-## Establish the Contract
-
-Before judging a candidate:
-
-1. Read the repository instructions supplied by the host.
-2. Read [`docs/design/architecture_overview.md`](../../../docs/design/architecture_overview.md).
-3. Select only the relevant active module and feature documents from [`docs/design/index.md`](../../../docs/design/index.md). Archived design pages are historical context, not current contracts.
-4. Identify the comparison base with `git merge-base HEAD origin/main`; do not assume the current branch represents the intended baseline.
-5. If tests or CI coverage may change, use [`vllm-omni-test`](../vllm-omni-test/SKILL.md) for test placement, markers, and commands.
-
-Separate an implementation accident from an intentional boundary. In particular:
-
- vLLM-Omni extends and sometimes overrides upstream vLLM. A similar upstream implementation is evidence for reuse only after comparing API, lifecycle, and multi-stage semantics.
- Registries, import strings, model configuration, deployment YAML, plugins, and optional dependencies create dynamic consumers that a static reference count can miss.
- Hardware backends, model families, execution modes, and connector implementations may be intentionally parallel. Do not propose collapsing one only because it is inactive in the local environment.
- Stage, replica, request, cache, and transport state can look redundant while representing different owners. Prove that two fields or barriers encode the same fact before merging them.
- A shorter hot path is not a simplification if it adds synchronization, tensor copies, host materialization, recompilation, or a measurable quality/performance regression.
-
-## Strong Candidates
-
-A strong candidate removes a meaningful surface and has a clear replacement or deletion boundary. Examples include:
-
- A public method, configuration option, registry entry, route, message field, or event has no production consumer and no compatibility obligation.
- Tests or documentation are the only consumers of behavior that is not part of a supported contract.
- Multiple layers mirror the same request, lifecycle, cache-validity, readiness, or topology state.
- AR, diffusion, platform, or model-specific implementations duplicate a stable common operation and can share it without hiding performance-critical differences.
- An inherited upstream vLLM primitive is reimplemented locally without an Omni-specific semantic difference.
- Compatibility or fallback branches protect environments the project no longer supports.
- Serialization, IPC, output formatting, or connector code materializes the same payload more than once or converts between equivalent representations.
- A helper, abstraction, package split, or extension point has only one real implementation and adds more indirection than policy.
- Hand-written infrastructure can be replaced by an existing project dependency, Python standard-library feature, PyTorch primitive, or upstream vLLM facility with net deletion and equal observability.
- Tests maintain large mocks, snapshots, or expected data solely for an unused API or representation.
-
-Do not elevate typo fixes, formatting, isolated renames, or vague complexity complaints into simplification candidates. Bundle small cleanups only when they support one substantive removal.
-
-## Survey by Ownership Boundary
-
-For broad audits, cover the largest or riskiest production deltas first. Useful domains are:
-
- `vllm_omni/engine/`: orchestration, stage pools, request state, output convergence, cancellation, and replica lifecycle.
- `vllm_omni/worker/` and AR model execution: upstream vLLM overlays, scheduler/cache state, collective RPC, adapters, and weight loading.
- `vllm_omni/diffusion/`: request/step execution, batching, output materialization, IPC, offload, parallelism, and model pipelines.
- `vllm_omni/entrypoints/`: duplicated validation/defaulting, offline/online parity, streaming, and route compatibility.
- Connectors and distributed code: ownership, copies, barriers, handles, cleanup, and failure propagation across process/device/node boundaries.
- Platform backends: genuine vendor differences versus copied control flow that has drifted.
- Configuration, registries, recipes, and examples: duplicate sources of truth and options that never reach a runtime consumer.
- Tests and CI: redundant fixtures, mocks of obsolete contracts, and expensive coverage that can move to a cheaper level without losing the guarded behavior.
-
-When the user explicitly requests a repository-wide or many-candidate audit and parallel agent work is available and authorized, divide these domains among agents and require the same evidence format from each. Otherwise survey them sequentially.
-
-## Prove or Reject Each Candidate
-
-Use `rg` first, then read every relevant caller and implementation. Search exact Python symbols plus serialized names, route paths, configuration keys, registry strings, YAML values, and CLI spellings.
-
-Classify evidence:
-
- **Production:** `vllm_omni/`, runtime configuration, registries, serving entrypoints, connectors, recipes used for supported deployments, and executable loader paths.
- **Validation/support:** `tests/`, benchmarks, examples, docs, CI, and developer tooling.
- **External/dynamic:** upstream vLLM contracts, third-party plugins, model repositories, optional backends, and string-loaded objects. State what was checked and what remains unknown.
-
-For each candidate, answer:
-
-1. What exact surface would disappear or merge?
-2. Who owns the state or behavior today?
-3. Which production consumers exist, including dynamic consumers?
-4. What supported behavior, compatibility, performance, memory, or observability could change?
-5. What is the smallest validation that would catch a bad simplification?
-6. Is the result net deletion after tests, adapters, migration glue, and documentation are counted?
-
-Reject or downgrade the candidate when a live consumer exists and removal is actually a feature decision; when an active design contract explains the separation; when the change only moves complexity; or when hardware/model evidence is unavailable for a performance-sensitive claim.
-
-## Lifecycle and Data-Movement Audits
-
-For asynchronous or distributed code, map the ownership graph before recommending deletion:
-
-```text
-request admission -> orchestrator -> stage/replica -> worker/device
-  -> connector or IPC boundary -> output aggregation -> terminal cleanup
-```
-
-Associate every lock, event, sentinel, queue, readiness flag, timeout, abort path, and cache marker with an owner and transition. Coalesce mechanisms only when they represent the same state and have the same failure boundary. Preserve separate mechanisms when they protect publication versus rollback, local versus remote ownership, first-terminal-outcome arbitration, or cleanup after partial failure.
-
-For tensors and media, also trace device, process, and ownership transitions. Count GPU-to-CPU copies, shared-memory/object-store handles, serialization, decode/encode steps, and unlink/release responsibility. Prefer eliminating a transfer or representation over merely hiding it behind a helper.
-
-## Dependency Replacements
-
-Prefer facilities already available in the repository before adding a dependency. For a proposed replacement:
-
- Name the exact local behavior it covers and any semantics that remain in glue code.
- Check maintenance, license, optional-dependency boundaries, platform support, and transitive footprint.
- Compare net deletion, test burden, import/startup cost, and runtime behavior.
- Benchmark when the replaced code is on a model, scheduler, connector, serialization, or serving hot path.
-
-A wrapper that retains the same state machine or conversion logic is not a simplification.
-
-## Deliver the Result
-
-Report only candidates supported by concrete evidence. For each one include:
-
- **Surface:** files and symbols involved.
- **Evidence:** production consumers found, dynamic paths checked, and relevant design contract.
- **Simplification:** exactly what to remove, merge, inline, or reuse.
- **Benefit:** deleted API/state/code, reduced data movement, or reduced maintenance/test burden.
- **Risk and validation:** behavior that could change and the narrowest useful tests or measurements.
- **Confidence:** high or medium, with the unresolved evidence named for medium-confidence items.
-
-Also list representative ideas that were rejected when that prevents repeated investigation. Prefer three high-confidence candidates over a long speculative inventory.
-
-If the user asks for a durable design proposal, place it under `docs/design/feature/` and register it in `docs/design/index.md`; use current design-document conventions and keep implementation details proportional to the decision. If the user asks for implementation, make the smallest coherent change, update affected tests/docs, and preserve public compatibility unless the user explicitly accepts a breaking change.
-
-## Folding Work from Another Branch
-
-Diff the source branch against its own merge base with `origin/main`, not against the current feature branch. Port only independently justified candidates. Consolidate overlaps into the candidate with stronger evidence, and do not preserve a candidate count by carrying weaker duplicates.
-
-## Validation
-
-Match validation to the outgoing diff:
-
- Documentation or skill changes: run the repository skill validator when available, check links/paths, search for stale source-specific terminology, and run `git diff --check`.
- Python changes: run the narrowest relevant pytest coverage through the repository environment, then lint/format the changed files.
- Distributed, model, hardware, performance, or accuracy changes: run available CPU/static checks and state the exact GPU/NPU/model gap; never present simulated evidence as device validation.
- Before submission, use [`precheck-pr`](../precheck-pr/SKILL.md) for the branch-level self-review.
-
-When summarizing, distinguish checks that passed from checks that were not runnable, and state the snapshot or branch against which the audit was performed.
@@ -67,10 +67,6 @@ Ask: "Quick mode or full mode?" Then walk the checklist for the detected PR type

 **Also run the Examples-Policy check on every PR** using [references/examples-policy.md](references/examples-policy.md). Inspect only Python paths introduced by the diff. Treat a new model-, checkpoint-, vendor-, or family-specific Python example as blocking; do not report pre-existing example debt.

-**Also run the Simplification pass on every PR** using [find-simplifications](../find-simplifications/SKILL.md). Keep it diff-scoped: inspect added or modified public APIs, state, abstractions, fallback and compatibility paths, data movement, and only the adjacent ownership needed to prove a candidate. Do not expand the pass into a repository-wide audit. Zero candidates is a valid pass; report only evidence-backed opportunities. Mark a candidate as blocking only when it proves a correctness or merge-readiness problem, such as newly unreachable code. Otherwise report it as a warning.
-
-**Also confirm local pre-commit gates** from [docs/contributing/README.md](../../../docs/contributing/README.md#linting). GitHub Actions `SKIP` does not prove they passed. Full new-hook list: Omni SPDX (`vLLM-Omni project`); forbidden imports (stdlib `re`/`base64`, pickle, Hugging Face Hub API, Triton/TileLang); no new `torch.cuda` call sites; shellcheck (macOS/Windows must install the binary); mypy-3.10; test files have CI level + hardware marks; TTS `_tts_model_type` branches in `serving_speech.py` must not increase; markdownlint on `docs/`; Buildkite YAML schema. ✗ for growing `allowed_files` / `ALLOWED_FILES` or raising `MAX_MODEL_TYPE_BRANCHES` without review.
-
 ### Step 5: Print Report

 ```
@@ -84,7 +80,6 @@ Pre-check report for <branch>
  PR title format    ✓
  Code quality       ⚠ 1 broad except, 2 Any hints
  Examples policy    ✗ new model-specific Python example
-  Simplification     ⚠ helper duplicates an existing owner
  PR desc integrity  ✓
  Registry/config    ✓
  Dead code          ⚠ 2 warnings
@@ -164,7 +164,6 @@ Diffusion models live under `vllm_omni/diffusion/`. In addition to the New Model
 - [ ] **PR body matches diff:** description doesn't claim changes not in the diff
 - [ ] **Branch is rebased:** `git merge-base HEAD origin/main` is recent, no merge conflicts
 - [ ] **CI gates passing:** DCO, pre-commit, build — check `gh pr view --json statusCheckRollup` if a PR already exists
- [ ] **Local pre-commit gates:** full list in [Linting](../../../../docs/contributing/README.md#linting). Blocking when the diff introduces: stale `vLLM project` SPDX; stdlib `re`/`base64` or pickle in library code; new `torch.cuda` call sites; `tests/**/test_*.py` without level+hardware marks; new `_tts_model_type` branches in `serving_speech.py`; invalid `.buildkite` YAML. macOS/Windows need a native `shellcheck`. ✗ for growing `CHECK_IMPORTS[*].allowed_files`, `ALLOWED_FILES`, or `MAX_MODEL_TYPE_BRANCHES` without review.

 ### Full (adds)

@@ -31,12 +31,9 @@ self-check.
 - [`diffusion-perf-opt`](diffusion-perf-opt/SKILL.md): guides diffusion model
  performance optimization, including profiling traces, parallel strategies,
  stage timing analysis, and benchmark-driven tuning
- [`find-simplifications`](find-simplifications/SKILL.md): finds evidence-backed
-  opportunities to remove or merge dead, duplicated, speculative,
-  over-generalized, or unnecessarily defensive vLLM-Omni code
 - [`precheck-pr`](precheck-pr/SKILL.md): self-checks a branch before creating a
-  PR by validating title format, dead code, simplification opportunities,
-  accuracy and performance claims, and merge readiness
+  PR by validating title format, dead code, accuracy and performance claims,
+  and merge readiness
 - [`quantization`](quantization/SKILL.md): guides quantization method selection,
  model integration, checkpoint loading, and quality/performance validation
  for vLLM-Omni
@@ -21,10 +21,7 @@ Make every finding:
 - **Calibrated:** match severity to user and maintainer impact.

 Do not report unrelated backlog, style already enforced by pre-commit, or a
-missing test that would not protect changed behavior. Do report new allowlist
-or budget entries in `check_forbidden_imports.py` / `check_torch_cuda.py` /
-`check_tts_adapter.py` / `check_buildkite.py` unless the PR justifies them:
-those are policy changes, not lint noise.
+missing test that would not protect changed behavior.

 ## Select the input and depth

@@ -95,13 +92,12 @@ If docs and live code disagree, verify the code/tests and report the drift.

 | Reference | Read when |
 | --- | --- |
-| [model-addition-checklist.md](references/checks/model-addition-checklist.md) | A model, architecture, loader, processor, registry, pipeline config, or deploy config is added. |
+| [model-addition-checklist.md](references/checks/model-addition-checklist.md) | A model, architecture, loader, processor, registry, or stage config is added. |
 | [perf-verification.md](references/checks/perf-verification.md) | The PR makes a latency, throughput, memory, or quality claim. |
 | [test-quality-evaluation.md](references/checks/test-quality-evaluation.md) | Tests change, are absent for risky code, or may not exercise production behavior. |
 | [tests-docs-checklist.md](references/checks/tests-docs-checklist.md) | Coverage, CI markers, examples, user docs, or PR evidence need review. |
 | [verification.md](references/checks/verification.md) | Hardware, a server, or a runnable affected path is available for active verification. |
 | [examples-policy.md](../precheck-pr/references/examples-policy.md) | The PR adds, copies, or renames Python under `examples/`; apply the canonical policy shared with `precheck-pr`. |
-| [find-simplifications](../find-simplifications/SKILL.md) | Every review; run a diff-scoped subtraction and simplification pass after correctness blockers. |

 ### Delivery and reviewer coordination

@@ -184,13 +180,9 @@ promotion gate. Candidate or draft rules are questions, not blockers, unless
 current code, tests, or policy enforce them. Inspect both sides of any config,
 registry, serialization, connector, cache, or stage boundary.

-Read and apply [find-simplifications](../find-simplifications/SKILL.md) on every
-review. Constrain it to the diff and the adjacent ownership, callers, or
-consumers needed to prove a candidate. Check whether added or expanded helpers,
-classes, state, fallback and compatibility branches, data movement, or public
-behavior can be deleted, merged, moved, or inlined. Zero candidates is a valid
-result. Do not widen the review into repository backlog or report speculative
-style preferences as simplification findings.
+When a diff adds or expands a helper, class, fallback, compatibility branch, or
+public behavior, run a subtraction pass: remove out-of-scope behavior and check
+whether each new abstraction can be deleted, merged, moved, or inlined.

 ### 6. Verify the changed path

@@ -1,7 +1,7 @@
 # Model Addition Checklist

 Read this reference when a PR adds or expands a model architecture, pipeline,
-loader, processor, registry entry, pipeline config, or deploy config.
+loader, processor, registry entry, or stage configuration.

 Official docs: [model contribution guides](https://docs.vllm.ai/projects/vllm-omni/en/latest/contributing/model/),
 [adding an omni model](https://docs.vllm.ai/projects/vllm-omni/en/latest/contributing/model/adding_omni_model/),
@@ -3,7 +3,7 @@
 Primary design: [vLLM-Omni Configuration](https://docs.vllm.ai/projects/vllm-omni/en/latest/design/module/vllm_omni_config/).

 Use for config construction, deploy YAML, registries, schema, defaults,
-aliases, CLI projection, pipeline config, and topology. Inspect the reviewed
+aliases, CLI projection, stage config, and topology. Inspect the reviewed
 page's status: while its contract remains deferred or draft, current code and
 tests—not proposed precedence rules—are authoritative.

@@ -111,17 +111,6 @@ Mark early findings as preliminary and continue. This is not a GitHub comment.
  but do not publish review events without separate authorization.
 - Record DCO, pre-commit, required CI, and mergeability. Pending or unknown gates
  do not block source review.
- GitHub Actions `SKIP` omits SPDX, shellcheck, markdownlint, mypy-3.10, and
-  test-mark coverage. A green GHA pre-commit job does not prove those local
-  gates passed. New files still need the full Linting list: Omni SPDX
-  (`vLLM-Omni project`), no stdlib `re`/`base64` in `vllm_omni/`, no new
-  pickle / Hugging Face Hub API / `torch.cuda` call sites, test marks, TTS
-  adapter ratchet, Buildkite schema, and native shellcheck on macOS/Windows.
-  See [Linting](https://vllm-omni.readthedocs.io/en/latest/contributing/#linting).
- Expanding `CHECK_IMPORTS[*].allowed_files`, `ALLOWED_FILES`,
-  `MAX_MODEL_TYPE_BRANCHES`, or Buildkite `SKIP_FILES` is a policy change.
-  Do not rubber-stamp allowlist/budget growth; require justification and
-  prefer fixing the call site.
 - Treat a failed gate as its own evidence. Do not restate its formatting/lint
  output as a new code-review finding.
 - Open CI logs only when the first failing step overlaps the frozen diff or
@@ -48,7 +48,7 @@ compatibility changes.

 | Signal | Read | Optional repo-local skill |
 | --- | --- | --- |
-| New or expanded model, loader, processor, registry, pipeline config, or deploy config | [model-addition-checklist.md](../checks/model-addition-checklist.md) | [`add-tts-model`](../../../add-tts-model/SKILL.md) or [`add-diffusion-model`](../../../add-diffusion-model/SKILL.md) |
+| New or expanded model, loader, processor, registry, or stage config | [model-addition-checklist.md](../checks/model-addition-checklist.md) | [`add-tts-model`](../../../add-tts-model/SKILL.md) or [`add-diffusion-model`](../../../add-diffusion-model/SKILL.md) |
 | Latency, throughput, memory, scaling, precision, or quality claim | [perf-verification.md](../checks/perf-verification.md) | [`diffusion-perf-opt`](../../../diffusion-perf-opt/SKILL.md) for diffusion |
 | Tests changed, absent for risky behavior, or test-only | [test-quality-evaluation.md](../checks/test-quality-evaluation.md) | [`vllm-omni-test`](../../../vllm-omni-test/SKILL.md) |
 | CI, examples, docs, public behavior, or contributor evidence | [tests-docs-checklist.md](../checks/tests-docs-checklist.md) | None |
@@ -94,8 +94,8 @@ Existing references: `tests/e2e/offline_inference/test_qwen2_5_omni.py` (L2-styl

 | Scenario | Typical location | Fixtures / runner pattern | Baseline markers & level |
 |----------|------------------|---------------------------|---------------------------|
-| **Offline inference e2e** | `tests/e2e/offline_inference/` | **Module (default):** `omni_runner` + `offline_client`. **Function (isolation only):** `omni_runner_function` + `offline_client_function`. Diffusion/TTS may use `Omni(...).generate` directly | L2: `core_model` + **one of** `omni` / `tts` / `diffusion`; `@hardware_test(...)` when GPU/NPU is required |
-| **Online serving e2e** | `tests/e2e/online_serving/` | **Module (default):** `omni_server` + `online_client`. **Function (isolation only):** `omni_server_function` + `online_client_function`. Clients: `send_omni_request` (omni), `send_audio_speech_request` (tts), `send_diffusion_request` / `send_video_diffusion_request` / `send_images_generations_request` (diffusion) | Baseline smoke: **`core_model` + `advanced_model`**; heavier paths: `advanced_model` only; L4 expansion: `full_model` |
+| **Offline inference e2e** | `tests/e2e/offline_inference/` | **Module (default):** `omni_runner` + `omni_runner_handler`. **Function (isolation only):** `omni_runner_function` + `omni_runner_handler_function`. Diffusion/TTS may use `Omni(...).generate` directly | L2: `core_model` + **one of** `omni` / `tts` / `diffusion`; `@hardware_test(...)` when GPU/NPU is required |
+| **Online serving e2e** | `tests/e2e/online_serving/` | **Module (default):** `omni_server` + `openai_client`. **Function (isolation only):** `omni_server_function` + `openai_client_function`. Clients: `send_omni_request` (omni), `send_audio_speech_request` (tts), `send_diffusion_request` / `send_video_diffusion_request` / `send_images_generations_request` (diffusion) | Baseline smoke: **`core_model` + `advanced_model`**; heavier paths: `advanced_model` only; L4 expansion: `full_model` |
 | **Documentation / runnable examples** | `tests/examples/offline_inference/`, `tests/examples/online_serving/` | **Offline docs (preferred):** extract Python/Bash blocks from the doc README (e.g. `ReadmeSnippet.extract_readme_snippets`), `pytest.mark.parametrize` each snippet, run via `example_runner.run` with a stable `output_subfolder`. **Online docs:** copy client/request scripts into dedicated tests and keep them in sync with the doc page. | Usually **L4**: `advanced_model`, often `example` plus hardware marks matching the nightly docs-example job (see `.buildkite/cuda/test-nightly.yml`). Full conventions: [docs/contributing/ci/test_examples/l4_doc_example_tests.inc.md](../../../docs/contributing/ci/test_examples/l4_doc_example_tests.inc.md) (introduced in [PR #1910](https://github.com/vllm-project/vllm-omni/pull/1910): naming, output directory layout, skip rules, avoid trimming `num_inference_steps` without a strong CI reason). |
 | **Performance / benchmark** | `tests/dfx/perf/tests/*.json` + `run_*_benchmark.py` | JSON or script-driven server + load config; assert explicit metrics / baselines | L4 Perf: JSON `mark` with `full_model` + `omni`/`tts`/`diffusion`; wire `test-nightly.yml` Perf steps |
 | **Invalid parameter / negative HTTP validation** | `tests/dfx/reliability/invalid_param_test/` | Live `omni_server` + low-level `send_*_http_request` with `err_code` / `err_message` | `pytest.mark.slow` + `omni` / `tts` / `diffusion` + `@hardware_marks` (`H100` or `L4`); CI in **`test-weekly.yml`** (not ready/merge/nightly) |
@@ -110,10 +110,10 @@ After choosing offline/online/docs/perf, classify the **product under test** and
 |-----------|------------------------------|----------------------------|----------------------------------------|
 | **What it is** | Multimodal LLM pipeline (thinker/talker/stages; text + vision + audio I/O) | Speech synthesis / voice models | Generative diffusion (noise → image, audio, text, or video) |
 | **Examples** | Qwen2.5-Omni, Qwen3-Omni | Qwen3-TTS, VoxCPM2, Higgs-Audio, Step-Audio2 | Qwen-Image, BAGEL, Wan2.2, HunyuanVideo |
-| **Offline runner** | `omni_runner` + `offline_client`, `generate_multimodal` | `Omni(...).generate` with deploy YAML + TTS params | `Omni(...).generate` + `OmniDiffusionSamplingParams` |
-| **Online client** | `online_client.send_omni_request` (chat completions, modalities) | `online_client.send_audio_speech_request` (`/v1/audio/speech`) | `send_diffusion_request` (chat/T2I), `send_video_diffusion_request` (`/v1/videos`, X2V), or `send_images_generations_http_request` / `send_images_edits_http_request` (DALL-E routes) |
-| **Typical assertions** | Stage outputs, text/audio keywords via `OfflineOmniClient` / response handler | WAV bytes, stream chunks, speech endpoint contract | Image/video dimensions, `final_output_type`, `assert_diffusion_response` |
-| **Deploy YAML** | Per-model deploy configs (`ci/qwen3_omni_moe.yaml`, …) | `qwen3_tts.yaml`, `voxcpm2.yaml`, … | Often default serve; parallel/offload YAML for heavy DiT |
+| **Offline runner** | `omni_runner` + `omni_runner_handler`, `generate_multimodal` | `Omni(...).generate` or stage YAML + TTS params | `Omni(...).generate` + `OmniDiffusionSamplingParams` |
+| **Online client** | `openai_client.send_omni_request` (chat completions, modalities) | `openai_client.send_audio_speech_request` (`/v1/audio/speech`) | `send_diffusion_request` (chat/T2I), `send_video_diffusion_request` (`/v1/videos`, X2V), or `send_images_generations_http_request` / `send_images_edits_http_request` (DALL-E routes) |
+| **Typical assertions** | Stage outputs, text/audio keywords via `OmniRunnerHandler` / response handler | WAV bytes, stream chunks, speech endpoint contract | Image/video dimensions, `final_output_type`, `assert_diffusion_response` |
+| **Stage / deploy YAML** | Per-model omni stage configs (`ci/qwen3_omni_moe.yaml`, …) | `qwen3_tts.yaml`, `voxcpm2.yaml`, … | Often default serve; parallel/offload YAML for heavy DiT |
 | **Nightly group** (`test-nightly.yml`) | **Omni Model Test** — `-m "full_model and omni"` | **TTS Model Test** — `-m "full_model and tts"` | **Diffusion X2I(&A&T)** *or* **Diffusion X2V** (see Step 3 table; same `diffusion` marker, different YAML group / file shard) |
 | **L4 pressure** | Expansion per modality/model as needed | Expansion + accuracy/perf in TTS group | X2I: merge feature combos per [#1832](https://github.com/vllm-project/vllm-omni/issues/1832); X2V: separate nightly group |

@@ -175,9 +175,9 @@ See **L1 unit test constraints (mocking)** below for the full do/don't list.
@pytest.mark.omni
@hardware_test(...)
@pytest.mark.parametrize("omni_runner", test_params, indirect=True)
-def test_<scenario>(omni_runner, offline_client) -> None:
+def test_<scenario>(omni_runner, omni_runner_handler) -> None:
    request_config = {"prompts": ..., "modalities": [...]}  # optional: images, videos, audios
-    offline_client.send_omni_request(request_config)
+    omni_runner_handler.send_omni_request(request_config)
 ```

 *Offline generative e2e — **Diffusion** (representative):*
@@ -187,8 +187,8 @@ def test_<scenario>(omni_runner, offline_client) -> None:
@pytest.mark.diffusion
@hardware_test(...)
@pytest.mark.parametrize("omni_runner", test_params, indirect=True)
-def test_text_to_image_001(offline_client) -> None:
-    offline_client.send_diffusion_request({"prompt": "...", "extra_body": {"num_inference_steps": 4, ...}})
+def test_text_to_image_001(omni_runner_handler) -> None:
+    omni_runner_handler.send_diffusion_request({"prompt": "...", "extra_body": {"num_inference_steps": 4, ...}})
 ```

 *Offline TTS e2e — **Qwen3-TTS** (two-stage; representative):*
@@ -198,8 +198,8 @@ def test_text_to_image_001(offline_client) -> None:
@pytest.mark.tts
@hardware_test(...)
@pytest.mark.parametrize("omni_runner", tts_server_params, indirect=True)
-def test_text_to_audio_001(omni_runner, offline_client) -> None:
-    offline_client.send_audio_speech_request({
+def test_text_to_audio_001(omni_runner, omni_runner_handler) -> None:
+    omni_runner_handler.send_audio_speech_request({
        "input": "...",
        "task_type": "Base",
        "ref_audio": REF_AUDIO_URL,
@@ -214,8 +214,8 @@ def test_text_to_audio_001(omni_runner, offline_client) -> None:
@pytest.mark.tts
@hardware_test(...)
@pytest.mark.parametrize("omni_runner", tts_server_params, indirect=True)
-def test_voice_clone_001(offline_client) -> None:
-    offline_client.send_single_stage_tts_request({
+def test_voice_clone_001(omni_runner_handler) -> None:
+    omni_runner_handler.send_single_stage_tts_request({
        "input": "...",
        "language": "en",
        "prompt_audio_path": REF_AUDIO_PATH,
@@ -231,9 +231,9 @@ def test_voice_clone_001(offline_client) -> None:
@pytest.mark.omni
@hardware_test(...)
@pytest.mark.parametrize("omni_server", test_params, indirect=True)
-def test_text_to_text_001(omni_server, online_client) -> None:
+def test_text_to_text_001(omni_server, openai_client) -> None:
    request_config = {"model": omni_server.model, "messages": ..., "modalities": ["text"]}
-    online_client.send_omni_request(request_config)
+    openai_client.send_omni_request(request_config)
 ```

 *Online serving e2e — **TTS** (representative):*
@@ -244,9 +244,9 @@ def test_text_to_text_001(omni_server, online_client) -> None:
@pytest.mark.tts
@hardware_test(...)
@pytest.mark.parametrize("omni_server", tts_server_params, indirect=True)
-def test_text_to_audio_001(omni_server, online_client) -> None:
+def test_text_to_audio_001(omni_server, openai_client) -> None:
    request_config = {"model": omni_server.model, "input": "...", "response_format": "wav", ...}
-    online_client.send_audio_speech_request(request_config)
+    openai_client.send_audio_speech_request(request_config)
 ```

 *Online serving e2e — **Diffusion** X2I (representative):*
@@ -255,8 +255,8 @@ def test_text_to_audio_001(omni_server, online_client) -> None:
@pytest.mark.core_model
@pytest.mark.diffusion
@pytest.mark.parametrize("omni_server", _get_default_case(MODEL), indirect=True)
-def test_text_to_image_001(omni_server, online_client) -> None:
-    online_client.send_diffusion_request({...})  # chat completions + extra_body
+def test_text_to_image_001(omni_server, openai_client) -> None:
+    openai_client.send_diffusion_request({...})  # chat completions + extra_body
 ```

 *Online serving e2e — **Diffusion** X2V (representative):*
@@ -264,8 +264,8 @@ def test_text_to_image_001(omni_server, online_client) -> None:
 ```python
@pytest.mark.core_model
@pytest.mark.diffusion
-def test_text_to_video_001(omni_server, online_client) -> None:
-    online_client.send_video_diffusion_request({"model": ..., "form_data": {...}})  # /v1/videos
+def test_text_to_video_001(omni_server, openai_client) -> None:
+    openai_client.send_video_diffusion_request({"model": ..., "form_data": {...}})  # /v1/videos
 ```

 *Documentation example tests:* follow the **Preferred Test Strategy** in [l4_doc_example_tests.inc.md](../../../docs/contributing/ci/test_examples/l4_doc_example_tests.inc.md): dynamic extraction for offline READMEs; explicit copied client code for online pages until extraction is justified; use the documented **naming**, **output directory** (page folder + case id), and **skipping** rules (e.g. Gradio-only scripts).
@@ -274,7 +274,6 @@ def test_text_to_video_001(omni_server, online_client) -> None:

 **3. Cross-cutting rules**

- New `.py` files need the Omni SPDX header (`Copyright contributors to the vLLM-Omni project`, not `vLLM project`). `tests/` may keep stdlib `re`/`base64`; pickle is still banned unless the file is already on the pickle allowlist. Every collected `tests/**/test_*.py` needs a CI **level** mark and a **hardware** mark/helper (`check-test-ci-coverage` runs locally; GHA skips it). Do not grow `allowed_files` to land a test. Policy: [docs/contributing/README.md](../../../docs/contributing/README.md#linting).
 - Reuse existing fixtures for the chosen scenario; do not mix “online client” assumptions into offline `OmniRunner` tests without a clear reason.
 - Avoid external network dependency in assertions unless the scenario is explicitly “online serving” or doc examples that require a model hub (then align with CI secrets/cache).
 - Keep **one test function = one intent** (one modality combo, one endpoint contract, or one acceleration combo).
@@ -324,21 +323,21 @@ vLLM-Omni e2e tests start a real **OmniServer** (online) or **OmniRunner** (offl

 | Scope | Online fixtures | Offline fixtures | When to use |
 |-------|-----------------|------------------|-------------|
-| **Module** (default) | `omni_server` → `online_client` | `omni_runner` → `offline_client` | **Default for L2/L3/L4 expansion** — amortize model/server init across `test_*` in the same module. Same `OmniServerParams` / runner config can be reused by multiple tests. |
-| **Function** | `omni_server_function` → `online_client_function` | `omni_runner_function` → `offline_client_function` | **Only when required** — each `test_*` must get a **clean** server/runner (no shared engine/GPU state). Typical: `tests/dfx/reliability/`, sleep/wakeup, crash/restart, tests that mutate global server state. |
+| **Module** (default) | `omni_server` → `openai_client` | `omni_runner` → `omni_runner_handler` | **Default for L2/L3/L4 expansion** — amortize model/server init across `test_*` in the same module. Same `OmniServerParams` / runner config can be reused by multiple tests. |
+| **Function** | `omni_server_function` → `openai_client_function` | `omni_runner_function` → `omni_runner_handler_function` | **Only when required** — each `test_*` must get a **clean** server/runner (no shared engine/GPU state). Typical: `tests/dfx/reliability/`, sleep/wakeup, crash/restart, tests that mutate global server state. |

 **Rules:**

 1. **Default to module scope** (`omni_server` / `omni_runner`) unless the scenario **explicitly** needs a fresh instance per test function.
-2. **Indirect parametrize name must match the fixture name**: `@pytest.mark.parametrize("omni_server", ...)` with `omni_server` + `online_client`; `@pytest.mark.parametrize("omni_server_function", ...)` with `omni_server_function` + `online_client_function`. Do not mix module fixture with function client (or vice versa).
+2. **Indirect parametrize name must match the fixture name**: `@pytest.mark.parametrize("omni_server", ...)` with `omni_server` + `openai_client`; `@pytest.mark.parametrize("omni_server_function", ...)` with `omni_server_function` + `openai_client_function`. Do not mix module fixture with function client (or vice versa).
 3. Different `OmniServerParams` per `test_*` (e.g. default vs `--enable-cpu-offload`) is still OK with **module** `omni_server` — pytest parametrizes per test node; only switch to `_function` when isolation between tests matters, not merely because `server_args` differ.
 4. One `test_*` with **many** server configs (expansion matrix) → single function + `@pytest.mark.parametrize("omni_server", [...], indirect=True)` + module `omni_server` (see in-tree `test_qwen_image_expansion.py`).

 ```python
 # Default — module-scoped server (L4 expansion)
@pytest.mark.parametrize("omni_server", [pytest.param(OmniServerParams(model=MODEL), marks=H100)], indirect=True)
-def test_foo_images_generations_default_1024(omni_server, online_client) -> None:
-    online_client.send_images_generations_request({...})
+def test_foo_images_generations_default_1024(omni_server, openai_client) -> None:
+    openai_client.send_images_generations_request({...})

 # Function-scoped — reliability / per-test clean state only
@pytest.mark.parametrize(
@@ -346,9 +345,9 @@ def test_foo_images_generations_default_1024(omni_server, online_client) -> None
    [pytest.param(OmniServerParams(model=MODEL), marks=H100)],
    indirect=True,
 )
-def test_foo_sleep_wakeup_cycle(omni_server_function, online_client_function) -> None:
-    online_client_function.send_omni_sleep_http_request({...})
-    online_client_function.send_omni_wakeup_http_request({...})
+def test_foo_sleep_wakeup_cycle(omni_server_function, openai_client_function) -> None:
+    openai_client_function.send_omni_sleep_http_request({...})
+    openai_client_function.send_omni_wakeup_http_request({...})
 ```

 #### Runtime send helpers — online **and** offline (`tests/helpers/runtime.py`)
@@ -357,19 +356,19 @@ def test_foo_sleep_wakeup_cycle(omni_server_function, online_client_function) ->

 | Principle | Action |
 |-----------|--------|
-| **Reuse first** | Grep `runtime.py` for an existing **`send_*_request`** on `OnlineOmniClient` (online) or `OfflineOmniClient` (offline) that matches the endpoint / pipeline shape. |
+| **Reuse first** | Grep `runtime.py` for an existing **`send_*_request`** on `OpenAIClientHandler` (online) or `OmniRunnerHandler` (offline) that matches the endpoint / pipeline shape. |
 | **Extend when close** | If an existing `send_*_request` almost fits (e.g. missing one optional field), extend it in `runtime.py` — do not fork logic in the test file. |
 | **Add when missing** | No suitable helper → add **`send_<feature>_request`** (high-level: call + general `assert_*`) or **`send_<route>_<verb>_http_request`** (low-level HTTP for negative/dfx) in **`runtime.py` first**, then call it from tests. |
 | **Test module owns payload only** | In `test_*.py`: `MODEL`, deploy path, vendored media, `get_prompt()`, and inline **`request_config` dicts** only. **No** `omni.generate(...)`, raw `requests.post`, OpenAI SDK calls, or `_collect_audio()` / `_process_output()` in e2e tests. |

-**Online** (`online_client` from `omni_server`): `OnlineOmniClient.send_*_request`.
+**Online** (`openai_client` from `omni_server`): `OpenAIClientHandler.send_*_request`.

-**Offline** (`offline_client` from `omni_runner`): `OfflineOmniClient.send_*_request`.
+**Offline** (`omni_runner_handler` from `omni_runner`): `OmniRunnerHandler.send_*_request`.

 | Do | Don't |
 |----|-------|
-| Online: `online_client.send_omni_request`, `send_diffusion_request`, `send_audio_speech_request`, `send_video_diffusion_request`, `send_images_generations_request`, … | `requests.post(f"{base_url}/v1/...", json=…)` or `client.chat.completions.create(...)` inside a test |
-| Offline: `offline_client.send_omni_request`, `send_diffusion_request`, `send_audio_speech_request`, `send_single_stage_tts_request`, `send_single_stage_tts_batch_request`, … | `omni_runner.omni.generate(...)` + hand-rolled tensor/WAV extraction in `test_*.py` |
+| Online: `openai_client.send_omni_request`, `send_diffusion_request`, `send_audio_speech_request`, `send_video_diffusion_request`, `send_images_generations_request`, … | `requests.post(f"{base_url}/v1/...", json=…)` or `client.chat.completions.create(...)` inside a test |
+| Offline: `omni_runner_handler.send_omni_request`, `send_diffusion_request`, `send_audio_speech_request`, `send_single_stage_tts_request`, `send_single_stage_tts_batch_request`, … | `omni_runner.omni.generate(...)` + hand-rolled tensor/WAV extraction in `test_*.py` |
 | Add missing `send_*` to **`runtime.py`** first; bundle general `assert_*` inside the send helper | A one-off `def _post_*` / `def _collect_audio` at the bottom of a test module |
 | Mirror naming/style of neighboring `send_*` (docstring, `request_config` dict, optional `run_level`, `err_code` / `err_message` for negative cases) | Different parameter shapes per test file for the same endpoint |

@@ -392,7 +391,7 @@ def test_foo_sleep_wakeup_cycle(omni_server_function, online_client_function) ->

 Changing `request_config` fields (`size`, `n`, `seed`, server flags) is **not** special validation — the general `assert_*` should read those from `request_config` inside `send_*`.

-**`send_*` ↔ `assert_*` pairing (online `OnlineOmniClient`):**
+**`send_*` ↔ `assert_*` pairing (online `OpenAIClientHandler`):**

 | High-level `send_*` (prefer in L2+ e2e) | Assert already invoked inside `runtime.py` | Low-level HTTP-only sibling |
 |----------------------------------------|--------------------------------------------|-----------------------------|
@@ -405,7 +404,7 @@ Changing `request_config` fields (`size`, `n`, `seed`, server flags) is **not**

 **Rule:** Tests call high-level `send_*_request` for the general contract. **Never** call the same bundled `assert_*` again. Call an extra `assert_*` in the test **only** for special, case-specific validation.

-**Common `OnlineOmniClient` entry points** (non-exhaustive — grep `runtime.py` before adding):
+**Common `OpenAIClientHandler` entry points** (non-exhaustive — grep `runtime.py` before adding):

 | Area | High-level (SDK + assert) | Low-level HTTP (`*_http_request`) |
 |------|---------------------------|-----------------------------------|
@@ -416,7 +415,7 @@ Changing `request_config` fields (`size`, `n`, `seed`, server flags) is **not**
 | TTS (online) | `send_audio_speech_request` | `send_audio_speech_http_request`, `send_audio_generate_http_request`, … |
 | Ops / meta | — | `send_health_http_request`, `send_models_http_request`, `send_omni_sleep_http_request`, … |

-**Common `OfflineOmniClient` entry points** (offline — grep `runtime.py` before adding):
+**Common `OmniRunnerHandler` entry points** (offline — grep `runtime.py` before adding):

 | Area | High-level (`send_*_request` + assert) | Notes |
 |------|----------------------------------------|-------|
@@ -426,7 +425,7 @@ Changing `request_config` fields (`size`, `n`, `seed`, server flags) is **not**
 | Single-stage TTS (Coqui XTTS, MOSS-TTS-Nano, …) | `send_single_stage_tts_request`, `send_single_stage_tts_batch_request` | `prompt` + `additional_information` + `omni.generate` — **do not** duplicate in tests |
 | New model family | **Add** `send_<family>_request` here first | Then call from `tests/e2e/offline_inference/test_*.py` |

-L1 tests under `tests/entrypoints/` may use **FastAPI `TestClient`** or direct handler calls with mocks; they do **not** need `OnlineOmniClient` / `OfflineOmniClient`. **L2+ online and offline e2e** must use `runtime.py` `send_*` helpers.
+L1 tests under `tests/entrypoints/` may use **FastAPI `TestClient`** or direct handler calls with mocks; they do **not** need `OpenAIClientHandler` / `OmniRunnerHandler`. **L2+ online and offline e2e** must use `runtime.py` `send_*` helpers.

 #### Invalid parameter validation (`tests/dfx/reliability/invalid_param_test/`)

@@ -452,7 +451,7 @@ When the user asks for **invalid parameter validation**, **invalid request bodie
 | **Module markers** | `pytestmark = [pytest.mark.slow, pytest.mark.<omni or tts or diffusion>]` |
 | **Server fixture** | `_PARAMS` / `_QWEN3_TTS_SPEECH`-style list of `pytest.param(OmniServerParams(...), id="...", marks=hardware_marks(...))`; `@pytest.mark.parametrize("omni_server", _PARAMS, indirect=True)` |
 | **Hardware** | `hardware_marks(res={"cuda": "H100"})` for heavy diffusion/omni/video; `hardware_marks(res={"cuda": "L4"})` for smaller TTS models (must match weekly `-m "slow and L4"` step) |
-| **HTTP client** | **Low-level** `online_client.send_*_http_request({..., "err_code": 400, "err_message": (...)} )` — **not** `send_*_request` (success path) |
+| **HTTP client** | **Low-level** `openai_client.send_*_http_request({..., "err_code": 400, "err_message": (...)} )` — **not** `send_*_request` (success path) |
 | **Case shape** | Prefer **one `test_*` per route family** + `@pytest.mark.parametrize("body_spec, err_message", [...])` with stable `id=` per case; or dedicated `test_<route>_malformed_json` when not parametrized |
 | **Body helpers** | `_minimal_<endpoint>_json(omni_server)` / `_minimal_*_form_data()`; merge overrides with `body.update(body_spec)` |
 | **Known gaps** | `pytest.mark.skip(reason="…#3649")` as `_SKIP_ISSUE_3649` when server validation is not yet strict (mirror neighboring cases) |
@@ -485,13 +484,13 @@ When the user asks for **invalid parameter validation**, **invalid request bodie
@pytest.mark.parametrize("omni_server", _PARAMS, indirect=True)
 def test_images_generations_invalid_requests(
    omni_server: OmniServer,
-    online_client: OnlineOmniClient,
+    openai_client: OpenAIClientHandler,
    body_spec: dict[str, object],
    err_message: str | tuple[str, ...],
 ) -> None:
    body = _minimal_images_gen_json(omni_server)
    body.update(body_spec)
-    online_client.send_images_generations_http_request(
+    openai_client.send_images_generations_http_request(
        {"json": body, "timeout": 300, "err_code": 400, "err_message": err_message}
    )
 ```
@@ -542,18 +541,18 @@ def send_images_generations_request(self, request_config: dict[str, Any], ...) -

 # tests/e2e/.../test_foo_expansion.py — one case per test_* (no case_id branching)
@pytest.mark.parametrize("omni_server", [pytest.param(OmniServerParams(model=MODEL), marks=SINGLE_L4)], indirect=True)
-def test_foo_images_generations_default_1024(omni_server, online_client) -> None:
-    online_client.send_images_generations_request({"json": body, "timeout": 300})
+def test_foo_images_generations_default_1024(omni_server, openai_client) -> None:
+    openai_client.send_images_generations_request({"json": body, "timeout": 300})

@pytest.mark.parametrize("omni_server", [pytest.param(OmniServerParams(model=MODEL), marks=SINGLE_L4)], indirect=True)
-def test_foo_images_generations_sizes_256_512_1024(omni_server, online_client) -> None:
+def test_foo_images_generations_sizes_256_512_1024(omni_server, openai_client) -> None:
    for size in ("256x256", "512x512", "1024x1024"):
-        online_client.send_images_generations_request({"json": {**body, "size": size}, "timeout": 300})
+        openai_client.send_images_generations_request({"json": {**body, "size": size}, "timeout": 300})

 # chat diffusion — separate test; send_diffusion_request bundles assert_diffusion_response
@pytest.mark.parametrize("omni_server", [pytest.param(OmniServerParams(model=MODEL), marks=SINGLE_L4)], indirect=True)
-def test_foo_chat_completions_t2i_fallback(omni_server, online_client) -> None:
-    online_client.send_diffusion_request({...})
+def test_foo_chat_completions_t2i_fallback(omni_server, openai_client) -> None:
+    openai_client.send_diffusion_request({...})
 ```

 L1 tests under `tests/entrypoints/` may keep **minimal** asserts next to the handler under test when validating a single branch; still prefer `assertions.py` when the same JSON/media check appears in more than one file or level (e.g. L1 protocol test + L4 e2e).
@@ -279,7 +279,7 @@ When adding or modifying tests, do not stop at “where the file lives” — al
 4. **API client + assert placement**: **General** validation → implement in `assertions.py`, call **inside** `send_*_request` in `runtime.py`; tests call **`send_*_request` only**. **Special** case validation → `assert_*` in `assertions.py`, called **in the test** after `send_*_request`. Low-level `send_*_http_request` is for negative/dfx tests (`err_code`), not ordinary L2+ success e2e.
 5. **Shared assertions**: logic in **`tests/helpers/assertions.py`**; general checks inside `send_*_request`; special checks only in the test. No `_assert_*` in `test_*.py`.
 6. **One case → one `test_*`**: function name reflects what is validated; no `if case_id == ...` mega-test merging multiple scenarios.
-7. **Fixture scope**: default **`omni_server` + `online_client`** / **`omni_runner` + `offline_client`** (module). Use **`omni_server_function` + `online_client_function`** / **`omni_runner_function` + `offline_client_function`** only when each `test_*` must spawn a fresh instance. Parametrize name must match fixture (`omni_server` vs `omni_server_function`).
+7. **Fixture scope**: default **`omni_server` + `openai_client`** / **`omni_runner` + `omni_runner_handler`** (module). Use **`omni_server_function` + `openai_client_function`** / **`omni_runner_function` + `omni_runner_handler_function`** only when each `test_*` must spawn a fresh instance. Parametrize name must match fixture (`omni_server` vs `omni_server_function`).
 8. **Type marker**: `omni`, `tts`, or `diffusion` on every model e2e module.
 9. **Diffusion L4 Function**: wire `*_expansion.py` into **X2I(&A&T)** or **X2V** **Function Test** in **`test-nightly.yml` only** — do not add `test-merge.yml` unless the user also requested L3.
 10. **Diffusion L4 Perf** (only when requested): add `tests/dfx/perf/tests/test_<slug>_vllm_omni.json` + **Perf Test · &lt;Model&gt;** step (artifact upload); not part of “L4 functional cases” by default.
@@ -79,6 +79,8 @@
 /vllm_omni/model_executor/models/ @tzhouam @gcanlin @Sy0307 @amy-why-3459 @linyueqian
 /vllm_omni/model_extras/ @tzhouam @gcanlin @princepride
 /vllm_omni/plugins/ @gcanlin @tjtanaa @xuechendi
+# Config override within model_executor — docs/design/module/vllm_omni_config.md
+/vllm_omni/model_executor/stage_configs/ @lishunyang12 @alex-jw-brooks

 # Execution platforms (hardware backends) — docs/design/module/execution_platforms.md
 /vllm_omni/platforms/ @gcanlin @tjtanaa @xuechendi
@@ -83,7 +83,7 @@ body:

      omni = Omni(
          model="Qwen/Qwen-Image",
-          deploy_config="/path/to/deploy_config.yaml",
+          stage_configs_path="/path/to/stage_configs.yaml",
      )

      prompts = [{"prompt": "A scenic watercolor painting of a lighthouse at sunset"}]
@@ -45,7 +45,7 @@ pull_request_rules:
        > # For mypy (substitute "3.10" with the failing version if needed)
        > pre-commit run --hook-stage manual mypy-3.10
        > # For markdownlint
-        > pre-commit run markdownlint-cli2
+        > pre-commit run --hook-stage manual markdownlint
        > ```
        > </details>

@@ -24,7 +24,9 @@ jobs:
          python-version: "3.12"
          cache: 'pip'
      - uses: pre-commit/action@v3.0.1
-        # Don't run historical-debt hooks against the whole tree in CI yet.
-        # They still run locally on changed files.
+        # Don't run the pytest mark check against everything in the CI
+        # for now since a lot of files are still missing them. This check
+        # is used to help contributors remember to add the marks when they
+        # commit.
        env:
-          SKIP: check-test-ci-coverage,markdownlint-cli2,shellcheck,check-spdx-header,mypy-3.10
+          SKIP: check-test-ci-coverage
@@ -242,9 +242,9 @@ data/
 datasets/
 *.csv
 *.json
-!recipes/cosmos3/negative_prompt.json
 !tests/dfx/perf/tests/*.json
 !apps/ComfyUI-vLLM-Omni/example_workflows/*.json
+!tests/assets/soulxsinger/*.json
 *.jsonl
 *.parquet

@@ -278,6 +278,3 @@ tests/.ci_generated/

 # Local Lance precision-matching dump scripts (not part of the repo)
 lance_compare/
-
-# Linting binaries downloaded by local pre-commit hooks
-shellcheck*/
@@ -1,17 +0,0 @@
-# Keep these rules aligned with vLLM so MkDocs Material syntax is tolerated.
-MD007:
-  indent: 4
-MD013: false
-# GitHub READMEs start with a centered logo, not an H1.
-MD041: false
-MD024:
-  siblings_only: true
-MD025:
-  # Allow front matter title to be different from the first heading in the document.
-  front_matter_title: ""
-MD031:
-  list_items: false
-MD033: false
-MD046: false
-MD052: false
-MD059: false
@@ -24,7 +24,7 @@ repos:
    - id: ruff-format

  - repo: https://github.com/crate-ci/typos
-    rev: v1.49.0
+    rev: typos-dict-v0.13.13
    hooks:
      - id: typos
        # only for staged files
@@ -38,19 +38,7 @@ repos:
      - id: actionlint
        files: ^\.github/workflows/.*\.ya?ml$

-  - repo: https://github.com/DavidAnson/markdownlint-cli2
-    rev: v0.23.2
-    hooks:
-      - id: markdownlint-cli2
-        language_version: lts
-        args: [--fix]
-        files: (^docs/|^recipes/|(^|/)README\.md$|^CONTRIBUTING\.md$)
-        # Agent skill docs and CLAUDE.md are not user-facing docs/READMEs.
-        exclude: (^|/)CLAUDE\.md$|^\.claude/|^\.cursor/

-  # Keep `local` last so `suggestion` stays the final hook. Autofix repos
-  # (ruff, typos, markdownlint, trailing-whitespace, etc.) must run first;
-  # otherwise their "files were modified" output displaces the SKIP tip.
  - repo: local
    hooks:
    - id: signoff-commit
@@ -66,45 +54,6 @@ repos:
      verbose: true
      stages: [commit-msg]

-    # TODO: Use https://github.com/pre-commit/mirrors-mypy when mypy setup
-    # is less awkward. Local wrapper groups files so follow_imports=skip on
-    # tests does not leak into library code.
-    # mypy-3.10 runs on git commit (changed files). CI SKIPs it because
-    # --all-files is not clean yet. Extra versions are manual-stage only
-    # (not in default `pre-commit run --all-files`):
-    #   pre-commit run --hook-stage manual mypy-3.12
-    - id: mypy-3.10
-      name: Run mypy for Python 3.10
-      entry: python tools/pre_commit/mypy.py "3.10"
-      <<: &mypy_common
-        language: python
-        types_or: [python, pyi]
-        require_serial: true
-        additional_dependencies:
-          - mypy==1.11.1
-          - regex
-          - types-cachetools
-          - types-setuptools
-          - types-PyYAML
-          - types-requests
-          - types-torch
-          - pydantic
-    - id: mypy-3.11
-      name: Run mypy for Python 3.11
-      entry: python tools/pre_commit/mypy.py "3.11"
-      <<: *mypy_common
-      stages: [manual]
-    - id: mypy-3.12
-      name: Run mypy for Python 3.12
-      entry: python tools/pre_commit/mypy.py "3.12"
-      <<: *mypy_common
-      stages: [manual]
-    - id: mypy-3.13
-      name: Run mypy for Python 3.13
-      entry: python tools/pre_commit/mypy.py "3.13"
-      <<: *mypy_common
-      stages: [manual]
-
    - id: check-test-ci-coverage
      name: Ensure test files have pytestmarks
      entry: python tools/pre_commit/check_test_marks.py
@@ -117,50 +66,12 @@ repos:
      entry: python tools/pre_commit/check_tts_adapter.py
      language: python
      pass_filenames: false
-      files: ^(vllm_omni/entrypoints/openai/serving_speech\.py|tools/pre_commit/check_tts_adapter\.py)$
+      files: ^(vllm_omni/entrypoints/openai/(serving_speech\.py|tts_adapters/__init__\.py)|tools/pre_commit/check_tts_adapter\.py)$
      # The budget-is-now-slack reminder is printed on a PASSING run, and
      # pre-commit hides output from passing hooks unless the hook is verbose.
      verbose: true

-    - id: shellcheck
-      name: Lint shell scripts
-      # language: script breaks on Windows (shebang path loses slashes).
-      # Invoke the vLLM-style wrapper with bash so Linux CI and Win/Git Bash work.
-      entry: bash
-      args: [tools/pre_commit/shellcheck.sh]
-      language: system
-      types: [shell]
-
-    - id: check-spdx-header
-      name: Check SPDX headers
-      entry: python tools/pre_commit/check_spdx_header.py
-      language: python
-      types_or: [python, pyi, rust, proto, shell]
-      files: \.(py|pyi|rs|proto|sh)$
-
-    - id: check-forbidden-imports
-      name: Check forbidden imports
-      entry: python tools/pre_commit/check_forbidden_imports.py
-      language: python
-      types: [python]
-      additional_dependencies: [regex]
-
-    - id: check-torch-cuda-call
-      name: Prevent new torch.cuda API calls
-      entry: python tools/pre_commit/check_torch_cuda.py
-      language: python
-      types: [python]
-      additional_dependencies: [regex]
-
-    - id: check-buildkite
-      name: Validate Buildkite Pipelines
-      entry: python tools/pre_commit/check_buildkite.py
-      language: python
-      files: ^\.buildkite/.*\.ya?ml$
-      additional_dependencies: [pyyaml, check-jsonschema==0.38.0]
-
-    # Keep `suggestion` as the final hook. Run after autofix hooks so the
-    # bypass/SKIP tip is not displaced.
+    # Keep `suggestion` last
    - id: suggestion
      name: Suggestion
      entry: bash -c 'echo "To bypass all the pre-commit hooks, add --no-verify to git commit. To skip a specific hook, prefix the commit command with SKIP=<hook-id>."'
@@ -168,3 +79,10 @@ repos:
      verbose: true
      pass_filenames: false
    # Insert new entries above the `suggestion` entry
+
+    - id: check-pickle-imports
+      name: Prevent new pickle/cloudpickle imports
+      entry: python tools/pre_commit/check_pickle_imports.py
+      language: python
+      types: [python]
+      additional_dependencies: [regex]
@@ -1,11 +1,5 @@
 # Contributing to vLLM-Omni

-You may find information about contributing to vLLM-Omni on [Contributing](https://vllm-omni.readthedocs.io/en/latest/contributing/).
-
-Local `pre-commit` gates (SPDX, forbidden imports, `torch.cuda`, shellcheck,
-mypy, test marks, TTS adapter ratchet, markdownlint, Buildkite schema, and
-how to extend allowlists) are documented in the
-[Linting](https://vllm-omni.readthedocs.io/en/latest/contributing/#linting)
-section of that guide.
+You may find information about contributing to vLLM-Omni on [Contributing](https://vllm-omni.readthedocs.io/en/latest/contributing/)

 Before submitting a PR, run the [precheck-pr skill](https://github.com/vllm-project/vllm-omni/blob/main/.claude/skills/precheck-pr/SKILL.md) with the code agent for a self-check against project conventions.
@@ -12,10 +12,10 @@ Easy, fast, and cheap omni-modality model serving for everyone
 | <a href="https://vllm-omni.readthedocs.io/en/latest/"><b>Documentation</b></a> | <a href="https://deepwiki.com/vllm-project/vllm-omni"><b>DeepWiki</b></a> | <a href="https://discuss.vllm.ai"><b>User Forum</b></a> | <a href="https://slack.vllm.ai"><b>Developer Slack</b></a> | <a href="docs/assets/WeChat.jpg"><b>WeChat</b></a> | <a href="https://arxiv.org/abs/2602.02204"><b>Paper</b></a> | <a href="https://docs.google.com/presentation/d/1aPj0OGl_-ZVoib-Qne5dGDAlrRFB-PdHl6E-EE99g8E/edit?usp=sharing"><b>Slides</b></a> |
 </p>

+
 ---

 *Latest News* 🔥
-
 - [2026/08] [VeRL-Omni](https://github.com/verl-project/verl-omni) `v0.2.0` is released: faster diffusion RL powered by vLLM-Omni (request-level/step-wise batching with FA3), rebuilt Qwen3-Omni multimodal training (DPO & GSPO), plus LTX-2.3, Qwen-Image-Edit support and more. See the [release notes](https://github.com/verl-project/verl-omni/releases/tag/v0.2.0).
 - [2026/08] We released [0.26.0](https://github.com/vllm-project/vllm-omni/releases/tag/v0.26.0) - aligned with the vLLM 0.26 release line, featuring [MiniMax H3](recipes/MiniMaxAI/MiniMax-H3.md) joint video/audio generation, an experimental full-duplex realtime runtime for [MiniCPM-o 4.5](recipes/OpenBMB/MiniCPM-o-4_5.md), distributed layerwise diffusion offload, and broader model, hardware, streaming, TTS, and quantization support.
 - [2026/07] We released [0.24.0](https://github.com/vllm-project/vllm-omni/releases/tag/v0.24.0) - aligned with the vLLM 0.24 release line, expanding production-ready coverage across TTS, speech, diffusion, image/video generation, and robot-policy serving, with major Omni stage runtime refactoring, diffusion request-level batching, async output materialization, quantization/cache/memory improvements, and broad CUDA/ROCm/XPU/NPU support.
@@ -89,18 +89,11 @@ If you use vLLM-Omni for your research, please cite our [paper](https://arxiv.or
 ```

 ## Join the Community
-
 Feel free to ask questions, provide feedbacks and discuss with fellow users of vLLM-Omni in `#sig-omni` slack channel at [slack.vllm.ai](https://slack.vllm.ai) or vLLM user forum at [discuss.vllm.ai](https://discuss.vllm.ai).

 ## Star History

-<a href="https://www.star-history.com/?repos=vllm-project%2Fvllm-omni&type=date&legend=top-left">
-  <picture>
-    <source media="(prefers-color-scheme: dark)" srcset="https://api.star-history.com/chart?repos=vllm-project/vllm-omni&type=date&theme=dark&legend=top-left&sealed_token=ExgLDZJoQEg27Zfhhut2LqN0GYO6Fw2PWLwPE6JYBUp2BgM3hmsYlwaIVopnUEfbRXidQ4nisumrTdKYydiKhy1SZXipw47qY2_tiUDhCpsPXeXtPuEVKVzBwKs3pw0tiHsJgtSfwXx5yjHXck0Y2SblzFWeJYCkTe1WLGTbUAOIETjXXQJjyCGZvKz5" />
-    <source media="(prefers-color-scheme: light)" srcset="https://api.star-history.com/chart?repos=vllm-project/vllm-omni&type=date&legend=top-left&sealed_token=ExgLDZJoQEg27Zfhhut2LqN0GYO6Fw2PWLwPE6JYBUp2BgM3hmsYlwaIVopnUEfbRXidQ4nisumrTdKYydiKhy1SZXipw47qY2_tiUDhCpsPXeXtPuEVKVzBwKs3pw0tiHsJgtSfwXx5yjHXck0Y2SblzFWeJYCkTe1WLGTbUAOIETjXXQJjyCGZvKz5" />
-    <img alt="Star History Chart" src="https://api.star-history.com/chart?repos=vllm-project/vllm-omni&type=date&legend=top-left&sealed_token=ExgLDZJoQEg27Zfhhut2LqN0GYO6Fw2PWLwPE6JYBUp2BgM3hmsYlwaIVopnUEfbRXidQ4nisumrTdKYydiKhy1SZXipw47qY2_tiUDhCpsPXeXtPuEVKVzBwKs3pw0tiHsJgtSfwXx5yjHXck0Y2SblzFWeJYCkTe1WLGTbUAOIETjXXQJjyCGZvKz5" />
-  </picture>
-</a>
+[![Star History Chart](https://api.star-history.com/svg?repos=vllm-project/vllm-omni&type=date&legend=top-left)](https://www.star-history.com/#vllm-project/vllm-omni&type=date&legend=top-left)

 ## License

@@ -18,8 +18,8 @@ vllm serve Qwen/Qwen3-TTS-12Hz-1.7B-Base --omni --port 8000
 ```

 The server auto-loads its Deploy YAML from `vllm_omni/deploy/qwen3_tts.yaml`
-(Pipeline + Deploy schema introduced in #2383). No explicit `--deploy-config`
-flag is needed for a registered model.
+(Pipeline + Deploy schema introduced in #2383). No `--stage-configs-path` or
+`--deploy-config` flag is needed for any registered model.

 ### 2. Run the benchmark (`vllm bench serve --omni`)

@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: Apache-2.0
-# SPDX-FileCopyrightText: Copyright contributors to the vLLM-Omni project
+# SPDX-FileCopyrightText: Copyright contributors to the vLLM project

 # ruff: noqa
 # code borrowed from https://github.com/pytorch/pytorch/blob/main/torch/utils/collect_env.py
@@ -494,16 +494,6 @@ def is_xnnpack_available():


 def get_env_vars():
-    try:
-        from vllm_omni.config.environment_variable_inventory import ENVIRONMENT_VARIABLE_INVENTORY
-    except Exception:
-        # Keep environment collection usable when an incomplete/broken Omni
-        # installation is the reason the user is running this diagnostic.
-        # Importing an Omni submodule executes package initialization, which
-        # may fail with RuntimeError, AssertionError, or OSError as well as
-        # ImportError when vLLM or the accelerator stack is broken.
-        ENVIRONMENT_VARIABLE_INVENTORY = {}
-
    env_vars = ""
    secret_terms = ("secret", "token", "api", "access", "password")
    report_prefix = (
@@ -517,17 +507,12 @@ def get_env_vars():
        "MKL_",
        "NVIDIA",
    )
-    for k, v in sorted(os.environ.items()):
-        omni_classification = ENVIRONMENT_VARIABLE_INVENTORY.get(k)
-        if (omni_classification is not None and omni_classification.redact_value) or any(
-            term in k.lower() for term in secret_terms
-        ):
+    for k, v in os.environ.items():
+        if any(term in k.lower() for term in secret_terms):
            continue
-        if (
-            k in environment_variables
-            or (omni_classification is not None and omni_classification.is_public_omni)
-            or k.startswith(report_prefix)
-        ):
+        if k in environment_variables:
+            env_vars = env_vars + "{}={}".format(k, v) + "\n"
+        if k.startswith(report_prefix):
            env_vars = env_vars + "{}={}".format(k, v) + "\n"

    return env_vars
@@ -43,7 +43,6 @@ nav:
    - Overview: features/README.md
    - Runtime and Stage Execution:
      - Execution Modes and Streaming: user_guide/diffusion/execution_modes.md
-      - Prefill-Decode Disaggregation (experimental): features/pd_disaggregation.md
      - Sleep Mode: features/sleep_mode.md
    - Quantization:
      - Overview: user_guide/quantization/overview.md
@@ -113,7 +112,6 @@ nav:
    - Feature Design:
      - Runtime and Stage Execution:
        - Disaggregated Inference: design/feature/disaggregated_inference.md
-        - Host Weight Runtime: design/feature/host_weight_runtime.md
        - Async Chunk: design/feature/async_chunk.md
        - Async Diffusion Output: design/feature/async_diffusion_output.md
        - Async Omni Output Materialization: design/feature/omni_async_output_materialization.md
@@ -170,7 +168,6 @@ nav:
        - Offloader: design/module/diffusion/offloader.md
      - Execution Platforms: design/module/execution_platforms.md
      - Cache Management: design/module/cache_management.md
-      - Host Weight Runtime: design/module/host_weight_runtime.md
      - Quantization: design/module/quantization.md
      - Observability: design/module/observability.md
      - Profiling: design/module/profiling.md
@@ -114,6 +114,10 @@ Configuration classes.
 - [vllm_omni.model_executor.models.qwen3_tts.tokenizer_25hz.configuration_qwen3_tts_tokenizer_v1.Qwen3TTSTokenizerV1DecoderDiTConfig][]
 - [vllm_omni.model_executor.models.qwen3_tts.tokenizer_25hz.configuration_qwen3_tts_tokenizer_v1.Qwen3TTSTokenizerV1EncoderConfig][]
 - [vllm_omni.transformers_utils.configs.cosyvoice3.CosyVoice3Config][]
+- [vllm_omni.transformers_utils.configs.mammoth_moda2.Mammothmoda2Config][]
+- [vllm_omni.transformers_utils.configs.mammoth_moda2.Mammothmoda2Qwen2_5_VLConfig][]
+- [vllm_omni.transformers_utils.configs.mammoth_moda2.Mammothmoda2Qwen2_5_VLTextConfig][]
+- [vllm_omni.transformers_utils.configs.mammoth_moda2.Mammothmoda2Qwen2_5_VLVisionConfig][]
 - [vllm_omni.transformers_utils.configs.omnivoice.OmniVoiceConfig][]
 - [vllm_omni.transformers_utils.configs.voxcpm2.VoxCPM2Config][]

@@ -2,11 +2,6 @@

 The CLI for vLLM-Omni inherits from vllm with some additional arguments.

-Environment variables are process configuration rather than CLI-only options.
-See the [Environment Variables](../configuration/environment_variables.md)
-reference for ownership, precedence, evaluation time, and per-stage `env`
-scoping.
-
 ## serve

 Starts the vLLM-Omni OpenAI Compatible API server.
@@ -44,5 +39,4 @@ vllm bench serve --omni \
    --num-prompts  5
 ```

-See [vllm bench serve](./bench/serve.md) for serving benchmark arguments and
-dataset-specific examples, including OmniInteract native-duplex sessions.
+See [vllm bench serve](./bench/serve.md) for the full reference of all available arguments.
@@ -2,7 +2,7 @@
 The vllm bench command launches the vLLM-Omni benchmark to evaluate the performance of multimodal models.

 ## Notes
-vLLM-Omni registers the `openai-chat-omni`, `openai-audio-speech`, `openai-image-edits-omni`, `daily-omni`, and `openai-realtime-duplex` serving benchmark backends. It also adds the `omniinteract` dataset.
+vLLM-Omni registers the `openai-chat-omni`, `openai-audio-speech`, `openai-image-edits-omni`, and `daily-omni` serving benchmark backends.

 ## Basic Parameter Description
 You can use `vllm bench serve --omni --help=all` to get descriptions of all parameters. The commonly used parameters are described below:
@@ -10,7 +10,7 @@ You can use `vllm bench serve --omni --help=all` to get descriptions of all para
  Enable Omni (multimodal) mode, supporting multimodal inputs and outputs such as images, videos, and audio.

 - `--backend`
-  Specify the backend adapter. vLLM-Omni adds `openai-chat-omni`, `openai-audio-speech`, `openai-image-edits-omni`, `daily-omni`, and `openai-realtime-duplex` to the upstream vLLM backend choices.
+  Specify the backend adapter. vLLM-Omni adds `openai-chat-omni`, `openai-audio-speech`, `openai-image-edits-omni`, and `daily-omni` to the upstream vLLM backend choices.

 - `--model`
  The model identifier to load, filled according to the models supported by vLLM-Omni.
@@ -19,7 +19,7 @@ You can use `vllm bench serve --omni --help=all` to get descriptions of all para
  The API endpoint exposed externally, to which clients send their requests.

 - `--dataset-name`
-  The name of the dataset used; random-mm indicates generating random multimodal inputs (images, videos, audio), while `omniinteract` replays official OmniInteract videos.
+  The name of the dataset used; random-mm indicates generating random multimodal inputs (images, videos, audio).

 - `--num-prompts`
  The total number of requests to send, an integer.
@@ -269,44 +269,6 @@ We use audio generation time / audio duration to calculate RTF.

 </details>

-### OmniInteract Realtime Benchmark
-
-OmniInteract runs each video as one native-duplex WebSocket sample in the standard serving-benchmark lifecycle:
-
-```bash
-vllm bench serve --omni \
-  --backend openai-realtime-duplex \
-  --dataset-name omniinteract \
-  --dataset-path /path/to/OmniInteract \
-  --model openbmb/MiniCPM-o-4_5 \
-  --base-url http://127.0.0.1:8000 \
-  --endpoint /v1/realtime \
-  --omniinteract-ref-audio /path/to/reference.wav \
-  --omniinteract-output-dir ./omniinteract-artifacts \
-  --num-prompts 3 \
-  --num-warmups 0
-```
-
-`--dataset-path` accepts an extracted directory, `data.tar[.gz]`, or a Hugging Face dataset ID; omitting it uses
-`lucky-lance/OmniInteract`. `--num-prompts` is the total across subsets and defaults to 3 for OmniInteract; explicit `0`
-selects all and oversize values use all available cases. Reference audio is required, and OmniInteract uses the
-`/v1/realtime` endpoint.
-
-Audio is replayed as 16 kHz PCM16 in 200 ms chunks and video at 1 FPS with real-time pacing. All selected media is decoded
-before timing and remains in client memory for the run, so `--max-concurrency` does not limit media preparation memory; use
-explicit `--num-prompts 0` only when the client has enough RAM for the full dataset. Media commands are bounded by
-`--omniinteract-media-timeout-s`, and concurrency defaults to 1. Standard request-rate, warmup, result-saving, and summary
-options apply. Use `--omniinteract-require-response` only for functional E2E cases; LISTEN is a valid benchmark result.
-
-Each completed case writes `output.wav`, `wav_transcript.json`, `events.json`, `result.json`, and a final `.done` marker under
-`--omniinteract-output-dir`. The root also contains `batch_summary.json` and `official_eval_manifest.jsonl`; failed cases write
-`.failed.json`. Runs sharing one output root are serialized. Completion validates transport, response lifecycle, and artifacts,
-not answer accuracy. Transcript timestamps are serialized playback-queue times. Clipped or cancelled outputs are ineligible and
-omitted from the official manifest; `audio_clipped_bytes` records output beyond the rounded video horizon.
-
-TTFT, TTFP, and RTF start at client receipt of `response.created`. TPOT/ITL use engine stage-0 timing; ITL is emitted only when
-every token interval is present.
-
 ### Multi-Modal Benchmark

 <details class="admonition abstract" markdown="1">
@@ -4,20 +4,20 @@ This section lists the most common options for running vLLM-Omni.

 For options within a vLLM Engine, please refer to the [vLLM 0.26 configuration guide](https://docs.vllm.ai/en/v0.26.0/configuration/index.html).

-Each model defines fixed topology in a registered `PipelineConfig` and runtime
-overrides in a deploy YAML.
-
-For process-level settings shared by the CLI, deploy YAML, workers, and model
-integrations, see [Environment Variables](./environment_variables.md).
+Currently, the main options are maintained by stage configs for each model.

 For a specific example, see the [Qwen2.5-Omni deploy config](gh-file:vllm_omni/deploy/qwen2_5_omni.yaml). The matching frozen pipeline topology lives at [vllm_omni/model_executor/models/qwen2_5_omni/pipeline.py](gh-file:vllm_omni/model_executor/models/qwen2_5_omni/pipeline.py).

-For an introduction, see [Pipeline and deploy configurations](./stage_configs.md).
+For introduction, please check [Introduction for stage config](./stage_configs.md)

 ## Memory Configuration

 - **[GPU Memory Calculation and Configuration](./gpu_memory_utilization.md)** - Guide on how to calculate memory requirements and set up `gpu_memory_utilization` for optimal performance

+## Multi-Stage Recipes
+
+- **[Prefill-Decode Disaggregation](./pd_disaggregation.md)** - How to derive a PD-aware Qwen3-Omni stage config from the default config without introducing another bundled YAML
+
 ## Optimization Features

 - **[Diffusion Features Overview](../user_guide/diffusion_features.md)** - Complete overview of all diffusion model features and supported models
@@ -1,6 +1,6 @@
 # Composable parallel strategies

-In vLLM-Omni, the `composable_parallel` system layers a declarative *parallel strategy* on top of the registered pipeline and deploy config. A strategy YAML maps each pipeline stage (by its `model_stage` name) to a stack of axis declarations — one per parallelism dimension — that the engine translates into per-stage parallel sizing (`tensor_parallel_size`, `data_parallel_size`, `pipeline_parallel_size`, expert-parallel toggle, replica count) and, when relevant, an orchestrator-wide load-balancer policy.
+In vLLM-Omni, the `composable_parallel` system layers a declarative *parallel strategy* on top of the existing stage configs. A strategy YAML maps each pipeline stage (by its `model_stage` name) to a stack of axis declarations — one per parallelism dimension — that the engine translates into per-stage parallel sizing (`tensor_parallel_size`, `data_parallel_size`, `pipeline_parallel_size`, expert-parallel toggle, replica count) and, when relevant, an orchestrator-wide load-balancer policy.

 Strategies are intentionally narrow: each one only writes the axes it declares, leaving every other engine arg untouched. This makes a strategy file a small, reusable overlay you can swap independently of the deploy YAML (see `configuration/stage_configs.md`).

@@ -195,7 +195,7 @@ Because `omni_lb_policy` is read once at `AsyncOmniEngine` construction — not

 Default: no default — required for every entry under `strategies:`.

-Strategy keys MUST be `model_stage` *names* (strings), the same labels defined by [`StagePipelineConfig.model_stage`](stage_configs.md#pipeline-configuration). Integer `stage_id` values are not accepted; the resolver matches on `model_stage` exactly (`_resolve_stage` in `vllm_omni/config/composable_parallel/apply.py`).
+Strategy keys MUST be `model_stage` *names* (strings), the same labels stage configs use for `engine_args.model_stage` (see [`model_stage` in `stage_configs.md`](stage_configs.md#engine_argsmodel_stage)). Integer `stage_id` values are not accepted; the resolver matches on `model_stage` exactly (`_resolve_stage` in `vllm_omni/config/composable_parallel/apply.py`).

 ## Common pitfalls

@@ -1,236 +0,0 @@
-# Environment Variables
-
-Environment variables are process-level configuration shared by the CLI,
-deploy YAML, Python APIs, worker processes, and model integrations. They are
-therefore documented under **User Guide → Configuration**, rather than under
-CLI Reference.
-
-This page describes the public vLLM-Omni environment-variable contract on the
-`latest` documentation branch. Use the documentation for your installed
-vLLM-Omni release when behavior differs.
-
-!!! important "Public contract"
-    Only names in [Public vLLM-Omni variables](#public-vllm-omni-variables) are
-    public Omni configuration. A name found in source code is not automatically
-    supported: model-specific, benchmark, platform, and internal variables have
-    separate ownership and lifecycle rules.
-
-## Naming and implementation boundary
-
-New public variables owned by vLLM-Omni must use the `VLLM_OMNI_` prefix.
-Existing public names with older prefixes remain supported for compatibility,
-but they do not establish naming precedent for new settings. Inherited vLLM
-and third-party names retain the prefix chosen by their owning project.
-
-The source [environment-variable inventory](gh-file:vllm_omni/config/environment_variable_inventory.py)
-records ownership, migration disposition, and redaction metadata. Unlike
-`vllm.envs`, it is not an executable value resolver: existing consumers still
-own parsing, defaults, precedence, and evaluation time. The public tables below
-describe those live consumer contracts. Stable model or stage behavior should
-move to typed configuration, and request-varying behavior should move to a
-request schema instead of adding another environment variable.
-
-## Precedence and evaluation time
-
-There is no repository-wide rule that makes environment variables override (or
-lose to) every CLI, YAML, or request option. The tables below state precedence
-for each public setting. In general:
-
- request fields should control behavior that can vary per request;
- typed deploy or stage configuration should control stable model and stage
-  behavior;
- environment variables are appropriate for process launch, platform
-  integration, emergency diagnostics, and compatibility fallbacks.
-
-An environment variable can be read while a module is imported, when server or
-model configuration is constructed, when a worker is spawned, or whenever a
-property is accessed. Set import- and startup-time variables before invoking
-`vllm serve` or importing vLLM-Omni. Changing the parent shell after workers
-start does not update existing worker environments.
-
-The lifecycle labels used below are:
-
- **Stable** — reviewed public configuration; changes require compatibility
-  consideration.
- **Experimental** — public for evaluation, but its contract may still evolve.
- **Diagnostic** — supported for investigation or temporary mitigation, not as
-  a normal tuning interface.
- **Deprecated** — compatibility alias; migrate to the named replacement.
-
-## Public vLLM-Omni variables
-
-### Diffusion backend and cache selection
-
-| Name | Type and default | Applies to and read time | Precedence and invalid values | Lifecycle |
-| --- | --- | --- | --- | --- |
-| `DIFFUSION_ATTENTION_BACKEND` | Backend name or `auto`; default `auto` (platform selection) | Diffusion stages; read when `OmniDiffusionConfig` is constructed | `diffusion_attention_config.default` wins. An unknown backend fails during backend resolution. | Stable fallback |
-| `DIFFUSION_CACHE_BACKEND` | `none`, `cache_dit`, `tea_cache`, `mag_cache`, `step_cache`, `stepcache`, or `step_cache_dit`; default `none` | Diffusion runner startup | Explicit `cache_backend` in config wins. Otherwise this name wins over the deprecated alias. Unsupported values raise `ValueError` during runner setup. | Stable fallback |
-| `DIFFUSION_CACHE_ADAPTER` | Same values as `DIFFUSION_CACHE_BACKEND`; default `none` | Diffusion runner startup | Used only when neither explicit `cache_backend` nor `DIFFUSION_CACHE_BACKEND` is set. Unsupported values raise `ValueError`. | Deprecated; use `DIFFUSION_CACHE_BACKEND` |
-| `OMNI_DIFFUSION_PROMPT_EMBED_CACHE` | Boolean: `1`, `true`, `yes`, `on`, `0`, `false`, `no`, or `off`; default disabled | Each diffusion runner; resolved during model setup | A recognized environment value overrides the explicit enable setting. An unrecognized value is ignored. | Experimental |
-| `OMNI_DIFFUSION_PROMPT_EMBED_CACHE_SIZE` | Positive integer; default `32` entries | Each diffusion runner; resolved during model setup | A valid environment value overrides the explicit cache size. A non-integer logs a warning; a non-positive value is ignored. | Experimental |
-| `OMNI_DIFFUSION_SESSION_STATE_MANAGER` | Boolean with the same accepted spellings as the prompt cache; default disabled | Experimental diffusion session manager; model setup | A recognized environment value overrides the explicit enable setting. An unrecognized value is ignored. | Experimental |
-| `OMNI_DIFFUSION_SESSION_STATE_MANAGER_MAX_SESSIONS` | Positive integer; default `64` | Experimental diffusion session manager; model setup | A valid environment value overrides the explicit maximum. A non-integer logs a warning; a non-positive value is ignored. | Experimental |
-
-Backend names for `DIFFUSION_ATTENTION_BACKEND` are the members of
-`DiffusionAttentionBackendEnum`, such as `FLASH_ATTN`, `TORCH_SDPA`,
-`SAGE_ATTN`, `FLASHINFER_ATTN`, and `TRTLLM_ATTN`. Platform support still
-depends on the installed kernels and model path.
-
-### Serving and runtime
-
-| Name | Type and default | Applies to and read time | Precedence and invalid values | Lifecycle |
-| --- | --- | --- | --- | --- |
-| `SPEAKER_SAMPLES_DIR` | Filesystem path; default `~/.cache/vllm-omni/speakers` | Speech server; read when speaker storage initializes | Environment-only setting. The directory is created; filesystem errors propagate. | Stable |
-| `SPEAKER_MAX_UPLOADED` | Integer; default `1000` | Speech server; read when speaker storage initializes | Environment-only setting. A non-integer logs a warning and uses `1000`; range is not otherwise validated. | Stable |
-| `VLLM_OMNI_INPUT_WAIT_TIMEOUT_S` | Float seconds; default `600`; `<=0` disables | Full-payload input coordinator, not async-chunk transfer; read when the scheduler module imports in each worker | Environment-only setting. A non-float logs a warning and uses `600`. | Stable operational control |
-| `VLLM_OMNI_ORCH_MONITOR_PATH` | Filesystem path; default `<current-working-directory>/vllm_omni_orch_monitor_<timestamp>.json` | Orchestrator monitor enabled by `--enable-orch-monitor`; read when the monitor is created | Environment-only path override. Parent directories are created; write errors are logged. | Diagnostic |
-| `VLLM_OMNI_VIDEO_SYNC_TIMEOUT` | Float seconds; default `600` | Synchronous Videos API; read when the API server module imports | Environment-only setting. A non-float raises `ValueError` during import. | Experimental |
-| `VLLM_VIDEO_ASYNC_CHUNK` | `on` or `off`; default `on` | Streaming video output; read on attribute access | Environment-only setting. Values are trimmed and case-normalized; an invalid value warns once and uses `on`. | Experimental |
-| `VLLM_VIDEO_AUDIO_DELTA_MODE` | `fast` or `slow`; default `fast` | Streaming video audio deltas; read on attribute access | Environment-only setting. Values are trimmed and case-normalized; an invalid value warns once and uses `fast`. | Experimental |
-
-### Server storage
-
-Storage names use Pydantic's nested-settings delimiter (`__`). They are read
-when `ServerSettings` is initialized, normally during server import/startup.
-Invalid integer values raise a Pydantic validation error.
-
-| Name | Type and default | Meaning | Lifecycle |
-| --- | --- | --- | --- |
-| `VLLM_OMNI_SERVER_STORAGE__PATH` | Path; default `/tmp/storage` | Directory for completed server files. | Stable |
-| `VLLM_OMNI_SERVER_STORAGE__FILE_CONCURRENCY` | Integer; default `4` | Maximum concurrent file operations. No additional range validation is currently applied. | Stable |
-| `VLLM_OMNI_SERVER_STORAGE__FILE_TTL` | Integer seconds or unset; default unset | Optional lifetime for locally stored files. | Stable |
-| `VLLM_OMNI_SERVER_STORAGE__TTL_SWEEP_INTERVAL` | Integer seconds or unset | Sweep frequency. If file TTL is set and this is unset, the effective default is `300`. | Stable |
-| `VLLM_OMNI_STORAGE_PATH` | Path | Deprecated alias for `VLLM_OMNI_SERVER_STORAGE__PATH`. The new name wins when both are set. | Deprecated |
-| `VLLM_OMNI_STORAGE_MAX_CONCURRENCY` | Integer | Deprecated alias for `VLLM_OMNI_SERVER_STORAGE__FILE_CONCURRENCY`. The new name wins when both are set. | Deprecated |
-
-The deprecated aliases emit `DeprecationWarning`. They do not affect file TTL
-settings.
-
-### Quantization diagnostics and performance
-
-| Name | Type and default | Applies to and read time | Precedence and invalid values | Lifecycle |
-| --- | --- | --- | --- | --- |
-| `VLLM_OMNI_SKIP_NVFP4_NAN_CLAMP` | Boolean truthy spellings: `1`, `true`, `yes`, `on`; default false | ModelOpt NVFP4 compatibility patch; read when `vllm_omni.patch` imports | Environment-only escape hatch. Any other value means false. Set only to diagnose the upstream NaN-scale issue. | Diagnostic and temporary |
-| `VLLM_OMNI_USE_QUACK_FP8` | Boolean truthy spellings: `1`, `true`, `yes`, `on`; unset means hardware auto-detection | FP8 scaled matrix multiplication; evaluated when quack capability is selected | A set value overrides auto-detection. Any non-truthy value forces quack off. If quack cannot load, vLLM-Omni warns and falls back to FlashInfer. | Experimental performance control |
-
-`QUACK_CACHE_DIR` is owned by the external quack library and is not an
-Omni-owned variable, even though vLLM-Omni supplies a persistent default when
-it is unset.
-
-## Per-stage environment
-
-Deploy configurations can set arbitrary environment keys for one stage:
-
-```yaml
-stages:
-  - stage_id: 0
-    env:
-      HCCL_IF_BASE_PORT: 23000
-      MY_MODEL_CACHE: /mnt/model-cache
-```
-
-The legacy nested form under `runtime.env` is also accepted. vLLM-Omni converts
-keys and values to strings, applies them while the stage engine or child process
-is launched, logs keys but not values, and restores the parent process's prior
-environment afterward. A child process inherits the scoped values. This keeps
-sibling stages from permanently changing one another's parent environment.
-
-This scoping has two consequences:
-
-1. A setting read inside stage/model initialization can see the stage value.
-2. A setting already cached by an import that occurred before stage launch
-   cannot be changed retroactively with stage `env`.
-
-Stage `env` is an escape hatch for process and third-party settings, not a
-replacement for typed stage configuration. Do not put request-varying behavior
-there. Secret values may reach child processes; logs and diagnostics must emit
-their keys only.
-
-## Inherited vLLM variables
-
-vLLM-Omni also reads variables through its aligned vLLM dependency. Refer to
-the [vLLM 0.26 environment-variable reference](https://docs.vllm.ai/en/v0.26.0/configuration/env_vars.html)
-for their definitions. This includes vLLM launch, cache, logging, plugin, ROCm,
-XPU, ModelScope, and FlashInfer workspace settings.
-
-An inherited name does not become Omni-owned because Omni reads or forwards it.
-Where behavior differs, the Omni-specific page should document only that
-difference. For example, device-visibility values can be further narrowed by a
-stage's `devices` setting.
-
-## Platform, external, and secret variables
-
-Hardware runtimes, distributed launchers, and third-party libraries retain
-ownership of their variables. Common groups include:
-
- device visibility (`ASCEND_RT_VISIBLE_DEVICES`, `HIP_VISIBLE_DEVICES`, and
-  `MUSA_VISIBLE_DEVICES`);
- distributed launch (`MASTER_ADDR`, `MASTER_PORT`, `RANK`, and `WORLD_SIZE`);
- Hugging Face cache and authentication (`HF_HOME`, `HF_TOKEN`, and related
-  names);
- accelerator libraries such as NCCL, FlashInfer, MindIE, MORI, and quack.
-
-Consult the owning project's documentation for accepted values and support.
-`HF_TOKEN`, `HUGGINGFACE_HUB_TOKEN`, and `OPENAI_API_KEY` are explicitly marked
-for redaction in the reviewed inventory. Never print their values in environment
-collection, examples, bug reports, or logs.
-
-## Model-specific variables
-
-The audit found 57 variables read by a single model or pipeline family. They are
-not listed as public usage options here because doing so would turn implementation
-escape hatches into an accidental compatibility contract.
-
-Every audited model-specific name has a migration disposition in the
-[environment-variable inventory](gh-file:vllm_omni/config/environment_variable_inventory.py):
-
-| Disposition | Count | Required outcome |
-| --- | ---: | --- |
-| Promote | 33 | Move a stable setting into typed stage or model configuration. |
-| Request scope | 6 | Move request-varying behavior into a declared request-option schema. |
-| External | 0 | Retain only when a supported third-party library owns the contract. |
-| Internalize | 11 | Keep a debug or diagnostic switch out of public documentation and configuration. |
-| Deprecate/remove | 7 | Remove a compatibility escape hatch that has no continuing contract. |
-
-The disposition is a migration target, not a statement that the existing
-environment switch is stable. Promote or request-scope work should land in
-model-owner-reviewed follow-up changes with validation and model-page updates.
-The family-sized migration packages and their ownership gate are tracked in
-[#6232](https://github.com/vllm-project/vllm-omni/issues/6232).
-
-## Environment collection and troubleshooting
-
-Run the repository collector when preparing a bug report:
-
-```bash
-python collect_env.py
-```
-
-The environment section includes the safe public Omni allowlist, registered
-vLLM variables, and selected platform prefixes. It omits names marked for
-redaction and names containing common secret terms. Review the output before
-sharing it. A key supplied through stage `env` is not collected merely because
-it appears in deploy configuration; the same allowlist and prefix rules apply.
-
-If a setting appears ineffective, first check its read time in the tables
-above. Restart processes after changing import- or startup-time values, verify
-that the variable reaches the intended worker, and check whether an explicit
-typed configuration field takes precedence.
-
-## Benchmark and internal variables
-
-The reviewed inventory marks 20 benchmark variables as transitional while
-benchmark configuration moves to CLI/request schemas in
-[issue #5376](https://github.com/vllm-project/vllm-omni/issues/5376). They are not
-part of the serving/runtime contract.
-
-Internal process-coordination and debug variables are deliberately excluded
-from this page. The CI scanner resolves string literals and module-level string
-constants used by direct `os` access, local wrapper helpers, aliased `os`
-imports, and environment membership checks. Server-storage names generated by
-Pydantic settings are checked separately against their model fields.
-
-Names assembled from cross-module metadata and arbitrary keys supplied through
-stage `env` cannot be inferred reliably. Contributors must classify those names
-explicitly. CI fails when a statically resolved name has no classification or
-when a reviewed public name is absent from this page.
@@ -80,15 +80,19 @@ When multiple stages share the same GPU, you must ensure the sum of their `gpu_m

 **Example: Two stages on GPU 0**
 ```yaml
-stages:
+stage_args:
  - stage_id: 0
-    devices: "0"
-    gpu_memory_utilization: 0.6  # Uses 60% of GPU 0
+    runtime:
+      devices: "0"
+    engine_args:
+      gpu_memory_utilization: 0.6  # Uses 60% of GPU 0

  - stage_id: 1
-    devices: "0"
-    gpu_memory_utilization: 0.3  # Uses 30% of GPU 0
-    # Total: 90% of GPU 0 (safe, leaves 10% buffer)
+    runtime:
+      devices: "0"
+    engine_args:
+      gpu_memory_utilization: 0.3  # Uses 30% of GPU 0
+      # Total: 90% of GPU 0 (safe, leaves 10% buffer)
 ```

 **Important:** If stages run on different GPUs, each can use up to 1.0 independently.
@@ -99,12 +103,14 @@ When using `tensor_parallel_size > 1`, the model is split across multiple GPUs,

 **Example: 2-way tensor parallelism**
 ```yaml
-stages:
+stage_args:
  - stage_id: 0
-    devices: "0,1"  # Uses both GPUs
-    tensor_parallel_size: 2
-    gpu_memory_utilization: 0.6  # 60% per GPU
-    # Model is split, so each GPU uses ~30% of model memory
+    runtime:
+      devices: "0,1"  # Uses both GPUs
+    engine_args:
+      tensor_parallel_size: 2
+      gpu_memory_utilization: 0.6  # 60% per GPU
+      # Model is split, so each GPU uses ~30% of model memory
 ```

 ## Examples
@@ -112,25 +118,27 @@ stages:
 ### Qwen3-Omni-MoE on 2x H100-80GB

 ```yaml
-base_config: /path/to/vllm_omni/deploy/qwen3_omni_moe.yaml
-
-stages:
+stage_args:
  - stage_id: 0  # Thinker stage with TP=2
-    devices: "0,1"
-    tensor_parallel_size: 2
-    gpu_memory_utilization: 0.6  # 48GB per GPU
+    runtime:
+      devices: "0,1"
+    engine_args:
+      tensor_parallel_size: 2
+      gpu_memory_utilization: 0.6  # 48GB per GPU

  - stage_id: 1  # Talker stage
-    devices: "1"
-    gpu_memory_utilization: 0.3  # 24GB on GPU 1
+    runtime:
+      devices: "1"
+    engine_args:
+      gpu_memory_utilization: 0.3  # 24GB on GPU 1

  - stage_id: 2  # Code2Wav stage
-    devices: "0"
-    gpu_memory_utilization: 0.1  # 8GB on GPU 0
+    runtime:
+      devices: "0"
+    engine_args:
+      gpu_memory_utilization: 0.1  # 8GB on GPU 0
 ```
-**Note:** Stage 0 uses GPUs 0 and 1, so the combined utilization is `0.7` on
-GPU 0 and `0.9` on GPU 1. Keep the sum of all resident stages below `1.0` on
-each device.
+**Note:** In this configuration, stages 0 and 2 share GPU 0, but they run at different times in the pipeline, so their memory usage doesn't overlap.

 ## Troubleshooting

@@ -0,0 +1,171 @@
+# Prefill-Decode (PD) Disaggregation
+
+PD disaggregation splits the Qwen3-Omni thinker into separate prefill and decode
+stages so prompt processing and token generation can run on different workers.
+
+This is documented as a stage-config recipe instead of a bundled YAML because the
+deployment-specific values usually change per environment:
+
+- GPU placement
+- `tensor_parallel_size`
+- connector backend and connector ports
+- connector IPs or bootstrap addresses
+
+Start from the [default Qwen3-Omni stage config](gh-file:vllm_omni/deploy/qwen3_omni_moe.yaml)
+and copy it to your own file, for example `qwen3_omni_pd.yaml`. Then apply the
+changes below.
+
+## Requirements
+
+- 3+ GPUs for a basic layout: prefill, decode, and talker+code2wav
+- A KV connector supported by vLLM, such as `MooncakeConnector`
+- Matching `tensor_parallel_size` on the prefill and decode thinker stages
+
+## 1. Split the thinker into prefill and decode stages
+
+Replace the original thinker stage with two stages:
+
+```yaml
+stage_args:
+  - stage_id: 0
+    stage_type: llm
+    is_prefill_only: true
+    runtime:
+      devices: "0"
+    engine_args:
+      max_num_seqs: 16
+      model_stage: thinker
+      model_arch: Qwen3OmniMoeForConditionalGeneration
+      worker_type: ar
+      scheduler_cls: vllm_omni.core.sched.omni_ar_scheduler.OmniARScheduler
+      gpu_memory_utilization: 0.9
+      enforce_eager: true
+      trust_remote_code: true
+      engine_output_type: latent
+      distributed_executor_backend: "mp"
+      enable_prefix_caching: false
+      max_num_batched_tokens: 32768
+      hf_config_name: thinker_config
+      tensor_parallel_size: 1
+      kv_transfer_config:
+        kv_connector: "MooncakeConnector"
+        kv_role: "kv_producer"
+        kv_rank: 0
+        kv_parallel_size: 2
+        kv_connector_extra_config:
+          mooncake_bootstrap_port: 25201
+    final_output: false
+    is_comprehension: true
+    default_sampling_params:
+      temperature: 0.4
+      top_p: 0.9
+      top_k: 1
+      max_tokens: 2048
+      seed: 42
+      detokenize: True
+      repetition_penalty: 1.05
+
+  - stage_id: 1
+    stage_type: llm
+    is_decode_only: true
+    runtime:
+      devices: "1"
+    engine_args:
+      max_num_seqs: 64
+      model_stage: thinker
+      model_arch: Qwen3OmniMoeForConditionalGeneration
+      worker_type: ar
+      scheduler_cls: vllm_omni.core.sched.omni_ar_scheduler.OmniARScheduler
+      gpu_memory_utilization: 0.9
+      enforce_eager: true
+      trust_remote_code: true
+      engine_output_type: latent
+      distributed_executor_backend: "mp"
+      enable_prefix_caching: false
+      max_num_batched_tokens: 32768
+      hf_config_name: thinker_config
+      tensor_parallel_size: 1
+      kv_transfer_config:
+        kv_connector: "MooncakeConnector"
+        kv_role: "kv_consumer"
+        kv_rank: 1
+        kv_parallel_size: 2
+        kv_connector_extra_config:
+          mooncake_bootstrap_port: 25202
+    engine_input_source: [0]
+    final_output: true
+    final_output_type: text
+    is_comprehension: true
+    default_sampling_params:
+      temperature: 0.4
+      top_p: 0.9
+      top_k: 1
+      max_tokens: 2048
+      seed: 42
+      detokenize: True
+      repetition_penalty: 1.05
+```
+
+Notes:
+
+- `is_prefill_only: true` marks the thinker stage that only saves KV.
+- `is_decode_only: true` marks the thinker stage that resumes from remote KV.
+- `kv_transfer_config` is required on both stages.
+- The orchestrator forces the prefill stage to run with `max_tokens=1`, so the
+  prefill side only processes the prompt and exports KV.
+
+## 2. Shift the downstream stages by one index
+
+After inserting the extra thinker stage, renumber the remaining stages:
+
+```yaml
+  - stage_id: 2
+    runtime:
+      devices: "2"
+    engine_input_source: [1]
+    sync_process_input_func: vllm_omni.model_executor.stage_input_processors.qwen3_omni.thinker2talker_token_only
+
+  - stage_id: 3
+    runtime:
+      devices: "2"
+    engine_args:
+      max_num_seqs: 1
+    engine_input_source: [2]
+    sync_process_input_func: vllm_omni.model_executor.stage_input_processors.qwen3_omni.talker2code2wav_token_only
+```
+
+Compared with the default Qwen3-Omni config:
+
+- the talker becomes stage `2` instead of stage `1`
+- the code2wav stage becomes stage `3` instead of stage `2`
+- the talker now reads from decode stage `1`
+
+## 3. Add runtime edges for the four-stage pipeline
+
+```yaml
+runtime:
+  enabled: true
+  edges:
+    - from: 0
+      to: 1
+    - from: 1
+      to: 2
+    - from: 2
+      to: 3
+```
+
+## 4. Launch with your custom config
+
+```bash
+vllm serve Qwen/Qwen3-Omni-30B-A3B-Instruct --omni --port 8091 \
+    --deploy-config /path/to/qwen3_omni_pd.yaml
+```
+
+## Operational Notes
+
+- `MooncakeConnector` does not support heterogeneous TP sizes across the PD
+  pair. Keep prefill and decode at the same `tensor_parallel_size`.
+- If the thinker requires TP=2, both thinker stages must use TP=2 and be given
+  separate GPU sets, for example `"0,1"` for prefill and `"2,3"` for decode.
+- Choose connector ports and addresses that match your deployment. The values
+  shown above are examples only.
@@ -3,46 +3,7 @@
 In vLLM-Omni, a model's `PipelineConfig` defines its fixed stage topology, while a deploy configuration controls how those stages run.

 !!! note
-    Default deploy config YAMLs (for example, `vllm_omni/deploy/qwen2_5_omni.yaml`, `vllm_omni/deploy/qwen3_omni_moe.yaml`, and `vllm_omni/deploy/qwen3_tts.yaml`) are bundled and loaded automatically when `--deploy-config` is omitted. The resolved pipeline selects its default through `default_deploy_config_name`.
-
-## Pipeline configuration
-
-`PipelineConfig` and its `StagePipelineConfig` entries are Python definitions
-owned by the model implementation and registered in `OMNI_PIPELINES`. They
-describe fixed model topology and are not accepted in deploy YAMLs.
-
-Common `PipelineConfig` fields include:
-
-| Field | Description |
-|-------|-------------|
-| `model_type` | Pipeline identifier used during model and config resolution. |
-| `default_deploy_config_name` | Bundled deploy YAML loaded when the user does not pass `deploy_config`. |
-| `model_arch` | Default Hugging Face architecture for the pipeline. |
-| `hf_architectures` | Architecture names used to identify checkpoints whose `model_type` is shared. |
-| `hf_config_predicate` | Optional predicate used to select between pipelines with otherwise identical HF metadata. |
-| `diffusers_class_name` | Diffusers `_class_name` used to identify Diffusers-style repositories. |
-| `stages` | Ordered tuple of fixed `StagePipelineConfig` definitions. |
-
-Common `StagePipelineConfig` fields include:
-
-| Field | Description |
-|-------|-------------|
-| `stage_id` | Stable stage identifier. |
-| `model_stage` | Logical stage name used by runtime and strategy resolution. |
-| `execution_type` | `LLM_AR`, `LLM_GENERATION`, or `DIFFUSION`. |
-| `input_sources` | Upstream stage IDs that provide this stage's inputs. |
-| `final_output` / `final_output_type` | Whether the stage produces a user-visible output and its modality. |
-| `owns_tokenizer` | Whether this stage owns the pipeline tokenizer. |
-| `model_arch`, `hf_config_name` | Stage-specific model architecture and nested HF config selector. |
-| `engine_output_type` | Runtime output representation such as `text`, `latent`, or `audio`. |
-| `custom_process_input_func` | Processor applied to this stage's incoming payload. |
-| `custom_process_next_stage_input_func` | Processor used for full-payload handoff to the next stage. |
-| `async_chunk_process_next_stage_input_func` | Processor used for async chunk handoff. |
-| `sampling_constraints` | Model-owned sampling constraints that deploy defaults cannot override. |
-
-To add or change topology, define and register a new pipeline variant. Use
-deploy YAML only for runtime placement, resource sizing, connectors, and other
-deployment overrides.
+    Default deploy config YAMLs (for example, `vllm_omni/deploy/qwen2_5_omni.yaml`, `vllm_omni/deploy/qwen3_omni_moe.yaml`, and `vllm_omni/deploy/qwen3_tts.yaml`) are bundled and loaded automatically when `--deploy-config` is omitted. The model registry resolves the right pipeline and deploy YAML by `model_type`.

 ## Deploy configuration schema

@@ -52,53 +13,42 @@ The new deploy schema lives under `vllm_omni/deploy/` and is paired with a froze
 |-------|------|----------|---------|-------------|
 | `base_config` | str (path) | optional | — | Overlay parent (relative or absolute). `stages:` / `platforms:` deep-merged by stage_id; other scalars overlay-wins. Intended for user-authored overlays; prod yamls stay flat. |
 | `async_chunk` | bool | optional | `true` | Enable chunked streaming between stages. Pin to `false` if the pipeline runs end-to-end. |
-| `session_mode` | str | optional | `"turn"` | Session behavior. Use `"duplex"` only with a pipeline that enables duplex control. |
-| `active_stream_window` | int | optional | `0` | Number of active downstream stream slots; `0` preserves all-stream cycling. |
-| `duplex_session` | dict | optional | runtime defaults | Full-duplex session lifecycle, buffering, replay, and capacity limits. |
 | `connectors` | dict | optional | `null` | Named connector specs (`{name, extra}`). Referenced by each stage's `input_connectors` / `output_connectors`. See [Connector schema](#connector-schema). |
 | `edges` | list | optional | `null` | Explicit edge list for the KV transfer graph. Auto-derived from stage inputs if omitted. |
-| `stages` | list | optional | `[]` | Per-stage runtime overrides matched by `stage_id`. Pipeline stages are still created from `PipelineConfig` when this list is empty. |
+| `stages` | list | required | — | Per-stage engine args + wiring (see [Stage fields](#stage-fields)). |
 | `platforms` | dict | optional | `null` | Keyed by `npu` / `rocm` / `xpu`, each contains a `stages:` list with per-platform overrides applied on top of the CUDA defaults. |
 | `pipeline` | str | optional | `null` | Override the auto-detected pipeline registry key (used for structural variants like `qwen2_5_omni_thinker_only`). |
-| `trust_remote_code` | bool \| null | optional | `null` | **Pipeline-wide.** Trust HF remote code on model load; applies to every stage when specified. |
+| `trust_remote_code` | bool | optional | `true` | **Pipeline-wide.** Trust HF remote code on model load; applies to every stage. |
 | `distributed_executor_backend` | str \| null | optional | `null` | **Pipeline-wide.** Distributed executor backend forwarded to vLLM (`"mp"`, `"ray"`, `"external_launcher"`). If omitted, vLLM auto-selects backend from runtime topology. |
 | `dtype` | str \| null | optional | `null` | **Pipeline-wide.** Model dtype for every stage. |
 | `quantization` | str \| null | optional | `null` | **Pipeline-wide.** Quantization method for every stage. |
-| `enable_prefix_caching` | bool \| null | optional | `null` | **Pipeline-wide.** Prefix cache toggle applied to every stage when specified. |
+| `enable_prefix_caching` | bool | optional | `false` | **Pipeline-wide.** Prefix cache toggle applied to every stage. |
 | `enable_chunked_prefill` | bool \| null | optional | `null` | **Pipeline-wide.** Chunked prefill toggle applied to every stage. |
-| `data_parallel_size` | int \| null | optional | `null` | **Pipeline-wide.** DP degree for every stage. |
-| `pipeline_parallel_size` | int \| null | optional | `null` | **Pipeline-wide.** PP degree for every stage. |
-| `custom_voice_dir` | str \| null | optional | `null` | **Pipeline-wide.** Directory containing custom voice profiles for supported TTS models. |
+| `data_parallel_size` | int | optional | `1` | **Pipeline-wide.** DP degree for every stage. |
+| `pipeline_parallel_size` | int | optional | `1` | **Pipeline-wide.** PP degree for every stage. |

-For fields whose deploy default is `null`, the deploy layer contributes no
-override. The effective value may still come from a platform section, an
-explicit CLI or stage override, or the downstream vLLM engine default.
-
-Note: for the diffusion path, an omitted `distributed_executor_backend` selects
-`uni` on a single GPU (in-process worker, no MessageQueue / `/dev/shm` output
-segments) and `mp` when `num_gpus > 1`. Set `mp` explicitly to keep a worker
-subprocess on one GPU. `ray` / `external_launcher` are not fully supported yet.
+Note: for diffusion path, `distributed_executor_backend` currently defaults to
+`mp`, and `ray` / `external_launcher` are not fully supported yet.

 ### Stage fields

-Each entry under `stages:` accepts any `StageDeployConfig` field directly (no nested `engine_args:`). Only fields whose value legitimately varies across stages live here; pipeline-wide settings (trust_remote_code, distributed_executor_backend, dtype, quantization, prefix/chunked prefill, DP/PP sizes) are declared at the top level and applied to every stage. Unknown keys fall through to `engine_extras:` and are forwarded to the engine. Frequently used fields are listed below; the source-of-truth schema is `StageDeployConfig` in `vllm_omni/config/stage_config.py`.
+Each entry under `stages:` accepts any `StageDeployConfig` field directly (no nested `engine_args:`). Only fields whose value legitimately varies across stages live here; pipeline-wide settings (trust_remote_code, distributed_executor_backend, dtype, quantization, prefix/chunked prefill, DP/PP sizes) are declared at the top level and applied to every stage. Unknown keys fall through to `engine_extras:` and are forwarded to the engine.

 | Field | Type | Required | Default | Description |
 |-------|------|----------|---------|-------------|
 | `stage_id` | int | required | — | Stage identity; matched against `PipelineConfig.stages[*].stage_id`. |
-| `max_num_seqs` | int \| null | optional | `null` | Max concurrent sequences per stage. |
-| `gpu_memory_utilization` | float \| null | optional | `null` | Per-stage total memory target; used for automatic KV-cache sizing. |
-| `kv_cache_memory_bytes` | int \| null | optional | `null` | Explicit per-rank KV-cache budget in bytes; overrides automatic sizing. |
-| `tensor_parallel_size` | int \| null | optional | `null` | TP degree for this stage. |
-| `enforce_eager` | bool \| null | optional | `null` | Disable CUDA graphs. |
-| `max_num_batched_tokens` | int \| null | optional | `null` | Per-stage prefill/token budget; also contributes to the native maximum in-flight token limit. |
-| `max_model_len` | int \| null | optional | `null` | Per-sequence context or KV length; `-1` enables native cache-capacity auto-fitting, while values above the HF default auto-set `VLLM_ALLOW_LONG_MAX_MODEL_LEN=1`. |
+| `max_num_seqs` | int | optional | `64` | Max concurrent sequences per stage. |
+| `gpu_memory_utilization` | float | optional | `0.9` | Per-stage memory budget. |
+| `tensor_parallel_size` | int | optional | `1` | TP degree for this stage. |
+| `enforce_eager` | bool | optional | `false` | Disable CUDA graphs. |
+| `max_num_batched_tokens` | int | optional | `32768` | Prefill budget. |
+| `max_model_len` | int \| null | optional | `null` | Per-stage context length (auto-sets `VLLM_ALLOW_LONG_MAX_MODEL_LEN=1` when larger than HF default). |
 | `async_scheduling` | bool \| null | optional | `null` | Per-stage async scheduling toggle. |
-| `devices` | str \| null | optional | `null` | Device list assigned to this stage. |
+| `devices` | str | optional | `"0"` | `CUDA_VISIBLE_DEVICES`-style device list. |
 | `output_connectors` | dict \| null | optional | `null` | Keyed by `to_stage_<n>`; values are names registered under top-level `connectors:`. |
 | `input_connectors` | dict \| null | optional | `null` | Keyed by `from_stage_<n>`; values are names registered under top-level `connectors:`. |
 | `default_sampling_params` | dict \| null | optional | `null` | Baseline sampling params. Deep-merged with pipeline `sampling_constraints` (pipeline wins). |
-| `engine_extras` | dict | optional | `{}` | Catch-all for engine fields not listed above; deep-merged across overlays and forwarded to the stage engine. |
+| `engine_extras` | dict | optional | `{}` | Catch-all for keys not listed above; deep-merged across overlays. Also carries per-stage overrides of pipeline-wide settings (e.g. stage-specific `dtype`). |

 ### Connector schema

@@ -110,7 +60,7 @@ connectors:
    name: <ConnectorClassName>     # required — class registered in vllm_omni.distributed
    extra:                         # optional — forwarded to the connector's __init__
      <key>: <value>
-      # Additional connector-specific options
+      ...
 ```

 | Connector class | Use case | `extra` keys |
@@ -285,3 +235,288 @@ vllm serve Qwen/Qwen2.5-Omni-7B --omni --port 8091 --deploy-config /path/to/depl

 !!! important
    We are actively iterating on the definition of deployment configurations, and we welcome feedback from users and developers.
+
+## Legacy stage configuration reference
+
+The remainder of this page documents the deprecated `stage_args` schema for models that have not migrated to deploy configurations. The following historical Qwen2.5-Omni configuration illustrates that schema; current Qwen2.5-Omni deployments should use `vllm_omni/deploy/qwen2_5_omni.yaml` instead.
+
+```python
+# Historical stage configuration for Qwen2.5-Omni.
+stage_args:
+  - stage_id: 0 # mark the unique id for each stage
+    runtime: # The disaggregated configuration
+      process: true  # Run this stage in a separate process
+      devices: "0" # Logical device index for this stage (mapped through CUDA_VISIBLE_DEVICES / ASCEND_RT_VISIBLE_DEVICES if set)
+    engine_args: # Engine arguments for a certain engine
+      model_stage: thinker
+      max_num_seqs: 1
+      model_arch: Qwen2_5OmniForConditionalGeneration # The model implementation registered in model_executor/models/registry.py
+      worker_type: ar # The specific worker used
+      scheduler_cls: vllm_omni.core.sched.omni_ar_scheduler.OmniARScheduler # The specific scehduler used
+      gpu_memory_utilization: 0.8 # The gpu memory allocation for the stage within a single chip
+      enforce_eager: true  # Now we only support eager mode
+      trust_remote_code: true # Needed by huggingface config parsing
+      engine_output_type: latent  # It claims that the stage will input latent hiddenstates besides token ids
+      enable_prefix_caching: false # For request with hiddenstates output, the prefix caching is not supported now
+    is_comprehension: true # If the stage is a text or multimodal comprehension module. If it is, the AsyncOmni will use its tokenizer as default
+    final_output: true # If the stage has output as part of final outputs. If it is false, which means that the stage only works as a intermediate role.
+    final_output_type: text # What is the final output type. It can be text and audio now.
+    default_sampling_params: # sampling parameters for the stage. Their meaning aligns with vLLM.
+      temperature: 0.0
+      top_p: 1.0
+      top_k: -1
+      max_tokens: 2048
+      seed: 42
+      detokenize: True
+      repetition_penalty: 1.1
+  - stage_id: 1
+    runtime:
+      process: true
+      devices: "1"
+    engine_args:
+      model_stage: talker
+      max_num_seqs: 3
+      model_arch: Qwen2_5OmniForConditionalGeneration
+      worker_type: ar
+      scheduler_cls: vllm_omni.core.sched.omni_ar_scheduler.OmniARScheduler
+      gpu_memory_utilization: 0.8
+      enforce_eager: true
+      trust_remote_code: true
+      enable_prefix_caching: false
+      engine_output_type: latent
+    engine_input_source: [0]
+    default_sampling_params:
+      temperature: 0.9
+      top_p: 0.8
+      top_k: 40
+      max_tokens: 2048
+      seed: 42
+      detokenize: True
+      repetition_penalty: 1.05
+      stop_token_ids: [8294]
+  - stage_id: 2
+    runtime:
+      process: true
+      devices: "0"            # Example: use a different GPU than the previous stage; use "0" if single GPU
+    engine_args:
+      model_stage: code2wav
+      max_num_seqs: 1
+      model_arch: Qwen2_5OmniForConditionalGeneration
+      worker_type: generation
+      scheduler_cls: vllm_omni.core.sched.omni_generation_scheduler.OmniGenerationScheduler
+      gpu_memory_utilization: 0.15
+      enforce_eager: true
+      trust_remote_code: true
+      enable_prefix_caching: false
+      engine_output_type: audio
+    engine_input_source: [1]
+    final_output: true
+    final_output_type: audio
+    default_sampling_params:
+      temperature: 0.0
+      top_p: 1.0
+      top_k: -1
+      max_tokens: 2048
+      seed: 42
+      detokenize: True
+      repetition_penalty: 1.1
+
+# Top-level runtime config (concise): default windows and stage edges
+runtime:
+  enabled: true
+
+  edges:
+    - from: 0                   # thinker → talker: trigger only after receiving full input (-1)
+      to: 1
+    - from: 1                   # talker → code2wav: trigger only after receiving full input (-1)
+      to: 2
+
+```
+
+## Legacy stage configuration arguments
+
+Each stage in the `stage_args` list contains the following configuration options:
+
+### `stage_id`
+
+A unique identifier for each stage in the multi-stage pipeline. Stages are numbered sequentially starting from 0, and this ID is used to reference stages in inter-stage dependencies (e.g., `engine_input_source`).
+
+### `prompt_expand_func` (Optional)
+
+A custom Python function hook for the LLM stage (Stage 0) that expands a single incoming prompt object into multiple prompts. This is primarily used for multi-modal Classifier-Free Guidance (CFG), where it generates the necessary companion requests (like a negative text prompt) and tags them with internal roles (e.g., `cfg_text`). This ensures the upstream LLM generates the needed contextual hidden states for both the conditional and unconditional generations simultaneously.
+
+### `cfg_kv_collect_func` (Optional)
+
+A custom Python function hook for downstream diffusion stages (Stage 1+) to collect, map, and process the KV caches transferred from the companion requests fired by `prompt_expand_func`. It aggregates the hidden condition states cleanly (e.g., binding them as `cfg_text_past_key_values` and `cfg_text_kv_metadata`), allowing the diffusion runtime to perform CFG smoothly without redundantly evaluating text paths on the DiT workers.
+
+### `runtime`
+
+Configuration for disaggregated execution of the stage, controlling how the stage is deployed and executed.
+
+#### `runtime.process`
+
+Whether to run this stage in a separate process. When set to `true`, the stage will be executed in an isolated process, enabling better resource isolation and parallel execution across different stages. This is essential for multi-GPU deployments where different stages run on different devices.
+
+Default: `true`
+
+#### `runtime.devices`
+
+Logical device indices for this stage, specified as a string. Values are **logical indices** (`0`, `1`, `2`, ...) — not physical GPU IDs — and are mapped through the platform's visibility env var (`CUDA_VISIBLE_DEVICES` on CUDA, `ASCEND_RT_VISIBLE_DEVICES` on NPU) before being applied via `torch.cuda.set_device()` (or the equivalent).
+
+Example: if `CUDA_VISIBLE_DEVICES=0,2,4` is set in the environment, then `devices: "0"` selects physical GPU 0 (the first visible), `devices: "1"` selects physical GPU 2, and `devices: "0,1"` makes physical GPUs 0 and 2 available to the stage. If no visibility env var is set, logical and physical IDs coincide.
+
+Default: `"0"`
+
+#### `engine_args.max_num_seqs`
+
+The maximum number of sequences for concurrent processing in this stage. For
+LLM stages, this controls the vLLM scheduler's maximum concurrent sequences.
+For diffusion stages, this controls scheduler wave capacity in both request
+batch mode and step batch mode. `max_num_seqs: 1` is the serial/conservative
+path; values above `1` allow compatible requests to batch when the selected
+diffusion pipeline supports that batching mode.
+
+Default: `1`
+
+#### `engine_args.request_batch_max_wait_ms`
+
+The maximum time, in milliseconds, that a diffusion request-mode stage may wait
+before the first `schedule()` of a new scheduler wave so compatible requests can
+accumulate for request-level batching. This only applies to diffusion pipelines
+that support request-level batching with `step_execution` disabled.
+
+Use this together with `max_num_seqs > 1` for bursty serving traffic. `0`
+disables admission waiting and preserves the lowest first-request latency.
+For diffusion execution and batching tuning, see
+[Diffusion Execution Modes](../user_guide/diffusion/execution_modes.md).
+
+Default: `0.0`
+
+### `engine_args`
+
+Engine arguments for configuring the LLM engine, diffusion engine, or other engine types used by this stage.
+
+#### `engine_args.model_stage`
+
+The name identifier for this model stage within the multi-stage architecture. This is used internally to distinguish different stages of the same model (e.g., "thinker", "talker", "code2wav" in Qwen2.5-Omni).
+
+#### `engine_args.model_arch`
+
+The model architecture class name that is registered in `model_executor/models/registry.py`. This specifies which model implementation to use for this stage. The class must be registered in the model registry for vLLM-Omni to locate and instantiate it.
+
+#### `engine_args.worker_cls`
+
+The specific worker class to use for this stage. This determines how the model computations are executed. Examples include `vllm_omni.worker.gpu_ar_worker.GPUARWorker` for autoregressive stages and `vllm_omni.worker.gpu_generation_worker.GPUGenerationWorker` for diffusion-based stages.
+
+#### `engine_args.scheduler_cls`
+
+The scheduler class to use for this stage. The scheduler manages request queuing, batching, and execution order. Examples include `vllm_omni.core.sched.omni_ar_scheduler.OmniARScheduler` for standard stages and `vllm_omni.core.sched.omni_generation_scheduler.OmniGenerationScheduler` for diffusion stages.
+
+#### `engine_args.gpu_memory_utilization`
+
+The fraction of GPU memory to allocate for this stage within a single GPU chip. This is a value between 0.0 and 1.0, where 0.8 means 80% of the GPU memory will be used by this stage. This allows fine-grained control over memory allocation when multiple stages share the same GPU or when reserving memory for other operations.
+
+Default: `0.8`
+
+!!! tip "Memory Configuration Guide"
+    For detailed information on how to calculate memory requirements and properly configure `gpu_memory_utilization`, see the [GPU Memory Calculation and Configuration Guide](./gpu_memory_utilization.md).
+
+#### `engine_args.enforce_eager`
+
+Whether to enforce eager execution mode. When set to `true`, the engine will run in eager mode without using CUDA graphs or other compilation optimizations. Currently, vLLM-Omni only supports eager mode.
+
+Default: `true`
+
+#### `engine_args.trust_remote_code`
+
+Whether to trust remote code when loading models from Hugging Face. This is required for models that use custom code in their configuration files. Set to `true` when loading models that require custom model implementations.
+
+Default: `true`
+
+#### `engine_args.engine_output_type`
+
+Specifies the type of output produced by this stage's engine. This determines what kind of data flows to downstream stages. Possible values include `latent` (hidden states), `text` (tokenized text), and `audio` (audio waveforms). When set to `latent`, the stage outputs latent hidden states in addition to token IDs, which are consumed by downstream stages.
+
+Default: `latent`
+
+#### `engine_args.enable_prefix_caching`
+
+Whether to enable prefix caching for this stage. Prefix caching can improve performance by caching KV cache for common prompt prefixes. However, for requests that output hidden states (when `engine_output_type` is `latent`), prefix caching is not currently supported and should be set to `false`.
+
+Default: `false`
+
+### `is_comprehension`
+
+Whether this stage is a text or multimodal comprehension module. When set to `true`, the stage acts as a comprehension module that processes input text or multimodal content. If this is the first comprehension stage, `AsyncOmni` will use its tokenizer as the default tokenizer for the entire pipeline.
+
+Default: `true`
+
+### `final_output`
+
+Whether this stage produces output that is part of the final outputs returned to the user. When set to `false`, the stage only works as an intermediate stage, processing data that flows to downstream stages but not contributing directly to the final response.
+
+Default: `true`
+
+### `final_output_type`
+
+The type of final output produced by this stage. This specifies what format the output will be in when returned to the user. Currently supported values are `text` (for text generation) and `audio` (for audio generation).
+
+Default: `text`
+
+### `default_sampling_params`
+
+Default sampling parameters for this stage. These parameters control the generation behavior and align with vLLM's sampling parameter semantics. These defaults are used when no explicit sampling parameters are provided in the request.
+
+#### `default_sampling_params.temperature`
+
+Sampling temperature for controlling randomness. Lower values (e.g., 0.0) make the output more deterministic and focused, while higher values increase randomness.
+
+Default: `0.0`
+
+#### `default_sampling_params.top_p`
+
+Nucleus sampling parameter. Only tokens with cumulative probability mass up to `top_p` are considered. This helps filter out low-probability tokens while maintaining diversity.
+
+Default: `1.0`
+
+#### `default_sampling_params.top_k`
+
+Top-k sampling parameter. Only the top `k` most likely tokens are considered. Set to `-1` to disable top-k filtering and consider all tokens.
+
+Default: `-1`
+
+#### `default_sampling_params.max_tokens`
+
+Maximum number of tokens to generate in this stage. This limits the length of the output sequence.
+
+Default: `2048`
+
+#### `default_sampling_params.seed`
+
+Random seed for reproducible generation. When set, the random number generator will be initialized with this seed to ensure consistent outputs across runs.
+
+Default: `42`
+
+#### `default_sampling_params.detokenize`
+
+Whether to detokenize the output tokens into text. When set to `true`, token IDs are converted back to readable text strings.
+
+Default: `True`
+
+#### `default_sampling_params.repetition_penalty`
+
+Penalty applied to tokens that have already appeared in the generated sequence. Values greater than 1.0 discourage repetition, while values less than 1.0 encourage it. A value of 1.0 applies no penalty.
+
+Default: `1.1`
+
+### `tts_args` (TTS stages only)
+
+Configuration for Text-to-Speech specific parameters. This section is only applicable to TTS model stages (e.g., `qwen3_tts`).
+
+#### `tts_args.max_instructions_length`
+
+Maximum character length for voice style/emotion instructions. Instructions exceeding this limit will be rejected with a validation error.
+
+Default: `500`
+
+This value can be overridden at runtime using the `--tts-max-instructions-length` CLI parameter when starting the server.
@@ -46,7 +46,7 @@ class Omni:

    Args:
        model: Model name or path
-        deploy_config: Optional path to a deploy configuration
+        stage_configs: Optional stage configurations
        **kwargs: Additional arguments passed to the engine

    Example:
@@ -44,149 +44,6 @@ vLLM-Omni's `pre-commit` hooks will now run automatically every time you commit.
    pre-commit run --show-diff-on-failure --color=always --all-files  # runs on all files (short for --all-files)
    ```

-!!! warning
-    GitHub Actions `pre-commit` **skips** several local gates so a whole-tree
-    `--all-files` run stays green while historical debt is cleaned up. The
-    current `SKIP` list in
-    [`.github/workflows/pre-commit.yml`](https://github.com/vllm-project/vllm-omni/blob/main/.github/workflows/pre-commit.yml)
-    is `check-test-ci-coverage`, `markdownlint-cli2`, `shellcheck`,
-    `check-spdx-header`, and `mypy-3.10`. Those hooks still run on **your
-    commit** for changed files. A passing GitHub pre-commit check does not mean
-    they passed locally. Hooks **not** on that list (forbidden imports,
-    `torch.cuda`, TTS adapter ratchet, Buildkite schema, Ruff, typos, …) run in
-    both places.
-
-The hooks below are new relative to the previous Omni config (Ruff, typos,
-actionlint, YAML/whitespace, DCO sign-off, and the pickle-only checker were
-already there). `check-pickle-imports` is gone: pickle is now one rule inside
-`check-forbidden-imports`.
-
-| Hook id | Enforces | GitHub Actions |
-| ------- | -------- | -------------- |
-| `markdownlint-cli2` | Markdown in `docs/`, `recipes/`, `README.md`, `CONTRIBUTING.md` (not `.claude/` / `.cursor/` / `CLAUDE.md`) | skipped |
-| `mypy-3.10` | Type-check changed `vllm_omni/` files (model trees excluded). `tests/` uses `--follow-imports skip` | skipped |
-| `mypy-3.11` / `3.12` / `3.13` | Same checker, extra Python versions | not installed; `pre-commit run --hook-stage manual mypy-3.12` |
-| `check-test-ci-coverage` | Every `tests/**/test_*.py` has a CI level mark and a hardware mark/helper | skipped |
-| `check-tts-adapter-migration` | `self._tts_model_type` branches in `serving_speech.py` must not increase | runs |
-| `shellcheck` | `*.sh` quoting / undefined vars | skipped |
-| `check-spdx-header` | Omni SPDX header on `.py` / `.pyi` / `.sh` / `.rs` / `.proto` | skipped |
-| `check-forbidden-imports` | pickle, stdlib `re`/`base64`, Triton, TileLang, Hugging Face Hub download/API | runs |
-| `check-torch-cuda-call` | Direct `torch.cuda.*` helpers outside platform adapters | runs |
-| `check-buildkite` | `.buildkite/*.yml` against the Buildkite schema | runs |
-
-Related config (not a new hook id): Ruff `TID251` also bans `librosa` and several
-`torch.cuda.*` names; typos is pinned and ignores git-describe hashes (`+g` +
-hex) and NumPy `writeable`. Keep the `suggestion` hook last in
-`.pre-commit-config.yaml` so autofix output does not bury the SKIP tip.
-
-#### SPDX headers
-
-Source files must start with:
-
-```text
-# SPDX-License-Identifier: Apache-2.0
-# SPDX-FileCopyrightText: Copyright contributors to the vLLM-Omni project
-```
-
-Rust and proto files use `//` instead of `#`. Empty files are exempt. A stale
-`Copyright contributors to the vLLM project` line is **rewritten in place** to
-the Omni copyright; the hook then exits non-zero so you restage the rewrite.
-
-#### Forbidden imports
-
-Under `vllm_omni/`, do not use:
-
- stdlib `re` → `import regex as re`
- stdlib `base64` → `import pybase64` (or `import pybase64 as base64`)
- `pickle` / `cloudpickle` (also banned in most tests)
- `from huggingface_hub import snapshot_download` / `hf_hub_download` / `HfApi`
-  / similar → `vllm.transformers_utils.repo_utils`
- direct `triton` / `tilelang` → `vllm.triton_utils` / `vllm.tilelang_utils`
-
-`examples/`, `tests/`, `benchmarks/`, `apps/`, `docs/`, `tools/`, `scripts/`,
-`.buildkite/`, and `.github/` may keep stdlib `re` and `base64`
-(`_NON_LIBRARY_DIRS`). Pickle is stricter: tests are not exempt unless the
-file is on the pickle allowlist.
-
-#### `torch.cuda` call sites
-
-Prefer `current_omni_platform` / `OmniPlatform`. Platform adapters under
-`vllm_omni/platforms/` are allowed; other files must not add new
-`torch.cuda.*` helpers (`device_count`, `synchronize`, `empty_cache`,
-`device()`, `manual_seed`, and similar). `import torch` is fine.
-
-#### shellcheck
-
-The hook does **not** download a binary. Install `shellcheck` with a signed
-package manager, then re-run:
-
- Debian/Ubuntu/WSL: `sudo apt-get install shellcheck`
- Fedora: `sudo dnf install ShellCheck`
- macOS: `brew install shellcheck`
- Git Bash (MINGW): `scoop install shellcheck` so `shellcheck.exe` is on PATH.
-  WSL is Linux: use `apt-get`, not a Windows `.exe`.
-
-If no native binary is found, the wrapper prints those commands (and
-[the upstream install page](https://github.com/koalaman/shellcheck?tab=readme-ov-file#installing))
-and exits 1. AMD and other vendor scripts are **not** excluded.
-
-#### mypy
-
-`mypy-3.10` runs on commit for changed files. `[tool.mypy]` uses Python 3.12,
-`ignore_missing_imports = true`, and `follow_imports = "silent"`. Wrapper
-`tools/pre_commit/mypy.py` skips `vllm_omni/model_executor/models/` and
-`vllm_omni/diffusion/models/`, and type-checks `tests/` with
-`--follow-imports skip`. Extra versions:
-
-```bash
-pre-commit run --hook-stage manual mypy-3.12
-```
-
-#### Test CI marks
-
-`check-test-ci-coverage` requires each collected test module under `tests/` to
-have at least one CI **level** mark (`core_model`, `advanced_model`,
-`full_model`, `local_model`, or `slow`) and a **hardware** mark (`cpu`, `cuda`,
-`H100`, …) or helper (`hardware_test(` / `hardware_marks(`). GitHub Actions
-skips this hook; local commit does not. See the
-[test writing guide](./ci/test_writing_guide.md).
-
-#### TTS adapter ratchet
-
-`check-tts-adapter-migration` counts `self._tts_model_type` comparisons in
-`vllm_omni/entrypoints/openai/serving_speech.py`. The count must stay at or
-below `MAX_MODEL_TYPE_BRANCHES` in
-[`tools/pre_commit/check_tts_adapter.py`](https://github.com/vllm-project/vllm-omni/blob/main/tools/pre_commit/check_tts_adapter.py).
-New per-model behavior belongs in
-`vllm_omni/entrypoints/openai/tts_adapters/`. Removing branches **must** lower
-the budget in the same change; raising it is a reviewable policy edit.
-
-#### Markdownlint and Buildkite
-
-`markdownlint-cli2` auto-fixes `docs/`, `recipes/`, and the root README /
-CONTRIBUTING (rules in `.markdownlint.yaml`). Skill files under `.claude/` and
-`.cursor/` are excluded.
-
-`check-buildkite` validates `.buildkite/*.yml` against the official schema
-after the same expansion `upload_pipeline.py` uses. Omni-only keys such as
-`mirror_hardwares` are stripped or rendered first. A few files are skipped in
-`SKIP_FILES` inside `tools/pre_commit/check_buildkite.py`.
-
-#### Extending allowlists and budgets
-
-Prefer fixing the call site. Growing an allowlist or raising a budget is a
-policy change and needs review — do not edit these just to make the hook pass.
-
-| Gate | File | What to edit |
-| ---- | ---- | ------------ |
-| pickle, `re`, `base64`, Hugging Face Hub, Triton/TileLang | [`tools/pre_commit/check_forbidden_imports.py`](https://github.com/vllm-project/vllm-omni/blob/main/tools/pre_commit/check_forbidden_imports.py) | `CHECK_IMPORTS[<rule>].allowed_files`. Use `allowed_dirs` only when a whole tree should stay exempt. |
-| `torch.cuda` | [`tools/pre_commit/check_torch_cuda.py`](https://github.com/vllm-project/vllm-omni/blob/main/tools/pre_commit/check_torch_cuda.py) | `ALLOWED_FILES`, or `ALLOWED_PREFIXES` for a platform adapter tree. |
-| TTS `_tts_model_type` branches | [`tools/pre_commit/check_tts_adapter.py`](https://github.com/vllm-project/vllm-omni/blob/main/tools/pre_commit/check_tts_adapter.py) | `MAX_MODEL_TYPE_BRANCHES` (down only, unless the PR justifies a raise). |
-| Buildkite skip list | [`tools/pre_commit/check_buildkite.py`](https://github.com/vllm-project/vllm-omni/blob/main/tools/pre_commit/check_buildkite.py) | `SKIP_FILES` for pipelines that cannot be expanded. |
-
-To skip one hook for a single commit (discouraged): `SKIP=<hook-id> git commit`.
-To bypass every hook: `git commit --no-verify` (also discouraged).
-
 ### Documentation

 MkDocs is a fast, simple and downright gorgeous static site generator that's geared towards building project documentation. Documentation source files are written in Markdown, and configured with a single YAML configuration file, `mkdocs.yml`.
@@ -305,14 +162,12 @@ Only specific types of PRs will be reviewed. The PR title is prefixed appropriat
 Before submitting a PR, run the [precheck-pr skill](https://github.com/vllm-project/vllm-omni/blob/main/.claude/skills/precheck-pr/SKILL.md) with the code agent for a self-review against project conventions:

 The skill offers two modes:
-
 - **Quick (~3 min):** catches showstoppers — PR title format, missing benchmark claims, rebase status
 - **Full (~10 min):** thorough maintainer-grade review — dead code scan, copy-paste detection, import hygiene

 The precheck covers five PR types: Bug Fix, Performance, New Model, Diffusion Model, and General. Each type has a tailored checklist that validates evidence quality (repro steps, A/B benchmarks, registry entries, etc.). See the [precheck-pr skill](https://github.com/vllm-project/vllm-omni/blob/main/.claude/skills/precheck-pr/SKILL.md) for the full checklist.

 ### Local Test
-
 Please run the L1 and L2 test cases locally first and attach the results before contacting us to add the "ready" label. Please refer to the [test instructions](./ci/test_execution_guide.md) for running the test cases.

 ### Automatic skip-ci (docs and pytest skip marks)
@@ -334,7 +189,7 @@ These PR shapes all trigger skip-ci:
 Skip-ci does **not** apply when the diff also touches product code (for example `vllm_omni/`), or when test files change assertions, imports, fixtures, or other non-skip logic. If the diff cannot be resolved (non-PR branches outside `main`), CI runs as usual.

 !!! note
-    Skipping L2/L3 does **not** disable the Docker image build step. Nightly (L4) upload can still run when the PR has a `nightly-test` label or on scheduled `main` builds with `NIGHTLY=1`. Weekly (L5) upload can still run with `weekly-test`, `WEEKLY=1`, or `NON_CRITICAL=1`. Bootstrap child steps live in `bootstrap-upload-steps.yml`; the hook entry step runs `upload_pipeline.py --upload <platform>/bootstrap-upload-steps.yml`, which injects `if` by step `key` from skip-ci before upload. See [CI Settings — Diff-aware CI](./ci/ci_settings.md#diff-aware-ci) and [Test System Overview](./ci/test_system_overview.md).
+    Skipping L2/L3 does **not** disable the Docker image build step. Nightly (L4) upload can still run when the PR has a `nightly-test` label or on scheduled `main` builds with `NIGHTLY=1`. Bootstrap child steps live in `bootstrap-upload-steps.yml`; the hook entry step runs `upload_pipeline.py --upload <platform>/bootstrap-upload-steps.yml`, which injects `if` by step `key` from skip-ci before upload. See [CI Settings — Diff-aware CI](./ci/ci_settings.md#diff-aware-ci) and [Test System Overview](./ci/test_system_overview.md).

 ### Code Quality

@@ -8,7 +8,7 @@ For CI levels (L1–L5) and triggers, see [Test System Overview](./test_system_o

 Canonical layout (prefer these paths for new changes):

-```text
+```
 .buildkite/
 ├── common/                          # Shared across platforms
 │   ├── scripts/
@@ -48,7 +48,7 @@ Canonical layout (prefer these paths for new changes):
    └── scripts/
 ```

-### Placement rules
+**Placement rules**

 | Rule | Detail |
 | ---- | ------ |
@@ -81,14 +81,7 @@ There are still **legacy copies** at `.buildkite/*.yaml` (without the `cuda/` pr
    | L2 | `cuda/test-ready.yml` | `ready` label |
    | L3 | `cuda/test-merge.yml` | `merge-test` label / main merge |
    | L4 | `cuda/test-nightly.yml` | `nightly-test` label or `NIGHTLY=1` |
-    | L5 | `cuda/test-weekly.yml` | `weekly-test` label, `WEEKLY=1`, or `NON_CRITICAL=1` (see step `if`s below) |
-
-    On scheduled `main` builds, `test-weekly.yml` is uploaded when **`WEEKLY=1` or `NON_CRITICAL=1`**. Inside that file:
-
-    - **Reliability** / **Perf Test** / **Simple · CPU Coverage Test** → `WEEKLY=1` (or PR label `weekly-test` for Reliability/Perf). Pipeline upload for scheduled env vars still requires `main`.
-    - **E2E Tests** group (slow Omni/TTS/Diffusion sweeps) → `NON_CRITICAL=1`
-
-    **`--e2e`:** when uploading ready/merge on `main` with **`WEEKLY=1`**, bootstrap passes `--e2e` so only the **E2E Test** group is kept (same flag `run_cov_split.sh` uses to enable per-model coverage).
+    | L5 | `cuda/test-weekly.yml` | `weekly-test` label or `WEEKLY=1` |

    **Upload:** `upload_pipeline.py --upload` expands uploader-only keys before Buildkite upload.

@@ -119,8 +112,6 @@ There are still **legacy copies** at `.buildkite/*.yaml` (without the `cuda/` pr

    **Test YAML:** `npu/test-npu-ready.yml` (L2), `test-npu-nightly.yml` (L4).

-    **L2 trigger:** PR label `ready` (CUDA/AMD L2). PR labels `ready` + `npu-test` trigger NPU CI only.
-
    **Upload:** same as CUDA—`upload_pipeline.py --upload`.

    **Hardware in YAML:** `mirror_hardwares` preset (string), expanded to `agents`, top-level `image`, and `plugins`. Presets: `a2b3_npu_1`, `a2b3_npu_4`, `a3_npu_2` in `common/ci_mirror_hardwares.yml`.
@@ -213,15 +204,15 @@ Label triggers (`ready`, `merge-test`) are unchanged—diff-aware logic only red
 | Diff shape | Path | Default L2/L3 |
 | --- | --- | --- |
 | Product code / non-whitelisted paths | normal CI | all on |
-| Docs and/or qualifying skip-mark only | `skip_all` | all off (scheduled `main` NIGHTLY/WEEKLY/`NON_CRITICAL` exceptions below) |
+| Docs and/or qualifying skip-mark only | `skip_all` | all off (scheduled `main` NIGHTLY/WEEKLY exceptions below) |
 | Whitelisted CI YAML only | yaml-gated (`skip_l2_l3`) | per platform/level matrix |
 | Docs/skip-mark **+** whitelisted CI YAML | yaml-gated (`skip_l2_l3`) | same as CI-YAML-only (does **not** widen to normal CI) |
 | Non-qualifying skip-mark and no CI YAML | normal CI | all on |
 | Diff unavailable | normal CI | all on |

-**`skip_all` exceptions (CUDA/NPU bootstrap only):** PR labels (`nightly-test`, `merge-test`, `weekly-test`, `ready`, …) do **not** revive jobs under `skip_all`. On `main`, scheduled `NIGHTLY=1` still builds the image and uploads L4; `WEEKLY=1` or `NON_CRITICAL=1` still builds the image and uploads L5 (CUDA). `WEEKLY=1` on `main` also uploads L2/L3 with `--e2e`.
+**`skip_all` exceptions (CUDA/NPU bootstrap only):** PR labels (`nightly-test`, `merge-test`, `npu-test`, `weekly-test`, …) do **not** revive jobs. On `main`, scheduled `NIGHTLY=1` still builds the image and uploads L4 plus L2/L3 (with `--e2e`); `WEEKLY=1` still builds the image and uploads L5 (CUDA).

-**Yaml-gated nightly/weekly:** L4/L5 upload steps keep their normal label / `NIGHTLY` / `WEEKLY` / `NON_CRITICAL` conditions (for example PR `nightly-test` still uploads nightly). Only L2/L3 upload steps are matrix-gated.
+**Yaml-gated nightly/weekly:** L4/L5 upload steps keep their normal label / `NIGHTLY` / `WEEKLY` conditions (for example PR `nightly-test` still uploads nightly). Only L2/L3 upload steps are matrix-gated.

 ##### Whitelisted CI YAML → platform

@@ -294,12 +285,12 @@ CUDA **L2** (`.buildkite/cuda/test-ready.yml`) and **L3** (`.buildkite/cuda/test
 | `source_file_dependencies` | List of path **prefixes**. If any changed file equals a prefix or starts with `prefix/`, keep the step (or group); otherwise omit it. |
 | `mirror_hardwares` | Expand to `agents` + `plugins` (+ optional `image`) from `ci_mirror_hardwares.yml`. |

-### Policy
+**Policy**

 - **Always uploaded** (no key): groups outside **E2E Test**—Simple Test, Diffusion unit tests, Engine/Model Executor, Distributed, Custom Pipeline, Entrypoints (L2), LoRA / Entrypoints (L3).
 - **Diff-gated**: every **E2E Test** leaf job. List the smallest prefix set per step—pytest file(s), model code under `vllm_omni/model_executor/models/` or `vllm_omni/diffusion/models/`, plus `stage_input_processors/` and `vllm_omni/deploy/*.yaml` when applicable. A **group** may define the key instead; the whole group drops if no prefix matches.

-### YAML examples
+**YAML examples**

 ```yaml
      - label: "Diffusion · Qwen Image Test"
@@ -321,7 +312,7 @@ CUDA **L2** (`.buildkite/cuda/test-ready.yml`) and **L3** (`.buildkite/cuda/test
        mirror_hardwares: l4_4
 ```

-### Local dry-run
+**Local dry-run**

 ```bash
 python3 .buildkite/common/scripts/upload_pipeline.py .buildkite/cuda/test-ready.yml
@@ -333,19 +324,18 @@ On PR builds, `upload_pipeline.py` logs `skip '…' (no changes under …)` for

 ### Labels and grouping

- Use **groups** for dashboard readability; keep **E2E Test** as the group name CUDA diff filtering expects for `--e2e` weekly runs on main (`WEEKLY=1`).
+- Use **groups** for dashboard readability; keep **E2E Test** as the group name CUDA diff filtering expects for `--e2e` nightly runs on main.
 - Prefix labels by model domain: **Omni ·**, **TTS ·**, **Diffusion ·**, **Simple ·**, etc., matching existing steps.

 ### Per-model coverage

 Pilot (v1): one Merge-tier (L3) job in `.buildkite/cuda/test-merge.yml` uploads
 per-model, per-entry-mode coverage as Buildkite artifacts — "TTS · Qwen3-TTS Base
-Test". Coverage + artifact upload run only when bootstrap uploaded that job with
-`--e2e` (`WEEKLY=1` and `BUILDKITE_BRANCH=main`, via `run_cov_split.sh`); otherwise
-the same job runs plain pytest without `--cov`. It runs on a single GPU so the
-pilot is cheap to reproduce.
-
-**L1 package coverage (CPU):** ready/merge Simple Test jobs run without `--cov`. Scheduled weekly on `main` with `WEEKLY=1` runs **Simple · CPU Coverage Test** in `.buildkite/cuda/test-weekly.yml` (`pytest -m 'core_model and cpu'` + Cobertura XML artifact).
+Test". It runs on a single GPU so the pilot is cheap to reproduce. (A second
+diffusion pilot, "Diffusion · Bagel Test", was retired from merge; reintroduce
+another diffusion coverage job if a second pilot is needed again.) This is a
+pilot, not a rollout: no dashboard/visualization lives in this repo, and nothing
+is gated on coverage.

 **Naming convention**: `coverage-<model_id>-<mode>-<step_id>.xml.gz`, where
 `<model_id>` is the model's directory name under
@@ -364,8 +354,8 @@ imported. A run covering zero lines produces the same 7 MB. gzip takes it to
 roughly 410 KB and changes nothing about the data.

 `<step_id>` is what keeps two steps that cover the same model apart. Artifacts are
-scoped to the build, and a weekly build can carry ready/merge (with `--e2e`) and
-weekly tiers at once, so several same-model steps land in one namespace — `qwen3_tts` already has
+scoped to the build, and a nightly build carries the ready, merge and nightly tiers
+at once, so several same-model steps land in one namespace — `qwen3_tts` already has
 both a Base and a CustomVoice job, and `minicpmo_4_5` a base and a duplex one. Two
 uploads on one path do not fail loudly: an exact-name download can report the path
 as ambiguous, and a glob download fetches every match concurrently and renames each
@@ -435,7 +425,7 @@ just confirming both files exist.
 | Check | Command / location |
 | ----- | ------------------ |
 | CUDA render | `python3 .buildkite/common/scripts/upload_pipeline.py .buildkite/cuda/test-<level>.yml` |
-| No leaked uploader keys | Pipe the render into `grep -E 'mirror_hardwares\|source_file_dependencies'` — expect empty |
+| No leaked uploader keys | `… \| grep -E 'mirror_hardwares|source_file_dependencies'` → empty |
 | Skip-ci / upload unit tests | `pytest tests/buildkite/` |
 | Local job replay (CUDA L2+) | `tools/run_ready_jobs.sh`, `tools/run_merge_jobs.sh`, `tools/nightly/run_nightly_jobs.sh` (read YAML from `cuda/`) |

@@ -6,7 +6,7 @@ When you open a PR against vLLM-Omni, several CI checks run automatically:

 | Check | Platform | What it does |
 | ----- | -------- | ------------ |
-| **pre-commit** | GitHub Actions | Runs Ruff, formatting, typos, YAML validation, forbidden imports, `torch.cuda`, TTS adapter ratchet, and Buildkite schema. Local-only gates (SPDX, shellcheck, markdownlint, mypy-3.10, test marks) are in the workflow `SKIP` env — see [Linting](../README.md#linting). |
+| **pre-commit** | GitHub Actions | Runs linting (Ruff), formatting, spell-checking (typos), and YAML validation. |
 | **Build Wheel** | GitHub Actions | Builds Python wheels for Python 3.11 and 3.12 on Ubuntu. Skipped for docs-only or Markdown-only changes (controlled by `paths-ignore` in the workflow). |
 | **DCO** | GitHub | Verifies every commit has a `Signed-off-by` line. |
 | **docs/readthedocs.org:vllm-omni** | Read the Docs | Builds the MkDocs documentation site. |
@@ -29,13 +29,6 @@ pre-commit run --all-files

 Then commit the fixes and push.

-A green GitHub pre-commit job can still miss SPDX, shellcheck, mypy-3.10,
-markdownlint, and test-mark coverage because CI skips those IDs. If your
-**local** commit hook fails, follow [Linting](../README.md#linting) for the
-full hook list (forbidden imports, `torch.cuda`, TTS adapter ratchet, and
-Buildkite schema still run in GHA). Do not grow allowlists or raise
-`MAX_MODEL_TYPE_BRANCHES` without review.
-
 ### DCO failures

 Every commit must include a `Signed-off-by` line. If you forgot, amend your commits:
@@ -1,8 +1,8 @@
-#### Scope
+**Scope**

 For diffusion models, the L4 functionality test covers all or common *diffusion features* that are supported by this model, including several [parallelism acceleration methods](https://docs.vllm.ai/projects/vllm-omni/en/latest/user_guide/diffusion/parallelism_acceleration/), [CPU offloading](https://docs.vllm.ai/projects/vllm-omni/en/latest/user_guide/diffusion/cpu_offload/), [TeaCache](https://docs.vllm.ai/projects/vllm-omni/en/latest/user_guide/diffusion/teacache/) and [Cache-DiT](https://docs.vllm.ai/projects/vllm-omni/en/latest/user_guide/diffusion/cache_dit_acceleration/) cache backends, [quantization methods](https://docs.vllm.ai/projects/vllm-omni/en/latest/user_guide/quantization/overview/).

-#### Test Case Design
+**Test Case Design**

 For a *high priority* model (currently listed in [issue #1832](https://github.com/vllm-project/vllm-omni/issues/1832)), we use several test cases, each with multiple features turned on, so that each supported feature is tested in at least one test case. This is to relieve the GPU workload on the CI machine. The suggested test case combination is as follows:

@@ -34,12 +34,12 @@ For a *normal priority* model, further reduce the number of test cases.

 Currently all the features are available in online serving mode. Hence, only need to add `tests/e2e/online_serving/test_{model}_expansion.py`.

-#### Code Style
+**Code Style**

- Validation: test that the multimodal output files of your model have the correct shapes. `OnlineOmniClient.send_diffusion_request` should have taken care of this.
+- Validation: test that the multimodal output files of your model have the correct shapes. `OpenAIClientHandler.send_diffusion_request` should have taken care of this.
 - Test marks: always add `full_model` and `diffusion` for L4 nightly `test_*_expansion.py` cases. Add GPU-related marks if needed. Ref: [Markers for Tests](https://docs.vllm.ai/projects/vllm-omni/en/latest/contributing/ci/test_writing_guide/#markers-for-tests).
 - To maximize code reuse, you may refer to
-    - `tests/conftest.py` for `omni_server` (running server in subprocess) and `online_client` fixtures (sending requests and validating output), `generate_synthetic_image` and `assert_XXX_valid` helper.
+    - `tests/conftest.py` for `omni_server` (running server in subprocess) and `openai_client` fixtures (sending requests and validating output), `generate_synthetic_image` and `assert_XXX_valid` helper.
    - `tests/helpers/mark.py` for `@hardware_test(...)` and `hardware_marks`.
    - [Parametrizing tests (pytest doc)](https://docs.pytest.org/en/stable/example/parametrize.html) to reuse test function implementation for different cases.
 - Doc: add a concise docstring for each test function.
@@ -1,15 +1,14 @@
 When you want to add L4-level ***performance test*** cases, add entries to JSON files under `tests/dfx/perf/tests/` and run them via `tests/dfx/perf/scripts/run_benchmark.py` (omni / TTS) or `run_diffusion_benchmark.py` (diffusion).

-#### Config file layout (in-tree examples)
+**Config file layout (in-tree examples)**

 | Model type | Runner | Example JSON files |
 | ---------- | ------ | ------------------ |
-| Omni (nightly) | `run_benchmark.py` | `test_qwen3_omni_no_async_chunk.json`, `test_qwen3_omni_async_chunk.json` (`full_model` without `slow` in `mark`) |
-| Omni (weekly) | `run_benchmark.py` | `test_qwen3_omni_async_chunk.json` (CUDA only), `test_qwen3_omni_vllm_text.json`, `test_qwen3_omni_multi_replicas.json` (`slow` in `mark`; **Perf Test** in `test-weekly.yml`) |
+| Omni | `run_benchmark.py` | `test_qwen3_omni_no_async_chunk.json`, `test_qwen3_omni_async_chunk.json`, `test_qwen3_omni_vllm_text.json`, `test_qwen3_omni_multi_replicas.json` |
 | TTS | `run_benchmark.py` | `test_tts.json`, `test_voxcpm2.json`, `test_higgs_audio_v3.json` |
 | Diffusion | `run_diffusion_benchmark.py` | `test_qwen_image_vllm_omni.json`, `test_bagel_vllm_omni.json`, `test_wan22_i2v_vllm_omni.json`, `test_cosmos3_vllm_omni.json`, … |

-#### How runners pick cases
+**How runners pick cases**

 Without **`--test-config-file`**, each runner scans all `*.json` under `tests/dfx/perf/tests/` but only keeps its own model type:

@@ -18,9 +17,9 @@ Without **`--test-config-file`**, each runner scans all `*.json` under `tests/df

 Diffusion cases are detected when the JSON has `server_type` (typically `"vllm-omni"`) or `"diffusion"` in the `mark` array. Omni / TTS JSON has neither.

-#### Running perf cases
+**Running perf cases**

-Pass **`--test-config-file`** to load one JSON file, or omit it for the bulk scan above. In either mode, pytest **`-m`** filters each case using its JSON `mark`. A single file can contain nightly, weekly, and platform-specific case objects. For example, the nightly object in `test_qwen3_omni_async_chunk.json` declares both H100 and A3, while its `slow` weekly object is CUDA-only; there is no NPU weekly counterpart. Use `-m "H100 and full_model and not slow"`, `-m "H100 and full_model and slow"`, or `-m "npu"` to select the intended schedule and platform.
+Pass **`--test-config-file`** to run one JSON file as-is, or omit it for the bulk scan above and filter with pytest **`-m`** on each case's JSON `mark` (for example `pytest … run_benchmark.py -m "full_model and tts and H100"`).

 ```JSON
 {
@@ -32,7 +31,7 @@ Pass **`--test-config-file`** to load one JSON file, or omit it for the bulk sca
    ],
    "server_params": {
        "model": "Qwen/Qwen3-Omni-30B-A3B-Instruct",
-        "stage_config_name": "qwen3_omni_moe.yaml"
+        "stage_config_name": "qwen3_omni.yaml"
    },
    "benchmark_params": [
        {
@@ -56,26 +55,24 @@ Pass **`--test-config-file`** to load one JSON file, or omit it for the bulk sca
 }
 ```

-#### Parameter Explanation
+**Parameter Explanation**

-##### Overview
+*Overview*

-| Field              | Required       | Description                                  |
-| ------------------ | -------------- | -------------------------------------------- |
-| test_name          | Yes            | Unique identifier for the test case          |
-| mark               | No             | Pytest marks; see **`mark` field** below     |
-| server_params      | Yes            | Server-side configuration parameters         |
-| benchmark_params   | Yes            | Benchmark running parameters                 |
-| server_type        | Diffusion only | Routes case to run_diffusion_benchmark.py    |
-| benchmark_endpoint | Diffusion only | Benchmark API path                           |
+| Field            | Required | Description                                                     |
+| ---------------- | -------- | --------------------------------------------------------------- |
+| test_name        | Yes      | Unique identifier for the test case                             |
+| mark             | No       | Pytest marks for this case (see **`mark` field** below). Omit only for configs not meant to be filtered by `-m`. |
+| server_params    | Yes      | Server-side configuration parameters                            |
+| benchmark_params | Yes      | Benchmark running parameters (supports multiple configurations) |
+| server_type      | Diffusion only | When set (e.g. `"vllm-omni"`), routes the case to `run_diffusion_benchmark.py`. |
+| benchmark_endpoint | Diffusion only | API path for the benchmark client (e.g. `/v1/videos`, `/v1/images/generations`). |

-Omit `mark` only for configs not meant to be filtered by `-m`. `server_type` is typically `"vllm-omni"`. `benchmark_endpoint` examples: `/v1/videos`, `/v1/images/generations`.
-
-#### `mark` field
+**`mark` field**

 Optional top-level field on each perf JSON **case object** (one per `test_name`). `run_benchmark.py` and `run_diffusion_benchmark.py` read it via `tests.dfx.conftest.resolve_pytest_marks` and attach the marks to the corresponding `pytest.param`, so you can filter locally with `-m`.

-When `mark` is present, it must be an **array** with exactly one ``hardware_marks`` object (same shape as `@hardware_test` / `hardware_marks()` in `tests/helpers/mark.py`), followed by registered pytest marker name strings such as `full_model`, `slow`, `omni`, `tts`, `diffusion`, or `local_model`.
+When `mark` is present, it must be an **array** with exactly one ``hardware_marks`` object (same shape as `@hardware_test` / `hardware_marks()` in `tests/helpers/mark.py`), followed by registered pytest marker name strings such as `full_model`, `omni`, `tts`, `diffusion`, or `local_model`.

 Supported form:

@@ -122,11 +119,11 @@ Multi-GPU diffusion (example: Cosmos3 with `cfg-parallel-size=2`):
 - Diffusion perf: include `"diffusion"` in the `mark` array
 - HunyuanImage local-weight cases: add `"local_model"` to the `mark` array

-#### Parametrization IDs
+**Parametrization IDs**

 Each `(server, benchmark index)` pair becomes one `pytest.param` with id `{test_name}-{suffix}`. The suffix comes from `benchmark_params[].name` when set (for example `test_tts-p0`, `test_omni-p1`); otherwise it is derived from fields like `task` / `eval_phase`.

-#### Benchmark result filenames
+**Benchmark result filenames**

 Result files use the **runtime** hardware label from `get_runtime_resource_label()` (detected GPU/NPU name on the machine that ran the job), **not** `mark.hardware_marks.res`. On the default H100 CI pool, `H100` is **omitted** from filenames (`resource_label_for_filename`).

@@ -135,40 +132,32 @@ Examples:
 - Omni/TTS: `result_{test_name}_{optional_hw}_{dataset}_....json` under `BENCHMARK_DIR`
 - Diffusion: one aggregate `diffusion_result_{config_stem}_{optional_hw}_{timestamp}.json` per source JSON file (array of all runs from that file)

-#### Local commands
+**Local commands**

 ```bash
 # Bulk load + filter by JSON mark
 pytest -s -v tests/dfx/perf/scripts/run_diffusion_benchmark.py -m "full_model and H100 and diffusion"
 pytest -s -v tests/dfx/perf/scripts/run_benchmark.py -m "full_model and omni and H100"

-# Single file (same selectors as the CI Perf steps)
+# Single file (same as nightly CI Perf steps)
 pytest -s -v tests/dfx/perf/scripts/run_diffusion_benchmark.py \
  --test-config-file tests/dfx/perf/tests/test_bagel_vllm_omni.json
 pytest -s -v tests/dfx/perf/scripts/run_benchmark.py \
-  --test-config-file tests/dfx/perf/tests/test_qwen3_omni_async_chunk.json \
-  -m "H100 and full_model and not slow"
-pytest -s -v tests/dfx/perf/scripts/run_benchmark.py \
-  --test-config-file tests/dfx/perf/tests/test_qwen3_omni_async_chunk.json \
-  -m "H100 and full_model and slow"
-pytest -s -v tests/dfx/perf/scripts/run_benchmark.py \
-  --test-config-file tests/dfx/perf/tests/test_qwen3_omni_async_chunk.json \
-  -m "npu"
+  --test-config-file tests/dfx/perf/tests/test_qwen3_omni_async_chunk.json
 ```

-<!-- markdownlint-disable-next-line MD051 -->
 See also [Markers for Tests](#markers-for-tests) for registered hardware markers (`H100`, `L4`, `cuda`, `distributed_cuda`, …).

-#### `server_params` Configuration
+**`server_params` Configuration**

-##### Basic Parameters
+*Basic Parameters*

-| Parameter         | Required | Example                   | Description                    |
-| ----------------- | -------- | ------------------------- | ------------------------------ |
-| model             | Yes      | Qwen/Qwen3-Omni-30B-A3B…  | Model name or path             |
-| stage_config_name | Yes      | qwen3_omni_moe.yaml       | Deploy configuration file name |
+| Parameter         | Required | Example                            | Description                   |
+| ----------------- | -------- | ---------------------------------- | ----------------------------- |
+| model             | Yes      | "Qwen/Qwen3-Omni-30B-A3B-Instruct" | Model name or path            |
+| stage_config_name | Yes      | "qwen3_omni.yaml"                  | Stage configuration file name |

-##### Dynamic Configuration (update/delete)
+*Dynamic Configuration (update/delete)*

 Supports incremental modifications based on the basic configuration:

@@ -177,40 +166,38 @@ Supports incremental modifications based on the basic configuration:
 | update    | Update or add configuration items    |
 | delete    | Delete specified configuration items |

-##### Example
+**Example**:

-```json
+```
 "update": {
    "async_chunk": true,  // Enable asynchronous chunk processing
-    "stages": {
+    "stage_args": {
        "0": {
-            "max_num_seqs": 64
+            "engine_args.custom_process_next_stage_input_func": "vllm_omni.model_executor.stage_input_processors.qwen3_omni.thinker2talker_async_chunk"
        }
    }
 },
 "delete": {
-    "stages": {
-        "2": ["max_num_batched_tokens"]  // Delete this deploy override for stage 2
+    "stage_args": {
+        "2": ["custom_process_input_func"]  // Delete this configuration for stage 2
    }
 }
 ```

-#### `benchmark_params` Configuration
+**`benchmark_params` Configuration**

 You can add any benchmark running parameters you need here. For all optional parameters, refer to the [benchmark documentation](https://github.com/vllm-project/vllm-omni/blob/main/docs/cli/bench/serve.md). General modifications are as follows:

-1. Change the --xxx-xx-xx running parameters to xxx_xx_xx format and fill them as keys in the JSON file.
-2. For boolean variables in the running parameters, modify them to forms such as ignore_eos: true/false and fill them into the JSON file.
-3. Optionally add a `baseline` object (see **Baseline thresholds** below). If you omit `baseline` or leave it empty, the performance test still runs but does not assert metric thresholds from this field.
-4. Set `"name"` on each `benchmark_params` entry for stable pytest ids and readable result keys.
-5. The qps and concurrency modes are recommended to be mutually exclusive. For detailed explanations, see the table below:
+1.  Change the --xxx-xx-xx running parameters to xxx_xx_xx format and fill them as keys in the JSON file.
+2.  For boolean variables in the running parameters, modify them to forms such as ignore_eos: true/false and fill them into the JSON file.
+3.  Optionally add a `baseline` object (see **Baseline thresholds** below). If you omit `baseline` or leave it empty, the performance test still runs but does not assert metric thresholds from this field.
+4.  Set `"name"` on each `benchmark_params` entry for stable pytest ids and readable result keys.
+5.  The qps and concurrency modes are recommended to be mutually exclusive. For detailed explanations, see the table below:

-| Parameter       | Type          | Required | Example/Values       | Description                          |
-| --------------- | ------------- | -------- | -------------------- | ------------------------------------ |
-| name            | string        | No       | `"1024x1024_steps4"` | Stable suffix for pytest param id    |
-| num_prompts     | int / array   | Yes      | 10, [10, 20, 30]     | Number of requests (scalar or sweep) |
-| request_rate    | float / array | No       | 0.5, [0.5, 1, inf]   | Queries per second (QPS mode)        |
-| max_concurrency | int / array   | No       | 1, [1, 2, 3]         | Max in-flight requests               |
-| baseline        | object        | No       | see below            | Optional hardware-nested thresholds  |
-
-`num_prompts`, `request_rate`, and `max_concurrency` accept scalars or arrays; single values expand to match sweep length. QPS and concurrency modes are mutually exclusive. `baseline` top-level keys must be hardware pytest markers from `pyproject.toml`; metric names and values are free-form (scalars or sweep-aligned lists). Omit `baseline` to run without threshold assertions.
+| Parameter       | Type        | Required | Example/Values  | Description                                                                                                                                                                                                                                                          |
+| --------------- | ----------- | -------- | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| name            | string      | No       | `"1024x1024_steps4"` | Stable suffix for pytest param id and logs. |
+| num_prompts     | int / array | Yes      | 10,[10, 20, 30] | Number of requests. Supports single values or arrays. If a single value is used, it will be automatically expanded to match the number of qps or max_concurrency, e.g., [10,10,10]. If an array is used, its length must match the number of qps or max_concurrency. |
+| request_rate    | float / array | No  | 0.5, [0.5, 1, inf] | Queries per second. Supports single values or arrays. If a single value is used, it will be automatically expanded to match the number of num_prompts, e.g., [1,1,1]. If an array is used, its length must match the number of num_prompts.                          |
+| max_concurrency | int / array | No       | 1, [1, 2, 3]    | Maximum concurrent in-flight requests. Same array / expansion rules as `request_rate` (mutually exclusive with QPS mode).                                                                                                                                                                                                             |
+| baseline        | object      | No       | see below       | Optional thresholds. **Hardware-nested only**: top-level keys must be `[hardware-resource]` pytest markers from `pyproject.toml` (`get_hardware_mark_list()`). Under each hardware key, metric names are free-form; values are scalars or sweep-aligned lists. Example: `{"H100": {"throughput_qps": […], "custom_stage_ms": 1.0}, "A3": {…}}`. Runtime filename aliases (`_RUNTIME_DEVICE_ALIASES`) are separate and do not expand this allowlist. |
@@ -1,20 +1,13 @@
 # Test Execution Guide
-
 ## Setting Up the Test Environment
-
 ### Creating a Container
-
 vLLM-Omni provides an official Docker image for deployment. These images are built upon vLLM Docker images and are available on [Docker Hub](https://hub.docker.com/r/vllm/vllm-omni/tags). The version of vLLM-Omni indicates which vLLM release it is based on.
 For a local test environment, you can follow the steps below to create a container:
-
 ## Installing Dependencies
-
 ### vLLM & vLLM-Omni
-
 vLLM-Omni is built based on vLLM. You can follow [install guide](../../getting_started/installation/README.md) to build your local environment.

 ### Test Case Dependencies
-
 When running test cases, you may need to install the following dependencies:

 ```bash
@@ -23,7 +16,6 @@ apt-get install -y espeak-ng jq
 ```

 ## Running Tests
-
 Our test scripts use the pytest framework. First, please use `git clone https://github.com/vllm-project/vllm-omni.git` to download the vllm-omni source code. Then, in the root directory of vllm-omni, you can run the following commands in your local test environment to execute the corresponding test cases.

 ### CI job runners (L2–L4): logs, timing, and timeouts
@@ -33,7 +25,7 @@ Our test scripts use the pytest framework. First, please use `git clone https://
 **Log layout** (default under `logs/ready_jobs`, `logs/merge_jobs`, or `logs/nightly_jobs`; override with `--log-dir`):

 | Path | Description |
-| ------ | ------------- |
+|------|-------------|
 | `jobs/*.sh` | Generated per-step bash wrappers |
 | `jobs/.job_timeouts` | Job key → `timeout_in_minutes` from Buildkite YAML (when set) |
 | `<job_key>.log` | Tee output for each job |
@@ -41,7 +33,7 @@ Our test scripts use the pytest framework. First, please use `git clone https://

 **Timing:** while each job runs, stderr prints `finished in …` or `failed after …`. When all jobs finish, a summary is printed and written to `timing_summary.log`, for example:

-```text
+```
 === Job timing summary ===
  TTS_VoxCPM2_Test  25m 40s  OK
  Omni_Qwen3-Omni_Test  8m 05s  TIMED OUT
@@ -122,6 +114,7 @@ Failed jobs: 1/2
    pytest -s -v -m "advanced_model and distributed_cuda and L4" --run-level=advanced_model
    ```

+
 === "L4 level"

    **Recommended:** run CI-aligned nightly jobs from the repo root via [`tools/nightly/run_nightly_jobs.sh`](https://github.com/vllm-project/vllm-omni/blob/main/tools/nightly/run_nightly_jobs.sh). The script reads [`.buildkite/cuda/test-nightly.yml`](https://github.com/vllm-project/vllm-omni/blob/main/.buildkite/cuda/test-nightly.yml), generates per-step bash wrappers, runs pytest (perf jobs first, then aggregates perf JSON into Excel), and tees logs under `logs/nightly_jobs/` (see [CI job runners](#ci-job-runners-l2l4-logs-timing-and-timeouts); `generate_nightly_perf_excel` is included in the timing summary). Requires `bash`, `python3`, and PyYAML (`pip install pyyaml`).
@@ -167,7 +160,7 @@ Failed jobs: 1/2
    pytest -sv tests/dfx/perf/scripts/run_benchmark.py --test-config-file tests/dfx/perf/tests/test_tts.json
    pytest -sv tests/dfx/perf/scripts/run_diffusion_benchmark.py --test-config-file tests/dfx/perf/tests/test_cosmos3_vllm_omni.json
    ```
-    Nightly **Perf Test** jobs in [``test-nightly.yml``](https://github.com/vllm-project/vllm-omni/blob/main/.buildkite/cuda/test-nightly.yml) use ``--test-config-file`` only (no ``-m``). Weekly **Perf Test** in [``test-weekly.yml``](https://github.com/vllm-project/vllm-omni/blob/main/.buildkite/cuda/test-weekly.yml) runs ``test_qwen3_omni_vllm_text.json`` and ``test_qwen3_omni_multi_replicas.json`` (JSON ``mark`` includes ``slow``). E2e L4 function tests use ``full_model`` + ``--run-level full_model``. Example:
+    Nightly **Perf Test** jobs in ``test-nightly.yml`` use ``--test-config-file`` only (no ``-m``). E2e L4 function tests still use ``full_model`` + ``--run-level full_model`` (see [test-nightly.yml](https://github.com/vllm-project/vllm-omni/blob/main/.buildkite/test-nightly.yml)). Example:

 === "L5 level"

@@ -191,15 +184,14 @@ Failed jobs: 1/2
    # Reliability: HunyuanImage DiT (H100 × 4)
    pytest -s -v dfx/reliability/test_reliability_hunyuan_image.py -m slow

+    # Reliability: VoxCPM2 (L4)
+    pytest -s -v dfx/reliability/test_reliability_voxcpm2.py -m slow
+
    ```

-    The latest L5 CI jobs are in [test-weekly.yml](https://github.com/vllm-project/vllm-omni/blob/main/.buildkite/cuda/test-weekly.yml):
-
-    - **Reliability** (+ invalid-parameter), **Perf Test** (Omni vLLM Text / Multi-Replica), and **Simple · CPU Coverage Test** → `WEEKLY=1` (or PR label `weekly-test` for Reliability/Perf). Scheduled upload of those env-gated steps still requires `main`.
-    - **E2E Tests** (slow Omni / TTS / Diffusion sweeps) → `NON_CRITICAL=1` (pipeline upload also accepts `WEEKLY=1` / `weekly-test`; the group `if` still needs `NON_CRITICAL`)
+    The latest L5 CI jobs (reliability + invalid-parameter weekly steps) are in [test-weekly.yml](https://github.com/vllm-project/vllm-omni/blob/main/.buildkite/cuda/test-weekly.yml).

 You can find more information about markers in [Test Writing Guide — Markers for Tests](./test_writing_guide.md#markers-for-tests).

 ## Adding New Test Cases
-
 Please refer to the [Test System Overview](./test_system_overview.md) and [Test Writing Guide](./test_writing_guide.md).
@@ -12,7 +12,8 @@ Through five levels (L1-L5) and common (Common) specifications, the system clari
      <th>Level</th>
      <th>Scope & Focus</th>
      <th>Model Coverage Strategy</th>
-      <th>Module Strategy</th>
+      <th>Feature Coverage Strategy</th>
+      <th>Interface Coverage Strategy</th>
      <th>Tags</th>
      <th>Time Cost</th>
      <th>Test Dir</th>
@@ -30,6 +31,7 @@ Through five levels (L1-L5) and common (Common) specifications, the system clari
      <td>/</td>
      <td>/</td>
      <td>/</td>
+      <td>/</td>
      <td><a href="https://github.com/vllm-project/vllm-omni/blob/main/.github/PULL_REQUEST_TEMPLATE.md">PR Checklist</a></td>
      <td>/</td>
      <td>/</td>
@@ -41,6 +43,7 @@ Through five levels (L1-L5) and common (Common) specifications, the system clari
      <td>/</td>
      <td>/</td>
      <td>/</td>
+      <td>/</td>
      <td><a href="./failures.md">CI Failures</a></td>
      <td>/</td>
      <td>/</td>
@@ -50,6 +53,7 @@ Through five levels (L1-L5) and common (Common) specifications, the system clari
      <td>Unit tests for components like entrypoints, models</td>
      <td>/</td>
      <td>/</td>
+      <td>/</td>
      <td><code>core_model and cpu</code></td>
      <td rowspan="2">&lt;15min</td>
      <td>
@@ -67,8 +71,9 @@ Through five levels (L1-L5) and common (Common) specifications, the system clari
    <tr>
      <td><strong>L2</strong><br>(E2E across models & GPU-required UT)</td>
      <td>Online (basic deployment scenarios):<br>dummy, normal inference function (output format, stream), some instance startup UT</td>
-      <td>Key models + online basic scenarios; request success, non-empty output, format match (no Whisper/accuracy)</td>
-      <td>Key features and modules that require launching instances (prefer random weights)</td>
+      <td>High-priority models + online basic scenarios; request success, non-empty output, format match (no Whisper/accuracy)</td>
+      <td>High-priority features and component tests that require launching instances</td>
+      <td>High-priority interfaces (using random lightweight models)</td>
      <td><code>core_model and hardware_test(H100, L4, etc.) and omni/tts/diffusion</code></td>
      <td>
        <strong>Model E2E:</strong><br>
@@ -90,8 +95,9 @@ Through five levels (L1-L5) and common (Common) specifications, the system clari
    <tr>
      <td><strong>L3</strong><br>(Important Perf & Integration & Accuracy)</td>
      <td>Online & Offline (multiple deployment scenarios):<br>real model, normal inference function, normal accuracy</td>
-      <td>Key models + key online/offline scenarios; real weights, Whisper/similarity, preset voice gender, basic accuracy</td>
-      <td>Key features and modules that require launching instances (using real weights)</td>
+      <td>High/medium-priority models + key online/offline scenarios; real weights, Whisper/similarity, preset voice gender, basic accuracy</td>
+      <td>Medium-priority features and component tests that require launching instances</td>
+      <td>Medium-priority interfaces (using random lightweight models)</td>
      <td><code>advanced_model and hardware_test(H100, L4, etc.) and omni/tts/diffusion</code></td>
      <td>&lt;30min</td>
      <td>
@@ -114,8 +120,9 @@ Through five levels (L1-L5) and common (Common) specifications, the system clari
    <tr>
      <td><strong>L4</strong><br>(Perf & Integration & Accuracy)</td>
      <td>Online: full functional scenarios + performance test + doc test + accuracy test</td>
-      <td>Key models: function, performance, accuracy, and doc testing</td>
-      <td>Other features and modules that require launching instances (using real weights)</td>
+      <td>High-priority models: function, performance, accuracy, and doc testing<br>Medium-priority models: function and doc testing</td>
+      <td>Low-priority features and component tests that require launching instances</td>
+      <td>Low-priority interfaces (using real weights)</td>
      <td><code>full_model and hardware_test(H100, L4, etc.) and omni/tts/diffusion</code></td>
      <td>&lt;3 hour</td>
      <td>
@@ -140,10 +147,11 @@ Through five levels (L1-L5) and common (Common) specifications, the system clari
      <td>GPU</td>
    </tr>
    <tr>
-      <td><strong>L5</strong><br>(Stability & Reliability & selected Perf)</td>
-      <td>Online: long-term stability + reliability; coverage test</td>
-      <td>Long-term stability and reliability testing for key models<br>Non-critical scenario performance and accuracy testing for key models<br>Other models: function and doc testing</td>
+      <td><strong>L5</strong><br>(Stability & Reliability)</td>
+      <td>Online: long-term stability test + reliability test</td>
+      <td>Long-term stability and reliability testing for high-priority models<br>Low-priority models: function and doc testing</td>
      <td>/</td>
+      <td>Invalid-parameter validation for high-priority interfaces</td>
      <td><code>slow and hardware_test(H100, L4, etc.) and omni/tts/diffusion</code></td>
      <td> Depends on reality </td>
      <td>
@@ -170,8 +178,8 @@ For per-level test authoring (markers, examples), see [Test Writing Guide](./tes

 Before entering specific testing levels, the project establishes two common specifications aimed at standardizing the development process and quickly locating issues.

-1. ***PR Checklist ([`.github/PULL_REQUEST_TEMPLATE.md`](https://github.com/vllm-project/vllm-omni/blob/main/.github/PULL_REQUEST_TEMPLATE.md))***: This template defines the self-check items that must be completed before submitting a code review (Pull Request). It ensures that each code change meets basic requirements such as code style, dependency updates, and documentation synchronization before entering the automated testing pipeline, serving as the first manual line of defense for quality assurance.
-2. ***CI Failure Explanation ([CI Failures](./failures.md))***: This document archives and explains common failure patterns in the Continuous Integration (CI) pipeline, error log interpretation, and preliminary troubleshooting steps. It helps developers and testers quickly diagnose the causes of automated test failures, improving problem-solving efficiency.
+1.  ***PR Checklist ([`.github/PULL_REQUEST_TEMPLATE.md`](https://github.com/vllm-project/vllm-omni/blob/main/.github/PULL_REQUEST_TEMPLATE.md))***: This template defines the self-check items that must be completed before submitting a code review (Pull Request). It ensures that each code change meets basic requirements such as code style, dependency updates, and documentation synchronization before entering the automated testing pipeline, serving as the first manual line of defense for quality assurance.
+2.  ***CI Failure Explanation ([CI Failures](./failures.md))***: This document archives and explains common failure patterns in the Continuous Integration (CI) pipeline, error log interpretation, and preliminary troubleshooting steps. It helps developers and testers quickly diagnose the causes of automated test failures, improving problem-solving efficiency.

 ## Notes

@@ -17,46 +17,45 @@ Summary:
 - **Reliability:** `tests/dfx/reliability/`
 - Do **not** add new top-level `tests/` directories unrelated to a component (or to `e2e` / `dfx` / `helpers` / `examples` / `buildkite`)

-Deploy YAMLs: `vllm_omni/deploy/` via `tests.helpers.stage_config.get_deploy_config_path` (see [pipeline and deploy configs](../../configuration/stage_configs.md)).
+Deploy YAMLs: `vllm_omni/deploy/` via `tests.helpers.stage_config.get_deploy_config_path` (see [stage configs](../../configuration/stage_configs.md)).

 ## Markers for Tests

 By adding markers before test functions, tests can later be executed uniformly by simply declaring the corresponding marker type.

 ### Current Markers
-
 Defined in `pyproject.toml`:

-| Marker             | Description                                                                                             |
-| ------------------ | ------------------------------------------------------------------------------------------------------- |
-| `core_model`       | L1&L2 tests (run in each PR)                                                                            |
-| `advanced_model`   | L3 tests (run on each merge to main)                                                                    |
-| `full_model`       | L4 tests (run nightly)                                                                                  |
-| `diffusion`        | Diffusion model tests                                                                                   |
-| `omni`             | Omni multimodal model tests                                                                             |
-| `tts`              | TTS model tests                                                                                         |
-| `cache`            | Cache backend tests                                                                                     |
-| `parallel`         | Parallelism/distributed tests                                                                           |
-| `cpu`              | Tests that run on CPU                                                                                   |
-| `gpu`              | Tests that run on GPU *                                                                                 |
-| `cuda`             | Tests that run on CUDA *                                                                                |
-| `rocm`             | Tests that run on AMD/ROCm *                                                                            |
-| `xpu`              | Tests that run on Intel XPU *                                                                           |
-| `npu`              | Tests that run on NPU/Ascend *                                                                          |
-| `H100`             | Tests that require H100 GPU  *                                                                          |
-| `L4`               | Tests that require L4 GPU *                                                                             |
-| `MI325`            | Tests that require MI325 GPU (AMD/ROCm) *                                                               |
-| `A2`               | Tests that require A2 NPU *                                                                             |
-| `A3`               | Tests that require A3 NPU *                                                                             |
-| `distributed_cuda` | Tests that require multi cards on CUDA platform *                                                       |
-| `distributed_rocm` | Tests that require multi cards on ROCm platform  *                                                      |
-| `distributed_npu`  | Tests that require multi cards on NPU platform  *                                                       |
-| `skipif_cuda`      | Skip if the num of CUDA cards is less than the required *                                               |
-| `skipif_rocm`      | Skip if the num of ROCm cards is less than the required *                                               |
-| `skipif_npu`       | Skip if the num of NPU cards is less than the required *                                                |
-| `slow`             | Slow tests (may skip in quick CI)                                                                       |
+| Marker             | Description                                               |
+| ------------------ | --------------------------------------------------------- |
+| `core_model`       | L1&L2 tests (run in each PR)                              |
+| `advanced_model`   | L3 tests (run on each merge to main)                 |
+| `full_model`       | L4 tests (run nightly) |
+| `diffusion`        | Diffusion model tests                                     |
+| `omni`             | Omni multimodal model tests |
+| `tts`              | TTS model tests     |
+| `cache`            | Cache backend tests                                       |
+| `parallel`         | Parallelism/distributed tests                             |
+| `cpu`              | Tests that run on CPU                                     |
+| `gpu`              | Tests that run on GPU *                                   |
+| `cuda`             | Tests that run on CUDA *                                  |
+| `rocm`             | Tests that run on AMD/ROCm *                              |
+| `xpu`              | Tests that run on Intel XPU *                             |
+| `npu`              | Tests that run on NPU/Ascend *                            |
+| `H100`             | Tests that require H100 GPU  *                            |
+| `L4`               | Tests that require L4 GPU *                               |
+| `MI325`            | Tests that require MI325 GPU (AMD/ROCm) *                 |
+| `A2`               | Tests that require A2 NPU *                               |
+| `A3`               | Tests that require A3 NPU *                               |
+| `distributed_cuda` | Tests that require multi cards on CUDA platform *         |
+| `distributed_rocm` | Tests that require multi cards on ROCm platform  *        |
+| `distributed_npu`  | Tests that require multi cards on NPU platform  *         |
+| `skipif_cuda`      | Skip if the num of CUDA cards is less than the required * |
+| `skipif_rocm`      | Skip if the num of ROCm cards is less than the required * |
+| `skipif_npu`       | Skip if the num of NPU cards is less than the required *  |
+| `slow`             | Slow tests (may skip in quick CI)                         |
 | `benchmark`        | Benchmark tests (decorator on runner test functions; perf JSON uses `full_model` + type marker instead) |
-| `local_model`      | Tests requiring local / non-HF-hub model weights                                                        |
+| `local_model`      | Tests requiring local / non-HF-hub model weights          |

 \* Means those markers are auto-added by `@hardware_test` (parametrization decorator) or `hardware_marks` (only returning the list of marks for flexibility).

@@ -82,13 +81,13 @@ This decorator is intended to make hardware-aware, cross-platform test authoring

 1. **Applies platform and resource markers**  
   Adds the appropriate pytest markers for each specified hardware platform (e.g., `cuda`, `rocm`, `xpu`, `npu`) and resource type (e.g., `L4`, `H100`, `MI325`, `B60`, `A2`, `A3`).
-   ```python
+   ```
   @pytest.mark.cuda
   @pytest.mark.L4
   ```
 2. **Handles multi-card (distributed) scenarios**  
   For tests requiring multiple cards, it automatically adds distributed markers such as `distributed_cuda`, `distributed_rocm`, or `distributed_npu`.
-   ```python
+   ```
   @pytest.mark.distributed_cuda(num_cards=num_cards)
   ```
 3. **Supports flexible card requirements**  
@@ -98,11 +97,11 @@ This decorator is intended to make hardware-aware, cross-platform test authoring
   On CUDA, adds a skip marker (`skipif_cuda`) if the system does not have the required number of devices.
   Support for `skipif_rocm` and `skipif_npu` will be implemented later.

+
 5. **Works with pytest filtering**  
   Allows tests to be filtered and selected at runtime using standard pytest marker expressions (e.g., `-m "distributed_cuda and L4"`).

 ##### Example usage for decorator
-
 - Single call for multiple platforms:
    ```python
    @hardware_test(
@@ -221,7 +220,6 @@ If you want to add support for a new platform (e.g., "tpu" for a new accelerator
   ```

 **Summary**:  
-
 - Add pytest markers for your new platform/resources  
 - Implement a marker function (`xxx_marks`)  
 - Plug into `hardware_marks`  
@@ -239,46 +237,47 @@ L1 and L2 level testing form the foundation of the quality assurance system. L1

 L2 level testing builds upon L1 by introducing GPU resources and verifying that the end-to-end (E2E) process of the model in basic deployment scenarios is smooth. For example, it uses dummy models to confirm that core interfaces like the inference pipeline, output format, and streaming response work properly. The common goal of these two levels is to provide developers with rapid feedback, discovering and fixing issues early in the development cycle.

+
+
 #### 1.2 Testing Content and Scope

- ***L1 (Unit & Logic Testing)***:
-    - ***Scope***: Tests internal functions and methods of core components such as `entrypoints`, `models`.
-        - ***Focus***: Branch coverage, exception handling, algorithm logic correctness. Does not involve external dependencies or the complete service stack.
-        - ***Time Cost***: Execution time is controlled within ***15 minutes*** to ensure fast feedback.
- ***L2 (Basic End-to-End Testing)***:
-    - ***Scope***: Covers two basic deployment scenarios: `online` (serving) and `offline` (inference).
-        - ***Focus***: Uses `dummy` weights (via deploy YAML patching at `core_model`) or lightweight real models to verify that the entire chain from request input to result output works normally, including output data structure, streaming (stream) support, and **cheap payload checks** at `--run-level core_model` (see below). Also includes some unit tests that require launching independent service instances.
-        - ***L2 response validation (`core_model`)***: Implemented in `tests/helpers/assertions.py` and invoked by `OpenAIClientHandler` based on `--run-level`. At L2 we require **request success** plus minimal output sanity—not full accuracy:
-            - **Speech / TTS** (`assert_audio_speech_response`): decoded audio must be present and non-empty (or exceed `min_audio_bytes` when set in `request_config`); `response_format` must match the returned content-type (e.g. `wav`, `pcm`). Whisper transcript similarity, PCM HNR, and preset-voice gender checks run only at L3+.
-            - **Diffusion** (`assert_diffusion_response`): at least one non-empty image, video, or audio artifact. Resolution/frame-count parity and other deep checks run only at L3+.
-            - **Omni multimodal** (`assert_omni_response`): L2 asserts successful completion; keyword, transcript, and cross-modal similarity checks run only at L3+.
-        - ***Characteristic***: Requires ***GPU*** resources to perform model computations.
+-   ***L1 (Unit & Logic Testing)***:
+-   -   ***Scope***: Tests internal functions and methods of core components such as `entrypoints`, `models`.
+    -   ***Focus***: Branch coverage, exception handling, algorithm logic correctness. Does not involve external dependencies or the complete service stack.
+    -   ***Time Cost***: Execution time is controlled within ***15 minutes*** to ensure fast feedback.
+-   ***L2 (Basic End-to-End Testing)***:
+-   -   ***Scope***: Covers two basic deployment scenarios: `online` (serving) and `offline` (inference).
+    -   ***Focus***: Uses `dummy` weights (via deploy YAML patching at `core_model`) or lightweight real models to verify that the entire chain from request input to result output works normally, including output data structure, streaming (stream) support, and **cheap payload checks** at `--run-level core_model` (see below). Also includes some unit tests that require launching independent service instances.
+    -   ***L2 response validation (`core_model`)***: Implemented in `tests/helpers/assertions.py` and invoked by `OpenAIClientHandler` based on `--run-level`. At L2 we require **request success** plus minimal output sanity—not full accuracy:
+        -   **Speech / TTS** (`assert_audio_speech_response`): decoded audio must be present and non-empty (or exceed `min_audio_bytes` when set in `request_config`); `response_format` must match the returned content-type (e.g. `wav`, `pcm`). Whisper transcript similarity, PCM HNR, and preset-voice gender checks run only at L3+.
+        -   **Diffusion** (`assert_diffusion_response`): at least one non-empty image, video, or audio artifact. Resolution/frame-count parity and other deep checks run only at L3+.
+        -   **Omni multimodal** (`assert_omni_response`): L2 asserts successful completion; keyword, transcript, and cross-modal similarity checks run only at L3+.
+    -   ***Characteristic***: Requires ***GPU*** resources to perform model computations.

 #### 1.3 Test Directory and Execution Files

 A clear directory structure is key to managing test cases efficiently. See the **Test Dir** column in [Test System Overview](./test_system_overview.md) for the canonical placement rules.

- ***L1 (component / unit)***: `tests/{component_name}/…` mirroring `vllm_omni/{component_name}/` (e.g. `tests/diffusion/`, `tests/entrypoints/`). Do **not** invent new top-level `tests/` folders unrelated to a component.
- ***L2 (basic model E2E)***:
-    - Online serving: `tests/e2e/online_serving/test_{model_name}.py`
-    - Offline inference: `tests/e2e/offline_inference/test_{model_name}.py`
- ***Feature-level integration*** (cross-cutting, not a single-model smoke): `tests/e2e/features/<feature>/` (e.g. `fullduplex/`, `custom_pipeline/`, `rlhf_test/`).
+-   ***L1 (component / unit)***: `tests/{component_name}/…` mirroring `vllm_omni/{component_name}/` (e.g. `tests/diffusion/`, `tests/entrypoints/`). Do **not** invent new top-level `tests/` folders unrelated to a component.
+-   ***L2 (basic model E2E)***:
+    -   Online serving: `tests/e2e/online_serving/test_{model_name}.py`
+    -   Offline inference: `tests/e2e/offline_inference/test_{model_name}.py`
+-   ***Feature-level integration*** (cross-cutting, not a single-model smoke): `tests/e2e/features/<feature>/` (e.g. `fullduplex/`, `custom_pipeline/`, `rlhf_test/`).

 #### 1.4 Execution Method and Example

- ***Trigger Timing***: **`PR with ready label`**. That is, when a developer adds a "ready for review" or similar label to a PR on platforms like GitHub, L1 and L2 tests are automatically triggered.
- ***Diff-aware step skipping***: On L2, **E2E Test** jobs may be omitted at pipeline upload when the PR diff does not touch their [`source_file_dependencies`](ci_settings.md#step-filtering) prefixes; non-E2E groups still always upload. See [CI Settings — Diff-aware CI](ci_settings.md#diff-aware-ci).
- ***Execution Environment***: L1 uses ***CPU*** environment; L2 requires ***GPU*** environment.
- ***Script Example***:
+-   ***Trigger Timing***: **`PR with ready label`**. That is, when a developer adds a "ready for review" or similar label to a PR on platforms like GitHub, L1 and L2 tests are automatically triggered.
+-   ***Diff-aware step skipping***: On L2, **E2E Test** jobs may be omitted at pipeline upload when the PR diff does not touch their [`source_file_dependencies`](ci_settings.md#step-filtering) prefixes; non-E2E groups still always upload. See [CI Settings — Diff-aware CI](ci_settings.md#diff-aware-ci).
+-   ***Execution Environment***: L1 uses ***CPU*** environment; L2 requires ***GPU*** environment.
+-   ***Script Example***:

 <details>
 <summary> L1 Test Examples</summary>

 Examples from `tests/model_executor/models/qwen2_5_omni/test_audio_length.py`
-
 ```python
 # SPDX-License-Identifier: Apache-2.0
-# SPDX-FileCopyrightText: Copyright contributors to the vLLM-Omni project
+# SPDX-FileCopyrightText: Copyright contributors to the vLLM project

 import pytest

@@ -332,7 +331,6 @@ def test_cap_and_align_mel_length_no_mismatch(repeats, code_len, max_mel_frames)
    if max_mel_frames is not None and int(max_mel_frames) > 0 and int(max_mel_frames) >= repeats:
        assert target_mel_len <= int(max_mel_frames)
 ```
-
 </details>

 <details>
@@ -340,7 +338,7 @@ def test_cap_and_align_mel_length_no_mismatch(repeats, code_len, max_mel_frames)
 You can refer to Test Examples in the L3 section to see example test cases that incorporate both L2 and L3 testing logic.
 </details>

- ***Run Command***:
+-   -   ***Run Command***:

    `pytest -s -v /tests/e2e/online_serving/test_{model_name}.py`
    `pytest -s -v -m 'core_model and cpu' --run-level=core_model`
@@ -353,34 +351,36 @@ L3 level testing executes after code is merged into the main branch. Its core pu

 . It acts as the "quality gatekeeper" for the main branch, ensuring that no merge breaks the core capabilities of the model service. Testing needs to provide clear conclusions within a relatively short time (<30min), balancing test depth with feedback speed.

+
+
 #### 2.2 Testing Content and Scope

- ***Deployment Scenarios***: Covers richer `online` and `offline` deployment configurations, which may include different hardware configurations, batch sizes, concurrency levels, etc.
- ***Core Verification***:
-    1. ***Inference Functionality***: Ensures real models can perform forward computation normally and return results.
-    2. ***Accuracy Compliance***: Verifies that the model's evaluation metrics (e.g., accuracy) meet the expected baseline, preventing code changes from introducing accuracy issues.
-    3. ***Important Performance***: Verifies whether performance (e.g., P99 latency, throughput) in core scenarios meets preset thresholds.
- ***L3 response validation (`advanced_model`)***: At `--run-level advanced_model`, `tests/helpers/assertions.py` adds semantic checks on top of L2 payload gates (see L1 & L2 above):
-    - **Speech / TTS** (`assert_audio_speech_response`): Whisper transcript of returned audio vs `request_config["input"]` (cosine similarity &gt; 0.9 when input text is set); optional `min_audio_bytes` floor; PCM harmonic-to-noise ratio when `response_format` is `pcm`; **preset voice gender** via `_assert_preset_voice_gender_from_audio` when `voice` matches a known preset in `_PRESET_VOICE_GENDER_MAP` (pitch/F0-based classifier; skipped for unknown voices or `pcm` output).
-    - **Omni multimodal** (`assert_omni_response`): non-empty text/audio outputs; `key_words` in transcript or text; text–audio similarity / containment; preset **`speaker`** gender check (same helper as TTS).
-    - **Diffusion** (`assert_*_diffusion_response`): image/video dimension and frame-count parity with request parameters where configured.
-    - **Accuracy suites**: pixel/video similarity and metric baselines under `/tests/e2e/accuracy/` (separate from inline helper assertions).
+-   ***Deployment Scenarios***: Covers richer `online` and `offline` deployment configurations, which may include different hardware configurations, batch sizes, concurrency levels, etc.
+-   ***Core Verification***:
+-   1.  ***Inference Functionality***: Ensures real models can perform forward computation normally and return results.
+    2.  ***Accuracy Compliance***: Verifies that the model's evaluation metrics (e.g., accuracy) meet the expected baseline, preventing code changes from introducing accuracy issues.
+    3.  ***Important Performance***: Verifies whether performance (e.g., P99 latency, throughput) in core scenarios meets preset thresholds.
+-   ***L3 response validation (`advanced_model`)***: At `--run-level advanced_model`, `tests/helpers/assertions.py` adds semantic checks on top of L2 payload gates (see L1 & L2 above):
+    -   **Speech / TTS** (`assert_audio_speech_response`): Whisper transcript of returned audio vs `request_config["input"]` (cosine similarity &gt; 0.9 when input text is set); optional `min_audio_bytes` floor; PCM harmonic-to-noise ratio when `response_format` is `pcm`; **preset voice gender** via `_assert_preset_voice_gender_from_audio` when `voice` matches a known preset in `_PRESET_VOICE_GENDER_MAP` (pitch/F0-based classifier; skipped for unknown voices or `pcm` output).
+    -   **Omni multimodal** (`assert_omni_response`): non-empty text/audio outputs; `key_words` in transcript or text; text–audio similarity / containment; preset **`speaker`** gender check (same helper as TTS).
+    -   **Diffusion** (`assert_*_diffusion_response`): image/video dimension and frame-count parity with request parameters where configured.
+    -   **Accuracy suites**: pixel/video similarity and metric baselines under `/tests/e2e/accuracy/` (separate from inline helper assertions).

 #### 2.3 Test Directory and Execution Files

- ***Functional / model E2E***:
-    - Online serving: `tests/e2e/online_serving/test_{model_name}_expansion.py`
-    - Offline inference: `tests/e2e/offline_inference/test_{model_name}_expansion.py`
-    - Accuracy / similarity: `tests/e2e/accuracy/`
-    - (`_expansion.py` holds broader scenario coverage than the L2 smoke file.)
- ***Feature-level integration***: `tests/e2e/features/<feature>/` (not under a new top-level `tests/` directory).
+-   ***Functional / model E2E***:
+    -   Online serving: `tests/e2e/online_serving/test_{model_name}_expansion.py`
+    -   Offline inference: `tests/e2e/offline_inference/test_{model_name}_expansion.py`
+    -   Accuracy / similarity: `tests/e2e/accuracy/`
+    -   (`_expansion.py` holds broader scenario coverage than the L2 smoke file.)
+-   ***Feature-level integration***: `tests/e2e/features/<feature>/` (not under a new top-level `tests/` directory).

 #### 2.4 Execution Method and Example

- ***Trigger Timing***: **`PR Merged`**. Automatically triggered after code review is approved and merged into the main branch (typically via `merge-test` label on the PR before merge).
- ***Diff-aware step skipping***: Same [`source_file_dependencies`](ci_settings.md#step-filtering) mechanism as L2—**all E2E Test** leaf steps are diff-gated; other L3 groups always upload. See [CI Settings — Diff-aware CI](ci_settings.md#diff-aware-ci).
- ***Execution Environment***: ***GPU*** servers.
- ***Script Example***:
+-   ***Trigger Timing***: **`PR Merged`**. Automatically triggered after code review is approved and merged into the main branch (typically via `merge-test` label on the PR before merge).
+-   ***Diff-aware step skipping***: Same [`source_file_dependencies`](ci_settings.md#step-filtering) mechanism as L2—**all E2E Test** leaf steps are diff-gated; other L3 groups always upload. See [CI Settings — Diff-aware CI](ci_settings.md#diff-aware-ci).
+-   ***Execution Environment***: ***GPU*** servers.
+-   ***Script Example***:

 ???+ example "Test Examples"

@@ -496,9 +496,9 @@ L3 level testing executes after code is merged into the main branch. Its core pu

    **Audio output debugging**: Deep validation may transcribe returned audio via `convert_audio_bytes_to_text` (Whisper). If an audio keyword or text–audio similarity assertion fails, set `VLLM_OMNI_KEEP_REQUEST_MEDIA=1` before running pytest to keep the intermediate WAV files for inspection (see [Test helper environment variables](test_system_overview.md#test-helper-environment-variables)).

- ***Run Command (L3 merge)***: `pytest -s -v /tests/e2e/online_serving/test_{model_name}.py -m advanced_model --run-level=advanced_model`
+-   ***Run Command (L3 merge)***: `pytest -s -v /tests/e2e/online_serving/test_{model_name}.py -m advanced_model --run-level=advanced_model`

- ***Run Command (L4 nightly expansion)***: `pytest -s -v /tests/e2e/online_serving/test_{model_name}_expansion.py -m full_model --run-level=full_model`
+-   ***Run Command (L4 nightly expansion)***: `pytest -s -v /tests/e2e/online_serving/test_{model_name}_expansion.py -m full_model --run-level=full_model`

 ### L4 Level Testing - Full Functionality, Performance, and Documentation Testing

@@ -506,25 +506,27 @@ L3 level testing executes after code is merged into the main branch. Its core pu

 L4 level testing is a comprehensive quality audit before a version release. It expands upon L3, executing ***full*** functional scenarios, conducting systematic ***performance stress tests***, and simultaneously verifying the correctness of accompanying ***example documentation***. Its purpose is to perform deep validation of the system during off-peak nighttime hours, providing quality trend reports for daytime development and data support for release decisions.

+
+
 #### 3.2 Testing Content and Scope

- ***Full Functionality Testing***: Executes all test cases defined in `test_{model_name}_expansion.py`, covering all implemented features, positive flows, boundary conditions, and exception handling.
- ***Performance Testing***: JSON configs under `tests/dfx/perf/tests/` drive Omni, TTS, and diffusion serving benchmarks via `run_benchmark.py` or `run_diffusion_benchmark.py`, measuring throughput, latency, and related metrics under configured workloads.
- ***Documentation Testing***: Verifies whether the example code provided to users is runnable and its results match the description.
+-   ***Full Functionality Testing***: Executes all test cases defined in `test_{model_name}_expansion.py`, covering all implemented features, positive flows, boundary conditions, and exception handling.
+-   ***Performance Testing***: Uses `tests/dfx/perf/tests/test_qwen3_omni_*.json` (Omni), `test_tts.json` / `test_voxcpm2.json` / `test_higgs_audio_v3.json` (TTS), and diffusion configs `tests/dfx/perf/tests/test_*_vllm_omni.json` (passed to `run_benchmark.py` or `run_diffusion_benchmark.py` via `--test-config-file` in nightly **Perf Test** steps) to drive throughput, latency, and memory benchmarks. Each JSON **case** may declare an optional top-level **`mark`** array: exactly one ``hardware_marks`` object plus pytest marker name strings (`full_model`, `omni` / `tts` / `diffusion`, …). Runners attach those marks to each parametrized `(server, benchmark index)` pair so **local** bulk runs can filter with `-m` (for example `-m "full_model and H100 and diffusion"`). Nightly CI perf jobs select workloads by **`--test-config-file`**, not `-m`. Details are in the Performance Tests example below.
+-   ***Documentation Testing***: Verifies whether the example code provided to users is runnable and its results match the description.

 #### 3.3 Test Directory and Execution Files

- ***Functional Testing***: Same directories as L3.
- ***Performance Test Configuration***: `tests/dfx/perf/tests/test_qwen3_omni_*.json`, `test_tts.json`, `test_voxcpm2.json`, `test_higgs_audio_v3.json`, and diffusion configs `tests/dfx/perf/tests/test_*_vllm_omni.json` (e.g. `test_qwen_image_vllm_omni.json`, `test_cosmos3_vllm_omni.json`). Optional per-case `mark` for local `-m` filtering is documented in Section 3.4 Performance Tests.
- ***Documentation Example Tests***:
-    - `tests/examples/online_serving/test_{model_name}.py`
-    - `tests/examples/offline_inference/test_{model_name}.py`
+-   ***Functional Testing***: Same directories as L3.
+-   ***Performance Test Configuration***: `tests/dfx/perf/tests/test_qwen3_omni_*.json`, `test_tts.json`, `test_voxcpm2.json`, `test_higgs_audio_v3.json`, and diffusion configs `tests/dfx/perf/tests/test_*_vllm_omni.json` (e.g. `test_qwen_image_vllm_omni.json`, `test_cosmos3_vllm_omni.json`). Optional per-case `mark` for local `-m` filtering is documented in Section 3.4 Performance Tests.
+-   ***Documentation Example Tests***:
+    -   `tests/examples/online_serving/test_{model_name}.py`
+    -   `tests/examples/offline_inference/test_{model_name}.py`

 #### 3.4 Execution Method and Example

- ***Trigger Timing***: **`Nightly`**, automatically executed every night.
- ***Execution Environment***: ***GPU*** server clusters to meet the resource demands of performance testing.
- ***Script Example***:
+-   ***Trigger Timing***: **`Nightly`**, automatically executed every night.
+-   ***Execution Environment***: ***GPU*** server clusters to meet the resource demands of performance testing.
+-   ***Script Example***:

 ??? example "Test Examples: Documentation Example Tests"

@@ -538,7 +540,7 @@ L4 level testing is a comprehensive quality audit before a version release. It e

    --8<-- "docs/contributing/ci/test_examples/l4_functionality_tests.inc.md"

- ***Run Command***: (Specific commands would depend on the performance testing tool and configuration defined in `nightly.json`).
+-   ***Run Command***: (Specific commands would depend on the performance testing tool and configuration defined in `nightly.json`).

 ### L5 Level Testing - Stability and Reliability Testing

@@ -546,43 +548,41 @@ L4 level testing is a comprehensive quality audit before a version release. It e

 L5 level testing focuses on the performance of model services under ***long-running*** and ***abnormal fault*** scenarios. It aims to uncover deep-seated issues that only manifest under sustained pressure or extreme conditions, such as memory leaks, resource contention, gradual performance degradation, and lack of fault tolerance mechanisms. This is the final, yet crucial, line of defense for ensuring service high availability and production environment robustness.

+
+
 #### 4.2 Testing Content and Scope

- ***Long-term Stability (Stability) Testing***: Uses JSON under `tests/dfx/stability/tests/` (for example `test_qwen3_omni.json` and `test_wan22.json`) to run the service under moderate load for an extended period (e.g., over 12 hours), monitoring whether metrics like memory/VRAM usage, response time, and throughput degrade over time, and whether the service process remains stable.
- ***Reliability Testing***: Uses pytest suites under `tests/dfx/reliability/` to inject controlled faults against a **live** `vllm_omni serve` instance (same **`omni_server` / `omni_server_function`** fixture style as E2E). Current suites emphasize **GPU memory pressure** (CUDA sidecar “memory hog”), **worker / runtime process kill** (`SIGKILL` on `VLLM::Worker` for Qwen3-Omni, `multiprocessing.spawn` for Wan2.2 video workers, or `vLLM-Omni::` for HunyuanImage DiT workers), **large multimodal chat**, **`/v1/videos`**, **`/v1/images/generations`**, or **`/v1/audio/speech`** jobs under OOM, **`/health` → 503** and **fast-fail / non-hanging concurrent** requests after kill, and **OpenAI-style 5xx error contracts** (e.g. text vs text+audio under OOM). **Post-fault recovery** checks exist where enabled (some cases may be `skip` while issues are tracked). See Section 4.3 for file-level responsibilities and Section 4.4 Test Examples (Reliability) for CI markers (`slow`, `hardware_test`, POSIX-only kill).
+-   ***Long-term Stability (Stability) Testing***: Uses JSON under `tests/dfx/stability/tests/` (for example `test_qwen3_omni.json` and `test_wan22.json`) to run the service under moderate load for an extended period (e.g., over 12 hours), monitoring whether metrics like memory/VRAM usage, response time, and throughput degrade over time, and whether the service process remains stable.
+-   ***Reliability Testing***: Uses pytest suites under `tests/dfx/reliability/` to inject controlled faults against a **live** `vllm_omni serve` instance (same **`omni_server` / `omni_server_function`** fixture style as E2E). Current suites emphasize **GPU memory pressure** (CUDA sidecar “memory hog”), **worker / runtime process kill** (`SIGKILL` on `VLLM::Worker` for Qwen3-Omni, `multiprocessing.spawn` for Wan2.2 video workers, or `vLLM-Omni::` for HunyuanImage DiT workers), **large multimodal chat**, **`/v1/videos`**, **`/v1/images/generations`**, or **`/v1/audio/speech`** jobs under OOM, **`/health` → 503** and **fast-fail / non-hanging concurrent** requests after kill, and **OpenAI-style 5xx error contracts** (e.g. text vs text+audio under OOM). **Post-fault recovery** checks exist where enabled (some cases may be `skip` while issues are tracked). See the Reliability `<details>` block in Section 4.4 for file-level responsibilities and CI markers (`slow`, `hardware_test`, POSIX-only kill).

 #### 4.3 Test Directory and Execution Files

- ***Stability Test Configuration***: `tests/dfx/stability/tests/test_qwen3_omni.json`, `tests/dfx/stability/tests/test_wan22.json` (one JSON per model / runner family)
- ***Reliability Test Suite*** (`tests/dfx/reliability/`):
-    - `test_reliability_qwen3_omni.py` — Qwen3-Omni chat / multimodal reliability (GPU OOM, process kill, recovery, error contract under `--async-chunk` vs default).
-    - `test_reliability_wan22.py` — Wan2.2 I2V video API reliability (`/v1/videos` under OOM and process kill, recovery).
-    - `test_reliability_hunyuan_image.py` — HunyuanImage-3.0-Instruct DiT-only reliability (`/v1/images/generations` under OOM and process kill; deploy `hunyuan_image3_dit.yaml`, H100 × 4).
-    - `helpers.py` — Shared primitives used by current suites: raw HTTP probes for `/v1/chat/completions` and `/health`, OpenAI-style error parsing, GPU OOM sidecar (`inject_gpu_oom` / `stop_gpu_oom_hogs`), and `pgrep`-based process-kill injector construction (`make_process_kill_fault_injector`).
-    - `conftest.py` — `fault_injector` and `omni_server_after_fault` / `omni_server_after_fault_function` fixtures to run a callable **after** the server is ready.
-    - `README.md` — Short local run commands for this directory.
+-   ***Stability Test Configuration***: `tests/dfx/stability/tests/test_qwen3_omni.json`, `tests/dfx/stability/tests/test_wan22.json` (one JSON per model / runner family)
+-   ***Reliability Test Suite*** (`tests/dfx/reliability/`):
+    -   `test_reliability_qwen3_omni.py` — Qwen3-Omni chat / multimodal reliability (GPU OOM, process kill, recovery, error contract under `--async-chunk` vs default).
+    -   `test_reliability_wan22.py` — Wan2.2 I2V video API reliability (`/v1/videos` under OOM and process kill, recovery).
+    -   `test_reliability_hunyuan_image.py` — HunyuanImage-3.0-Instruct DiT-only reliability (`/v1/images/generations` under OOM and process kill; deploy `hunyuan_image3_dit.yaml`, H100 × 4).
+    -   `test_reliability_voxcpm2.py` — VoxCPM2 TTS reliability (`/v1/audio/speech` under OOM and process kill; deploy `voxcpm2.yaml`, L4 × 1).
+    -   `helpers.py` — Shared primitives used by current suites: raw HTTP probes for `/v1/chat/completions` and `/health`, OpenAI-style error parsing, GPU OOM sidecar (`inject_gpu_oom` / `stop_gpu_oom_hogs`), and `pgrep`-based process-kill injector construction (`make_process_kill_fault_injector`).
+    -   `conftest.py` — `fault_injector` and `omni_server_after_fault` / `omni_server_after_fault_function` fixtures to run a callable **after** the server is ready.
+    -   `README.md` — Short local run commands for this directory.

 #### 4.4 Execution Method and Example

- ***Trigger Timing***: **`Weekly`** (weekly) or **`Days before Release`** (several days before a major release). Due to long execution times, the frequency is lower.
- ***Run Command***:
-    - ***Stability***: `pytest -s -v tests/dfx/stability/scripts/test_stability_qwen3_omni.py` or `pytest -s -v tests/dfx/stability/scripts/test_stability_wan22.py` (or add `test_stability_<model>.py` alongside a matching JSON config)
-    - ***Reliability***: `pytest -s -v tests/dfx/reliability/test_reliability_<model>.py -m slow` (current suites: `qwen3_omni`, `wan22`, `hunyuan_image`).
- ***Script Example***:
-
+-   ***Trigger Timing***: **`Weekly`** (weekly) or **`Days before Release`** (several days before a major release). Due to long execution times, the frequency is lower.
+-   ***Execution Environment***: ***GPU*** servers, requiring a stable and exclusive testing environment.
+-   ***Script Example***:
 <details>
 <summary> Test Examples</summary>

-##### Stability
-
-When you want to add L5-level stability test cases, add or extend the appropriate JSON file under `tests/dfx/stability/tests/` (for example `test_qwen3_omni.json` for Omni bench traffic, or `test_wan22.json` for diffusion `/v1/videos` workloads). Pair the JSON with `tests/dfx/stability/scripts/test_stability_<model>.py`. The following illustrates the Qwen3-Omni shape:
+When you want to add L5-level stability test cases, add or extend the appropriate JSON file under `tests/dfx/stability/tests/` (for example `test_qwen3_omni.json` for Omni bench traffic, or `test_wan22.json` for diffusion `/v1/videos` workloads). The following illustrates the Qwen3-Omni shape:

 ```json
 {
    "test_name": "test_qwen3_omni_stability",
    "server_params": {
        "model": "Qwen/Qwen3-Omni-30B-A3B-Instruct",
-        "stage_config_name": "qwen3_omni_moe.yaml"
+        "stage_config_name": "qwen3_omni.yaml"
    },
    "benchmark_params": [
        {
@@ -601,61 +601,112 @@ When you want to add L5-level stability test cases, add or extend the appropriat
 }
 ```

-###### Parameter Explanation
+##### Parameter Explanation

 ***Overview***

 | Field            | Required | Description                                                                 |
 | ---------------- | -------- | --------------------------------------------------------------------------- |
 | test_name        | Yes      | Unique identifier for the stability test case                               |
-| server_params    | Yes      | Server-side configuration parameters (model, deploy configuration, etc.)    |
+| server_params    | Yes      | Server-side configuration parameters (model, stage configuration, etc.)     |
 | benchmark_params | Yes      | Stability benchmark running parameters (supports multiple configurations)   |

-###### server_params Configuration
+##### server_params Configuration

-Basic parameters:
+###### Basic Parameters

 | Parameter         | Required | Example                            | Description                         |
 | ----------------- | -------- | ---------------------------------- | ----------------------------------- |
 | model             | Yes      | "Qwen/Qwen3-Omni-30B-A3B-Instruct" | Model name or path                  |
-| stage_config_name | Yes      | "qwen3_omni_moe.yaml"              | Deploy configuration file name      |
+| stage_config_name | Yes      | "qwen3_omni.yaml"                  | Stage configuration file name       |

-Dynamic configuration (`update` / `delete`) supports incremental modifications based on the basic configuration:
+###### Dynamic Configuration (update/delete)
+
+Supports incremental modifications based on the basic configuration:

 | Operation | Description                          |
 | --------- | ------------------------------------ |
 | update    | Update or add configuration items    |
 | delete    | Delete specified configuration items |

-***Example***: You can refer to Test Examples in L4 §3.4.
+***Example***:
+You can refer to Test Examples in L4 §3.4

-###### benchmark_params Configuration
+##### benchmark_params Configuration

 For stability testing, the key parameters are:

- **duration_sec**: Total duration (in seconds) during which benchmark traffic is sent. The stability benchmark will keep sending batches until this duration is reached.
- **request_rate** / **max_concurrency**: Exactly one of them must be specified. They control how the traffic is generated for each batch:
-    - `request_rate`: Number of requests per second. The benchmark will send `num_prompts_per_batch` requests at the given rate.
-    - `max_concurrency`: Maximum number of concurrent requests. When this is used, `request_rate` is set to `inf` internally.
- **num_prompts_per_batch**: Number of prompts sent in each batch. Multiple batches will be executed sequentially within `duration_sec`.
+-   **duration_sec**: Total duration (in seconds) during which benchmark traffic is sent. The stability benchmark will keep sending batches until this duration is reached.
+-   **request_rate** / **max_concurrency**: Exactly one of them must be specified. They control how the traffic is generated for each batch:
+    -   `request_rate`: Number of requests per second. The benchmark will send `num_prompts_per_batch` requests at the given rate.
+    -   `max_concurrency`: Maximum number of concurrent requests. When this is used, `request_rate` is set to `inf` internally.
+-   **num_prompts_per_batch**: Number of prompts sent in each batch. Multiple batches will be executed sequentially within `duration_sec`.

 All other optional parameters follow the same rules as in L4 §3.4.

-##### Reliability
+</details>

-Add pytest modules under `tests/dfx/reliability/` (for example `test_reliability_qwen3_omni.py`, `test_reliability_wan22.py`, `test_reliability_hunyuan_image.py`). Reuse `helpers.py` and `conftest.py` rather than duplicating OOM / process-kill / raw HTTP plumbing.
+<details>
+<summary> Reliability test suite (<code>tests/dfx/reliability</code>)</summary>

-###### Parametrization and markers
+##### Purpose and relationship to stability
+
+Reliability tests are **short fault-injection** integration runs (L5 **(b)** in `tests/dfx/reliability/README.md`). They complement **stability** JSON-driven long runs: instead of hours of steady traffic, they **perturb** the server (GPU OOM sidecar, fatal signals on selected processes) and check **failure mode** and **latency bounds** (e.g. chat or `/v1/videos` must not hang under concurrent fault-time load).
+
+##### Directory layout
+
+| Path | Responsibility |
+| ---- | -------------- |
+| `helpers.py` | Shared helpers used by current reliability suites: raw `POST`/`GET` probes (`/v1/chat/completions`, `/health`), OpenAI error parsing (`extract_openai_error_contract_from_bytes`), GPU OOM sidecar lifecycle (`inject_gpu_oom`, `stop_gpu_oom_hogs`), and process-kill injector builder (`make_process_kill_fault_injector`). |
+| `conftest.py` | Pytest fixtures: indirect `fault_injector`, `omni_server_after_fault` / `omni_server_after_fault_function` (run injector after server is ready, then yield server). |
+| `test_reliability_qwen3_omni.py` | Qwen3-Omni: OOM vs **text vs text+audio** error contract, large multimodal chat under OOM, concurrent pressure, **SIGKILL** on `VLLM::Worker`, `/health` → 503 + fast-fail + concurrent chat; optional OOM recovery scenario (may be skipped while tracked in issues). |
+| `test_reliability_wan22.py` | Wan2.2 I2V: large `/v1/videos` under OOM, **SIGKILL** on `multiprocessing.spawn` chain, health / fast-fail / concurrent video requests; optional recovery test (may be skipped). |
+| `test_reliability_hunyuan_image.py` | HunyuanImage DiT-only: large `/v1/images/generations` under OOM, **SIGKILL** on `vLLM-Omni::` workers and serve/tree targets, health / fast-fail / concurrent image requests; some OOM/recovery cases may be skipped while tracked in issues. |
+| `test_reliability_voxcpm2.py` | VoxCPM2: `/v1/audio/speech` under OOM (error contract), **SIGKILL** on `VLLM::` workers and serve/tree targets, health / fast-fail / concurrent speech requests; some OOM cases may be skipped while tracked in issues. |
+| `README.md` | Minimal run / collect examples. |
+
+##### Parametrization and markers

 - Each test module defines a **`RELIABILITY_SCENARIOS`** list (`test_name`, `server_params`: model, `stage_config_name` or diffusion `server_args`, etc.). **`create_reliability_omni_server_params()`** in `tests/dfx/conftest.py` resolves stage paths (including XPU substitutions where applicable) and builds **`OmniServerParams`** lists consumed by **`@pytest.mark.parametrize(..., indirect=True)`** on `omni_server` or `omni_server_function`.
- Cases are tagged **`@pytest.mark.slow`** for weekly / selective CI. GPU-heavy suites use **`@hardware_test(res={"cuda": "H100"}, num_cards=...)`** (Qwen3-Omni **2**× H100; Wan2.2 **1**× H100; HunyuanImage DiT **4**× H100).
+- Cases are tagged **`@pytest.mark.slow`** for weekly / selective CI. GPU-heavy suites use **`@hardware_test(res={"cuda": "H100"}, num_cards=...)`** or **`@hardware_test(res={"cuda": "L4"}, num_cards=1)`** (Qwen3-Omni **2**× H100; Wan2.2 **1**× H100; HunyuanImage DiT **4**× H100; VoxCPM2 **1**× L4).
 - **Process-kill** tests use **`@pytest.mark.skipif(os.name == "nt", ...)`** because injection uses POSIX **`pgrep` / `kill`**.

-###### Adding a new model suite
+##### CI trigger
+
+Weekly Buildkite (`.buildkite/cuda/test-weekly.yml`) runs one step per model suite (trigger: `WEEKLY=1` or PR label `weekly-test`), for example:
+
+| Buildkite step | Test file | CI hardware |
+| -------------- | --------- | ----------- |
+| Reliability Test - qwen3-omni | `test_reliability_qwen3_omni.py` | H100 × 2 (`mithril-h100-pool`) |
+| Reliability Test - wan22 | `test_reliability_wan22.py` | H100 × 2 (`mithril-h100-pool`) |
+| Reliability Test - hunyuan-image | `test_reliability_hunyuan_image.py` | H100 × 4 (`mithril-h100-pool`) |
+| Reliability Test - voxcpm2 | `test_reliability_voxcpm2.py` | L4 × 1 (`gpu_1_queue`) |
+
+```bash
+pytest -s -v tests/dfx/reliability/test_reliability_qwen3_omni.py -m "slow"
+pytest -s -v tests/dfx/reliability/test_reliability_wan22.py -m "slow"
+pytest -s -v tests/dfx/reliability/test_reliability_hunyuan_image.py -m "slow"
+pytest -s -v tests/dfx/reliability/test_reliability_voxcpm2.py -m "slow"
+```
+
+##### Local commands
+
+```bash
+pytest --collect-only tests/dfx/reliability
+pytest -s -v tests/dfx/reliability/test_reliability_qwen3_omni.py -m slow
+pytest -s -v tests/dfx/reliability/test_reliability_wan22.py -m slow
+pytest -s -v tests/dfx/reliability/test_reliability_hunyuan_image.py -m slow
+pytest -s -v tests/dfx/reliability/test_reliability_voxcpm2.py -m slow
+```
+
+##### Adding a new model suite

 1. Add `test_reliability_<model>.py` under `tests/dfx/reliability/`.
-2. Define **`RELIABILITY_SCENARIOS`** and pass them through **`create_reliability_omni_server_params()`** with the correct deploy or e2e deploy-config directory (same pattern as existing files).
-3. Reuse **`helpers`** for OOM / kill / raw HTTP; prefer **`assert_fault_exception()`** and **`resolve_oom_device_spec()`** from `tests/dfx/conftest.py` for consistent device selection vs deploy YAML.
+2. Define **`RELIABILITY_SCENARIOS`** and pass them through **`create_reliability_omni_server_params()`** with the correct deploy or e2e stage-config directory (same pattern as existing files).
+3. Reuse **`helpers`** for OOM / kill / raw HTTP; prefer **`assert_fault_exception()`** and **`resolve_oom_device_spec()`** from `tests/dfx/conftest.py` for consistent device selection vs stage YAML.
 4. Register **`slow`** (and **`hardware_test`** if needed); extend **`.buildkite/cuda/test-weekly.yml`** when the suite should run in weekly L5.

 </details>
+
+-   -   ***Stability***: `pytest -s -v tests/dfx/stability/scripts/test_stability_qwen3_omni.py` or `pytest -s -v tests/dfx/stability/scripts/test_stability_wan22.py` (or add `test_stability_<model>.py` alongside a matching JSON config)
+    -   ***Reliability***: `pytest -s -v tests/dfx/reliability/test_reliability_<model>.py -m slow` (current suites: `qwen3_omni`, `wan22`, `hunyuan_image`, `voxcpm2`; add `test_reliability_<suite>.py` and a matching step in `.buildkite/cuda/test-weekly.yml` for new models)
@@ -9,7 +9,7 @@ This guide walks through the process of adding a new multi-stage model to vLLM-O
 3. [Step-by-Step Implementation](#step-by-step-implementation)
 4. [Key Components](#key-components)
 5. [Model Registration](#model-registration)
-6. [Pipeline and Deploy Configuration](#pipeline-and-deploy-configuration)
+6. [Stage Configuration](#stage-configuration)
 7. [Stage Input Processors](#stage-input-processors)
 8. [Testing](#testing)
 9. [Adding a Model Recipe](#adding-a-model-recipe)
@@ -316,28 +316,18 @@ _OMNI_MODELS = {

 The registry uses lazy loading, so the model class is imported only when needed.

-## Pipeline and Deploy Configuration
+## Stage Configuration

-Define fixed topology in `vllm_omni/model_executor/models/<model>/pipeline.py`
-with `PipelineConfig` and `StagePipelineConfig`, then register it in
-`vllm_omni/config/pipeline_registry.py`. For a complete example, see the
-[Qwen3-Omni pipeline](gh-file:vllm_omni/model_executor/models/qwen3_omni/pipeline.py).
+Create a YAML configuration file in `vllm_omni/deploy/`. For a complete example, see the [Qwen3-Omni configuration file](gh-file:vllm_omni/deploy/qwen3_omni_moe.yaml).

-### Pipeline topology fields
+### Key Configuration Fields

- **`model_stage`**: Logical stage name ("thinker", "talker", "code2wav", etc.)
- **`execution_type`**: Runtime family (`LLM_AR`, `LLM_GENERATION`, or `DIFFUSION`)
- **`model_arch`**: Stage architecture name, when different from the pipeline default
- **`input_sources`**: Upstream stage IDs that provide input to this stage
- **`custom_process_input_func`**: Function that processes inputs from previous stages
- **`final_output`**: Whether this stage produces user-facing output
- **`final_output_type`**: Output modality ("text", "audio", "image", etc.)
- **`owns_tokenizer`**: Whether this stage owns the pipeline tokenizer
-
-Create the matching runtime defaults in `vllm_omni/deploy/<model>.yaml` and set
-`PipelineConfig.default_deploy_config_name` to that file. The deploy YAML owns
-GPU placement, memory sizing, parallelism, connectors, and sampling defaults;
-it must not redefine topology fields.
+- **`model_stage`**: Which stage to run ("thinker", "talker", "code2wav", etc.)
+- **`model_arch`**: The model architecture name (must match registry)
+- **`engine_input_source`**: List of stage IDs that provide input to this stage
+- **`custom_process_input_func`**: Function to process inputs from previous stages
+- **`final_output`**: Whether this stage produces the final output (True/False)
+- **`final_output_type`**: Type of final output ("text", "audio", "image", etc.)

 ## Stage Input Processors

@@ -384,7 +374,7 @@ The stage transition process follows these steps:

 2. **Transition Detection**: The orchestrator checks if there's a next stage and calls `process_engine_inputs()` on it

-3. **Input Processing**: The stage input processor registered by the pipeline (implemented under `vllm_omni/model_executor/stage_input_processors/`) handles the transition:
+3. **Input Processing**: The stage input processor configured in stage YAML (under `vllm_omni/model_executor/stage_input_processors/`) handles the transition:
   ```python
   def process_engine_inputs(
       self, stage_list: list[Any], prompt: OmniTokensPrompt | TextPrompt = None
@@ -587,7 +577,7 @@ Adding a new model to vLLM-Omni involves:
 1. **Create model directory structure** with stage implementations
 2. **Implement unified model class** that orchestrates stages
 3. **Register model** in `registry.py`
-4. **Define pipeline topology and deploy defaults** in `pipeline.py` and `vllm_omni/deploy/`
+4. **Create stage configuration** YAML file
 5. **Implement stage input processors** for stage transitions
 6. **Write tests** to verify functionality
 7. **Add model recipe** to the [vllm-project/recipes](https://github.com/vllm-project/recipes) repository (see [Adding a Model Recipe](#adding-a-model-recipe) section)
@@ -600,8 +590,7 @@ For a complete reference implementation, see:
 - **Thinker**: `vllm_omni/model_executor/models/qwen3_omni/qwen3_omni_moe_thinker.py`
 - **Talker**: `vllm_omni/model_executor/models/qwen3_omni/qwen3_omni_moe_talker.py`
 - **Code2Wav**: `vllm_omni/model_executor/models/qwen3_omni/qwen3_omni_code2wav.py`
- **Pipeline topology**: `vllm_omni/model_executor/models/qwen3_omni/pipeline.py`
- **Deploy config**: `vllm_omni/deploy/qwen3_omni_moe.yaml`
+- **Stage config**: `vllm_omni/deploy/qwen3_omni_moe.yaml`
 - **Input processors**: `vllm_omni/model_executor/stage_input_processors/qwen3_omni.py`
 - **Registry**: `vllm_omni/model_executor/models/registry.py`
 - **Testing**: `vllm_omni/tests/e2e/offline_inference/test_qwen3_omni.py`
@@ -609,4 +598,4 @@ For a complete reference implementation, see:
 For more information, see:
 - [Architecture Overview](../../design/architecture_overview.md)
 - [Supported Models](../../models/supported_models.md)
- [Pipeline and Deploy Configuration Guide](../../configuration/stage_configs.md)
+- [Stage Configuration Guide](../../configuration/stage_configs.md)
@@ -20,7 +20,7 @@ pattern, refer to MOSS-TTS-Nano.
 4. [Step-by-Step Implementation](#step-by-step-implementation)
 5. [Key Components](#key-components)
 6. [Model Registration](#model-registration)
-7. [Pipeline and Deploy Configuration](#pipeline-and-deploy-configuration)
+7. [Stage Configuration](#stage-configuration)
 8. [Stage Input Processors](#stage-input-processors)
 9. [Online Serving Integration](#online-serving-integration)
 10. [Single-Stage Models](#single-stage-models)
@@ -78,7 +78,7 @@ Profile before optimizing.
 new TTS model must pass all three levels:

 | Layer | Catches | Tool |
-| ------- | --------- | ------ |
+|-------|---------|------|
 | Offline RTF / duration | Throughput regressions, missing audio, wrong sample rate | `end2end.py`, pytest e2e |
 | Browser streaming playback | Delta-vs-cumulative bugs, chunk boundary glitches, TTFP regressions | Gradio demo over `/v1/audio/speech?stream=true` |
 | Concurrent requests | Per-request state leaks, codec window round-robin gaps | `max_num_seqs>1` smoke with 4+ parallel prompts |
@@ -94,10 +94,10 @@ the symptom is crosstalk or truncation under load, nothing in single-request tes
 vLLM-Omni supports TTS models as multi-stage pipelines where each stage runs independently
 and can be placed on different devices. Qwen3-TTS has two stages:

-| Stage | Name                | Input           | Output                   |
-| ----- | ------------------- | --------------- | ------------------------ |
-| 0     | Code Predictor (AR) | Text tokens     | Discrete RVQ codec codes |
-| 1     | Code2Wav (Decoder)  | RVQ codec codes | Audio waveform           |
+| Stage | Name | Input | Output |
+|-------|------|-------|--------|
+| 0 | Code Predictor (AR) | Text tokens | Discrete RVQ codec codes |
+| 1 | Code2Wav (Decoder) | RVQ codec codes | Audio waveform |

 Each stage is a separate model class configured independently via YAML. The two stages
 are connected by the `async_chunk` framework, which enables inter-stage streaming for
@@ -170,7 +170,7 @@ and Qwen3-Omni).

 When adding a new TTS model, create the following structure:

-```text
+```
 vllm_omni/model_executor/models/
  your_model_name/
    __init__.py
@@ -201,7 +201,7 @@ it would not be picked up — the hub README is the documented surface.
 **Qwen3-TTS reference files:**

 | File | Purpose |
-| ------ | --------- |
+|------|---------|
 | `models/qwen3_tts/qwen3_tts.py` | Unified model class |
 | `models/qwen3_tts/qwen3_tts_code_predictor_vllm.py` | Stage 0 - optimized AR |
 | `models/qwen3_tts/qwen3_tts_code2wav.py` | Stage 1 - decoder |
@@ -427,92 +427,111 @@ _OMNI_MODELS = {

 The registry uses lazy loading - model classes are only imported when needed.

-## Pipeline and Deploy Configuration
+## Stage Configuration

-Define fixed topology in `models/<model>/pipeline.py`. The execution type
-selects the scheduler and worker family:
+Each stage has a `worker_type` that determines how it is scheduled:

- `StageExecutionType.LLM_AR` uses the autoregressive runtime with PagedAttention.
- `StageExecutionType.LLM_GENERATION` uses the generation runtime for stages such as audio decoders.
+- `worker_type: ar` - autoregressive stage, uses `OmniARScheduler` with PagedAttention
+- `worker_type: generation` - non-AR stage (e.g. decoder), uses `OmniGenerationScheduler`

-Key topology fields belong to `StagePipelineConfig`:
+Key configuration fields:

 | Field | Description |
 |-------|-------------|
-| `model_stage` | Logical stage name (`ar_stage`, `decoder`, etc.). |
-| `execution_type` | Runtime family for this stage. |
-| `input_sources` | Upstream stage IDs that provide input. |
-| `model_arch` | Stage-specific architecture name, when it differs from the pipeline default. |
-| `engine_output_type` | Output representation such as `latent` or `audio`. |
-| `custom_process_next_stage_input_func` | Processor for full-payload stage handoff. |
-| `async_chunk_process_next_stage_input_func` | Processor for streaming chunk handoff. |
-| `final_output` / `final_output_type` | Whether this stage produces user-facing output and its modality. |
-| `owns_tokenizer` | Whether this stage supplies the pipeline tokenizer. |
+| `model_stage` | Which stage to initialize (`ar_stage`, `decoder`, etc.) |
+| `model_arch` | Architecture name, must match `registry.py` |
+| `engine_input_source` | List of upstream stage IDs that provide input (e.g. `[0]`) |
+| `engine_output_type` | Output type: `latent` for intermediate, `audio` for final |
+| `custom_process_next_stage_input_func` | Async chunk processor function path (streaming only) |
+| `final_output` | Whether this stage produces the final user-facing output |
+| `final_output_type` | Type of final output (`audio`, `text`, etc.) |

-For example, a two-stage TTS topology can be defined as:
+!!! note
+    New in-tree models should define frozen topology in `models/<model>/pipeline.py`,
+    register it in `vllm_omni/config/pipeline_registry.py`, and put deployment
+    knobs in `vllm_omni/deploy/<model>.yaml`. Use `--deploy-config` to load a
+    custom deployment YAML.

-```python
-from vllm_omni.config.stage_config import (
-    PipelineConfig,
-    StageExecutionType,
-    StagePipelineConfig,
-)
-
-_PROC = "vllm_omni.model_executor.stage_input_processors.your_model_name"
-
-YOUR_TTS_PIPELINE = PipelineConfig(
-    model_type="your_model_name",
-    default_deploy_config_name="your_model_name.yaml",
-    model_arch="YourTTSModelForConditionalGeneration",
-    stages=(
-        StagePipelineConfig(
-            stage_id=0,
-            model_stage="ar_stage",
-            execution_type=StageExecutionType.LLM_AR,
-            input_sources=(),
-            owns_tokenizer=True,
-            engine_output_type="latent",
-            custom_process_next_stage_input_func=f"{_PROC}.ar2decoder",
-            async_chunk_process_next_stage_input_func=f"{_PROC}.ar2decoder_async_chunk",
-        ),
-        StagePipelineConfig(
-            stage_id=1,
-            model_stage="decoder",
-            execution_type=StageExecutionType.LLM_GENERATION,
-            input_sources=(0,),
-            model_arch="YourTTSDecoder",
-            engine_output_type="audio",
-            final_output=True,
-            final_output_type="audio",
-        ),
-    ),
-)
-```
-
-Register the pipeline in `vllm_omni/config/pipeline_registry.py`. Runtime
-placement and sizing belong in `vllm_omni/deploy/your_model_name.yaml`:
+### Batch mode

 ```yaml
-async_chunk: true
+# stage_configs/your_model_name.yaml

-stages:
+stage_args:
  - stage_id: 0
-    devices: "0"
-    max_num_seqs: 64
+    stage_type: llm
+    runtime:
+      devices: "0"
+    engine_args:
+      model_stage: ar_stage
+      max_num_seqs: 64
+      model_arch: YourTTSModelForConditionalGeneration
+      worker_type: ar
+      scheduler_cls: vllm_omni.core.sched.omni_ar_scheduler.OmniARScheduler
+      engine_output_type: latent
    default_sampling_params:
      temperature: 0.9
      top_k: 50
      max_tokens: 2048

  - stage_id: 1
-    devices: "0"
-    max_num_seqs: 1
+    stage_type: llm
+    runtime:
+      devices: "0"
+    engine_args:
+      model_stage: decoder
+      model_arch: YourTTSModelForConditionalGeneration
+      worker_type: generation
+      scheduler_cls: vllm_omni.core.sched.omni_generation_scheduler.OmniGenerationScheduler
+      engine_output_type: audio
+    engine_input_source: [0]
+    final_output: true
+    final_output_type: audio
 ```

-Set `async_chunk: false` for end-to-end handoff. The registered pipeline
-selects the full-payload or async chunk processor; processor paths and topology
-must not be moved into the deploy YAML. Use `--deploy-config` to load a custom
-deployment overlay.
+### Streaming mode (async_chunk)
+
+Add `async_chunk: true` at the top level and specify `custom_process_next_stage_input_func`
+on Stage 0 to define how intermediate outputs are chunked and forwarded:
+
+```yaml
+# stage_configs/your_model_name_async_chunk.yaml
+
+async_chunk: true
+
+stage_args:
+  - stage_id: 0
+    stage_type: llm
+    runtime:
+      devices: "0"
+    engine_args:
+      model_stage: ar_stage
+      max_num_seqs: 64
+      model_arch: YourTTSModelForConditionalGeneration
+      worker_type: ar
+      scheduler_cls: vllm_omni.core.sched.omni_ar_scheduler.OmniARScheduler
+      engine_output_type: latent
+      custom_process_next_stage_input_func: >
+        vllm_omni.model_executor.stage_input_processors.your_model_name.ar2decoder_async_chunk
+    default_sampling_params:
+      temperature: 0.9
+      top_k: 50
+      max_tokens: 2048
+
+  - stage_id: 1
+    stage_type: llm
+    runtime:
+      devices: "0"
+    engine_args:
+      model_stage: decoder
+      model_arch: YourTTSModelForConditionalGeneration
+      worker_type: generation
+      scheduler_cls: vllm_omni.core.sched.omni_generation_scheduler.OmniGenerationScheduler
+      engine_output_type: audio
+    engine_input_source: [0]
+    final_output: true
+    final_output_type: audio
+```

 ## Stage Input Processors

@@ -528,9 +547,9 @@ Understanding what's available in stage outputs:
 - `stage_list[source_id].engine_outputs` - list of `EngineCoreOutput` objects
 - Each `EngineCoreOutput` has `outputs` - list of `RequestOutput` objects
 - Each `RequestOutput` has:
-    - `token_ids` - generated token IDs
-    - `multimodal_output` - dict with keys matching your model's `OmniOutput.multimodal_outputs`
-    - `prompt_token_ids` - original prompt token IDs
+  - `token_ids` - generated token IDs
+  - `multimodal_output` - dict with keys matching your model's `OmniOutput.multimodal_outputs`
+  - `prompt_token_ids` - original prompt token IDs

 ### Batch mode (non-streaming)

@@ -610,7 +629,6 @@ def ar2decoder_async_chunk(
 ```

 Key points:
-
 - `transfer_manager` is the `OmniChunkTransferAdapter` that owns the chunk lifecycle
 - Each call appends one AR decode step's output; a chunk is emitted every `chunk_size` steps
 - The final (possibly partial) chunk is flushed when `is_finished` is true
@@ -665,7 +683,6 @@ Create `vllm_omni/entrypoints/openai/tts_adapters/your_model.py`:

 ```python
 # SPDX-License-Identifier: Apache-2.0
-# SPDX-FileCopyrightText: Copyright contributors to the vLLM-Omni project
 """YourModel serving adapter."""

 from typing import TYPE_CHECKING
@@ -804,7 +821,7 @@ directly from the model's own generator.

 ### Directory structure

-```text
+```
 vllm_omni/model_executor/models/your_model_name/
    __init__.py
    modeling_your_model_name.py    # unified class: load_weights + forward + streaming
@@ -815,40 +832,32 @@ vllm_omni/deploy/your_model_name.yaml

 No stage input processor is needed.

-### Pipeline and deploy config
+### Stage config

-Use a single `LLM_AR` stage that owns the tokenizer and produces final audio:
-
-```python
-YOUR_TTS_PIPELINE = PipelineConfig(
-    model_type="your_model_name",
-    default_deploy_config_name="your_model_name.yaml",
-    model_arch="YourModelForCausalLM",
-    stages=(
-        StagePipelineConfig(
-            stage_id=0,
-            model_stage="your_model_stage_key",
-            execution_type=StageExecutionType.LLM_AR,
-            input_sources=(),
-            owns_tokenizer=True,
-            engine_output_type="audio",
-            final_output=True,
-            final_output_type="audio",
-        ),
-    ),
-)
-```
-
-The deploy YAML controls runtime behavior. Set `max_num_seqs` to at least 4
-for concurrent production use:
+Use a single stage with `worker_type: ar`. The `is_comprehension: true` field and the
+top-level `async_chunk: false` are required — omitting them causes silent
+misclassification in the serving layer. Set `max_num_seqs` to at least 4 for
+concurrent production use.

 ```yaml
+# stage_configs/your_model_name.yaml
 async_chunk: false

-stages:
+stage_args:
  - stage_id: 0
-    devices: "0"
-    max_num_seqs: 4
+    stage_type: llm
+    is_comprehension: true          # required for serving_speech.py dispatch
+    runtime:
+      devices: "0"
+    engine_args:
+      model_stage: your_model_stage_key
+      model_arch: YourModelForCausalLM
+      worker_type: ar
+      scheduler_cls: vllm_omni.core.sched.omni_ar_scheduler.OmniARScheduler
+      engine_output_type: audio
+      max_num_seqs: 4               # min 4 for concurrent requests; default 1 causes gaps
+    final_output: true
+    final_output_type: audio
 ```

 ### Generator-based streaming pattern
@@ -952,17 +961,10 @@ is correct. Stage the modified files and commit again — do not revert the chan
 Common failures and fixes:

 | Check | Cause | Fix |
-| ------- | ------- | ----- |
+|-------|-------|-----|
 | `ruff F841` | Local variable assigned but never used | Remove the extraction or forward it to the model call |
 | `ruff E402` | Module-level import not at top of file | Move import to the top-level import block |
 | `ruff format` | Line length, spacing, or quote style | Accept the auto-fix, stage, and re-commit |
-| `check-spdx-header` | Missing header, or copyright still says `vLLM project` | Use `Copyright contributors to the vLLM-Omni project`; restage the rewrite |
-| `check-forbidden-imports` | Stdlib `re`/`base64`, pickle, Hugging Face Hub API, or direct Triton/TileLang | `import regex as re` and `pybase64`; do not grow the allowlist without review |
-| `check-torch-cuda-call` | New `torch.cuda.*` call site | Use `current_omni_platform`; do not grow `ALLOWED_FILES` without review |
-| `check-tts-adapter-migration` | New `_tts_model_type` branch in `serving_speech.py` | Put logic in `tts_adapters/`; lower `MAX_MODEL_TYPE_BRANCHES` when removing branches |
-| `check-test-ci-coverage` | Test file missing level or hardware mark | Add `core_model`/… plus `cpu`/`cuda`/`hardware_test(` |
-| `shellcheck` | Native `shellcheck` missing, or script warning | Install via apt/dnf/brew (or `shellcheck.exe` on Windows). See [Linting](../README.md#linting) |
-| `mypy-3.10` / `markdownlint-cli2` / `check-buildkite` | Types, docs markdown, or Buildkite YAML | See [Linting](../README.md#linting) |

 ### DCO sign-off

@@ -1017,7 +1019,7 @@ Adding a TTS model to vLLM-Omni involves:
 ### Qwen3-TTS Reference Files

 | File | Purpose |
-| ------ | --------- |
+|------|---------|
 | `models/qwen3_tts/qwen3_tts.py` | Unified model class |
 | `models/qwen3_tts/qwen3_tts_code_predictor_vllm.py` | AR stage with vLLM fused ops |
 | `models/qwen3_tts/qwen3_tts_code2wav.py` | Decoder stage with `chunked_decode_streaming()` |
@@ -1029,4 +1031,4 @@ For more information, see:

 - [Architecture Overview](../../design/architecture_overview.md)
 - [Async Chunk Design](../../design/feature/async_chunk.md)
- [Pipeline and Deploy Configuration Guide](../../configuration/stage_configs.md)
+- [Stage Configuration Guide](../../configuration/stage_configs.md)
@@ -335,8 +335,8 @@ The single resolution boundary is implemented by
 `StageConfigFactory.create_from_model()` and
 `VllmOmniConfig.from_pipeline_config()` in
 [`vllm_omni/config`](https://github.com/vllm-project/vllm-omni/tree/main/vllm_omni/config).
-The legacy `stage_args` YAML path has been removed. Model topology now resolves
-through `PipelineConfig`, with runtime overrides supplied by `DeployConfig`.
+The legacy `stage_args` YAML path remains only for models that have not yet
+migrated to `PipelineConfig` and `DeployConfig`.

 In the typed path, each stage configuration derives from
 `BaseVllmOmniStageConfig` and is specialized as
@@ -211,39 +211,38 @@ In sequential mode, each stage must wait for the previous stage to complete enti

 ## Configuration

-Enable async chunk mode in the deploy YAML:
+Enable async_chunk in stage configuration YAML:

 ```yaml
 async_chunk: true
+stage_args:
+  - stage_id: 0
+    engine_args:
+      custom_process_next_stage_input_func: vllm_omni.model_executor.stage_input_processors.qwen3_omni.thinker2talker_async_chunk
+  - stage_id: 1
+    engine_args:
+      custom_process_next_stage_input_func: vllm_omni.model_executor.stage_input_processors.qwen3_omni.talker2code2wav_async_chunk
 ```

-The registered `PipelineConfig` owns the async handoff processor functions.
-For Qwen3-Omni these are `thinker2talker_async_chunk` and
-`talker2code2wav_async_chunk`; deploy YAML only selects the mode and runtime
-sizing.
-
-### Configuration ownership
+### Stage Configuration

 - `async_chunk: bool`: Enable/disable async chunk mode
- `async_chunk_process_next_stage_input_func: str`: Pipeline-owned chunk processor path
- `execution_type: StageExecutionType`: Pipeline-owned runtime family
- `connectors: dict`: Deploy-owned connector definitions
+- `custom_process_next_stage_input_func: str`: Path to custom chunk processing function; receives `(transfer_manager, pooling_output, request)`. For qwen3-omni: `thinker2talker_async_chunk`, `talker2code2wav_async_chunk`
+- `stage_connector_config: dict`: Connector configuration
+- `worker_type: str`: Model type, e.g. `"ar"` or `"generation"` (used by OmniChunkTransferAdapter for mode-specific payload handling)
 - `max_num_seqs: int`: Maximum number of sequences for concurrent processing in the stage

+
 ### Connector Configuration

 ```yaml
 connectors:
-  connector_of_shared_memory:
-    name: SharedMemoryConnector
-
-stages:
-  - stage_id: 0
-    output_connectors:
-      to_stage_1: connector_of_shared_memory
-  - stage_id: 1
-    input_connectors:
-      from_stage_0: connector_of_shared_memory
+  - from_stage: 0
+    to_stage: 1
+    spec:
+      name: SharedMemoryConnector
+      extra:
+        stage_id: 0
 ```

 ### Code2Wav Batch Configuration
@@ -251,10 +250,13 @@ stages:
 For optimal performance with async_chunk, the code2wav stage should be configured with batching:

 ```yaml
-stages:
+stage_args:
  - stage_id: 2  # code2wav stage
-    devices: "1"
-    max_num_seqs: 64  # Enables batched audio generation
+    runtime:
+      devices: "1"
+    engine_args:
+      model_stage: code2wav
+      max_num_seqs: 64  # Enables batched audio generation
 ```

 ## Related Files
@@ -124,8 +124,8 @@ When `execute_model_batch` returns a `COMPUTE_DONE` with a single `async_output_
 1. **Drain Before Memory Release (`drain_async_outputs` / `_ASYNC_OUTPUT_DRAIN_TIMEOUT_S`)**:
   When workers transition into sleep states (`handle_sleep_task`) or invoke memory-releasing methods, `WorkerProc.drain_async_outputs()` blocks up to `_ASYNC_OUTPUT_DRAIN_TIMEOUT_S` (10.0s) until all in-flight background D2H/SHM packing tasks finish. This acts as a synchronization barrier preventing worker sleep cycles from releasing device tensors while the side CUDA stream is still actively reading them. Draining typically completes within 10–50 ms under normal operation.

-2. **Timeout Diagnostics (`_async_output_timeout()`)**:
-   The engine waits for `wait_output_ready()` with a timeout of `_async_output_timeout()` — 600.0s by default, overridable per run with the `VLLM_OMNI_ASYNC_OUTPUT_TIMEOUT` environment variable (a non-numeric or non-positive value is ignored with a warning and the default applies, since this resolves on the request path). If a timeout occurs, the executor logs detailed diagnostic bookkeeping (pending futures, cached outputs, and batch split maps) to identify whether the stall occurred in the worker, pump, or waiter. The packing itself takes milliseconds, but the wait is queued behind the step's GPU work, so its wall-clock duration tracks step time; the bound is generous because a hung engine is surfaced by the worker monitor and `check_health()`, not by this timeout.
+2. **Timeout Diagnostics (`_ASYNC_OUTPUT_TIMEOUT`)**:
+   The engine waits for `wait_output_ready()` with a timeout of `_ASYNC_OUTPUT_TIMEOUT` (30.0s). If a timeout occurs, the executor logs detailed diagnostic bookkeeping (pending futures, cached outputs, and batch split maps) to identify whether the stall occurred in the worker, pump, or waiter.

 3. **Queue Serialization & Atomic Future Resolution**:
   - `result_mq` writes are serialized with `_result_mq_lock` to protect the single-writer `MessageQueue` against concurrent writes from the worker main loop (`COMPUTE_DONE`) and background thread (`OUTPUT_READY`).
@@ -61,8 +61,7 @@ unstructured keyword dictionaries:
 - `quant` is consumed by FlashInfer and TRTLLM with backend-specific value
  validation;
 - `skip_softmax` is consumed by TRTLLM; and
- `block_sparse` is consumed by block-sparse backends such as RainFusion; and
- `fastvideo_vsa_topk` is consumed by FastVideo VSA.
+- `block_sparse` is consumed by block-sparse backends such as RainFusion.

 A backend reads only the fields it owns and rejects incompatible values. New
 options should be added to a shared typed spec only when more than one backend
@@ -88,19 +87,3 @@ An implementation change is complete only when it:
   corresponding user guide; and
 6. updates the overview matrix without moving algorithm details back into the
   landing page.
-
-## FastVideo VSA model metadata
-
-FastVideo VSA support is scoped to `FastVideo/FastWan2.2-TI2V-5B-Diffusers`, whose text-to-video and image-to-video modes both use `Wan22Pipeline`. It operates on a flattened DiT sequence but partitions tokens in
-the original latent video grid. Wan integrations therefore attach the
-post-patch `(T, H, W)` shape as `vsa_dit_seq_shape` attention metadata. The
-backend validates that `T * H * W` equals the sequence length, derives the
-runtime block count, and selects the configured top-k key/value blocks for
-each query block.
-
-Checkpoint-specific compensation remains model-owned. Wan layers pass an
-optional learned `gate_compress` projection through attention metadata when
-the checkpoint contains those weights. Checkpoints without the projection do
-not allocate or execute it. When top-k selects every block, native checkpoints
-route to SDPA, while FastVideo DMD checkpoints preserve the VSA all-block path
-to retain checkpoint semantics.
@@ -59,18 +59,19 @@ This `metadata` must be passed through the control plane so `get()` can locate t

 ## Configuration Model

-Define connectors at the top level of the deploy YAML:
+Define connectors in runtime:

 ```yaml
-connectors:
-  connector_of_shared_memory:
-    name: SharedMemoryConnector
+runtime:
+  connectors:
+    connector_of_shared_memory:
+      name: SharedMemoryConnector
 ```

 Wire stages to connectors:

 ```yaml
-stages:
+stage_args:
  - stage_id: 0
    output_connectors:
      to_stage_1: connector_of_shared_memory
@@ -1,386 +0,0 @@
-# Host Weight Runtime
-
-The Host Weight Runtime is a loader-facing feature for reusing immutable,
-runtime-ready model weights across workers on one host. It lets a model
-integration replace repeated checkpoint loading and transformation with an
-exact lookup of a previously published host representation, while keeping the
-canonical model source authoritative.
-
-This feature is shared infrastructure. Diffusion, autoregressive, speech, and
-future model integrations may depend on the top-level
-`vllm_omni.host_weight_runtime` package without depending on one another's
-loader or execution stack. The internal component and filesystem contracts are
-specified in the [Host Weight Runtime module design](../module/host_weight_runtime.md).
-
-## Status
-
-The first implementation provides contracts and a CPU local-filesystem store.
-The initial diffusion consumer contract additionally defines typed,
-representation-independent final-layout identity/restoration mechanics plus a
-concrete BF16-with-preserved-FP32 policy for MiniMax H3. It remains
-library-only: no loader or DLO path selects, publishes, restores, or transports
-that artifact yet.
-
-V1 includes:
-
- exact runtime-weight identity and immutable manifests;
- coordinated local lookup and one-producer publication;
- descriptor-backed safetensors mmap leases;
- preferred and required resolution policy;
- explicit, separately reported post-load publication;
- validation, deny, quarantine, cleanup, and capacity controls; and
- typed reports for every terminal resolution outcome.
-
-V1 does not include:
-
- a public CLI, loader activation, or default-on model integration;
- lease handoff to DLO or another transport consumer;
- FP8, quantized, merged-adaptation, or additional model producers;
- CUDA registration, pinned staging, H2D scheduling, or GPU kernels;
- a remote artifact provider or cross-node coordination;
- automatic eviction; or
- a change to DLO AllGather or no-AllGather behavior.
-
-## Motivation and use cases
-
-Model loading can create the same final host representation repeatedly. This
-is especially expensive when loading performs checkpoint decoding, tensor
-renaming, TP slicing, quantization, packing, or scale construction before GPU
-transfer. Independent workers may then retain private CPU copies of identical
-runtime weights.
-
-The Host Weight Runtime is useful when:
-
- multiple same-node workers request semantically identical final weights;
- constructing those weights is materially more expensive than validating and
-  mapping a local artifact;
- the runtime layout can be identified exactly and reproduced deterministically;
- the workers can share immutable file-backed pages through the OS page cache;
-  and
- canonical loading remains available when policy permits fallback.
-
-Typical consumers include same-node diffusion replicas, DLO host-weight
-sources, and future transformed or quantized model loaders. Request routing and
-replica orchestration remain outside this feature.
-
-This feature is not zero-copy GPU execution. A lease exposes stable CPU tensor
-views and mapped ranges. A separate transport still decides whether to use
-registered mmap, private pinned staging, synchronous copies, or asynchronous
-H2D transfer.
-
-## Resolution behavior
-
-The loader resolves the immutable canonical source and computes the exact
-requested identity before asking the runtime for a representation.
-
-```mermaid
-flowchart TD
-    L["Loader resolves canonical source"] --> I["Compute exact WeightArtifactIdentity"]
-    I --> M{"Runtime mode"}
-    M -->|"disabled"| C["Canonical loader"]
-    M -->|"preferred or required"| A{"Validated local artifact?"}
-    A -->|"yes"| R["Return HostWeightLease"]
-    A -->|"no"| X["Remote exact artifact (future)"]
-    X --> P{"Registered producer available?"}
-    P -->|"yes"| B["Build, validate, and publish atomically"]
-    B --> R
-    P -->|"no or recoverable failure"| F{"Policy permits fallback?"}
-    F -->|"preferred"| C
-    F -->|"required"| E["Fail startup"]
-    P -->|"nonretryable failure"| E
-    C --> W{"Post-load publication enabled?"}
-    W -->|"yes"| B2["Publish final model through POST_LOAD_ONLY producer"]
-    B2 --> CL["Close validated publication lease"]
-    CL --> R2["Return separate publication report"]
-    R2 --> D
-    W -->|"no"| D["Keep canonical model"]
-```
-
-The modes are:
-
-| Mode | Observable behavior |
-| --- | --- |
-| `disabled` | Use canonical loading directly without probing storage, identity, credentials, or topology. |
-| `preferred` | Return an exact lease when available; otherwise use canonical fallback only for a miss, invalid cache entry, or typed retryable failure. |
-| `required` | Fail when an exact lease cannot be acquired. |
-
-During pre-load resolution, an unsupported capability, semantic identity
-collision, producer failure, or publication failure is nonretryable and remains
-visible even in preferred mode. A post-load publication failure is likewise
-visible in its own report, but cannot revise the canonical-fallback outcome.
-Storage policy must never disguise a semantic or configuration error as a cache
-miss.
-
-## Loader and restoration sequence
-
-The model integration owns the end-to-end loading transaction. The runtime
-does not construct a model or invoke the canonical loader.
-
-```mermaid
-sequenceDiagram
-    participant L as Loader adapter
-    participant R as HostWeightRuntime
-    participant S as HostWeightStore
-    participant P as WeightProducer
-    participant X as WeightRestorer
-    participant T as GPU transport
-
-    L->>L: Resolve canonical revision and exact identity
-    L->>R: resolve(identity, producer)
-    R->>S: lookup(exact identity)
-    alt validated hit
-        S-->>R: HostWeightLease
-        R-->>L: lease and LOCAL_HIT report
-        L->>X: plan_restore(model, lease)
-        X-->>L: validation-only restore plan
-        L->>X: commit() once
-    else miss with allowed producer
-        R->>S: get_or_build(identity, producer)
-        S->>P: produce(store-scoped writer)
-        P-->>S: final-layout tensors and metadata
-        S-->>R: validated HostWeightLease
-        R-->>L: lease and LOCAL_PRODUCTION report
-        L->>X: plan_restore(model, lease)
-        X-->>L: validation-only restore plan
-        L->>X: commit() once
-    else policy permits canonical fallback
-        R-->>L: CANONICAL_FALLBACK
-        L->>L: Run canonical loader
-        opt explicit post-load publication enabled
-            L->>R: publish_after_load(identity, POST_LOAD_ONLY producer)
-            R->>S: get_or_build(identity, producer)
-            S-->>R: validated HostWeightLease or typed failure
-            R->>R: close publication lease
-            R-->>L: separate publication report
-        end
-    else required or nonretryable failure
-        R-->>L: FAILED report
-    end
-    L->>T: consume final CPU tensors and any lease
-    T-->>L: transfer teardown complete
-    L->>L: close lease when one was acquired
-```
-
-`plan_restore()` must not mutate the model or lease. `commit() -> None` is the
-sole one-shot model mutation. If planning fails, canonical fallback may reuse
-the untouched model. If commit begins and fails, the partially hydrated model
-must be discarded and canonical fallback must construct a fresh model.
-
-`publish_after_load()` is synchronous in V1 and accepts only a
-`POST_LOAD_ONLY` producer. Its report is separate from the terminal resolution,
-so a publication failure cannot rewrite a successful canonical fallback. A
-successful publication closes the store-returned lease inside the runtime and
-warms only future startups. It does not restore, rebind, or otherwise mutate the
-canonically loaded model serving the current startup.
-`allow_local_build` gates producers during pre-load resolution, while
-`allow_post_load_publish` independently gates this explicit post-load path.
-
-## Exact representation identity
-
-The store performs exact lookup. It never silently converts one representation
-into another or substitutes the first backing that responds.
-
-Identity includes:
-
- immutable model revision and source fingerprint;
- model component and ownership boundary;
- representation name, dtype, and format metadata;
- final tensor layout and semantic parallel coordinates;
- static adaptation identity; and
- producer implementation, manifest, and restorer schema versions.
-
-The requested representation is selected by the loader. The store chooses
-where to obtain that exact representation: validated local artifact, future
-remote materialization, or a registered producer.
-
-### Parallelism
-
-Parallel coordinates are included only when they change bytes, shape, layout,
-or component ownership.
-
-| Dimension | Identity and sharing rule |
-| --- | --- |
-| DP | Exclude DP rank for replicated weights so same-node replicas can acquire the same artifact. Include a coordinate only if DP changes weight ownership. |
-| TP | Include TP size and rank when each rank owns different tensor slices or packed layouts. Each distinct TP shard is a separate exact artifact. |
-| SP | Include SP size and backend when they change the weight layout. Exclude SP rank when all SP ranks consume identical bytes. |
-| PP | Encode component ownership or stage-local layout when PP changes which weights belong to the consumer. |
-| EP | Encode expert ownership and layout whenever ranks own different expert weights. |
-
-The runtime does not infer these rules from process-group topology. The model
-adapter is responsible for constructing a correct identity.
-
-### Quantization and adaptations
-
-Runtime BF16, FP8, packed quantized weights, and future formats are distinct
-representations. Conversion is performed by an explicitly versioned producer,
-never by cache coercion. A producer must publish the final layout consumed by
-its matching restorer.
-
-Dynamic LoRA overlays are not part of a reusable base-weight artifact. A
-statically merged adapter is cacheable only as a separate identity containing
-the adapter fingerprint and merge semantics.
-
-### Initial diffusion final-layout contract
-
-The shared diffusion contract covers complete final-layout DiT parameters and
-persistent buffers. Text encoders, VAEs, non-persistent derived state, and other
-pipeline components remain outside the artifact. One explicit representation
-policy selects allowed dtypes, tensor roles, physical layout identity, producer
-ABI, manifest schema, and restoration schema.
-
-The contract is intentionally separate from loader activation:
-
- `FinalLayoutRequest` contains typed loader identity/configuration fingerprints,
-  TP coordinate, and conservative SP semantics. It has no open metadata bag,
-  DP coordinate, SP rank, device identity, DLO transfer mode, registration
-  policy, or store path.
- `FinalLayoutArtifactSpec` binds one `WeightRepresentation` and runtime-layout
-  name to explicit producer/restorer schemas and a canonical, versioned
-  implementation ABI descriptor. Compatibility never depends on reflective
-  source inspection.
- `PreparedWeightSource` snapshots immutable revisions or exact local file
-  content plus a typed checkpoint-adapter identity before ordinary
-  materialization. Source replacement before or during production fails
-  publication. A hash-looking symlink basename is trusted only for an explicit
-  Hugging Face Hub source whose repository ID and
-  `models--.../snapshots/<revision> -> blobs/<hash>` topology validate; every
-  local or otherwise unverified symlink target is content-hashed.
- the tensor ownership digest records exact runtime names, kinds, shapes,
-  semantic roles, dtypes, and strides from a CPU or meta model skeleton;
- `FinalLayoutTensorRestorer` accepts only an exact lease identity, validates
-  complete policy-defined coverage without mutation, and returns a one-shot
-  commit plan;
- each model declares one dtype-neutral `FinalLayoutModelContract` with an
-  explicit implementation version and a post-commit validator; and
- `FinalLayoutBF16Producer` accepts only the matching identity context and a
-  finalized CPU model. It is `POST_LOAD_ONLY` and `SINGLE_PROCESS` per exact TP
-  coordinate. Its BF16 policy preserves model-declared FP32 parameters and
-  buffers and revalidates MiniMax H3 mixed-precision invariants.
-
-Other representations reuse source identity, typed parallel identity, tensor
-ownership, and exact restoration only when their policy proves those semantics.
-For example, runtime FP8 needs a separate policy/producer for generated scales,
-quantization metadata, and Cutlass physical layouts; it is not enabled by
-changing a dtype string on the BF16 producer.
-
-This stage makes no startup, sharing, or DLO performance claim. A following
-consumer PR owns disabled/preferred/required precedence, mixed-component loader
-transactions, warm-hit restoration, and transactional lease handoff. A TP2
-prewarm deployment will require a matching TP2 producer cohort to populate both
-TP-coordinate identities even though the store coordinates each artifact
-independently.
-
-## Host sharing and GPU transport
-
-Every process receives its own virtual mappings and `HostWeightLease`, but
-workers mapping the same local artifact can share physical file-backed pages
-through the OS page cache. This avoids independent private tensor allocations;
-it does not guarantee that process PSS reports exactly one model copy.
-
-The ownership boundary is:
-
- the store owns immutable artifact files, publication, and lifecycle;
- the kernel owns page-cache residency and placement;
- the lease owns process-local mappings and the shared artifact lock; and
- transport owns page registration, page locking, private staging, H2D copies,
-  streams, device buffers, and lease release ordering.
-
-DLO AllGather and no-AllGather remain transport and execution choices. A DLO
-integration may consume a lease, but the Host Weight Runtime does not choose a
-parallel collective or orchestrate DP requests. See the
-[DLO feature design](offloader/distributed_layerwise_offload.md).
-
-## Locality and NUMA policy
-
-The V1 backend is node-local. It accepts an allowlist of known local disk
-filesystems plus tmpfs/ramfs, records the detected kernel filesystem type, and
-rejects known remote or unknown filesystems. NFS, CIFS, Lustre, Ceph, and other
-cross-node mounts cannot silently satisfy the local backend because their
-page-cache and advisory-lock behavior does not provide the required node-local
-contract.
-
-A NUMA-specific root creates a separate storage domain but does not by itself
-place page-cache pages on that NUMA node. A topology-aware integration must
-also pin workers, establish local first touch or prefault, perform transport
-registration in the same domain, and collect residency evidence.
-
-Tmpfs artifacts consume host memory and may consume swap. They must be
-accounted as memory-backed storage rather than ordinary disk capacity.
-
-## Concurrency and timeouts
-
-One process per exact identity owns a build; other workers wait and then acquire
-leases for the published artifact. Publication is invisible until all payloads
-and metadata are validated, hashed, fsynced, and atomically renamed.
-
-`coordination_timeout_seconds` bounds filesystem lock acquisition. It does not
-cancel synchronous validation, a producer that has already started, or atomic
-publication. A hung in-process producer therefore blocks its owning process and
-must be handled by external process supervision. Enforceable producer
-cancellation requires a future process-isolated producer contract.
-
-Leases keep a shared artifact lock for their lifetime. A forked child may close
-its inherited descriptors but cannot unlock the parent process's lease. Cleanup
-uses a nonblocking exclusive lock and reports an active lease instead of
-removing live mappings.
-
-## Failure and fallback contract
-
-| Condition | Preferred mode | Required mode |
-| --- | --- | --- |
-| Exact local hit | Return lease | Return lease |
-| Local miss | Try later backing or canonical fallback | Try later backing or fail |
-| Invalid or denied artifact | Quarantine/rebuild when possible; otherwise canonical fallback | Quarantine/rebuild or fail |
-| Retryable lock, domain, or capacity failure | Canonical fallback | Fail |
-| Unsupported producer or backend | Fail | Fail |
-| Identity collision | Fail | Fail |
-| Pre-load producer or atomic publication failure | Fail | Fail |
-| Post-load publication failure after canonical fallback | Keep canonical model; report publication failure | Not reached through required resolution |
-| Restore planning failure | Canonical fallback may reuse untouched model | Fail |
-| Restore commit failure | Discard model; fallback requires a fresh instance | Fail |
-
-Cache failures should normally reduce performance rather than availability,
-but only when the typed failure explicitly permits fallback. Canonical source,
-authentication, configuration, and semantic errors remain visible.
-
-## Consumer integration requirements
-
-A consumer PR must:
-
-1. Resolve an immutable canonical model source before cache lookup.
-2. Construct the exact final representation identity, including relevant
-   parallel, quantization, and adaptation semantics.
-3. Register a deterministic producer for that identity or support lookup-only
-   operation.
-4. Provide a validation-only restorer with a one-shot commit.
-5. Keep GPU transport outside the producer, store, and restorer contracts.
-6. Handle preferred fallback and required failure without reusing a model after
-   a failed restore commit.
-7. Retain the lease until every transport operation that may access mapped
-   memory has completed.
-8. Emit and test the terminal resolution report and any separate post-load
-   publication report.
-
-Consumer validation must prove:
-
- output parity with canonical loading;
- exact warm-hit work avoidance;
- correct TP/SP/PP/EP ownership and layout identity;
- correct BF16, FP8, quantized, or adaptation semantics;
- shared-backing evidence when host-memory savings are claimed;
- clean unmapping, unregistration, and artifact-lock release; and
- startup, host-memory, and transport effects for the claimed deployment.
-
-## Rollout
-
-The rollout is intentionally staged:
-
-1. Land the neutral contracts and local filesystem store.
-2. Add one model-specific producer/restorer integration with parity evidence.
-3. Connect eligible DLO or other transport paths without moving transport
-   ownership into the runtime.
-4. Add additional final-layout and quantized producers independently.
-5. Introduce remote materialization only through the same local lease contract.
-
-The architectural decisions and deferred work are tracked in
-[RFC #6414](https://github.com/vllm-project/vllm-omni/issues/6414).
@@ -10,31 +10,6 @@ For user-facing commands, see the
 [distributed layerwise offloading guide](../../../user_guide/diffusion/offloader/distributed_layerwise_offload.md)
 and the [Cosmos3 recipe](https://github.com/vllm-project/vllm-omni/blob/main/recipes/cosmos3/Cosmos3-DistOffload.md).

-## Feature compatibility
-
-Host-storage optimization and runtime compatibility are separate decisions.
-When direct checkpoint mmap is unavailable, DLO can still use tensors produced
-by the ordinary loader. "Compatibility path" below means that fallback is
-implemented but has less end-to-end coverage than the primary path.
-
-Legend: ✅ supported, ⚠️ compatibility path or limited validation, ❌ unsupported.
-
-| Feature | DLO + AllGather | DLO without AllGather |
-| --- | --- | --- |
-| **DP** | ✅ Primary path; host weights are sharded across the DP group. | ✅ Each DP rank streams complete rank-local blocks. |
-| **SP** | ✅ When DP=1, DLO uses the SP group for weight sharding. | ✅ SP remains active without a DLO weight collective. |
-| **TP > 1** | ⚠️ Ordinary TP-aware loader only; no direct checkpoint mmap. | ⚠️ Ordinary TP-aware loader only; no direct checkpoint mmap. |
-| **HSDP** | ❌ Rejected to avoid double-sharding parameters. | ⚠️ Limited end-to-end coverage. |
-| **Per-tensor online FP8 linears** | ✅ Ordinary loader finalizes weights and scales before DLO sharding. | ✅ Ordinary loader retains complete rank-local tensors. |
-| **Other online quantization methods** | ❌ Rejected until runtime packing and scale layouts are validated. | ⚠️ Allowed through the ordinary loader; validation is method-specific. |
-| **Model-level or standard layerwise CPU offload** | ❌ Disabled because DLO takes priority. | ❌ Disabled because DLO takes priority. |
-| **Resident leading layers** | ❌ Rejected. | ✅ Requires eligible resident paths in the model's `OffloadPlan`. |
-| **Auxiliary component policy** | ✅ Encoders/VAEs may remain resident. | ✅ Encoders/VAEs may remain resident. |
-
-See [Parallelism compatibility](#parallelism-compatibility) and
-[Request and loading constraints](#request-and-loading-constraints) for the
-detailed contracts and validation boundaries.
-
 ## Status

 DLO is implemented for multi-device diffusion execution. The default
@@ -44,15 +19,17 @@ DLO weight collective.

 Host storage is selected separately from the transfer protocol. The loader can
 produce a direct-checkpoint mmap plan for a proven-compatible runtime layout;
-otherwise it uses the ordinary loader. Consequently, no-AllGather replicas on
-the same node can share immutable checkpoint pages when direct mmap is
-selected, while the ordinary-loader fallback still keeps a private runtime
-copy per process.
+otherwise it uses the ordinary loader. In no-AllGather mode, an opt-in Phase B
+runtime cache can normalize those final ordinary-loader DiT tensors into an
+immutable node-local mmap entry. Consequently, replicas can share either
+proven-compatible checkpoint pages or equivalent final runtime layouts. An
+opt-in CUDA registration budget can make the complete final mapping directly
+H2D-copyable, avoiding the recurrent host packing otherwise required by mmap.

 The Phase A shared-mmap support boundary is TP1. TP greater than one is an
 ordinary-loader compatibility path: DLO can consume the resulting TP-local
-tensors, but those configurations do not use checkpoint mmap and must not be
-used to claim shared-mmap host-memory savings.
+tensors. Direct checkpoint mmap still does not cover TP, but the Phase B cache
+can share each final TP coordinate among equivalent processes.

 The compatibility matrix below describes the current implementation. The
 unit-level guards are covered, but not every parallelism combination has a
@@ -106,6 +83,90 @@ flags such as `_supports_mmap_loading` or parameter attributes for mmap-only
 transforms. Model-specific direct-layout knowledge, when required, lives in a
 checkpoint adapter beside the ordinary loader.

+### Post-load runtime cache
+
+The Phase B cache preserves the same ownership boundary. DLO neither derives
+cache keys nor interprets model loaders. When enabled with no-AllGather, every
+rank first completes the ordinary loader, custom callbacks, post-load
+processing, strict validation, and calibration. The loader then:
+
+1. discovers final CPU DiT parameters and persistent buffers;
+2. rejects unsupported non-contiguous, aliased, quantized, distributed, or
+   ambiguous layouts before changing the model;
+3. hashes tensor names, metadata, and final bytes;
+4. builds or joins one content-addressed entry under a strict POSIX lock; and
+5. returns a `HostWeightPlan(backing_kind="runtime_cache")` only after file,
+   manifest, and remapped-tensor content validation succeeds.
+
+The identity excludes DP size/rank and SP rank. It includes TP world size/rank
+and conservative SP implementation/world-size guards. DP replicas and
+equivalent SP ranks can therefore share; different TP coordinates cannot.
+Final tensor content is authoritative, so an unmodeled loader/config change
+that changes bytes creates a different entry instead of risking silent
+sharing.
+
+Publication writes sharded safetensors and a JSON manifest into a same-
+filesystem temporary directory, flushes them, and atomically renames the
+directory. The manifest includes per-file SHA-256 digests and the final tensor
+content digest. Kernel `flock` ownership distinguishes a live writer from a
+stale lock file: process death releases the lock automatically. Stale temporary
+entries are removed only by the next lock owner. A bounded wait or any cache
+error retains the already-valid ordinary tensors.
+
+DLO maps this plan without moving the DiT to `meta` and without rerunning any
+post-load hook. It changes tensor storage while preserving `Parameter` objects,
+then runs the existing `gc.collect()`/`malloc_trim()` cleanup before installing
+streaming hooks. The source mappings remain open through DLO disable. With the
+default zero registration budget they feed the existing bounded two-slot host
+staging path. Every streamed block is first packed from pageable mmap storage
+into one of those pinned slots and is then copied to the device. This removes
+model-sized private pinned storage, but adds a recurrent host-to-host copy and
+can amplify TP synchronization waits when several ranks compete for host
+bandwidth.
+
+This version is deliberately opt-in and steady-state-oriented. It requires
+roughly one local-disk model copy per runtime identity, has no eviction, and
+still performs ordinary loading plus full content-hash passes in every rank.
+Skip-load-on-hit is a separate follow-up after loader side effects can be
+modeled safely.
+
+### Registered runtime-cache transfer
+
+`dlo_runtime_cache_pin_limit_gib > 0` opts a CUDA worker into complete
+runtime-cache registration. It also changes loader selection: no-AllGather
+uses the ordinary loader and final runtime cache even when a TP1 direct-
+checkpoint plan is available. A checkpoint binding can carry a deferred
+adapter such as grouped-QKV reordering. Registering that raw source would not
+remove the adapter's recurrent CPU allocation/copy, whereas the runtime cache
+contains the transform-complete final tensors.
+
+After mapping and validating every final tensor, DLO groups source storages by
+backing file, page-aligns their address ranges, and coalesces overlapping or
+adjacent ranges within that mapping. The complete byte count is checked
+against the per-worker budget before any CUDA call. It then registers every
+range with the read-only CUDA host-registration flag and verifies that PyTorch
+recognizes every mapped tensor as pinned. Failure rolls back any ranges already
+registered and preserves the existing two-slot staging path. Partial direct
+transfer is deliberately unsupported. A rollback failure aborts worker
+initialization so a still-registered range is retained until process/context
+teardown rather than being unsafely unmapped.
+
+On success, the hooks copy each immutable tensor view directly into its offset
+in the existing flattened rotating device buffer on the copy stream. Parameter
+repointing, two-block HBM residency, and H2D/compute overlap are unchanged. The
+implementation currently issues more H2D copy operations than block packing,
+but avoids the much larger recurrent CPU copy. A packed cache schema should be
+considered only if launch-count measurements justify its added format and
+publication complexity.
+
+Registration is per process and CUDA context; physical file-cache pages remain
+shared and are not copied into one private host allocation per worker. The
+operator must nevertheless budget page-locked memory and satisfy OS/CUDA
+registration limits for every worker. During shutdown, DLO first synchronizes
+outstanding device work, unregisters all ranges, and then closes the safetensors
+mappings. Worker teardown invokes this cleanup before destroying the
+distributed environment and CUDA context.
+
 ### AllGather path

 With the default `dlo_use_allgather=True`, each rank stores approximately
@@ -139,11 +200,17 @@ When DP is greater than one, the engine can process one request per DP rank in
 the same denoising wave. Because AllGather is a collective, all participating
 requests must take the same execution path at every denoising step.

+Fast NVLink/NVSwitch changes collective cost, not this execution contract. For
+independently scheduled replicas—even on one NVSwitch baseboard—no-AllGather
+plus shared mmap storage avoids coupling their request schedules and failure
+domains.
+
 ### Rank-local path without DLO AllGather

 With `--dlo-no-use-allgather`, DLO forces its internal offload shard size to
 one and streams complete blocks using H2D copies only. The host backing may be
-either a loader-approved checkpoint mapping or ordinary runtime tensors.
+a loader-approved checkpoint mapping, a normalized runtime-cache mapping, or
+ordinary runtime tensors.

 For direct mmap, each process retains immutable safetensors views and uses two
 bounded pinned host staging slots. Processes on the same node that map the same
@@ -152,10 +219,14 @@ the persistent private full-model copy per pure-DP process, but each process
 still packs and transfers every complete block. Sharing is node-local; each
 node has its own page cache.

+For a runtime-cache mapping, a positive registration budget replaces those
+host slots with direct copies from the shared final tensor views. A zero budget
+or failed registration retains the bounded staging behavior.
+
 When direct mmap preflight fails, the regular model loader remains responsible
 for preparing each rank's weights, including TP-local tensors or HSDP-managed
-parameters. In that fallback, each pure-DP process keeps a private full runtime
-copy.
+parameters. Supported CPU layouts may then enter the opt-in runtime cache.
+Unsupported layouts keep one private runtime copy per process.

 This mode means:

@@ -166,243 +237,17 @@ This mode means:
 - TP/HSDP/SP collectives, if configured, are not disabled by this flag; only
  DLO's additional weight AllGather is disabled.
 - Pure DP deployments share one checkpoint-backed copy per node when direct
-  mmap is selected; the ordinary-loader fallback keeps one private runtime
-  copy per rank.
+  mmap is selected. The runtime cache can share equivalent ordinary-loader
+  outputs; its fallback keeps one private runtime copy per rank.
 - The scheduler does not require a synchronized DP request wave for DLO.

-### Component allocator-cache retention
-
-MiniMax-H3 DLO keeps one bounded PyTorch allocator cache across its staged
-encoder, DiT, and VAE component boundaries so allocations released by one
-component can be reused by the next. The DiT prefetch path and its two shared
-device buffers are unchanged.
-
-After a component is offloaded, cached-but-unallocated memory is retained only
-while it is at most 25% of device capacity and at least 5% of device capacity
-remains physically free. Crossing either bound releases the allocator cache.
-Missing allocator telemetry also releases it conservatively. Component or
-staging failure forces a release, and an out-of-memory allocation gets one
-retry after release. This is a component-local policy rather than a global
-`empty_cache` override, so the executor's unconditional shutdown cleanup is
-preserved.
-
-Retaining allocator blocks trades higher reserved and peak device memory for
-lower lifecycle latency. The benefit is device- and workload-dependent, and a
-smaller or externally loaded device may cross a bound and return to the
-ordinary per-component cache-release behavior. Current performance validation
-covers MiniMax-H3 no-AllGather DLO on CUDA. Other MiniMax-H3 DLO transfer
-topologies and platforms receive the same bounded policy but are not claimed
-performance targets; other DLO models remain unchanged unless they explicitly
-adopt it.
-
-### Final-layout Host Weight Runtime consumer
-
-> **Status:** PR2 landed in
-> [PR #6486](https://github.com/vllm-project/vllm-omni/pull/6486). PR3 adds
-> registered direct H2D plus generic HWR publication/source-digest
-> optimizations without changing AllGather behavior.
-
-Final-layout Host Weight Runtime (HWR) backing is opt-in and currently applies
-only to no-AllGather DLO. Enable it with
-`--host-weight-runtime-mode preferred` (or `required`) and
-`--host-weight-runtime-root <node-local-root>`.
-
-The modes express operator fallback policy, not different artifact formats:
-
- `preferred` consumes an exact hit, but on a miss it allows canonical loading
-  followed by post-load publication. It is the normal population path.
- `required` consumes the same exact artifact but fails startup on a miss or
-  unusable artifact. It never invokes canonical DiT fallback or post-load
-  publication and therefore cannot populate an empty store.
-
-PR2 has no separate prewarm command. Operators populate one matching producer
-cohort per node-local storage domain in `preferred` mode, then restart the same
-model revision and parallel layout with `required`. TP coordinates have distinct
-identities, while equivalent DP replicas share them.
-
-The current producer/consumer boundary is the model-declared final-layout BF16
-contract (MiniMax H3 today). It supports ordinary-loader final layouts for TP1
-and TP2 rank identities plus SP layout identities; online quantization, HSDP,
-LoRA/adapted weights, and non-default load formats remain ineligible. HWR mode
-`disabled`, DLO-disabled, and DLO AllGather configurations stop before source
-identity or store construction and retain the existing checkpoint-mmap or
-ordinary-loader path.
-
-Eligibility is decided before constructing HWR, resolving canonical sources,
-hashing identity inputs, probing a filesystem, or emitting an HWR observer
-event:
-
-```text
-DLO disabled / HWR disabled / DLO AllGather
-  -> zero final-layout HWR interaction
-  -> preserve current checkpoint-mmap or ordinary-loader behavior
-```
-
-When final-layout HWR is explicitly enabled for no-AllGather DLO, runtime
-outcomes are authoritative:
-
- `LOCAL_HIT`: plan and commit an exact restoration, then transfer the lease
-  transactionally to DLO.
- `CANONICAL_FALLBACK`: bypass checkpoint mmap, canonically materialize and
-  finalize the DiT, then call `publish_after_load()` for a future startup. The
-  current startup retains its canonical tensors.
- `FAILED`: fail startup. Preferred mode does not reinterpret nonretryable
-  identity, configuration, or compatibility failures as misses.
- Required mode cannot bootstrap an empty store through a `POST_LOAD_ONLY`
-  producer.
-
-Checkpoint mmap remains an unchanged control path whenever final-layout HWR is
-not selected.
-
-Local source identity and publication avoid repeated full-payload passes while
-preserving the same semantic contract:
-
- Canonical files without a trusted immutable Hub blob identity are hashed in
-  parallel. Their content IDs are cached per storage domain under the HWR root
-  and reused only when the path, inode, size, timestamps, symlink target, and
-  cache-record checksum still match. Corrupt entries are rebuilt; cache-lock or
-  cache-I/O failure falls back to hashing the canonical file directly.
- Producers that emit payload bytes in canonical storage-key order may declare
-  `ordered=True`. The filesystem writer then computes file and tensor SHA256
-  values during the write and overlaps payload `fsync` with later producer
-  work. Producers without that guarantee retain unordered writes and use a
-  parallel readback checksum fallback.
- Manifest and `READY` publication still wait for every payload `fsync` and
-  checksum to complete. These optimizations do not weaken artifact validation
-  or change lease ownership.
-
-#### Registered mmap transport
-
-After DLO takes an HWR lease, the no-AllGather backend may register the lease's
-complete immutable mapped ranges under the existing `pin_cpu_memory` policy.
-Registration is transport state: it does not change artifact identity, the
-store, tensor ownership, or H2D payload. On success, each tensor view copies
-directly into the existing rotating HBM block buffers and the two private host
-staging slots are not allocated.
-
-`--dlo-host-registration-limit-gib` is an optional per-worker preflight ceiling
-over page-aligned registered bytes. Zero adds no ceiling. A disabled pinned
-memory policy, unsupported platform/capability, over-budget mapping, or fully
-rolled-back registration error selects the existing two-slot staging path. A
-partial registration that cannot be rolled back aborts startup because closing
-the lease would unmap memory still owned by the platform.
-
-Direct checkpoint mmap remains unchanged and continues to use staging. It may
-require loader-owned per-block transforms, while the HWR artifact already
-contains final runtime bytes. DLO AllGather never receives an HWR final-layout
-lease and therefore never enters this registration path.
-
-#### Pre-service transaction boundary
-
-The startup transaction does not end at restore commit. A lease-backed model is
-disposable until backend setup and initial prefetch complete:
-
-```text
-UNRESOLVED
-  -> LEASE_OWNED_BY_LOADER
-  -> RESTORE_PLANNED
-  -> COMMIT_STARTED
-  -> CARRIER_OWNED
-  -> BACKEND_OWNED
-  -> BACKEND_READY
-  -> IN_SERVICE
-```
-
-Failure before `COMMIT_STARTED` closes the loader-owned lease. Preferred mode
-may canonically load using the untouched skeleton; required mode fails.
-
-Failure from `COMMIT_STARTED` through `BACKEND_READY` must:
-
-1. synchronize or otherwise quiesce partial backend and initial-prefetch work;
-2. release hook, staging, restore-plan, and model references;
-3. close the lease through its current owner;
-4. discard the restored model; and
-5. in preferred mode, construct a fresh canonical model while bypassing HWR
-   lookup, HWR publication, and checkpoint mmap for that recovery attempt.
-
-Required mode fails instead of constructing the fresh fallback. Once the model
-enters service, failures follow normal runtime handling rather than startup
-fallback.
-
-#### Finalization phases
-
-Cold canonical loading separates byte-changing work from shared runtime-state
-finalization:
-
-```text
-Cold-only byte-changing:
-  casting, reordering, packing, quantization, generated scales,
-  model-specific weight transforms, and calibration that mutates
-  parameters or persistent buffers
-
-Shared cold/warm non-byte:
-  validation, hook installation, eval state, bookkeeping,
-  and non-persistent runtime state
-```
-
-The warm path must snapshot restored tensor bytes and backing pointers before
-shared finalization and prove both are unchanged afterward.
-
-#### Lease ownership
-
-Lease transfer is single-owner and single-take:
-
-```text
-loader owns
-  -> restore plan borrows
-  -> commit succeeds
-  -> runner carrier takes once
-  -> backend takes once before asynchronous work
-  -> backend drains pending H2D work
-  -> backend releases hooks, staging, and model references
-  -> backend unregisters every mapped range
-  -> backend closes lease
-```
-
-The runner carrier is process-local, rejects serialization, and rejects a
-duplicate `take()`. If the carrier still owns the lease, runner cleanup closes
-it. Once the backend takes ownership, only backend abort or teardown may drain
-work and close it.
-
-The implementation keeps the final-layout lease through backend setup and
-initial prefetch. Successful registration copies directly from immutable HWR
-views; otherwise the backend uses the existing two bounded rank-local staging
-slots. Transactional cleanup drains device work, removes source references,
-unregisters mappings, and only then closes the lease. An unregistration failure
-retains both registration and lease for retry/process teardown. Preferred mode
-then uses the runner's fresh canonical retry; required mode propagates the
-failure.
-
-#### PR2 and PR3 promotion gates
-
- Warm hit performs zero ordinary DiT materialization and zero producer calls.
- Shared warm finalization changes neither restored bytes nor backing pointers.
- Preferred `FAILED` outcomes do not silently fall back.
- Planning failure leaves the skeleton untouched.
- Any pre-service failure after commit begins discards the restored model;
-  preferred mode uses a fresh canonical model and required mode fails.
- Mixed components load normally and no required tensor remains on `meta`.
- Disabled mode and AllGather emit zero final-layout HWR interaction.
- The lease carrier rejects duplicate take and serialization.
- Backend setup or prefetch failure drains asynchronous work before lease close.
- Registration is all-or-nothing; rollback/unregistration failure never closes
-  a mapping still owned by the platform.
- Registered HWR transport bypasses host staging while preserving output and
-  H2D payload; unsupported registration retains the bounded staging path.
- Compatible checkpoint mmap remains an unchanged benchmark and control path.
- Prewarm uses one matching producer cohort per TP/SP topology and storage
-  domain.
- Benchmarks compare ordinary loading, cold publication, and warm staging with
-  output parity, startup latency, aggregate PSS, page-cache state, HBM, and H2D
-  payload.
-
 ## Parallelism compatibility

 | Parallelism | DLO + AllGather | DLO without AllGather |
-| --- | --- | --- |
-| **DP** | Supported primary path. DLO shards host weights across the DP group and can run DP multi-concurrency. | Supported rank-local path. Compatible TP1 replicas can share checkpoint pages on each node; fallback runtime tensors remain private. |
-| **SP** | Supported in the implementation. With DP=1, DLO uses the SP group for host-weight sharding; SP still shards sequence/activation work. | SP remains active, but DLO keeps standard-loader rank-local weights and adds no SP weight collective. |
-| **TP > 1** | Outside the Phase A shared-mmap support scope. The loader falls back before mutation, preserves TP-local layouts, and DLO may apply DP/SP host sharding to those ordinary runtime tensors. | Outside the Phase A shared-mmap support scope. The ordinary TP-aware loader produces rank-local tensors, which DLO streams without an additional weight collective; DP replicas retain private runtime storage. |
+|---|---|---|
+| **DP** | Supported primary path. DLO shards host weights across the DP group and can run DP multi-concurrency. | Supported rank-local path. Compatible TP1 replicas can share checkpoint pages; the optional runtime cache shares equivalent final layouts while excluding DP rank from its identity. CUDA workers may register the complete final mapping for direct H2D. |
+| **SP** | Supported in the implementation. With DP=1, DLO uses the SP group for host-weight sharding; SP still shards sequence/activation work. | SP remains active without a DLO weight collective. Runtime-cache v1 excludes SP rank and includes conservative SP implementation/world-size guards. Registered transfer does not remove ordinary SP activation/attention collectives. |
+| **TP > 1** | Outside the Phase A direct-mmap scope. The loader preserves TP-local layouts and DLO may apply DP/SP host sharding to ordinary runtime tensors. | The ordinary TP-aware loader produces rank-local tensors. Runtime-cache v1 creates one entry per TP coordinate, shareable by equivalent DP/SP processes. Registering those final mappings removes staging-driven TP skew but does not remove ordinary TP collectives. |
 | **HSDP** | Rejected. HSDP has already sharded parameters, so DLO AllGather would double-shard them. | Accepted by configuration. HSDP owns parameter sharding and its own gathers; DLO only stages rank-local parameters. End-to-end coverage is limited. |

 ### Combined dimensions
@@ -412,30 +257,13 @@ failure.
  the SP group becomes DLO's sharding group in AllGather mode.
 - **DP + TP/SP without AllGather:** standard model loading defines the
  rank-local tensor layout. DLO adds no cross-DP, cross-TP, or cross-SP weight
-  collective. When the model declares the final-layout contract, HWR keys the
-  reusable artifact by TP rank/size and SP layout.
+  collective.
 - **HSDP + SP:** the general parallel configuration permits HSDP over SP, but
  DLO must use `--dlo-no-use-allgather`. HSDP remains responsible for weight
  materialization and synchronization.
 - **HSDP + DP or TP:** rejected independently by the diffusion parallel
  configuration.

-### Auxiliary component policy
-
-`dlo_offload_components` maps discovered encoder/VAE paths to booleans. A
-component set to `False` is materialized on the target device once and is not
-entered through the model's manual offload lifecycle. A `True` value permits
-the existing `OffloadPlan.on_demand_component_paths` and encoder block-hook
-behavior; it does not add support where the model declares none. The optional
-`default` key handles unmatched auxiliary components, and an empty map
-preserves the current policy.
-
-The policy is resolved after component discovery and before DLO mutates DiT
-storage. Unknown names, including DiT paths, are rejected. DLO continues to
-own DiT streaming regardless of this map, which avoids an invalid state where
-the loader has skipped ordinary DiT materialization but the backend is asked
-to keep that DiT resident.
-
 ## Request and loading constraints

 AllGather DP multi-concurrency requires:
@@ -447,29 +275,13 @@ AllGather DP multi-concurrency requires:
 The no-AllGather path does not impose these DLO-specific synchronized-wave
 requirements.

-MiniMax-H3 currently builds one global encoder TP group and broadcasts the
-resulting conditioning from global rank 0. Therefore an encoder TP group that
-spans multiple DP replicas is not valid for independent-prompt AllGather
-waves. Exact-recipe DP2/TP2 and DP2/SP2 experiments with encoder TP4 completed
-the collective schedule, but two distinct prompts with the same seed produced
-byte-identical video and audio in every measured wave. Enabling or disabling
-encoder offload produced paired-identical results, so this is a pre-existing
-model topology limitation rather than component-policy behavior.
-
 Direct checkpoint mmap can back either transfer path. It is currently limited
 to proven TP1, non-HSDP, non-online-quantized layouts. Other layouts use the
-ordinary loader. Per-tensor online FP8 linears can use DLO AllGather after the
-ordinary loader finalizes their runtime weights and scales; DLO then shards and
-reconstructs those tensors with their recorded layouts. Other online methods
-must use `--dlo-no-use-allgather` or disable online quantization until their
-runtime layouts are validated.
-
-The Host Weight Runtime representation, publication, and no-AllGather consumer
-contracts are merged; see
-[RFC #6414](https://github.com/vllm-project/vllm-omni/issues/6414),
-[PR #6445](https://github.com/vllm-project/vllm-omni/pull/6445), and
-[PR #6486](https://github.com/vllm-project/vllm-omni/pull/6486). Registered
-direct H2D is an optional transport layer over that merged lease contract.
+ordinary loader. Online quantization remains incompatible with DLO AllGather;
+use `--dlo-no-use-allgather` or disable online quantization. Runtime-cache v1
+is no-AllGather only and rejects all quantization configurations, HSDP/DTensor,
+expert parallelism, CFG parallelism, PP, non-contiguous tensors, and
+tied/shared storage.

 ## Validation coverage

@@ -479,19 +291,18 @@ Current source-level validation includes:
 - HSDP + DLO without AllGather acceptance at configuration level;
 - loader preflight fallback for TP, HSDP, online quantization, unknown custom
  loaders, missing keys, and shape/dtype mismatches;
- ordinary-loader fallback for per-tensor online FP8 linears followed by DLO
-  sharding of finalized weights and scales;
 - exact loader-to-backend plan transfer and ordinary-loader fallback;
- ordered publication hashing, overlapped durability, unordered parallel
-  checksum fallback, and node-local source-digest reuse/invalidation;
 - rank-local mmap source retention, bounded two-slot staging, and adapter
  transforms without parameter-side flags;
- read-only registration preflight, direct source-to-device copies, safe
-  fallback, partial rollback, retryable unregistration, and lease ordering;
+- runtime-cache content identity, sharded atomic publication, concurrent
+  writer election, corruption rebuild, lock timeout, and fail-closed layout
+  rejection;
+- loader ordering through final post-load mutation and DLO remapping without
+  rerunning post-load hooks;
+- all-or-nothing page-aligned registration, budget rejection, partial-failure
+  rollback, direct-copy staging bypass, and explicit shutdown cleanup;
 - resident-layer requests requiring no-AllGather;
 - DP request-wave validation for denoising-step compatibility;
- bounded component allocator-cache retention, conservative/forced release,
-  OOM retry, and immutable encoder non-block staging;
 - sharding, double-buffer, AllGather-size, and heterogeneous-block regression
  tests.

@@ -504,7 +315,7 @@ VAEs at TP1. They validate the ordinary-loader fallback only, not direct mmap
 or shared-mmap host-memory savings.

 | Configuration | Result | Warm E2E | Peak device memory | Host PSS |
-| --- | ---: | ---: | ---: | ---: |
+|---|---:|---:|---:|---:|
 | DP4xTP1 AllGather | Passed, 4 concurrent requests | 2.87 s / 4 requests | 13.84 GiB | 211.99 GiB |
 | DP4xTP1 no-AllGather | Passed, 1 request | 15.02 s | 13.23 GiB | 187.77 GiB |
 | DP2xTP2 AllGather | Passed, 2 concurrent requests | 4.16 s / 2 requests | 12.50 GiB | 211.97 GiB |
@@ -520,9 +331,6 @@ AllGather, because DP replicas did not share checkpoint-backed runtime
 weights. This is a functional and memory smoke test, not a production-quality
 performance or output-quality benchmark.

-These B300 DP waves intentionally reused the same prompt and seed, so they do
-not establish independent-prompt isolation across DP replicas.
-
 ### Host-memory measurement

 A two-worker MiniMax-H3 FL2VA measurement on one L20X node compared the
@@ -539,7 +347,7 @@ pipeline components, so each worker should be compared with the same worker in
 the other storage mode.

 | Worker | Ordinary RSS | mmap RSS | Ordinary PSS | mmap PSS | PSS reduction |
-| --- | ---: | ---: | ---: | ---: | ---: |
+|---|---:|---:|---:|---:|---:|
 | DP worker 0 | 168.27 GiB | 132.76 GiB | 167.84 GiB | 101.43 GiB | 66.40 GiB |
 | DP worker 1 | 116.19 GiB | 79.97 GiB | 115.73 GiB | 48.64 GiB | 67.09 GiB |
 | **Two-worker total** | — | — | **283.56 GiB** | **150.08 GiB** | **133.48 GiB (47.1%)** |
@@ -552,11 +360,99 @@ from 167.53 to 70.24 GiB for worker 0 and from 115.40 to 17.44 GiB for worker
 because it counts a shared physical page in every process that maps it; summed
 PSS is the appropriate node-memory comparison.

-The highest-value missing coverage is broader end-to-end numerical and
-lifecycle comparison against ordinary layerwise offload for DP+SP,
-HSDP+SP+no-AllGather, and TP greater than one across additional models and
-target CUDA/NCCL or CANN/HCCL hardware. That broader TP coverage does not
-change the Phase A direct-mmap TP1 support boundary.
+### L20X runtime-cache smoke matrix
+
+Phase B was also exercised on four L20X GPUs in one NVLink domain with
+MiniMax-H3 FL2VA, CUDNN attention, eager execution, 256x256 four-second
+outputs, two denoising steps, `dlo_resident_layers=0`, text-encoder TP1, and
+VAE TP1. This is a functional, memory, and profiler smoke test rather than a
+production-quality performance benchmark. Host values below are node-wide
+maxima during request waves from descendant-process `smaps_rollup`; they do
+not represent the private startup peak. HBM is the engine-reported request
+peak because sampled `nvidia-smi` data can miss short-lived allocations.
+
+One internal DP2xTP2 engine compared the three host-storage/transfer choices.
+Each measured wave contained two requests. NVLink TX is the physical per-link
+counter delta summed across the four GPUs; RX had the same value and is not
+added again here.
+
+| Mode | Two-request wave | Throughput | Host PSS | `Private_Dirty` | Engine peak HBM | NVLink TX / wave |
+|---|---:|---:|---:|---:|---:|---:|
+| AllGather, ordinary loader | 3.41 s | 0.587 req/s | 210.70 GiB | 209.72 GiB | 12,498 MB | 73.37 GiB |
+| no-AllGather, private loader weights | 6.96 s | 0.287 req/s | 312.56 GiB | 311.56 GiB | 11,882 MB | 19.78 GiB |
+| no-AllGather, runtime cache (cold publish) | 18.94 s | 0.106 req/s | 178.71 GiB | 116.00 GiB | 11,882 MB | 19.78 GiB |
+| no-AllGather, runtime cache (warm reuse) | 24.23 s | 0.083 req/s | 178.29 GiB | 115.58 GiB | 11,882 MB | 19.78 GiB |
+
+The no-AllGather cache preserved the no-AllGather NVLink traffic and HBM
+footprint while reducing node PSS by about 134 GiB relative to private loader
+weights. Cold and warm labels describe cache publication or reuse during
+initialization; both request phases ran after initialization. A warm hit still
+performed ordinary loading and full content hashing, so it was not a startup
+fast path. All measured no-AllGather private/cache outputs were byte-identical
+for matching seeds.
+
+The deployment shape targeted by the cache was tested separately as two
+independent DP1xTP2 engines on the same node. Both engines mapped the same two
+TP-coordinate entries, including the same file device/inode tuples; the cache
+occupied 66,281,995,903 bytes. A start barrier kept all four measured requests
+ahead of profiling.
+
+| Storage | Mean request latency, engines A / B | Combined throughput | Host PSS | `Private_Dirty` | Engine peak HBM |
+|---|---:|---:|---:|---:|---:|
+| Private loader weights | 3.50 / 3.60 s | 0.463 req/s | 366.20 GiB | 365.22 GiB | 11,882 MB |
+| Shared runtime cache | 8.96 / 12.30 s | 0.142 req/s | 232.23 GiB | 169.52 GiB | 11,882 MB |
+
+The shared cache reduced request-time PSS by 133.97 GiB (36.6%) and
+`Private_Dirty` by 195.70 GiB (53.6%), but reduced combined throughput by
+69.3% in this host-contention smoke. Across one profiled request per engine,
+aggregate GPU compute was unchanged (1.359 versus 1.357 seconds) and H2D
+payload was exactly 264.24 GiB in both modes. Aggregate CPU `aten::copy_` time
+rose from 3.75 to 32.49 seconds, while communication-kernel time rose from
+3.56 to 5.80 seconds as TP ranks waited on skewed staging. These durations are
+summed across ranks and can overlap; they identify the mechanism, not wall
+time. Matching private/cache outputs were byte-identical.
+
+The result confirms that zero-budget runtime-cache staging is a host-capacity
+option, not a latency-neutral replacement for private pinned weights. Broader
+SP, model, platform, and production-quality validation remains tracked in
+[issue #6231](https://github.com/vllm-project/vllm-omni/issues/6231). The
+historical B300 rows above predate the runtime cache and must not be treated as
+Phase B memory validation.
+
+### L20X registered-runtime-cache smoke
+
+The read-only registered path was then tested with the same MiniMax-H3
+workload. These are functional and mechanism-validation measurements, not a
+production benchmark. The TP1 pair used one request per wave. Both modes moved
+exactly 121.86 GiB H2D in the profiled request and produced byte-identical video
+and audio for both measured seeds.
+
+| TP1 no-AllGather mode | Mean wave | Throughput | Request-time host PSS | `Private_Dirty` | Engine peak HBM | CPU `aten::copy_` | GPU compute |
+|---|---:|---:|---:|---:|---:|---:|---:|
+| Checkpoint mmap + bounded staging | 33.87 s | 0.0295 req/s | 133.65 GiB | 71.16 GiB | 13,226 MB | 21.91 s | 419.28 ms |
+| Final runtime cache + registered direct H2D | 4.88 s | 0.2055 req/s | 129.41 GiB | 66.93 GiB | 13,226 MB | 1.64 s | 419.05 ms |
+
+Registration covered 61.73 GiB in 13 page-aligned ranges. Mean wave latency
+fell by 85.6% and throughput increased 6.94x. GPU compute and H2D payload were
+unchanged, identifying recurrent host transform/packing as the removed work.
+The direct path issued 2,425 H2D events versus 1,945 for packed staging, but
+that launch increase was much smaller than the eliminated CPU cost.
+
+Two independent TP2 engines also registered the same two TP-coordinate cache
+entries across four workers. Compared with the zero-budget cache, mean wave
+latency improved from 9.21/12.55 seconds to 3.80/3.86 seconds for engines A/B;
+the private-loader reference was 3.61/3.72 seconds. Registered request-time
+host PSS was 224.26 GiB versus 232.23 GiB staged and 366.20 GiB private.
+Aggregate CPU `aten::copy_` time was 3.83 seconds registered, 32.49 seconds
+staged, and 3.75 seconds private; aggregate GPU compute and the 264.24 GiB H2D
+payload were effectively unchanged. Ordinary TP communication remained, but
+the extra wait caused by staging-driven rank skew largely disappeared.
+
+All workers explicitly unregistered before releasing their mappings, the
+system's acquired-minus-released pin counter returned to its pre-run value,
+and every GPU allocation was released. Cold runtime-cache publication remained
+expensive because it still performs ordinary loading and multiple full-content
+passes; that startup problem is outside the registered transfer scope.

 ## Recommendations

@@ -565,8 +461,12 @@ change the Phase A direct-mmap TP1 support boundary.
 - Use **SP + DLO AllGather** for long-sequence workloads when DP concurrency is
  not the goal.
 - Use **no-AllGather** when independent replica execution is required. TP1
-  direct-mmap deployments can share checkpoint pages per node; other layouts
-  retain the ordinary loader's private host memory behavior and are outside
-  the Phase A shared-mmap support scope.
+  direct-mmap deployments can share checkpoint pages per node. Enable the
+  runtime cache only when independent replicas have repeated final layouts and
+  benchmark the target CPU/memory topology, especially for matching
+  coordinates across multiple TP engines. On CUDA, provide an explicit
+  registration budget large enough for the complete final layout when
+  recurrent staging cost is unacceptable; leave it at zero when page-locking
+  that layout is not operationally acceptable.
 - Prefer **HSDP alone** for production HSDP deployments until the combined
  HSDP + DLO no-AllGather path has broader end-to-end coverage.
@@ -32,25 +32,26 @@ mooncake_master \

 ## Configuration

-Define the connector at the top level of the deploy YAML:
+Define the connector in runtime:

 ```yaml
-connectors:
-  connector_of_mooncake:
-    name: MooncakeStoreConnector
-    extra:
-      host: "127.0.0.1"
-      metadata_server: "http://<MASTER_IP>:8080/metadata"
-      master: "<MASTER_IP>:50051"
-      segment: 512000000
-      localbuf: 64000000
-      proto: "tcp"
+runtime:
+  connectors:
+    connector_of_mooncake:
+      name: MooncakeStoreConnector
+      extra:
+        host: "127.0.0.1"
+        metadata_server: "http://<MASTER_IP>:8080/metadata"
+        master: "<MASTER_IP>:50051"
+        segment: 512000000
+        localbuf: 64000000
+        proto: "tcp"
 ```

 Wire stages to the connector:

 ```yaml
-stages:
+stage_args:
  - stage_id: 0
    output_connectors:
      to_stage_1: connector_of_mooncake
@@ -21,25 +21,26 @@ InfiniBand/RoCE NICs).

 ## Configuration

-Define the connector at the top level of the deploy YAML:
+Define the connector in runtime:

 ```yaml
-connectors:
-  rdma_connector:
-    name: MooncakeTransferEngineConnector
-    extra:
-      host: "auto"                  # Auto-detect local RDMA IP
-      zmq_port: 50051               # ZMQ base port (see "Port Offset Scheme" below)
-      protocol: "rdma"              # "rdma" or "tcp"
-      device_name: ""               # RDMA device (e.g., "mlx5_0"), empty for auto-detect
-      memory_pool_size: 4294967296  # 4 GB (CPU); use 2147483648 (2 GB) for GPU
-      memory_pool_device: "cpu"     # "cpu" for pinned memory (recommended), "cuda" for GPUDirect RDMA
+runtime:
+  connectors:
+    rdma_connector:
+      name: MooncakeTransferEngineConnector
+      extra:
+        host: "auto"                  # Auto-detect local RDMA IP
+        zmq_port: 50051               # ZMQ base port (see "Port Offset Scheme" below)
+        protocol: "rdma"              # "rdma" or "tcp"
+        device_name: ""               # RDMA device (e.g., "mlx5_0"), empty for auto-detect
+        memory_pool_size: 4294967296  # 4 GB (CPU); use 2147483648 (2 GB) for GPU
+        memory_pool_device: "cpu"     # "cpu" for pinned memory (recommended), "cuda" for GPUDirect RDMA
 ```

 Wire stages to the connector:

 ```yaml
-stages:
+stage_args:
  - stage_id: 0
    output_connectors:
      to_stage_1: rdma_connector
@@ -414,7 +415,7 @@ A receiver connector:
 - allocates receive buffers from its own pool
 - requests metadata or transfer service from the sender

-The role is not inferred dynamically. It is injected from the deploy connector wiring:
+The role is not inferred dynamically. It is injected by the stage configuration layer:

 - incoming edge for a stage -> `role="receiver"`
 - outgoing edge for a stage -> `role="sender"`
@@ -13,9 +13,10 @@ segment name is returned in metadata.
 ## Configuration

 ```yaml
-connectors:
-  connector_of_shared_memory:
-    name: SharedMemoryConnector
+runtime:
+  connectors:
+    connector_of_shared_memory:
+      name: SharedMemoryConnector
 ```

 ## Notes
@@ -65,22 +65,23 @@ dscli stop --worker_address "${WORKER_IP}:31501"

 ## Configuration

-Define the connector at the top level of the deploy YAML:
+Define the connector in runtime:

 ```yaml
-connectors:
-  connector_of_yuanrong:
-    name: YuanrongConnector
-    extra:
-      host: "127.0.0.1"
-      port: 31501
-      get_sub_timeout_ms: 1000
+runtime:
+  connectors:
+    connector_of_yuanrong:
+      name: YuanrongConnector
+      extra:
+        host: "127.0.0.1"
+        port: 31501
+        get_sub_timeout_ms: 1000
 ```

 Wire stages to the connector:

 ```yaml
-stages:
+stage_args:
  - stage_id: 0
    output_connectors:
      to_stage_1: connector_of_yuanrong
@@ -94,23 +94,26 @@ For Ascend P2P, configure the connector with `protocol: "ascend"` and an NPU
 memory pool:

 ```yaml
-connectors:
-  yuanrong_te_connector:
-    name: YuanrongTransferEngineConnector
-    extra:
-      host: "auto"
-      zmq_port: 50051
-      rpc_port: "auto"
-      protocol: "ascend"
-      device_name: "auto"
-      memory_pool_size: 1073741824
-      memory_pool_device: "npu"
-
-edges:
-  - from: 0
-    to: 1
+runtime:
+  enabled: true
+  defaults:
    window_size: -1
    max_inflight: 1
+  connectors:
+    yuanrong_te_connector:
+      name: YuanrongTransferEngineConnector
+      extra:
+        host: "auto"
+        zmq_port: 50051
+        rpc_port: "auto"
+        protocol: "ascend"
+        device_name: "auto"
+        memory_pool_size: 1073741824
+        memory_pool_device: "npu"
+  edges:
+    - from: 0
+      to: 1
+      window_size: -1
 ```

 Important fields:
@@ -138,27 +141,31 @@ For AR 4-way TP sending KV cache to DiT 4-way TP, set the stage TP topology in
 both stage `omni_kv_config` blocks:

 ```yaml
-stages:
+stage_args:
  - stage_id: 0
-    devices: "0,1,2,3"
-    tensor_parallel_size: 4
-    omni_kv_config:
-      need_send_cache: true
-      rank_mapping:
-        from_tp: 4
-        to_tp: 4
+    runtime:
+      devices: "0,1,2,3"
+    engine_args:
+      tensor_parallel_size: 4
+      omni_kv_config:
+        need_send_cache: true
+        rank_mapping:
+          from_tp: 4
+          to_tp: 4
    output_connectors:
      to_stage_1: yuanrong_te_connector

  - stage_id: 1
-    devices: "4,5,6,7"
-    parallel_config:
-      tensor_parallel_size: 4
-    omni_kv_config:
-      need_recv_cache: true
-      rank_mapping:
-        from_tp: 4
-        to_tp: 4
+    runtime:
+      devices: "4,5,6,7"
+    engine_args:
+      parallel_config:
+        tensor_parallel_size: 4
+      omni_kv_config:
+        need_recv_cache: true
+        rank_mapping:
+          from_tp: 4
+          to_tp: 4
    input_connectors:
      from_stage_0: yuanrong_te_connector
 ```
@@ -41,7 +41,7 @@ With this in mind, consider the set of blocks in a 2D layout, where the row repr

 ### Example
 !!! note "Note 3"
-    Prefix caching in vLLM-Omni currently is only supported on AutoRegressive stages with one kv-cache group. Configure it with the pipeline-wide `enable_prefix_caching` field in the deploy config.
+    Prefix caching in vLLM-Omni currently is only supported on AutoRegressive stages with one kv-cache group. It can be enabled/disabled per-stage via the `enable_prefix_caching` parameter in the model's stage config.

 The way in which vLLM-Omni ties into vLLM's prefix caching is best understood by example. Say that we have the following:

@@ -190,15 +190,12 @@ configured parallelism strategy:
 - `WeightsMapper` transformations must be applied before matching ignored-layer
  lists or component prefixes.

-Distributed layerwise offload has an additional boundary: direct checkpoint
-mmap cannot prepare online-quantized tensors because it bypasses the ordinary
-loader that creates their runtime weights and scales. Per-tensor online FP8
-linears can still use DLO AllGather through the ordinary loader: each rank first
-finalizes the FP8 tensors, then DLO shards those runtime tensors for
-reconstruction during prefetch. Other online methods remain limited to
-`--dlo-no-use-allgather` until their packing and scale layouts are validated.
-See the [DLO design document](offloader/distributed_layerwise_offload.md) for
-the full compatibility matrix.
+Distributed layerwise offload has an additional boundary: its sharded mmap
+AllGather path is not compatible with online quantization because the path
+expects already materialized checkpoint weights. Use the rank-local
+`--dlo-no-use-allgather` path or a compatible pre-quantized checkpoint when
+combining these features. See the [DLO design document](offloader/distributed_layerwise_offload.md)
+for the full compatibility matrix.

 ## Adding a quantization backend

@@ -18,7 +18,6 @@ implementation contract; it is not, by itself, a general support claim.
 ### Runtime and stage execution

 - [Disaggregated Inference](feature/disaggregated_inference.md)
- [Host Weight Runtime](feature/host_weight_runtime.md)
 - [Async Chunk](feature/async_chunk.md)
 - [Async Diffusion Output](feature/async_diffusion_output.md)
 - [Async Omni Output Materialization](feature/omni_async_output_materialization.md)
@@ -89,15 +88,14 @@ The design contracts separate selection mechanics from backend algorithms:
 - [Model Integration](module/model_integration.md)
 - [Autoregressive Runtime](module/ar_runtime.md)
 - Diffusion
-    - [Overview](module/diffusion/index.md)
-    - [Runtime](module/diffusion/diffusion_runtime.md)
-    - [Model Integration](module/diffusion/diffusion_model_integration.md)
-    - [Continuous Batching](module/diffusion/continuous_batching.md)
-    - [Parallelism](module/diffusion/parallelism.md)
-    - [Offloader](module/diffusion/offloader.md)
+  - [Overview](module/diffusion/index.md)
+  - [Runtime](module/diffusion/diffusion_runtime.md)
+  - [Model Integration](module/diffusion/diffusion_model_integration.md)
+  - [Continuous Batching](module/diffusion/continuous_batching.md)
+  - [Parallelism](module/diffusion/parallelism.md)
+  - [Offloader](module/diffusion/offloader.md)
 - [Execution Platforms](module/execution_platforms.md)
 - [Cache Management](module/cache_management.md)
- [Host Weight Runtime](module/host_weight_runtime.md)
 - [Quantization](module/quantization.md)
 - [Observability](module/observability.md)
 - [Profiling](module/profiling.md)
@@ -18,7 +18,7 @@ validation_paths:
  - tests/diffusion/offloader/**
 upstream_refs:
  - torch.nn.Module.to
-last_reviewed: 2026-08-25
+last_reviewed: 2026-07-16
 ---

 # Diffusion offloader
@@ -48,11 +48,6 @@ and correctness required by the selected execution mode.
 **Rule:** Retained host and device copies MUST respect configured limits and
 provide deterministic teardown.

-Allocator-cache retention MUST remain local to an explicit component owner,
-declare both cache and physical-free-memory bounds, release conservatively
-when telemetry is unavailable, and force release on failure or memory
-pressure. It MUST NOT replace unconditional executor shutdown cleanup.
-
 ## Safe-change guide

 Test enabled and disabled paths, repeated execution, asynchronous transfer,
@@ -1,294 +0,0 @@
---
-title: Host Weight Runtime
-kind: module
-status: draft
-owners:
-  - "@hsliuustc0106"
-primary_code_paths:
-  - vllm_omni/host_weight_runtime/**
-related_code_paths:
-  - vllm_omni/diffusion/model_loader/**
-  - vllm_omni/diffusion/offloader/**
-depends_on:
-  - model_integration.md
-  - quantization.md
-validation_paths:
-  - tests/host_weight_runtime/**
-upstream_refs:
-  - https://github.com/vllm-project/vllm-omni/issues/6414
-last_reviewed: 2026-08-25
---
-
-# Host Weight Runtime
-
-The Host Weight Runtime is a loader-adjacent, transport-independent foundation
-for reusing immutable, runtime-ready model weights. It separates the semantic
-question—"are these exactly the weights this loader requested?"—from the
-physical question—"where is the validated host representation stored?"
-
-The runtime can save repeated checkpoint loading, transformation, and peak host
-memory when several workers need the same final representation. It also creates
-a second, versioned path for reconstructing a valid model, so a cache miss or
-recoverable store failure normally falls back to the canonical loader.
-
-This module does not enable host-weight caching for any model by itself. A model
-integration must still provide an exact identity, a producer, and a restorer.
-For feature behavior and consumer integration requirements, see the
-[Host Weight Runtime feature design](../feature/host_weight_runtime.md).
-
-## Component boundary
-
-```mermaid
-flowchart LR
-    LA["Model loader adapter"] -->|"exact identity + policy"| RT["HostWeightRuntime"]
-    RT -->|"lookup / get_or_build"| ST["HostWeightStore"]
-    PR["WeightProducer"] -->|"runtime-ready tensors"| ST
-    ST -->|"validated mmap views"| LE["HostWeightLease"]
-    LE --> RE["WeightRestorer"]
-    RE --> MO["Restored host model"]
-    MO --> TR["DLO or another GPU transport"]
-
-    CS["Canonical model source"] --> PR
-    LA -. "fallback" .-> CS
-```
-
-The contracts have deliberately narrow ownership:
-
- `HostWeightRuntime` applies resolution and fallback policy and emits one
-  terminal resolution report. Explicit post-load publication emits a separate
-  report and closes its store-returned lease before returning; it does not
-  revise the completed resolution.
-  The runtime does not own a model or call the canonical loader.
- `HostWeightStore` owns artifact lookup, coordinated construction,
-  publication, validation, quarantine, and lifecycle.
- `HostWeightLease` owns process-local tensor views, mapped-file resources, and
-  the shared artifact lock that stabilizes their lifetime.
- `WeightProducer` creates one declared final-layout representation. It writes
-  only through a store-scoped writer and cannot publish paths directly.
- `WeightRestorer` validates a lease-to-model plan without mutation. Its
-  one-shot `commit() -> None` is the sole model-mutating phase. Concrete
-  restorers remain with the model or quantization integration.
- GPU transport owns page registration, private staging, H2D scheduling, and
-  lease release. DLO must not parse manifests or manage store artifacts.
-
-## Exact semantic identity
-
-Storage lookup is exact; the store never coerces one representation into
-another. `WeightArtifactIdentity` includes:
-
- immutable model revision and source-file fingerprint;
- component and ownership boundary;
- runtime representation, dtype, and representation metadata;
- final tensor layout and semantic parallel coordinates;
- static adaptation identity; and
- producer version, implementation fingerprint, manifest schema, and restorer
-  schema.
-
-Loader integrations may persist content digests for canonical source shards in
-the selected storage domain. Reuse requires the same path, inode, size,
-timestamps, symlink target, and cache-record checksum. Corrupt records are
-rebuilt, and coordination or cache-I/O failure falls back to hashing the
-canonical source directly. This is an identity-computation optimization, not a
-second source of truth or an artifact substitution rule.
-
-The identity excludes transfer policy such as registered mmap versus private
-pinned staging. Those paths move the same host representation and must not
-produce duplicate artifacts.
-
-Parallel coordinates follow semantics rather than process topology:
-
- TP size and rank are included when they change tensor contents or shape.
- DP rank is excluded for replicated weights.
- SP size and backend are included when they affect layout. SP rank is excluded
-  only when all SP ranks consume an identical representation.
- PP, EP, or future parallel modes must be added by the model adapter whenever
-  they change component ownership or tensor layout.
-
-Dynamic LoRA overlays are not cached as base weights. A statically merged
-adapter is a distinct artifact identity with its own fingerprint.
-
-## Deterministic resolution
-
-The loader first resolves the canonical source and computes the exact requested
-identity. The runtime then follows this order:
-
-```text
-validated local artifact
-    -> exact remote artifact materialized locally (future)
-    -> registered local producer
-    -> canonical loader fallback, if policy permits
-```
-
-An already published local artifact wins because it avoids network transfer and
-is already in node-accessible storage. "Wins" means the highest-priority valid
-representation, not whichever backing responds first.
-
-Configuration modes are:
-
- `disabled`: return the canonical-direct outcome without probing a root,
-  credentials, topology, or identity;
- `preferred`: recoverable store failures may return canonical fallback; and
- `required`: fail when no exact lease can be acquired.
-
-Failure-to-action policy is centralized in `HostWeightRuntime`. A clean miss or
-invalid cache artifact may fall back in preferred mode. A typed failure may do
-so only when it is marked retryable; unsupported capabilities, identity
-collisions, producer failures, and publication failures remain visible as
-startup failures.
-
-`coordination_timeout_seconds` bounds acquisition of lookup and build locks; it
-is not a hard wall-clock deadline for in-process validation, production, or
-atomic publication. Once this V1 implementation becomes the producer, the
-synchronous producer and publication run to completion. A hung producer blocks
-its owning process and requires external process supervision; enforceable
-producer cancellation requires a future process-isolated producer contract. A
-waiter timing out never cancels another process's valid build.
-
-Remote providers are represented by protocols but are explicitly unsupported
-in the first implementation. Pre-load `resolve()` invokes only
-`PRE_LOAD_SAFE` producers. A loader that completed canonical materialization
-may explicitly call `publish_after_load()` with a `POST_LOAD_ONLY` producer
-when `allow_post_load_publish` is enabled.
-
-`allow_local_build` controls producer use during pre-load resolution;
-`allow_post_load_publish` independently controls the explicit post-load entry
-point. This permits lookup-only warm starts that populate a missing artifact
-only after the canonical loader has established the current model.
-
-Post-load publication is synchronous in V1, but its outcome is independent of
-the already completed resolution. A store failure is returned in a separate
-publication report and cannot turn a valid canonical model into a failed
-resolution. On success, the runtime closes the validated store lease before
-returning the report. Post-load publication only warms future startups; it does
-not restore, rebind, or otherwise mutate the canonically loaded model serving
-the current startup.
-
-## Restoration transaction boundary
-
-`WeightRestorer.plan_restore()` is validation-only: it must not modify the model
-or lease. The returned plan may be committed exactly once, `commit()` returns
-`None`, and commit is the sole phase allowed to mutate the model. Registration,
-staging, and GPU transfer remain transport responsibilities rather than restore
-side effects.
-
-If planning fails, preferred-mode canonical fallback may reuse the untouched
-model. If commit begins and then fails, the model is considered partially
-hydrated and must be discarded; canonical fallback must construct a fresh model
-instance instead of reusing it.
-
-## Filesystem domain and artifact lifecycle
-
-A storage domain describes physical locality and policy; it is not part of
-semantic identity. The first implementation supports node- or NUMA-scoped
-roots on verified local disk filesystems or tmpfs. The detected kernel
-filesystem type is preserved in `domain.json` and inspection output. Known
-remote filesystems and unknown filesystem types are rejected rather than being
-silently treated as local disk, because cross-node page cache and advisory-lock
-semantics do not satisfy this backend's contract. A NUMA root alone does not
-guarantee page placement; CPU pinning, local first-touch/prefault, and residency
-evidence belong to a later topology-aware integration.
-
-```text
-<domain>/
-├── domain.json
-├── domain-policy.json
-├── locks/
-│   ├── <identity>.build.lock
-│   └── <identity>.artifact.lock
-├── artifacts/<identity>/
-│   ├── READY.json
-│   ├── manifest.json
-│   └── *.safetensors
-├── tmp/
-├── quarantine/
-└── deny/
-```
-
-Lock files live outside replaceable artifact directories. Every cooperative
-mutation follows one lock order: build lock, then exclusive artifact lock.
-Lookup acquires a shared artifact lock, validates `READY` and the manifest,
-opens payloads with non-following descriptor-based access, creates mmap-backed
-views, and transfers that shared lock to the lease.
-
-Lease acquisition rechecks the producer and restorer schemas against the exact
-identity. Malformed safetensors payloads are reported as typed invalid
-artifacts and denied rather than escaping the resolution policy as raw parser
-exceptions.
-
-Each `FileLock` records its creator PID. A forked child closes an inherited lock
-descriptor without issuing `LOCK_UN`, because `flock` state belongs to the
-shared open-file description and unlocking in the child would also release the
-parent's active lease lock.
-
-Publication follows this lifecycle:
-
-```text
-ABSENT -> invisible temporary build -> fully hashed and fsynced
-       -> atomic rename -> READY
-
-READY -> denied -> quarantined -> explicit removal
-```
-
-`READY.json` is written last in the temporary directory. Readers therefore see
-either a complete validated artifact or a miss, never an in-progress build.
-Failed process-local builds are left invisible and a later build owner removes
-their stale temporary directories. Explicit cleanup is nonblocking and reports
-an active builder or lease instead of unlinking live mappings.
-
-## Validation and capacity
-
-Every publication computes full file and tensor hashes. Local lookup supports:
-
- `manifest_and_metadata`, which validates identity, immutable publication
-  metadata, file descriptors, sizes, tensor keys, shapes, dtypes, and strides;
-  and
- `full_checksum`, which additionally reads and hashes every payload file.
-
-An ordered producer may compute file and tensor digests while payload bytes are
-written and overlap each closed payload's `fsync` with later producer work. An
-unordered producer retains parallel readback hashing. In both cases manifest
-and `READY` publication wait for every payload digest and `fsync`; the atomic
-publication and validation contract is unchanged.
-
-Filesystem verity is modeled but unsupported. Invalid artifacts receive an
-external deny marker before their shared lookup lock is released; a build owner
-then quarantines the immutable directory under the exclusive lock.
-Lookup checks the marker both before validation and after constructing the
-lease so a weaker overlapping lookup cannot return a lease after a stronger
-validation has denied the artifact.
-
-`inspect_domain()` and `inspect_artifact()` return typed, read-only snapshots.
-Inspection validation does not create a deny marker. Reported lock activity is
-point-in-time evidence only; kernel locks are not a persistent owner registry.
-
-Capacity policy covers all store-owned bytes, including ready, temporary, and
-quarantined data. The local writer preflights `max_artifact_bytes`,
-`max_store_bytes`, and `min_free_bytes`, and preallocates payloads where the
-filesystem supports it. `ENOSPC` remains a normal typed store failure because
-concurrent preflight is inherently racy. Automatic eviction and strict
-concurrent reservations are not implemented.
-
-For tmpfs, artifact bytes are host-memory consumption and may consume swap;
-they must not be reported operationally as ordinary disk capacity. The store
-owns files and reports capacity. The kernel controls page-cache residency, and
-transport controls registration or page locking.
-
-## First implementation scope
-
-The foundation implements a CPU local filesystem store and
-`SINGLE_PROCESS` production for one exact artifact. It intentionally adds no:
-
- public CLI or DLO configuration;
- BF16, FP8, or model-specific producer/restorer;
- change to DLO AllGather or no-AllGather behavior;
- CUDA registration, pinned staging, or H2D scheduling;
- remote provider, group-cohort producer, artifact bundle, eviction, or
-  cross-node coordination.
-
-Consumer PRs must prove ordinary-loader parity, warm-hit work avoidance,
-parallel-layout correctness, clean teardown, shared-backing evidence, and
-representation-specific startup and memory behavior. Generic foundation tests
-remain CPU-only and make no production performance claim.
-
-The complete rationale and staged rollout are tracked in
-[RFC #6414](https://github.com/vllm-project/vllm-omni/issues/6414).
@@ -42,7 +42,7 @@ and execution behavior to stable runtime contracts.
 ### MODEL-INV-001: Registration is explicit

 **Rule:** A model integration MUST declare how its model class, loader, input
-processor, and pipeline configuration are selected.
+processor, and stage configuration are selected.

 ### MODEL-INV-002: Model code does not route stages

@@ -10,15 +10,16 @@ owners:
 primary_code_paths:
  - vllm_omni/config/**
  - vllm_omni/deploy/**
-  - vllm_omni/model_executor/models/*/pipeline.py
-related_code_paths: []
+  - vllm_omni/model_executor/stage_configs/**
+related_code_paths:
+  - vllm_omni/platforms/*/stage_configs/**
 depends_on: []
 validation_paths:
  - tests/config/**
 upstream_refs:
  - vllm.config
-last_reviewed: 2026-08-11
-last_verified_commit: e356708da4cd39992405686dacfc32b18fcccc7f
+last_reviewed: 2026-08-07
+last_verified_commit: 3d7fc3b9ba3cac88d579d4dc35b78b0b641675fc
 ---

 # vLLM-Omni configuration
@@ -38,66 +39,11 @@ The PR review proposal to capture environment-derived values in configuration
 objects at initialization is an open design question, not a current
 invariant.

-## Current structured-stage reuse behavior
-
-The current RFC #4021 implementation uses upstream vLLM config classes as the
-schema source for AR and generation stages:
-
- `OmniStageLoadConfig` inherits `vllm.config.LoadConfig`.
- `OmniStageCacheConfig` inherits `vllm.config.CacheConfig`.
- `OmniStageSchedulerConfig` inherits `vllm.config.SchedulerConfig`.
- `OmniStageParallelConfig` inherits `vllm.config.ParallelConfig`.
-
-This inheritance preserves the existing load, cache, scheduler, and parallel
-concern boundaries while reducing duplicate downstream declarations. It does
-not, by itself, make every inherited field an effective vLLM-Omni runtime
-option. Construction and runtime consumption are separate surfaces:
-
-| Surface | Current behavior |
-| --- | --- |
-| Structured schema | Upstream dataclass fields are inherited. Their defaults, default factories, and applicable Pydantic validation can participate when the structured object is constructed. |
-| Omni input ownership | Pipeline/deploy/CLI construction continues to accept only fields with an existing structured owner. Direct construction of an inherited sub-config can expose a wider upstream schema. |
-| Engine projection | For AR and generation stages, reusable fields are discovered by intersecting each upstream config dataclass with upstream `EngineArgs`. Only constructor-explicit values are emitted; inherited defaults remain deferred to terminal materialization. |
-| Terminal materialization | The engine-owning process constructs the final upstream `VllmConfig` and performs model-, platform-, rank-, port-, and backend-dependent initialization. |
-
-The generated projection maps include known upstream naming differences such
-as `cache_dtype` to `kv_cache_dtype`, `policy` to `scheduling_policy`, and
-`data_parallel_master_ip` to `data_parallel_address`. A field added to both an
-upstream concern config and `EngineArgs` therefore enters the AR/generation
-projection without requiring a second downstream allowlist. Explicit inherited
-fields that have no projection raise an error rather than being silently
-dropped.
-
-Ownership exclusions remain deliberate. Stage topology owns `scheduler_cls`,
-cache owns `disable_hybrid_kv_cache_manager`, and Omni runtime owns
-`distributed_executor_backend` and `worker_cls`; vLLM's private API-process
-fields are terminal internals. These exclusions prevent one input from being
-constructed or projected through two config concerns. Effective-engine-argument
-tests cover both the dynamic mapping and this exclusion boundary.
-
-`CompilationConfig` and `ProfilerConfig` are direct structured-stage fields:
-`stage.compilation_config` and `stage.profiler_config`. They accept mapping/YAML
-inputs and complete upstream value objects. Mapping inputs are validated and
-materialized as their concrete upstream types when the structured config is
-constructed, so downstream consumers see one resolved representation.
-Prebuilt upstream objects retain their type across the structured projection
-boundary.
-
-Quantization remains on its existing Omni-owned transport contract. This
-reuse step does not adopt upstream `QuantizationConfigArgs`, because the
-current engine-specific quantization split needs to be resolved separately.
-
-Diffusion keeps its existing engine-field ownership and projection surface.
-Shared Python inheritance must not be treated as evidence that an LLM-only
-parallel input is effective for a diffusion stage.
-
 ## Safe-change guide while deferred

 Changes should trace every affected producer to its runtime consumer and test
-the structured pipeline, CLI, and deployment paths that are actually supported.
-For inherited vLLM fields, tests should separately cover constructor behavior
-and effective `EngineArgs` projection. Do not infer a stable contract from
-this placeholder page.
+the structured, legacy, CLI, and deployment paths that are actually supported.
+Do not infer a stable contract from this placeholder page.

 ## Promotion gate

@@ -111,7 +111,7 @@ This post walks through each optimization in the same order they are typically e

 For both Qwen3-Omni and Qwen3-TTS, batching is a pipeline-level optimization:

- Requests are grouped per stage using `stages[].max_num_seqs`
+- Requests are grouped per stage using `runtime.max_batch_size`
 - Each stage executes batch inference with its own scheduler/worker
 - Stage outputs are routed to downstream stages with per-request mapping preserved

@@ -171,7 +171,7 @@ At concurrency 10, batching alone brings Qwen3-TTS RTF from 2.19 (slower than re

 In decode-heavy serving, repeatedly launching many small kernels from CPU can become a visible overhead. CUDA Graph reduces this overhead by capturing and replaying stable execution graphs.

-In deploy configs, this is represented by `enforce_eager: false` for stages where graph capture is desired (Thinker/Talker), while Code2Wav keeps eager mode depending on stage behavior.
+In stage configs, this is represented by `enforce_eager: false` for stages where graph capture is desired (Thinker/Talker), while Code2Wav keeps eager mode depending on stage behavior.

 ### CUDA Graph results on top of batching

@@ -320,7 +320,7 @@ In the async chunk pipeline, the standard `codec_chunk_frames` is 25 (each chunk

 **Dynamic initial chunk sizing (default behavior):**

-Rather than using a fixed initial chunk size, vLLM-Omni dynamically selects it based on current server load. The initial chunk size is chosen from power-of-2 steps [2, 4, 8, 16] based on load factor (`active_requests / max_num_seqs`):
+Rather than using a fixed initial chunk size, vLLM-Omni dynamically selects it based on current server load. The initial chunk size is chosen from power-of-2 steps [2, 4, 8, 16] based on load factor (`active_requests / max_batch_size`):

 | Server load | Initial chunk frames | Rationale |
 | --- | --- | --- |
@@ -349,15 +349,16 @@ This overrides the dynamic calculation for that request.
 **Config (server-side):**

 ```yaml
-connectors:
-  connector_of_shared_memory:
-    name: SharedMemoryConnector
-    extra:
-      codec_streaming: true
-      codec_chunk_frames: 25              # standard chunk size (~2s of audio)
-      codec_left_context_frames: 25
-      # initial chunk is computed dynamically by default
-      # set initial_codec_chunk_frames: 2 to force a fixed value
+runtime:
+  connectors:
+    connector_of_shared_memory:
+      name: SharedMemoryConnector
+      extra:
+        codec_streaming: true
+        codec_chunk_frames: 25              # standard chunk size (~2s of audio)
+        codec_left_context_frames: 25
+        # initial chunk is computed dynamically by default
+        # set initial_codec_chunk_frames: 2 to force a fixed value
 ```

 The 64 ms TTFP result reported above for Qwen3-TTS at concurrency 1 uses the dynamic initial chunk, which picks `initial_codec_chunk_frames=2` at low load. At higher concurrency the dynamic sizing increases the initial chunk to maintain decode efficiency.
@@ -407,7 +408,7 @@ vllm serve Qwen/Qwen3-Omni-30B-A3B-Instruct \

 Notes:

- `stages[].max_num_seqs` controls stage-level batching.
+- `runtime.max_batch_size` controls stage-level batching.
 - Thinker/Talker commonly use `enforce_eager: false` for CUDA Graph paths.
 - Code2Wav often remains eager (`enforce_eager: true`) depending on runtime behavior.
 - Qwen3-Omni defaults `VLLM_USE_FLASHINFER_MOE_FP16=0`. The Triton has been more stable & faster
@@ -425,26 +426,33 @@ vllm serve Qwen/Qwen3-Omni-30B-A3B-Instruct \

 ```yaml
 async_chunk: true
-stages:
+stage_args:
  - stage_id: 0  # thinker
-    max_num_seqs: 64
-    enforce_eager: false
-    max_num_batched_tokens: 32768
+    runtime:
+      max_batch_size: 64
+    engine_args:
+      enforce_eager: false
+      max_num_batched_tokens: 32768
+      custom_process_next_stage_input_func: >-
+        vllm_omni.model_executor.stage_input_processors.qwen3_omni.thinker2talker_async_chunk

  - stage_id: 1  # talker
-    max_num_seqs: 64
-    enforce_eager: false
-    max_num_batched_tokens: 32768
+    runtime:
+      max_batch_size: 64
+    engine_args:
+      enforce_eager: false
+      max_num_batched_tokens: 32768
+      custom_process_next_stage_input_func: >-
+        vllm_omni.model_executor.stage_input_processors.qwen3_omni.talker2code2wav_async_chunk

  - stage_id: 2  # code2wav
-    max_num_seqs: 64
-    enforce_eager: true
-    max_num_batched_tokens: 51200
+    runtime:
+      max_batch_size: 64
+    engine_args:
+      enforce_eager: true
+      max_num_batched_tokens: 51200
 ```

-The async handoff processors are fixed by the registered Qwen3-Omni
-`PipelineConfig`; deploy YAML only selects `async_chunk` and runtime sizing.
-
 #### Reproduce Qwen3-Omni benchmarks

 ```bash
@@ -475,7 +483,7 @@ vllm-omni serve Qwen/Qwen3-TTS-12Hz-1.7B-CustomVoice \

 The default config (`qwen3_tts.yaml`) enables the full optimization stack:

- Batching with `max_num_seqs: 10` on the Talker stage
+- Batching with `max_batch_size: 10` on the Talker stage
 - CUDA Graph on the Talker (`enforce_eager: false`)
 - Async chunk with streaming transport

@@ -492,29 +500,33 @@ vllm-omni serve Qwen/Qwen3-TTS-12Hz-1.7B-CustomVoice \

 ```yaml
 async_chunk: true
-stages:
+stage_args:
  - stage_id: 0  # Talker (AR decoder)
-    max_num_seqs: 10
-    enforce_eager: false
-    max_num_batched_tokens: 512
+    runtime:
+      max_batch_size: 10
+    engine_args:
+      enforce_eager: false
+      max_num_batched_tokens: 512
+      custom_process_next_stage_input_func: >-
+        vllm_omni.model_executor.stage_input_processors.qwen3_tts.talker2code2wav_async_chunk

  - stage_id: 1  # Code2Wav (vocoder)
-    max_num_seqs: 1
-    enforce_eager: true
-    max_num_batched_tokens: 8192
+    runtime:
+      max_batch_size: 1
+    engine_args:
+      enforce_eager: true
+      max_num_batched_tokens: 8192

-connectors:
-  connector_of_shared_memory:
-    name: SharedMemoryConnector
-    extra:
-      codec_streaming: true
-      codec_chunk_frames: 25
-      codec_left_context_frames: 25
+runtime:
+  connectors:
+    connector_of_shared_memory:
+      name: SharedMemoryConnector
+      extra:
+        codec_streaming: true
+        codec_chunk_frames: 25
+        codec_left_context_frames: 25
 ```

-The async Talker-to-Code2Wav processor is defined by the registered Qwen3-TTS
-pipeline rather than the deploy YAML.
-
 #### Reproduce Qwen3-TTS benchmarks

 ```bash
@@ -20,19 +20,13 @@ an implementation contract has a user-facing workflow.
 | Choose serial, batched, step-wise, or streaming diffusion execution | [Execution Modes and Streaming](../user_guide/diffusion/execution_modes.md) | [Diffusion Continuous Batching](../design/feature/diffusion_continuous_batching.md), [Async Diffusion Output](../design/feature/async_diffusion_output.md) |
 | Reclaim stage memory without restarting the server | [Sleep Mode](sleep_mode.md) | Runtime lifecycle behavior is documented in the user guide |

-The [Prefill-Decode Disaggregation design reference](pd_disaggregation.md)
-describes the experimental Qwen3-Omni runtime topology and its current
-integration boundaries. It is not yet a supported launch recipe.
-
 Some runtime designs are deliberately not promoted as standalone User Guide
 features yet:

- Generic, OmniConnector-based
-  [Disaggregated Inference](../design/feature/disaggregated_inference.md) is not
-  yet a standalone User Guide feature. Its
+- [Disaggregated Inference](../design/feature/disaggregated_inference.md) and
  [OmniConnector implementations](../design/index.md#communication) describe
-  transport contracts, while practical connector configuration remains under
-  [Pipeline and deploy configurations](../configuration/stage_configs.md).
+  topology and transport contracts. Practical deployment configuration remains
+  under [Pipeline and deploy configurations](../configuration/stage_configs.md).
 - [Async Chunk](../design/feature/async_chunk.md) and
  [Async Omni Output Materialization](../design/feature/omni_async_output_materialization.md)
  are model- and pipeline-dependent. Use the selected model's deploy
@@ -1,140 +0,0 @@
-# Prefill-Decode (PD) Disaggregation (experimental)
-
-!!! warning "Experimental design reference"
-    PD disaggregation is only partially integrated on the current `main` branch.
-    The runtime contains PD detection and routing scaffolding, but there is no
-    supported deploy overlay or end-to-end validated launch recipe yet. Treat this
-    page as a description of the current design, not as production guidance.
-
-Prefill-decode disaggregation splits the Qwen3-Omni Thinker into two logical
-stages: a prefill worker that processes the prompt and produces KV cache, and a
-decode worker that imports that cache and generates tokens. The Talker and
-Code2Wav stages remain downstream; PD does not disaggregate the entire
-Qwen3-Omni pipeline.
-
-## Current design
-
-### Runtime topology
-
-```mermaid
-flowchart LR
-    client["Client request"] --> orchestrator["Omni Orchestrator"]
-    orchestrator -->|"original prompt<br/>max_tokens = 1"| prefill["Thinker prefill<br/>KV producer"]
-    prefill -->|"KV blocks"| connector[("vLLM KV connector")]
-    prefill -->|"KV routing metadata"| orchestrator
-    orchestrator -->|"original prompt<br/>remote KV parameters"| decode["Thinker decode<br/>KV consumer"]
-    connector -->|"remote KV load"| decode
-    decode -->|"generated text"| client
-```
-
-The orchestrator owns the request lifecycle, while the vLLM KV connector owns
-the bulk KV transfer. The original prompt is submitted to both Thinker stages:
-the decode worker still needs the request tokens and multimodal features to
-construct its request, while the imported KV cache prevents it from repeating
-the completed prefill computation.
-
-For the full Qwen3-Omni pipeline, splitting the Thinker adds one logical stage:
-
-| Stage | Role | Output or handoff |
-| --- | --- | --- |
-| 0 | Thinker prefill | Saves prompt KV and prompt-side multimodal output |
-| 1 | Thinker decode | Loads remote KV, generates text, and produces decode-side conditioning |
-| 2 | Talker | Converts combined Thinker conditioning into codec codes |
-| 3 | Code2Wav | Converts codec codes into audio |
-
-Text remains a final output of the decode stage, and audio remains a final
-output of Code2Wav.
-
-### Request lifecycle
-
-1. At startup, PD detection looks for one stage marked `is_prefill_only` and
-   one downstream stage marked `is_decode_only`. The decode stage must list the
-   prefill stage as an input source.
-2. The orchestrator clones the Thinker sampling parameters for prefill, forces
-   `max_tokens=1`, clears stop conditions, and sets producer-side
-   `kv_transfer_params`. This makes prefill finish by length after exporting KV.
-3. When prefill finishes, the orchestrator captures its KV routing metadata and
-   Qwen multimodal output under the original request ID.
-4. The orchestrator submits the original prompt to decode with consumer-side
-   `kv_transfer_params`. Those parameters identify the transfer, prefill engine,
-   bootstrap endpoint, and, when required by the connector, remote request.
-5. The decode engine imports the KV cache and continues generation. The normal
-   Omni stage path then carries Thinker conditioning through Talker and
-   Code2Wav.
-
-### Control and data paths
-
-PD uses two different connector layers. They solve different handoffs and are
-not interchangeable.
-
-| Path | Payload | Owner |
-| --- | --- | --- |
-| PD control path | Request ID, original prompt, `transfer_id`, bootstrap address, engine ID, and connector-specific request metadata | Omni Orchestrator |
-| PD data path | Thinker attention KV blocks | vLLM KV connector |
-| Downstream model path | Thinker hidden states and embeddings, Talker codec codes, and audio tensors | vLLM-Omni stage connectors and processors |
-
-### Detection and validation
-
-The current runtime accepts one logical prefill/decode pair per pipeline. Each
-stage may use tensor parallelism, but both sides of the pair must satisfy these
-invariants:
-
- both stages define `kv_transfer_config`
- prefill uses `kv_producer` or `kv_both`
- decode uses `kv_consumer` or `kv_both`
- both stages use the same KV connector
- `kv_buffer_device` and `kv_buffer_size` agree when set on both stages
- both stages use the same `tensor_parallel_size`
-
-These checks happen before request processing so an inconsistent PD topology
-fails during engine initialization.
-
-## What is implemented today
-
-| Area | Current state |
-| --- | --- |
-| Pair detection and topology validation | Implemented in the shared PD helper |
-| Prefill sampling preparation | Implemented for sync and async entrypoints |
-| Prefill-to-decode routing | Implemented in the current Orchestrator |
-| Deploy-based configuration | Not yet migrated; the supported `stages:` deploy schema cannot currently expand Qwen3-Omni into the four-stage PD topology |
-| Qwen3 Thinker-to-Talker handoff | Bridge state and embedding-merge helpers exist, but the merge is not wired into the live stage processor |
-| Connector compatibility | Incomplete; the Orchestrator currently requires `remote_request_id`, while the pinned Mooncake connector completes prefill without returning that metadata |
-| Validation coverage | PD entrypoint tests and the PD deploy overlay in online end-to-end tests are temporarily disabled during migration |
-| Performance | No non-regression or throughput/latency result is established for the current path |
-
-Because these pieces are still converging, the previous legacy `stage_args` YAML
-and `vllm serve` command have been removed. The serve CLI now accepts the
-deploy-based `stages:` schema, so retaining the legacy recipe would imply a
-launch path that current `main` rejects.
-
-## Configuration contract under development
-
-The intended deploy integration starts from the
-[default Qwen3-Omni deploy config](gh-file:vllm_omni/deploy/qwen3_omni_moe.yaml)
-and expands its frozen three-stage pipeline into the four stages shown above.
-A complete integration must:
-
- split the Thinker definition without duplicating the Talker or Code2Wav model
-  contracts
- remap downstream stage IDs, input sources, and stage connectors
- inject producer and consumer `kv_transfer_config` values into the two Thinker
-  stages
- allocate separate device sets for prefill and decode
- preserve both final outputs: decode text and Code2Wav audio
- provide connector-specific routing metadata without hard-coding one connector
-  contract
-
-The required number of GPUs depends on tensor-parallel sizes and whether Talker
-and Code2Wav share a device. A basic TP=1 layout uses one device for prefill, one
-for decode, and one for the two downstream audio stages.
-
-## Implementation map
-
- PD detection, validation, and sampling-parameter preparation:
-  [`PDDisaggregationMixin`](gh-file:vllm_omni/entrypoints/pd_utils.py)
- startup detection and connector metadata:
-  [`AsyncOmniEngine`](gh-file:vllm_omni/engine/async_omni_engine.py)
- request-scoped prefill-to-decode routing:
-  [`Orchestrator`](gh-file:vllm_omni/engine/orchestrator.py)
- Qwen3 downstream conditioning helpers:
-  [Qwen3-Omni stage input processor](gh-file:vllm_omni/model_executor/stage_input_processors/qwen3_omni.py)
@@ -66,7 +66,7 @@ from vllm_omni.entrypoints.omni import Omni
 if __name__ == "__main__":
    omni = Omni(
        model="Tongyi-MAI/Z-Image-Turbo",
-        # deploy_config="./deploy-config.yaml",  # Optional deploy override
+        # stage_configs_path="./stage-config.yaml",  # See below
    )
    prompts = [
        "a cup of coffee on a table",
@@ -39,7 +39,6 @@ th {
 | `WanImageToVideoPipeline` | Wan2.2-I2V | `Wan-AI/Wan2.2-I2V-A14B-Diffusers` | ✅︎ | ✅︎ | ✅︎ | ✅︎ | — |
 | `LingBotWorldCausalDMDPipeline` | LingBot-World 2.0 v1 (experimental) | `robbyant/lingbot-world-v2-14b-causal-fast-diffusers` | Experimental | | | | — |
 | `Cosmos3OmniDiffusersPipeline` | Cosmos3 T2I, T2V, I2V, V2V, T2V with sound, action policy | `nvidia/Cosmos3-Nano`, `nvidia/Cosmos3-Super` | ✅︎ | ✅︎ | ✅︎ | ✅︎ | — |
-| `SanaWmPipeline` | SANA-WM | `BBBBruce/SANA-WM_bidirectional-stage1-diffusers` | ✅︎ | | | | [Repository](https://github.com/vllm-project/vllm-omni/blob/main/recipes/NVIDIA/SANA-WM.md) |
 | `Wan22S2VPipeline` | Wan2.2-S2V | `Wan-AI/Wan2.2-S2V-14B` | ✅︎ | ✅︎ | ✅︎ | ✅︎ | — |
 | `Wan22VACEPipeline` | Wan2.1-VACE | `Wan-AI/Wan2.1-VACE-1.3B-diffusers`, `Wan-AI/Wan2.1-VACE-14B-diffusers` | ✅︎ | ✅︎ | ✅︎ | ✅︎ | — |
 | `Wan22VACEPipeline` | Wan2.2-VACE | `Pyros13/Wan2.2-VACE-Fun-A14B-Diffusers` | ✅︎ |   |   |   | — |
@@ -52,11 +51,8 @@ th {
 | `LTX2DistilledOneStagePipeline` | LTX-2.5 merged-distilled one-stage T2V and I2V | `Lightricks/LTX-2.5-Diffusers` | ✅︎ | | | | [Repository](https://github.com/vllm-project/vllm-omni/blob/main/recipes/LTX/LTX-2.5.md) |
 | `LTX2DistilledTwoStagePipeline` | LTX-2.5 merged-distilled two-stage T2V and I2V | `Lightricks/LTX-2.5-Diffusers` | ✅︎ | | | | [Repository](https://github.com/vllm-project/vllm-omni/blob/main/recipes/LTX/LTX-2.5.md) |
 | `LingBotVideoPipeline` | LingBot-Video dense and MoE T2I, T2V, TI2V | `robbyant/lingbot-video-dense-1.3b`, `robbyant/lingbot-video-moe-30b-a3b` | ✅︎ | | | | — |
-| `SanaVideoPipeline` | SANA-Video-2B T2V (native 480p/720p; Diffusers adapter validated at both resolutions) | `Efficient-Large-Model/SANA-Video_2B_480p_diffusers`, `Efficient-Large-Model/SANA-Video_2B_720p_diffusers` | ✅︎ | | | | [Repository](https://github.com/vllm-project/vllm-omni/blob/main/recipes/NVIDIA/SANA-Video-2B.md) |
-| `SanaImageToVideoPipeline` | SANA-Video-2B I2V (native and Diffusers adapter validated at 480p/720p) | `Efficient-Large-Model/SANA-Video_2B_480p_diffusers`, `Efficient-Large-Model/SANA-Video_2B_720p_diffusers` | ✅︎ | | | | [Repository](https://github.com/vllm-project/vllm-omni/blob/main/recipes/NVIDIA/SANA-Video-2B.md) |
 | `MiniMaxH3Pipeline` | MiniMax H3 T2VA, first/last-keyframe FL2VA, and mixed-reference Ref2VA | `MiniMaxAI/MiniMax-H3` | ✅︎ | ✅︎ | | | [Published](https://recipes.vllm.ai/MiniMaxAI/MiniMax-H3) |
 | `DreamZeroPipeline` | DreamZero-DROID | `GEAR-Dreams/DreamZero-DROID` | ✅︎ | ✅︎ | ✅︎ | ✅︎ | — |
-| `Pi0Pipeline` | π0 (Pi-Zero) VLA | `lerobot/pi0_base` | ✅︎ | | | | [Repository](https://github.com/vllm-project/vllm-omni/blob/main/recipes/lerobot/Pi0.md) |
 | `HeliosPipeline`, `HeliosPyramidPipeline` | Helios | `BestWishYsh/Helios-Base`, `BestWishYsh/Helios-Mid`, `BestWishYsh/Helios-Distilled` | ✅︎ | ✅︎ | ✅︎ | | — |
 | `MagiHumanPipeline` | MagiHuman | `SII-GAIR/daVinci-MagiHuman-Base-1080p` | ✅︎ | ✅︎ | | | — |
 | `OvisImagePipeline` | Ovis-Image | `OvisAI/Ovis-Image` | ✅︎ | ✅︎ | | ✅︎ | — |
@@ -70,13 +66,17 @@ th {
 | `OmniVoiceModel` | OmniVoice | `k2-fsa/OmniVoice` | ✅︎ | | | | — |
 | `VoxCPM2TalkerForConditionalGeneration` | VoxCPM2 | `openbmb/VoxCPM2` | ✅︎ | | | | — |
 | `DotsTTSForConditionalGeneration` | dots.tts | `rednote-hilab/dots.tts-soar` | ✅︎ | | | | — |
+| `MammothModa2ForConditionalGeneration` | MammothModa2-Preview | `bytedance-research/MammothModa2-Preview` | ✅︎ | ✅︎ | | | — |
+| `MammothModa2ForConditionalGeneration` | MammothModa2-Dev (AR-only image understanding) | `bytedance-research/MammothModa2-Dev` | ✅︎ | | | | — |
 | `Flux2KleinPipeline` | FLUX.2-klein | `black-forest-labs/FLUX.2-klein-4B`, `black-forest-labs/FLUX.2-klein-9B` | ✅︎ | ✅︎ | ✅︎ | ✅︎ | — |
 | `FluxKontextPipeline` | FLUX.1-Kontext-dev | `black-forest-labs/FLUX.1-Kontext-dev` | ✅︎ | ✅︎ | | | — |
 | `FluxPipeline` | FLUX.1-dev | `black-forest-labs/FLUX.1-dev` | ✅︎ | ✅︎ | | ✅︎ | — |
 | `FluxPipeline` | FLUX.1-schnell | `black-forest-labs/FLUX.1-schnell` | ✅︎ | ✅︎ | | ✅︎ | — |
 | `OmniGen2Pipeline` | OmniGen2 | `OmniGen2/OmniGen2` | ✅︎ | ✅︎ | | ✅︎ | — |
 | `StableAudioPipeline` | Stable-Audio-Open | `stabilityai/stable-audio-open-1.0` | ✅︎ | ✅︎ | | ✅︎ | — |
-| `MiniMaxMusic3ForConditionalGeneration` | MiniMax Music 3 (text-to-music) | `MiniMaxAI/MiniMax-Music3` | ✅︎ | | | | — |
+| `SoulXSingerPipeline` | SoulX-Singer (SVS) | `Soul-AILab/SoulX-Singer` | ✅︎ | | | | — |
+| `SoulXSingerSVCPipeline` | SoulX-Singer-SVC | `Soul-AILab/SoulX-Singer` (`model-svc.pt`) | ✅︎ | | | | — |
+| `AudioXPipeline` | AudioX | `zhangj1an/AudioX` | ✅︎ | ✅︎ | | | — |
 | `Qwen3TTSForConditionalGeneration` | Qwen3-TTS-12Hz-1.7B-CustomVoice | `Qwen/Qwen3-TTS-12Hz-1.7B-CustomVoice` | ✅︎ | | | | [Published](https://recipes.vllm.ai/Qwen/Qwen3-TTS-12Hz-1.7B-CustomVoice) |
 | `Qwen3TTSForConditionalGeneration` | Qwen3-TTS-12Hz-1.7B-VoiceDesign | `Qwen/Qwen3-TTS-12Hz-1.7B-VoiceDesign` | ✅︎ | ✅︎ | ✅︎ | ✅︎ | — |
 | `Qwen3TTSForConditionalGeneration` | Qwen3-TTS-12Hz-1.7B-Base | `Qwen/Qwen3-TTS-12Hz-1.7B-Base` | ✅︎ | ✅︎ | ✅︎ | ✅︎ | — |
@@ -106,7 +106,6 @@ th {
 | `ErnieImagePipeline` | ERNIE-Image | `baidu/ERNIE-Image`, `baidu/ERNIE-Image-Turbo` | ✅︎ | ✅︎ | ✅︎ | ✅︎ | — |
 | `GepardTalkerForConditionalGeneration` | Gepard-1.0 | `nineninesix/gepard-1.0` | ✅︎ | | | | — |
 |`HiDreamImagePipeline` | HiDream-I1-Full | `HiDream-ai/HiDream-I1-Full` | ✅︎ | ✅︎ | | | — |
-| `HiDreamO1ImagePipeline` | HiDream-O1-Image | `HiDream-ai/HiDream-O1-Image` | ✅︎ | | | | — |

 The `Recipe` column links the corresponding deployment recipe. `Published` is
 preferred when a corresponding `recipes.vllm.ai` page exists; otherwise the
@@ -123,14 +123,7 @@ When `stream=false` or omitted, the endpoint returns the standard image edit res
    }
  ],
  "output_format": null,
-  "size": null,
-  "metrics": {
-    "stage_durations": {
-      "queue_wait_ms": 1.0,
-      "stage_0_gen_ms": 2.0
-    },
-    "peak_memory_mb": 1024.0
-  }
+  "size": null
 }
 ```

@@ -131,7 +131,7 @@ Content-Type: application/json

 | Parameter | Type | Default | Description |
 |-----------|------|---------|-------------|
-| `ref_audio` | string | null | Reference audio (HTTP URL, base64 data URL, or `file://` URI with `--allowed-local-media-path`). Local files fold `mtime_ns` and `size` into cache keys to automatically reload on-disk edits; HTTP URLs and base64 URIs remain cached by string locator. |
+| `ref_audio` | string | null | Reference audio (HTTP URL, base64 data URL, or `file://` URI with `--allowed-local-media-path`) |
 | `ref_text` | string | null | Transcript of reference audio |
 | `x_vector_only_mode` | bool | null | Use speaker embedding only (no ICL) |

@@ -141,20 +141,7 @@ The response shape depends on the streaming parameters:

 **Non-streaming (default).** With `stream=false` and no `stream_format`, returns the
 complete clip as binary audio data with an appropriate `Content-Type` header (e.g.
-`audio/wav`). Because the raw-bytes body has no JSON carrier, successful
-non-streaming responses from non-diffusion speech servers report usage through
-response headers:
-
-| Header | Description |
-| --- | --- |
-| `x-vllm-omni-input-tokens` | Total input tokens (`text_tokens` + `audio_tokens`). |
-| `x-vllm-omni-output-tokens` | Generated codec/audio tokens. |
-| `x-vllm-omni-total-tokens` | `input_tokens` + `output_tokens`. |
-| `x-vllm-omni-input-text-tokens` | Tokens from the synthesized text (`input` plus `instructions`). |
-| `x-vllm-omni-input-audio-tokens` | Reference-audio codec frames, non-zero only for in-context voice cloning. |
-
-Diffusion-mode speech servers route through a separate response path and do not
-emit these headers.
+`audio/wav`). The raw-bytes body has no JSON carrier, so no `usage` is reported.

 **Raw audio stream** (`stream_format="audio"`). Streams raw audio bytes (PCM or
 WAV) as they are decoded.
@@ -688,7 +675,7 @@ for result in response.json()["results"]:
 |-----------|--------|---------|-------------|
 | `tts_batch_max_items` | engine kwarg | 32 | Maximum number of items per batch request |

-All items are fanned out to `generate()` concurrently. The engine's stage worker automatically batches them up to the configured `max_num_seqs` and queues the rest — no client-side throttling needed.
+All items are fanned out to `generate()` concurrently. The engine's stage worker automatically batches them up to the configured `max_batch_size` and queues the rest — no client-side throttling needed.

 For best throughput, set both stages' `max_num_seqs` above 1 via `--stage-overrides`. On the current Qwen3-TTS CustomVoice benchmark, stage 1 performed best at `max_num_seqs: 10`:

@@ -10,7 +10,7 @@ Each server instance runs a single model specified at startup with `vllm serve <

 ```bash
 vllm serve Qwen/Qwen3-Omni-30B-A3B-Instruct \
-    --deploy-config vllm_omni/deploy/qwen3_omni_moe.yaml \
+    --deploy-config vllm_omni/deploy/qwen3_omni.yaml \
    --omni \
    --port 8000 \
    --trust-remote-code
@@ -161,29 +161,11 @@ are not implemented yet. Models may expose additional V2V controls through
 `extra_params`. For example, Cosmos3 supports
 `condition_frame_indexes_vision` and `condition_video_keep` to select which
 decoded reference frames are used as clean conditioning. Cosmos3 transfer mode
-also accepts `edge`, `blur`, `depth`, `seg`, or `wsm` control hints. Each hint
-may specify its own `control_path` and `control_weight`. Request-level transfer
-options include
-`control_guidance`, `control_guidance_interval`,
-`emphasize_control_in_prompt`, `num_video_frames_per_chunk`,
-`num_conditional_frames`, `show_control_condition`, and `show_input`. Transfer
-uses its transfer-specific system prompt and, by default, appends a
-control-adherence directive to the positive prompt. It adds duration/FPS and
-resolution metadata to both CFG branches but does not add a negative prompt
-automatically. The Cosmos3 recipe includes an optional reference negative
-prompt and shows how to pass it. Set `emphasize_control_in_prompt`,
-`use_duration_template`, or `use_resolution_template` to `false` to disable the
-corresponding addition. `negative_metadata_mode` accepts `same`, `inverse`, or
-`none` and defaults to `same` for transfer. See the Cosmos3 recipe for complete
-examples.
-
-HTTP redirects for `image_reference.image_url` follow vLLM's
-`VLLM_MEDIA_URL_ALLOW_REDIRECTS` setting. Before starting the server, set it to
-`1` (the default) to allow redirects or `0` to reject them. A redirect target
-can differ from the original host, and vLLM-Omni does not yet fully implement
-upstream vLLM's media URL allowlist protection. Deployments should therefore
-treat remote media URLs as untrusted and choose this setting as part of their
-URL access policy.
+also accepts `edge`, `blur`, `depth`, `seg`, or `wsm` control hints plus
+transfer options such as `control_path`, `control_guidance`,
+`control_guidance_interval`, `num_video_frames_per_chunk`,
+`num_conditional_frames`, `show_control_condition`, and `show_input`; see the
+Cosmos3 recipe for complete examples.

 ### Speech-to-Video

@@ -20,7 +20,6 @@ For the internal selector, registry, and platform contract, see
 | Install and use SageAttention 2.2 or SageAttention3 | [SageAttention](attention_backends/sage.md) |
 | Match training or rollout kernels loaded from Hugging Face | [Hugging Face Hub Backends](attention_backends/huggingface_hub.md) |
 | Use block-sparse video attention on Ascend NPU | [RainFusion](attention_backends/rainfusion.md) |
-| Use FastVideo VSA with FastWan2.2-TI2V-5B on CUDA | [FastVideo VSA](attention_backends/fastvideo_vsa.md) |

 ## Backend options

@@ -36,7 +35,6 @@ For the internal selector, registry, and platform contract, see
 | `FLASH_ATTN_HUB` | Hub kernel | FlashAttention 2 from Hugging Face `kernels` | [Hugging Face Hub Backends](attention_backends/huggingface_hub.md) |
 | `FLASH_ATTN_3_HUB` | Hub kernel | FlashAttention 3 from Hugging Face `kernels` on Hopper or newer | [Hugging Face Hub Backends](attention_backends/huggingface_hub.md) |
 | `RAINFUSION_ATTN` | Block sparse | MindIE-SD RainFusion video attention on Ascend NPU | [RainFusion](attention_backends/rainfusion.md) |
-| `FASTVIDEO_VSA` | Block sparse | FastVideo variable sparse self-attention for FastWan2.2-TI2V-5B on CUDA | [FastVideo VSA](attention_backends/fastvideo_vsa.md) |

 ## Configuration

@@ -107,7 +105,6 @@ Backend-specific typed blocks are documented with their consumers:
  and [TRTLLM SAGE](attention_backends/trtllm.md#sage-quantization).
 - `skip_softmax`: [TRTLLM Skip-Softmax](attention_backends/trtllm.md#skip-softmax).
 - `block_sparse`: [RainFusion](attention_backends/rainfusion.md#configuration).
- `fastvideo_vsa_topk`: [FastVideo VSA](attention_backends/fastvideo_vsa.md#choose-top-k).

 ## Platform defaults

@@ -1,125 +0,0 @@
-# FastVideo VSA
-
-FastVideo Variable Sparse Attention (VSA) accelerates the `FastVideo/FastWan2.2-TI2V-5B-Diffusers` model's
-self-attention by partitioning the post-patch latent grid into spatiotemporal
-blocks. For every query block, VSA scores the key/value blocks and computes
-attention only against the selected top-k blocks.
-
-The supported checkpoint provides both text-to-video and image-to-video modes through `Wan22Pipeline`; the separate Wan I2V-14B, S2V, and VACE pipelines are outside this backend's supported scope.
-
-VSA is a CUDA-only, explicitly selected backend. It requires the
-`fastvideo-kernel` package and currently supports non-causal self-attention
-with equal query and key/value sequence lengths. Unsupported shapes, masks,
-dtypes, sequence-parallel execution, or kernel failures fall back to
-`TORCH_SDPA` and emit a warning with the reason.
-
-## Enable the backend
-
-For online serving, select the backend with the existing attention backend
-flag. Use `--fastvideo-vsa-topk` to set the number of key/value blocks retained
-for every query block:
-
-```bash
-vllm-omni serve <model> \
-  --diffusion-attention-backend FASTVIDEO_VSA \
-  --fastvideo-vsa-topk 64
-```
-
-The backwards-compatible environment variable selects the backend with the
-default `topk=64`:
-
-```bash
-export DIFFUSION_ATTENTION_BACKEND=FASTVIDEO_VSA
-vllm-omni serve <model>
-```
-
-To tune top-k, pass the CLI backend and top-k flags together as shown above,
-or use the equivalent structured configuration:
-
-```bash
-vllm-omni serve <model> \
-  --diffusion-attention-config \
-  '{"default":{"backend":"FASTVIDEO_VSA","fastvideo_vsa_topk":64}}'
-```
-
-Do not combine `--diffusion-attention-backend` with an explicit
-`diffusion_attention_config.default.backend`. The top-k value must be positive
-and is valid only when the default backend is `FASTVIDEO_VSA`.
-
-For a deploy YAML stage, use either the shorthand fields:
-
-```yaml
-stages:
-  - stage_id: 0
-    diffusion_attention_backend: FASTVIDEO_VSA
-    fastvideo_vsa_topk: 64
-```
-
-or the structured configuration:
-
-```yaml
-stages:
-  - stage_id: 0
-    diffusion_attention_config:
-      default:
-        backend: FASTVIDEO_VSA
-        fastvideo_vsa_topk: 64
-```
-
-## Choose top-k
-
-At runtime the backend logs the sequence shape and derived block count:
-
-```text
-FASTVIDEO_VSA routing: seq_len=27280, dit_seq_shape=(31, 22, 40),
-block_size=(4, 8, 8), num_blocks=120, topk=64, keep_ratio=53.3%,
-checkpoint_mode=native, route=VSA
-```
-
-Use `num_blocks` as the upper bound when tuning top-k. Top-k is the number of
-key/value blocks retained for each query block, not the number of tokens or
-the total number of blocks processed by the layer.
-
- A smaller top-k increases sparsity and may reduce attention computation, but
-  it can remove relevant blocks and reduce visual quality or temporal
-  consistency. Routing and padding overhead can also make a smaller value
-  slower for some shapes.
- A larger top-k retains more context and generally approaches dense-attention
-  quality, but reduces the potential speedup and increases memory traffic.
- `topk > num_blocks` is invalid for the runtime shape and falls back to SDPA.
- For a native checkpoint, `topk == num_blocks` routes to SDPA because scoring
-  every block provides no sparsity benefit.
- For a FastVideo DMD checkpoint, `topk == num_blocks` stays on the VSA
-  all-block path so the checkpoint keeps its trained compensation semantics.
-
-There is no universally optimal value. Resolution, frame count, GPU, kernel
-version, and checkpoint all affect both quality and latency. Start from the
-logged `num_blocks`, test several keep ratios on the target workload, and
-compare output quality against the same checkpoint running dense attention.
-
-## Checkpoint behavior
-
-The backend does not expose a user-selectable gate mode. Wan checkpoints that
-contain learned `to_gate_compress` weights use that projection automatically.
-When those weights are absent, the unused projection is removed and VSA uses
-the sparse branch without learned compensation.
-
-FastVideo DMD checkpoints use their fixed distilled timestep schedule. Native
-Wan checkpoints keep their normal scheduler and inference-step configuration;
-selecting VSA does not turn a native checkpoint into a distilled model.
-
-## Verify routing and fallback
-
-Check the startup and first-forward logs instead of assuming that selecting
-the backend guarantees sparse execution:
-
- `route=VSA` means top-k block selection is active.
- `route=VSA_ALL_BLOCKS` means the FastVideo DMD checkpoint retained all
-  blocks through the VSA kernel.
- `route=SDPA` or `FASTVIDEO_VSA falling back to SDPA: ...` means dense SDPA
-  executed; the warning includes the reason.
-
-The current kernel requires CUDA tensors in FP16 or BF16, 256-token blocks,
-standard `head_size**-0.5` scaling, equal Q/K/V head counts, no attention mask,
-and no active sequence-parallel context. NPU and XPU paths do not execute the
-FastVideo VSA CUDA kernel.
@@ -49,6 +49,7 @@ higher-priority strategy is selected.
 | StableDiffusion3Pipeline | `stabilityai/stable-diffusion-3.5-medium` | `SD3Transformer2DModel` | — | yes | — | `transformer_blocks` |
 | Wan22I2VPipeline | `Wan-AI/Wan2.2-I2V-A14B-Diffusers` | `WanTransformer3DModel` | yes | yes | — | `blocks` |
 | Wan22Pipeline | `Wan-AI/Wan2.2-T2V-A14B-Diffusers` | `WanTransformer3DModel` | yes | yes | — | `blocks` |
+| SoulXSingerPipeline / SoulXSingerSVCPipeline | `Soul-AILab/SoulX-Singer` | `DiffLlama` | yes | yes | — | `layers` |
 | BagelPipeline | `ByteDance-Seed/BAGEL-7B-MoT` | `Qwen2MoTModel` | — | yes | — | `layers`, customized modules |
 | Cosmos3OmniDiffusersPipeline | `nvidia/Cosmos3-Nano`, `nvidia/Cosmos3-Super` | `Cosmos3VFMTransformer`, `Cosmos3LanguageModel` | yes | yes | yes | `layers`, `gen_layers` |

@@ -101,16 +101,8 @@ set `DIFFUSION_ATTENTION_BACKEND=TORCH_SDPA` or configure
 `--max-num-seqs >1`. See the
 [HunyuanImage-3.0 recipe](https://github.com/vllm-project/vllm-omni/blob/main/recipes/Tencent/HunyuanImage-3.0-Instruct.md)
 for its validated configuration. Helios supports single-request step execution only: use
-`--step-execution --max-num-seqs 1` for Helios. MiniMax H3 supports step-wise
-continuous batching by packing co-batched requests into one sequence that keeps
-a separate attention document per request; that layout needs a backend which
-honors the packed `cu_seqlens` metadata, so run it with
-`--diffusion-attention-backend FLASH_ATTN` (other backends stay correct but
-fall back to one transformer forward per request). Batching H3 does not improve
-its throughput — see the measured numbers in the
-[MiniMax-H3 recipe](https://github.com/vllm-project/vllm-omni/blob/main/recipes/MiniMaxAI/MiniMax-H3.md)
-— so keep `--max-num-seqs 1` unless you need step-level scheduling. Consult the
-selected pipeline's documentation and source for the latest support status.
+`--step-execution --max-num-seqs 1` for Helios. Consult the selected pipeline's
+documentation and source for the latest support status.

 ## Streaming Output

@@ -215,16 +207,18 @@ outputs = omni.generate(
 )
 ```

-## Deploy Configuration
+## Stage Configuration

 Use the equivalent engine arguments in a deployment YAML:

 ```yaml
-stages:
+stage_args:
  - stage_id: 0
-    step_execution: false
-    max_num_seqs: 4
-    request_batch_max_wait_ms: 20
+    stage_type: diffusion
+    engine_args:
+      step_execution: false
+      max_num_seqs: 4
+      request_batch_max_wait_ms: 20
 ```

 For step execution, set `step_execution: true` and remove
@@ -5,7 +5,11 @@ deployments. With AllGather enabled, each rank stores roughly `1 / dp_size` of
 the host weights and reconstructs each layer at runtime. Without AllGather,
 each rank streams a complete block independently. Compatible TP1 deployments
 can share checkpoint-backed host pages among processes on the same node;
-otherwise DLO streams the ordinary loader's rank-local tensors.
+otherwise DLO streams the ordinary loader's rank-local tensors. The optional
+runtime-weight cache extends node-local sharing to final ordinary-loader
+layouts, including matching TP coordinates across independent engines. On
+CUDA, an explicit registration budget can make those shared mappings directly
+H2D-copyable and avoid recurrent mmap-to-pinned host packing.

 See the [DLO feature design](../../../design/feature/offloader/distributed_layerwise_offload.md)
 for the implementation contract and compatibility matrix.
@@ -21,8 +25,10 @@ AllGather:       [AG N+1]           [AG N+2]
 Slots:           slot 0: Layer N    slot 1: Layer N+1
 ```

-AllGather communicates only request-independent weight shards, so data-
-parallel ranks may process different requests concurrently.
+AllGather communicates request-independent weight shards, but every member of
+the transfer group must request the same next block in the same collective
+order. A synchronized DP wave may contain different prompts only when those
+requests follow the same denoising and block-execution path.

 ## Usage

@@ -36,8 +42,16 @@ vllm serve /path/to/model --omni \
 vllm serve /path/to/model --omni \
  --enable-distributed-layerwise-offload \
  --data-parallel-size 4 \
+  --dlo-no-use-allgather
+
+# Independently scheduled replicas sharing final runtime weights on one node
+vllm serve /path/to/model --omni \
+  --enable-distributed-layerwise-offload \
+  --tensor-parallel-size 2 \
  --dlo-no-use-allgather \
-  --dlo-offload-components '{"text_encoder": false}'
+  --dlo-enable-runtime-cache \
+  --dlo-runtime-cache-dir /var/cache/vllm-omni/dlo-runtime-weights \
+  --dlo-runtime-cache-pin-limit-gib 80

 # Sequence parallel deployment
 vllm serve /path/to/model --omni \
@@ -51,8 +65,10 @@ from vllm_omni import Omni
 omni = Omni(
    model="/path/to/model",
    enable_distributed_layerwise_offload=True,
-    dlo_use_allgather=True,
-    dlo_offload_components={"text_encoder": False},
+    dlo_use_allgather=False,
+    dlo_enable_runtime_cache=True,
+    dlo_runtime_cache_dir="/var/cache/vllm-omni/dlo-runtime-weights",
+    dlo_runtime_cache_pin_limit_gib=80,
 )
 ```

@@ -64,11 +80,11 @@ omni = Omni(
 | `--data-parallel-size N` | DP ranks and AllGather weight-sharding group | `1` |
 | `--dlo-use-allgather` | Shard host weights and reconstruct with AllGather | `true` |
 | `--dlo-no-use-allgather` | Stream complete rank-local blocks without a DLO weight collective | `false` |
+| `--dlo-enable-runtime-cache` | Normalize final ordinary-loader DiT weights into a node-local mmap cache; requires no-AllGather | `false` |
+| `--dlo-runtime-cache-dir PATH` | Shared local-disk cache root | `~/.cache/vllm-omni/dlo-runtime-weights` |
+| `--dlo-runtime-cache-lock-timeout SECONDS` | Maximum wait for another process publishing the same layout | `600` |
+| `--dlo-runtime-cache-pin-limit-gib GIB` | Per-worker limit for registering the complete read-only runtime-cache mapping for direct H2D; zero keeps bounded host staging | `0` |
 | `--dlo-resident-layers N` | Keep N leading main-DiT blocks on device; requires no-AllGather and model-declared resident paths | `0` |
-| `--dlo-offload-components JSON` | Permit or disable offload for discovered encoder/VAE components | `{}` |
-| `--host-weight-runtime-mode {disabled,preferred,required}` | HWR policy: no interaction, populate on a miss, or require an exact hit | `disabled` |
-| `--host-weight-runtime-root PATH` | Writable node-local HWR store shared by workers in one storage domain; required for `preferred` and `required` | unset |
-| `--dlo-host-registration-limit-gib N` | Optional per-worker ceiling for registering an HWR mmap; zero adds no ceiling | `0` |

 ## Host-weight loading

@@ -84,6 +100,50 @@ DLO may still consume those TP-local tensors, but this is a compatibility path:
 it does not share checkpoint-backed runtime weights across DP replicas and
 provides no shared-mmap host-memory guarantee.

+When `--dlo-enable-runtime-cache` is set with no-AllGather, ordinary loading
+gains a second storage opportunity. Every rank completes loader callbacks,
+post-load processing, validation, and calibration. It then hashes the final
+CPU DiT parameters and persistent buffers. One process per equivalent runtime
+layout publishes sharded safetensors plus a checksummed manifest; peers
+validate and mmap the same files. DLO replaces only tensor storage, preserves
+the final `Parameter` objects, and releases the private allocator-backed copies
+before installing its streaming hooks.
+
+A positive `--dlo-runtime-cache-pin-limit-gib` deliberately selects this final
+runtime layout even when a direct TP1 checkpoint plan is available. Raw
+checkpoint mappings may require deferred loader transforms such as grouped-QKV
+reordering; registering them would still leave recurrent host work. Publishing
+the fully transformed layout once makes every streamed source directly
+copyable.
+
+The runtime layout identity excludes DP rank and SP rank. It includes TP world
+size/rank and conservative SP implementation/world-size guards. Therefore two
+independent `TP=2` engines normally create two entries: both TP0 workers map
+one entry and both TP1 workers map the other. Cache sharing does not create a
+process group or an inference-time collective.
+
+With a zero registration budget, cached tensors remain pageable mmap views.
+DLO packs each streamed block into one of two bounded pinned host slots before
+the asynchronous H2D copy. This lowers steady-state PSS but adds recurrent
+host-to-host copies; competing TP ranks or engines can turn DDR contention and
+staging skew into collective wait time.
+
+With a positive budget on CUDA, DLO instead attempts to register the complete
+page-aligned cache mapping as read-only pinned host memory. Registration is
+all-or-nothing: the total mapped range must fit the per-worker budget, and any
+CUDA registration or verification failure rolls back partial registrations and
+uses the bounded staging path. If CUDA cannot roll back a partial registration,
+worker initialization aborts instead of unmapping memory that CUDA may still
+own. On success, each immutable tensor view is copied directly into the
+existing rotating device buffers on the H2D stream, so no private host staging
+slots are allocated.
+
+CUDA registration is process-local, but it does not clone file contents. The
+same physical page-cache pages remain shared among equivalent workers; each
+worker does, however, hold its own registration reference and must satisfy the
+host's page-locking limits. Shutdown synchronizes outstanding GPU work,
+unregisters every range, and only then closes the mmap handles.
+
 The mmap plan skips only dedicated DiT weight sources. Other component sources,
 such as a text encoder loaded through the shared diffusion loader, continue to
 use their ordinary component loader. A checkpoint source that mixes DiT and
@@ -110,123 +170,33 @@ process.
 When the effective DLO group size is one, `dlo_use_allgather=True` does not
 perform a collective and uses the same rank-local transfer behavior.

-### Final-layout Host Weight Runtime
+## Runtime-cache lifecycle

-HWR is an opt-in startup optimization for models that declare the final-layout
-BF16 restore contract. Use it only with no-AllGather DLO:
+Runtime-cache publication uses a per-layout POSIX file lock, a temporary
+directory on the same filesystem, file and final-tensor SHA-256 validation,
+`fsync`, and an atomic directory rename. A crashed writer releases its kernel
+lock; the next writer removes only that layout's stale temporary directories
+while holding the lock. Lock timeout, unsupported layout, insufficient disk,
+or validation failure keeps the already-valid ordinary tensors.

-```bash
-vllm serve /path/to/model --omni \
-  --enable-distributed-layerwise-offload \
-  --dlo-no-use-allgather \
-  --host-weight-runtime-mode preferred \
-  --host-weight-runtime-root /var/cache/vllm-omni/hwr
-```
+The cache root is deliberately independent of `VLLM_CACHE_ROOT`, because
+vLLM-Omni may isolate that variable between stage replicas. All consumers that
+should share must receive the same `--dlo-runtime-cache-dir` on a local,
+disk-backed filesystem. Do not place the cache on tmpfs when the goal is lower
+host-memory PSS, and do not use a cross-node directory in this version.

-#### Choosing a mode
+There is no automatic eviction. Budget roughly one final DiT copy per distinct
+TP coordinate, dtype/layout, and model version, plus temporary space while an
+entry is published. Operators may remove entries or the complete cache root
+only after all workers using its mmap files have stopped. The feature is
+opt-in for this reason.

-| Mode | Exact local artifact hit | Miss or recoverable artifact/store problem | Intended use |
-| --- | --- | --- | --- |
-| `disabled` | HWR is not consulted | Use the existing checkpoint-mmap or ordinary-loader path | Default compatibility path |
-| `preferred` | Restore the final-layout artifact | Load canonically, serve with those tensors, and attempt to publish an artifact for the next startup | Normal deployment and store population |
-| `required` | Restore the final-layout artifact | Fail startup without canonical DiT fallback or publication | Enforce a pre-populated store in controlled rollouts or CI |
-
-Both enabled modes still fail on non-retryable configuration, identity, or
-compatibility errors. `preferred` is a fallback policy for a cache miss or a
-recoverable cache problem; it does not hide an invalid deployment.
-
-#### Populating a store for `required` mode
-
-`required` is deliberately consume-only. PR2 does not include a separate
-prewarm command, so populate each node-local storage domain with one matching
-`preferred` producer cohort:
-
-1. Choose a persistent, writable root visible to every diffusion worker in the
-   storage domain. Do not use a process-private temporary directory.
-2. Start the deployment with `preferred`, using the exact model revision,
-   dtype, TP size, SP configuration, and other weight-layout settings intended
-   for serving. No inference request is needed; publication happens during
-   model startup. Wait for the engine to become healthy, then shut it down
-   cleanly.
-3. Restart with the same arguments and root, changing only the mode to
-   `required`. A successful startup proves that every worker acquired a valid
-   artifact; a miss, corrupt artifact, or incompatible identity fails startup.
-4. Repeat the population start on every node or storage domain because this
-   store is node-local.
-
-For example:
-
-```bash
-# First startup: canonically load and populate the exact artifacts.
-vllm serve /path/to/model --omni \
-  --enable-distributed-layerwise-offload \
-  --dlo-no-use-allgather \
-  --host-weight-runtime-mode preferred \
-  --host-weight-runtime-root /var/cache/vllm-omni/hwr
-
-# After a healthy startup and clean shutdown, enforce cache hits.
-vllm serve /path/to/model --omni \
-  --enable-distributed-layerwise-offload \
-  --dlo-no-use-allgather \
-  --host-weight-runtime-mode required \
-  --host-weight-runtime-root /var/cache/vllm-omni/hwr
-```
-
-Include the same TP and SP layout flags in both commands. DP rank and DP size
-are excluded from artifact identity, so the population and serving DP sizes may
-differ and equivalent DP replicas share artifacts. TP rank is included, so a
-TP-N deployment normally needs N rank-specific artifacts in each storage
-domain; launching the matching TP cohort creates that set. If the model
-revision or layout changes, run `preferred` again for the new identity before
-returning to `required`.
-
-On a cold start, the canonical loader remains authoritative and publishes a
-validated final-layout artifact for later workers. A warm start restores the
-DiT final tensors without ordinary DiT materialization. DLO then attempts to
-register the immutable mapping for direct H2D; if registration is unavailable,
-it streams through the same two bounded host staging slots. The artifact
-identity includes the TP rank/size and SP layout, so TP1, TP2 rank-local shards,
-and distinct SP layouts do not alias one another. Publication failure remains
-separate from a `preferred` serving startup; the next `required` startup
-provides the explicit artifact-availability check.
-
-For local canonical checkpoints, the first eligible worker may hash source
-shards to establish immutable identity. HWR caches those digests in the same
-node-local storage domain and validates file metadata before reuse, so later
-workers normally avoid repeating that read. Cold BF16 publication also hashes
-ordered payloads as they are written and overlaps payload durability work with
-later shards; this changes startup work only, not artifact contents or runtime
-H2D behavior.
-
-#### Registered direct H2D
-
-Registration is attempted automatically only for an eligible warm HWR hit when
-`pin_cpu_memory` is enabled. A successful path is:
-
-```text
-shared read-only HWR mmap -> existing rotating HBM block buffer -> GPU kernel
-```
-
-It removes the recurrent mmap-to-private-staging CPU copy and does not allocate
-the two host staging slots. It does not reduce the H2D payload or make GPU
-kernels access host memory directly.
-
-CUDA requires read-only host-registration capability for the immutable HWR
-mapping. Unsupported capability, a positive registration limit smaller than
-the complete page-aligned mapping, or a safely rolled-back registration error
-falls back to bounded staging. Programmatic configurations can set
-`pin_cpu_memory=False` to disable registration explicitly. A successful
-registration locks the complete mapped range in host memory for that worker's
-lifetime, so use
-`--dlo-host-registration-limit-gib` when an operator-enforced ceiling is
-required.
-
-Shutdown drains H2D work, releases hook/source references, unregisters every
-range, and only then closes the HWR lease. AllGather and direct checkpoint mmap
-retain their existing transfer paths.
-
-When HWR is disabled, DLO is disabled, or AllGather is enabled, the loader does
-not resolve HWR sources or construct its store.
+For direct H2D, set the registration limit above the complete page-aligned
+layout size reported in the worker log. Partial registration is intentionally
+unsupported because mixing direct and staged tensors would complicate buffer
+lifetime and make performance topology-dependent. Registration is CUDA-only;
+an insufficient budget, unsupported runtime, OS/CUDA pinning limit, or
+registration error is reported and falls back to bounded staging.

 ## Declarative topology

@@ -247,25 +217,6 @@ class MyPipeline(nn.Module):
 When no plan exists, discovery falls back to
 `_layerwise_offload_blocks_attrs` and then heuristic attribute lookup.

-## Auxiliary component policy
-
-`dlo_offload_components` follows the same component-map style as diffusion
-quantization. Keys are discovered encoder or VAE paths, values are booleans,
-and `default` is the optional fallback:
-
-```python
-dlo_offload_components = {
-    "text_encoder": False,
-    "default": True,
-}
-```
-
-`True` permits the model's existing DLO behavior for that component. `False`
-keeps the whole component resident, including its child blocks and non-block
-modules. An empty map preserves current behavior. Unknown keys are rejected;
-the map does not control DiT blocks because enabling DLO gives the backend
-ownership of DiT streaming.
-
 ## Data-parallel concurrency

 With `data_parallel_size > 1` and AllGather enabled, the scheduler can process
@@ -275,34 +226,37 @@ must enter each collective.

 ## Limitations

- Direct checkpoint mmap currently requires TP1. TP greater than one is
-  outside the Phase A shared-mmap support scope and falls back before model
-  mutation to the ordinary TP-aware loader. DLO can stream that runtime layout,
-  and eligible no-AllGather configurations may use HWR final-layout artifacts,
-  but direct checkpoint mmap provides no shared-mmap host-memory guarantee for
-  TP greater than one.
+- Direct checkpoint mmap currently requires TP1. TP greater than one falls
+  back to the ordinary TP-aware loader. With the optional runtime cache,
+  equivalent processes at the same TP coordinate can then share that final
+  rank-local layout in no-AllGather mode. A positive registration budget also
+  chooses the final runtime cache at TP1 so deferred checkpoint transforms are
+  not repeated during inference.
 - HSDP plus AllGather is rejected to avoid double sharding. HSDP without
  AllGather has limited end-to-end validation.
- Per-tensor online FP8 linears use the ordinary loader and can run with either
-  DLO transfer path. With AllGather, every rank temporarily materializes the
-  complete FP8 model in host memory before DLO retains only its shard. Other
-  online quantization methods require no-AllGather until their runtime layouts
-  are validated.
+- Online quantization uses the ordinary loader with no-AllGather. It remains
+  incompatible with DLO AllGather and runtime-cache v1. Runtime-cache v1 also
+  rejects other quantized, non-contiguous, aliased/tied, device-only, HSDP,
+  expert-parallel, CFG-parallel, and PP layouts.
 - Resident leading layers require `--dlo-no-use-allgather` and a model
  `OffloadPlan` that declares eligible `resident_dit_paths`.
- Component policy applies only to discovered auxiliary encoders and VAEs;
-  it cannot disable DLO for a DiT.
- MiniMax-H3's encoder TP group is global rather than DP-replica-local. An
-  encoder TP size that spans multiple DP replicas (for example TP4 with
-  DP2/TP2 or DP2/SP2 on four ranks) is not supported for independent-prompt
-  AllGather waves: the current pipeline broadcasts rank 0's conditioning to
-  both replicas. This limitation is independent of the component policy.
 - DP concurrency requires an explicit, identical inference-step count.

-Sharing quantized or otherwise unvalidated transformed layouts through a
-normalized HWR producer is a follow-up design in
-[RFC #6195](https://github.com/vllm-project/vllm-omni/issues/6195), not part of
-the current BF16 final-layout path.
+The runtime cache improves steady-state host PSS, not startup peak: every rank
+loads private weights before remapping, and validation adds full content-hash
+passes. Direct H2D removes recurrent staging but does not change that startup
+contract. Skip-load-on-cache-hit and cache eviction remain follow-up work in
+[RFC #6195](https://github.com/vllm-project/vllm-omni/issues/6195).
+
+Zero-budget staging is also not latency-neutral. In the four-L20X MiniMax-H3
+smoke documented in the L20X runtime-cache matrix in the
+[feature design](../../../design/feature/offloader/distributed_layerwise_offload.md#l20x-runtime-cache-smoke-matrix),
+two independent TP2 engines reduced request-time host PSS by 36.6% with the
+cache, but recurrent mmap-to-pinned staging reduced combined throughput by
+69.3%. The registered path recovered near-private per-engine latency while
+retaining the shared-memory benefit; a matched TP1 run improved mean wave
+latency from 33.87 seconds to 4.88 seconds with byte-identical outputs. See the
+feature design for the full smoke-test caveats and metrics.

 See the [Cosmos3 DistOffload recipe](https://github.com/vllm-project/vllm-omni/blob/main/recipes/cosmos3/Cosmos3-DistOffload.md)
 for an end-to-end example.
@@ -152,8 +152,7 @@ In `DiffusionParallelConfig`:
 **Constraints:**

 - `hsdp_replicate_size × hsdp_shard_size == world_size`
- HSDP cannot be used with Tensor Parallelism, ordinary Data Parallelism,
-  Pipeline Parallelism, or Expert Parallelism.
+- HSDP cannot be used with Tensor Parallelism (`tensor_parallel_size` must be 1)

 ---

@@ -24,7 +24,7 @@ stages:

 For an experimental whole-transformer compile scope, set
 `--diffusion-compile-granularity full` or use
-`diffusion_compile_granularity: full` in the deploy configuration. Full scope may
+`diffusion_compile_granularity: full` in the stage configuration. Full scope may
 still contain graph breaks; it does not force one graph. It is rejected when
 HSDP, sequence parallelism, CPU offload, or layerwise offload is enabled. Use
 regional scope with those features.
@@ -124,12 +124,12 @@ The following tables show which models support each feature:
 | **FLUX.2-dev**           |     ✅     |     ✅      |           ✅           |       ✅        |         ✅         |          ❌          |   ✅    |             ✅             |          ✅           |       ❌        |        ❌         |
 | **GLM-Image**            |     ❌     |     ❌      |           ❌           |       ✅        |         ✅         |          ❌          |   ✅    |             ❌             |          ❌           |       ❌        |        ❌         |
 | **Hidream-I1-Full**        |     ❌     |     ❌      |           ❌           |       ❌        |         ✅         |          ❌          |   ❌    |             ❌             |          ❌           |       ❌        |        ❌         |
-| **HiDream-O1-Image**     |     ❌     |     ✅      |           ❌           |       ❌        |         ✅         |          ❌          |   ❌    |             ❌             |          ❌           |       ❌        |        ❌         |
 | **HunyuanImage3**        |     ❌     |     ✅      |           ❌           |       ❌        |         ✅         |          ❌          |   ❌    |             ❌             |          ❌           |       ✅        |        ✅*        |
 | **Krea 2**               |     ❌     |     ✅      |           ❌           |       ❌        |         ❌         |          ❌          |   ✅    |             ✅             |      ✅ (decode)      |       ❌        |        ❌         |
 | **LongCat-Image**        |     ✅     |     ✅      |           ✅           |       ✅        |         ✅         |          ❌          |   ❌    |             ✅             |          ❌           |       ❌        |        ❌         |
 | **LongCat-Image-Edit**   |     ✅     |     ✅      |           ✅           |       ✅        |         ✅         |          ❌          |   ❌    |             ✅             |          ❌           |       ❌        |        ❌         |
 | **MagiHuman**            |     ❌     |     ❌      |           ❌           |       ❓        |         ✅         |          ❌          |   ❌    |             ✅             |          ❌           |       ❌        |        ❌         |
+| **MammothModa2(T2I)**    |     ❌     |     ❌      |           ❌           |       ❌        |         ❌         |          ❌          |   ❌    |             ❌             |          ❌           |       ❌        |        ❌         |
 | **Nextstep_1(T2I)**      |     ❓     |     ❓      |           ❌           |       ✅        |         ✅         |          ❌          |   ❌    |             ✅             |          ❌           |       ❌        |        ❌         |
 | **OmniGen2**             |     ❌     |     ✅      |           ✅           |       ❌        |         ✅         |          ❌          |   ❌    |             ❌             |          ❌           |       ❌        |        ❌         |
 | **Ovis-Image**           |     ❌     |     ✅      |           ❌           |       ✅        |         ❌         |          ❌          |   ❌    |             ✅             |          ❌           |       ❌        |        ❌         |
@@ -162,29 +162,20 @@ The following tables show which models support each feature:
 | **LTX-2**                    |     ❌     |     ✅      |           ✅           |       ✅        |         ✅         |         ❌         |   ✅    |             ✅             |      ✅ (decode)      |       ❌        |        ❌         |
 | **LTX-2.3**                  |     ❌     |     ✅      |           ✅           |       ✅        |         ✅         |         ❌         |   ✅    |             ✅             |      ✅ (decode)      |       ❌        |        ❌         |
 | **LTX-2.5**                  |     ❌     | ❓ (one-stage) | ❓ (Ulysses only) | ✅ (Full only) |         ❓         |         ❌         |   ✅    |             ✅             |      ✅ (decode)      |    ❓ (FP8)     |        ❌         |
-| **SANA-Video-2B T2V I2V**   |     ❓     |     ❓      |           ❓           |       ❓        |         ❓         |         ❓         |   ❓    |             ❓             |          ❓           |       ❓        |        ❌         |
 | **Helios**                   |     ❌     |     ✅      |           ✅           |       ✅        |         ✅         |         ❌         |   ✅    |             ✅             |          ❌           |       ❌        |        ✅*        |
 | **HunyuanVideo-1.5 T2V I2V** |     ❌     |     ✅      |           ✅           |       ✅        |         ✅         |         ❌         |   ✅    |             ✅             |  ✅ (encode/decode)   |       ✅        |        ❌         |
 | **DreamID-Omni**             |     ❌     |     ❌      |           ❌           |       ✅        |         ❌         |         ❌         |   ✅    |             ✅             |          ❌           |       ❌        |        ❌         |
 | **Cosmos3**                  |     ❌     |     ✅      |           ✅           |       ✅        |         ✅         |         ❌         |   ✅    |             ✅             |  ✅ (encode/decode)   |       ✅        |        ❌         |
 | **LongCat-Video-Avatar-1.5** |     ❌     |     ❌      |           ❌           |       ❌        |         ❌         |         ❌         |   ❌    |             ❌             |          ❌           |       ❌        |        ❌         |
 | **MiniMax-H3**               | ✅ (FL2VA) |     ✅      |           ✅           |       ❌        |       ✅ (DiT/TE)  |         ❌         |   ✅    |             ✅             |       ✅ (tile)       |      ✅ (DiT)      |        ❌         |
-| **SANA-WM**                  |     ❌     |     ❌      |          ❌<sup>5</sup> |       ✅        |         ✅         |         ❌         |   ❌    |             ❌             |          ❌           |       ❌        |        ❌         |
-
-> Notes:
-> 5. SANA-WM cannot support sequence parallelism: its bidirectional gated delta
->    recurrence carries state across frames, so a rank cannot denoise a slice of
->    the token sequence in isolation. Doing so would need a distributed scan or
->    an all-gather before every GDN block. The remaining ❌ columns are simply
->    unvalidated on this model, not known-broken.

 > **Step execution note:** Helios supports single-request step execution only;
 > use `max_num_seqs=1`.

 **Frame Interpolation Support**

- **Supported**: Wan2.2 text-to-video, image-to-video, and TI2V pipelines; SANA-Video-2B native text-to-video and image-to-video pipelines
- **Not supported**: Wan2.1-VACE, LTX-2, LTX-2.3, LTX-2.5, Helios, HunyuanVideo-1.5, DreamID-Omni, SANA-WM; SANA-Video-2B Diffusers-adapter text-to-video and image-to-video pipelines
+- **Supported**: Wan2.2 text-to-video, image-to-video, and TI2V pipelines
+- **Not supported**: Wan2.1-VACE, LTX-2, LTX-2.3, LTX-2.5, Helios, HunyuanVideo-1.5, DreamID-Omni

 ### AudioGen

@@ -4,8 +4,8 @@ Source <https://github.com/vllm-project/vllm-omni/tree/main/examples/offline_inf


 This example demonstrates how to generate videos from images using Wan2.2,
-LTX-2, HunyuanVideo-1.5, and SANA-Video Image-to-Video models with
-vLLM-Omni's offline inference API.
+LTX-2, and HunyuanVideo-1.5 Image-to-Video models with vLLM-Omni's
+offline inference API.

 ## Local CLI Usage

@@ -66,49 +66,9 @@ python image_to_video.py \
 See the [LTX-2 recipe](../../../../recipes/LTX/LTX-2.md) for all checkpoints,
 pipeline selection, T2V, defaults, and advanced options.

-### SANA-Video-2B
-
-SANA checkpoints identify their upstream T2V pipeline in `model_index.json`.
-Select the native I2V implementation explicitly:
-
-```bash
-python image_to_video.py \
-  --model Efficient-Large-Model/SANA-Video_2B_480p_diffusers \
-  --model-class-name SanaImageToVideoPipeline \
-  --image cherry_blossom.jpg \
-  --prompt "Cherry blossoms sway in the breeze as petals drift past the camera." \
-  --negative-prompt "blurry, low quality, temporal artifacts" \
-  --height 480 \
-  --width 832 \
-  --num-frames 81 \
-  --num-inference-steps 50 \
-  --guidance-scale 6.0 \
-  --extra-body '{"motion_score": 30}' \
-  --fps 16 \
-  --seed 42 \
-  --output sana_video_i2v_480p.mp4
-```
-
-For the 720p checkpoint, use
-`Efficient-Large-Model/SANA-Video_2B_720p_diffusers` with
-`--height 704 --width 1280`. The native I2V path supports both checkpoint
-variants: the 480p checkpoint uses the Wan VAE, while the 720p checkpoint uses
-the LTX-2 Video VAE.
-
-For SANA-Video, 81 frames at 16 FPS is the standard checkpoint request
-(approximately five seconds), not minute-scale long-video generation.
-Minute-scale SANA generation requires the separate LongSANA/LongLive
-autoregressive workflow, which this pipeline does not implement.
-
-See the [SANA-Video recipe](../../../../recipes/NVIDIA/SANA-Video-2B.md) for
-online serving, backend boundaries, and the tested hardware profile.
-
 Key arguments:

- `--model`: Model ID or local path (for example Wan I2V/TI2V, LTX-2, or
-  SANA-Video).
- `--model-class-name`: Explicit pipeline override. SANA-Video I2V requires
-  `SanaImageToVideoPipeline`.
+- `--model`: Model ID (I2V-A14B for MoE, TI2V-5B for unified T2V+I2V, or LTX-2).
 - `--image`: Path to input image (required).
 - `--prompt`: Text description of desired motion/animation.
 - `--height/--width`: Output resolution (auto-calculated from image if not set).
@@ -22,7 +22,7 @@ MiMo-Audio provides multiple task variants for audio understanding and generatio

 ## Setup

-See the [pipeline and deploy configuration documentation](https://docs.vllm.ai/projects/vllm-omni/en/latest/configuration/stage_configs/) to configure memory allocation for your hardware.
+Please refer to the [stage configuration documentation](https://docs.vllm.ai/projects/vllm-omni/en/latest/configuration/stage_configs/) to configure memory allocation appropriately for your hardware setup.

 ### Environment Variables

@@ -188,7 +188,7 @@ Note: This task uses hardcoded message lists in the script.

 ### Other

- If the model or deploy config fails to load, check the [pipeline and deploy configuration documentation](https://docs.vllm.ai/projects/vllm-omni/en/latest/configuration/stage_configs/) for memory and GPU settings.
+- If the model or stage config fails to load, check [stage configuration documentation](https://docs.vllm.ai/projects/vllm-omni/en/latest/configuration/stage_configs/) for memory and GPU settings.
 - For errors when reading/writing WAV (e.g. unsupported format), ensure input files are standard WAV/MP3 and that `soundfile` is linked to a working libsndfile (see above).

 ## Notes
@@ -4,7 +4,7 @@ Source <https://github.com/vllm-project/vllm-omni/tree/main/examples/offline_inf


 ## Setup
-See the [pipeline and deploy configuration documentation](https://docs.vllm.ai/projects/vllm-omni/en/latest/configuration/stage_configs/) to configure memory allocation for your hardware.
+Please refer to the [stage configuration documentation](https://docs.vllm.ai/projects/vllm-omni/en/latest/configuration/stage_configs/) to configure memory allocation appropriately for your hardware setup.

 ## Run examples

@@ -4,8 +4,7 @@ Source <https://github.com/vllm-project/vllm-omni/tree/main/examples/offline_inf


 ## Setup
-Use `--deploy-config` for deployment overrides such as stage memory allocation.
-See the [pipeline and deploy configuration documentation](https://docs.vllm.ai/projects/vllm-omni/en/latest/configuration/stage_configs/).
+Please refer to the [stage configuration documentation](https://docs.vllm.ai/projects/vllm-omni/en/latest/configuration/stage_configs/) to configure memory allocation appropriately for your hardware setup.

 ## Run examples

@@ -74,8 +73,8 @@ For true stage-level concurrency -- where downstream stages (Talker, Code2Wav)
 start **before** the upstream stage (Thinker) finishes -- use the async_chunk
 example. This requires:

-1. A deploy YAML with ``async_chunk: true`` (for example, an overlay based on
-   ``vllm_omni/deploy/qwen3_omni_moe.yaml``).
+1. A stage config YAML with ``async_chunk: true`` (e.g.
+   ``qwen3_omni_moe_async_chunk.yaml``).
 2. Hardware that matches the config (e.g. 2x H100 for the default 3-stage
   config).

@@ -101,11 +100,11 @@ bash run_multiple_prompts_async_chunk.sh --max-in-flight 4
 python end2end_async_chunk.py --query-type text --modalities text
 ```

-#### Custom deploy config
+#### Custom stage config
 ```bash
 python end2end_async_chunk.py \
    --query-type use_audio \
-    --deploy-config /path/to/your_async_chunk.yaml
+    --stage-configs-path /path/to/your_async_chunk.yaml
 ```

 > **Note**: The synchronous ``end2end.py`` (using ``Omni``) is still the
@@ -69,7 +69,7 @@ python examples/offline_inference/text_to_speech/voxcpm2/end2end.py \

 ### Notes
 - Output: 48 kHz mono WAV.
- Deploy config: `vllm_omni/deploy/voxcpm2.yaml` (default).
+- Stage config: `vllm_omni/model_executor/stage_configs/voxcpm2.yaml` (default).

 ---

@@ -152,7 +152,7 @@ python examples/offline_inference/text_to_speech/fish_speech/end2end.py \
    --text "Hello, this is a streaming test." \
    --streaming
 ```
-Streaming requires `async_chunk: true` in the deploy config.
+Streaming requires `async_chunk: true` in the stage config.

 ### Notes
 - Output: 44.1 kHz mono WAV.
@@ -274,7 +274,7 @@ python examples/offline_inference/text_to_speech/qwen3_tts/end2end.py \
    --streaming \
    --output-dir /tmp/out_stream
 ```
-Streaming requires `async_chunk: true` in the deploy config.
+Streaming requires `async_chunk: true` in the stage config.

 ### Batched decoding
 The Code2Wav stage supports batched decoding through the SpeechTokenizer. Configure both stages with `max_num_seqs > 1` via `--stage-overrides` and pass multiple prompts via `--txt-prompts`:
Author	SHA1	Message	Date
Hongsheng Liu	f1abb13958	[Diffusion] Register runtime cache for direct DLO H2D Avoid recurrent mmap-to-pinned packing in no-AllGather DLO by registering transform-complete runtime-cache mappings under an explicit per-worker budget. Copy mapped tensors directly into the rotating device buffers while preserving bounded-staging fallback and ordered shutdown cleanup. Signed-off-by: Hongsheng Liu <liuhongsheng4@huawei.com>	2026-08-17 11:50:32 +08:00
Hongsheng Liu	b732ad2cea	[Diffusion] Document runtime cache hardware tradeoffs Signed-off-by: Hongsheng Liu <liuhongsheng4@huawei.com>	2026-08-17 00:43:06 +08:00
Hongsheng Liu	99347e1ba7	[Diffusion] Tighten runtime cache compatibility guards Signed-off-by: Hongsheng Liu <liuhongsheng4@huawei.com>	2026-08-16 23:26:25 +08:00
Hongsheng Liu	db86a6a078	[Diffusion] Add node-local runtime weight cache for DLO Signed-off-by: Hongsheng Liu <liuhongsheng4@huawei.com>	2026-08-16 23:15:48 +08:00