Fibo 2.0 Dev 对比 Fibo 2.0：你并非要在两个模型之间做选择

Fibo 2.0 Dev 和 Fibo 2.0 是同一个模型，只是顶着两个不同的职位头衔。Fibo 2.0 是 Bria 为其于 2026 年 10 月 20 日发布的 81.3 亿参数检查点系列所取的发布名称；而 Fibo 2.0 Dev 则是承载该发布版本的完整、未经蒸馏的基础模型。只有当你按照大多数人实际接触“Fibo 2.0”的方式——把它当作一个通过托管端点调用、每张图片定价 0.032 美元的产品——去对照那个你可以下载、可以权衡、可以训练的东西时，这个比较才真正成立。其中一个是你能掌控的流水线，另一个是你按量租用的计量表。这才是真正的决策所在，而罐子上的名字并不能替你做出这个决定。

房间里还有第三个对象，而把它略去不提，正是人们最终失望的原因：Fibo 2.0 Edit Turbo，这个蒸馏版四步编辑器与本次发布同名，每张图的工作量大约只有十分之一。三样东西，一个名字，以及一个描述整个发布而非任何单个检查点的排行榜分数。下文将按它们让你付出多少成本、它们能做什么，以及它们在法律上允许你交付什么来区分它们。

实际存在差异的六个维度

以下每一处差异你都可以据此采取行动。凡数据来自 Bria 而非独立运行所得，均已加以标注。

• 可下载的权重——Fibo 2.0 Dev：有，在 Hugging Face 上需申请访问，CC BY-NC 4.0，约 25.5 GB，其中包括一个 16.3 GB 的 Transformer、一个 8.9 GB 的 Qwen3-VL-4B 编码器和一个 0.34 GB 的 FLUX.2 VAE。Fibo 2.0 作为产品：无需下载任何内容。

• 采样 — Dev：50 步，使用无分类器引导，引导系数为 5.0。托管编辑路径和 Edit Turbo：4 步，引导系数为 1.0，完全不使用无分类器引导。

• 任务覆盖范围 — Dev：同一套权重即可同时支持文生图与编辑。已上线的编辑端点以及 Turbo：仅支持编辑。通过 Turbo 走文生图并不是一条更慢的路径，而是一条错误的路径。

• 微调 — Dev：唯一可训练的检查点，完整 DiT 微调与 LoRA 二者皆支持。Turbo：明确不是微调的对象。托管产品：你租用的是权重，而不是去教它们。

• 负面提示词——Dev：它们有效，因为 CFG 已开启，有可推动的杠杆。Turbo：引导强度固定为 1.0，因此负面提示词没有可作用的对象。

• 价格——托管产品：每 1,000 张图像 $32.00，即每张 $0.032，这是 Artificial Analysis 列出的数字。Local Dev：没有按图像计费的价格；你需支付的是 GPU 小时数和 25.5 GB 的下载量。

Fibo 2.0 Dev 胜出之处，而且优势悬殊

生成是第一处差距。Fibo 2.0 被宣传为一个既能绘图又能编辑的模型，而这一说法只对 Dev 成立。托管编辑端点和 Edit Turbo 都是围绕输入图像构建的；要求它们根据文字描述生成图片，等于要求它们提供蒸馏过程中已被丢弃的能力。如果你的流程从零开始，那么选择要么是 Dev，要么是另一个模型。

Control 是第二个。引导系数为 5.0 的五十步比不使用引导的四步更慢，而更慢正是可操控性的代价——能够逆着提示词施加影响、使用负面提示词，以及用步数换取保真度。在编辑方面，Dev 还支持蒙版编辑、最多可使用四张上下文图像的多参考编辑，以及 Inspire 模式——该模式会借用参考图像的风格，而不会将该图像传递给渲染器。

训练是第三项，也是规模最大的一项。Dev 是每条微调路径所指向的检查点：ModelScope 的 DiffSynth-Studio 文档称，只有 Fibo-2.0-dev 可训练；而 Bria 在仓库中提供了单 GPU LoRA 训练器以及一份数据准备指南。由于生成与编辑共享权重，一个 LoRA 就能同时教会一种风格以及与之配套的编辑行为。托管产品并无类似方案，而 Turbo 从设计上就被排除在外。

可移植性是第四点。本地检查点可在 diffusers 下通过 BriaFibo2Pipeline 运行，也可在 ComfyUI 内运行；ComfyUI 的原生支持已于 10 月 21 日合并，并在 v0.43.0 中发布，包含专用的文本编码器类型和一个接收 VGL 提示词与参考图像的节点。它还能以量化形式运行——BF16、INT8 和 GGUF 重打包版本均已存在——这正是让一个 25.5 GB 的仓库能在普通硬件上可处理的原因。

已发布的 Fibo 2.0 胜在哪里

主要是延迟和运维。四步无引导编辑路径的返回耗时，只是 50 个引导步骤所需时间的一小部分；而 Bria 自己给出的托管 API 数据是模型时间低于两秒、端到端低于五秒——这是厂商报告，未经独立测量，值得把它当作上限而非承诺。当一批编辑任务必须在截止时间前清空时，这就是全部理由。

资本成本是第二点。每张图片 0.032 美元，无需 GPU，无需 25.5 GB 的下载，无需卸载调优，也无需在 FP8 与 BF16 之间做抉择。一个每月需要 500 次编辑的团队只需花费 16 美元，而且从不需要打开终端。同一个团队若为了在本地运行 Dev 而购买一张显卡，那么在生成第一张图片之前就要花上数百美元。本地 Dev 只有在用量足够大、并且 GPU 的成本已经通过其他工作摊销的情况下，才能在这笔账上胜出。

