DucHaiten Highway V1 — INT8 Video + Audio
⚠️ READ THE SETUP GUIDE FIRST — THIS MODEL REQUIRES THE HIGHWAY INTEGRATION
Highway V1 will not run with standard MiniMax H3 loaders. You must install the Highway ComfyUI integration and use the supplied workflows. Follow the setup guide before clicking Generate.
Hey everyone! Meet Highway V1, my INT8 video-and-audio model built on MiniMax H3. Create from a text prompt, guide scenes with multiple reference images, or connect first and last frames using one Highway checkpoint. I’m excited to share it with you.
In my evaluated comparisons, Highway’s native C20 schedule (20 evaluations) matched the quality of MiniMax H3 at 50 steps.
I built Highway on MiniMax H3 through DaSiWa Hybrid v2 INT8, with its own saved generation policy and resource management. Text-only, multiple references and first/last-frame control use one Highway checkpoint. You can see the actual videos, prompts and reference images on my HF page.
✦ What changes from MiniMax H3?
Comparison MiniMax H3 Highway V1 INT8 Quality in my evaluated comparisons 50-step reference Matched at 20 evaluations Published / demonstrated resolution Released recipe targets a 768-pixel short edge 1344×768, 1792×1024 and 2688×1536 demonstrated Checkpoint coverage FL2VA and Ref2VA partitions One checkpoint tested across text, image references and first/last frames Generation controls Configurable sampling recipes Native C20 policy saved with Highway; no Steps slider to configure
Quality is my visual assessment; the other rows compare the published H3 recipe with my demonstrations. That 768p target is not H3’s proven maximum. A normal H3 sampler set to 20 steps does not reproduce Highway’s policy.
⚡ The 15-second case: reported OOM → a completed Highway video
At 1344×768 / 362 frames on RTX 4090, the H3 INT8 community guide by yume-arasaki reports OOM. Highway’s demonstration at those dimensions and frame count completed with four image references and stereo audio.
1344×768 · 362 frames Reported H3 INT8 setup Highway V1 INT8 — my run Outcome Author-reported OOM Completed · 15.08 seconds · four references Full request time No completed result reported for this case 24m 33.58s Host configuration 32 GB RAM; 8-step res_multistep; NVFP4 encoder 128 GB RAM; native C20; BF16 layer-50 encoder
Reported OOM in that community setup; completed in mine. Software, conditioning and host RAM differ, and the source supplies no matching allocation log. This eight-step report provides OOM context only; it is excluded from original-H3 speed/memory comparisons.
✓ Five completed runs — here are my timings and memory figures
RTX 4090 · INT8 · 24 fps · 32 kHz stereo audio. Full request time includes preparation, generation and output work.
Input Output Full request Peak process RAM¹ Worker GPU memory² allocated / reserved Text only 1344×768 · 5.17s 5m 59.34s 29.81 GiB 3.31 / 3.78 GiB Four references 1344×768 · 5.17s 8m 44.24s 31.11 GiB 3.81 / 4.41 GiB Four references 1344×768 · 15.08s 24m 33.58s 34.00 GiB 7.36 / 9.72 GiB First + last frames 1792×1024 · 5.17s 11m 11.34s 32.58 GiB 4.97 / 6.62 GiB Text only 2688×1536 · 5.17s 32m 52.19s 36.29 GiB 9.03 / 11.97 GiB
¹ RAM covers Highway’s recorded process tree, excluding unrelated apps; shared resident pages can be counted more than once.
² These VRAM figures cover the generation worker’s PyTorch allocator, not total Highway GPU memory. They exclude the separate reference reader and allocations outside that allocator. Reserved includes allocated; do not add them. These are observed peaks, not minimum hardware requirements.
Full timings, historical builds and memory definitions are on HF. Matching original-H3 measurements are unavailable for these five runs, so I’m showing measured usage rather than a claimed saving percentage.
2688×1536 is four times the pixel count of 1344×768 — generated directly. I pushed that setting for the showcase; motion can look strained there. Start at 1344×768. For higher-resolution experiments, I’d try 2560×1440; that setting is a suggestion, not a measured row above.
I used quickly drafted test prompts. Watch the outputs and judge for yourself — there’s also compatible LoRA inference through the supplied controls.
◇ Why Civitai says “Merge” and “H3”
These are Civitai’s available labels. “Merge” means integrating Highway V1’s architecture and saved policy into this H3-derived model, not blending several checkpoints’ learned knowledge. “H3” identifies its lineage, not standard-loader compatibility.
⚙ Before you hit Generate
Use the Highway ComfyUI integration and supplied workflows. Standard H3/generic checkpoint loaders will not run it; a workflow JSON alone does not install the software.
Download the RC.3.7 integration ZIP and extract it.
Close ComfyUI, run INSTALL_WINDOWS.bat, and select your ComfyUI folder if asked.
Restart ComfyUI and drag in 01 - Start Here.json.
Click Prepare / download models on Asset Profile. Let it verify/reuse existing files or download what’s missing, then enter your prompt and run.
The setup uses the RC.3.1 Safetensors checkpoint, matching runtime, Qwen encoder and video/audio VAEs. Required model files total 78.30 GB on disk, plus software/caches/outputs. Optional automatic-reference assistance adds 8.89 GB; basic references work without it. Highway downloads are open on HF; any access requirements for separately hosted components still apply. Unused reference upload slots can stay connected in RC.3.7.
→ Get Highway V1 and show me what you make
Highway V1 on Hugging Face → · Installation guide
The source/component terms still apply; keep the included notices. This is my project, not an official MiniMax release.
I’d love to see your results! If you hit an error, include your setup and the message so it’s easier to help.
Description
FAQ
Comments (50)
Damn this is amazing. You got real skills. I wished I had a GPU with 24-32gb of vram to run this... maybe in a couple of years when next gen gpus are affordable and give us 36-48-64gb of vram for under 1000$...
Or maybe we have a breakthrough in video generators efficiency and we can run like a minute of video in real time on 16gb of vram, thatd be amazing.
You could try 12–16 GB and see how it goes; I’m also curious to see how it performs with different configurations.
Fingers crossed for the latter, since the former looks increasingly unlikely...
@Joe375 It’s sad but true; however, I might be able to find a way to let GPUs with low VRAM run higher-quality AI models.
@DucHaiten so there is no hope for 8?
@putratroops Maybe 768p 5s or lower, but I’m afraid it will take a very long time to run
I love to see new innovation!
Hey, thanks for the work! So far the model seems really great had a couple issues though, I have a pretty Wonky folder setup involving a portable installation using a different model location, but even when I directed the install to that model folder it couldnt find any of the existing models and downloaded all of them in the models/highway location, not the end of the world but def have some redundant installs now.
I have a system with a 48GB RAM and a 4080, but the model just wouldn't fit, and I couldn't get it to work.
Could you please send me the exact error message or the error log file with the RTX 4080/48GB VRAM? I don’t have that GPU to test with on my own machine, so I need detailed information to understand exactly what the issue is.
Hi! Thanks for letting me know. To work out what’s failing on your setup, could you send me:
The full error report from ComfyUI: click Show Report on the error, or copy the console traceback. If it mentions a diagnostic JSON file, please attach that too.
A screenshot of your workflow settings showing resolution, frame count/duration, number of reference images, and whether automatic reference binding is enabled.
Whether it fails while loading, before generation starts, during generation, or when saving the video.
Whether you use ComfyUI Portable, Desktop, or a manual installation.
I’ve added better diagnostics in RC.3.8. Update the integration, restart ComfyUI, then open Prepare / download models → Download diagnostics and attach the JSON. You don’t need to download the model again or run another video just to collect this report.
The exact error will help me distinguish system RAM, GPU memory, or a loading problem. Please redact any personal information from paths before sharing.
Update: Fixed in RC3.8 - now works on 48GB RAM + RTX 4080
Same setup that failed before (48GB + 4080) now generates fine with DucHaiten-Highway-V1.0.0-rc.3.8-ComfyUI.zip
Workflow: default 01 - Start Here.json - prompt: "A continuous five-second shot of a traveler walking beside a stone wall in warm afternoon light..."
1344x768 / 124 frames / 24fps
Prompt executed in 433.11 seconds - no error. Thanks for the fix!
@rahip I fixed it as soon as I read your first comment. I asked for clarification earlier because I wasn't sure if the error was fully resolved, but it’s great to hear that it’s fixed now. Also, could you provide some more details about your run, such as the parameters used, the total completion time (as you already noted), your system RAM, and your GPU VRAM? This information would be very helpful for my future updates.
Final report on RC3.8 fix:
System: 48GB RAM + RTX 4080 16GB VRAM
All runs completed with no error:
406.20 sec - default settings 1344x768 (16:9)
433.11 sec - 01 - Image Reference.json / 768x1344 (9:16)
384.04 sec - 02 - Image Reference.json / 768x1344 (9:16) / balcony reference (identity/clothing only)
Fix works stable for both landscape and portrait. Thanks again!
Attaching the generated outputs to the post as well.
@rahip Thank you; I am extremely grateful.
@DucHaiten [TUTORIAL] Highway-V1 Alias Error Fix - No Skip Needed - Liza vs Frost Giant Example
I was getting CHARACTER BINDING - alias not found error in DucHaiten/Highway-V1 with 2 references. Everyone opens on_error: skip but I fixed it without skip.
MY SETUP
Workflow: 02 - Image Reference
2 refs: [image 1] Female warrior Liza, [image 2] Frost Giant Ice Golem
Resolution: 768x1344 vertical 9:16
THE PROBLEM - Faulty Prompt
Characters:
Liza is the female warrior [image 1] - black armor...
Stages:
0-2.5s: shot from behind [image 1] Liza looking up...
2.5-4.5s: Liza [image 1] turns, Frost [image 2] charges...
I was re-using [image 1] / [image 2] inside Stages, and my reference sheet had snowy mountain background + scar on face. Qwen reader couldn't lock Liza = [image 1] at 100%, so it threw alias error.
THE FIX - 4 steps
Lock alias only once, in correct order:Name is the description [image X] - details
Correct:Liza is the female warrior [image 1] - ornate black full plate armor with etched patterns covered in snow, tattered black cape, long dark windblown hair, pale clean skin no scars, piercing light blue eyes, steel longsword.Frost is the colossal stone and frost golem [image 2] - massive cracked rock body covered in snow and ice...
Never re-use [image X] in Stages. Use only names after that:Liza turns to face camera... Frost charges behind her...
Add Continuity section:Continuity: Keep exactly two distinct fighters throughout. Liza keeps her longsword, Frost keeps his fists. Maintain positions, momentum, distance.
Make reference sheet like official ELEC:
White background, FRONT / BACK / SIDE / 3/4 VIEW, 2x CLOSE UP, DETAILS, bottom KEY FEATURES • ... and COLOR PALETTE with 5 swatches + hex codes. Clean face, snowy armor. This is what finally locked it.
FINAL WORKING PROMPT (no skip needed)
Goal: A continuous 10-second cinematic action sequence in a misty snow-covered mountain pass, vertical 9:16, 768x1344, all action centered vertically. Photorealistic dark fantasy, natural physics, consistent character geometry, no outfit change, blowing snow.
Characters: [as above locked once]
Continuity: [as above]
Stages:
0-2.5s: low-angle over-the-shoulder shot from behind Liza looking up as towering Frost emerges from fog...
2.5-4.5s: Liza turns to face camera in medium shot, Frost charges forward right behind her raising massive icy fist...
4.5-7.5s: Liza spins and blocks the downward smash with her longsword in exact center of vertical frame, shattered ice shards exploding...
7.5-10s: Frost collapses into snow, camera pushes in for tight vertical portrait close-up on Liza's face as she exhales cold breath.
Visual Style: Detailed cinematic 3D realism...
Camera: One continuous tracking shot...
Audio: Synchronized footsteps in snow, cloth, sword and ice impact, wind...
Exclusions: No extra characters, duplicated bodies, costume swaps, glowing eyes for Liza, labels, subtitles...
After this, same workflow with CHARACTER BINDING enabled: true and on_error CLOSED started without error.
Reference sheets I used: Liza and Frost Giant with KEY FEATURES + COLOR PALETTE at bottom (white bg).
Hope this helps anyone stuck on alias.
Bitdefender gave me this:
"The file C:\Users\Owner\AppData\Local\Temp\tmpcrhqbqc_\cuda_utils.cp311-win_amd64.pyd is infected with Gen:Suspicious.Cloud.4.bu4@amsrwKo. The threat has been successfully blocked, your device is safe."
I will look into this matter more closely. Due to certain limitations, I am unable to test across various environments to identify potential issues; however, should you encounter any problems, please provide me with the details, and I will be happy to assist you.
Hi! Thanks for reporting this. I’d like to investigate the exact file Bitdefender blocked. Could you send me:
A screenshot of the detection details, including the full file path and SHA-256 hash if Bitdefender displays one.
When it happened: during installation, model preparation, or after clicking Run.
The full ComfyUI error report or console error, if there was one.
I’ve added a support-report button in RC.3.8. After updating the integration and restarting ComfyUI, open Prepare / download models → Download diagnostics and attach the JSON file here. This collects environment information without loading a model.
Please keep the security block enabled—there’s no need to restore the quarantined file or add an exclusion. If diagnostics is blocked too, just send the information already available. You can redact your Windows username from file paths.
Since I completed everything within just one month, while dedicating 70% of my time and effort to other work to earn a living and given the inherent limitations of this being a personal project, I haven't been able to test it across various environments to identify potential issues. That said, if you encounter any difficulties, please provide me with the details, and I will be happy to help. This model has undergone significant changes in how it functions, so there is a high probability that bugs may arise across different systems.
hello,
I think it works from my side. thank you for your work, and the share.
i just can tell that add a lora or more is a pain : i have to get the full path manually and paste it, maybe it should be like the others, with a list and a qui search bar etc, like "Power Lora Loader (rgthree)" or any else. I'm still trying to explore but the changes with the request/profile method is so different that I can't just get my own subgraphs, and I have to re-do everything.
the video render node could have a video/sound output to put it to upscaler/dlss/seedvr nodes more easily.
otherwise, the quality looks great, i have to go further ! seems promising
@argotic I will look into this, but I have to say it’s unlikely to be a priority right now, as I am currently focusing my time on larger updates and fixing other critical bugs.
@DucHaiten no problems ! :) Thanks for your reply. I can’t wait to see what you’re working on.
I'm usually a late adopter when it comes to new generation paradigms, but this just sounded too interesting not to try out. I set it up on Arch Linux, using an rtx 3090 and 64GB DDR4 RAM (+swap). The first tests look very promising, as I have yet to run into any OoM trouble. I just generated a 768p, 10 seconds scene from 5 image references in about 46 minutes without issues. Now I gotta dig a little more into the documentation, in order to figure out what the options are for continuous, consecutive generation and optimizing reference input, etc. Very very impressed so far, keep it up!
Thank you for the kind words. I am constantly looking for more feedback and data from users as they work with this model; this will help me in my ongoing research to develop better updates. My goal is to enable everyone to run AI video generation on their own personal computers, with quality that rivals Seedance 2.5.
Very nice model for anime. Thank you!!
This model works for me even without downloading and installing everything that’s written in the description. Will anything change if I set everything up as described in the instructions? I just don’t like dealing with these setups.
It depends on what hardware you are using and what you have already installed.
The full setup is not just for loading the checkpoint. It installs Highway’s matching runtime and nodes, which handle its native C20 sampling policy, memory management, and optional automatic character/reference binding. Loading the weights in an existing H3 workflow does not necessarily activate those features, and setting a normal sampler to 20 steps is not equivalent to Highway’s C20 policy.
You would also need to use the supplied Highway workflow, not just install the package and keep using the old H3 nodes. That is the setup used for the published demos and performance measurements. It can change generation behavior, speed, and memory usage, but I haven’t tested your workflow, so I can’t give an exact before-and-after comparison.
The Windows installer handles the software setup separately from ComfyUI’s own Python environment, and compatible model files you already have can be reused.
Analysed by Claude it says the model is identical to dasiwa v2, which you mention in the description, but the entire thing is a bit misleading imo, 99% of what you made except the memory handling for big videos on low vram, is obtainable with the custom 20steps sigma which is different than the standard h3. correct me if im wrong
I think your analysis is partly correct, but there’s an important distinction between the learned weights of a model and the architecture responsible for executing those weights. Your conclusion that 99% of Highway can be reproduced with a custom 20-step sigma schedule overlooks several parts of the project.
Let me explain exactly what Highway V1 is, what it inherits, and what I actually developed.
1. Yes, Highway inherits its learned weights from DaSiWa Hybrid V2
I’ve never tried to hide this. It’s explicitly documented on the Hugging Face model page.
Highway V1 is a derivative model based on MiniMax H3, using DaSiWa Hybrid V2 INT8 as its immediate learned-weight source.
The internal audit confirmed that all 932 inherited tensor payloads were preserved byte for byte.
This means the underlying knowledge about motion, objects, language, visual concepts, and audio generation originates from the existing trained model.
I did not pretrain another 33B-parameter model, and I do not claim to have created new learned knowledge through conventional training.
But identical learned weights do not automatically mean identical execution behavior.
The trained weights are one part of a model. How those weights are organized, evaluated, scheduled, and managed during inference is another.
2. Highway is not simply DaSiWa with a different sigma schedule
Highway V1 has its own saved model definition and a matching execution runtime.
Its checkpoint contains:
932 physical tensor stores and 1,136 logical parameter handles, with a model-defined computation graph covering the Transformer and associated components.
Its native C20 generation policy, including the sampling schedule and numerical state-update behavior.
An execution definition that the Highway runtime interprets, alongside its own memory, tensor-lifetime, caching, and resource-management mechanisms.
The approximately 20.97 GB Safetensors checkpoint can load its own Transformer payload without reopening the original DaSiWa or H3 Transformer checkpoint.
The external encoders, VAEs, and other dependencies remain separate, as documented.
This is a derivative model with an independently loadable checkpoint and an execution architecture built around inherited knowledge.
It is not a newly trained foundation model, but it is also not just a renamed DaSiWa checkpoint or a ComfyUI workflow.
3. C20 is not simply “set sigma to 20 steps”
This is an important technical distinction.
A sigma schedule determines the noise levels at which a diffusion model is evaluated.
But the complete sampling process also depends on how the predictions are used to update the latent state, how solver history is handled, and how the numerical sequence is executed.
Highway’s C20 is a model-defined generation policy using 20 denoiser evaluations.
Simply taking DaSiWa and setting a standard sampler to 20 steps does not establish equivalence with C20.
A custom sampler could potentially reproduce equivalent numerical behavior if it implemented the same relevant schedule, solver updates, and state handling. I’m not claiming that this is mathematically impossible.
But showing that DaSiWa works with a custom 20-step sigma schedule is not evidence that you’ve reproduced Highway’s complete C20 policy.
My claim that C20 achieves quality comparable to 50-step H3 comes from my own evaluated comparisons, which I have identified as such in the documentation. It is not presented as an independently verified universal benchmark.
4. The execution system is a substantial part of Highway
This is where I think your analysis overlooks most of the engineering work.
Highway has its own execution graph, runtime resource planning, weight loading, cache handling, memory-lifetime management, and integration of the generation process.
These components determine how the model actually operates, not merely which noise levels it samples.
For example, Highway V1 has publicly demonstrated the following on a single RTX 4090:
1344×768, 362 frames at 24 fps, approximately 15.08 seconds, with four image references and stereo audio.
The complete request took approximately 24 minutes and 34 seconds in the published run.
It also demonstrated direct generation at 2688×1536, without first generating a completed lower-resolution video and upscaling it afterward.
I’m not claiming Highway invented 15-second video generation, multi-reference conditioning, or stereo audio. Those capabilities originate from H3 and its derivatives.
The contribution is how those capabilities are executed and combined under the measured hardware and resource constraints.
Changing a sigma schedule does not automatically implement that execution system.
5. Why similar-looking videos would not prove the systems are identical
Since the learned weights are inherited, it is entirely reasonable that DaSiWa and Highway can generate visually similar results.
In fact, I would expect considerable overlap in their underlying generation capabilities.
If you load the inherited weights through an existing H3-compatible workflow, you may still generate video successfully.
However, that does not establish that the workflow is executing Highway’s native model definition, C20 policy, and resource-management system.
There are several separate questions here:
Can DaSiWa produce similar-looking videos with a custom sampler? Possibly, and I have no reason to dismiss that.
Does that mean its sampler reproduces Highway’s C20 numerical behavior? Not without a corresponding comparison.
Does that mean it reproduces Highway’s memory management, execution architecture, and demonstrated combined workloads? No. Those are separate technical questions.
6. About your “99%” estimate
I don’t think that percentage has a technical basis yet.
99% of what exactly?
If you’re referring to learned knowledge contained in the Transformer, the vast majority is indeed inherited, and I’ve openly acknowledged that.
If you’re referring to image quality on short videos, similar results may be achievable with the source model and a well-configured sampler.
But if you’re referring to Highway’s entire model definition, generation policy, execution architecture, resource management, and demonstrated operating capabilities, a custom sigma schedule does not account for all of those components.
Those are different measurements, and they shouldn’t be collapsed into one percentage.
My conclusion
Highway V1 is a derivative AI video model that retains the learned knowledge of DaSiWa/H3 while introducing its own saved execution definition, native generation policy, and integrated runtime.
Its contribution is not the invention of new learned weights. It is the development of a different way to organize and execute inherited weights as a functioning model system.
This is also why I provided a dedicated Highway runtime rather than distributing only a sigma schedule.
I fully acknowledge MiniMax and DaSiWa for their work. Without their trained weights, Highway V1 would not have its underlying generation capabilities.
But acknowledging the origin of the knowledge does not mean the engineering required to execute that knowledge differently has no independent value.
If another DaSiWa workflow can reproduce the same quality, complete workloads, resource usage, and execution behavior, that would be a meaningful technical comparison.
Until then, saying that 99% of Highway is just a custom 20-step sigma schedule is a much stronger conclusion than the evidence supports.
I appreciate technical criticism, especially when it helps establish what Highway actually improves. I just want the comparison to distinguish inherited model capabilities from the execution architecture developed for Highway.
NATIVE_SMOKE_FAILED on Ada Lovelace (RTX 4080 / SM89) - Missing _qattn_sm89 in bundled sageattention
Summary:
On RTX 4080 (Ada Lovelace, SM89), DucHaitenHighwayGenerate fails at startup during native_smoke.py.
In _dense_low_memory.py (line 29), it attempts:
from sageattention.core import _qattn_sm89
However, the bundled worker environment (sageattention 2.2.0+highway.20261022) does not contain the compiled SM89 kernel, raising:
ImportError: cannot import name '_qattn_sm89' from 'sageattention.core'
Attached diagnostic:
worker-error-82faa1f9b7de4837bc35d8b206e7121a.json
Requested Fix:
Please provide a compiled _qattn_sm89 wheel for Windows / Python 3.11 / CUDA 12.x/13.x, or implement an ImportError fallback to SDPA/standard attention inside _dense_low_memory.py when the SM89 native kernel is missing.
{
"schema_version": 1,
"request_id": "bfabcc50fd094b09b204baab2736d623",
"worker_pid": 20832,
"captured_epoch_seconds": 1792791298.8957062,
"error": {
"type": "DispatchError",
"message": "NATIVE_SMOKE_FAILED: Native target admission failed before model weights load",
"notes": [],
"traceback": "Traceback (most recent call last):\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\custom_nodes\\duchaiten_highway\\_runtime\\work\\h3_model_core\\native_smoke.py\", line 185, in verify_native_runtime\n receipt = cached_admission(identity, lambda: runnative(plan, torch))\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\custom_nodes\\duchaiten_highway\\_runtime\\work\\h3_model_core\\native_smoke.py\", line 87, in cached_admission\n result = runner() # failure is never cached\n ^^^^^^^^\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\custom_nodes\\duchaiten_highway\\_runtime\\work\\h3_model_core\\native_smoke.py\", line 185, in <lambda>\n receipt = cached_admission(identity, lambda: runnative(plan, torch))\n ^^^^^^^^^^^^^^^^^^^^^^^^\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\custom_nodes\\duchaiten_highway\\_runtime\\work\\h3_model_core\\native_smoke.py\", line 140, in runnative\n dense = importlib.import_module('._dense_low_memory', package=__package__).dense_attention\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\.highway\\python-3.11.9\\tools\\Lib\\importlib\\__init__.py\", line 126, in import_module\n return bootstrap.gcd_import(name[level:], package, level)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"<frozen importlib._bootstrap>\", line 1204, in gcdimport\n File \"<frozen importlib._bootstrap>\", line 1176, in findand_load\n File \"<frozen importlib._bootstrap>\", line 1147, in findand_load_unlocked\n File \"<frozen importlib._bootstrap>\", line 690, in loadunlocked\n File \"<frozen importlib._bootstrap_external>\", line 940, in exec_module\n File \"<frozen importlib._bootstrap>\", line 241, in callwith_frames_removed\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\custom_nodes\\duchaiten_highway\\_runtime\\work\\h3_model_core\\_dense_low_memory.py\", line 29, in <module>\n from sageattention.core import (\nImportError: cannot import name '_qattn_sm89' from 'sageattention.core' (C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\.highway\\worker-e94f339695c6\\Lib\\site-packages\\sageattention\\core.py)\n\nThe above exception was the direct cause of the following exception:\n\nTraceback (most recent call last):\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\custom_nodes\\duchaiten_highway\\worker.py\", line 244, in main\n result = session.generate(message[\"request\"], message[\"output\"],\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\custom_nodes\\duchaiten_highway\\_runtime\\work\\highway-native78\\adapter.py\", line 528, in generate\n self._backend = self._create_backend(selection)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\custom_nodes\\duchaiten_highway\\_runtime\\work\\highway-native78\\adapter.py\", line 375, in createbackend\n plan, dispatch = self._binding.validate_selection(torch, resources, self.runtime_plan)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\custom_nodes\\duchaiten_highway\\_runtime\\work\\highway-native78\\backend.py\", line 144, in validate_selection\n native_smoke=smoke_probe(selected,torch_module=torch)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\custom_nodes\\duchaiten_highway\\_runtime\\work\\h3_model_core\\native_smoke.py\", line 187, in verify_native_runtime\n raise DispatchError('NATIVE_SMOKE_FAILED', 'Native target admission failed before model weights load',\nh3_model_core.execution_contract.DispatchError: NATIVE_SMOKE_FAILED: Native target admission failed before model weights load\n",
"code": "NATIVE_SMOKE_FAILED",
"request_trace": {
"worker_request_seconds": 2.3067881999886595,
"progress": [
{
"seconds": 0.05406479998782743,
"stage": "loading",
"completed": 0,
"total": 1,
"process_memory": {
"rss": 37883904,
"vms": 26353664,
"num_page_faults": 15643,
"peak_wset": 42029056,
"wset": 37883904,
"peak_paged_pool": 193296,
"paged_pool": 191200,
"peak_nonpaged_pool": 28272,
"nonpaged_pool": 16720,
"pagefile": 26353664,
"peak_pagefile": 31330304,
"private": 26353664
}
}
],
"environment": {
"PYTORCH_CUDA_ALLOC_CONF": "backend:cudaMallocAsync",
"PYTORCH_ALLOC_CONF": null,
"TORCHINDUCTOR_CACHE_DIR": "C:\\Users\\Berkay\\AppData\\Local\\Temp\\torchinductor_Berkay",
"TRITON_CACHE_DIR": null,
"CUDA_CACHE_PATH": null
},
"scope": "Worker request wall time and phase observations, including load/export; not host queue/IPC time, not per-request memory peaks. No synchronization or numerical policy changes."
},
"runtime_context": {
"schema_version": 1,
"observed_epoch_seconds": 1792791298.8902605,
"python_version": "3.11.9",
"platform": "win32",
"versions": {
"torch": "2.10.0+cu130",
"triton-windows": "3.6.0.post26",
"comfy-kitchen": "0.2.33",
"sageattention": "2.2.0+highway.20261022",
"mmgp": "3.7.14",
"transformers": "4.54.0",
"numpy": "2.1.2",
"safetensors": "0.8.0"
},
"scope": "Read-only snapshots, not memory peaks or a hardware compatibility claim. System RAM includes other applications; process memory belongs to this worker.",
"system_ram": {
"total_bytes": 50369753088,
"available_bytes": 36706119680,
"source": "psutil.virtual_memory"
},
"worker_memory": {
"rss": 872419328,
"vms": 1726484480,
"num_page_faults": 282858,
"peak_wset": 872419328,
"wset": 872419328,
"peak_paged_pool": 6538264,
"paged_pool": 6538264,
"peak_nonpaged_pool": 67744,
"nonpaged_pool": 67136,
"pagefile": 1726484480,
"peak_pagefile": 1726484480,
"private": 1726484480,
"scope": "This process only; values are bytes."
},
"windows_memory": {
"source": "Windows GetPerformanceInfo",
"physical_total_bytes": 50369753088,
"physical_available_bytes": 36706119680,
"commit_used_bytes": 24386719744,
"commit_limit_bytes": 69697105920,
"commit_available_bytes": 45310386176,
"commit_peak_bytes": 74975383552,
"scope": "System-wide snapshot; commit limit includes RAM/pagefile backing, not VRAM."
},
"cuda": {
"observed": true,
"scope": "Already-initialized current CUDA device only. Allocated/reserved are this process's PyTorch allocator; device free/total include other applications.",
"allocated_bytes": 390656,
"reserved_bytes": 33554432,
"device_name": "NVIDIA GeForce RTX 4080",
"device_free_bytes": 15718154240,
"device_total_bytes": 17170956288
}
},
"diagnostic_path": "C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\diagnostics\\worker-error-82faa1f9b7de4837bc35d8b206e7121a.json"
}
}
I updated it recently.
RC.3.9 GPU update (2026-10-22): includes platform-specific SageAttention wheels for Windows x86-64, Linux x86-64 and Linux ARM64, with runtime routes for SM80/86/87/89/90/100/103/110/120/121. Use the matching Python 3.11 / Torch 2.10 CUDA 13.0 worker. GPU support, driver requirements and update instructions. Model weights are unchanged.
Updating an existing installation: Download only the RC.3.9 ComfyUI ZIP (about 89 MB). Keep your existing model files; no model redownload is needed for this GPU update. The ZIP includes the platform-specific SageAttention wheels, so you do not need to download them separately. The installer may still download required software dependencies. Stop ComfyUI, back up the old Highway node and its runtime/asset configuration outside custom_nodes, then use INSTALL_WINDOWS.bat on Windows or linux/setup_linux.py on Linux. Follow the update instructions to preserve your model paths and prepare a compatible worker environment.
https://huggingface.co/DucHaiten/Highway-V1/resolve/05010ce38744fdc18c375b18c3ed2cb96d339ac3/downloads/DucHaiten-Highway-V1.0.0-rc.3.9-ComfyUI.zip
Try downloading and reinstalling the latest version; if the issue persists, please let me know.
Hi DucHaiten,
Thank you for the update, but the issue is still present because the Windows wheel is completely missing from the RC.3.9 ZIP archive.
I checked the contents of DucHaiten-Highway-V1.0.0-rc.3.9-ComfyUI.zip:
- Under the wheels directory, there is only:
ComfyUI/linux/wheels/sageattention-2.2.0+highway.20261022-cp311-cp311-manylinux_2_28_aarch64.whl
- Inside that wheel, only Linux aarch64 binaries (_fused.cpython-311-aarch64-linux-gnu.so and qattnsm80.cpython-311-aarch64-linux-gnu.so) exist.
- There is NO Windows x86_64 wheel (e.g. win_amd64.whl with SM89 .pyd support) included in the ZIP.
Because of this, when installing on Windows with an RTX 4080 (SM 8.9), the worker still fails at startup with:
ImportError: cannot import name '_qattn_sm89' from 'sageattention.core'
NATIVE_SMOKE_FAILED: Native target admission failed before model weights load
Also, modifying denselow_memory.py manually to fall back triggers:
ValueError: Runtime patch does not match this artifact provenance in runtime_source_transition.py
Could you please repackage the ZIP with the actual Windows x86_64 wheel containing the compiled SM89 kernel?
[{
"schema_version": 1,
"request_id": "a919f1d4d0204f19aa525828b7220439",
"worker_pid": 22716,
"captured_epoch_seconds": 1792943935.0743325,
"error": {
"type": "DispatchError",
"message": "NATIVE_SMOKE_FAILED: Native target admission failed before model weights load",
"notes": [],
"traceback": "Traceback (most recent call last):\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\custom_nodes\\duchaiten_highway\\_runtime\\work\\h3_model_core\\native_smoke.py\", line 185, in verify_native_runtime\n receipt = cached_admission(identity, lambda: runnative(plan, torch))\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\custom_nodes\\duchaiten_highway\\_runtime\\work\\h3_model_core\\native_smoke.py\", line 87, in cached_admission\n result = runner() # failure is never cached\n ^^^^^^^^\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\custom_nodes\\duchaiten_highway\\_runtime\\work\\h3_model_core\\native_smoke.py\", line 185, in <lambda>\n receipt = cached_admission(identity, lambda: runnative(plan, torch))\n ^^^^^^^^^^^^^^^^^^^^^^^^\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\custom_nodes\\duchaiten_highway\\_runtime\\work\\h3_model_core\\native_smoke.py\", line 140, in runnative\n dense = importlib.import_module('._dense_low_memory', package=__package__).dense_attention\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\.highway\\python-3.11.9\\tools\\Lib\\importlib\\__init__.py\", line 126, in import_module\n return bootstrap.gcd_import(name[level:], package, level)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"<frozen importlib._bootstrap>\", line 1204, in gcdimport\n File \"<frozen importlib._bootstrap>\", line 1176, in findand_load\n File \"<frozen importlib._bootstrap>\", line 1147, in findand_load_unlocked\n File \"<frozen importlib._bootstrap>\", line 690, in loadunlocked\n File \"<frozen importlib._bootstrap_external>\", line 940, in exec_module\n File \"<frozen importlib._bootstrap>\", line 241, in callwith_frames_removed\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\custom_nodes\\duchaiten_highway\\_runtime\\work\\h3_model_core\\_dense_low_memory.py\", line 29, in <module>\n from sageattention.core import (\nImportError: cannot import name '_qattn_sm89' from 'sageattention.core' (C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\.highway\\worker-e94f339695c6\\Lib\\site-packages\\sageattention\\core.py)\n\nThe above exception was the direct cause of the following exception:\n\nTraceback (most recent call last):\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\custom_nodes\\duchaiten_highway\\worker.py\", line 244, in main\n result = session.generate(message[\"request\"], message[\"output\"],\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\custom_nodes\\duchaiten_highway\\_runtime\\work\\highway-native78\\adapter.py\", line 528, in generate\n self._backend = self._create_backend(selection)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\custom_nodes\\duchaiten_highway\\_runtime\\work\\highway-native78\\adapter.py\", line 375, in createbackend\n plan, dispatch = self._binding.validate_selection(torch, resources, self.runtime_plan)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\custom_nodes\\duchaiten_highway\\_runtime\\work\\highway-native78\\backend.py\", line 144, in validate_selection\n native_smoke=smoke_probe(selected,torch_module=torch)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\ComfyUI\\custom_nodes\\duchaiten_highway\\_runtime\\work\\h3_model_core\\native_smoke.py\", line 187, in verify_native_runtime\n raise DispatchError('NATIVE_SMOKE_FAILED', 'Native target admission failed before model weights load',\nh3_model_core.execution_contract.DispatchError: NATIVE_SMOKE_FAILED: Native target admission failed before model weights load\n",
"code": "NATIVE_SMOKE_FAILED",
"request_trace": {
"worker_request_seconds": 2.6721681999915745,
"progress": [
{
"seconds": 0.060110899998107925,
"stage": "loading",
"completed": 0,
"total": 1,
"process_memory": {
"rss": 37711872,
"vms": 26550272,
"num_page_faults": 15399,
"peak_wset": 42160128,
"wset": 37711872,
"peak_paged_pool": 193264,
"paged_pool": 191168,
"peak_nonpaged_pool": 28408,
"nonpaged_pool": 16856,
"pagefile": 26550272,
"peak_pagefile": 31715328,
"private": 26550272
}
}
],
"environment": {
"PYTORCH_CUDA_ALLOC_CONF": "backend:cudaMallocAsync",
"PYTORCH_ALLOC_CONF": null,
"TORCHINDUCTOR_CACHE_DIR": "C:\\Users\\Berkay\\AppData\\Local\\Temp\\torchinductor_Berkay",
"TRITON_CACHE_DIR": null,
"CUDA_CACHE_PATH": null
},
"scope": "Worker request wall time and phase observations, including load/export; not host queue/IPC time, not per-request memory peaks. No synchronization or numerical policy changes."
},
"runtime_context": {
"schema_version": 1,
"observed_epoch_seconds": 1792943935.0678182,
"python_version": "3.11.9",
"platform": "win32",
"versions": {
"torch": "2.10.0+cu130",
"triton-windows": "3.6.0.post26",
"comfy-kitchen": "0.2.33",
"sageattention": "2.2.0+highway.20261022",
"mmgp": "3.7.14",
"transformers": "4.54.0",
"numpy": "2.1.2",
"safetensors": "0.8.0"
},
"scope": "Read-only snapshots, not memory peaks or a hardware compatibility claim. System RAM includes other applications; process memory belongs to this worker.",
"system_ram": {
"total_bytes": 50369753088,
"available_bytes": 34577080320,
"source": "psutil.virtual_memory"
},
"worker_memory": {
"rss": 872230912,
"vms": 1727037440,
"num_page_faults": 282714,
"peak_wset": 872230912,
"wset": 872230912,
"peak_paged_pool": 6538232,
"paged_pool": 6538232,
"peak_nonpaged_pool": 67744,
"nonpaged_pool": 67136,
"pagefile": 1727037440,
"peak_pagefile": 1727037440,
"private": 1727037440,
"scope": "This process only; values are bytes."
},
"windows_memory": {
"source": "Windows GetPerformanceInfo",
"physical_total_bytes": 50369753088,
"physical_available_bytes": 34577080320,
"commit_used_bytes": 22874734592,
"commit_limit_bytes": 73992073216,
"commit_available_bytes": 51117338624,
"commit_peak_bytes": 23245275136,
"scope": "System-wide snapshot; commit limit includes RAM/pagefile backing, not VRAM."
},
"cuda": {
"observed": true,
"scope": "Already-initialized current CUDA device only. Allocated/reserved are this process's PyTorch allocator; device free/total include other applications.",
"allocated_bytes": 390656,
"reserved_bytes": 33554432,
"device_name": "NVIDIA GeForce RTX 4080",
"device_free_bytes": 15718154240,
"device_total_bytes": 17170956288
}
},
"diagnostic_path": "C:\\Users\\Berkay\\Desktop\\ComfyUI-Easy-Install\\ComfyUI-Easy-Install\\diagnostics\\worker-error-5e76a7dc0de54035ad34390e82d3446f.json"
}
}
]
@rahip I will try to find time to take a look as soon as I can; at the moment, I’m exploring LLMs and working on some other tasks, so I can’t continue with this just yet.
@DucHaiten Understood, no problem! Take your time. I'll roll back to an earlier release for now. Whenever you get a chance to fix it or release an update, please let me know and I'll gladly test it on the RTX 4080. Good luck with your projects!
@rahip I’ve just fixed the issue and released an update, could you check if the error is gone now?
RC.3.10 hotfix (2026-10-28): repairs the SageAttention native-module import used by Ada GPUs and a separate source-provenance mismatch against the public checkpoint. Both problems are reproducible in RC.3.9. Model weights, C20, kernel arithmetic and dependency versions are unchanged.
Existing users: download only the RC.3.10 ComfyUI ZIP (about 89 MB). No model redownload and no separate SageAttention wheel download are needed. Close ComfyUI, extract into a new folder, run INSTALL_WINDOWS.bat on Windows or linux/setup_linux.py on Linux, then restart ComfyUI. Keep existing model files and saved workflows. Do not patch internal runtime files by hand; the update supplies a complete matching provenance manifest.
@DucHaiten Hi DucHaiten,
The RC.3.10 hotfix successfully resolved the SageAttention import issue (_qattn_sm89 / NATIVE_SMOKE_FAILED), and the worker now runs through the initial loading, conditioning, and Qwen stages for ~70 seconds!
However, it now fails right when activating the transformer model with a ParameterBindingError:
Error:
ParameterBindingError: Unsupported owned importer policy
Traceback:
File "custom_nodes\duchaiten_highway\_runtime\work\highway-native78\backend.py", line 62, in from_archive
if artifact['model']['parameter_import']!=OWNED_IMPORT_POLICY:
raise ParameterBindingError('Unsupported owned importer policy')
Diagnostic log attached: worker-error-fa768332c41e4661a0d637ba9a9da37f.json
It seems there is a policy mismatch between the current backend code's OWNED_IMPORT_POLICY and the parameter_import field in the public checkpoint/archive manifest. Could you please update this policy check or align it with the public checkpoint?
@rahip Apologies, since I lack a suitable GPU, I’m unable to fully verify things without logs from others, which leads to unpredictable errors that couldn't have been foreseen.
@rahip I’m fixing it, please check it again. I really hope there aren’t any silly mistakes left this time.
@DucHaiten It works perfectly now!
The ParameterBindingError is completely gone. The worker successfully loaded the model and GPU utilization hit 100% on my RTX 4080. The video rendered without any issues.
I also noticed you added the new example workflows (Video Edit, Video Reference, and Masked Video Edit) — I will definitely be testing those out as well. Thank you so much for the swift updates and great work!
@rahip Great, that’s wonderful to hear! If you have some free time, could you post a few more videos for me to check out? Or perhaps share some logs so I can see the performance metrics, specifically the speed and VRAM usage, when running on a 4080?
@DucHaiten Hi DucHaiten,
Here are the detailed performance and VRAM metrics extracted directly from the generation-summary.json generated in the ComfyUI output directory (inside the Highway run output folder):
### Source of Metrics
- File: ComfyUI/output/.../generation-summary.json
- Run Type: Image-to-Video generation (evaluated on default C20 schedule)
### Environment & Setup
- GPU: NVIDIA GeForce RTX 4080 (Compute Capability 8.9 / Ada Lovelace)
- OS: Windows 11 (Python 3.11, CUDA 13.0, Torch 2.10.0+cu130)
- Modules: SageAttention 2.2.0+highway.20261022, triton-windows 3.6.0.post26
- Target Recipe: ada-sm89-core37-v1 (INT8_ConvRot_CUTLASS + SageAttention)
- Schedule: C20 (20 evaluation steps)
### Execution Time & Speeds
- Total Numerical Time: 1201.28s (~20.02 mins)
- Transformer Generation Run: 1025.66s (~17.09 mins)
- Per-Step Evaluation Speed: ~51.1s per step
- Conditioning / Text Encode (Qwen3-VL-32B single-pass): ~32s
- VAE Decode Stage: ~34.5s
### VRAM & Memory Footprint
- Peak CUDA Allocated: 5.70 GB (6,125,715,540 bytes)
- Peak CUDA Reserved: 7.50 GB (8,053,063,680 bytes)
- Headroom: More than 8.5 GB of VRAM stayed completely free throughout the generation pass!
- Offload Strategy: The flat_artifact_owned_async_two_block_ring streamed all 50 blocks smoothly without any OOM or memory fragmentation issues.
The Ada Lovelace path works stably and cleanly. I will run a few more tests with the Video Edit / Reference workflows next and share further samples. Let me know if you need any other logs!
@rahip Is this a 15 second video?
@DucHaiten No, it's actually a ~5 second video (~124 frames at 24fps / 17 latent clip frames according to the decode logs).
The ~17-minute transformer generation time (about 51s per evaluation step on C20) is due to the heavy 50-block layer-by-layer offloading over host-device transfers (flat_artifact_owned_async_two_block_ring) along with the higher native resolution.
Since VRAM utilization stayed remarkably low (peak allocated was only ~5.7 GB, reserved ~7.5 GB out of 16 GB), there is plenty of headroom left. If there is a way or parameter to cache/keep more blocks resident in VRAM rather than cycling all 50 blocks individually, the generation speed on 16GB cards could probably scale up significantly!
@rahip You’re right. I hadn’t considered that. I’ll look into implementing two modes: one would be the current VRAM-saving mode, and the second would be an "auto" mode, this would automatically check the available VRAM at that moment and adjust usage accordingly for that specific generation.
@DucHaiten Hi DucHaiten,
I have just posted the generated sample video on the page for you to check out!
Here is the context regarding the video duration and the performance metrics from this run (from Highway_Video_reference_b0rgexv0):
### Workflow Context & Video Duration
- Multi-Part Run: This was rendered as part of a 3-stage continuation/extension chain (7.5s + 7.5s + 5s, total ~20s).
- Specific Log Target: The attached generation-summary.json belongs specifically to one of the 7.5-second segments (~180 frames at 24fps).
- Latent Footprint:
- video_latent_bytes: 18,370,560 bytes (1.4x scale over the default 5s / 13MB latent)
- audio_latent_bytes: 74,752 bytes
- context_elements: 43,361,280
### Key Performance & Hardware Metrics (RTX 4080 16GB)
- Generation Time (Transformer): 1533.99s (~25.56 mins) on C20 (20 steps)
- Total Pipeline Time: 1744.15s (~29.06 mins)
- Step Latency: ~76.7s per evaluation step (scaled proportionally with the 1.4x longer temporal context).
- Decode Time: ~55s (streaming chunks of 17 latent frames worked very well, no VAE spikes).
### VRAM & Offload Profile (Useful for your "Auto" Mode design)
- Peak Allocated: ~6.80 GB (7,304,341,092 bytes)
- Peak Reserved: ~8.97 GB (9,630,121,984 bytes)
- Free Headroom: ~7.03 GB remained completely unused on the 16GB GPU.
- Offload Activity:
- Block Mechanism: flat_artifact_owned_async_two_block_ring
- Ring Size: max_resident_blocks: 2
- PCIe Bus Traffic: Exactly 1,000 block calls across the 20 steps, pushing ~390.9 GB of tensor transfers back and forth from system RAM.
The memory management is extremely rock-solid and stable—zero fragmentation or leak. However, since the 4080 has ~7 GB of unused VRAM sitting idle, bumping max_resident_blocks dynamically in your upcoming "Auto" mode will cut down a huge portion of that ~390 GB PCIe traffic and speed up step latency dramatically.
Hope the video sample and these numbers help with tuning the dynamic residency manager!
@rahip I’ve just updated to a new version that includes an auto-adjustment feature for VRAM; it dynamically configures VRAM usage at runtime based on the amount currently available. This helps improve speed while making optimal use of the remaining VRAM, though the performance gain isn't particularly significant. I’m not sure if there’s a bottleneck elsewhere, but perhaps server-grade GPUs might see more noticeable benefits, hard to say for sure.