补漏四条：
- 「6B + 243K GPU hours」两个数字放一起，说明 Swift-Image 不是「快模型」而是「高效模型」。243K 小时约等于 1100 个 H100 跑 9 天——比 HunyuanImage 3.0 / Seedream 4.0 这种 12B+ / 几百万 GPU hours 的训练投入小一两个数量级，但「leading aggregate performance」还是评估开源模型里的第一。「高效训练」比「高效推理」更稀缺——Swift-Image 重新定义的是训练经济学，不只是推理 latency。
- Prompt Enhancer 是这篇的关键架构选择，原帖讲「解耦高级推理与像素级渲染」但没说这一层用的是什么模型。从描述看，应该是单独的 LLM 或 MLLM 把用户请求改写成「generator-aligned visual specifications」——这一层如果用 GPT-5 / Claude / Gemini 闭源模型，那 Swift-Image 的「开源」其实是「权重开源 + 推理接口依赖闭源」。这是开源图像模型普遍被掩盖的隐式依赖。
- Parallel Expert RL + Multi-teacher on-policy distillation 是论文里最难懂的设计。Parallel Expert RL 应该是"对不同任务族分别训专家 + 推理时路由"；Multi-teacher on-policy distillation 应该是"用一个统一的学生模型去模仿多个教师模型在不同任务上的行为"。这两步是 post-training 的核心。但 post-training 的训练数据怎么标？谁当裁判？论文没说。这条"训练数据来源"是后续复现的关键卡点。
- 「3B 压缩版几乎无损失」很反直觉。结构剪枝 + 少步蒸馏通常会带来 5-10% 的指标损失；「几乎无」意味着原作者在剪枝时做了 alignment-aware 的恢复训练，或者剪枝比例小到 6B→3B 不算激进（50%）。这条经验对其他模型作者有借鉴价值——「3B 不丢点」不是常态，是工程纪律的结果。
- Swift-Image 6B 单流 DiT + 8 步蒸馏，跟阿里巴巴 Z-Image Turbo 同构（LinkedIn 测评显示后者也是 6B 单流 + 8 步）。这意味着「统一生成-编辑 + 小模型 fast」赛道在 2026 H1 已经成型。AI 图像生成的「小模型 fast」让「千亿参数图像模型」在开源端几乎不再有竞争力——这是估值锚定的硬变化。
- Safety / Copyright 讨论是统一生成-编辑模型最敏感的领域，原帖几乎没提。一旦用户用「editing 模式」修改版权图像或生成 deepfake，模型的护栏如何？这部分空白是开源模型进企业采购目录的卡点。Swift-Image 没出现 SafetyGuard 设计——意味着它在 B2B 落地时还要补这一刀。