WIP: PD-DFlash Task 9 — route-ahead priority band recovered; BM3 BLOCKED (not justified, do not merge) - #167
Closed
drunkcoding wants to merge 1 commit into
Closed
WIP: PD-DFlash Task 9 — route-ahead priority band recovered; BM3 BLOCKED (not justified, do not merge)#167drunkcoding wants to merge 1 commit into
drunkcoding wants to merge 1 commit into
Conversation
…hipped) Re-implements the Task 9 route-ahead priority-band candidate that PR #161 implemented+built+validated locally then reverted (Python-only shipped) because its DFlash draft was absent. No original add/revert commit exists (verified via git log/pickaxe/fsck/stash) -- the revert was a working-tree discard -- so this restores the candidate per the plan spec to make it reviewable. C++ (core/prefetch, core/python): - task_scheduler.h: name the bands kOnDemandPriority=0, kRouteAheadPriority=1, kBackgroundPrefetchPriority=2 (NUM_PRIORITY stays 20). - EnqueuePrefetch (ordinary/background prefetch) now enqueues at background (2); EnqueuePrefetchTensors + the prefetch_tensors binding default to the dedicated route-ahead band (1). Python (expert_prefetcher.py): - add ExpertPrefetcher.route_ahead_priority (the BM3 knob, mirrors the native constants). Explicit route-ahead prefetch_experts_list issues at that band; legacy speculative_prefetch issues at background. Tests: - native GPU smoke asserts all three bands + the knob issue without raising; CPU mock tests assert explicit=route-ahead / legacy=background band mapping. BM3 was NOT run to a ship/no-ship verdict -- blocked by two issues on dev that are independent of this candidate (a 1-line EnqueuePrefetch priority + a Python knob; the native smoke swept all three bands without hanging): (A) bench_prefetch_priority._reset_cache() calls the terminal clean_up_resources() between arms, deadlocking the offload engine; the next forward hangs in fetch_tensors (model_offload.py:1670). No JSON. (B) exposed_fetch_seconds is uninstrumented, so _exposed_fetch_seconds() returns 0.0 for every arm and bm3_decision.exposed_fetch_improved can never be true -- ship_priority_band is structurally unmeasurable on dev. Per the plan's rule (no C++ ships without its paired benchmark proving the exposed window is closed) the band is NOT shipped. No false win either way. Validated (not a ship claim): SM120 build clean (0 errors); native priority smoke 5 passed on offloaded gpt-oss-20b; 60 CPU decision/mock tests passed; gpt-oss offload no-regression 9 passed.
Contributor
Author
|
Superseded by #169 (BM3 settled NO-SHIP). |
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.
WIP / DRAFT — do not merge. Off
origin/dev. Reviewable recovery of the Task 9 route-ahead priority-band candidate. BM3 did not produce a ship/no-ship verdict (blocked — see below), so per the plan's iron rule the band is NOT shipped. No false win either way.What this recovers
PR #161 states the priority-band C++ was "implemented locally, built (sm_120), and validated … then reverted" (Python-only shipped) because its DFlash draft was absent, so BM3 could not run. The draft
z-lab/gpt-oss-20b-DFlashis now cached.The reverted candidate was never committed — verified via
git log/pickaxe (-S kRouteAheadPriority),fsck --lost-found,reflog, and all stashes: no add commit, no revert commit, no dangling commit. The only hit was the plan doc's example code block. So the revert was a working-tree discard, and I re-implemented it from the plan spec (Task 9 Steps 4–5), building on the already-shippedEnqueuePrefetchTensors(tensor_ids, priority=1)(Task 8).The candidate (7 files, +131/-8)
C++ —
core/prefetch/task_scheduler.h,archer_prefetch_handle.{h,cpp},core/python/py_archer_prefetch.cpp:kOnDemandPriority=0,kRouteAheadPriority=1,kBackgroundPrefetchPriority=2(NUM_PRIORITYstays 20).EnqueuePrefetchnow enqueues at background (2) (was 1); the batchedEnqueuePrefetchTensors+prefetch_tensorsbinding default to the dedicated route-ahead (1) band.Python —
moe_infinity/memory/expert_prefetcher.py:ExpertPrefetcher.route_ahead_priority(the exact knobbench_prefetch_priority.pydrives). Explicit route-aheadprefetch_experts_listissues at that band; legacyspeculative_prefetchissues at background.Tests —
test_prefetch_native_gpu.py,test_speculative_prefetch.py:BM3 — BLOCKED (could not reach a verdict)
Two independent issues on
dev, both unrelated to this candidate (a 1-lineEnqueuePrefetchpriority change + a Python knob; the native smoke swept all three bands with no hang):bench_prefetch_priority.run_priority_ablation._reset_cache()calls the terminalarcher_engine.clean_up_resources()between arms. After the first measured generation the offload engine is torn down (has_cleaned_up_resources_=true,StopExec), so the next forward hangs forever infetch_tensors→_pre_forward_input_hook(moe_infinity/runtime/model_offload.py:1670, frominit code commit). Reproduced with a faulthandler stack dump; GEN#1 completes in ~1 s, GEN#2 (post-reset) never returns and nobm3.jsonis written. It is a native wait (evenos._exitcouldn't reap it).bm3_decision's condition (1) needsroute_ahead.exposed_fetch < default.exposed_fetch, but noexposed_fetch_seconds/get_exposed_fetch_seconds/on_demand_fetch_secondsaccessor exists on the engine/prefetcher androute_ahead_stats.as_dict()has no such key, so_exposed_fetch_seconds()returns0.0for every arm →exposed_fetch_improved = (0.0 < 0.0) = False.ship_priority_bandis structurally unmeasurable on dev (can never be true), regardless of hardware or the now-cached draft.Because BM3 cannot prove the route-ahead band lowers exposed fetch, and the plan forbids shipping any C++ hop without that proof, the band is not shipped. I did not fabricate a
ship=true(no evidence) nor a measuredship=false(the metric is unmeasured).Validation (evidence, not a ship claim)
MOE_ENABLE_SM120=1) clean, 0 errors;_store.sorebuilt; binding confirmedprefetch_tensors(..., priority=1),ExpertPrefetcher.route_ahead_priority=1.tests/python/dflash/test_prefetch_native_gpu.py→ 5 passed (3 existing + 2 new: all-three-bands + knob sweep).test_prefetch_perf_reports.py+test_speculative_prefetch.py→ 60 passed.tests/test_gpt_oss_offload_topology.py+tests/python/unit/test_gpt_oss_mxfp4_dispatch.py→ 9 passed (matches WIP: PD-DFlash Tasks 9–10 — BM3 priority band + BM4/BM5 overlap/e2e #161).To actually run BM3 later (out of scope here)
Fix
_reset_cache()to reset cache state without the terminalclean_up_resources()(Blocker A), and instrumentexposed_fetch_seconds(Blocker B, e.g. an on-demand-fetch stall accumulator on the prefetcher or a native accessor). Then rerunpython -m benchmarks.dflash.bench_prefetch_priorityon offloaded gpt-oss-20b +z-lab/gpt-oss-20b-DFlash.