feat(kernel): route mori EP dispatch/combine to the KernelForge vendor playbook - #1191
Merged
Merged
Conversation
zili-amd
requested review from
a team,
devalshahamd and
tsrikris
as code owners
August 14, 2026 20:06
CI E2E report — ✅ Succeeded
|
zili-amd
added a commit
that referenced
this pull request
Aug 15, 2026
…phaned lock, GPU% gating, kb_path docs) A review pass on the mori dispatch/combine vendor-playbook path (#1191) surfaced four real bugs: - High: a reused (combine) result lost its optimized artifact. invoke_backend() unconditionally overwrites result["output_dir"] with the current attempt's own (empty) directory after submit() returns, and cli_workspace pointed at the git worktree while optimized_versions/ was actually written under output_dir -- so _candidate_artifact_paths() found nothing for the reused role and make_proposal() returned PARTIAL despite a real, validated speedup. Fix: align cli_workspace with output_dir (matching the convention the rest of forge_submit.py already uses), and physically stage a copy of the artifact under the reused attempt's own output_dir as a second, independent safety net. - High: an exception after claiming a vendor-playbook group's lock (e.g. subprocess.CalledProcessError from _copy_vendor_task_bundle's git calls, previously only caught as OSError, or anything else unexpected) left claimed.lock on disk with no result.json ever written, hanging every future submission for that group for the rest of the session. Fix: wrap all post-claim work in try/except so any exception always writes a failure result.json. - Medium: aggregate_gpu_pct was stamped on grouped candidates but never consulted by the hot-kernel gate, so a split load (e.g. dispatch=7%, combine=5%) could be dropped as below_min_gpu_pct on both members despite clearing the floor combined; the registry's min_gpu_pct_floor was likewise unused. Fix: add effective_hot_kernel_gpu_pct()/ effective_hot_kernel_min_gpu_pct() helpers and wire them into all three gate call sites (untried_hot_reusable_kernels(), the task_group and legacy per-kernel passes in _batch_kernel_candidates()). - Medium: the registry's _comment claimed forge_submit.py "includes kb_path in the fellow's context", but the code only ever sets KERNELFORGE_INCLUDE_MORI_KB=1. Traced into KernelForge itself: that env var is a boolean-only ablation switch with no hook to accept an external path, so kb_path was never actually passable. Fix: correct the comment instead of adding a no-op pass-through. Adds regression tests for all four: build_verification()/make_proposal() now runs on the *reused* result (not just the winner) and asserts KEEP; a new test simulates a post-claim exception and asserts submit() never raises and always writes a result; two new gate tests cover the 7%+5% aggregate scenario and the floor-still-applies case. Verified each new test actually fails without its corresponding fix, and that the full agents/kernel/tests + inference_optimizer/tests suites have identical pre-existing failure sets before/after (unrelated missing pytest-asyncio plugin and a subprocess PYTHONPATH gap in the sandbox, not this change). Co-authored-by: Cursor <cursoragent@cursor.com>
zili-amd
added a commit
that referenced
this pull request
Aug 17, 2026
…rwrite, session-locked retries, orphaned claims, double-counted benefit) A second review of the mori dispatch/combine vendor-playbook path (#1191) surfaced four more real bugs on top of the round-2 fixes, plus confirmed four smaller findings already partially addressed: - Blocking: a vendor-playbook KEEP's best_artifact_path is a copy of a KernelForge task-bundle config file, not a rewrite of the real installed operator -- apply_kernel_patch's legacy full-file-replace strategy would happily overwrite the real site-packages module with it once routed through NEEDS_REVIEW->LLM-initiated integrate, or automatically once a future fix lets vendor-playbook reach KEEP. Fix: stamp vendor_playbook_deploy_blocked on the ledger entry in record_kernel_opt(), refuse to queue it in _queue_kernel_keep(), and add a second, independent refusal in integrate_handler() (via _fill_integrate_defaults_from_state()) so an LLM-initiated integrate naming the kernel_id directly is caught too. - Blocking: the vendor-playbook lock/result cache is scoped to the whole session, so every failure branch (FORGE_PATH unset, bundle copy failure, post-claim exception) permanently retired the group for the rest of the session with no way to retry after a transient fault. Fix: cached failures now expire after _VENDOR_PLAYBOOK_FAILURE_CACHE_TTL_S (10min); cached successes remain permanent, preserving the intended one-session dedup for a genuinely concurrent dispatch+combine pair. - High: claimed.lock carried no owner/timestamp, so a holder killed by SIGKILL/OOM/node-restart left every subsequent submission polling the full wait deadline (timeout_s + 300s) before failing -- up to an hour burned per submission for a 60-minute-budget attempt. Fix: claim markers now carry {pid, claimed_at, nonce}; a claim older than its own budget (plus grace) -- or backing a failure result that has aged out of the TTL above -- is treated as abandoned and safely stolen via a nonce-verified atomic replace. - High: dispatch and combine are separate kernel_ids that both carry the identical mean_case_speedup/best_ms from one shared forge-loop session, so a benefit collector summing per-kernel-id would double-count one real measurement as two. Fix: the role that actually ran forge-loop is stamped vendor_playbook_independently_counted=True; a reused sibling is stamped False. - The vendor-playbook path reused one forge-loop run but never wrote optimization_report.md, so correctness_passed stayed False and make_proposal() could never return KEEP even when SNR validation had already passed inside forge-loop. Fix: call the same _write_report() the ordinary per-file path uses, where cli_workspace == output_dir. - _role_haystack() only applied the trailing-symbol-segment fix to `name`, not `operation` -- this repo's own convention (_task_group_contract.logical_operator_name, _bypass_report.py) is to populate `operation` with the same fully-qualified Class::method string, which would silently reintroduce the dispatch/combine ambiguity the round-2 fix already claimed to close. Fix: apply the same segment extraction to `operation`. - aggregate_gpu_pct collided with an existing task_group-level field name (tracelens_skill_runner.py, _bypass_report.py); reading it unconditionally off a candidate row would silently change every ordinary group's gating behavior if a future change ever flattened task_group data onto candidate rows. Fix: renamed to vendor_playbook_aggregate_gpu_pct everywhere it's stamped and read. - resolve_kernel_anchor_path() returned a bare relative path when FORGE_PATH was unset, which a later Path(...).resolve() would silently reinterpret against whatever the apply-stage process's CWD happened to be. Fix: always return an absolute path, anchored under $FORGE_PATH when set or a fixed synthetic root otherwise. Adds regression tests for all of the above: two new SharedState tests plus four new request_handlers tests for the deploy-blocking guard; six new tests in test_vendor_operator_playbook_mori.py covering the failure-TTL retry, claim stealing/non-stealing, the optimization_report.md write, and the independently-counted dedup flag; one new role-haystack-ambiguity test and one new absolute-path test. Full agents/kernel/tests/ (1595 passed) and the touched inference_optimizer/tests/ files pass with the same pre-existing pytest-asyncio-plugin-missing and subprocess PYTHONPATH gaps already present on the base branch. Co-authored-by: Cursor <cursoragent@cursor.com>
![github-code-quality[bot]](https://avatars.githubusercontent.com/u/9919?s=60&v=4){kind=small}
…r playbook
Mori's dispatch/combine kernels are pip-installed compiled binaries with no
rewritable device source, so classify_patchability() previously rejected
them as vendor_binary before any tuning could happen. Add a registry-based
vendor operator playbook (vendor_operator_playbooks.json +
_vendor_operator_playbooks.py) that matches these kernels by
class/operation name, disambiguating dispatch vs combine by trailing method
segment instead of substring match (both appear in
`mori::EpDispatchCombineOp::{dispatch,combine}`), and routes them to the
validated KernelForge examples/mori_ep_dispatch_combine/ task bundle
(KernelForge PR #88) instead of source rewriting.
classify_patchability() checks the playbook registry before the
vendor_binary rejection, and _finalize_candidates() aggregates GPU% across
grouped candidates so dispatch and combine are recognized as one logical
optimization target. forge_submit.py adds a _submit_vendor_playbook() path
that copies+git-inits the task bundle and uses a session-scoped lock/cache
so dispatch and combine share exactly one forge-loop session instead of
running it twice.
Fixes a result-dict field gap (total_improved, pristine_baseline_ms,
search_start_ms, etc.) that caused kernel_optimization.py's verification
pipeline to report PARTIAL/"no measurable speedup found" even when
forge-loop had validated a real speedup internally -- confirmed against a
live MI300X run that achieved a genuine 1.25x speedup.
Co-authored-by: Cursor <cursoragent@cursor.com>
…phaned lock, GPU% gating, kb_path docs) A review pass on the mori dispatch/combine vendor-playbook path (#1191) surfaced four real bugs: - High: a reused (combine) result lost its optimized artifact. invoke_backend() unconditionally overwrites result["output_dir"] with the current attempt's own (empty) directory after submit() returns, and cli_workspace pointed at the git worktree while optimized_versions/ was actually written under output_dir -- so _candidate_artifact_paths() found nothing for the reused role and make_proposal() returned PARTIAL despite a real, validated speedup. Fix: align cli_workspace with output_dir (matching the convention the rest of forge_submit.py already uses), and physically stage a copy of the artifact under the reused attempt's own output_dir as a second, independent safety net. - High: an exception after claiming a vendor-playbook group's lock (e.g. subprocess.CalledProcessError from _copy_vendor_task_bundle's git calls, previously only caught as OSError, or anything else unexpected) left claimed.lock on disk with no result.json ever written, hanging every future submission for that group for the rest of the session. Fix: wrap all post-claim work in try/except so any exception always writes a failure result.json. - Medium: aggregate_gpu_pct was stamped on grouped candidates but never consulted by the hot-kernel gate, so a split load (e.g. dispatch=7%, combine=5%) could be dropped as below_min_gpu_pct on both members despite clearing the floor combined; the registry's min_gpu_pct_floor was likewise unused. Fix: add effective_hot_kernel_gpu_pct()/ effective_hot_kernel_min_gpu_pct() helpers and wire them into all three gate call sites (untried_hot_reusable_kernels(), the task_group and legacy per-kernel passes in _batch_kernel_candidates()). - Medium: the registry's _comment claimed forge_submit.py "includes kb_path in the fellow's context", but the code only ever sets KERNELFORGE_INCLUDE_MORI_KB=1. Traced into KernelForge itself: that env var is a boolean-only ablation switch with no hook to accept an external path, so kb_path was never actually passable. Fix: correct the comment instead of adding a no-op pass-through. Adds regression tests for all four: build_verification()/make_proposal() now runs on the *reused* result (not just the winner) and asserts KEEP; a new test simulates a post-claim exception and asserts submit() never raises and always writes a result; two new gate tests cover the 7%+5% aggregate scenario and the floor-still-applies case. Verified each new test actually fails without its corresponding fix, and that the full agents/kernel/tests + inference_optimizer/tests suites have identical pre-existing failure sets before/after (unrelated missing pytest-asyncio plugin and a subprocess PYTHONPATH gap in the sandbox, not this change). Co-authored-by: Cursor <cursoragent@cursor.com>
…rwrite, session-locked retries, orphaned claims, double-counted benefit) A second review of the mori dispatch/combine vendor-playbook path (#1191) surfaced four more real bugs on top of the round-2 fixes, plus confirmed four smaller findings already partially addressed: - Blocking: a vendor-playbook KEEP's best_artifact_path is a copy of a KernelForge task-bundle config file, not a rewrite of the real installed operator -- apply_kernel_patch's legacy full-file-replace strategy would happily overwrite the real site-packages module with it once routed through NEEDS_REVIEW->LLM-initiated integrate, or automatically once a future fix lets vendor-playbook reach KEEP. Fix: stamp vendor_playbook_deploy_blocked on the ledger entry in record_kernel_opt(), refuse to queue it in _queue_kernel_keep(), and add a second, independent refusal in integrate_handler() (via _fill_integrate_defaults_from_state()) so an LLM-initiated integrate naming the kernel_id directly is caught too. - Blocking: the vendor-playbook lock/result cache is scoped to the whole session, so every failure branch (FORGE_PATH unset, bundle copy failure, post-claim exception) permanently retired the group for the rest of the session with no way to retry after a transient fault. Fix: cached failures now expire after _VENDOR_PLAYBOOK_FAILURE_CACHE_TTL_S (10min); cached successes remain permanent, preserving the intended one-session dedup for a genuinely concurrent dispatch+combine pair. - High: claimed.lock carried no owner/timestamp, so a holder killed by SIGKILL/OOM/node-restart left every subsequent submission polling the full wait deadline (timeout_s + 300s) before failing -- up to an hour burned per submission for a 60-minute-budget attempt. Fix: claim markers now carry {pid, claimed_at, nonce}; a claim older than its own budget (plus grace) -- or backing a failure result that has aged out of the TTL above -- is treated as abandoned and safely stolen via a nonce-verified atomic replace. - High: dispatch and combine are separate kernel_ids that both carry the identical mean_case_speedup/best_ms from one shared forge-loop session, so a benefit collector summing per-kernel-id would double-count one real measurement as two. Fix: the role that actually ran forge-loop is stamped vendor_playbook_independently_counted=True; a reused sibling is stamped False. - The vendor-playbook path reused one forge-loop run but never wrote optimization_report.md, so correctness_passed stayed False and make_proposal() could never return KEEP even when SNR validation had already passed inside forge-loop. Fix: call the same _write_report() the ordinary per-file path uses, where cli_workspace == output_dir. - _role_haystack() only applied the trailing-symbol-segment fix to `name`, not `operation` -- this repo's own convention (_task_group_contract.logical_operator_name, _bypass_report.py) is to populate `operation` with the same fully-qualified Class::method string, which would silently reintroduce the dispatch/combine ambiguity the round-2 fix already claimed to close. Fix: apply the same segment extraction to `operation`. - aggregate_gpu_pct collided with an existing task_group-level field name (tracelens_skill_runner.py, _bypass_report.py); reading it unconditionally off a candidate row would silently change every ordinary group's gating behavior if a future change ever flattened task_group data onto candidate rows. Fix: renamed to vendor_playbook_aggregate_gpu_pct everywhere it's stamped and read. - resolve_kernel_anchor_path() returned a bare relative path when FORGE_PATH was unset, which a later Path(...).resolve() would silently reinterpret against whatever the apply-stage process's CWD happened to be. Fix: always return an absolute path, anchored under $FORGE_PATH when set or a fixed synthetic root otherwise. Adds regression tests for all of the above: two new SharedState tests plus four new request_handlers tests for the deploy-blocking guard; six new tests in test_vendor_operator_playbook_mori.py covering the failure-TTL retry, claim stealing/non-stealing, the optimization_report.md write, and the independently-counted dedup flag; one new role-haystack-ambiguity test and one new absolute-path test. Full agents/kernel/tests/ (1595 passed) and the touched inference_optimizer/tests/ files pass with the same pre-existing pytest-asyncio-plugin-missing and subprocess PYTHONPATH gaps already present on the base branch. Co-authored-by: Cursor <cursoragent@cursor.com>
zili-amd
force-pushed
the
feature/zicanli/mori_dispatch_and_combine
branch
from
August 17, 2026 21:04
745f599 to
125d853
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
A live MI300X end-to-end run (DeepSeek-V2-Lite, TP=1/EP=8/DP=8, mori_high_throughput backend) surfaced a fifth routing gap beyond the four review-round-2 fixes: TraceLens reconstructs a graph-captured launch as a "Synthetic Op" (e.g. `vllm::moe_forward_shared-> EpDispatchIntraNodeKernel_bf16 (Synthetic Op)`) with no surviving module chain, so `library`/`source_file`/`kernel_repo` all resolve empty on the real candidate. The only field that still carries the mori identity marker is `trace_launcher_file` (the Python frame that launched the op, e.g. `.../site-packages/mori/jit/hip_driver.py`), which `_candidate_haystack()` did not check -- so `match_vendor_operator_playbook()` silently returned None and both kernels fell through to "source file not resolved" instead of routing to the playbook, even though TraceLens correctly flagged them as the #1 and #3 bottlenecks (35.8% of GPU time combined). Add trace_launcher_file to the haystack, plus two regression tests reproducing the exact real-trace candidate shape. Co-authored-by: Cursor <cursoragent@cursor.com>
github-actions
Bot
removed
the
retest
github-code-quality[bot] and github-advanced-security[bot] (CodeQL) both flagged the bare `except OSError: pass` around the scratch temp-file unlink in _steal_stale_claim() as an empty except with no explanation. The behavior is intentional (the unlink is best-effort cleanup of a file that has, by that point, already been atomically replaced onto claim_path or never fully written -- it must never raise out of a claim-stealing attempt) -- add a comment documenting why, no behavior change. Co-authored-by: Cursor <cursoragent@cursor.com>
Collaborator
|
Reviewed the full diff. The design holds up and the nine listed findings are genuinely closed in the code — the deploy refusal is defense-in-depth in both places that matter ( One thing to fix before merge. The aggregate/floor gate is a no-op on the production path in
|
…uction Tech-lead review finding on PR #1191: SharedState._build_hot_kernel_ summaries() projects each hot kernel into an explicit key whitelist (summary_entry) that becomes last_trace_analyze["hot_kernels_top15"]. That whitelist never carried patch_strategy, vendor_playbook_group_id, vendor_playbook_aggregate_gpu_pct, or vendor_playbook_min_gpu_pct_floor. untried_hot_reusable_kernels() reads hot_kernels_top15 in preference to raw hot_kernels, and hot_kernels_top15 is always populated in production, so effective_hot_kernel_gpu_pct()/effective_hot_kernel_min_gpu_pct() silently degraded to bare gpu_pct/min_gpu_pct at that call site -- the only one of the three gate call sites affected (the two in _batch_kernel_candidates read full candidate dicts off candidates_path instead, so they were never broken). This broke both directions of the intended behavior: a split-load vendor-playbook group (e.g. dispatch=7%, combine=5%) clearing a 10% floor together was still dropped as below-threshold on both members, and the playbook's own min_gpu_pct_floor was not enforced either, so a loosened HYPERLOOM_KERNEL_OPT_MIN_GPU_PCT could let a below-floor group burn a whole forge-loop session. Fix: add the four fields to summary_entry. Existing coverage (test_untried_hot_kernels_vendor_playbook_group_gated_on_aggregate/ _floor_still_applies) could not catch this because their _set_trace() helper assigns last_trace_analyze directly and never populates hot_kernels_top15, so they fell through to the unprojected raw hot_kernels list. Added two new regression tests that go through the real record_trace_analyze() entry point instead (one per direction); both fail with a KeyError without this fix and pass with it. Also strengthened the existing aggregate test's weak `assert untried` (which passed even if only one member cleared the gate) to assert the specific kernel id set, and fixed its comment, which incorrectly claimed the two rows share (source_file, name) -- they do not; the differing names (::dispatch vs ::combine) are exactly what keeps them distinct instead of collapsing under the identity-dedup fallback. Verified: the two new tests fail with KeyError without the shared_state.py fix and pass with it. Full agents/kernel/tests/ + inference_optimizer/tests/ suites show the identical 1612 pre-existing, unrelated failures (missing pytest-asyncio plugin) both before and after this change -- no regressions. Co-authored-by: Cursor <cursoragent@cursor.com>
Collaborator
Author
|
Fixed in 1a637b8 — thanks for catching this, good find. Confirmed your read exactly:
Ran the full Also waiting on |
chaojhou
approved these changes
Aug 19, 2026
chaojhou
left a comment
chaojhou
left a comment
Collaborator
There was a problem hiding this comment.
Verified the fix in 1a637b871. Both halves are there: _build_hot_kernel_summaries()'s summary_entry now carries patch_strategy / vendor_playbook_group_id / vendor_playbook_aggregate_gpu_pct / vendor_playbook_min_gpu_pct_floor, and the two new tests go through the real record_trace_analyze() entry point — one for the pass direction (7% + 5% clearing the 10% default as 12%) and one for the unsafe direction (the playbook's 10.0 floor still blocking under a loosened min_gpu_pct=1.0) — each asserting the projection actually carries the fields, which is exactly the assertion that fails without the change. The weak assert untried is now assert set(untried) == {"k010", "k011"} and the misleading comment about the rows sharing (source_file, name) is corrected.
Also checked the new keys don't disturb the surrounding logic: the kernel_roofline inclusion test just below only inspects its own key tuple (bound_type, arithmetic_intensity, ...), so a None-valued vendor field on an ordinary kernel doesn't change which rows land in kernel_roofline_top15, and breakdown/collectors/kernels.py re-projects explicit keys, so the extra keys are inert downstream.
On the Read the Docs failure — agreed, unrelated to this PR:
- the same commit passes the repo's own Sphinx build (Actions
Docsrun 32183961767,head_sha 1a637b8719b1…,build (sphinx html)green in 47s runningsphinx-build -b html docs docs/_build/html); - the fix commit touches only
shared_state.pyand one test file, and no docs file changed anywhere in the PR; - RTD succeeded on the four earlier commits of this same branch (125d853, 2bfba7c, 873a610), so neither the docs tree nor
.readthedocs.yamlis broken here; - RTD is failing intermittently on unrelated open PRs too (#1222, #1216) while a dozen others pass; and
- the failures return in 34-62s versus 78-101s for the successes, i.e. it is failing early (clone/env/install or a queue rejection), not at the end of a real documentation build.
A re-run of RTD build 4332364 should clear it; worth a glance at that build's "Installing" step if it recurs.
Approving. The four non-blocking items from my earlier pass (recommend_backends() still returning [] for a vendor_binary-typed playbook candidate, vendor_playbook_independently_counted having no production reader, both roles consuming a top-N slot, and the breadth of the "mori" substring marker now that trace_launcher_file is in the haystack) are fine to leave for follow-ups. The one worth filing alongside the GPU-exclusivity item is the deployability gap: with integrate refused, a vendor-playbook KEEP is measured but never shipped, so the tuned launch config has no route to a live server yet.
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
3 participants
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.
Summary
Mori's EP
dispatch/combinekernels are pip-installed compiled binaries with no rewritable source, soclassify_patchability()used to reject them asvendor_binarybefore any tuning could happen (KernelForge PR #88). This adds a vendor operator playbook: a registry that recognizes known vendor operators and routes them to a validated KernelForge task bundle instead of source rewriting.Implemented:
vendor_operator_playbooks.json+_vendor_operator_playbooks.py— registry + matcher, disambiguatesdispatchvscombineby trailing method segment, routes toexamples/mori_ep_dispatch_combine/.tracelens_analysis.py—classify_patchability()checks the registry before rejecting asvendor_binary; groups dispatch+combine into one aggregate GPU% target.forge_submit.py— new_submit_vendor_playbook()path with a session-scoped lock so dispatch and combine share one forge-loop session instead of running twice.kernel_optimization.pyreportPARTIAL/no-speedup even when forge-loop had validated a real speedup internally.Bugs found & fixed during review (4 rounds, 10 total, all with regression tests)
cli_workspace/output_dir; added a physical artifact copy as a safety netaggregate_gpu_pctcomputed but never used for gatingkb_pathdoesapply_kernel_patch's legacy full-file-replace and overwrite the real installed operator{pid, timestamp, nonce}and are safely stolen once stale_candidate_haystack()didn't checktrace_launcher_file, so graph-captured kernels (the real production trace shape) never matched the registry at all_build_hot_kernel_summaries()'s key whitelist droppedpatch_strategy/vendor_playbook_*fields, sountried_hot_reusable_kernels()silently degraded the aggregate/floor gate to baregpu_pcton the real production path (hot_kernels_top15) — losing both the split-load pass-through and the playbook's own floor enforcementrecord_trace_analyze()entry point (existing tests bypassed the projection and couldn't catch this)Testing
test_vendor_operator_playbook_mori.py18/18 passing. Fullagents/kernel/tests/+inference_optimizer/tests/suites checked before/after the latest fix: identical pre-existing, unrelated failure set both times (missingpytest-asyncioplugin) — no regressions.combine_zero_copy=True, tuned block/warp grid), correctness PASS against mori's own reference test-suite math, single-session dedup confirmed (combine reused dispatch's cached result in 0.1s). This is the run that proves mori is actually re-tuned by KernelForge, with a real measured win, end to end.mori_high_throughput): proves the automatic half of the pipeline off a real serving trace, with zero manual intervention — TraceLens classified dispatch+combine asvendor_playbookon its own (42.7% aggregate GPU%), the orchestrator transitionedPRELUDE → KERNEL_AGENT,forge_submitresolved the target and spawned a real forge-loop subprocess (fresh git worktree, aiter-cache,claude-opus-5implementer/supervisor), and thecombinecandidate correctly deduped onto the same session instead of spawning its own. forge-loop's baseline benchmark then hit a native abort inside mori's own compiled shmem library (ShmemStates::CheckStatusValid(), ×8 ranks) before a clean timing round could complete — so this run does not produce a second measured speedup, but the crash trace itself is further confirmation that mori's real operator construction path was reached (not mocked). Handled safely by the orchestrator (REVERT,crash_count: 0, no stuck lock) — see "Known follow-up" below.ci-e2e(a transient CI-infra disk-quota fault on the first run was unrelated to this PR's code — cleared on retest).Known follow-up (not blocking)
On the full production run, forge-loop's own baseline benchmark crashed with a native abort inside mori's shmem library (
ShmemStates::CheckStatusValid()). Handled safely —REVERT,crash_count: 0, no stuck lock, no false-positive speedup — but this specific task bundle couldn't produce a measured speedup on that run.Root cause is most likely resource exclusivity, not a missing rendezvous: mori's
shmemis a GPU-initiated symmetric-memory heap shared across all ranks on a node, anddriver.pyalready does its own complete standalonedist.init_process_group+shmem_torch_process_group_init— it doesn't depend on an external process group. The live vLLM server being optimized was still serving on the same 8 GPUs when forge-loop's driver tried to claim its own independent 8-rank mori heap on top of it; two competing mori-EP groups can't coexist on one 8-GPU box. A real fix means pausing/releasing the live server's GPU allocation around this class of kernel_opt attempt (or routing distributed collective kernels to a phase where the GPUs are guaranteed free) — an orchestrator-level coordination change, not adriver.pypatch, and risky to rush (a botched pause/resume could hang a live production server, a worse outcome than today's safe no-op). Filed as follow-up rather than patched here; not a regression risk as-is since the pipeline already fails safe.Test plan
pytest .../test_vendor_operator_playbook_mori.py -q(18/18)main)ci-e2esmoke check greenMade with Cursor