mirror of
https://github.com/Comfy-Org/rfcs.git
synced 2026-11-05 00:17:38 +00:00
[PR #47] RFC: opt-in static weight-patch inspection for external execution adapters #28
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Comfy-Org/rfcs#28
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📋 Pull Request Information
Original PR: https://github.com/Comfy-Org/rfcs/pull/47
Author: @RagnarokChan
Created: 9/21/2026
Status: 🔄 Open
Base:
main← Head:rfc/static-weight-patch-inspection📝 Commits (1)
110fbbdRFC: discuss opt-in static weight-patch inspection📊 Changes
1 file changed (+194 additions, -0 deletions)
View changed files
➕
rfcs/0000-static-weight-patch-inspection.md(+194 -0)📄 Description
Attribution first
This proposal originates from compatibility work on buqi-code's
buqi-minimax-h3-multigpu.
The original Ulysses sequence parallelism, rank0/worker architecture and core
collective/attention implementation belong to the original author. Our work is
compatibility adaptation, patch synchronization, lifecycle/device handling and
validation, not a new claim of authorship of those algorithms.
Related: #46 and author-facing compatibility PR #6.
Neither author endorsement nor ComfyUI acceptance is implied.
Proposal
A draft, documentation-only RFC for an explicitly invoked, patch-only static
weight-patch inspection boundary on ModelPatcher. The provisional design returns
read-only containers with borrowed native payloads and an opaque version; it is
explicitly not an immutable snapshot or serialization/worker API.
The goal is to discuss whether this should be a supported boundary at all before
writing core code. An owned export or keeping the adapter private are alternatives.
Scope and safety
Existing plugin evidence is not evidence for the proposed core API. The RFC
distinguishes published older validation from newer unpublished local work and
does not claim bit-identical independent INT8 single/dual generation.
Review requested
Is this a useful first boundary? Should it expose a borrowed view, an owned
export, or only metadata? Would maintainers prefer a focused API issue or an
existing interface instead? Draft status reflects these unresolved decisions.
This is a continuation of the Pre-RFC discussion, not a request to merge the
entire H3 plugin into ComfyUI. It does not close #46.
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.