feat(plan): MOBILE_2GB is strict, as its own documentation always claimed - #1128
Merged
Merged
Conversation
…imed The profile has said since it was written that it treats dequantization as "the defect it is". The flag said otherwise, so nothing enforced it. On a 2 GB board a missing kernel is not a slow path to take quietly: it is a weight arriving several times its size on the device least able to hold it, and the honest moment to say so is before the load rather than at the OOM. strict drives two things, and both change. WeightFormResolver refuses to resolve a weight nothing on the target can feed, and checkDequant turns a dispatcher-inserted widening past the 5 % threshold from a warning into an error. Consistent, because it is the same defect whether it is paid once at load or on every step. Three tests were asserting the old policy: - PlannerProfileTest used MOBILE_2GB as its *lenient* example. DESKTOP is the honest one now — it has the memory to absorb a widening and is told, while a 2 GB board does not and fails. strict() stays covered for turning a lenient profile into a failing one in CI. - The #1118 acceptance test had mobile as the side that dequantizes, which is no longer legal. Swapped: a desktop build without a Q8_0 kernel pays once at load, a phone with the kernel keeps it packed and mapped. The same contrast, and a more plausible story. - The pricing test opts out of strict explicitly to price a widening — which is exactly the decision that number exists to inform. skainet-plan needed it too: `--profile mobile --kernels dense` would have surfaced an IllegalStateException as a stack trace. A strict profile refusing is an answer to what the planner was asked, so it prints the message and exits 1. copy(strict = false) is documented on the profile: "would rather load slowly than not at all" is a legitimate position, it just should not be the silent default. Gate: scripts/pr-gate.sh — all legs passed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
📖 Documentation Preview The documentation has been built successfully for this PR. Generated Files:
Artifacts:
This comment will be updated automatically when the PR is updated. |
6 tasks
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follows #1109 / #1114.
MOBILE_2GBhas said since it was written that it treats dequantization as "the defect it is". Thestrictflag said otherwise, so nothing enforced it.On a 2 GB board a missing kernel is not a slow path to take quietly — it is a weight arriving several times its size on the device least able to hold it. The honest moment to say so is before the load, not at the OOM.
Both effects of
strictchangeWeightFormResolverDequantizeTo(FP32)checkDequantConsistent, because it is the same defect whether it is paid once at load or on every step.
Three tests were asserting the old policy
Each rewrite says something truer than a flag flip would have:
PlannerProfileTestusedMOBILE_2GBas its lenient example.DESKTOPis the honest one now: it has the memory to absorb a widening and is told, while a 2 GB board does not and fails.strict()stays covered, for turning a lenient profile into a failing one in CI.The CLI needed it
skainet-plan --profile mobile --kernels densewould have surfaced anIllegalStateExceptionas a stack trace. A strict profile refusing is an answer to what the planner was asked, so it prints the message and exits 1.The opt-out is documented
copy(strict = false)is named on the profile itself. "Would rather load slowly than not at all" is a legitimate position for someone shipping to a phone that lacks a kernel — it just should not be the silent default.Gate
scripts/pr-gate.sh— all legs passed.🤖 Generated with Claude Code