Fedora 43上的ComfyUI:双虚拟环境 + 一键启动(2026年3月)

目标:保留两个Python虚拟环境(例如3.12和3.14)以确保兼容性,但通过一个简洁、轻量的配置自动启动ComfyUI。
已发布:
Aleksandar Stajić
已更新: 2026年3月1日 10:36
Fedora 43上的ComfyUI:双虚拟环境 + 一键启动(2026年3月)

Fedora 43 上的 ComfyUI:两个虚拟环境 + 一键启动(2026年3月)

日期:2026年3月
操作系统:Fedora 43
目标:保留两个 Python 虚拟环境(例如 3.12 + 3.14)以实现兼容性,但通过一个干净、轻量级的设置自动启动 ComfyUI。

企业交付操作系统

本指南是企业交付操作系统系列的一部分。使用这些分类中心来导航整个技术栈(基础设施 → 工作流 → 治理)。

架构

企业交付操作系统的参考架构。

DevOps 与运行时

部署、服务、端口、运行时操作和可重复性。

AI 工具与自动化

本地 AI 技术栈、编排、自动化和稳定的工作流。

安全与合规

本地 AI 系统的权限、加固和安全默认设置。

可观测性与性能

性能调优、监控、VRAM/RAM 预算和稳定性。

为什么保留两个虚拟环境?

AI 工具发展迅速。一些节点和 wheel 包落后于最新的 Python 版本,而另一些则需要它。

  • Python 3.12 虚拟环境 → “稳定且兼容”(TensorRT/LW wheels/Lightning 通常更适配)
  • Python 3.14 虚拟环境 → 拥有最新功能,但缺少更多 wheel 包 / 导入问题更常见

规则:切勿在虚拟环境之间混合安装。始终从你打算使用的虚拟环境中运行 ComfyUI。

设置:每个虚拟环境一个脚本

创建一个小的启动器脚本,它:
1) 切换到 ComfyUI 文件夹
2) 激活选定的虚拟环境
3) 在 localhost 上运行 ComfyUI

1) 为 Python 3.12 虚拟环境创建一个启动器

mkdir -p ~/.local/bin

cat > ~/.local/bin/comfyui-start-312.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

cd /home/x/ai/ComfyUI
source /home/x/ai/ComfyUI/.venv312/bin/activate
exec python main.py --listen 127.0.0.1 --port 8188
EOF

chmod +x ~/.local/bin/comfyui-start-312.sh

2) (可选)为 Python 3.14 虚拟环境创建一个启动器

cat > ~/.local/bin/comfyui-start-314.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

cd /home/x/ai/ComfyUI
source /home/x/ai/ComfyUI/.venv/bin/activate
exec python main.py --listen 127.0.0.1 --port 8189
EOF

chmod +x ~/.local/bin/comfyui-start-314.sh

现在你可以不加思索地运行任一版本:

  • ~/.local/bin/comfyui-start-312.sh
  • ~/.local/bin/comfyui-start-314.sh

自动启动:systemd 用户服务(最佳选项)

这会在登录时启动 ComfyUI,崩溃时重启,并保持最简化(无需 root,无重型包装器)。

1) 为 3.12 创建用户服务

mkdir -p ~/.config/systemd/user

cat > ~/.config/systemd/user/comfyui312.service <<'EOF'
[Unit]
Description=ComfyUI (Python 3.12 venv)
After=network.target

[Service]
Type=simple
WorkingDirectory=/home/x/ai/ComfyUI
ExecStart=/home/x/.local/bin/comfyui-start-312.sh
Restart=on-failure
RestartSec=2
Environment=PYTHONUNBUFFERED=1

[Install]
WantedBy=default.target
EOF

2) 启用 + 启动

systemctl --user daemon-reload
systemctl --user enable --now comfyui312.service
systemctl --user status comfyui312.service --no-pager

3) 日志(调试)

journalctl --user -u comfyui312.service -f

(如果你也需要 3.14 服务,请重复上述步骤,使用 comfyui314.service 和另一个脚本。)

一键 GUI:桌面启动器(在浏览器中打开 ComfyUI)

这会在你的菜单中创建一个应用条目。点击它:
1) 启动服务
2) 在浏览器中打开 UI

mkdir -p ~/.local/share/applications

cat > ~/.local/share/applications/comfyui.desktop <<'EOF'
[Desktop Entry]
Type=Application
Name=ComfyUI (Local)
Comment=Start ComfyUI and open the UI
Exec=sh -lc 'systemctl --user start comfyui312.service; xdg-open http://127.0.0.1:8188'
Icon=utilities-terminal
Terminal=false
Categories=Graphics;AI;
EOF

避免常见错误的注意事项

  • 如果你看到 pip 安装到 ~/.local/...,说明你不在正确的虚拟环境中(或者你没有激活它)。
  • 如果节点因 pkg_resources 缺失而失败 → 在选定的虚拟环境内安装 setuptools:source /home/x/ai/ComfyUI/.venv312/bin/activatepython -m pip install -U pip setuptools wheel
  • TensorRT 节点在较新的 Python 构建上失败是正常的:如果你不需要它,请禁用该自定义节点文件夹。

后续阅读

