企业官网建设流程全解析

今年最火的关键词里，“工作流”绝对排得上前三。2024年底到2025年，我陆续接触过 ComfyUI、Dify、Coze，也在本地跑过 Ollama 和各类大模型部署，但真正让我愿意花一个完整周末去部署，并且乐意推荐给朋友的，是 Infinite-Canvas 这个开源的 AI 绘画工作流平台。它把无限画布、节点编排、任务调度和本地模型后端整合在一起，做成了一套可以私有化部署的一站式方案。这篇文章围绕 Infinite-Canvas 的部署和实战展开，适合想自己搭一套 AI 绘画生产力工具的团队与个人开发者。

1. Infinite-Canvas 到底是什么：不只是“能画图”的工作流平台

1.1 项目定位：从“单张出图”到“批量化生产”

Infinite-Canvas 本质上是一个面向 AI 绘画场景的可视化工作流编排平台。你在浏览器里打开它，看到的不是传统 Web 后台上那种表单和列表，而是一块可以无限平移、无限缩放的画布。画布上有各种节点：文生图、图生图、局部重绘、超分放大、风格迁移、图片保存，甚至还可以接入大语言模型节点来做提示词优化。你把这些节点用连线串起来，一次点击，整条链路就会按顺序执行。

这个定位和单机版的 Stable Diffusion WebUI 完全不同。WebUI 更适合单张调试，你改一个参数、点一次生成、看一次结果，过程很直觉。但如果要做批量风格化、多模型对比、团队协作、自动化调用，WebUI 就明显吃力了。Infinite-Canvas 解决的核心问题是“把零散的出图过程变成可复用、可管理、可调用的工作流”，这也是我把它叫做一站式 AI 绘画工作流平台的原因。它适合那些已经不再满足于“能画图”，而是希望“稳定地、批量地产出图片”的人。

1.2 我选它而不是 ComfyUI / Dify 的理由

我在选型时其实对比过好几个方向。ComfyUI 的节点能力确实强，但它的画布和文件管理偏专业，团队里非技术成员上手难度高，而且任务队列、用户权限、工作流版本管理这些偏平台化的能力比较弱。Dify 在 LLM 应用编排上很强，但它的定位更偏向文本对话、Agent、知识库，生图相关能力只能算点缀。Coze 这类云端平台用起来方便，可数据都在别人服务器上，对于有私有化诉求的团队很尴尬。

Infinite-Canvas 让我觉得顺手的点在于：它从底层就是按“绘画生产平台”来设计的。画布交互流畅，节点类型覆盖了绘画场景的常见操作，自带任务队列和并发控制，而且整个项目通过 Docker Compose 一键拉起，部署门槛比裸机装一套 ComfyUI 加各种插件低不少。下表是我当时做选型对比时的思路：

1.3 适用人群与真实场景

到底什么样的人适合用它？从我的实际接触来看，主要有三类。第一类是画师和设计师，他们用 Infinite-Canvas 批量生成角色参考图、材质贴图、风格草图，先把工作流固定下来，再在结果上做精修。第二类是运营和内容团队，比如每天需要产出大量封面图、社媒配图、信息图模板，以前人工一张张做，现在做成模板工作流，换关键词换风格就能出。第三类是小团队和创业公司，把 Infinite-Canvas 作为内部 AI 图片服务，开放 API 给商城、CMS 或内容中台调用，实现商品图批量生成、素材自动加工。

我实际部署下来最大的感受是：这个项目把“绘画”和“工程化”之间的缝隙填上了。它不是替代某个具体画图软件，而是给你一层统一调度和管理的框架，下面接什么模型、上面挂什么业务，都由你自己决定。

2. 部署前先想明白三件事：硬件、依赖与版本

2.1 硬件配置怎么算：显存、内存和硬盘都要提前估

很多人一上来就问“需要什么显卡”，但这个问题要拆开看。Infinite-Canvas 平台本身不直接跑 Stable Diffusion 模型，真正吃显存的是你接进来的生图后端。平台端更像一个“总控台”，主要消耗内存和 CPU。所以我在规划硬件时，会把平台容器和后端模型容器分开看。

