把 MiniMax H3 的 2K 生成和超分放进同一个容器对外提供服务，看起来是最省钱的方案：一张卡、一个实例、一套代码。我们的压测结论是——短时可用，长跑必崩。这篇文章复盘一次完整的 OOM 故障定位过程，以及两条经过实测验证的架构解法。

压测按五层设计：L 层（单任务基线）、M 层（生成与超分混流）、F 层（突发与故障注入）、A 层（架构对比）、P 层（产品化验证），共 40 余个场景。全文成本按 RTX 5090 单卡 3.25 元/小时计算。

M2 持续混流场景的设计是：10s 生成任务持续排队（共 5 条）+ 每 90 秒插入一条超分任务（共 21 条），同一容器、同一张 GPU。

💡

混流约 1 小时后，第 5 条生成任务执行期间显存耗尽，容器被系统 OOMKill（退出码 137）。

后果比崩溃本身更严重：运行中的生成任务与超分任务全部丢失。容器会自动重启（约 30-60 秒），重启后能继续接收新任务，但丢失的任务无法恢复。整个压测期间容器累计重启 4 次，全部由同一原因导致。

用户侧的表现很有迷惑性，两边都是”静默失败”：

同一套服务，M1 时序交错测试（5 种”生成过程中插入超分”的场景）全部存活：生成起始插入、峰值负载插入、完成后插入，都没有出事。原因是两者显存分配的高峰时序恰好错开，没有形成持续的资源竞争。唯一的代价是同步冷启动场景（M1e）性能下降 30%-100%，但任务不丢。

问题出在”持续”两个字上。混流跑起来之后，显存分配碎片化累积、生成任务的峰值显存需求和超分任务的常驻需求逐渐叠加，1 小时左右达到 32GB 显存上限。这不是偶发故障，而是结构性缺陷：两个模型挤一张卡，峰值之和必然超限，只是需要时间积累到触发点。

多租户公平性测试（M3）提供了另一个视角：三个租户并发时，超分延迟几乎不受影响（25s，与独占运行一致），瓶颈集中在生成队列。也就是说超分链路本身是安全的，风险全部来自”混跑”这个部署决策。

4.1 A3 双实例分离（推荐）

两张 GPU 各部署一个容器，生成与超分各自独占资源，物理隔离。压测结果：并发满负载零干扰，容器零重启。

意外的收益是超分性能反而提升了：专属实例无需与生成模型争用显存，热态单条耗时从 25s 降到 17-18s，提升约 30%，超分容量直接翻倍（144-200 条/h，突发 5 并发全部完成，最差 91s）。成本 6.5 元/h（双卡）。

4.2 A1 网关串行（低成本备选）

维持单卡部署，在网关层把生成与超分做成串行调度：超分任务等生成任务完成后再执行。成本维持 3.25 元/h，代价是超分排队时间不可控。适合流量小、对延迟不敏感的场景。

磁盘写满：每个任务产生 3 份视频文件（原始视频 + 超分输入 + 超分输出），平均 26MB。满负荷推算单卡日写入约 31GB，节点盘容量不高于 100GB 时约 3 天写满。上线前必须配置自动清理：下载后即删，或 24 小时 TTL 自动删除。

任务丢失的静默性：OOM 重启后的容器看起来一切正常，健康检查通过、能接收新任务，唯一的问题是之前提交的任务”人间蒸发”。对外服务时，客户端必须有独立的超时和对账机制，不能依赖服务端的状态接口——因为任务表本身已经丢了。

这次压测最有价值的教训是：“能跑通”和”能上线”之间隔着一小时的持续负载测试。所有短时验证都给出了绿灯，真正的结构性问题只在长时间、真实混合流量下才暴露。如果你也在做生成 + 后处理的服务化部署，建议直接从双实例分离的架构开始，省下这次复盘的时间。

产能参考（768p/10s 口径）：单卡串行全链路（生成 + 超分）P50 约 265 秒/条，合 13.6 条/h；满载成本约 0.24 元/条。纯超分（5s 源）专属实例 0.23 元/条。