从 Python 地狱到 ComfyUI 成功启动：一次完整的 Windows AIGC 环境排错实录

优质文章学习记录

— 11 min read
从 Python 地狱到 ComfyUI 成功启动：一次完整的 Windows AIGC 环境排错实录

前言

在 Windows 平台部署 ComfyUI 时，很多用户都会遇到类似问题：
Python 已安装、CUDA 驱动正常、显卡也能识别，但 ComfyUI 仍然无法正常启动，或在启动器与命令行之间反复报错。

这些问题往往并非某一步操作失误，而是 Python 版本不一致、CUDA 与 PyTorch 构建不匹配，以及启动器未正确使用虚拟环境 等因素叠加造成的结果。

本文将围绕 ComfyUI + 绘世启动器 的典型使用场景，系统梳理以下三个高频问题：

  • Python 多版本共存导致的环境错位
  • CUDA / PyTorch 无法正确识别 GPU
  • 启动器与命令行运行环境不一致

并给出 可复现、可验证、适合新手操作的解决方案，帮助你在 Windows 环境下，先把 ComfyUI 的基础运行环境彻底跑稳。

本文聚焦基础python环境配置问题，插件与扩展相关内容将放在后续文章中单独说明。

在这里插入图片描述

本次实际使用的组合是：

  • 绘世启动器
  • ComfyUI 便携包（ComfyUI-aki-v3）
  • NVIDIA 显卡环境（CUDA）
  • PyTorch（CUDA 版本）
  • GitHub 插件体系（Impact-Pack / SAM2）

这些组件单独使用时问题不大，但一旦组合在一起，就会出现一个典型问题：
每一个工具都假设“系统环境是干净且唯一的”，而现实恰恰相反。

例如：

  • Python 工具默认认为：系统里只有一个 Python
  • 启动器默认认为：系统 Python 就是运行 Python
  • PyTorch 默认认为：安装它的 Python 就是运行它的 Python
  • GitHub 插件默认认为：网络环境稳定、GitHub 可直连

这些“合理但不现实”的默认假设，在同一台 Windows 机器上叠加后，最终导致了一系列看似无关、实则强相关的问题集中爆发，包括：

  • Python 版本混乱
  • CUDA / PyTorch 无法识别
  • 启动器与命令行行为不一致
  • 插件安装过程中 GitHub 克隆反复失败

因此，本次环境“全面崩溃”的核心原因并不是操作失误，而是：

多个工具在同一环境中叠加运行，而它们都默认用户的系统是“干净的”。

理解这一点，是后续所有问题能够被逐一拆解和解决的前提。

二、问题一：Python 版本混乱（3.10 / 3.11 / 3.14 冲突）

在所有问题中，Python 版本混乱是第一个、也是最致命的根因。
后续出现的 PyTorch、CUDA、插件安装异常，本质上都可以追溯到这一点。

2.1 现象表现

在实际排查过程中，最让人迷惑的不是报错本身，而是**“每个地方看到的 Python 版本都不一样”**：

  • 在 PowerShell / CMD 中执行 python -V，显示的是 Python 3.14
  • 进入 ComfyUI 自带的 venv 后，python -V 却是 Python 3.10
  • 绘世启动器的环境检测中，显示的 Python 与命令行结果不一致
  • PyTorch 安装成功，但运行时却出现：
    • 模块找不到
    • CUDA 不可用
    • 运行路径与安装路径不一致

这些现象单独看都不算“致命错误”，但组合在一起，就会让人产生一种错觉：
“明明都装好了，为什么就是跑不起来？”

2.2 核心原因

问题的根本并不复杂，但非常典型——Windows 下多 Python 共存 + 默认 PATH 机制。

具体来说，核心原因有三点：

  1. Windows 的 PATH 中存在多个 Python
    • 系统 Python（可能是 3.14）
    • 其他软件自带的 Python
    • ComfyUI 实际需要使用的 Python 3.10
  2. 启动器默认调用的是“系统 Python”
    • 启动器并不会自动识别 venv
    • 如果不手动指定，它只会从 PATH 中找第一个 python.exe
  3. ComfyUI 对 Python 版本是“有要求的”
    • 当前稳定版本的 ComfyUI + PyTorch 生态，明确推荐 Python 3.10
    • 使用 3.11 / 3.14 虽然可能安装成功，但极易在运行期出问题