以我自己的一台测试机为例：CPU 8 核、内存 16G、显卡 RTX 3060 12G、系统盘 256G NVMe。这个配置跑一套单后端的工作流完全够用。如果想让平台和模型都跑得舒服，我建议最低配置是 8 核 CPU、16G 内存、显存 8G 以上，硬盘预留至少 100G 给模型文件和输出图片。显存方面，SD 1.5 系列的模型推理大概需要 4G 到 6G，SDXL 则需要 8G 到 10G，如果还要做 LoRA 叠加和超分放大，24G 显存会更从容。

硬盘空间经常被忽略，但实际跑起来之后涨得很快。一个 SDXL 模型文件 6G 到 7G，控制网络和 LoRA 文件动辄几个 G，再加上每天的生成结果，一周就能吃掉几十 G。我的习惯是把数据目录独立挂载到一块大容量数据盘，而不是放在系统盘里，避免系统盘写满导致整个服务异常。

2.2 软件依赖与端口规划

部署环境方面，我用的是 Docker + Docker Compose v2，这也是项目官方推荐的方式。为什么不用裸机部署或者直接上 Kubernetes？裸机部署要手动装 Python、Node、Redis、PostgreSQL 等一堆依赖，版本冲突很头疼；Kubernetes 对小团队来说又太重，光是维护集群本身就需要精力。Docker Compose 恰好卡在中间：一条命令启动所有服务，升级回滚都方便，适合中小规模团队。

端口规划也要提前想清楚。Infinite-Canvas 涉及的默认端口通常包括：Web 服务端口 8080，任务执行引擎和 API 服务端口 5678、5432 或 6379 按部署方式不同会暴露数据库和缓存端口，SD WebUI 默认 5000，Ollama 默认 11434。如果你服务器上已经有服务占用这些端口，一定要在 .env 里改掉，否则容器会起不来。我给几个建议：一是不要把所有端口都暴露到公网，内网访问或者用 Nginx 反向代理即可；二是数据库、Redis 这类中间件端口只在 Docker 内部网络中使用，不要映射到宿主机，减少暴露面。

2.3 镜像与版本选择：稳定优先还是追新优先

镜像版本的选择，我踩过一次坑。最开始图省事，直接用了 latest 标签，结果某次上游 Stable Diffusion WebUI 升级后，Infinite-Canvas 里的生图节点连不上后端，排查了半天才发现是版本不兼容。从此之后我给自己定了个规矩：非必要不追 latest，按 release tag 部署。

具体做法很简单。先去项目的 GitHub Releases 页面看最新稳定版本号，然后拉取对应的 tag 镜像，比如 v0.4.5。升级前先读 release notes，确认没有破坏性变更，再决定要不要升级。工作流平台的部署不是“装上就行”，它是一套长期运行的业务系统，稳定应该排在第一位。如果你的核心诉求是跑通流程，就选一个社区验证过的稳定版本，不要再折腾花活。

3. 完整部署实操：用 Docker Compose 从零跑通

3.1 下载项目与初始化目录结构

部署第一步是拿到项目代码和默认配置文件。Infinite-Canvas 是开源项目，直接去 GitHub 搜索官方仓库即可。拿到仓库地址后，克隆到服务器上：

git clone https://github.com/your-name/infinite-canvas.git cd infinite-canvas cp .env.example .env mkdir -p data/models data/output data/logs data/redis data/postgres

我习惯先把数据目录建好，并挂载到宿主机。这种做法的好处是：容器可以随时删掉重建，但数据不丢。尤其是 Redis 缓存和 PostgreSQL 数据库，如果存在容器内部，一个 docker compose down 就会把数据清空，到时候后悔都来不及。

目录结构也不用追求完全按官方来，你只需要在 .env 里把路径指向自己的目录即可。我更喜欢把数据统一放在一个 data 目录下，方便备份。备份时只需要打包 data 目录和 .env 文件，整个平台就能迁移到另一台服务器上。

3.2 配置 .env 环境变量：密码、存储和模型后端

