Clarify base-relative validation patches

This commit is contained in:
2026-04-30 06:52:09 +08:00
parent 46e9040613
commit f59919e21c
3 changed files with 12 additions and 6 deletions

View File

@@ -604,6 +604,7 @@ def _proposal_rules() -> list[str]:
"For decode_tpot bottlenecks, prefer legal TP/DP topology redistribution before runtime-only knobs, then tune max-num-seqs or max-num-batched-tokens only from observed SLO headroom/failures.",
"Pick at most one primary knob family from knob_harnesses unless the history proves a coupled change is needed.",
"Use adjacent legal values around the incumbent; avoid broad exploratory jumps.",
"config_patch is applied to the study base config, not as a delta on the incumbent; when validating an incumbent topology, include all topology flags needed to reconstruct that incumbent plus the runtime knob under test.",
"When strong_incumbent.guard_active is true, treat the run as a validation phase, not as proof of optimum: probe only adjacent topology or same-topology runtime knobs that can falsify the incumbent.",
"Do not stop solely because a strong incumbent appeared; stop only after nearby validation probes are exhausted, blocked by infeasible evidence, or repeatedly remain near the incumbent.",
"During validation, prefer probes that answer whether the incumbent is locally optimal over probes that merely chase another large gain.",