feat(kernel_workflow): from-analysis variant workflow

[iraj465]

Summary

Adds kernel_workflow/kernel_workflow_from_analysis.js, a GEAK v4 workflow variant that starts from a pre-computed TraceLens/HL analysis instead of running v4's own Analyze/Profile phases.

• A new Seed phase reads ONLY analysis_md_path + kernel_candidates_path (the same two files that feed GEAK v3) plus the authoritative dispatch_prompt_path (verbatim HL build_prompt() output: device source + captured serving shapes + #703 WORKLOAD CONTEXT), and maps them into v4's roadmap — no rocprof / re-trace / re-profile.
• Benchmark (harness build), Optimize, Verify, Merge, Report are byte-identical to stock kernel_workflow.js.

Why

For a controlled GEAK v3 vs v4 optimizer comparison, both must consume identical info; only the optimization engine should differ. Stock v4 re-derives its own analysis, which breaks apples-to-apples. This variant feeds v4 the exact analysis/candidates/prompt v3 received.

Usage

Invoke via the Claude Code Workflow tool with args: kernel_path, analysis_md_path, kernel_candidates_path, dispatch_prompt_path, seed_target (tgNNN), budget, gpu_ids. Run once per target kernel.

[iraj465]

GEAK v4 results via this from-analysis variant (HL + TraceLens driven)

These runs use this PR's kernel_workflow_from_analysis.js as the per-kernel optimizer, consuming HL+TraceLens output (analysis.md + kernel_candidates.json + the #703 enriched dispatch prompt). HL owns trace/serve/TraceLens/EXPLORE/SWEEP; GEAK v4 is invoked per-kernel and builds its own harness in an isolated EVAL_DIR.

meta-llama-Llama-3.1-8B-Instruct (SGLang, TP=1, ISL/OSL=1024, conc=64)

Dispatch funnel: TL identified 11 (6 hot + 5 skipped) → HL editable task_groups 3 (attention_paged_ragged, dynamic_per_tensor_quant, silu_and_mul) → 2 dispatched (k001 paged_attention 47.3%, k007 dynamic_per_tensor_quant 16.3%). silu_and_mul (2.7%) gated below the 3.0% min-GPU% threshold. Identical dispatch set to v3.

Invoked successfully: 2/2 ran fully (attention 2 rounds, quant 6 rounds). v4 builds its own harness → sidestepped the AITER_META_DIR routing bug (issue #715).

Improved patch (X/Y) → 2/2:

Kernel	GPU%	Verified speedup
paged_attention (k001)	47.3%	1.0096× ✅ director-verified (host-runtime wrapper-invariant cache, enqueue 60µs→33µs; ctx=1024/2048)
dynamic_per_tensor_quant (k007)	16.3%	1.0728× ✅ director-verified (6 rounds; fused single-pass at the real captured (64,4096) shape)

Headline: the #703 WORKLOAD CONTEXT fixed v4's ctx-guess (baseline guessed ctx=18401 → no-win 0.9995×; enriched used the real ctx=1024/2048 → real 1.0096× win).

% E2E (gate-less apply_and_bench, engagement-proof=true):

Config	Baseline	Patched	Delta
quant patch alone	5318.4 tok/s	5211.5 tok/s	−2.01%
both patches combined	5209.2 tok/s	5233.8 tok/s	+0.47%

Both engaged=true on the live serving path. Combined +0.47% — modest, Amdahl-bounded (Llama TP=1 is host/decode-bound, ~55% GPU), but positive with both kernels confirmed live.

gpt-oss-120b (vLLM, TP=4)

Dispatch funnel: TL identified 7 P-items → HL editable task_groups 2 (moe_triton_unfused_up, custom_ar::all_reduce) → 2 dispatched (tg002 MoE 34.9%, tg001 all_reduce 65.1%). tg003 gemm (2.05%) gated below 3.0%. MoE is dispatchable only via the triton_kernels source-root allowlist env.

Invoked successfully: 2/2 ran fully (both validation_status=accepted; MoE 2 rounds, all_reduce 3 rounds; budget 6/6). 1 GPU per kernel.

Improved patch (X/Y) → 2/2 (director-verified):

Kernel	GPU%	Verified speedup
MoE up-proj (k007)	34.9%	1.1536× (geomean; arith 1.1620×), 2 rounds — shape-aware tile spec in opt_flags.py: decode tpe_8_16_128/num_stages=1 (~1.28× on M64), prefill_128_128_128 (~1.07×)
all_reduce (k001)	65.1%	1.0068× (director geomean; tech_lead 1.0216×), 3 rounds — floor-dominated/comm-bound, flat as analysis predicted

Headline: #703 WORKLOAD CONTEXT gave v4 the real M=64 decode shape, and v4's MoE patch is a clean, import-safe opt_flags.py heuristic change (unlike a v3 attempt that broke vLLM with a circular import).

% E2E (gate-less apply_and_bench, vLLM TP=4, engagement=true):

Config	Baseline	Patched	Delta
MoE patch alone (3-rep)	2870 tok/s	2704 tok/s	−5.8% (noise — distributions fully overlap)

Notes

• Kernel speedups here were scored on GEAK v4's director-verified harness; E2E deltas are Amdahl-bounded on these host/decode-bound configs.
• This validates the per-kernel from-analysis boundary: HL+TraceLens does profiling/analysis/EXPLORE/SWEEP, GEAK v4 optimizes each dispatched kernel from that prior.

[iraj465]

Recommendation: this path (#306 + HL apply) is the most robust for integration

Summarizing the code-level comparison vs the e2e_workflow path (#312), on the axes that determine robustness:

1. Deploy capability — the decider. #312's deploy mechanism (e2e_workflow/scripts/overlay_setup.py) is a Python sitecustomize.py monkeypatch — no .cu/.cuh, AITER_REBUILD, hipcc/nvcc, cpp_itfs, jit/build, or .so handling. It cannot deploy a device .cu/CK kernel win into a live server (Hyperloom #717). The path this PR hands off to — HL's apply_and_bench → apply_kernel_patch — does: drops the prebuilt fused .so, sets AITER_REBUILD=1, invalidates jit/build + cpp_itfs caches, and verifies a fresh rebuild. On aiter/CK serving paths most GPU time is device kernels, so this is the capability that matters. #306 + HL apply is a strict superset on deploy.

2. Measurement trustworthiness. HL's path adds byte-exact reconstruction, engagement-proof (patch actually on the live path), warmup-discard, fixed dataset seed across arms, ≥5-rep IQR significance, TPOT, process-scoped teardown, and manifest-based revert. The e2e_workflow's kernel deploy underneath has none of these (its Integrator interleaved-A/B + parity is solid for config sweeps, not the kernel apply).

3. Validation. This PR has two workloads of real results (Llama-3.1-8B: attention 1.0096× / quant 1.0728× director-verified, combined E2E +0.47%; gpt-oss-120b: MoE 1.1536× / all_reduce 1.0068×, both accepted) — each through HL+TraceLens + gate-less apply_and_bench (engagement=true). #312 currently has no end-to-end results.

4. Blast radius. This is one additive entrypoint that returns a patch; the already-battle-tested orchestration (HL+TraceLens trace/serve/explore/sweep) stays in charge.

The one piece #312 does better — and it's portable: its profiler discipline of "analysis.md shapes are unreliable → reconcile against a live trace capture." That matches a real bug (v4 decode-ctx guessed 18401 vs the true 1024; attention shapes GEMM-flattened). I'll fold that shape-reconciliation guard into this PR's Seed/handoff (preferably in HL's dispatch-prompt construction, with a defensive backstop here).

Net: integrate #306 + HL apply as the per-kernel boundary (most robust, .cu-capable, with results); port #312's shape-reconciliation rule into this handoff; keep #312's TraceLens-fast-path for standalone GEAK-e2e usage. Detailed gap list + suggestions are on #312.