MOSS-Image 对比 Krea 3：一个按图像计费，另一个按小时计费

这两个模型以不同货币定价，所以那种显而易见的比较——六美分对零——是错误的。Krea 3于 2026 年 10 月 15 日发布，是一款托管式编辑模型，并公布了费率：原生 2K 下每张图像 0.06 美元，按厂商自己的测算，端到端耗时不到八秒。MOSS-Image由 OpenMOSS 于 2026 年 10 月 16 日以 Apache 2.0 检查点MOSS-Image-Base和MOSS-Image-SFT的形式发布，则完全没有费率。你租一块 GPU，按小时付费，无论这一小时里是生成一张图像还是四百张。

所以真正的问题不是哪一个更便宜，而是你的工作负载在一个月里是什么样子，因为按每张图片的固定费率和按小时费率会在一个完全取决于你自己利用率的用量上出现交叉点。在这个交叉点之下，K​rea 在花钱上更划算，而且在延迟上要好得多。在这个交叉点之上，M​OSS-Image 每张图片的边际成本就趋近于电费。几乎没有人会算这笔账，而这就是整个决策。

他们俩都想要一个盒子，而且希望用不同的单位来表示。

先从让二者具备可比性的那部分说起，因为这一点很容易被忽略。这两者都不是那种"写完提示词就祈祷"的生成器。Krea 3 的编辑工具包含用于放置新元素的边界框，以及能在多轮之间保持上下文的多次编辑。MOSS-Image 的布局格式以 JSON 对象作为提示词——一个 summary 块，外加一个 items 数组，其中每个元素都带有 text、character 或 object 标签、一段说明文字、一个边界框，而对于文本元素还要给出待渲染的字面字符串。

• 框的来源 —— MOSS-Image：布局提示中每个条目的一个 JSON 字段，使用 bbox_format: "yxyx"，配合 bbox_coord_space: "abs_centralized"，即以画布中心为原点测量的绝对像素值。Krea 3：在其编辑界面中提供一个边界框控件，用于放置新元素。

• 输出分辨率 — MOSS-Image：在 256px、512px 以及约 1024² 分辨率下训练，token 预算从 576 → 3,072 → 8,192 递增。Krea 3：原生 2K，示例标注为 2736 × 1536 px，1K 价格减半。

• 参考图像 — MOSS-Image：相关元素在布局提示词中以结构化方式描述，而非以参考图像的形式提供。Krea 3：发布帖中每次编辑最多可使用六张，产品页面上则最多八张——厂商自家的材料给出了两个数字，且两者均未被撤回。

• 你正在构建的是——MOSS-Image：一种根据规范、基本从无到有的合成。Krea 3：对已有图像的编辑，编辑区域之外的部分保持不变。

最后一行才是决定大多数真实工作负载的关键。如果你的任务是“拿这张产品照片，换个背景”，那么 M​OSS-Image 就是错误的工具——它不是原地编辑器，其厂商将编辑行为标记为实验性。如果你的任务是“制作四百张独特的海报，并在特定位置放置特定文案”，那么 K​rea 3 就是错误的工具，而且其自身材料在长文本方面内容单薄——其发布示例是英文，其文档记载的强项是产品场景更换、物体移除和照片清理。

速度，其中只有一方发布过内容

Krea 3 的核心数字是：在 2K 下，端到端每次编辑不到八秒。这是厂商给出的数字，而该厂商对其来源罕见地坦率：这些计时是每个模型的十二张图像批次从请求到结果的中位时间，包含排队时间，于 2026 年 9 月 24 日至 10 月 1 日期间在 Krea 自家平台上测得。基准测试中写明方法论，比一个光秃秃的数字更有价值，而这个数字正是如此。这仍然是 Krea 在测 Krea。

