[PR #47] RFC: opt-in static weight-patch inspection for external execution adapters #28

Open
opened 2026-10-26 22:01:31 +00:00 by bsakaguchi · 0 comments
Owner

📋 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)

  • 110fbbd RFC: 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

  • No core implementation, Ulysses changes, GPU scheduler or distributed framework.
  • No changes to ordinary inference, memory management or existing patch methods.
  • Explicit ownership requirements, unsupported-state rejection and proposed tests.
  • Worker receiving/application and lifecycle remain separate unresolved boundaries.
  • Original source/license attribution retained; no copied algorithm code here.

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.

## 📋 Pull Request Information **Original PR:** https://github.com/Comfy-Org/rfcs/pull/47 **Author:** [@RagnarokChan](https://github.com/RagnarokChan) **Created:** 9/21/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `rfc/static-weight-patch-inspection` --- ### 📝 Commits (1) - [`110fbbd`](https://github.com/Comfy-Org/rfcs/commit/110fbbd0a988664e10ea9bae3d30bad55bdc4046) RFC: discuss opt-in static weight-patch inspection ### 📊 Changes **1 file changed** (+194 additions, -0 deletions) <details> <summary>View changed files</summary> ➕ `rfcs/0000-static-weight-patch-inspection.md` (+194 -0) </details> ### 📄 Description ## Attribution first This proposal originates from compatibility work on **[buqi-code's buqi-minimax-h3-multigpu](https://github.com/buqi-code/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](https://github.com/buqi-code/buqi-minimax-h3-multigpu/pull/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 - No core implementation, Ulysses changes, GPU scheduler or distributed framework. - No changes to ordinary inference, memory management or existing patch methods. - Explicit ownership requirements, unsupported-state rejection and proposed tests. - Worker receiving/application and lifecycle remain separate unresolved boundaries. - Original source/license attribution retained; no copied algorithm code here. 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. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
Sign in to join this conversation.
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Comfy-Org/rfcs#28
No description provided.