P7: AllocationResolver + plan→load wiring (re-land #1153/#1154 onto develop) - #1155
Merged
Merged
Conversation
Placement joins WeightForm as a resolved decision (#1133's answer): AllocationResolver is a pure function of what will be held (the resolved form), what the profile says (domainFor and its threshold) and what the platform can do (StorageCapabilities, injectable so a test can resolve for a platform it is not running on). PlanTensor.allocation stops hardcoding MMAP_FILE/MODEL — a spec that claimed every weight was mapped even on a platform that cannot map, and even for a dequantized copy that no longer matches the file. Mapping now requires all three: the form asks MAPPED, the platform can map, and the bytes really are the file's bytes; everything else falls to the profile's heap/off-heap threshold over the bytes actually held. AllocationResolver.explain() renders the decision with its reason, so a plan can say where every tensor landed and why. Closes #1143. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…iring Plan and load were two disjoint pipelines sharing vocabulary and never talking: nothing on the load path consulted what the resolvers decided. StreamingGgufParametersLoader gains weightFormFor — per-tensor forms with an explicit, documented precedence: your function > the uniform weightForm > the three legacy parameters. The user-wins channel is named as such: whatever you pass outranks every resolver, including 'everything dense on the managed heap'. ResolvedGguf ties it together: header-only planInput, forms resolved from file × profile × kernel capability, overrides applied, and a loader that delivers exactly those forms. The same resolved input is priceable (profiledPlan().requireFits() refuses pre-load) and explainable (explainPlacements() — one line per weight, where and why) before a byte of payload is read. Closes #1144. 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. |
This was referenced Aug 26, 2026
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
1 participant
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.
Re-lands #1153 + #1154 against
develop.Both PRs were merged, but into their stacked base branches (
feature/1142-…,feature/1143-…) rather thandevelop— GitHub only retargets a stacked PR automatically when its base branch is deleted at merge, and the bases weren't deleted. So the AllocationResolver (#1143) and plan→load wiring (#1144) never reacheddevelop. This PR is those same two commits, rebased onto currentdevelop(post-#1151/#1152); see the original PRs for the full descriptions and the green full-gate runs.Tip for the rest of the stack: ticking "delete branch" when merging makes GitHub retarget the child PR to
developautomatically.🤖 Generated with Claude Code