微型扩散模型用约5.5MB权重生成图像

TinyDiffusion 128 把一个问题推到了极限：扩散模型缩到多小，还能根据文字生成有结构的图片？作者给出的结果是 1.45M 参数、5.55MB 的 FP32 权重，以及最快配置下低于 200ms 的纯 CPU 推理。不过，它生成的是 128×128 图像，评估也主要围绕程序化样本展开。

对程序员来说，这篇最有价值的部分，是作者如何拆解体积、速度与质量之间的取舍，以及哪些漂亮数字需要附带测试条件才能成立。

5.55MB 的模型，靠什么完成文生图

TinyDiffusion 128 是一个微型潜空间扩散系统。潜空间可以理解为图片的压缩表示：模型先在小尺寸数据上去噪，最后再还原成图片，减少直接处理像素的开销。

它的生成流程分三步。

首先，提示词经过 TinyTokenizer 和 TinyTextEncoder，变成一个 1×64 的上下文向量。后续生成依靠这个向量接收文字条件。原文没有提供它对长提示词、复杂关系或中文的测试，不能直接套用大型文生图模型的理解能力。

然后，模型从 1×4×16×16 的高斯噪声开始，用 Diffusion Transformer，也就是 TinyDiT，预测每一步需要去掉的噪声。DDIM 调度器把采样控制在 10 至 15 步。去噪完成后，TinyVAE 解码器将潜表示放大 8 倍，输出 128×128 RGB 图片。

减小参数规模、使用压缩潜空间、选择适合小模型的骨干网络，共同构成了这套方案。不能只看到「Transformer 替换 UNet」，就认为换个架构也能把通用模型压到这个大小。

部署方面，作者称它支持 Windows、macOS、Linux，纯 CPU 推理所需 RAM 低于 25MB。模型还能导出为单文件 .tdiff，交给零外部依赖的 C++17 运行时执行。运行时使用原始指针运算和 arena allocator，也就是预先划出内存区域、集中分配临时数据的方式。

这些设计让它具备边缘部署的探索价值，但原文没有证明浏览器或 Node 可以直接加载运行。

默认 guidance 为什么是 3.5，而不是越大越好

无分类器引导（Classifier-free guidance，CFG）会结合有文字条件和无文字条件的两次预测，用 guidance scale 调整条件的影响。

作者对五个 guidance 值做了消融实验。输入材料没有完整列出这五个值，但保留了几个关键结果：7.0 的空间方差最高，为 48.70；3.5 达到 48.05，只低约 1.3%，同时避开了 7.0 出现的饱和伪影，以及 10.0 出现的边缘裁切。

因此，默认值选成了 3.5。

单项指标最高的参数，不一定生成最好看的图片。

空间方差可以帮助观察图像变化，却不能单独代表质量。作者这里做对的一点，是把数值和可见缺陷放在一起判断。至于 3.5 是否适合其他模型、数据集和提示词，原文没有给出证据。

架构比较也采用了类似方法。作者在相同硬件上比较 TinyDiT 与卷积网络版本 TinyUNet：TinyDiT 参数少约 5.8%，每步速度快约 1.82 倍，文件也更小。

作者把更大的速度差归因于 Transformer 结构更适合 CPU 缓存行为。这个解释有合理性，不过输入材料没有展示缓存命中率等底层分析。能够确认的是这两个具体实现的测试结果，不能据此推出 Transformer 在 CPU 上普遍优于卷积网络。

「低于 200ms」和 FID 分数，分别证明了什么

速度部分最需要把口径拆开。

文章出现了两组未完全对齐的测试数据：最快配置每步 13.13ms，标题里的低于 200ms 来自这一配置；另一组单步耗时为 31.81ms，12 步完整采样耗时 763.5ms。

后一组平均每步约 63.6ms，接近 31.81ms 的两倍，与 CFG 每步需要有条件、无条件两次预测的机制相符。但作者明确承认，没有在完全一致的硬件与设置下协调这两组结果。

因此，低于 200ms 应理解为项目测到的最佳情况，不能当成任意配置的延迟承诺。

