fix: llama 3.1 405b fp8 - #714
Merged
Merged
Conversation
Contributor
Author
# server
python -m sglang.launch_server --model-path meta-llama/Meta-Llama-3.1-405B-FP8 --disable-radix-cache --tp 8
# client
curl http://127.0.0.1:30000/v1/completions -H "Content-Type: application/json" -d '{"model": "meta-llama/Meta-Llama-3.1-405B-FP8", "prompt": "What the weather is like today?", "max_tokens": 100, "temperature": 0.7}'before after |
Contributor
Author
|
This fix will not affect the output of previously normal models. python3 playground/reference_hf.py --model meta-llama/Meta-Llama-3.1-8B-Instruct
python3 -m sglang.bench_latency --model meta-llama/Meta-Llama-3.1-8B-Instruct --correct --output-len 16 --trust-remote-code |
Ying1123
approved these changes
Jul 24, 2024
timethink
pushed a commit
to timethink/sglang
that referenced
this pull request
Mar 9, 2025
cen121212
pushed a commit
to cen121212/sglang
that referenced
this pull request
Nov 10, 2025
* Update run_suite.py * Update pr-test-npu-debug.yml * debug testcase * Update pr-test-npu-debug.yml * debug testcase * debug testcase * Update pr-test-npu-debug.yml * Update pr-test-npu-debug.yml * debug testcase * debug testcase * debug testcase * debug testcase * debug testcase * debug testcase * Update daily-build-test-npu-innersource.yml
efschu
added a commit
to efschu/htsglang
that referenced
this pull request
Aug 17, 2026
…nothing closed it Desk analysis of the 3x FLIP ABANDONED on 0b61699, plus the guard that makes the real state legible. 1. THE 1748-vs-1693 ARITHMETIC, reconstructed. phase_flip_runtime.py:4993-5019: usable = from_driver = max(0, driver_free - reserve) spendable = usable # allocator cache is NOT counted So "spendable" is driver-free minus the kept-free reserve, measured AFTER _reclaim_cached_blocks() has returned what it can; whatever the caching allocator still holds is deliberately excluded. The 1748 requirement comes from _staging_bytes, which is incoming + max(outgoing, local) over the WIDEST WAVE, using the same row_nbytes the move itself uses -- derived from the plan, not estimated, and waved so it scales with pool geometry rather than prompt length. I find no overcount on that side. 2. THE RUNG LINE IS ARITHMETICALLY IMPOSSIBLE, and that is the root. _floor_rows is max_live + 1 + margin_rows + admission_reserve_rows. margin_rows DEFAULTS TO 0 and is never passed at the construction site (kv_backing_relief.py:2158-2167), and admission_reserve_rows is chunked_prefill_size = 512. So floor = max_live + 513, and floor=398471 means max_live = 397,958 -- against a current cap of 137,216. A live row id 2.9x ABOVE the cap. Compare the healthy shape this module documents itself (line 875): "max_live=644 + admission reserve 512, slack=405894". There the high-water id is tiny. Here it outlived the pool it was measured in: ids from a larger id space surviving a reshard/shrink. Because slack is max(0, current - floor_rows), it pins to 0 for as long as that holds, so the rung can NEVER propose a shrink. The evict-rung funding path (sgl-project#688) is therefore permanently unavailable at this operating point, and every flip falls back on the raw seam fund alone. That is why the instance abandoned three times over 55 MiB instead of funding it from KV once -- the backstop was gone, not merely small. So: the floor FORMULA is right and its INPUT is impossible. The defect is upstream of this file, in whatever leaves live ids above the cap. 3. WHAT LANDS HERE. Only the guard: a floor above the cap now says FLOOR UNREACHABLE, names the gap in rows, and states the implication (this rung can never fund; max_live is above the cap). "slack=0" alone is indistinguishable from a rung that merely had no room this round, which is exactly the confusion this ticket started in. The healthy path is untouched and a floor exactly AT the cap is reported as tight, not impossible. I did NOT change the floor, the eviction handoff, or the live-set derivation. Re-basing live ids after a shrink/reshard is the actual fix and it sits in the area F4-r4 holds for sgl-project#715, so per the coordination rule it goes back through the operator rather than being edited here. Tests: 5, red first -- two new assertions failed, three controls (healthy shape, boundary at floor == cap, never-ran) passed before the change and still do. managers + mem_cache: 2892 passed, 0 failed. ruff clean.
efschu
added a commit
to efschu/htsglang
that referenced
this pull request
Aug 17, 2026
…ndition, not a cause Follow-up to b9f4580. F4-r4 rooted sgl-project#717 (c4e5579) and DISPROVED the framing I had put in that message. I wrote that a floor above the cap means "live row ids outliving a pool shrink/reshard". That is wrong. 397,958 is a VALID id in the ~437k id space while only 137,216 rows are backed: the live set is SPARSE, so a high-water ID above the backed-row count is normal, not evidence of staleness. max_live is an ID, not a count, and I read it as a count. The actual root was _resident_ceiling encoding "none" and "unknown" as the same -1 sentinel, so an idle box read as an unreadable split and eviction was never priced -- a sentinel-collision defect, nothing to do with rebasing. The guard itself stands and is unchanged in behaviour: whatever the cause, a floor above the cap pins slack to 0 and the rung cannot fund, which is worth naming and was invisible before. Only the diagnosis is removed. The message now states the condition and says explicitly that max_live is a high-water ID over a sparse set -- "state the fact, do not infer the cause" -- so the next reader is not sent down the road I went down. Tests unchanged, 5 passed: they assert the condition and the gap, never the cause, which is why the correction needed no test edit.
efschu
pushed a commit
to efschu/htsglang
that referenced
this pull request
Aug 22, 2026
… it is _evict_floor_rows has eight ways to return the plain, un-evicted floor: eviction disabled, an unreadable parked extent, no tree cache, an unknown resident half, a mark pinned by work in flight, a priced floor no better than the plain one, a pricing exception, and nothing evictable above the reserve. All eight produce one observable. Over a sparse live set that observable is a group-wide veto. sgl-project#714 established that max_live is a high-water ID in the id space rather than a count of backed rows, so the plain floor routinely sits ABOVE the cap; the rung then reports slack 0, and because the group's agreed shrink target must clear the HIGHEST floor in the group, this rank cancels the shrink for every rank -- including one holding a fundable plan. Measured on metal 2026-08-22: PP0 could have returned +1740 MiB from 89119 rows of slack, PP2 was under no memory pressure at all and reported fundable_bytes() == 0 on all eight of its asks, and the flip abandoned eight times. Which of the eight branches held on PP2 is not recoverable from that boot, because none of them says so. Three are healthy, one is a setting, and the rest are defects -- they want opposite responses, and telling them apart currently costs one boot per hypothesis. Every return now records its reason, and last_proposal_summary prints it whenever the rung has no slack, which is exactly when that floor is capable of being the binding term for the whole group. No behaviour change: only assignments to a new attribute and the text of one diagnostic string. Tests: test/registered/unit/managers/test_evict_floor_reason_796.py (7 new, all red before this commit -- no reason was recorded on any branch). Regression sweep over the KV rung / collective family, 159 passed: test_kv_backing_collective_631, test_kv_backing_cap_agreement_656, test_kv_rung_unreachable_floor_714, test_evict_rung_floor_invariant_717, test_evict_rung_nothing_resident_717, test_evict_rung_flip_park_744, test_kv_backing_relief_631, test_kv_backing_exhaustion_662_f4, test_kv_backing_recovery_clamp_684. ruff check, ruff format, codespell clean.
efschu
pushed a commit
to efschu/htsglang
that referenced
this pull request
Aug 22, 2026
…f liveness Branch 8 of _evict_floor_rows returned "healthy, the pool is genuinely live" for every zero that came back from evictable_rows_above, without having measured liveness anywhere. Two different conditions reach that zero and they want different answers. When the priced floor sits ABOVE the high-water row, the query asked for evictable rows in a region the tree cannot hold anything in, so the zero is a tautology. _floor_rows(x) == x + 1 + margin + reserve, so a resident ceiling within (margin + reserve) rows of the high-water lifts the priced floor past it. The guards above cover req_max >= max_live and floor >= plain; neither covers this, so it fell through to the pricing call and was mislabelled by it. This is sgl-project#714 arriving at the high-water mark rather than at the pool cap. When the floor is genuinely below the high-water, the band is real and the tree pricing nothing in it may be health or may be unowned rows. The message now names the size of the band and points at the POOL CENSUS line, which is where that is settled, instead of deciding it. Measured on boot_798_0822_0737.log while the flip stayed wedged in TP: priced floor 167440 against high-water row 164055 (empty region), and priced floor 97643 against high-water row 134148 (a real band of 36506 rows priced at nothing, against a census reporting ~94000 unaccounted rows out of a 448698-row pool). Instrumentation only: both paths return (plain, 0) exactly as the single branch did, and a test pins that equality so the ladder cannot move. Tests: 165 passed across the eight relief/floor suites (test_evict_floor_reason_796, test_arming_floor_funding_662, test_evict_rung_floor_invariant_717, test_kv_rung_unreachable_floor_714, test_kv_radix_watermark_662, test_kv_backing_relief_631, test_admission_relief_ladder_679, test_relief_rung_executor_553), ruff clean. Can-fail proven against a git archive of HEAD rather than by toggling the patch in the shared worktree: the two new assertion tests fail there ("'genuinely live' unexpectedly found", "'census' not found") while the neutrality test passes in both states.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Thank you for your contribution, we really appreciate it. The following instructions will help improve your pull request and make it easier to receive feedback. If there are any items you don't understand, don't worry. Just submit the pull request and ask the maintainers for help.
Motivation
Please explain the motivation behind this PR and the goal you aim to achieve with it.
Modification
Briefly describe the changes made in this PR.
Checklist
pre-commit run --all-filesor other linting tools are used to fix potential lint issues.