这就造成了一个典型错位：

你以为你在用 venv 的 Python 3.10，
但启动器实际上还在调用系统里的 Python 3.14。

2.3 解决方案

解决思路只有一个：彻底让“运行 Python”与“预期 Python”对齐。

具体操作步骤如下：

  1. 单独安装 Python 3.10
    • 不要覆盖系统 Python
    • 指定一个清晰、固定的安装目录
  2. 使用 venv 进行环境隔离
    • 所有依赖（PyTorch、ComfyUI 插件）只安装在 venv 内
    • 不再向系统 Python 安装任何依赖
  3. 在绘世启动器中手动指定 Python 路径（关键步骤）

将启动器中的 Python 路径明确设置为：

E:\Aicg\Comfyui\ComfyUI-aki-v3\venv\Scripts\python.exe

这一操作的意义在于：

  • 强制启动器使用 venv 的 Python
  • 避免 PATH 顺序、系统环境变量带来的不确定性
  • 确保 PyTorch、CUDA、插件全部运行在同一解释器下

在完成这一步之后，Python 相关的“玄学问题”基本会一次性消失。

2.4 关键经验总结

这次踩坑之后，有一个经验非常值得反复强调：

永远不要相信系统 python，要相信 venv。

在 Windows + 深度学习 + 启动器 + 插件生态的组合下：

  • 系统 Python 只适合“存在”
  • venv 才适合“运行”
  • 启动器不做强制约束，就必须由使用者来“钉死路径”

这是后续所有问题能够继续排查和解决的前提条件。

在这里插入图片描述

三、问题二：CUDA / PyTorch 版本不匹配报错

如果说 Python 版本混乱 是“地基问题”，
那么 CUDA / PyTorch 不匹配，就是在地基不稳的情况下继续往上盖楼，最终必然塌。

这一问题在 Windows + NVIDIA 显卡 + 启动器环境中极其常见。

3.1 现象表现

在排查过程中，出现了以下典型现象：

  • 绘世启动器环境检测中提示：CUDA 无效
  • 在 Python 中执行：
import torch torch.cuda.is_available()

返回结果为：

False
  • 但从硬件层面来看：
    • 显卡型号明确：RTX 4070 Laptop
    • NVIDIA 驱动已安装
    • 系统层面 GPU 工作正常

也就是说，系统“看得到 GPU”，但 PyTorch “用不到 GPU”。

3.2 核心原因

这类问题通常不会只有一个原因，而是两个常见错误叠加导致的：

原因一：PyTorch 安装在“错误的 Python 环境”
  • 系统 Python ≠ venv Python
  • PyTorch 可能被装在：
    • 系统 Python
    • 其他软件自带 Python
  • 但 ComfyUI 实际运行的是 venv 内的 Python

结果就是：

你安装了 PyTorch，但运行时用的不是它所在的解释器。
原因二：CUDA 版本与 PyTorch 不匹配
  • PyTorch 的 CUDA 是内置运行时（不是系统 CUDA Toolkit）
  • 不同 PyTorch 版本对应不同 CUDA 构建：
    • cu118
    • cu121
    • cpu-only

如果：

  • 安装了 CPU 版 Torch
    或
  • 安装了 CUDA 版本，但与显卡 / 驱动不兼容

都会导致 cuda.is_available() == False。

3.3 解决方案

解决原则只有一句话：

在 venv 中，显式安装“与显卡和驱动匹配的 CUDA 版 PyTorch”。

具体操作如下。

第一步：确保已经进入 venv
E:\Aicg\Comfyui\ComfyUI-aki-v3\venv\Scripts\activate
第二步：安装 CUDA 版 PyTorch（以 CUDA 12.1 为例）
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

说明：

  • 不要用默认 PyPI
  • 不要让 pip 自行判断
  • 明确指定 PyTorch 官方 CUDA 构建源
第三步：验证安装结果
python -c "import torch; print(torch.__version__); print(torch.cuda.is_available())"

期望输出结果为：

  • PyTorch 版本号正常
  • torch.cuda.is_available() 返回 True

3.4 结果