M​OSS-Image 完全没有公开的延迟数据，而在把它当作疏漏之前，值得先理解其中的原因。默认采样设置是采用 50 步的 flow-matching Euler，CFG 3.0，shift 5.0，并在第 22 层使用负分支跳层引导。默认引导路径每步需要两次 transformer 前向。因此，M​OSS-Image 的延迟并不像托管端点那样是模型本身的属性——它取决于你为它配备的 GPU、你选择的步数，以及你是否去掉引导或运行蒸馏。社区在发布后大约一天内就推出了 INT8 和 INT4 量化、一个 4 步 DMD LoRA 和一个 8 步蒸馏变体，这说明人们发现 50 步默认设置对于交互式工作来说太慢，于是自己解决了这个问题。

所以，就速度而言，诚实的比较是：Krea 3 报出的数字取决于 Krea，而 MOSS-Image 没有数字，因为它取决于你。默认 50 步、每步两次前向，并不快。在租来的显卡上跑 8 步蒸馏版，倒有可能快。这两种说法都无法从任何厂商的页面上核实，而第二种你自己一个下午就能验证。

修订计算，正是在这里，六美分不再重要

这就是改变决策的计算，而它始于 Krea 自己的框架。

每次编辑 0.06 美元，跑五遍再挑出最好的一版，成本是 30 美分，而且不用开会。这就是 Krea 的隐含卖点，而且是个好卖点，因为廉价重试的替代方案，是占用设计师一小时。每月十万次 2K 编辑就是 6,000 美元——而 Krea 明确表示，发布价就是标价，并且它预计价格会下降而不是上涨，这让 6,000 美元成为上限，而不是下限。

在同一笔账中，MOSS-Image 这一侧不是费率问题，而是利用率问题。许可证是 Apache 2.0，没有收入门槛；作为参照，本次对比的邻近范围内有一款来自不同供应商、每张图像 0.008 美元的开放权重模型——但开放路径并非如此运作。下载大小约为 27.2 GB，其中约 16.8 GB 分布在四个分片中，是冻结的 Qwen3.5-9B 文本编码器；约 10.2 GB 分布在三个分片中，是 Transformer。5B 这个标签仅描述扩散生成器本身，而编码器占磁盘占用的更大一半。

这是否胜过六美分取决于你已知的三个数字：你的GPU小时费率、在你选定的步数下你每小时的图像数，以及显卡当月实际忙碌的时间比例。一个运行稳定生产线的团队会获得较低的每图像有效成本，应该自托管。一个周二下午需要四十张图像的团队不应该为此租用GPU，也不应该假装许可证价格就是图像价格。

双方都提出、但双方都未证明的微调主张

这正是规格对比通常会忽略的部分，也是这两款机型最有趣的共同点。

Krea 的说法是，Krea 3 是首个可以针对特定产品、某个人或某种风格进行微调的编辑模型，因此品牌的商品图或某个反复出现的角色能在整场营销活动中保持一致。这个机制是可以核查的——API 参考文档中有一个“训练自定义风格（LoRA）”端点——而“首个”是否站得住脚，是关于该领域的论断，而不是一项测量结果。这是 Krea 的说法。但这个机制确实存在，有文档记录，而且它是 Krea 这边唯一已公布的锁定某一主体的路径。

OpenMOSS 的对应做法是结构性的，而非商业性的。Base 是预训练检查点，被刻意保持未蒸馏——模型卡明确说明，没有应用任何后训练，也没有对 CFG 等推理参数进行蒸馏，以保留训练信息并让 LoRA 训练保持可行。这是一个厂商选择交付一个更差的默认版本，以换取更好的训练基底，而这是整个发布中最清晰的信号，说明 Base 检查点是面向谁的。

这两种说法指向的是同一个买家：一个拥有必须不漂移的重复主体的人。两家厂商都没有发布漂移测量结果，而社区围绕 MOSS-Image 构建起来——ComfyUI 打包、量化、蒸馏 LoRA——大约一天内就出现了，这说明训练路径是真实存在的，尽管厂商尚未发布任何训练结果。

• LoRA 存放在哪里 —— K​rea 3：K​rea 平台上的托管端点，基于 K​rea 的模型、在 K​rea 的基础设施上训练而成。M​OSS-Image：你自己的权重、你自己的训练运行、你自己的 GPU，外加一个厂商有意将其保留在可训练状态的检查点。

