Repository navigation
hyperloom custom: the report names the drafter it measured with, and the rep count behind its medians - #978
Conversation
…the rep count)
`HL_DFLASH` does not decide what drafts: `serve_lever_args()` hands `--dflash` the file
`HL_DFLASH_GGUF` names, defaulting to the relative path `dflash.gguf`, and `HL_MTP_HEAD`
substitutes an external head. `levers()` echoed neither, and this model has two drafter quants
on this box (q8_0, q4k), so the 50.87 best of record (`HL_DFLASH=1 HL_MTP_MAX=6`) reports
`{"HL_DFLASH": "1"}` and its drafter is recoverable only from that session's serve.log line 29.
The tuner already treats the pair as one configuration: it drops a drafter-quant variant because
overwriting `HL_DFLASH_GGUF` "would make its number incomparable to the baseline" (18:14:39).
Same for the rep count: the pp512/tg128 medians are over `-r HL_REPS` (default 3), never recorded.
Before (arm of record, 2026-11-01 00:31):
bench_summary keys: levers, placement, pp512_tok_s, runner_type, score_geomean, serve_tok_s,
tg128_tok_s -- no drafter, no reps
After, on this box with the real file:
"drafting": {"dflash": {"env": "HL_DFLASH_GGUF",
"path": ".../DFlash2/Qwen3.8-27B-DFlash2-q8_0.gguf",
"sha256": "68bc4dfd72f9864c5d0b07fa72620c9c3ab5df43a61729d8fdfd826d034f2f58"}}
"llama_bench_reps": 3
closes #977
|
CI is green on |
bong-water-water-bong
left a comment
There was a problem hiding this comment.
READY.
$ python3 tests/hyperloom_benchmark_test.py
hyperloom_benchmark_test: OK (rc 0)
and the new arm discriminates rather than just running: it writes two real drafter files and asserts the reported path and sha256 follow HL_DFLASH_GGUF when it is set, that env reads HL_DFLASH_GGUF rather than default, that dflash_gguf_arg() — the value serve_lever_args() actually hands --dflash — is the same string the report names, and that unset gives an absolute resolved default with sha256 is None for a file that is not there. That is the pair that matters: one definition (dflash_gguf_arg()) feeds both the serve command and the artifact, so "the report cannot name another" is structural, not a comment.
Read: drafting_identity() returns {} unless a drafter is in use, and mtp_head is recorded only when HL_MTP_HEAD is set and DFlash is off, so an arm without a drafter gains no key and no existing result changes shape. llama_bench_reps in bench_summary is the same class of gap and correctly adjacent. Recording "env": "default" rather than leaving the default unnamed is what makes {"HL_DFLASH": "1"} a configuration rather than a guess.
Nit: the docstring cites run-26030.log and ~/models/qwen38/DFlash2/{q8_0,q4k}.gguf — both are box-local paths; the README's new paragraph is the durable half, so make sure it names the two quant files (it looks like it does).
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT: READY
Own diff at 6c94f73a6: benchmark.py +81/-4 (plus docs), and it is the right shape — one definition feeds both the
argv and the report, so they cannot disagree: dflash_gguf_arg() is now the single source for what --dflash is handed
(:233) and for what the result names (:248, drafting_identity()).
Exercised the new identity function directly at this head (real environment permutations, real file):
HL_DFLASH unset -> {} (nothing to name)
HL_DFLASH=1, default relative name -> dflash env=default path=/tmp/ldtest/sub/dflash.gguf sha256=a21d7524…
HL_DFLASH_GGUF=/…/dflash.gguf -> dflash env=HL_DFLASH_GGUF path=/…/dflash.gguf sha256=a21d7524…
both set -> dflash wins (env=HL_DFLASH_GGUF)
only HL_MTP_HEAD -> mtp_head env=HL_MTP_HEAD path=… sha256=a21d7524…
expected sha256 -> a21d752490d24df8… (matches)
So the two things the report was missing are both closed, and in the way the docstring argues for: the path is
resolved (the default dflash.gguf is relative, so the run's cwd used to decide which drafter a number described),
the sha256 pins the file rather than its name, and env says whether the value was supplied or defaulted instead of
leaving the default unnamed. HL_REPS is recorded as llama_bench_reps (:569), so the medians carry their -r.
One behaviour worth knowing rather than fixing: mtp_head is recorded only when the DFlash path is off (and not dflash_on()), which matches serve_lever_args()' precedence but means a configuration that sets both is reported as
dflash-only. That is the correct report if only dflash reached the command line, and the argv is what the result is
about — noting it so a future reader does not read the absence of mtp_head as "not set" when it was set and unused.
Not re-run by me: the measurement (needs the HRX device and the 27B file). The report fields are verified by calling
the function, which is where the defect was.
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT: READY at 3c0690f9e — merge-only update, own content byte-identical.
Checked with a hash of the PR's own diff at both heads rather than by eyeballing the file list: git diff <merge-base> <head> | sha256sum is the same at 6c94f73a6 and at 3c0690f9e, so nothing of this PR's moved. The branch is MERGEABLE/BLOCKED; the whole delta is main advancing (#1007, #1002, and the console-TUI/prefix-cache work that landed with them).
Evidence from the review at 6c94f73a6 stands: drafting_identity() — resolved path + sha256 + env=default|HL_DFLASH_GGUF|HL_MTP_HEAD, verified over five environment permutations with a real file.
CI at this head: red/pending: build, pr_agent — pr_agent failures on engine PRs are superseded-run cancellations ("Canceling since a higher priority waiting request exists"), not findings.
PR Reviewer Guide 🔍Here are some key observations to aid the review process:
|
closes #977
Root cause
tools/hyperloom/custom/benchmark.pybuilds the serve argv from env, and two of the names it reads there changewhat runs rather than how fast:
HL_DFLASH_GGUF(the file--dflashis handed, default the relativedflash.gguf, so the run's cwd decides it too) andHL_MTP_HEAD(an external head instead of the model's own). Theresult's only configuration echo is
levers(), which listedHL_DFLASH/HL_MTP_MAXbut neither of those, and nothingrecorded the
-r HL_REPScount the pp512/tg128 medians are taken over.This model has two drafter quants on the box (
~/models/qwen38/DFlash2/{q8_0,q4k}.gguf, 2,056,414,560 B /1,207,231,840 B), and the tuner already treats the pair as one configuration — it drops a drafter-quant variant because
overwriting
HL_DFLASH_GGUF"would make its number incomparable to the baseline" (orchestrator loghl-workspace-26030, 2026-10-30 18:14:39). The arm of record, 50.87 (HL_DFLASH=1 HL_MTP_MAX=6), is exactly thisshape.
Before / after
The pair-of-record artifact (
.../benchmark_custom_20261101_003158/inferencex_result.json):No drafter, no reps. Which drafter produced 50.87 was recoverable only from that session's
serve.log:29(
loading draft model '.../DFlash2/Qwen3.8-27B-DFlash2-q8_0.gguf') — and until #892 a second arm in the sameRESULT_DIRoverwrote that file. 50HL_DFLASH-carrying artifacts (25 distinct runs xbenchmark_report.json+inferencex_result.json) exist in thatworkspace and none of them names its drafter.
With this change, same box, real drafter file, no device touched:
bench_summarynow carriesdrafting(resolved path + head sha256 per drafting file, withenvsaying whether the pathcame from the environment or the default, and
{}when nothing drafts) andllama_bench_reps. The path is resolved andcomes from a single
dflash_gguf_arg()that the argv builder itself uses, so the report cannot name a different filefrom the one serve was handed; an absent file is a
nullhash rather than a guess.No score, threshold or gate changes:
output_throughput,quality_gate.*and the reference-establishing logic areuntouched, and this adds no measurement.
Verification (no GPU, no NPU, CPU only)
The new test block fails on the parent commit for the right reason:
It asserts the reported path is the resolved one and the hash the file's own, that a different drafter under the same
lever is a different record, that an unset
HL_DFLASH_GGUFis resolved and markeddefaultwith anullhash whenabsent, that drafting off is
{}rather than a claim, and thatHL_MTP_HEADis reported when it is the head in use.README: the
HL_DFLASHrow now documentsHL_DFLASH_GGUFand thedraftingrecord; the box-etiquette list documentsHL_REPSandbench_summary.llama_bench_reps.