在完成上述操作后，环境状态恢复正常：

  • CUDA 成功启用
  • PyTorch 正确识别 GPU
  • 显卡信息显示为：RTX 4070 Laptop
  • ComfyUI 推理阶段不再回退到 CPU

至此，计算层的问题被彻底解决，后续插件与节点的问题，才有继续排查的基础。

四、问题三：启动器使用了“错误的 Python”

在完成 Python 版本与 PyTorch / CUDA 的修复之后，表面上看环境已经“能跑了”，但一个新的问题随之出现：

命令行可以正常启动 ComfyUI，但启动器的一键启动却反复失败。

这一现象往往会让人误判问题已经回到 CUDA 或 PyTorch，其实完全不是。

4.1 现象

具体表现为：

  • 在 venv 环境中，通过命令行手动执行 python main.py，ComfyUI 可以正常启动
  • 浏览器可以访问 http://127.0.0.1:8188
  • 但使用绘世启动器的 一键启动：
    • 环境检测反复报错
    • 提示 Python / CUDA 异常
    • 与命令行运行结果明显不一致

换句话说，同一套代码，在不同入口下表现完全不同。

4.2 原因

原因并不复杂，但非常容易被忽略：

启动器默认调用的是“系统 Python”，而不是 venv 中的 Python。

即使：

  • venv 已经正确创建
  • PyTorch / CUDA 已在 venv 中配置完成
  • 命令行明确使用的是 venv Python

只要启动器没有被显式告知：

“你应该用哪个 python.exe”

它就会继续从系统 PATH 中寻找默认 Python（本例中为 Python 3.14），从而再次造成环境错位。

这也是为什么会出现：

  • 启动器报错
  • 命令行却一切正常

两者并不在同一个 Python 运行环境中。

4.3 解决方案

解决这一问题的关键在于：
不要试图“让启动器自己判断”，而是直接强制指定路径。

具体操作步骤如下：

  1. 启用绘世启动器的「专家模式」
  2. 在高级设置中，手动配置：
    • Python 路径覆盖
    • Git 路径覆盖（后续插件安装依赖）

其中，Python 路径必须明确指向 ComfyUI 所使用的 venv：

E:\Aicg\Comfyui\ComfyUI-aki-v3\venv\Scripts\python.exe

这一设置的效果是：

  • 启动器不再使用系统 Python
  • 所有检测、启动、插件安装行为，全部在 venv 中执行
  • 命令行与启动器的行为彻底对齐

4.4 关键结论

这一步完成后，可以得到一个非常重要的结论：

启动器 ≠ venv，必须手动对齐它们。

启动器只是一个“入口工具”，并不会自动理解你的 Python 隔离策略。
在多 Python、多环境并存的 Windows 系统中：

  • 不显式指定路径 = 不可控
  • 一键启动想稳定，必须先把“解释器”钉死

这一点解决之后，后续所有插件、依赖与网络问题，才有继续讨论的意义。

总结

在 Windows 平台使用 ComfyUI 时，大多数启动失败或环境异常问题，最终都可以归结为三个核心原因：

  • Python 版本未统一，运行环境发生错位
  • PyTorch 未安装正确的 CUDA 构建版本
  • 启动器未显式使用虚拟环境中的 Python

只要做到以下几点，基础环境基本可以稳定运行：

  • 使用 Python 3.10，并通过 venv 进行环境隔离
  • 在虚拟环境中安装匹配显卡驱动的 CUDA 版 PyTorch
  • 在绘世启动器中明确指定虚拟环境的 Python 路径

完成以上配置后，ComfyUI 应能够正常启动并识别 GPU，满足日常使用与基础工作流运行需求。

在基础环境稳定的前提下，再逐步引入插件和复杂节点，能够显著降低后续排错成本。
插件相关的问题与安装思路，将在后续文章中继续整理说明。
comfy插件体系与git解析

Read more

开源ASR新选择：Fun-ASR WebUI本地部署与使用指南

