A8R8：统一画布，让 AI 画图不再"分裂"

图 1：A8R8 的统一画布界面，左侧工具栏集成 ControlNet、蒙版、Lora 等控制项

想象这样一个场景：你在用 Stable Diffusion 生成一张赛博朋克风格的城市夜景，背景已经出来了，但人物的手部姿势总觉得别扭。你想借助 ControlNet 来精确控制手部骨骼——但在 A1111 的界面里，你需要切换标签页、调整参数、重新预览。整个过程打断了创作流，让你从"艺术家"变成了"工程师"。

A8R8（Alternate Reality）正是为解决这个问题而生。它不是一个新的 Stable Diffusion 运行时，而是一层统一的操作界面，让你同时操控 Forge、A1111 和 ComfyUI 三种主流 SD 前端，无需反复切换，体验如同在 Photoshop 里处理图层一样流畅。

---

背景：SD 生态为何如此碎片化？

Stable Diffusion 的开源生态极为活跃，但也因此分裂出了多个互相竞争的前端实现：

• AUTOMATIC1111 (A1111)：历史最悠久，插件生态最丰富，是大多数教程的默认选择
• Forge：后起之秀，优化了显存占用，ControlNet 支持更完整
• ComfyUI：节点式工作流，适合复杂的多模型组合，但学习曲线陡峭

每个前端都有自己的 WebUI，用户往往根据不同任务在不同工具间来回切换，配置不继承、操作不连贯、参数要重复设置，这是 SD 爱好者共同的痛点。

A8R8 的作者 ramyma 正是长期使用这三个前端的深度用户，他在 Discord 中提到："我没有动力重新实现一套 SD 生成逻辑——真正的价值在于提供一个真正统一的画布。" 这个务实的定位，让 A8R8 避开了与成熟前端正面竞争，转而解决更高层次的体验问题。

---

核心能力：画布即战场

统一画布（Unified Canvas）

A8R8 提供了一个整合式的画布视图，支持**图生图（img2img）、局部重绘（inpainting）、外部扩展（outpainting）**三大核心操作，所有控制项集中在一个界面里，无需跳出和刷新页面。

ControlNet 全家桶

每个 SD 前端对 ControlNet 的支持程度不一，A8R8 对三种前端做了统一抽象：

• 自动检测已安装的 ControlNet 模型
• 支持 ControlNet Mask Layers（蒙版图层），在 Forge 中可精细控制每层的蒙版
• Attention Mask Layers：配合 Forge Couple 插件实现注意力区域精确控制

增强的放大与超分

内置与 TiledVAE、Tiled Diffusion、Ultimate SD Upscale 的集成，支持低显存用户也能完成高分辨率图像的超分放大，不需要额外手动配置参数。

实时 VRAM 监控

生成过程中在界面底部实时显示显存占用，帮助用户了解当前 GPU 负载，在质量和资源消耗间做出判断。

---

技术架构：Elixir + Phoenix LiveView 的非主流选择

A8R8 是本次分析中难得一见的技术亮点——它使用 Elixir 作为核心后端语言，搭配 Phoenix LiveView 实现实时 Web UI。这在 AI 工具领域极为罕见。

为什么是 Elixir？

Elixir 运行在 Erlang 虚拟机（BEAM）上，擅长构建高并发、低延迟、容错性强的实时系统。A8R8 的核心逻辑（ExSd 模块）通过 GenServer 模式（SdServer）管理与 SD 后端的 WebSocket 连接，接收生成进度广播（broadcast_progress），并通过 Phoenix Channel 实时推送至浏览器端。整个架构天然适合"生成任务持续数秒到数分钟"的 AI 场景，不需要额外搭建消息队列。

双客户端模式

代码中存在两个平行的客户端实现：

• AutoClient：对接 A1111 / Forge 的原生 API（/txt2img、/img2img）
• ComfyClient：对接 ComfyUI 的 Prompt API（/prompt）

两者通过统一的 GenerationParams 结构体抽象，业务逻辑层（ex_sd/sd.ex）对上层隐藏了底层差异，只暴露 generate()、interrupt() 等简洁接口。

