Format code by hnyls2002 · Pull Request #441 · sgl-project/sglang

hnyls2002 · 2024-05-14T14:39:13Z

No description provided.

* fix dummy loader

Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

Co-authored-by: zhuxingxin.0 <zhuxingxin.0@bytedance.com>

…ect + direct My earlier page_first choice was wrong and is reversed here. Three facts, the first two from the tree and the third measured on this rig today: * MambaPoolHost raises unless layout == 'page_first_direct' (memory_pool_host.py:96-100) and the hybrid assembler constructs it UNCONDITIONALLY for a GDN model (hybrid_pool_assembler.py:551). With page_first this boot would have failed hard, not stored KV-only. * page_first + io_backend=kernel is the route with an OPEN segfault on both the cu12 and cu13 wheels (transfer_kv_all_layer_lf_ph, per the runbook). That was the combination I had picked. * The direct route works. cudaMemcpyBatchAsync needs a pinned host side and a non-legacy stream; production satisfies both (pin_memory defaults True, and cache_controller.py:742 copies inside 'with device_module.stream(self.write_stream)'). Measured matrix, transfer_kv_all_layer_direct_lf_pf through MHATokenToKVPoolHost(layout='page_first_direct') on the cu13 wheel: pageable + default stream -> failIdx=SIZE_MAX invalid argument pageable + side stream -> CUDA error: invalid argument pinned + default stream -> failIdx=SIZE_MAX invalid argument pinned + side stream -> OK (the production shape) So the sgl-project#441(b) guard is NOT a stale flip: the test fails for real because it allocates pageable host memory (pin_memory = io_backend == 'kernel') and copies on the default stream. Unskipping it alone leaves it red. The guard is restored with the measured matrix as its reason so nobody reads it as 'direct is broken in production'; making the test production-shaped is the actual follow-up, alongside the separate kernel+page_first segfault. Boot command accepts hermetically: hicache True/file/24, layout page_first_direct, io direct, max_size 100Gi, min_free_space 20Gi, chat_template_default_kwargs {'preserve_thinking': true}, spec EAGLE, ctx 262144, kvso False.

…fuse both guard flips WHEEL PINNED FIRST, by path and sha, because sgl-project#384 says never assume which sgl_kernel is installed: .../site-packages/sgl_kernel/sm100/common_ops.abi3.so sha256 a12be9bc94aed339... 11021280 bytes built 2026-08-03 12:37:15 It is the ONLY common_ops present. Despite the `sm100/` directory it carries BOTH sm_86 and sm_120 cubins, matching the 3080s and the 5090, so the tempting "wheel built for the wrong arch" reading is wrong and is recorded as excluded rather than left as a live suspicion. (a) ATTRIBUTION CORRECTED; THE SEGFAULT IS NOT WHERE THE TICKET SAYS. `transfer_kv_all_layer_lf_ph` is NOT reachable from test_device_to_host_kernel_page_first on the current tree: pool_host/mha.py gates that call on `layout == "page_head"` (:405), the test drives only layer_first / page_first / page_first_direct, and the index-K host (MHATokenToKOnlyPoolHost) uses the MLA variants, never lf_ph. Three hypotheses eliminated, each against the pinned binary rather than the source: * wrong-arch cubin -- excluded, both archs present; * the CPU `dst_indices` this test deliberately feeds the (kernel, page_first) arm -- excluded: the installed .so contains TORCH_CHECK(dst_indices.is_cuda(), "Destination indices must be a CUDA tensor"), so that path raises cleanly and cannot segfault. The test's own comment claiming "CUDA accepts the CPU dst-indices this combo feeds" is therefore stale; * the int32 index contract seen in the binary's strings -- excluded, it belongs to the grammar kernel, not kvcacheio. NO HERMETIC REPRO IS CONSTRUCTIBLE, and the reason is structural rather than an admission of effort: the fault is inside a CUDA kernel launch and there is no CPU path through these kernels, so CVD="" cannot reach the code that crashes. The smallest CUDA repro is that one test alone, deferred to a window. What eliminating three suspects buys is that the window does not get spent on them. (b) NEITHER GUARD FLIPS, and both refusals are evidence-backed. * `_DIRECT_PF_BATCHCOPY_BROKEN_CUDA13`: trigger ALIVE. The measured matrix already in the file says the failure is the test's memory and stream SHAPE -- pageable host, legacy null stream -- which production does not have (pinned + side stream is the only passing cell). The predicate keys on the CUDA major, which is not what the measurement blames, so the guard is also misnamed. Flipping it re-enables a test that fails for a reason the guard does not mention. The cheap discriminating experiment is named in the file: make the test production-shaped and see it pass ON cu13, after which the guard can be DELETED rather than flipped. * the kvcacheio module-skip: it is not a skip and not obsolete. `_install_sgl_kernel_stub()` returns early when `sgl_kernel` is importable, so on this machine it already does nothing; it is a portability shim for environments without the wheel, and removing it would break those. Nothing to flip. (c) scripts/handover/live_handover_gate_shortrun.sh -- PREP ONLY, GPU-gated. It composes live_handover_gate.sh rather than reimplementing it, so the gate's order of proof stays single-sourced. It REFUSES rather than fixes up: a set SGLANG_HICACHE_HARNESS_SHIM is refused with the reason (a short run through the shim would prove the shim, not the host tier this run exists to prove), a missing gpu-arb holder is refused, and all eight required variables are checked up front so a window is not spent discovering them one at a time. "Short" shortens only the continuation length -- every step still runs, because dropping one makes the rest unattributable, and byte-identity holds at 64 tokens or not at all. Both refusal paths exercised without CUDA. test_minimax_sparse_pool_host_unit: 4 passed, 4 skipped (the CUDA arms). Hermetic. NO DEPLOY, nothing flipped, no boot.

