Clarify base-relative validation patches
This commit is contained in:
@@ -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.",
|
||||
|
||||
Reference in New Issue
Block a user