底层管线是否正确，是第三点。托管路径会处理那些乏味的部分：文本编码器、VAE、采样调度以及结构化提示扩展，都是别人的问题。本地安装则必须在每次升级时让 Qwen3-VL-4B 编码器、FLUX.2 VAE 和 44 块 DiT 保持一致——这正是 ComfyUI 和 diffusers 集成哪怕只是存在也至关重要的原因，也是 GGUF 重打包之所以重要的原因。

五十步对四步：决定大多数案件的算术

每张图片的成本，往往正是比较开始沦为含糊其辞的地方，所以要把它当作三笔单独的费用。Hosted：每张图片 0.032 美元，全包。Local Dev：50 步下的 GPU 秒数，加上电费，再加上显卡。Local Turbo：4 步下的 GPU 秒数，大约是计算量的十分之一，但仅限编辑。

成本交叉点确实存在，但比人们以为的来得更晚。如果租用一小时的 GPU 大约要一美元，而一次 50 步的百万像素渲染假设要二十秒，那么单张图像的原始算力成本约为 0.005 美元——在计入任务之间的空闲时间，以及你自己的时间并非免费这一事实之前，就已经比托管价格便宜六倍。每月 500 张图像时，相比 16 美元能省下 2.50 美元，这不足以成为商业理由。每月 50,000 张图像时，相比 1,600 美元能省下 250 美元，这就足以成为商业理由了。微调则完全逆转了这一点，因为你训练出的 LoRA 只有在你能够运行的权重上才有价值。

还有一个数字对 Dev 一侧尤其重要：diffusers 管线默认使用 30 步、guidance 5，而 Bria 针对 Dev 推荐的设置是 50。默认设置能生成图像；但它不会生成 Bria 的图像。任何搭建本地管线的人都应当有意识地决定这一点，而不是直接沿用默认值。

许可证重新界定了整个对比。

两个可下载的检查点均采用 CC BY-NC 4.0 许可——仅限非商业用途，商业部署需要与 Bria 另行签订协议，且访问需通过公司和预期用途表单进行限制。托管产品是商业途径：你购买的是使用量，而不是权重许可。

这会产生一个确实很尴尬的结果，而这正是这篇“对比”值得一写的原因。具备你想要的能力——生成、引导、微调——的那个检查点，恰恰是你若不进行协商就无法商业交付的那个。而在法律上可以直接商业交付的产品，则是无法微调、也无法从头生成的那个。如果你的用例是商业性且定制化的，你并不是在两个 Bria 产品之间做选择；你是在选择究竟要不要开启一场许可洽谈。

也值得直说：Fibo 2.0 被引用的那条排行榜成绩——在 Artificial Analysis 的 AA-Image-Editing v2.1 上得到 1,088 Elo，在开放权重编辑器中排名第一、在 5,009 次盲投中总排名第二十三——是这个发布版本的成绩，而不是 Dev 对 Turbo 的成绩。它的 ±14 区间与 Qwen-Image-2.1 的 1,081 ±13 几乎完全重叠，所以开放权重方面的领先只能算作打破平局的结果。在文生图方面，排序反转：Fibo 2.0 的 1,039 ±12 落后于 Qwen-Image-2.1 的 1,042 ±12。两个 checkpoint 都没有单独公布的分数，这意味着任何“Dev 比 Fibo 2.0 更好”的说法，都是根据 checkpoint 如何构建作出的推断，而不是测量结果。

哪一个，视情况而定

• 你需要文生图，并且希望它遵守数量、位置和属性——Dev。结构化 JSON 控制接口正是为此而构建，流水线会返回它据此渲染的说明文字。

• 你正在为某个品牌、某种风格或某个垂直领域进行微调——Dev，先使用 LoRA。完整的 DiT 训练确实存在，但在冻结编码器上使用秩受限适配器才是合理的首个实验。

• 你正在进行大批量指令编辑，且不包含自定义行为——走托管路径，或者如果图像无法离开你的网络，就在本地使用 Turbo。四个步骤、没有引导，在这里是一种特性，而不是限制。

• 你需要商业部署——开启与 Bria 的沟通，或计划租用。下载权重并不能解决许可问题。

你只是想看看这个模型到底行不行——每张图 $0.032 的托管端点，比你自己下载、配置，再加上因 FP8 加载而白白搭进去的一个晚上都要划算。先花上 $5，再决定要不要搭进去一整个周末。

文本那部分只用一个端点，你选哪一侧都行。

两条路线都共用一个没人做基准测试的依赖项：编写 VGL 的语言模型。Fibo 是在 Visual GenAI Language 描述文本上训练的，其中光照、构图、相机和物体都是可寻址字段，而输出是否有帮助取决于该 JSON 的质量。手工编写它在十来个提示词时可行，到上千个时就令人痛苦，这正是描述生成器成为系统一部分的原因。

这正是 OrcaRouter 所覆盖的部分。一个 API 即可接入 200+ 模型，0% 加价——按供应商标价原样传递，因此供应商调价当天就会反映到你的账单上——借助路由 DSL，可以把批量字幕生成任务分配给低成本模型，并将难处理的那些行升级处理；当单个字幕生成器总是把你关心的某个字段压平时，还可以使用模型融合。它也让对比变得可测试：用同一张图片分别跑两个字幕生成器，对比 JSON 差异，看看究竟哪些字段真正影响了渲染结果。Fibo 2.0 本身不在我们的目录中，因此图像侧仍由你自己决定放在哪里——文本侧才是被整合的那一侧。

简短结论：如果你在做开发，就选 Fibo 2.0 Dev；如果你在买成品，就选 Fibo 2.0 端点。名字是共用的，许可证却不是，而带训练循环的检查点才是六个月后仍然属于你的那一个。