… dry run, and the vouch The notes were written at 3c984ad and had gone stale in three ways. Chain: 18 commits at e21e87f -> 22 at 5939d0e. Added sgl-project#697 (8fb86ef), sgl-project#441 (5e0fa1e), sgl-project#524 (5939d0e) and the revision-1 docs commit. Runtime-touching is now 8 of 22, and sgl-project#441 is recorded as NOT runtime despite its ticket -- it adds a handover script and one test guard. Target: integration/r2 has moved a73a0d8 -> a157bf1, so the dry run was re-run rather than carried over. Still zero conflicts. Scope shrank with the target's advance: 115 -> 109 commits, 129 -> 124 files, +22731 -> +22196. Merged-tree tests: managers 2093 passed / 0 failed; planner plus the three new test files 2594 passed / 2 failed. Those 2 are PpWithSpecEvidenceTest in test_rejected_evidence_pins.py and were re-verified as pre-existing by aborting the merge and running that file on clean a157bf1 -- same 2 failed, 2 passed. The chain introduces no new failure. Because the target tip moved, this was re-checked instead of quoting revision 1's finding. Holds: sgl-project#690 (e21e87f) and sgl-project#697 (8fb86ef) are in F4-r4's bundle, so revision 1's objection to landing sgl-project#690 ahead of the sgl-project#694 soak is spent; both lift to group 1 on his boot commit. sgl-project#524 (5939d0e) joins the hold list -- desk-verified only, never on metal, A/B window-gated. sgl-project#685 (5301b94) stays held on the unmade R' decision. Vouch (new section 5): the four F4-r4 cherry-picks are byte-identical to the originals by git patch-id --stable -- f630947/c41645c8c9, 7c58aba/ce6035884d, f1f31d2/658ea3ac11, de92bb6/84b0171fa6 -- so preferring the originals is free and the only real risk is double attribution. 1073702 is excluded: patch-id 8595e66885ac matches nothing here, it is diagnostic scaffolding and not mine to vouch for. Section 6 records that 5af1531 (sgl-project#696) and c738ef5 (sgl-project#689) are F4-r4's line, not this branch, and are listed only because they lift holds; sgl-project#696 is what was DoSing the lanes. Docs only. No merge performed; the dry-run worktree was removed.

