Repository navigation
[Relocate] Kernel agent: move the kernel tools to their owner packages and retire HYPERLOOM_KERNEL_AGENT_ROOT - #1787
Conversation
Co-authored-by: Cursor <cursoragent@cursor.com>
The kernel tools import each other package-relatively, and every caller uses them as modules: trace_analyze starts the TraceLens and bypass analyses with `python -m`, the kernel request handlers start GEMM tuning, forge GEMM tuning and forge fusion with `python -m`, the KERNEL phase starts the GEAK runner with `python -m`, and patch apply is a plain import. The sys.path mutations, the flat-vs-package sibling-import fallbacks and the path resolution through HYPERLOOM_KERNEL_AGENT_ROOT (_kernel_agent_tool_path, _load_apply_tool) are gone, so each tool is loaded once per process under one module name. The bypass analysis, GEMM tuning and forge fusion now run under the orchestrator's own interpreter (sys.executable) like the other tools, instead of the first python3 on PATH. Packaging ships vendor_operator_playbooks.json from its new package and install_kernel_tools.sh with the inference_optimizer assets; install.sh chains to its sibling installer; CODEOWNERS, the coverage omit list, the CI TraceLens pin lookup and the docs point at the new paths. Tests import the real modules, assert the `-m` command shapes, and hold the GEAK phase at its launch gate through KernelPhase._geak_timeouts. A contract test checks that every tool module-name constant resolves to a module with a callable main. Co-authored-by: Cursor <cursoragent@cursor.com>
Nothing reads the kernel-agent source root any more: the tools load as package modules, so the variable and its KERNEL_AGENT_ROOT twin only steered the preflight env-file loader. Preflight no longer skips the kernel-agent env file when HYPERLOOM_KERNEL_AGENT_ROOT is set, and no longer uses it as the "file was sourced correctly" check. The env file is resolved from $KERNEL_AGENT_ENV or $USER_DATA_PATH/runtime/kernel-agent.env.sh on every launch; a file that yields no supported kernel-agent variable exits 2 as malformed or stale and points at install.sh. The installers stop exporting and writing both variables, the env-file and .env allowlists and the Ray runtime env drop them, and kernel_agent provenance reports this distribution's version. Both names stay in the installer and setup scrub lists so a shell that still carries them cannot leak a stale root into a fresh install. Observable effect: an operator who exported HYPERLOOM_KERNEL_AGENT_ROOT to bypass a missing env file now gets the missing-file error instead. An old kernel-agent.env.sh carrying either variable logs an "ignoring unsupported kernel-agent env key" warning until install.sh rewrites it; a stale KERNEL_AGENT_ROOT line in .env logs the matching .env warning until it is deleted by hand (install.sh does not remove it). Co-authored-by: Cursor <cursoragent@cursor.com>
…kage trace_analysis/tests is a package, so test_analysis_md reaches its sibling as .test_bypass_report. The bare name only resolved while the old agents/kernel/tests directory, which had no __init__.py, was put on sys.path by pytest. Co-authored-by: Cursor <cursoragent@cursor.com>
…gent-relocate # Conflicts: # docs/reference/environment-variables.md
…ed tools test_install_image_python_path checks the kernel installer at its assets path. The absent-backends recovery test hands its stand-in runner to the phase through _GEAK_RUNNER_MODULE, now that the phase launches the runner with python -m instead of resolving a tool file path. Co-authored-by: Cursor <cursoragent@cursor.com>
CI E2E report — ✅ Succeeded
|
|
/review |
|
Automated review started for head 975d6ec. Progress: https://github.com/AMD-AGI/Hyperloom/actions/runs/37898297542 |
PR #1787 -- [Relocate] Kernel agent: move the kernel tools to their owner packages and retire HYPERLOOM_KERNEL_AGENT_ROOTWhat it does: The KERNEL_AGENT arm's tools lived under Blocking issues: none Checked: preflight.py LGTM |
…gent-relocate #1736 runs the bypass trace, GEAK GEMM and fusion tools with sys.executable and drops the command-line shells of apply_kernel_patch, diffusion_flops and diffusion_roofline. The moved tools already start as sys.executable -m, so the launch sites keep this branch's form and the tests keep main's new interpreter assertions. The shells go at the tools' new homes, and the two tests that lost their last sys use from both sides no longer import it. Conflicts: docs/reference/authentication.md docs/reference/kernel-execution-path.md src/hyperloom/inference_optimizer/assets/install.sh src/hyperloom/inference_optimizer/assets/install_kernel_tools.sh src/hyperloom/inference_optimizer/tests/test_kernel_request_handlers_units.py src/hyperloom/orchestrator/actions/executors/trace_analyze.py src/hyperloom/orchestrator/kernel/request_handlers.py src/hyperloom/orchestrator/trace_analysis/diffusion_roofline.py
What this PR doesThe KERNEL_AGENT arm's tools were located at runtime through Blocking issuesNone. What was checked
Base LGTM |
#1787 was squash-merged, so main carries its changes as one new commit instead of the branch commits this branch already merged. That commit's tree is identical to merging this branch's #1787 head (8e07325) with 82e4b51, which the previous merge already contains, so it is recorded as merged and the tree is left unchanged.
…okup AMD-AGI#1787 moved the kernel tools to their owner packages and removed _kernel_agent_tool._kernel_agent_tool_path, which the handoff test patched to stop right after handoff.json is written. The timeline is the first thing the GEAK phase touches once the file is on disk, so the test now stops there. Co-authored-by: Cursor <cursoragent@cursor.com>
* feat(gpu): support the Radeon AI PRO R9700 (gfx1201) with vLLM Register r9700 -> gfx1201 as a dispatch identity and route it to Magpie's gfx12 runner: - state, provenance and the GEAK handoff keep the product (r9700); only the Magpie materialization uses the gfx12 runner and vllm_gfx12.sh, in baseline, profile and grid runs. - product detection matches R9700 exactly; a bare gfx1201 stays product-unknown. - frameworks without a validated gfx12 runner are rejected at launch. - the targeted-build (compiled / AITER) path stays off for r9700. - the GEAK handoff carries expected_target / expected_gfx, the explicit identity pair GEAK's run_e2e accepts. Co-authored-by: Cursor <cursoragent@cursor.com> * Address review: document r9700, drop the rebaseline pair test - SKILL.md and references/frameworks.md list r9700 (runner gfx12, --framework vllm only). - Drop test_kernel_rebaseline_replays_with_the_pair: the GEAK-harness replay takes its serving identity from the recipe, not from the handoff pair, so the test asserted a field nothing reads. Co-authored-by: Cursor <cursoragent@cursor.com> * Fix the r9700 runner test after the merge: name the profile asset _default_profile_config does not exist; baseline.py exports only _default_baseline_config. The profile half of the assertion now names assets/configs/profile_vllm.yaml directly, as the sglang case above it does. Co-authored-by: Cursor <cursoragent@cursor.com> * Stop the GEAK handoff test at the timeline, not the relocated tool lookup #1787 moved the kernel tools to their owner packages and removed _kernel_agent_tool._kernel_agent_tool_path, which the handoff test patched to stop right after handoff.json is written. The timeline is the first thing the GEAK phase touches once the file is on disk, so the test now stops there. Co-authored-by: Cursor <cursoragent@cursor.com> * Align the R9700 routing tests with Magpie's native AgentX contract #1922 replaced Hyperloom's AIPerf client with Magpie's native AgentX execution, so an AgentX session no longer pins aiperf_client.sh and the two tests asserting that pin no longer describe a supported path. The gfx12 runner routing they also checked stays covered by the non-AgentX tests for materialize_config_with_envs and apply_runtime_benchmark_overrides. The baseline/profile routing test now uses the renamed default_baseline_config and materialize_benchmark_config helpers. Co-authored-by: Cursor <cursoragent@cursor.com> * Satisfy ruff and the code-metrics gate after the main merge - Format the two test files left with extra blank lines by the removed AgentX tests. - Make gpu_runner_type public in gpu_types, since the orchestrator now calls it, and rename it at every caller. - Move the R9700 targeted-build guard into _targeted_build_disabled with the existing HYPERLOOM_ENABLEMENT_DISABLE_TARGETED_BUILD switch, so both EnablementBuild entry points share one early return. Both functions get shorter; their baseline entries are lowered to match. - Read the resolved runner label back from the benchmark dict instead of a temporary, so materialize_config_with_envs does not grow. Co-authored-by: Cursor <cursoragent@cursor.com> * Keep the CLI, kernel phase and workload envs within their recorded size The code-metrics gate fails a change that grows a unit already over its baseline on main. Three modules and one function were in that position. - The runner/framework refusal and the architecture-family runner warning move to gpu_types (require_runner_framework, warn_family_runner); the CLI calls them where it did the work inline. - _resolve_handoff_gpu_identity also returns the handoff's gpu_type, so the handoff dict takes both from one entry instead of a separate update. - Same-module imports in kernel.py and _workload_envs.py share a line. Co-authored-by: Cursor <cursoragent@cursor.com> * Let an R9700 session reuse its vLLM server across rounds vllm_gfx12.sh was missing from MAGPIE_BUILTIN_SCRIPTS, so every R9700 config was ineligible for the managed server lifecycle. Each round then booted its own server, and with no reuse the baseline double run and the warm decision rounds were turned off: the baseline was measured on a cold server and candidates were graded against it. Co-authored-by: Cursor <cursoragent@cursor.com> * Give the R9700 its vendor peaks in the roofline tables HW_SPECS and the bypass roofline's _VENDOR_HW_SPECS gain an r9700 row with AMD's published dense peaks (191 TFLOPS FP16/BF16 matrix, 383 FP8, 47.8 FP32) and 640 GB/s, so the session ceiling and the bypass roofline exist on the board and are labelled "vendor". There is no 4-bit entry, so an MXFP4 model gets the memory ceiling only. The achievable tables are unchanged: those numbers are measured, and come from TraceLens. Co-authored-by: Cursor <cursoragent@cursor.com> * Report a targeted build refused on the R9700, and keep board facts in gpu_types A targeted build on a board whose build path is unvalidated is now refused where it would be enqueued, with a warning naming the board and the capability, and last_build_failure set so the next enablement mandate tells the specialist no build was attempted. A specialist request is still consumed, so it is not retried every tick. The operator's HYPERLOOM_ENABLEMENT_DISABLE_TARGETED_BUILD switch behaves as before. The unvalidated-build list and the GEAK identity pin move to gpu_types (targeted_build_validated, geak_identity_pin), so _gpu_pin and the build path no longer carry an r9700 branch of their own. Co-authored-by: Cursor <cursoragent@cursor.com> * Test the runner gate through the CLI, and drop tests of unreachable inputs - test_runner_framework_gate: a fresh R9700 session with sglang exits 2 from _seed_fresh_session, vllm passes, and _resume_session runs the gate. - Drop test_fresh_gpu_request_prefers_product_over_runner, which pinned precedence this PR does not change. - Drop the " R9700 ", "" and None handoff parameters and the two Coordinator harness tests that re-asserted the pure-function cases. Co-authored-by: Cursor <cursoragent@cursor.com> * Stub the local GPU probe in the runner-gate tests On a GPU host the local probe overrides --gpu-type, so on an MI300X host the sglang case failed and the vLLM case passed without reaching the gate. Co-authored-by: Cursor <cursoragent@cursor.com> --------- Co-authored-by: Cursor <cursoragent@cursor.com>
Description
The KERNEL_AGENT arm's tools lived under
src/hyperloom/agents/kernel/as if they were a separately installed component: callers located them throughHYPERLOOM_KERNEL_AGENT_ROOT/KERNEL_AGENT_ROOT, launched them as script files, and every tool mutatedsys.pathand carried flat-vs-package import fallbacks so it could also run outside the package. The installer already installs the whole distribution, so that standalone mode had no consumer left; it only widened what a change to the arm could break.This PR does for the kernel agent what #1655 did for the framework agent: the tools move next to the code that owns them, run as package modules, and
agents/kernel/is deleted.Where things moved (90 renames, R096–R100 except the package
__init__):agents/kernel/tools/trace-analysis tools (TraceLens and bypass routes,trace_selfcert, diffusion FLOPs / roofline,vendor_operator_playbooks.json) and their_*helpersorchestrator/trace_analysis/tools/apply_kernel_patch.py,gemm_tuning.py,forge_gemm_tuning.py,forge_fusion.py,tools/backends/geak_runner.pyorchestrator/kernel/tools/backends/ray_runtime.pyorchestrator/actions/executors/_ray_runtime.pyscripts/install.shinference_optimizer/assets/install_kernel_tools.sh, chained frominstall.shtests/How the tools run now.
trace_analyzestarts the TraceLens and bypass analyses, the kernel request handlers start GEMM tuning, forge GEMM tuning and forge fusion, and the KERNEL phase starts the GEAK runner, all assys.executable -m hyperloom.orchestrator.<package>.<tool>. Patch apply is a plain import._kernel_agent_tool_path,_load_apply_tool, thesys.pathmutations and the sibling-import fallbacks are gone, so each tool is loaded once per process under one module name.HYPERLOOM_KERNEL_AGENT_ROOT/KERNEL_AGENT_ROOTare retired. After the move nothing reads a kernel-agent source root; the variables only steered the preflight env-file loader. Preflight now resolves the env file from$KERNEL_AGENT_ENVor$USER_DATA_PATH/runtime/kernel-agent.env.shon every launch, and a file that yields no supported kernel-agent variable exits 2 and points atinstall.sh. The installers stop writing both variables; the env-file and.envallowlists and the Ray runtime env drop them. Both names stay in the installer andsetupscrub lists, so a shell that still exports them cannot leak a stale root into a fresh install.CODEOWNERS (same owners, new paths), the coverage omit list, the CI TraceLens pin lookup, package data and the docs follow the move.
The stacked follow-up #1791 removes the rule copies the tools kept only for standalone mode (
trace_analysis/_paths.py, the_io_utilscopies ofhyperloom.commonhelpers,apply_kernel_patch.known_target_roots).orchestrator/actions/executors/tests/test_kernel_tool_entry_points.py: every module-name constant a caller launches resolves to a module with a callablemain.-mcommand shapes; the GEAK phase tests hold the phase at its launch gate throughKernelPhase._geak_timeouts(inference_optimizer/tests/_geak_helpers.py).test_install_image_python_pathchecks the kernel installer at its assets path, and the absent-backends recovery test intest_geak_resume_recovery.pyhands its stand-in runner to the phase through_GEAK_RUNNER_MODULE.main:ruff checkandruff format --checkon the 133 changed Python files;pyteston the contract test,test_profile_and_kernel_handlers.py,test_preflight_auth_override.py,orchestrator/phases/tests, the GEAK tests, and theapply_kernel_patch, trace-analysis and framework-path slices. The local machine is Windows, where tests that assume POSIX paths, bash or a UTF-8 locale fail; each failing case was rerun onorigin/mainin the same environment and fails identically there. The one difference istest_trace_analyze_handler_dry_run_returns_structured_result, which fails onmain(it shells out to apythonthat is not on PATH) and passes here (sys.executable).test_kernel_integrate_and_report.pyran to 74% before its psutil process scan made each remaining case take minutes on Windows. After the latestmainmerge, the same comparison over the preflight, profile, request-handler, GEAK-recovery and installer tests shows no new failure, andpytest --collect-onlyover every test path collects all modules except those needingresource,hypothesisorcoverage, which this environment lacks. CI is the Linux authority.-mhave to land together, because a moved file breaks every caller that launches it by path; retiring the variable is the same change seen from the operator's side, because once the tools are package modules it points at nothing._kernel_agent_tool_path,_load_apply_tool); per-toolsys.pathmutation and flat/package import fallbacks; per-testspec_from_file_locationloaders.kernel-agent/runs, thetool_versions["kernel_agent"]key); the kernel-agent env file's name and location.-mcommand-shape assertions.<python> -m hyperloom.orchestrator.trace_analysis.tracelens_analysis …(and likewise for the other tools) instead of a path underagents/kernel/tools/.python3came first on PATH, which need not be the interpreter the session's packages are installed in.HYPERLOOM_KERNEL_AGENT_ROOTno longer bypasses a missing kernel-agent env file: the operator gets the missing-file error. An env file that yields no supported variable exits 2 instead of being treated as loaded.kernel-agent.env.shcarrying either variable logsignoring unsupported kernel-agent env keyuntilinstall.shrewrites it; a staleKERNEL_AGENT_ROOTline in.envlogs the matching.envwarning until it is deleted by hand (install.shdoes not edit.env).tool_versions["kernel_agent"]reports thehyperloom-inference_optimizerdistribution version, likebypassandforge, instead of the short git SHA of$HYPERLOOM_KERNEL_AGENT_ROOT, which was empty whenever the variable was unset or the root was not a git checkout.hyperloom.agents.kernel.tools.*import paths and running a tool by file path are gone (usepython -m hyperloom.orchestrator.trace_analysis.<tool>orhyperloom.orchestrator.kernel.<tool>), and the two environment variables are no longer read. No caller in this repo remains on the old paths.