跨模型比较还多了一层限制。Stable Diffusion v1.5 的约 2,800ms 每步耗时，以及 SnapFusion、MobileDiffusion、Mini-SD 的数据，都是引用值，没有在同一台机器上重跑。TinyDiffusion 使用 12 步，SD v1.5 使用 20 步，总耗时比较还混入了步数差异。

按每步耗时计算，2,800ms 对 13.13ms 约为 213 倍，对 31.81ms 约为 88 倍。每步比较消除了步数差异，却仍没有消除硬件、实现和输出质量差异。它比「整体快 150 倍」更容易解释，仍不是严格受控的性能结论。

质量评估同样有边界。项目使用 792 张程序化生成的参考样本，得到 FID 301.64，通过了 <350 的目标阈值。

FID 用来衡量生成图片与参考图片在特征分布上的差异。特征提取器、参考集和样本数量都会影响结果，小样本还会让分数偏高。因此，这个结果适合作为检查模型有没有退化成噪声的信号，不能拿去与 ImageNet、COCO 等大规模基准上的分数直接排名。

项目提供了 1,000 张图片的图库、评估和消融报告，仓库还包含 FID、IS、Shannon entropy 评估模块，以及 27 个通过的 pytest 单元测试。这些材料提高了可检查性，但单元测试通过与图像生成质量是两件事。

我的判断

我认可作者把测量条件写出来的做法。小模型项目很容易靠体积和单次演示吸引注意，CFG 扫描、同硬件架构比较，以及主动解释两组延迟的差异，让读者有机会判断结果到底覆盖到哪里。

但这篇的结论应当收窄到：一个 1.45M 参数的潜空间扩散模型，能够在其评估范围内生成有结构的低分辨率图片，并实现很低的 CPU 开销。

原文展示的提示词主要是圆形、星形、六边形与颜色、背景的组合，参考集又由程序生成。它没有给出复杂自然场景、人物、文字渲染等任务的充分证据，也没有证明能替代通用文生图服务。

开头关于 Stable Diffusion 需要 A100 才够快的表述也偏笼统。原文没有定义「够快」的标准，不能据此判断所有部署方案。

与静态素材、SVG 或程序化绘图相比，这个项目也没有提供成本和效果对照。如果需求只是稳定画出指定颜色的几何图形，确定性绘制仍应进入候选方案。微型扩散模型是否值得引入，要看任务是否真的需要生成变化。

这里值得带走的是实验方法，速度倍数则需要连同测试条件一起阅读。

能拿来做什么

• 可以先用固定提示词、步数和种子建立复现基线。安装命令是 pip install -e ".[dev]"，交互入口是 tiny-diffusion interactive。下面这条命令把关键采样条件写全了，适合保存成实验记录：

tiny-diffusion generate \
  --prompt "a ruby red circle on a white background" \
  --steps 12 \
  --guidance 3.5 \
  --seed 42 \
  --output output/ruby_circle.png

要重点记录 --steps 12 和 --guidance 3.5，否则两次耗时变化可能只是采样配置不同。

• 如果要做批量实验，可以通过 Python API 固定参数生成图片。下面保留了原文的调用方式：

from tiny_diffusion import TinyDiffusionPipeline

pipe = TinyDiffusionPipeline.from_pretrained(checkpoint_dir="checkpoints", model_type="dit")

image = pipe(
    prompt="a vibrant magenta hexagon on a golden glow background",
    num_inference_steps=10,
    guidance_scale=3.5,
    seed=513,
)
image.save("output/magenta_hexagon.png")

要留意 checkpoint_dir="checkpoints"：示例依赖本地检查点，输入材料没有说明权重下载和准备过程；这段代码也使用了与 CLI 示例不同的步数和种子。

• 如果在做本地工具或边缘部署，可以评估 .tdiff 与 C++17 路线。原文给出的顺序是 cmake -B build、cmake --build build --config Release、./build/test_runtime、./build/tiny-diffusion-cpp。先测目标机器上的完整生成耗时和内存，再判断是否适合接入；原文没有提供 Node 绑定。

• 日常阅读 AI 项目报告时，可以照着这篇拆开检查：参数规模与文件体积是否对应，单步时间是否包含 CFG，质量指标用了什么参考集，跨模型数据是否来自同机测试。遇到缺失条件，就把它记作待验证项。