自建还是用 API：成人图像生成的真实成本
关于图像生成的「自建 vs 采购」讨论，通常从 GPU 每小时报价开始，也在那里结束。这个数字是真的，但它同时也是预算里最小的一项。自建流水线中所有昂贵的部分，都不会出现在租用账单上。
自建到底意味着什么
一条能跑的流水线是由模型、自定义节点和权重构成的图——其中每一项都有版本，都可能在你脚下变动。节点包一升级，某个参数的含义就变了。基础模型一替换，你精心调过的预设就换了气质。这些都不稀奇，这就是日常。工程成本不在于把流水线搭起来一次，而在于生态持续变动时保持输出稳定。
接着是容量问题。生成天然是突发型负载：傍晚和周末冲高，工作日上午几乎没人。按峰值配置意味着一周里大部分时间都在为闲置算力付钱；按均值配置则意味着用户恰好在最在意的时刻开始排队。GPU 自动扩容是可行的，但冷启动的 worker 必须先加载几十 GB 权重才能对外服务，所以扩容以分钟而非秒计。
永远不会写进表格的成本
- 值班。周六凌晨三点挂掉的 GPU 机器要有人爬起来，而图像生成天然就是夜间和周末的负载。
- 存储与留存。输入和输出在磁盘上不断堆积，悄悄变成一笔没人去清理的负债。
- 模型漂移。每次升级后对预设做回归测试都是实打实的工作，而且每次升级都要重做一遍。
- 队列工程。背压、重试、去重和崩溃恢复，无论 GPU 是不是你租的，都是同样的问题。
- 安全。开放推理端口的 GPU 主机是极具吸引力的攻击目标，而这类软件在设计时并没有考虑直面公网的敌意环境。
自建确实占优的场景
这并不是一边倒的结论。当流水线本身就是产品时，就该自建——你在训练或微调自己的模型、具体的计算图就是你的差异化优势，或者监管要求处理必须留在你可控的基础设施内。稳定、高量、可预测的业务量也会改变算术：一块全天满载的 GPU，单张成本低于按次计费。
真正需要警惕的是中间地带：中等业务量、需求有尖峰、团队规模小、流水线只是手段而非目的。这种组合会付出自建的全部运维成本，却几乎拿不到它的任何好处。
API 占优的场景
API 把容量问题变成一个账单条目。没有闲置算力，没有冷启动工程，没有升级加班的周末，也不用为硬件安排值班轮值。你的集成收敛为四次 HTTP 调用，而容量问题变成别人的运维负担。
它还把上线周期从数周压缩到一个下午。对于一个还在验证的功能来说，这比单位经济性更重要：一天上线、然后发现用户并不想要，其代价远低于铺完一整个 GPU 集群之后才得出同样结论。
五分钟能做完的决策
- 流水线本身是你的产品吗？是，就自建。
- 你的业务量是否足够高、稳定且可预测，能让 GPU 真正跑满？是，自建开始划算。
- 有没有人愿意承担 GPU 值班，而且他自己清楚这件事？没有，就采购。
- 功能还在验证阶段吗？先采购，等需求曲线真实起来再重新评估。
没人提起的混合方案
两者并不互斥。一种常见且合理的安排是：面向公众的不可预测流量走 API，稳定的内部基线负载由自有硬件消化。它同时消除了迁移悬崖：把集成封装在一层 HTTP 边界之后，日后在两者之间切换只是改配置，而不是重写。
常见问题
按单张算，API 一定更贵吗？
按单张算，通常是。按月算，往往不是——自建 GPU 闲置时也要付钱，而 API 不用。请比较包含闲置容量和工程投入的总成本，而不是只看单张价格。
能先用 API，以后再转自建吗？
可以，而且这是风险最低的顺序。在代码里把集成封装在单一接口之后，切换就只是改配置。
自建最大的隐性成本是什么？
在模型和节点包不断更新的同时保持输出稳定。这是持续性的工作，流水线跑起来之后也不会停。