Opt-in two-GPU sequence parallelism for MiniMax H3

Open
  • Is something wrong?
#17,717 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python, pytorch
Domain
machine-learning

Research direction

Start by reading the native MiniMax H3 attention path and model-patcher lifecycle; the issue does not name their files or tests. The proposed node would split query rows across two GPUs while retaining full keys and values on each partition, and register its secondary model with ComfyUI model management. Done means correctness tests and generation comparisons validate latency, model reuse, and offload/reload behavior.

Written by the indexing model from the issue text.

Description

Feature
Feature Idea

Add an opt-in way to run MiniMax H3 denoising across two GPUs within ComfyUI’s native execution path.

The proposed MiniMaxH3SequenceParallel node would sit between the model loader and sampler. It would split query rows between two GPUs while keeping full keys/values available to each partition, preserving dense attention and the existing precision.

The secondary model would be created through the existing loader and registered with ComfyUI model management for loading, residency, reuse, and offloading. Existing workflows would retain their current behavior unless the node is added.

The goal is lower generation latency on suitable GPU pairs. This requires bidirectional peer access and enough memory for a model replica plus activations; it does not pool VRAM to fit otherwise oversized model weights.

Would this focused integration be appropriate for ComfyUI core? It needs coordinated changes to the native H3 attention path and model-patcher lifecycle, which is why I am proposing it here.

Existing Solutions

Related discussions:

  • #11050 requests native support for ComfyUI-MultiGPU.
  • #4238 discusses multi-GPU memory distribution and distributed inference.
  • #15281 proposes an external vLLM-Omni backend for MiniMax H3.

The ComfyUI-MultiGPU extension is also relevant:
https://github.com/pollockjj/ComfyUI-MultiGPU

This proposal focuses specifically on splitting a single native H3 denoising execution across two GPUs, with model replicas owned by ComfyUI’s memory manager.

Other

A local implementation is prepared and has been validated on Navi48.

I plan to submit a PR with the implementation, correctness tests, and generation comparisons, including checks for managed model reuse and offload/reload.

Dominant language
Python
Stars
146k
Forks
17.4k
Avg merge
19h 44m
Merged PRs (30d)
178

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Comfy-Org/ComfyUI

All issues in Comfy-Org/ComfyUI

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.