From 0342fb50bf564ad55e3efb903e667496298c93bb Mon Sep 17 00:00:00 2001 From: Jiajun Li Date: Fri, 24 Jul 2026 06:24:53 +0000 Subject: [PATCH 1/6] Overlay mooncake structured object store module in the CUDA image miles' mooncake rollout-data object store backend needs the structured object store API (FieldSchema, export_ref/import_ref, unified put/get, release_result) that is merged upstream in kvcache-ai/Mooncake #2907, #3013 and #3023 but missing from every released wheel: the v0.3.12 release branch was cut before those merges landed. The API is a single pure-Python module compatible with the C++ core the sglang base image already ships, so fetch that module at a pinned master commit over the installed package instead of rebuilding mooncake from source. The layer import-checks every required symbol so an incomplete overlay fails the image build instead of surfacing at runtime. Verified against mooncake-transfer-engine-cuda13 0.3.11.post1 (the version the current image ships): with the overlaid module, the full put(field_schemas) -> export_ref/import_ref -> get -> release_result -> cleanup_dataproto round-trip passes over tcp against a local mooncake_master. Drop this layer once a mooncake release contains the API. Co-Authored-By: Claude Fable 5 --- docker/Dockerfile | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/docker/Dockerfile b/docker/Dockerfile index 23badbacd5..3127b3ae3f 100644 --- a/docker/Dockerfile +++ b/docker/Dockerfile @@ -172,6 +172,20 @@ RUN cd /sgl-workspace/sglang && \ fi && \ pip install -e "python[all]" --no-deps +# =========================== Mooncake structured object store overlay =========================== + +# miles' mooncake rollout-data backend needs the structured object store API (FieldSchema, +# export_ref/import_ref, unified put/get, release_result) merged upstream in +# kvcache-ai/Mooncake#2907/#3013/#3023 but not present in any released wheel (<= 0.3.12, +# whose release branch was cut before those merges). The API is a single pure-Python module +# compatible with the C++ core the base image already ships, so overlay just that module. +# Drop this layer once a mooncake release contains the API. +ARG MOONCAKE_SOS_COMMIT=4dbe5a4c194669850e9abad61172e9878b245b15 +RUN MOONCAKE_DIR=$(python3 -c "import mooncake, os; print(os.path.dirname(mooncake.__file__))") && \ + curl -fsSL --retry 3 "https://raw.githubusercontent.com/kvcache-ai/Mooncake/${MOONCAKE_SOS_COMMIT}/mooncake-wheel/mooncake/structured_object_store.py" \ + -o "${MOONCAKE_DIR}/structured_object_store.py" && \ + python3 -c "from mooncake.structured_object_store import FieldSchema, MooncakeBundleTransfer, export_ref, import_ref; MooncakeBundleTransfer.put; MooncakeBundleTransfer.get; MooncakeBundleTransfer.release_result; MooncakeBundleTransfer.cleanup_dataproto" + # ====================================== Install main package ============================================ ARG MILES_COMMIT=main From a3c8b573e9e14067f6b99c7ec9c11736cb49b739 Mon Sep 17 00:00:00 2001 From: Jiajun Li Date: Fri, 24 Jul 2026 07:34:21 +0000 Subject: [PATCH 2/6] Install mooncake from the wheels release instead of overlaying the module Supersedes the raw-file overlay: the pinned structured object store now ships as a real wheel built by the miles-wheels `mooncake` step (yueming-yuan/miles-wheels#8), and the wheels-release download already lands it in /tmp/wheels. Installing the whole wheel replaces the base image's identically named dist, so the C++ core, mooncake_master, and the Python API stay one pinned build instead of a hybrid of 0.3.11 binaries with a newer overlaid module. The layer requires the wheel on cu13/amd64 (the variant miles CI runs mooncake on) and fails the build when the release lacks it; other (cuda, arch) variants log and keep the base image's mooncake until their wheel is built. The import self-check stays as the fail-loud gate for an incomplete wheel. Co-Authored-By: Claude Fable 5 --- docker/Dockerfile | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/docker/Dockerfile b/docker/Dockerfile index 3127b3ae3f..575a66515e 100644 --- a/docker/Dockerfile +++ b/docker/Dockerfile @@ -172,19 +172,25 @@ RUN cd /sgl-workspace/sglang && \ fi && \ pip install -e "python[all]" --no-deps -# =========================== Mooncake structured object store overlay =========================== +# =========================== Mooncake structured object store wheel =========================== # miles' mooncake rollout-data backend needs the structured object store API (FieldSchema, # export_ref/import_ref, unified put/get, release_result) merged upstream in # kvcache-ai/Mooncake#2907/#3013/#3023 but not present in any released wheel (<= 0.3.12, -# whose release branch was cut before those merges). The API is a single pure-Python module -# compatible with the C++ core the base image already ships, so overlay just that module. -# Drop this layer once a mooncake release contains the API. -ARG MOONCAKE_SOS_COMMIT=4dbe5a4c194669850e9abad61172e9878b245b15 -RUN MOONCAKE_DIR=$(python3 -c "import mooncake, os; print(os.path.dirname(mooncake.__file__))") && \ - curl -fsSL --retry 3 "https://raw.githubusercontent.com/kvcache-ai/Mooncake/${MOONCAKE_SOS_COMMIT}/mooncake-wheel/mooncake/structured_object_store.py" \ - -o "${MOONCAKE_DIR}/structured_object_store.py" && \ - python3 -c "from mooncake.structured_object_store import FieldSchema, MooncakeBundleTransfer, export_ref, import_ref; MooncakeBundleTransfer.put; MooncakeBundleTransfer.get; MooncakeBundleTransfer.release_result; MooncakeBundleTransfer.cleanup_dataproto" +# whose release branch was cut before those merges). The wheels release carries mooncake +# built from a pinned master commit (the miles-wheels `mooncake` step); install it over the +# base image's identically named dist. Wheels exist per (cuda, arch) release tag — cu13/amd64 +# is required, other variants keep the base image's mooncake until their wheel is built. +# Drop this layer for a plain pip pin once a mooncake release contains the API. +RUN set -- /tmp/wheels/mooncake_transfer_engine*-*.whl; \ + if [ -e "$1" ]; then \ + pip install --force-reinstall --no-deps "$@" && \ + python3 -c "from mooncake.structured_object_store import FieldSchema, MooncakeBundleTransfer, export_ref, import_ref; MooncakeBundleTransfer.put; MooncakeBundleTransfer.get; MooncakeBundleTransfer.release_result; MooncakeBundleTransfer.cleanup_dataproto"; \ + elif [ "${ENABLE_CUDA_13}" = "1" ] && [ "${TARGETARCH}" = "amd64" ]; then \ + echo "mooncake wheel missing from the wheels release for cu13/amd64" >&2; exit 1; \ + else \ + echo "no mooncake wheel for this variant; keeping the base image's mooncake (no structured object store API)"; \ + fi # ====================================== Install main package ============================================ From e047ceda0cdc71e48b5c84946d03cfd8d7b53815 Mon Sep 17 00:00:00 2001 From: Jiajun Li Date: Fri, 24 Jul 2026 07:39:43 +0000 Subject: [PATCH 3/6] Simplify mooncake wheel layer comment The per-variant gating is readable from the shell branches; keep the comment to the why and the drop condition. Co-Authored-By: Claude Fable 5 --- docker/Dockerfile | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/docker/Dockerfile b/docker/Dockerfile index 575a66515e..12bf59f92b 100644 --- a/docker/Dockerfile +++ b/docker/Dockerfile @@ -174,14 +174,10 @@ RUN cd /sgl-workspace/sglang && \ # =========================== Mooncake structured object store wheel =========================== -# miles' mooncake rollout-data backend needs the structured object store API (FieldSchema, -# export_ref/import_ref, unified put/get, release_result) merged upstream in -# kvcache-ai/Mooncake#2907/#3013/#3023 but not present in any released wheel (<= 0.3.12, -# whose release branch was cut before those merges). The wheels release carries mooncake -# built from a pinned master commit (the miles-wheels `mooncake` step); install it over the -# base image's identically named dist. Wheels exist per (cuda, arch) release tag — cu13/amd64 -# is required, other variants keep the base image's mooncake until their wheel is built. -# Drop this layer for a plain pip pin once a mooncake release contains the API. +# miles' mooncake rollout-data backend needs the structured object store API, merged upstream +# (kvcache-ai/Mooncake#2907/#3013/#3023) but in no released wheel (<= 0.3.12). Until a release +# ships it, install the pinned-commit build from the wheels release (miles-wheels `mooncake` +# step) over the base image's mooncake. RUN set -- /tmp/wheels/mooncake_transfer_engine*-*.whl; \ if [ -e "$1" ]; then \ pip install --force-reinstall --no-deps "$@" && \ From 4505ddd24faf90890dc56ba65c1e7dd3d10af288 Mon Sep 17 00:00:00 2001 From: Jiajun Li Date: Fri, 24 Jul 2026 15:22:02 -0700 Subject: [PATCH 4/6] fix(docker): keep Mooncake on CUDA 13 wheels Require exactly one Mooncake wheel for CUDA 13 images and leave CUDA 12 on its ABI-matched base package. Track the rolling CUDA 13 wheel releases while preserving the Torch 2.11 CUDA 12 pin. --- .github/workflows/docker-build.yml | 6 +++--- docker/Dockerfile | 19 +++++++++---------- docker/build.py | 1 + docs/ci/02-docker-build.md | 10 +++++----- 4 files changed, 18 insertions(+), 18 deletions(-) diff --git a/.github/workflows/docker-build.yml b/.github/workflows/docker-build.yml index cd5e8c7dcd..36d53a8f34 100644 --- a/.github/workflows/docker-build.yml +++ b/.github/workflows/docker-build.yml @@ -80,7 +80,7 @@ jobs: # Fingerprint the miles-wheels releases the images install from (sgl-router + # the other prebuilt wheels). cu13 installs cu130-x86_64 / cu130-aarch64; - # cu12-x86 installs cu129-x86_64 — both build automatically, so track all + # cu12-x86 installs cu129-x86_64-v0.5.12 — both build automatically, so track all # release tags they bake. Bumping a WHEELS_TAG is a Dockerfile change already # caught by the push trigger; asset re-uploads keep the tag's commit fixed, so # fingerprint the asset list, not a SHA. @@ -88,8 +88,8 @@ jobs: curl -s "https://api.github.com/repos/yueming-yuan/miles-wheels/releases/tags/$1" \ | python3 -c "import sys,json,hashlib; a=json.load(sys.stdin).get('assets',[]); fp=sorted([x['name'],x['id'],x['size'],x['updated_at']] for x in a); print(hashlib.sha256(repr(fp).encode()).hexdigest() if a else '')" } - WHEELS_CU13_X86_FP=$(wheels_fp cu130-x86_64-v0.5.12) - WHEELS_CU13_ARM64_FP=$(wheels_fp cu130-aarch64-v0.5.12) + WHEELS_CU13_X86_FP=$(wheels_fp cu130-x86_64) + WHEELS_CU13_ARM64_FP=$(wheels_fp cu130-aarch64) WHEELS_CU12_X86_FP=$(wheels_fp cu129-x86_64-v0.5.12) echo "sglang HEAD: ${SGLANG_SHA}" diff --git a/docker/Dockerfile b/docker/Dockerfile index 12bf59f92b..a453a18df8 100644 --- a/docker/Dockerfile +++ b/docker/Dockerfile @@ -174,18 +174,17 @@ RUN cd /sgl-workspace/sglang && \ # =========================== Mooncake structured object store wheel =========================== -# miles' mooncake rollout-data backend needs the structured object store API, merged upstream -# (kvcache-ai/Mooncake#2907/#3013/#3023) but in no released wheel (<= 0.3.12). Until a release -# ships it, install the pinned-commit build from the wheels release (miles-wheels `mooncake` -# step) over the base image's mooncake. -RUN set -- /tmp/wheels/mooncake_transfer_engine*-*.whl; \ - if [ -e "$1" ]; then \ - pip install --force-reinstall --no-deps "$@" && \ +# Miles' Mooncake backend requires the structured object store API. Install the pinned +# CUDA 13 wheel as one coherent Python/native package; CUDA 12 keeps its base Mooncake. +RUN if [ "${ENABLE_CUDA_13}" = "1" ]; then \ + set -- /tmp/wheels/mooncake_transfer_engine*-*.whl; \ + if [ "$#" -ne 1 ] || [ ! -e "$1" ]; then \ + echo "expected exactly one mooncake wheel for cu13/${TARGETARCH}" >&2; exit 1; \ + fi && \ + pip install --force-reinstall --no-deps "$1" && \ python3 -c "from mooncake.structured_object_store import FieldSchema, MooncakeBundleTransfer, export_ref, import_ref; MooncakeBundleTransfer.put; MooncakeBundleTransfer.get; MooncakeBundleTransfer.release_result; MooncakeBundleTransfer.cleanup_dataproto"; \ - elif [ "${ENABLE_CUDA_13}" = "1" ] && [ "${TARGETARCH}" = "amd64" ]; then \ - echo "mooncake wheel missing from the wheels release for cu13/amd64" >&2; exit 1; \ else \ - echo "no mooncake wheel for this variant; keeping the base image's mooncake (no structured object store API)"; \ + echo "CUDA 12 variant: keeping the base image's mooncake"; \ fi # ====================================== Install main package ============================================ diff --git a/docker/build.py b/docker/build.py index 6d620d87ef..b2a234c77a 100644 --- a/docker/build.py +++ b/docker/build.py @@ -46,6 +46,7 @@ "build_args": { "ENABLE_CUDA_13": "0", "SGLANG_IMAGE_TAG": "v0.5.15-cu129", + # Keep the torch 2.11.0 ABI-matched release; cu129 rolling predates that rebuild. "WHEELS_TAG_X86": "cu129-x86_64-v0.5.12", }, }, diff --git a/docs/ci/02-docker-build.md b/docs/ci/02-docker-build.md index ddd88700f3..5d4c63ee05 100644 --- a/docs/ci/02-docker-build.md +++ b/docs/ci/02-docker-build.md @@ -18,17 +18,17 @@ GPU CI runs inside `radixark/miles`. This doc maps which Dockerfiles exist, the ### `docker/Dockerfile` — inputs & output -The Dockerfile is the build recipe and nothing more: it knows no variants and no tags. Everything it needs arrives as build-args; it emits one image. `build.py` owns the variant → build-arg mapping (see Build script), so the boundary stays clean — e.g. the wheels-repo tag naming lives only in `build.py`, never here. +The Dockerfile is the build recipe: it provides the cu13 defaults and emits one image. `build.py` owns the variant → build-arg overrides (see Build script), including the cu12 base and wheels release. **Inputs (build-args)** | Arg | Meaning | | ------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `SGLANG_IMAGE_TAG` | base `lmsysorg/sglang` tag (default `v0.5.14`, a multi-arch release) | -| `ENABLE_CUDA_13` | `1` = CUDA 13 (default), `0` = CUDA 12.9 | +| `SGLANG_IMAGE_TAG` | base `lmsysorg/sglang` tag (default `v0.5.15`, a multi-arch release) | +| `ENABLE_CUDA_13` | `1` = CUDA 13 (default) and installs the Mooncake wheel from the selected wheels release; `0` = CUDA 12.9 and keeps the base image's Mooncake | | `WHEELS_REPO` | prebuilt-wheels GitHub repo (`yueming-yuan/miles-wheels`) | -| `WHEELS_TAG_X86` / `WHEELS_TAG_ARM64` | the two **complete** wheels release tags, the wheels repo's own names — rolling per-(CUDA, arch) sets like `cu130-x86_64` / `cu130-aarch64`, updated in place (legacy pinned tags like `cu129-x86_64-v0.5.12` still work). In a multi-arch build the Dockerfile **picks one by `TARGETARCH`** (the only per-platform value buildx varies) and installs it **verbatim** — never assembling a tag from parts; cu12-x86 overrides `WHEELS_TAG_X86` | +| `WHEELS_TAG_X86` / `WHEELS_TAG_ARM64` | the two **complete** wheels release tags selected by `TARGETARCH` and installed **verbatim**. cu13 uses the rolling `cu130-x86_64` / `cu130-aarch64` releases; cu12-x86 overrides `WHEELS_TAG_X86` with the Torch 2.11.0 ABI-matched `cu129-x86_64-v0.5.12` release | | `SGLANG_BRANCH` / `SGLANG_COMMIT`, `MEGATRON_REPO` / `MEGATRON_BRANCH`, `MILES_COMMIT`, `SGL_ROUTER_*` | source pins for the layered repos | @@ -51,7 +51,7 @@ The Dockerfile is the build recipe and nothing more: it knows no variants and no | `rocm-mi350` | `rocm/sgl-dev:miles-rocm720-mi35x` | native | AMD MI35x — `docker/Dockerfile.rocm` | -The cu13 variants share one CUDA base (`lmsysorg/sglang:v0.5.14`, multi-arch) and differ only in platforms. `cu13` runs a single `buildx --platform linux/amd64,linux/arm64` — buildx builds both arches and pushes them as one manifest in a single shot, with the Dockerfile picking each layer's wheels by `TARGETARCH` (see Dockerfile inputs), so `docker pull` auto-selects by host arch. +The cu13 variants share one CUDA base (`lmsysorg/sglang:v0.5.15`, multi-arch) and differ only in platforms. `cu13` runs a single `buildx --platform linux/amd64,linux/arm64` — buildx builds both arches and pushes them as one manifest in a single shot, with the Dockerfile picking each layer's wheels by `TARGETARCH` (see Dockerfile inputs), so `docker pull` auto-selects by host arch. The **Tag** column is for `--image-tag dev`, which also pushes a timestamped `dev-` sibling; `latest` swaps the prefix to `latest`, `custom` uses `--custom-tag`. `cu13` / `cu13-x86` / `cu13-aarch64` intentionally share `radixark/miles:dev` — the daily build runs `cu13` (multi-arch), while a single-arch variant overwrites `dev` with one arch when run alone. From 249303a074733afaa075ad0fd543304ee6a6b2c4 Mon Sep 17 00:00:00 2001 From: Jiajun Li Date: Fri, 24 Jul 2026 15:43:09 -0700 Subject: [PATCH 5/6] fix(docker): use rolling CUDA wheel tags Remove the CUDA 12 versioned wheels exception so every CUDA variant consumes an architecture-specific rolling release. Keep scheduled release fingerprints and Docker documentation aligned with those mutable tags. --- .github/workflows/docker-build.yml | 9 ++++----- docker/Dockerfile | 2 +- docker/build.py | 3 +-- docs/ci/02-docker-build.md | 4 ++-- 4 files changed, 8 insertions(+), 10 deletions(-) diff --git a/.github/workflows/docker-build.yml b/.github/workflows/docker-build.yml index 36d53a8f34..7f863067c5 100644 --- a/.github/workflows/docker-build.yml +++ b/.github/workflows/docker-build.yml @@ -80,17 +80,16 @@ jobs: # Fingerprint the miles-wheels releases the images install from (sgl-router + # the other prebuilt wheels). cu13 installs cu130-x86_64 / cu130-aarch64; - # cu12-x86 installs cu129-x86_64-v0.5.12 — both build automatically, so track all - # release tags they bake. Bumping a WHEELS_TAG is a Dockerfile change already - # caught by the push trigger; asset re-uploads keep the tag's commit fixed, so - # fingerprint the asset list, not a SHA. + # cu12-x86 installs cu129-x86_64 — both build automatically, so track all rolling + # release tags they bake. Rolling tags stay fixed while assets may be replaced, + # so fingerprint the asset list rather than a commit SHA. wheels_fp() { curl -s "https://api.github.com/repos/yueming-yuan/miles-wheels/releases/tags/$1" \ | python3 -c "import sys,json,hashlib; a=json.load(sys.stdin).get('assets',[]); fp=sorted([x['name'],x['id'],x['size'],x['updated_at']] for x in a); print(hashlib.sha256(repr(fp).encode()).hexdigest() if a else '')" } WHEELS_CU13_X86_FP=$(wheels_fp cu130-x86_64) WHEELS_CU13_ARM64_FP=$(wheels_fp cu130-aarch64) - WHEELS_CU12_X86_FP=$(wheels_fp cu129-x86_64-v0.5.12) + WHEELS_CU12_X86_FP=$(wheels_fp cu129-x86_64) echo "sglang HEAD: ${SGLANG_SHA}" echo "megatron HEAD: ${MEGATRON_SHA}" diff --git a/docker/Dockerfile b/docker/Dockerfile index a453a18df8..f8ce794fef 100644 --- a/docker/Dockerfile +++ b/docker/Dockerfile @@ -174,7 +174,7 @@ RUN cd /sgl-workspace/sglang && \ # =========================== Mooncake structured object store wheel =========================== -# Miles' Mooncake backend requires the structured object store API. Install the pinned +# Miles' Mooncake backend requires the structured object store API. Install the selected # CUDA 13 wheel as one coherent Python/native package; CUDA 12 keeps its base Mooncake. RUN if [ "${ENABLE_CUDA_13}" = "1" ]; then \ set -- /tmp/wheels/mooncake_transfer_engine*-*.whl; \ diff --git a/docker/build.py b/docker/build.py index b2a234c77a..207746417c 100644 --- a/docker/build.py +++ b/docker/build.py @@ -46,8 +46,7 @@ "build_args": { "ENABLE_CUDA_13": "0", "SGLANG_IMAGE_TAG": "v0.5.15-cu129", - # Keep the torch 2.11.0 ABI-matched release; cu129 rolling predates that rebuild. - "WHEELS_TAG_X86": "cu129-x86_64-v0.5.12", + "WHEELS_TAG_X86": "cu129-x86_64", }, }, "rocm700-mi35x": { diff --git a/docs/ci/02-docker-build.md b/docs/ci/02-docker-build.md index 5d4c63ee05..a669d8f856 100644 --- a/docs/ci/02-docker-build.md +++ b/docs/ci/02-docker-build.md @@ -28,7 +28,7 @@ The Dockerfile is the build recipe: it provides the cu13 defaults and emits one | `SGLANG_IMAGE_TAG` | base `lmsysorg/sglang` tag (default `v0.5.15`, a multi-arch release) | | `ENABLE_CUDA_13` | `1` = CUDA 13 (default) and installs the Mooncake wheel from the selected wheels release; `0` = CUDA 12.9 and keeps the base image's Mooncake | | `WHEELS_REPO` | prebuilt-wheels GitHub repo (`yueming-yuan/miles-wheels`) | -| `WHEELS_TAG_X86` / `WHEELS_TAG_ARM64` | the two **complete** wheels release tags selected by `TARGETARCH` and installed **verbatim**. cu13 uses the rolling `cu130-x86_64` / `cu130-aarch64` releases; cu12-x86 overrides `WHEELS_TAG_X86` with the Torch 2.11.0 ABI-matched `cu129-x86_64-v0.5.12` release | +| `WHEELS_TAG_X86` / `WHEELS_TAG_ARM64` | the two **complete** wheels release tags selected by `TARGETARCH` and installed **verbatim**. cu13 uses the rolling `cu130-x86_64` / `cu130-aarch64` releases; cu12-x86 overrides `WHEELS_TAG_X86` with the rolling `cu129-x86_64` release | | `SGLANG_BRANCH` / `SGLANG_COMMIT`, `MEGATRON_REPO` / `MEGATRON_BRANCH`, `MILES_COMMIT`, `SGL_ROUTER_*` | source pins for the layered repos | @@ -75,7 +75,7 @@ Non-docker PRs are untouched: `docker-paths` reports no change, `docker-build` s The only automated builder of `radixark/miles`. Two jobs: -- **`check-upstream`** (schedule / `simulate_schedule` only) — polls the inputs the image bakes: the HEAD SHA of sglang `sglang-miles` (`sgl-project/sglang`) and Megatron-LM `miles-main` (`radixark/Megatron-LM`) — the source branches it builds — plus a fingerprint of the `yueming-yuan/miles-wheels` release it installs, so a rebuilt sgl-router or other wheel also triggers a build (the wheels are pinned by `WHEELS_TAG`, so re-uploads to the same tag are caught by fingerprint, not commit SHA). It compares against the values cached from the last build and sets `should_build=true` if any moved. `miles` itself is intentionally not polled. This is what stops the 12-hour cron from rebuilding an unchanged image. +- **`check-upstream`** (schedule / `simulate_schedule` only) — polls the inputs the image bakes: the HEAD SHA of sglang `sglang-miles` (`sgl-project/sglang`) and Megatron-LM `miles-main` (`radixark/Megatron-LM`) — the source branches it builds — plus a fingerprint of the selected `yueming-yuan/miles-wheels` rolling release, so a rebuilt sgl-router or other wheel also triggers a build (re-uploads to the same tag are caught by fingerprint, not commit SHA). It compares against the values cached from the last build and sets `should_build=true` if any moved. `miles` itself is intentionally not polled. This is what stops the 12-hour cron from rebuilding an unchanged image. - **`build-and-push`** (self-hosted runner) — calls `docker/build.py` to build + push, then conditionally points `latest` at the new `dev` and prunes old timestamped tags. `build-and-push` runs when `check-upstream` was skipped, or ran and reported `should_build=true`. From 47b565a233c91be9a5b298c48c5a0023f143c600 Mon Sep 17 00:00:00 2001 From: Jiajun Li Date: Fri, 24 Jul 2026 16:17:28 -0700 Subject: [PATCH 6/6] docs(docker): avoid pinning SGLang version in prose Describe the shared cu13 base generically so the documentation does not go stale when Docker build tags move. Keep SGLANG_IMAGE_TAG as the source of the concrete version. --- docs/ci/02-docker-build.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/ci/02-docker-build.md b/docs/ci/02-docker-build.md index a669d8f856..e1da1eb3b0 100644 --- a/docs/ci/02-docker-build.md +++ b/docs/ci/02-docker-build.md @@ -25,7 +25,7 @@ The Dockerfile is the build recipe: it provides the cu13 defaults and emits one | Arg | Meaning | | ------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `SGLANG_IMAGE_TAG` | base `lmsysorg/sglang` tag (default `v0.5.15`, a multi-arch release) | +| `SGLANG_IMAGE_TAG` | base `lmsysorg/sglang` image tag | | `ENABLE_CUDA_13` | `1` = CUDA 13 (default) and installs the Mooncake wheel from the selected wheels release; `0` = CUDA 12.9 and keeps the base image's Mooncake | | `WHEELS_REPO` | prebuilt-wheels GitHub repo (`yueming-yuan/miles-wheels`) | | `WHEELS_TAG_X86` / `WHEELS_TAG_ARM64` | the two **complete** wheels release tags selected by `TARGETARCH` and installed **verbatim**. cu13 uses the rolling `cu130-x86_64` / `cu130-aarch64` releases; cu12-x86 overrides `WHEELS_TAG_X86` with the rolling `cu129-x86_64` release | @@ -51,7 +51,7 @@ The Dockerfile is the build recipe: it provides the cu13 defaults and emits one | `rocm-mi350` | `rocm/sgl-dev:miles-rocm720-mi35x` | native | AMD MI35x — `docker/Dockerfile.rocm` | -The cu13 variants share one CUDA base (`lmsysorg/sglang:v0.5.15`, multi-arch) and differ only in platforms. `cu13` runs a single `buildx --platform linux/amd64,linux/arm64` — buildx builds both arches and pushes them as one manifest in a single shot, with the Dockerfile picking each layer's wheels by `TARGETARCH` (see Dockerfile inputs), so `docker pull` auto-selects by host arch. +The cu13 variants share one multi-arch CUDA base image and differ only in platforms. `cu13` runs a single `buildx --platform linux/amd64,linux/arm64` — buildx builds both arches and pushes them as one manifest in a single shot, with the Dockerfile picking each layer's wheels by `TARGETARCH` (see Dockerfile inputs), so `docker pull` auto-selects by host arch. The **Tag** column is for `--image-tag dev`, which also pushes a timestamped `dev-` sibling; `latest` swaps the prefix to `latest`, `custom` uses `--custom-tag`. `cu13` / `cu13-x86` / `cu13-aarch64` intentionally share `radixark/miles:dev` — the daily build runs `cu13` (multi-arch), while a single-arch variant overwrites `dev` with one arch when run alone.