Hyperloom Qwen3-8B 3h Framework-Only (No-Kernel) Run
Load .env with the preamble below and resolve HYPERLOOM_SKILL_PATH. Read and follow the optimizer skill at @${HYPERLOOM_SKILL_PATH} before launching. If HYPERLOOM_SKILL_PATH is missing, fall back to @hyperloom/inference_optimizer/SKILL.md (wheel install) or @src/hyperloom/inference_optimizer/SKILL.md (source checkout). This skill provides the concrete workload and launch constraints for a short Qwen3-8B demo.
Execution Shell
Run this in the current Hyperloom workspace before setup or runtime installation. Repeat it in each new execution shell, including inside Docker; the shared loader fills dotenv gaps without replacing existing non-empty exports.
bashset -e export REPO_ROOT="$(pwd -P)" INSTALL_SH="${REPO_ROOT}/hyperloom/inference_optimizer/assets/install.sh" if [ ! -f "$INSTALL_SH" ]; then INSTALL_SH="${REPO_ROOT}/src/hyperloom/inference_optimizer/assets/install.sh" fi . "${INSTALL_SH%/*}/runtime_env.sh" load_dotenv_no_clobber
Run Mode
Resolve the run mode before launching Hyperloom:
- If
HYPERLOOM_RUN_MODE=baremetalor it is unset, run this demo directly on the host. - If
HYPERLOOM_RUN_MODE=docker, this skill owns the Docker setup. Ask the user whether they want avllmorsglangDocker image unlessHYPERLOOM_IMAGEis already set. Use a ROCm image that already contains the selected framework; do not install the framework inside Docker.
In docker mode:
- If
hyperloom-setupalready ran, do not re-run setup on the host. - Read
HYPERLOOM_DOCKER_TARGET_HOSTfrom.envwhen present. If it names a host different from$(hostname), first SSH to that host and continue this Docker setup there; do not start Docker on the login/current host. - Always run setup inside the container after
docker run. - Pass
--install-framework none --yesin the container (ROCm/framework comes from the image). Do not use--skip-base-check— let Phase 1 preflight validate the container environment. - Do not run
python -m hyperloom optimizeon the host.
Prior workload cleanup (required)
Before any replacement launch after a failed or abandoned demo run (docker run,
install.sh, or a new/fresh optimize), follow IR-1 — Prior workload cleanup
gate in @${HYPERLOOM_SKILL_PATH}. Run all probes on the docker host; never
skip the user-approval step (#1314).
Suggested Docker images:
vllm:docker.io/rocm/vllm:rocm10.0.0_ubuntu24.04_py3.14_pytorch_2.12.0_vllm_0.27.0sglangMI300X:docker.io/lmsysorg/sglang-rocm:v0.5.21-rocm10-mi30x-20261008sglangMI355X:docker.io/lmsysorg/sglang-rocm:v0.5.21-rocm10-mi35x-20261008
In Docker mode, start a long-running container on HYPERLOOM_DOCKER_TARGET_HOST
(or the current host when it is unset) before running setup or optimize:
bashexport REPO_ROOT="$(pwd -P)" docker run -d \ --name "${HYPERLOOM_CONTAINER_NAME:-hyperloom-local}" \ --shm-size "${HYPERLOOM_SHM_SIZE:-64g}" \ --entrypoint tail \ --device /dev/kfd \ --device /dev/dri \ --group-add video \ -v "$REPO_ROOT:$REPO_ROOT" \ "$HYPERLOOM_IMAGE" \ -f /dev/null
Mount the Hyperloom workspace at the same absolute path (-v "$REPO_ROOT:$REPO_ROOT") so paths in .env, logs, and session artifacts stay valid. If USER_DATA_PATH or a pre-downloaded model directory is outside the workspace, add matching -v host_path:host_path mounts before starting the container.
Then run the setup backend inside the container:
bashdocker exec -w "$REPO_ROOT" "${HYPERLOOM_CONTAINER_NAME:-hyperloom-local}" bash -lc \ 'REPO_ROOT="$(pwd -P)"; PYTHONPATH="$REPO_ROOT" python3 -m hyperloom setup -- --install-framework none --yes'
After that, run all remaining commands for this demo inside the same container with docker exec -w "$REPO_ROOT" ...; do not run python -m hyperloom optimize on the host in Docker mode.
Do not use docker exec -d to launch optimize. Detached docker exec
discards stdout and stderr, so an optimizer that dies on startup looks like
"backgrounding does not work." Use one attached
docker exec -w "$REPO_ROOT" "${HYPERLOOM_CONTAINER_NAME:-hyperloom-local}" bash -lc '…' that
runs the Launch recipe in @${HYPERLOOM_SKILL_PATH}. Startup preflight loads
kernel-agent.env.sh; do not source it. Under Claw, hand that attached exec
to the bash tool with run_in_background=true and no setsid, nohup, or
trailing &; otherwise the command inside the exec is
setsid nohup … > "$RUN_LOG" 2>&1 < /dev/null & plus --launch-info-file.
Confirm with pgrep -af 'hyperloom optimize'. If nothing
is alive or the launch-info JSON has no .session_dir, read the run log and
fix that error; do not retry with a different backgrounding trick.
When the demo is finished, ask the user whether to stop the container. If they say yes, run:
bashdocker stop "${HYPERLOOM_CONTAINER_NAME:-hyperloom-local}"
Environment
-
MODEL_PATH=<optional; if unset, download Qwen/Qwen3-8B from Hugging Face with the Python steps below, then set MODEL_PATH to that local path> -
FRAMEWORK=<provided by the existing environment or repository-root .env; do not invent it> -
GPU_TYPE=<do not set; omit --gpu-type and let Hyperloom auto-detect from ROCm/system info>Required optimize CLI flags: -
--tp 1 -
--conc 64 -
--isl 1024 -
--osl 1024 -
--precision bf16 -
--target-gain 30 -
--max-hours 3 -
--phase-budget-framework-pct 0.50 -
--phase-budget-sweep-pct 0.01 -
--no-kernel -
--no-enable-conc-sweep -
--no-enable-roofline
Before launch, read the repository-root .env file if it exists and load the needed environment variables from it, such as LLM API keys/base URLs, FRAMEWORK, and HF_TOKEN. Do not copy secret values into the prompt, terminal output, reports, or logs. Do not modify USER_DATA_PATH.
Before resolving or downloading any model, always ask the user which model path to use. Present the currently resolved option when MODEL_PATH is already set, and always offer a custom local path plus the demo default. Do not continue until the user chooses one.
Use this decision flow:
- If the user chooses the existing
MODEL_PATH, inspect that path and use it only when it containsconfig.json; otherwise ask again for a valid path or the demo default. - If the user provides a custom local path, export
MODEL_PATHto that path and requireconfig.jsonbefore launch. - If the user chooses the demo default, set
MODEL_PATH=${REPO_ROOT}/.cache/hyperloom-models/Qwen3-8Band downloadQwen/Qwen3-8Bthere whenconfig.jsonis not already present.
Do not assume the Hugging Face CLI exists; resolve or download the selected model with Python:
bashpython -m pip install -U huggingface_hub export REPO_ROOT="$(pwd -P)" export MODEL_PATH="${MODEL_PATH:-${REPO_ROOT}/.cache/hyperloom-models/Qwen3-8B}" python - <<'PY' import os from pathlib import Path from huggingface_hub import snapshot_download target = Path(os.environ["MODEL_PATH"]).expanduser() if (target / "config.json").is_file(): print(f"Using existing model at {target.resolve()}") else: snapshot_download( repo_id="Qwen/Qwen3-8B", local_dir=str(target), ) print(target.resolve()) PY
Pre-launch Runtime Install
Before the first optimize launch, run the full runtime installer in the same
environment that will launch the optimizer. This is required even for this
--no-kernel demo: preflight loads kernel-agent.env.sh before it can reach the
later Ray/Magpie/InferenceX auto-install checks.
For Docker mode, run this inside the container. For bare-metal mode, run it on the host:
Use the execution-shell preamble first, then run:
bashload_dotenv_no_clobber : "${USER_DATA_PATH:?USER_DATA_PATH missing}" export USER_DATA_PATH export PYTHONPATH="${REPO_ROOT}:${PYTHONPATH:-}" ulimit -Sn 65536 || true bash "$INSTALL_SH"
The optimizer's startup preflight loads kernel-agent.env.sh in process;
do not source the generated file in the launch shell.
User-visible Progress
Keep the user informed with concise status updates throughout the demo. Do not dump full debug logs into chat; report the important values and paths so the user can tell that work is progressing.
Before launch, report the launch plan:
- model path and whether it is an existing local model or a downloaded default;
- run mode (
baremetalordocker) and target host/container when applicable; - framework, TP, concurrency, ISL, OSL, precision, max hours, and required demo flags;
USER_DATA_PATHand where runtime artifacts will be written.
After the runtime install, report whether it succeeded and the path to
kernel-agent.env.sh. After starting the optimizer, report:
- optimizer PID;
- run log path;
- launch-info JSON path;
- resolved session directory;
state.jsonpath;- initial health check result.
On each requested status check, read persisted state and print a short summary. Use platform-scheduled invocations if recurring checks are requested; do not start a background watchdog, hold a blocking polling connection, or auto-resume. Busy logs alone are not evidence of useful progress. Include:
- process alive/stopped;
- phase and
stop_reason; - baseline throughput, current best throughput, and cumulative gain when present;
- latest benchmark result or candidate decision when available;
- the most relevant recent log lines, excluding secrets.
When the run finishes, report the final status, final report path, best result, and the stop reason. Never print API keys, tokens, or custom header values.
Launch Requirements
- Run the pre-launch runtime install above; startup preflight loads the generated runtime environment in process.
- Keep
PYTHONPATH="$REPO_ROOT:${PYTHONPATH:-}"in the launch shell so critic subprocesses can importhyperloom.agentsafter changing cwd. - Run it detached the way the harness understands: if
$CLAW_SESSION_IDis set and your bash tool takes arun_in_backgroundparameter, hand the optimizer command to it withrun_in_background=true, without shell-level detachment (setsid,nohup, or a trailing&); otherwise usesetsid nohup ... &. See the Launch section of the packagedhyperloom/inference_optimizer/SKILL.mdfor why — a hand-detached run is invisible to Claw and its sandbox is reclaimed about fifteen minutes after the turn ends. In Docker mode that launch still runs inside one attacheddocker exec … bash -lc; neverdocker exec -d. - Pass all required optimize CLI flags in the
python -m hyperloom optimizecommand. Do not rely on.envalone forTP,CONC,ISL,OSL, orPRECISION: the flag is the top of the ladder, while a value reaching the environment from.envis indistinguishable from one a previous run left there, and on--resume-fromthe session's recorded workload outranks it. - Include
--phase-budget-framework-pct 0.50and--phase-budget-sweep-pct 0.01in the optimize command. These are the value before redistribution: with--no-kernel, KERNEL_AGENT is disabled and its freed share is added on top, so0.50becomes ~0.99 of wall clock for FRAMEWORK_AGENT. Raising0.50buys almost nothing — the post-redistribution share is capped at a full wall clock, and the excess is discarded. Do not pass--no-framework-agent— that skips OPTIMIZE entirely. - Include
--no-kernelin the optimize command so the Kernel Agent phase is skipped. - Include
--no-enable-conc-sweepin the optimize command so the SWEEP-phase post-optimization concurrency sweep is skipped. - Include
--no-enable-rooflinein the optimize command so PRELUDE uses the lighter profile path instead of roofline analysis. - Report the session ID, log path, PID, and initial health check result.
- Inspect persisted state on requested status checks; report when work stops.
- After diagnosing an unexpected crash and obtaining explicit resume approval, only run
optimize --resume-from "$SESSION_DIR"against the same session dir. After the first launch, never start a newoptimize; that creates a new<UTC_ts>session and is forbidden. - If
stop_reasonin the current sessionstate.jsonis final, stop and exit.