…riant, refuse both guard flips (a) ROOT, at file:line. transfer_item_warp moves bytes with 64-bit PTX -- ld.global.nc.b64 / st.global.cg.b64 (transfer.cu:29-30) -- which faults on a misaligned address. The only alignment guard in the path is TORCH_CHECK(item_size % 8 == 0) at transfer.cu:285. That guard is sufficient for the lf_pf sibling and NOT for lf_ph, and the difference is entirely in the offset arithmetic. I compared the two launcher calls line by line (:496-513 against :532-551): identical empty tensors, identical tables in identical slots, identical layout dims. But get_global_offset_pf builds offsets only as multiples of item_size and layout_dim, so alignment is inherited from the checked guard, while get_global_offset_ph (transfer.cu:106-119) SUBDIVIDES by head_num in three of its four terms and the page-head kernel copies head_size_bytes = item_size / head_num (transfer.cu:145). Nothing requires that quotient to be 8-byte aligned. MISSING INVARIANT: item_size % (8 * head_num) == 0. Smallest faulting shape head_num=2 head_dim=2 fp16 -- item_size=8 passes the guard, head_size=4 does not, 24 enumerated offsets misalign. SCOPE, STATED RATHER THAN STRETCHED: this does NOT explain the reported segfault. test_minimax_sparse_pool_host_unit's shapes (page_size=4, float32, head_num=1, head_dim=2) give head_size=8 and zero misaligned offsets, and so do this rig's serving shapes (head_num=4, head_dim=256, fp8 -> head_size=256). The defect is real and latent; no production shape here is exposed. Both facts are PINNED so the attribution cannot quietly widen. Three hypotheses checked and closed on the way: the layer pointer table is correctly a device uint64 tensor (mha.py:135-144); layout_dim is the right per-token all-layer stride for the ph formula (mha.py:182); the k-only pool cannot reach lf_ph, it raises for any non-page_first layout under the kernel backend (mha.py:1113-1118). Attribution needs metal, so the falsifier is FILED NOT RUN: tools/441/falsify_lf_ph_441.py, three arms (repro / alignment / bisect), one arm per invocation because each is expected to kill the process, to be run under a gpu-arb claim. (b) BOTH GUARDS: DO NOT FLIP. The brief's premise was that the sgl-project#436 rebuild made them obsolete. Checking them at the code says otherwise, for two reasons, neither of which is the ABI issue. test_kvcacheio.py:20-24 module skip claims "segfaults on CUDA 13.x". But the lf_ph segfault reproduces on BOTH wheels -- that is this ticket's own premise and why it is not sgl-project#436. So the reason is wrong or incomplete, and flipping would expose a live cu12 crash. It must stay until (a) is fixed; what should change now is the REASON STRING, because a wrong reason sends the next reader to the wrong wheel. _DIRECT_PF_BATCHCOPY_BROKEN_CUDA13 never guarded a wheel issue at all. Per the measured matrix above it, it guards a TEST-SHAPE violation of the cudaMemcpyBatchAsync contract: pageable+default stream fails, pinned+side stream is OK, and production pins (mha.py:97) and uses a side stream (cache_controller.py:276,:742-749). The file's own comment already says unskipping alone leaves it red. The rebuild landing does not change a contract the test violates by construction; the fix is a test-shape change, and verifying it is GPU work. PIN TESTS NOT WRITTEN, deliberately: a pin that "goes red if the breakage returns" presupposes the breakage is gone, and for both guards it is not. Writing them now would encode a green state that does not exist. NOT DELIVERED: the sgl-project#261-Gate short-run script. Preparing it turnkey needs the gate's shim details verified at the code, which I have not done, and shipping a script I cannot stand behind would be worse than saying so. Tests, hermetic (CUDA_VISIBLE_DEVICES="", no CUDA context, no launch, no GPU): test_page_head_offset_alignment_441.py 6 passed + 6 subtests in 0.07 s pure arithmetic transcription of get_global_offset_ph; states the proposed guard positively and fails if that predicate is not the right one test/registered/unit/mem_cache/ 940 failed / 796 passed -- the 940 are PRE-EXISTING ON THIS BASE (b786858 lacks the sgl-project#585 conftest that turns no-accelerator errors into skips). Proven by re-running with my file ignored: 940 failed / 790 passed, i.e. identical failures and exactly my 6 passes added. ruff clean; falsifier byte-compiles without executing.

