2GB单核服务器跑AI图像流水线：近零成本实战

在AI图像生成领域，人们习惯把成本等同于API调用费。但真正让账单失控的，往往不是生成本身，而是重试、重复提交和被拒后的无谓消耗。一位开发者在1 vCPU、2GB内存、无GPU的VPS上，用一套极简脚本把图像流水线成本压到了接近零。他的方法不依赖大模型部署技巧，而是围绕“不浪费”重新设计了整条工作流。

真正烧钱的不是生成，是重试

多数人讨论AI图像成本时，默认指的是API积分消耗。但这套流水线的成本之所以接近零，核心原因在于——它不再丢弃已经完成的工作。过去，每次上传失败或被拒都意味着重新生成，也就是再次付费。现在，只要文件还在，就不会重新生成。

实现方式很朴素：一个名为 upload_tracker.py 的脚本维护一份已提交资产的台账。任何批量任务开始前先查台账，只处理缺失的部分。这看似简单，却同时解决了两个问题：在素材站重复提交同一文件是账号被封的最快路径，而重新生成已有文件则是烧钱的最快路径。两者的根源相同——系统对运行历史没有记忆。

元数据被拒：不花积分，但烧掉数天

iStock、Adobe Stock、Vecteezy、Dreamstime 等平台对CSV表头的格式要求各不相同。Adobe要求5列表头，Vecteezy要4列，Dreamstime要15列。用错格式，文件在图像被查看之前就会被系统直接弹回。

因此 make_metadata.py 只做一件事：按目标平台生成精确的表头，不引入框架，不依赖第三方库，只用标准库。指向文件夹、选择平台、生成CSV。如果有真实的标题和关键词，传入 titles.json；没有的话，文件名会被转成标题格式作为占位，但正式提交前务必替换——关键词质量直接决定一个资产是能卖出去还是石沉大海。

对成本而言，每一次被拒都意味着一天的审核周期被浪费。当生成变得便宜之后，审核时间才是真正的瓶颈。

素材站的 CSV 提交机制

iStock、Adobe Stock、Shutterstock 等平台都支持通过 CSV（逗号分隔值）批量提交，文件里每一行对应一个待上传资产，列中通常包含文件名、标题、描述、关键词、分类等字段。表头（header）不是任意命名的——平台后端按固定列名和列序解析，任何多余列、缺失列或错拼的列名都会导致整批文件在解析阶段被拒，甚至还没进入人工审核队列。Adobe Stock 的 CSV 通常只需标题、关键词等少数几列，而 Dreamstime 的列数多得多，包含模型释放、类别、编辑标记等字段。这就是为什么 make_metadata.py 必须按平台精确生成表头，而多用一个第三方库反而会引入版本兼容风险。

让2GB机器活下来的内存习惯

以下四条习惯，每一条都是撞到墙之后才学会的。

一次只跑一个进程。 在单核机器上绝不要并行展开图像任务。单核上的并行意味着两个任务各拿到一半内存，然后双双失败。串行单任务在单个任务上更慢，但在整个批次上更快——因为没有任何任务被杀死重启。

每个条目之间释放内存。 每处理完一个资产调用一次 gc.collect()。Python持有引用的时间比你预期的更长，在2GB机器上，第40个条目的残留就是第41个条目崩溃的原因。

测量峰值RSS，而不是平均值。 平均内存说明不了任何问题。resource.getrusage(RUSAGE_SELF).ru_maxrss 能告诉你这批任务真实的内存天花板。每次运行后记录这个数字，如果峰值在向极限逼近，你就能在OOM Killer动手之前知道。

重渲染步骤放到独立子进程。 在子进程中渲染，进程退出时操作系统会回收全部内存。在小机器上做进程内渲染，最终会得到一个占着1.8GB且永不归还的Python进程。

按所需分辨率渲染。 用60 dpi而非300 dpi检查预览图，内存和时间都能降一个数量级。只有最终文件才需要全分辨率渲染。

关于 RSS 与 OOM Killer

RSS（Resident Set Size）指进程当前实际占用的物理内存，而非虚拟内存。resource.getrusage(RUSAGE_SELF).ru_maxrss 返回的是该进程生命周期内的峰值 RSS，单位在 Linux 上是 KB。之所以强调峰值而非平均值，是因为 Linux 的 OOM Killer 只在内存真正耗尽的那一刻触发——一个平均占用 200MB、峰值却冲到 1.9GB 的进程，照样会被杀掉。持续记录峰值还能帮你画出内存随条目数的增长曲线，一旦发现斜率不收敛（例如每个条目稳定泄漏几 MB），就能在崩盘之前定位到具体环节。

关于 gc.collect() 为何有效

CPython 使用引用计数为主、分代标记清除为辅的回收策略。引用计数能立即释放循环外对象，但循环引用（如对象之间互相持有、闭包捕获等）只能等待分代 GC 触发，而分代 GC 的触发频率由分配次数决定，在小批量任务里往往迟迟不来。手动调用 gc.collect() 会强制立即执行一次完整回收，把那些滞留的循环引用一次性清掉。在 2GB 的机器上，每处理一个条目主动回收一次，等于把内存曲线从锯齿状堆积变成一段段平整的台阶。

为什么把重渲染放进子进程能回收内存

Python 进程一旦从操作系统申请到内存页，即便对象被回收，这些页通常也不会立刻归还给系统——它们留在解释器的内存池里备用，表现为进程 RSS 居高不下。子进程的好处在于：进程结束（exit()）时，操作系统会无条件回收该进程的全部地址空间，包括那些被 Python 内存池攥住的部分。因此，凡是占用高、生命周期短、结果可落盘的重活（如高分辨率渲染），用 multiprocessing 或 subprocess 丢到独立进程里跑，主进程的常驻内存几乎不受影响。代价是进程启动开销和序列化成本，对单核机器而言这点代价远小于被 OOM Killer 打断的风险。

打包才是从免费到可售的转折点

一个带正式封面的zip包能卖出去，一个裸文件不能。pack_product.py 用Pillow把文件打包，并渲染一张1280×720的封面和一张600×600的缩略图。Pillow是整个工具集中仅有的两个第三方包之一，另一个是 md2pdf.py 用来把Markdown转成样式化PDF的reportlab。

其余全部使用标准库。在小型服务器上这一点至关重要，因为每一个依赖都意味着内存占用和安装时间——而这两样你都没有多余的。

数字，如实说

这套流水线打包了39个成品，输出约856 MB，背后是大约19,000行流水线代码和300多页研究资料。四个脚本构成了打包层，全部运行在那台1 vCPU / 2GB / 无GPU的机器上。生成成本之所以接近零，是因为没有任何东西被浪费：没有重复提交，没有被拒的批次，没有对已有文件重新生成。

有一个值得引以为戒的错误：他曾为了“清理”删掉了研究文件夹。那些抓取日志和笔记是未来产品的原材料。research/ 目录应当永久保留——磁盘比重做工作便宜得多。

这套方案的核心思路并不复杂：把“不浪费”作为系统设计的第一原则，用台账、精确元数据和内存纪律代替算力堆砌。对于在有限资源上运行内容流水线的独立开发者来说，这是比追求更强硬件更实际的路径。