前端：TypeScript + Phoenix LiveView

前端采用 TypeScript，配合 Phoenix LiveView 的实时特性实现无刷新更新。前端构建工具使用 pnpm + esbuild（Dockerfile 中可见），生产构建产物通过 Dockerfile 多阶段构建打包进镜像。

依赖一览

组件	技术选型	用途
后端框架	Phoenix 1.7 + LiveView 0.18	实时 Web UI
数据存储	PostgreSQL + Ecto	持久化配置
HTTP 客户端	Finch	对接 SD 后端 API
ML 支持	Nx（Elixir 数值计算）	模型参数处理
图像处理	Image（Elixir）	缩略图、格式转换
异步消息	gRPC/Protobuf	内部服务通信
Web 服务器	Bandit	替代 Cowboy 的高性能选择

---

部署体验：Docker 一键，但需要一点准备

A8R8 提供了 Dockerfile + docker-compose.yml 完整方案，理论上可以一行命令启动：

docker-compose up --build

Dockerfile 采用多阶段构建：

1. Node 阶段：安装 pnpm，构建前端静态资源
2. Builder 阶段：安装 Elixir/Erlang 依赖，编译 Mix 项目
3. Runner 阶段：复制构建产物，运行精简 Debian 镜像

docker-compose 中已配置 NVIDIA GPU 直通（deploy.resources.reservations.devices），对 Docker Desktop + WSL2 用户非常友好。

但有一个关键前置条件：宿主机必须已经运行了 SD 后端服务（A1111/Forge 监听 7860 端口，或 ComfyUI 监听 8188）。docker-compose 中的 AUTO_URL 和 COMFY_URL 环境变量指向 host.docker.internal，依赖 Linux 内核的 extra_hosts 机制。在 Windows WSL2 环境下这一步通常透明，但在纯 Linux 宿主机上需要额外配置网络。

推荐部署方式：Windows 用户使用官方提供的 WSL2 一键安装脚本（one-click-installer-wsl2.bat），全自动配置 Docker + WSL2 + NVIDIA 驱动，是上手成本最低的路径。

---

局限与争议

前端依赖不可忽视

A8R8 本身不包含 SD 模型和推理引擎，必须与宿主机上独立运行的 SD 前端配合使用。这意味着用户实际上在运行两套系统（A8R8 + SD 前端），故障排查的复杂度翻倍。当生成质量不佳时，问题可能在 SD 前端、A8R8 的参数转发逻辑，或两者之间的网络通信，需要一定排查能力。

Mac/Linux 体验弱于 Windows

官方明确标注 Windows WSL2 为推荐方式，Mac 和纯 Linux 的安装脚本维护程度较低，社区反馈的问题也更多。对于非 Windows 用户，Docker 方式仍是主要选择，但 NVIDIA GPU 直通在 macOS 上完全不可用（Metal 限制）。

121 stars 背后的真实用户量

这个 star 数相对较低，说明项目处于早期社区阶段，功能迭代较快但不保证向后兼容。文档相对简陋，很多细节需要阅读源码或翻 Discord 才能找到答案。

---

总结：值得尝试，但不建议作为唯一工具

A8R8 的核心价值主张非常清晰：在多个 SD 前端之间建立统一的操作层，这对于同时使用多种后端、追求工作流效率的深度用户有实质意义。其 Elixir 技术栈在实时性和并发处理上有天然优势，架构设计也体现了作者对问题本质的思考。

但它不是银弹——需要宿主机已运行 SD 后端、依赖 Docker 环境、Mac 支持有限，这些限制决定了它更适合有技术基础的 AI 绘画爱好者或同时维护多个 SD 前端的高级用户。如果你的工作流只用一种前端且已足够高效，A8R8 的迁移成本可能大于收益。

对于想要体验 A8R8 的用户，建议从 Discord 社区获取最新信息，关注版本更新日志——毕竟 0.7.1 的版本号说明项目仍在快速迭代中。

图 2：ControlNet 多层蒙版配置界面，支持精细化的区域控制