环境变量是部署中最容易忽视的环节。我打开 .env 后，第一件事就是改默认密码和管理员账号，这是部署安全的第一步。除此之外，几个关键变量我建议重点确认：

# Web 服务端口 APP_PORT=8080 # 管理员初始账号，部署后立即修改 ADMIN_USER=admin ADMIN_PASSWORD=your-strong-password # 数据存储路径 DATA_DIR=./data OUTPUT_DIR=./data/output # 任务并发数 WORKER_CONCURRENCY=2 # 可用的 GPU 编号，多卡场景用逗号分隔 GPU_VISIBLE_DEVICES=0 # 生图默认超时时间，单位秒 IMAGE_GENERATION_TIMEOUT=300

WORKER_CONCURRENCY 这个参数我专门说一下。它代表同一个生图后端同时能跑多少个任务，不是越大越好。如果你的显卡只有 8G 显存，并发调成 2 都可能在批量任务时把显存打满。我一开始把它设成 4，结果连着报 CUDA out of memory，后来老老实实改回 2。当你后面换了 24G 显存的大卡，再慢慢往上加也不迟。

3.3 使用 docker compose 启动并初始化

配置好环境变量后，进入项目目录，执行以下命令：

docker compose pull docker compose up -d docker compose ps

docker compose pull 会拉取所有镜像，docker compose up -d 会在后台启动服务，docker compose ps 用来查看容器状态。等待一两分钟后，所有容器状态变成 running 或 healthy，再用 docker compose logs -f app 查看平台主服务的日志。如果日志里出现 “ready” 或 “server started” 之类的字样，说明启动成功。

然后打开浏览器，访问 http://服务器IP:8080，进入初始化向导。向导会让你创建管理员账号、确认存储路径、添加生图后端。这里有一个容易忽略的问题：如果你用的云服务器，记得在安全组里放行 8080 端口，否则页面永远打不开。另外，Web 页面能打开不代表生图链路是通的，一定要继续走到后端连接测试那一步。

3.4 接入生图后端：SD WebUI 与 Ollama 的实战配置

Infinite-Canvas 本身不内置绘图模型，所以安装完平台后，还要接一个能实际生成图片的后端。我目前用的是 Stable Diffusion WebUI，在 docker-compose 中加入如下服务片段：

sd-webui: image: your-sd-webui-image:latest ports: - "5000:5000" volumes: - ./data/models:/app/models - ./data/output:/app/output environment: - GPU_VISIBLE_DEVICES=0 command: ["--api", "--listen", "--port", "5000"]

启动 SD WebUI 时一定要带--api参数，否则它只有一个网页界面，Infinite-Canvas 无法通过 API 调用。然后在 Infinite-Canvas 的后端管理页面里，添加后端地址：

Stable Diffusion WebUI API 地址：http://sd-webui:5000

这里要格外注意，不能写 http://localhost:5000。在 Docker 网络里，localhost 指向的是发起请求的容器本身，而不是 SD WebUI 容器。跨容器访问要用 Compose 服务名 sd-webui，或者用宿主机 IP。

如果还想在平台里做提示词自动优化，可以再挂一个 Ollama 容器，用来跑本地大模型。做法是给 Ollama 设置 base URL 为 http://ollama:11434，然后在工作流里拖入一个 LLM 节点，让它根据你的主题关键词生成英文提示词，再喂给文生图节点。这条链路跑通之后，你会发现整个工作流的价值直接上升一个台阶。

4. 上手实战：在无限画布里搭一条完整工作流

4.1 第一个工作流：文生图 → 放大 → 批量风格化

部署只是开始，真正有意思的是画布上的工作流编排。我第一次完整跑通的工作流，包含三个环节：文生图、放大、批量风格化。考虑到新手可能连节点都不太熟悉，先看下面节点对应表：

在无限画布上，我习惯把每个环节放到一块相对独立的区域，然后用连线从 Text Encode 节点连到 Sampler，Sampler 再连到 Latent Upscale，最后接 Style Transfer 和输出节点。画布无限延展的优势在这里体现得很明显：节点多的时候可以横向排开，也可以纵向分列，不需要像普通图表工具那样挤在一屏里。

