用GitHub Actions免费跑本地AI生图模型自动化

编辑点评 · AI 连续创业者视角（以下内容由 AI 提炼，观点归原作者；读完可不看原文）

作者解决斯坦福食堂菜单查询痛点，需每日自动抓取菜单并生成菜品图。关键数据：单张图CPU耗时17-19分钟（A·实测），并发10台机器4小时完成百张图，10月409道新菜中406道在开餐前成功配图（A·实测）。这意味着创业者可用GitHub Actions免费算力替代付费GPU，实现低成本自动化。下一步是构建多任务矩阵分发流程，利用缓存加速模型加载。

• 用矩阵功能并发任务，4小时渲染百图
• 清理预装软件腾出14G硬盘
• Hugging Face模型入缓存提速
• 独立AI审图环节控制质量
• 定时任务避开整点错峰执行

结论先行：GitHub Actions 免费算力可替代付费 GPU，实现本地 AI 生图自动化

核心打法是利用 GitHub 公开仓库的免费矩阵（Matrix）并发功能，将 CPU 跑图任务拆分到多台无显卡的 Actions 机器上，通过缓存加速与独立 AI 审图环节，在不花费一分钱 GPU 租金的前提下，实现每日新菜品的图像自动化生成与部署。

为什么放弃付费 GPU 和云服务，选择 GitHub Actions？

直接原因是成本。作者不愿为每日几十张图支付云 GPU 租金，且实测发现 Cloudflare Workers AI 的免费模型（SDXL-Lightning 等）生成图像质量极差，无法通过视觉校验。本地笔记本跑 RealVisXL 模型效果最好，但无法 24 小时开机。GitHub Actions 提供了 4 核 CPU、16GB 内存的免费实例，虽然单台 CPU 跑一张图需 17-19 分钟，远慢于 GPU，但通过并发抵消了单点延迟。

核心数据与验证结果

关键指标在于并发效率与成功率。系统通过 Matrix 功能同时启动最多 10 台 Actions 机器，每台机器负责渲染 2 道菜，单台运行 4 小时。这种“小批量、多并发”策略确保了所有任务在 GitHub 6 小时的任务时限内完成。截至 10 月，系统处理了 409 道新出现的菜品，其中 406 道在开餐前成功生成并上线了配图，成功率超过 99%。剩余 3 道因模型绘制不准确未能在首日上架，留待次日重试。

工程实现：如何解决硬盘与内存瓶颈

Actions 免费机器仅 14GB SSD，而 RealVisXL 模型文件近 7GB，且系统预装了 .NET、Android SDK 等无用软件。实施步骤如下：

• 清理环境：安装前卸载预装软件，腾出至少 14GB 空间（原文表述清理腾出空间以容纳模型与系统文件）。
• 内存极限利用：模型加载后占用 15.3GB，接近 16GB 上限，因此每台机器严格限制一次只能生成一张图，避免内存溢出导致任务失败。
• 缓存加速：将 Hugging Face 上的模型文件存入 GitHub Actions Cache，每晚任务启动时直接拉取热缓存，避免重复下载 7GB 大文件。
• 质量校准：引入独立的 Vision AI 模型审图，通过是非题校验图像内容（如“这是一根裹着面糊的香肠吗？”），答错则重画，确保图文匹配。

合规性与风险规避

GitHub 条款禁止将 Actions 用作通用服务器或挖矿。此方案合规的关键在于：生成图像是仓库代码的直接产物，随仓库提交并发布，属于项目自身的开发与发布环节，而非对外提供 SaaS 服务。此外，需注意 Actions 定时任务存在 5 小时左右的漂移延迟，且自身推送不触发工作流，需通过跨工作流调用并明确指定 ref 来解决代码同步问题。

怎么用它赚钱

此工具适合自用降本，项目化空间有限。虽可复制该逻辑为电商卖家提供“低价自动生图服务”，但受限于 Actions 6 小时任务上限和免费额度并发数（20 台），处理海量 SKU 的时效性与稳定性不足，且极易触及 GitHub 滥用条款导致封禁。若需商业化，建议转向租赁专用 CPU 集群或自建低成本节点，而非依赖免费额度。

原文 · 博客 on Neil的自留地：阅读原文 →