开源ASR新选择：Fun-ASR WebUI本地部署与使用指南 在远程办公、在线教育和智能客服日益普及的今天，语音转文字的需求正以前所未有的速度增长。会议录音、课堂讲解、访谈记录——这些原本需要人工逐字整理的内容，如今都期待通过自动语音识别（ASR）技术实现高效转化。然而，当我们将目光投向主流云服务时，高昂的调用成本、数据外传的风险以及网络延迟带来的体验割裂，常常让人望而却步。 正是在这种背景下，Fun-ASR WebUI 的出现显得尤为及时。这款由钉钉联合通义实验室推出的开源语音识别系统，不仅具备高精度多语言支持能力，更通过一个简洁直观的图形界面，让非技术人员也能轻松完成复杂的语音转写任务。它真正实现了“本地运行、零代码操作、全程可控”的理想状态。 从模型到交互：理解 Fun-ASR 的核心架构 Fun-ASR 并非简单的工具封装，而是一套经过深度优化的端到端语音识别体系。其底层搭载的是轻量级大模型 Fun-ASR-Nano-2512，专为本地部署设计，在保持较高准确率的同时大幅降低资源消耗。该模型采用编码器-解码器结构，并融合注意力机制，能够对梅尔频谱图进行有效建模，逐词

科哥定制FunASR镜像发布｜支持标点恢复与多语言识别的WebUI实践

科哥定制FunASR镜像发布｜支持标点恢复与多语言识别的WebUI实践 1. 背景与核心价值 随着语音识别技术在智能客服、会议记录、内容创作等场景中的广泛应用，开发者对易用性高、功能完整且可快速部署的本地化语音识别系统需求日益增长。FunASR作为阿里巴巴达摩院开源的高性能语音识别工具包，具备良好的精度和扩展能力，但其原始版本主要面向API服务调用，缺乏直观的图形化交互界面。 为此，科哥基于 speech_ngram_lm_zh-cn 模型进行二次开发，推出了定制化FunASR镜像： 镜像名称：FunASR 语音识别基于speech_ngram_lm_zh-cn 二次开发构建by科哥 该镜像集成了WebUI交互系统，显著降低了使用门槛，支持中文标点自动恢复、多语言识别（含粤语、日语、韩语）、时间戳输出及SRT字幕生成等功能，真正实现“开箱即用”的本地语音转写体验。 本篇文章将深入解析该定制镜像的技术架构、核心功能实现逻辑，并提供完整的使用指南与工程优化建议。 2. 技术架构与关键组件 2.1 整体架构设计 该定制镜像采用模块化设计，整合了前端WebUI、后端推理引擎
.NET Core WebAPI 开发工程师的面试问题

.NET Core WebAPI 开发工程师的面试问题

让我们一起走向未来 🎓作者简介：全栈领域优质创作者 🌐个人主页：百锦再@新空间代码工作室 📞工作室：新空间代码工作室（提供各种软件服务） 💌个人邮箱：[[email protected]] 📱个人微信：15045666310 🌐网站：https://meihua150.cn/ 💡座右铭：坚持自己的坚持，不要迷失自己！要快乐 目录 * 让我们一起走向未来 * 一、.NET Core 基础 * 1. **什么是 .NET Core，和 .NET Framework 有什么区别？** * 2. **什么是依赖注入（DI）？为什么要使用依赖注入？** * 3. **如何在 .NET Core 中创建一个 Web API？** * 二、Web
Linux 下 Tomcat 结合内网穿透 实现 Web 应用公网访问

Linux 下 Tomcat 结合内网穿透 实现 Web 应用公网访问

前言 在日常的 Web 开发与测试中，常常会遇到这样的困扰：本地部署好的 Java Web 项目，只能在局域网内访问，想要让异地的同事协作调试、给客户演示功能，或是外出时远程查看项目运行状态，往往需要繁琐的公网 IP 配置、端口映射，甚至要依赖云服务器部署。 而有一种实用的内网穿透功能，能轻松打破这种网络限制 —— 它可以将本地运行的服务，无需复杂配置就能映射到公网，生成可全球访问的地址，让本地的 Tomcat 服务随时被外部设备访问。 今天我们要分享的，就是如何借助这一功能，搭配经典的 Tomcat 服务器，在 Linux 系统中快速实现 Web 应用的公网访问，整个过程简单易操作，几分钟就能完成配置，解决开发和演示中的网络访问难题。 1.在CentOs7上安装OpenJDK 在已安装套件中查找含有java字符串的文件： rpm-qa|grepjava 若没有安装则开始安装吧！ 查询yum中存在的JDK版本： yum list |grep java-11