如果你想深入了解,以下指南与上述设置直接相关:

ComfyUI节点:依赖修复(Lightning、pkg_resources、ffmpeg)

修复常见的节点导入失败问题,确保您的ComfyUI堆栈在更新过程中保持稳定。

两个虚拟环境,两个端口,零混淆

干净地运行多个ComfyUI实例:端口、服务和可预测的配置文件。

VRAM预算:实际减少内存不足(OOM)的方法

实用的VRAM策略:注意力模式、模型大小、批处理以及实际限制。

本地AI加固:权限、沙箱和安全默认设置

降低本地AI系统的风险:文件权限、服务隔离和更安全的默认设置。

权衡(快速概览)

systemd用户服务

  • ✅ 稳定、自动重启、低开销、干净
  • ⛔ 需要一次性初始设置

桌面启动器

  • ✅ 一键式工作流程
  • ⛔ 仍然依赖于浏览器用户界面

两个虚拟环境

  • ✅ 两全其美(兼容性+最新版本)
  • ⛔ 您必须保持端口/服务分离以避免混淆

Related Articles

超越提示工程:一种更可靠的人工智能推理方法

超越提示工程:一种更可靠的人工智能推理方法

大型语言模型未必是因为缺乏推理能力而失败。它们常常失败,是因为推理过程没有得到充分的约束、质疑或验证。本文提出一种与领域无关的方法论,将提示转化为一种结构化的认知过程:将事实与假设分离,生成相互竞争的假说,检验反证,应用证伪,并检查结论在替代性框架下是否仍然稳定。目标不是让模型“更少同意”,而是让它的结论更少依赖于用户最初的框架。

MCP vs A2A vs UCP vs AP2 vs A2UI:智能体协议栈详解

MCP vs A2A vs UCP vs AP2 vs A2UI:智能体协议栈详解

MCP、A2A、UCP、AP2 和 A2UI 常被描述为相互竞争的智能体标准。它们大多解决的是不同的互操作性问题。本指南将每个协议映射到其实际标准化的边界,并展示它们如何在同一个生产系统中协同工作。

全面评估指南:精通LLM性能评估

全面评估指南:精通LLM性能评估

本指南详细介绍了评估工具(Evaluation Harness),这是一个在企业级LLMOps流程中严格评估大型语言模型(LLM)能力的关键框架。您将学习其设置方法、最佳实践以及高级技巧,以确保模型基准测试与优化的可靠性。

AI代理应该记住、遗忘、重新计算还是再次检索什么?

AI代理应该记住、遗忘、重新计算还是再次检索什么?

长时间运行的代理不应记住所有内容。本文提供了一个实用的生命周期模型,用于决定哪些内容应属于持久记忆、哪些内容应重新检索、哪些内容重新计算更安全,以及哪些内容应过期或被取代。

基于Next.js、Fastify、Prisma和NGINX的实用单体仓库架构

基于Next.js、Fastify、Prisma和NGINX的实用单体仓库架构

探索一种实用的单体仓库架构,结合Next.js、Fastify、Prisma与NGINX,重点展示实际集成与工作流程。

向量数据库、嵌入和重排序:检索的三个不同部分

向量数据库、嵌入和重排序:检索的三个不同部分

嵌入表示含义,向量数据库检索候选结果,重排序器则精炼结果。了解这三个检索层在RAG中如何不同并协同工作。

生成式人工智能解析:模型、检索、工具与应用并非同一回事

生成式人工智能解析:模型、检索、工具与应用并非同一回事

生成式AI不仅仅是一个模型。了解模型、检索、工具、上下文、运行时和应用程序如何在生产AI系统中协同工作。

AI Agent可靠性:为什么最终答案并不足够

AI Agent可靠性:为什么最终答案并不足够

正确的输出并不能证明推理的正确性、执行的安全性,或系统的可信赖性。

Google I/O 2026:反重力、AI Studio 以及向智能体开发工具的转变

Google I/O 2026:反重力、AI Studio 以及向智能体开发工具的转变

Google I/O 2026 向工程师们明确传达了一个信息:AI 工具正从自动补全迈向托管式自主执行。本文深入解析 Antigravity 2.0、Google AI Studio 不断扩展的角色、Gemini 3.5 Flash,以及在编排、锁定效应、验证和开发者工作流设计方面的实际权衡。

全新Qwen 3.5-Plus:开源AI迈入新纪元

全新Qwen 3.5-Plus:开源AI迈入新纪元

探索阿里巴巴Qwen 3.5-Plus的革命性特性与优势,这款为开发者打造的颠覆性开源人工智能模型。

人工智能何时应停止信任自身知识?——检索触发机制

人工智能何时应停止信任自身知识?——检索触发机制

AI 模型并非每个问题都需要检索。重要的问题在于知道何时其内部知识已不再足够。检索触发器是一个实用的决策边界,它决定 AI 系统何时应停止仅依赖模型知识,并在回答前获取外部证据。

什么是AI解决方案架构师?系统边界、职责与权衡

什么是AI解决方案架构师?系统边界、职责与权衡

AI解决方案架构师将业务需求转化为生产就绪的AI系统,涵盖数据、模型、工具、安全、运行时、评估和运维。