Hidden ComfyUI Bug: What Caused H3 Video Generation to Slow Down 4x and How to Fix It

A Performance Regression Lurking for Three Weeks

Recently, a Reddit community member posted an important PSA (Public Service Announcement), revealing a hidden yet highly impactful performance issue in ComfyUI: starting from an update three weeks ago, the MiniMax H3 video generation model experienced a severe slowdown at full resolution — roughly 4x slower, according to the user. This issue has been independently reproduced twice, lending it strong credibility.

ComfyUI is one of the most popular open-source AI image and video generation workflow tools available today. It uses a node-based visual interface that lets users drag, drop, and connect different functional modules to build complex generation pipelines. Unlike traditional WebUI tools, ComfyUI's core strength lies in its high flexibility and extensibility, giving users precise control over every step of the inference process. MiniMax H3 is a video generation model released by MiniMax, capable of producing high-quality AI video content. It has garnered widespread attention in the community for its excellent visual quality and motion coherence. The H3 model demands substantial VRAM — full-resolution generation typically requires at least 16GB — which is why memory optimization is particularly sensitive for this model.

For creators and researchers who rely on ComfyUI for AI video generation, a performance degradation of this magnitude essentially means their workflow efficiency is cut in half — or worse. What makes it trickier is that regression issues like this are often hard to notice in daily use — users might vaguely feel that "things seem slower lately" without being able to pinpoint the specific code change responsible. In software engineering, a regression refers to a previously working feature deteriorating or breaking after a code change. Performance regressions are among the hardest to detect because the program still runs correctly and produces correct results — it's just slower. Large projects typically establish performance benchmarks and CI (Continuous Integration) pipelines to automatically catch these issues, but for fast-iterating open-source projects, comprehensive performance regression test coverage is often a luxury. This explains why the bug was able to lurk in ComfyUI for three weeks.

Root Cause: A Side Effect from a Memory Optimization

According to the poster's investigation, the source of the performance issue is quite clear. It originates from commit #15486 in the ComfyUI repository — submitted by core developer comfyanonymous, titled "Fix peak memory issue with H3." The PR's original intent was to address peak memory usage during H3 model execution.

The Cost of a Single Line of Code

The core of the problem comes down to this line of code:

v = v.clone()

From a technical standpoint, .clone() creates a deep copy of a tensor. In PyTorch, tensors are the fundamental data containers. The .clone() method creates a new tensor with the same data, data type, and device placement as the original, but with its own independent memory space — it does not share underlying storage with the original. This differs from .detach(), which only severs gradient propagation in the computation graph while still sharing memory with the original tensor. In GPU environments, each .clone() call triggers the CUDA memory allocator to allocate a new region of VRAM and execute a device-to-device data copy. For the high-dimensional tensors common in video generation models (e.g., five-dimensional tensors with shape [batch, frames, channels, height, width]), a single clone operation can involve copying hundreds of megabytes or even several gigabytes of data.

The developer likely introduced this line to avoid memory conflicts caused by in-place operations, or to sever reference relationships in the computation graph, thereby reducing peak VRAM usage. PyTorch's automatic differentiation engine (Autograd) builds a computation graph during the forward pass, which is used to compute gradients during backpropagation. If a tensor is referenced by multiple nodes in the computation graph and one of those nodes performs an in-place operation on it (such as tensor.mul_() or tensor[idx] = value), other nodes referencing that tensor will receive corrupted data during backpropagation. Even in pure inference mode where gradient computation isn't involved, shared-memory tensors that are accidentally modified can lead to incorrect downstream results. .clone() is the most straightforward — but also the most expensive — way to solve such problems.

However, the side effect is obvious: every call to v.clone() triggers a full memory allocation and data copy. In video generation scenarios that require repeatedly processing large-scale tensors — especially in full-resolution workflows — when this operation sits in the model inference's hot path (such as every iteration of the attention mechanism), the accumulated overhead ultimately causes a massive drop in overall inference speed.

This is a classic case of an imbalanced memory-vs-speed trade-off: peak VRAM was reduced at the cost of multiplied execution time — a price that isn't worth paying for many users' hardware configurations.

Temporary Fix for the ComfyUI H3 Speed Issue

The poster's solution is very straightforward — delete the line v = v.clone().

The corresponding issue is documented in detail in GitHub Issue #15665 ("MiniMax H3 video generation ~4x slower since v0.32.0 at full resolution"), with the regression's starting point clearly traced back to v0.32.0.

Step-by-Step Instructions

If you're affected by this issue, here's how to fix it:

1. Locate the relevant file modified in PR #15486;
2. Find and remove the line v = v.clone();
3. Restart ComfyUI and verify that H3 generation speed has returned to normal.

The poster specifically highlighted a critical detail: if you update ComfyUI, the issue will reappear. This means you'll need to re-check this code every time you pull a new version. It's precisely this repeatable cause-and-effect relationship — "issue returns after update, disappears after deletion" — that gives the community confidence that the root cause is pinpointed correctly.

Reflections on the Memory Optimization vs. Performance Trade-off

This incident is worth careful consideration by every AI tool user and developer.

The stealth nature of performance regressions should not be underestimated. Unlike crashes or error messages — which are obvious bugs — performance degradation is often silent. Without attentive community members actively tracking and reproducing the issue, problems like this can persist for a long time, quietly draining the time and compute resources of thousands of users.

Memory optimization is a double-edged sword. The original PR's motivation was perfectly reasonable — peak memory issues can indeed cause OOM (Out of Memory) errors that prevent the model from running at all. OOM is one of the most common runtime errors in GPU computing, manifesting as a CUDA memory allocation failure. When peak VRAM usage during model inference exceeds the GPU's physical VRAM capacity, the program crashes immediately with a CUDA out of memory error. Peak VRAM depends not only on the model parameters themselves but also on intermediate activations, attention matrices, temporary buffers, and other factors. Modern video generation models, which need to process multiple frames simultaneously, often have VRAM requirements far exceeding those of image models with comparable parameter counts.

But using .clone() as a blanket solution to avoid memory conflicts clearly failed to adequately assess the performance cost in high-frequency call scenarios. An ideal fix might involve conditional copying, or adopting lighter-weight memory management strategies — such as gradient checkpointing (trading compute for VRAM), tiled attention, using .contiguous() instead of cloning (when the issue only involves memory layout), or restructuring code logic to prevent shared-reference tensors from being modified in-place — rather than indiscriminately deep-copying tensors.

The open-source community's self-healing capability deserves recognition. From a user noticing the anomaly, to tracing it to a GitHub Issue, to providing a clear code-level fix — the entire process demonstrates the value of an active open-source ecosystem. However, manually deleting code as a temporary workaround is not a long-term solution — a more fundamental resolution still requires the official team to rebalance the memory-vs-speed tension in a future release.

Practical Advice for ComfyUI Users

For regular users, if you don't frequently run into OOM issues with H3, deleting this line of code to regain speed is a worthwhile trade-off. But if you're already running at the edge of VRAM capacity (e.g., running full resolution on 8GB of VRAM), you'll need to weigh the options — removing the copy may retrigger peak memory problems.

Regardless, this case reminds us once again: while pursuing cutting-edge AI tools, staying alert to version changes and following community feedback can help you avoid many invisible pitfalls. Affected users are advised to keep an eye on Issue #15665 for updates and wait for the official team to deliver a more elegant final fix.

Key Takeaways