…ason strings, file the host-tier gate 1. THE GUARD. check_page_head_alignment in csrc/kvcacheio/transfer.cu, requiring item_size % (8 * head_num) == 0, called from BOTH page-head entries: transfer_kv_all_layer_lf_ph and transfer_kv_per_layer_ph_lf. Guarding only the reported one would have left the same asymmetry sgl-project#717 was reverted for -- a defect that looks fixed from one side. The message names the two facts that EXPLAIN the rule, not just the rule: the .b64 PTX width (ld.global.nc.b64 / st.global.cg.b64 fault on a misaligned address) and the subdividing offset formula (get_global_offset_ph divides three of its four terms by head_num). A reader who learns only the rule works around it by changing head_num. Pinned: the predicate refuses the faulting shape (head_num=2 head_dim=2 fp16, item_size=8 passes the OLD guard, head_size=4 does not), does NOT falsely refuse the reported-crash shapes or this rig's shapes, and AGREES WITH ACTUAL OFFSET ALIGNMENT on every shape -- so a future edit cannot keep the tests green by tuning the constant. A source pin holds it wired at both entries. MUTATION PROOF: unguarding one entry and weakening the predicate back to % 8 turns 2 pins red. 2. BOTH REASON STRINGS. test_kvcacheio.py's skip said "segfaults on CUDA 13.x". It now states the evidence: reproduces on BOTH wheels, root NOT yet attributed, the alignment defect found here is real but is NOT this crash's cause (these shapes are aligned), and the metal falsifier is at tools/441/. The >= 13 condition is deliberately left as-is with the reason recorded -- widening it would hide the cu12 signal the falsifier needs, removing it would hand CI a known segfault. test_minimax_sparse_pool_host_unit.py's batchcopy comment now LEADS with the reading it previously only implied: the flag guards a CONTRACT VIOLATION COMMITTED BY THE TEST, not a wheel, ABI or CUDA-13 bug, and the measured matrix proves it because pinned+side-stream passes on the same wheel that fails the other three. It says explicitly that the sgl-project#436 rebuild cannot make it obsolete, since a rebuild cannot change a contract the test breaks by construction. 3. sgl-project#261 GATE: THE "SHIM" IS LOAD-BEARING. Verified at the code, which is what was owed. Step 4 is `python -m sglang.srt.mem_cache.hicache_migrate` with --target-tp-size / --target-ratios / GDN layout arguments. The live gate runs source A at TP=1 and destination B at TP=N (live_handover_gate.sh:37), and stored KV pages and GDN state blobs carry the SOURCE's shard geometry. Without the conversion B is not reading the host tier the hard way -- it is handed bytes in a layout it cannot interpret, and the run fails for a reason unrelated to the host tier. So a no-shim 1->N run is structurally meaningless, which is the stop condition the brief named; the cross-geometry handover IS the umsharder. What IS meaningful is holding the geometry EQUAL and dropping the migration: no conversion is needed by construction and the host tier is what remains under test -- write-through, park/export, prefetch, resume from cache, byte-identical continuation. Weaker than the 1->N gate, and real. Filed as scripts/handover/hostier_gate_noshim.sh, syntax-checked and refusing cleanly on missing env, NOT RUN. Its preflight REFUSES when the two servers' geometry/checkpoint differ rather than producing a red a reader could mistake for a host-tier finding -- that refusal is the script's safety property. It keeps the original gate's two load-bearing pieces: the A-vs-A floor FIRST (a cross-server byte claim on a rig whose own repeat is not byte-identical is not a claim about handover) and --expect-cached (without it a destination that re-prefilled reproduces the same greedy tokens and the comparison passes while proving nothing -- observed for real on the sgl-project#261 gate before it was added). Tests, hermetic (CUDA_VISIBLE_DEVICES="", no CUDA context, no launch, no GPU, no server contacted): test_page_head_offset_alignment_441.py 13 passed + 14 subtests in 0.07 s test/registered/unit/mem_cache/ 940 failed / 803 passed -- the 940 are the unchanged PRE-EXISTING baseline on this base (b786858 lacks the sgl-project#585 conftest); passes moved 796 -> 803, exactly the 7 new pins. ruff + codespell clean; the shell script passes bash -n; edited Python files byte-compile. The C++ guard is NOT compiled here (no CUDA build in a hermetic run). Its predicate is pinned arithmetically and its wiring by source inspection; a compile rides the next kernel build.