• 这会让你付出什么代价 —— Krea 3：训练对话是一场许可对话。MOSS-Image：训练对话是你的电费账单，还有某个人的一周。

• 它能回馈你什么——Krea 3：一个你可以调用的风格，却依托于别人的服务可用性。MOSS-Image：一个属于你自己的检查点，即便供应商跑路也照样能用。

接入，以及路由器在双工具流水线中的位置

Krea 3 已闭源。Krea 此前曾发布过开放权重——Krea 2 RAW 和 Turbo 就在 Hub 上——但 Krea 3 不在其中，而 Krea 的 FAQ 将自托管归入企业方案，需在你自己的 GPU 上运行，许可条款和硬件配置还需另行讨论。所以这需要你来决定。MOSS-Image 就是一个下载，而下载就是整个产品。

这两个都不在 OrcaRouter 的目录里——我们提供 200 多个模型，而这两者都不在其中——所以两者都意味着要直接去找源头：Krea 3 得靠 Krea 自家的 API 以及若干第三方平台；MOSS-Image 则得靠相关代码仓库和你自己的硬件。

在这样一条流水线里，路由器真正擅长的是那些不属于任何一个模型的部分。把元素放进画面通常只是一项任务中的一步，而这项任务还需要托管的底图生成器、单独的放大模型，以及一道描述生成或评判环节——而这正是一个端点覆盖数百个模型、自动故障转移、并以 0% 加价直通供应商标价发挥作用的地方：它省去的是集成的活儿，而不是模型的活儿。路由 DSL 之所以重要，原因也在于此：如果底图步骤和编辑步骤是两个不同的模型，那么在一份配置里按请求分别固定各自的模型，胜过同时维护两套厂商 SDK。这是管道活儿，而 MOSS-Image 自身的架构也提醒人们，相对于模型而言管道活儿价值几何——该厂商最强的端到端版式结果，出自一条流水线，而这条流水线的提示词规范那一半完全跑在第三方模型上。

哪一款，以及决定胜负的跨界车

如果交付成果是对现有图像的编辑，如果你的团队以分钟来衡量自身延迟，如果你的业务量波动足够大，以至于租用的 GPU 在一个月的大部分时间里都闲置，那就选择 K​rea 3。六美分、低于八秒的往返时间、有文档记录的精度说明，以及供应商自有基础设施上的 LoRA 端点，对于这项工作来说是一个自洽的产品；而且发布价被标为标价这一事实意味着其经济性不太可能变差。入手前要知道，附在它身上的每一项性能数据都来自 K​rea 自己，参考数量有两种记录方式，而且它没有任何形式的独立评分——这就是它未出现在排行榜上的全部原因，因为它是在本文研究数据收集的前一天发布的。

如果你需要按规范以稳定规模生成合成图像，如果在 JSON 提示词中使用边界框比在某个人的 UI 中使用框更适合你的流水线，或者如果拥有检查点是一项要求而不是偏好，那就选择 MOSS-Image。Apache 2.0 且没有收入门槛，使得法律审查很短，Base 检查点是刻意设计为可训练的，而布局 schema 是真正的规范。你要知道，延迟取决于你，编码器占下载量的大部分，社区量化版本之所以存在，是因为 50 步默认设置很慢，而且供应商的两个基准都没有被任何人复现。

这个临界点并不是什么谜题。用你每月的 GPU 成本除以每月的图片数量，再把结果与六美分做比较。如果你无法有把握地估算出每小时能生成多少张图片，那么这种不确定性本身就是答案：租用 K​rea 一个月，生成你实际预期的量，然后让账单来告诉你，自建开源路线是否值得。比起租一张显卡一个月来验证，这是更省钱的实验。

此类发布背后有据可查的 AI 故障与智能体事件，均收录于OrcaRouter AI 事件档案，其中每条记录都带有自己的来源、严重程度、置信度评级和争议标记。