开始时不要追求一步到位，先建一个只包含文生图和输出节点的最简链路，确认图片能正常保存到输出目录，再逐步加入放大和风格化节点。我见过太多人第一步就搭一个十几节点的巨无霸工作流，结果报错之后根本不知道问题出在哪个环节。

4.2 节点参数配置的细节和坑

节点参数是决定出图质量的关键，也是坑最多的地方。先说 Seed 参数：如果固定 seed，同一套参数生成的图每次都一样，方便复现；如果希望每次随机，就把 seed 设置成随机值。批量出图时建议固定 seed 并逐步微调其他参数，方便做对比。

然后是采样步数，也就是 Steps。SD 1.5 在 20 到 30 步之间就能出不错的图，过量步数不仅慢，边际收益也不高。CFG scale 一般在 7 到 9 之间，太高容易让画面过饱和、变形，太低则会出现内容与提示词不贴合的问题。这些参数没有绝对的正确值，但一定范围内可以快速锁定。

批次数和批次大小是两个容易混淆的参数。Batch count 表示连续跑多少次，相当于一个循环；Batch size 表示一次并行生成几张，更吃显存。初学者如果显存不大，我建议把 Batch size 固定为 1，用 Batch count 来控制总产出数量，否则极易触发显存溢出。

4.3 模板复用与团队协作

Infinite-Canvas 支持把工作流保存为模板，并导出 JSON。这个功能我强烈建议团队从一开始就用起来。我们团队的做法是：每类需求固化一套模板，比如“电商白底图”“小红书封面”“风格化头像”，模板里节点的连接方式、默认参数、输出命名规则全部统一。运营同学只需要填写关键词和风格，不用去理解底层节点逻辑。

团队协作时还有一个容易被忽略的点：提示词规范。同样描述一个“产品”，不同的人写出来的提示词完全不同，出图风格也会漂移。我给的建议是在模板中预留提示词片段节点，把它做成统一的开头或后缀，比如固定的画质词、镜头描述词、光照描述词，再让运营填入主体内容。这样既保留了灵活性，又保证了整体风格的一致性。

5. 生产环境化：调度、资源与存储的进阶优化

5.1 任务队列与并发：把 GPU 用满但不至于 OOM

当工作流开始被团队频繁使用，任务就会堆积。Infinite-Canvas 内置了任务队列，所有被触发的工作流都会进入队列，由 worker 按顺序拉取执行。队列机制的好处是，即使同时提交了 20 个任务，系统也不会一次性把它们全塞给 GPU，而是按照可配置的并发数挨个处理。

我在生产环境里的配置是：并发数 2，任务队列上限 100。这样设置的原因很简单，当前机器的 GPU 显存只够同时跑 2 个 SDXL 任务。如果你只是个人使用，又不急着出图，把并发数设为 1 其实最稳妥，至少不会把机器卡死。等以后换了更大的显存，再逐步往上加。

队列积压了怎么办？优先考虑的不是调高并发，而是提高单张出图速度。减少不必要的超分放大节点、关闭过高分辨率、检查是否有重复的模型加载，这些往往比简单加并发更有效。

5.2 低显存机器的优化策略

如果你和我一样，手头只有一张中端显卡，也不要放弃。低显存环境下有几招很实用。

第一，开启低显存模式。在 SD WebUI 的启动参数里加上--medvram或者--lowvram，它会用算法降低显存占用，代价是略微变慢。第二，保持模型半精度加载。现在的主流模型和脚本都已经默认用 fp16，不要手动切换成 fp32。第三，控制输出分辨率和批次大小。一次只生成一张 512x768 的图，比一次生成四张 512x512 要稳定得多。

显存占用估算有个简单方法：总显存占用大约等于模型权重加当前 Batch 的潜空间张量加 VAE 解码开销。以 SD 1.5 为例，模型权重约 2G，512x512 的潜空间张量约 0.5G，VAE 解码约 1G，整体约 4G 左右。如果开着 ControlNet 或多 LoRA，再额外加 1 到 2G。8G 显存能跑，但 12G 会更从容。

