Skip to content

fix: llama 3.1 405b fp8 - #714

Merged
Ying1123 merged 1 commit into
sgl-project:mainfrom
zhyncs:fix
Jul 24, 2024
Merged

Ying1123 merged 1 commit into
sgl-project:mainfrom
zhyncs:fix

Conversation

@zhyncs

@zhyncs zhyncs commented Jul 24, 2024

Copy link
Copy Markdown
Contributor

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

  1. Ensure pre-commit pre-commit run --all-files or other linting tools are used to fix potential lint issues.
  2. Confirm that modifications are covered by complete unit tests. If not, please add more unit tests for correctness.
  3. Modify documentation as needed, such as docstrings or example tutorials.

@zhyncs

zhyncs commented Jul 24, 2024

Copy link
Copy Markdown
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

{"id":"84a8d16010dd44e2b60f6423fe6624d0","object":"text_completion","created":1721835240,"model":"meta-llama/Meta-Llama-3.1-405B-FP8","choices":[{"index":0,"text":"!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!","logprobs":null,"finish_reason":"FINISH_LENGTH: 100"}],"usage":{"prompt_tokens":8,"total_tokens":108,"completion_tokens":100}}

after

{"id":"9257b9d53660410a8ce2f7ffe2c60478","object":"text_completion","created":1721835356,"model":"meta-llama/Meta-Llama-3.1-405B-FP8","choices":[{"index":0,"text":" If we want to know it, we have to look at the sky. If the sky is blue and the sun is shining, we can say that it is fine weather. If the sky is cloudy and it is raining, we can say that it is bad weather.\nIt is not always easy to say what the weather is like. Sometimes the sky is clear and the sun is shining, but the wind is blowing and it is cold. Then we can say that it is windy weather.\nIt is","logprobs":null,"finish_reason":"FINISH_LENGTH: 100"}],"usage":{"prompt_tokens":8,"total_tokens":108,"completion_tokens":100}}

@zhyncs

zhyncs commented Jul 24, 2024

Copy link
Copy Markdown
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
prefill logits tensor([ 5.2266,  2.0352,  1.0605,  ..., -5.2344, -5.2344, -5.2344],
       device='cuda:0')
prefill logits tensor([ 4.9609,  3.5312,  2.2852,  ..., -3.7344, -3.7344, -3.7344],
       device='cuda:0')
prefill logits tensor([10.2500,  3.1348,  2.1699,  ..., -2.6797, -2.6797, -2.6797],
       device='cuda:0')
prefill logits (final) tensor([[ 5.2188,  2.0312,  1.0781,  ..., -5.2188, -5.2188, -5.2188],
        [ 5.0000,  3.5625,  2.3125,  ..., -3.7344, -3.7344, -3.7344],
        [10.1875,  3.1406,  2.1719,  ..., -2.6875, -2.6875, -2.6875]],
       device='cuda:0', dtype=torch.bfloat16)

@Ying1123
Ying1123 merged commit e17deb2 into sgl-project:main Jul 24, 2024
@zhyncs
zhyncs deleted the fix branch July 24, 2024 16:38
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants