ImportError: No module named ‘triton’

快速结论：该问题通常出现在 Windows 便携版 ComfyUI 使用官方 MiniMax H3 参考生视频工作流、RTX 50 系（Blackwell）显卡推理时，系统直接触发 DPC_WATCHDOG_VIOLATION (0x133) 且没有任何 Python 异常；重点排查方向是驱动/硬件层面的 nvlddmkm 超时，而非 ComfyUI 工作流本身的配置错误。原始报错中若伴随 ImportError: No module named ‘triton’，那是另一条独立的环境缺失提示，不是本次重启的根因。

适用环境：Windows 11、ComfyUI 0.31.0 便携版（官方 Windows Portable）、RTX 50 系（报告者为 5090）、NVIDIA 驱动 nvlddmkm.sys 32.0.16.1088 / 610.88、PyTorch CUDA 环境、comfyui_workflow_templates_json 0.1.37、官方 MiniMax H3 模型文件；用户已排除自定义节点因素（未安装自定义节点亦复现）。

最快修复方案：暂无确认的一步修复方案。Issue 中最终定位为硬件问题，报告者联系供应商更换 CPU 与 GPU 板卡后完全恢复正常；如果同样的复现步骤下也出现“跑测试/负载切换即崩溃”，可优先尝试联系硬件供应商做检测与更换。

注意事项：更换硬件是报告者个人验证结果，并非通用修复；在未确认硬件故障前，不要盲目更换。评论中提到的 ck-attention + w4a8 + 8b 文本编码器 + int8 视频 VAE + KJNodes Low VRAM Attention + Spectrum 组合可规避崩溃，但会带来一定画质下降，属于规避而非根治，且依赖额外自定义节点。DPC 超时属于内核/驱动级问题，ComfyUI 侧日志不会给出栈信息，排查时不要只盯着节点报错。

问题场景

用户在全新安装的 ComfyUI 0.31.0 Windows 便携版上，运行官方 video_minimax_h3_r2v（MiniMax H3 Reference-to-Video）参考生视频工作流。使用官方 Comfy-Org 模型文件：minimax_h3_ref2va_pruned_int8_convrot.safetensors、qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors、minimax_h3_video_vae_fp16.safetensors、minimax_h3_audio_vae_fp32.safetensors。生成参数为 0.8 MP、3:4、5 秒、20 步、simple 调度器、res_multistep 采样器。排队生成后，电脑在生成过程中自动重启，且没有可见的 Python 异常输出。

报错原文

ImportError: No module named 'triton'

DPC_WATCHDOG_VIOLATION (0x133)
Arg1: 0 (one DPC/ISR exceeded its time allotment)
Arg2: 0x500
Arg3: 0x500
DPC_TIMEOUT_TYPE: SINGLE_DPC_TIMEOUT_EXCEEDED
NVIDIA driver: nvlddmkm.sys 32.0.16.1088 / 610.88
Crash time: 2026-08-11 17:02:18 +08:00
System uptime: 1:05:53

原因分析

最可能的原因是 NVIDIA 内核驱动 nvlddmkm.sys 在处理 GPU 负载时超出了 Windows DPC/ISR 的时间额度，触发 DPC_WATCHDOG_VIOLATION (0x133)，进而强制重启。minidump 栈中存在 17 个连续的 nvlddmkm.sys 帧，说明问题发生在驱动/内核路径，而非 ComfyUI 的 Python 计算图层面。

报告者进一步用一个纯 PyTorch 的矩阵乘法压测脚本复现：先运行数分钟，再切换到 FurMark（或反向操作）会导致 GPU 崩溃，说明崩溃与具体工作流弱相关，更像是显卡在高负载切换/长时高负载下的稳定性问题。最终该 Issue 以更换硬件（CPU 与 GPU 板卡）后解决而关闭。

至于 ImportError: No module named 'triton'，是 Python 环境缺少 triton 模块的提示，属于另一类环境缺失问题；在本次 Issue 中没有证据表明它会导致 DPC 超时或重启，不应把它当作本问题的根因。

环境排查

确认是否为全新安装的 ComfyUI 0.31.0 便携版，是否使用官方启动参数（报告者使用 --fast fp16_accumulation，且未安装自定义节点，因此未加 --disable-all-custom-nodes）。
确认是否已尝试禁用全部自定义节点后仍复现。
记录显卡型号（RTX 50 系 / Blackwell，报告者为 5090）与 NVIDIA 驱动版本（nvlddmkm.sys 32.0.16.1088 / 610.88）。
确认是否使用官方 comfyui_workflow_templates_json 0.1.37 中的 video_minimax_h3_r2v 工作流及官方 Comfy-Org 模型文件。
确认 Python 环境中是否确实缺少 triton（ImportError: No module named 'triton'），如缺失可单独处理，但这与重启无直接证据关联。
确认能否用纯 GPU 压测（如 Issue 中的 PyTorch 矩阵乘法脚本 + FurMark 切换）复现崩溃，以区分是 ComfyUI 还是硬件/驱动层面的问题。
确认宿主系统是否存在与显卡相关的历史崩溃记录（Windows 事件查看器 / minidump）。

解决步骤

先按 Issue 中的条件复现：全新 ComfyUI 0.31.0 便携版、不装自定义节点、使用官方 MiniMax H3 工作流与模型，观察是否在生成中无异常重启。
运行 Issue 中的纯 PyTorch 压测脚本（8192×8192 float16 矩阵乘法循环），并尝试在运行数分钟后切换到 FurMark，或反向操作，观察是否触发 GPU 崩溃，用于验证是否为硬件/驱动层面的稳定性问题。
若同样出现无异常重启，可优先尝试联系硬件供应商检测并更换 CPU 与 GPU 板卡（报告者更换后完全恢复正常，属于其个人验证结果，非通用结论）。
作为规避手段（可优先尝试）：评论中提到使用 ck-attention + w4a8 模型 + 8b 文本编码器 + int8 视频 VAE + KJNodes Low VRAM Attention + Spectrum 的组合，在相同分辨率与步数下不再崩溃，但会带来一定画质下降；该方案依赖额外自定义节点，属规避而非根治。
如果日志中同时出现 ImportError: No module named 'triton'，单独处理该 Python 依赖缺失问题，但不要以此认为已解决重启问题。

验证方法

按原参数（0.8 MP、3:4、5 秒、20 步、simple、res_multistep）重新排队相同的 MiniMax H3 参考生视频工作流，确认在完整生成周期内系统不再自动重启，并能在 Windows 事件查看器 / minidump 中确认没有新的 DPC_WATCHDOG_VIOLATION (0x133) 记录。若采用评论中的低显存规避组合，则需在相同分辨率与步数下连续跑通而不崩溃，同时接受可能出现的画质下降。硬件更换后需重新做一次同类压力测试以确认稳定。