…d conflict map PREPARATION ONLY. No branch pointer was moved and nothing was merged. Every conflict is MEASURED by trial merges in a throwaway worktree (throwaway/merge-train-probe, removed after measurement), not predicted. Built from git rather than from the handed list, and git contradicted the list twice: * fix/713-admission-intake is ALREADY in the serving line (+0 commits, 0 files) -- not a train item, and scheduling it would be a no-op step that looks like progress. * fix/728-max-bytes-uniform points at 79216e6, byte-identical to feat/706-phase-uniform-hicache-keys, and has NO REMOTE. It must not be merged as a separate item, and its identity has to be settled first: a local-only branch is the one kind that disappears with its worktree. DIVERGENCE. The 4222976 class turned out not to be the risk it looked like: that commit is PRESENT in integration/r2 and absent only from upstream main, which is true of every fork commit. The useful axis is the merge target -- 167 commits are on the serving line and not in integration/r2, and exactly SIX of them are on no other train branch (the sgl-project#677 range c4bc982..5fed8a6, sgl-project#708 fc6f97b, and the merge 761d0d7). All six are reachable from feat/677-park-wiring, so that branch carries them; if any step drops or rewrites it, those six are the loss. The serving line is also NOT an orphaned detached head -- 5fed8a6 is exactly feat/677-park-wiring, checked, because unbranched commits on a serving head are how a train loses a fix. ORDER. All eleven candidates are independent siblings (a containment check found no branch containing another), so order is a conflict question. The measured result is two clusters and a clean set: * Cluster A, scheduler_teardown.py: all four sgl-project#673 thread-stop branches add their stop logic to the same file this lane created for sgl-project#673. They conflict with EACH OTHER, not with the trunk, so whichever lands first sets the file's shape. The barlink one also touches scheduler.py and belongs to live sgl-project#722. * Cluster B, planner/seam: fix/602-fill-side, fix/701-ledger-wiring and feat/704-prefill-ladder each rewrote seam_slope.py, planner/pp_cut.py and test_pp_cut_prefill_speed_702.py. Three lanes editing one model of the same thing -- the conflict is SEMANTIC, and resolving it by taking hunks would produce a seam model nobody designed. * The clean six-step train (621, 699, 673-lockstep, 706, 717, 677) merged in sequence with no conflicts at all and can run without either cluster. TEST MATRIX, measured on the merged probe state: mem_cache 940 failed / 973 passed and distributed 21 failed / 2716 passed, both matching the standing baselines. managers came out at 12 failed / 2274 passed against a standing figure of 14 -- and the point is that this suite's count is TRAIN-COMPOSITION-DEPENDENT: this lane's branch alone shows 4, the merged probe 12, with the extra 8 arriving from the sgl-project#677/sgl-project#713/sgl-project#631 lanes rather than from the merge. The failing classes are listed so they can be attributed, and each owner must record their own baseline before the train, or "the branch shipped it" becomes "the merge broke it". HELD OUT, with the separability question answered: 2ce1ed7 is NOT docs-only -- it changes managers/phase_flip_runtime.py, which is exactly why it earns its review boot. The two later sgl-project#441 commits touch no file it touches, so they are cherry-pickable without it; the only entanglement on that branch is be1fcec -> 2ce1ed7 (same NOTE). But 4512136 carries sgl-kernel/csrc/kvcacheio/transfer.cu, so riding it means a kernel rebuild -- its own boot-gated risk, not something to smuggle in behind a docs-and-tests framing. Also in this push: the sgl-project#568 ledger commit (79216e6), which the audit found was this lane's only unpushed work.

…cket Two docs, both prep: no branch pointer on a real line moves here. MERGE_TRAIN_2_FOLLOWUP.md -- the follow-up train, measured against the head train 1 projects (integration/r2 + 621 + 699 + 673-lockstep + 4c84637 + 67572ce + 677 = 6bab764c33), not against r2. Order and trial-merge result: reconcile/cluster-b-seam-model clean; fix/673-teardown-stack ONE conflict, docs/dev/MERGE_TRAIN_2026-08-17.md, doc only, no source conflict anywhere in the train; fix/728-max-bytes-uniform clean. Assembled head c5a4c1bca8. Ancestry finding, which moves the kernel rebuild: 4512136 and a8b068b are ancestors of reconcile/cluster-b-seam-model (YES) and of nothing else in the train -- not of 6bab764c33, 887a6d4 or a66f5e2. So the separately listed "sgl-project#441 kernel commits" step is a NO-OP and should be struck, the sgl-kernel rebuild is triggered by step 1, and train 1 is unaffected (it merges 67572ce, which carries neither). The rebuild step is named with the runbook's wheel-pin discipline (arch list 86;120, MAX_JOBS=4, nvcc from the venv cu13 toolkit) and its acceptance is boot-gated, not desk-gated. Baselines on c5a4c1bca8, hermetic (CUDA_VISIBLE_DEVICES=""): mem_cache 1086 passed / 0 failed (1651 skipped); managers 19 failed / 2367 passed; planner 8 failed / 2842 passed (all test_webui/chess, missing optional dep); distributed 27 failed / 2764 passed vs 21 on train 1; test_scheduler_teardown_673.py 10 passed. The +6 on distributed is attributed rather than asserted. On the three implicated files: 887a6d4 9 failed, a66f5e2 9, feat/704 9, fix/602 9, fix/701-ledger-wiring 15, reconcile 15, train-2 head 15. The extra failures are pre-existing on fix/701-ledger-wiring and inherited unchanged; no merge in this train creates one. Reported as "21 pre-existing + 6 inherited from sgl-project#701", not as green. DESIGN_706_BOOT.md -- the boot-side open items are closed as a decision, and section 5 is a run-card F4-r4 can execute: preconditions, verbatim flag set, ordered steps, pass/fail by greppable log string, abort conditions. Boot WITHOUT the second host pool. The phase_flip_host_pools builder stays unwritten deliberately: it does not fit (5.37 GB remainder, both pools need ~27 GB on rank 0's ratio) and the cross-phase path does not need it, since sgl-project#706 made the disk tier geometry-neutral. One code-verified correction to this doc's own earlier framing: with --phase-flip-rebind-hicache OFF, rebind_for_cutover returns None on the flag check BEFORE phase_pools_for is called, so the recommended boot logs no sgl-project#719 line AT ALL -- the previous text said the unarmed rebind refuses at every cutover. Armed without a second pool it does refuse, exactly once per cutover, logged-never-raised at ERROR level. Both expectations are stated, because an expected ERROR line is what stops a boot for no reason. Acceptance counts the prefill log line (#cached-token > 0), never cache_hit_rate, which reports 0.0 despite real hits.