5.3 产物管理：输出路径、对象存储与自动清理

图片生成之后，如果不做管理，过一段时间文件就会铺满磁盘。我部署时把输出目录单独挂载到宿主机，并使用按日期分层的目录结构。在节点配置里可以设置输出路径模板，例如：

${OUTPUT_DIR}/${yyyy-MM-dd}/${workflow_name}/${node_id}_${timestamp}.png

这种命名方式在做批量回溯时非常方便，一看路径就知道是哪天、哪个工作流、哪个节点产出的。

如果业务量再大一些，可以接入对象存储，比如 MinIO 或者兼容 S3 的服务。Infinite-Canvas 提供了存储后端的配置项，你把输出目录切换到 S3 之后，生成的图片可以直接通过对象存储的外链分享给业务系统，不需要从中转服务器下载后再次上传。不过前提是你有 MinIO 之类的服务，否则老老实实用磁盘挂载就够。

6. 常见问题与排查技巧实录

6.1 问题速查表

部署和日常使用中遇到的问题，大部分其实都有固定套路可查。我把最常遇到的几个整理成了一个速查表：

这部分内容真的建议截图保存，遇到问题时逐条对照，能省下大量搜索时间。

6.2 三个印象最深的排错现场

第一个是平台页面打开后一直 502。所有容器看起来都在运行，但页面就是打不开。后来看日志发现，平台主服务启动时数据库还没有完全就绪，连接超时导致后端进程一直处于异常状态。解决办法是在 Compose 配置里为依赖服务加上健康检查和depends_on条件，确保 PostgreSQL 健康之后再启动主服务。

第二个是连接 SD WebUI 失败。我检查了三遍 API 地址，明明记得后端已经启动，浏览器也能打开 SD WebUI 的页面，但 Infinite-Canvas 就是连接失败。最后发现我写的是http://localhost:5000，而 Infinite-Canvas 容器里的 localhost 并不是我的宿主机。改成http://sd-webui:5000后立即通畅。这个问题非常典型，Docker 网络机制不熟悉的话很容易踩。

第三个是任务一直排队不执行。起初我以为是并发被占满，但看 GPU 显存又没动静。检查执行日志后，发现 worker 正在等待一个前端节点回传的确认消息，而这个前端节点因为浏览器标签页被关闭而断开了。重启任务后恢复正常。从那以后，我发布长任务时会让浏览器保持标签页打开，或者通过 API 方式提交任务，不再依赖前端页面状态。

6.3 通用避坑建议

最后分享几个比较通用的建议。

第一，不要在生产环境用 latest 镜像版本，这个我已经强调过。第二，重要数据一定要做备份，至少备份 .env、数据库和模型目录。我自己就吃过亏，重装容器后才发现数据库没有持久化。第三，升级前看官方的 release notes。有一次我跳过了两个版本直接升级，结果工作流 JSON 格式不兼容，很多模板只能重新搭。第四，学习用日志命令，docker compose logs -f --tail=100 app这类操作能让你快速定位问题，而不是靠猜。第五，别在一台机器上部署太多无关服务，GitLab、监控、数据库全挤一起，最终哪个都不稳。

我个人在整个部署过程中最大的体会是：Infinite-Canvas 这类平台真正厉害的地方，不是某个具体功能多炫，而是把 AI 绘画的生产过程变成了可积累、可复用、可协作的体系。以前用 WebUI 出图，全凭感觉，图一多就乱；现在所有工作流、参数、模型、提示词都沉淀在平台里，像资产一样被管理起来。如果你正准备上手，我先劝一句：别急着研究各种高级节点，先把 Docker Compose 跑通，把一条最简链路走完整，再逐步扩展。稳定能用的系统，远比一台配置堆满却没人能维护的服务器值钱。我目前也还在持续调优这套平台，后续如果有机会，再聊聊怎么把提示词自动优化、任务回调、业务系统集成这些玩法接进来。