…cket Two docs, both prep: no branch pointer on a real line moves here. MERGE_TRAIN_2_FOLLOWUP.md -- the follow-up train, measured against the head train 1 projects (integration/r2 + 621 + 699 + 673-lockstep + 4c84637 + 67572ce + 677 = 6bab764c33), not against r2. Order and trial-merge result: reconcile/cluster-b-seam-model clean; fix/673-teardown-stack ONE conflict, docs/dev/MERGE_TRAIN_2026-08-17.md, doc only, no source conflict anywhere in the train; fix/728-max-bytes-uniform clean. Assembled head c5a4c1bca8. Ancestry finding, which moves the kernel rebuild: 4512136 and a8b068b are ancestors of reconcile/cluster-b-seam-model (YES) and of nothing else in the train -- not of 6bab764c33, 887a6d4 or a66f5e2. So the separately listed "sgl-project#441 kernel commits" step is a NO-OP and should be struck, the sgl-kernel rebuild is triggered by step 1, and train 1 is unaffected (it merges 67572ce, which carries neither). The rebuild step is named with the runbook's wheel-pin discipline (arch list 86;120, MAX_JOBS=4, nvcc from the venv cu13 toolkit) and its acceptance is boot-gated, not desk-gated. Baselines on c5a4c1bca8, hermetic (CUDA_VISIBLE_DEVICES=""): mem_cache 1086 passed / 0 failed (1651 skipped); managers 19 failed / 2367 passed; planner 8 failed / 2842 passed (all test_webui/chess, missing optional dep); distributed 27 failed / 2764 passed vs 21 on train 1; test_scheduler_teardown_673.py 10 passed. The +6 on distributed is attributed rather than asserted. On the three implicated files: 887a6d4 9 failed, a66f5e2 9, feat/704 9, fix/602 9, fix/701-ledger-wiring 15, reconcile 15, train-2 head 15. The extra failures are pre-existing on fix/701-ledger-wiring and inherited unchanged; no merge in this train creates one. Reported as "21 pre-existing + 6 inherited from sgl-project#701", not as green. DESIGN_706_BOOT.md -- the boot-side open items are closed as a decision, and section 5 is a run-card F4-r4 can execute: preconditions, verbatim flag set, ordered steps, pass/fail by greppable log string, abort conditions. Boot WITHOUT the second host pool. The phase_flip_host_pools builder stays unwritten deliberately: it does not fit (5.37 GB remainder, both pools need ~27 GB on rank 0's ratio) and the cross-phase path does not need it, since sgl-project#706 made the disk tier geometry-neutral. One code-verified correction to this doc's own earlier framing: with --phase-flip-rebind-hicache OFF, rebind_for_cutover returns None on the flag check BEFORE phase_pools_for is called, so the recommended boot logs no sgl-project#719 line AT ALL -- the previous text said the unarmed rebind refuses at every cutover. Armed without a second pool it does refuse, exactly once per cutover, logged-never-raised at ERROR level. Both expectations are stated, because an expected ERROR line is what stops a boot for no reason. Acceptance counts the prefill log line (#cached-token > 0), never cache_hit_rate, which reports 0.0 despite real hits. (cherry picked from commit 60414e9)

format

4fb8d63

hnyls2002 merged commit 690d162 into main May 14, 2024

hnyls2002 deleted the format branch May 14, 2024 14:40

timethink pushed a commit to timethink/sglang that referenced this pull request Mar 9, 2025

Format code (sgl-project#441)

e910d7a

Garrybest pushed a commit to Garrybest/sglang that referenced this pull request Jan 9, 2026

feat: rebuild dummy loader with weight loader (sgl-project#441)

e77cbde

* fix dummy loader

vschandramourya pushed a commit to vschandramourya/sglang that referenced this pull request Feb 3, 2026

change test partition (sgl-project#441)

105fcdb

Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

HanHan009527 pushed a commit to HanHan009527/sglang that referenced this pull request Apr 7, 2026

Fix builderr (sgl-project#441)

42eb123

Co-authored-by: zhuxingxin.0 <zhuxingxin.0@bytedance.com>

Navigation Menu

Uh oh!

Format code - #441

Format code#441
hnyls2002 merged 1 commit into
mainfrom
format

hnyls2002 commented May 14, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

hnyls2002 commented May 14, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant