MOSS-Image vs Krea 3：一方は画像ごとに課金、もう一方は時間ごとに課金

この比較に登場する2つのモデルは異なる通貨で価格が設定されている。だからこそ、一見明白に見える比較——6セント対ゼロ——が誤っているのだ。K​rea 3は2026年10月15日にリリースされたホスト型の編集モデルで、公開された料金体系がある。ネイティブ2Kで1画像あたり0.06ドル、ベンダー自身の計測によればエンドツーエンドで8秒未満。M​OSS-Imageは、OpenMOSSが2026年10月16日にApache 2.0のチェックポイントM​OSS-Image-BaseおよびM​OSS-Image-SFTとしてリリースしたもので、料金は一切設定されていない。GPUを借りて時間単位で支払うことになり、その1時間で画像を1枚生成しようが400枚生成しようが関係ない。

つまり本当の問いは、どちらが安いかではない。1か月を通して自分のワークロードがどうなるかだ。なぜなら、画像1枚あたりの固定料金と時間単位の料金は、完全に自分の利用状況に左右される処理量で逆転するからだ。その分岐点を下回るなら、K​rea はコスト面で優れ、レイテンシ面では圧倒的に優れている。上回るなら、M​OSS-Image の画像1枚あたりの限界コストは電気代に近づく。ほとんど誰もその計算をしないが、まさにそれが判断のすべてだ。

二人とも箱を欲しがっていて、しかもそれをそれぞれ違う単位で欲しがっている。

まず、そもそも両者を比較可能にしている部分から始めましょう。ここは見落としがちな点です。どちらも「プロンプトを投げて祈る」タイプの生成ツールではありません。Krea 3の編集ツールには、新しい要素を配置するためのバウンディングボックスと、ターンをまたいでコンテキストを保持するマルチターン編集が備わっています。MOSS-Imageのレイアウト形式は、JSONオブジェクトをプロンプトとして受け取ります — 概要ブロックと、アイテム配列で、各要素はテキスト、キャラクター、またはオブジェクトのいずれかのラベルを持ち、さらにキャプション、バウンディングボックス、そしてテキスト要素の場合はレンダリングする文字列そのものを含みます。

• ボックスの由来 — M​OSS-Image: レイアウトプロンプト内の各アイテムにある JSON フィールドで、bbox_format: "yxyx" を bbox_coord_space: "abs_centralized" で使用します。つまり、キャンバスの中心から測定した絶対ピクセルです。K​rea 3: 新しい要素を配置するための、編集インターフェース内のバウンディングボックスコントロール。

• 出力解像度 — MOSS-Image: 256px、512px、およそ1024²にわたって学習されており、トークン予算は576 → 3,072 → 8,192と推移します。Krea 3: ネイティブ2Kで、例は2736 × 1536 pxで示されており、1Kは半額です。

• 参照画像 — M​OSS-Image：要素は参照画像として提供されるのではなく、レイアウトプロンプト内で構造的に記述されます。K​rea 3：ローンチ投稿では編集ごとに最大6つ、製品ページでは8つ — ベンダー自身の資料には2つの数値が示されており、どちらも撤回されていません。

• あなたが作っているもの — MOSS-Image：仕様に基づき、ほとんどゼロから作るコンポジション。Krea 3：すでに持っている画像への編集で、編集箇所以外の領域はそのままにする。

その最後の一行こそが、ほとんどの実際のワークロードを左右する。あなたの仕事が「この商品写真を撮って背景を変える」ことなら、M​OSS-Image は間違った道具だ。それはインプレース編集ツールではなく、そのベンダーは編集挙動を実験的と位置づけている。あなたの仕事が「特定のコピーを特定の場所に配置した400枚のユニークなポスターを作る」ことなら、K​rea 3 は間違った道具であり、長いテキストに関する自社資料も薄い。ローンチ時の例は英語で、文書化された強みは商品シーンの変更、オブジェクト除去、写真のクリーンアップだ。

スピード、片方だけが何かを公開している場合

Krea 3の目玉となる数値は、2Kで、編集1回あたりエンドツーエンドで8秒未満だ。これはベンダー公称値であり、そのベンダーは出どころについて異例なほど率直だ。計測時間は各モデルの12枚画像バッチにおけるリクエストから結果までの中央値で、キュー待ち時間も含み、2026年9月24日から10月1日の間にKrea自身のプラットフォーム上で測定された。ベンチマークに方法論が明記されていることは、ただの数字以上の価値があり、今回のベンチマークにはそれが備わっている。それでも、KreaがKreaを測っていることに変わりはない。

M​OSS-Imageには公開されたレイテンシの数値が一切存在しない。そして、それを単なる抜け落ちとして扱う前に、その理由を理解しておく価値がある。サンプリングのデフォルトは、50ステップのフローマッチングEuler、CFG 3.0、shift 5.0、そしてレイヤー22でのネガティブ分岐スキップレイヤーガイダンスだ。デフォルトのガイダンス経路では、1ステップにつき2回のtransformerフォワードが必要になる。したがってM​OSS-Imageのレイテンシは、ホスト型エンドポイントの場合のようにモデルそのものの性質ではない。それは、下に置くGPU、選ぶステップ数、そしてガイダンスを外すか蒸留を走らせるかによって決まる性質だ。コミュニティはリリースからおよそ1日以内に、INT8とINT4の量子化、4ステップのDMD LoRA、8ステップの蒸留版を公開した。これは、人々が50ステップのデフォルトをインタラクティブな作業には遅すぎると感じ、自分たちで修正したことを示している。

では、速度に関する正直な比較はこうだ。K​rea 3はK​reaに依存する数値を提示し、M​OSS-Imageはあなた次第なので数値がない。1ステップあたり2回のフォワードで50ステップのデフォルトは速くない。レンタルしたカードでの8ステップの蒸留ビルドなら速いかもしれない。これらの記述はどちらも、どのベンダーのページからも確認できず、2つ目はあなたが午後一つで確認できる。

改訂の計算——そこではもう6セントは問題にならない

ここに、判断を変える計算があります。そしてそれはKrea自身の枠組みから始まります。

1編集あたり0.06ドルで、5回パスを回して最良のものを選んでも30セント、会議は不要だ。それがK​reaの暗黙の売り込みであり、しかも優れたものだ。なぜなら、安価な再試行に代わるものはデザイナーの1時間だからだ。月10万編集を2Kで行えば6,000ドル——そしてK​reaは、ローンチ価格が定価であり、価格は上がるのではなく下がると見込んでいると明言している。そのため、この6,000ドルは下限ではなく上限となる。

MOSS-Image側の同じ算術は、レートではなく、利用率の問題だ。ライセンスはApache 2.0で収益閾値はなく、参考までに、この比較の近傍には別ベンダーの画像あたり$0.008のオープンウェイトモデルがある——しかし、オープンな道はそういうふうには機能しない。ダウンロードは約27.2 GBで、そのうち4つのシャードにまたがる約16.8 GBが凍結されたQwen3.5-9Bテキストエンコーダー、約10.2 GBが3つにまたがるトランスフォーマーだ。5Bというバッジは拡散生成器だけを指し、エンコーダーがディスク占有量の大きい方の半分だ。

それが6セントを下回るかどうかは、すでに把握している3つの数字にかかっています。あなたのGPU時間単価、最終的に決めるステップ数での1時間あたりの画像生成数、そしてそのカードが実際に稼働している時間が月のどれだけの割合かです。安定した生産ラインを回しているチームは、実効的な1画像あたりコストを低くできるので、自前でホストすべきです。火曜日の午後に40枚の画像が必要なチームは、そのためにGPUを借りるべきではありませんし、ライセンス料金を画像1枚の価格であるかのように装うべきでもありません。

双方が唱え、どちらも証明していない微調整の主張

これはスペック比較ではたいてい見落とされてしまう部分であり、この2つのモデルに共通する最も興味深い点でもあります。

Kreaの主張は、Krea 3が特定の製品、人物、スタイルでファインチューニングできる最初の編集モデルであり、それによってブランドのパックショットや繰り返し登場するキャラクターがキャンペーン全体を通して同じまま保たれる、というものだ。仕組みは確認可能で、APIリファレンスには「Train a custom style (LoRA)」エンドポイントが掲載されている。そして「最初」が成り立つかどうかは、測定結果というよりこの分野に関する主張である。それはKreaの主張だ。しかし仕組みは存在し、文書化されており、被写体を固定するためのKrea側で公表された唯一の道筋である。

OpenMOSSの相当物は、商業的というより構造的なものだ。Baseは事前学習済みチェックポイントであり、意図的に蒸留されないままにされている——モデルカードには、学習情報を保持し、LoRA学習を実行可能なままにしておくため、CFGのような推論パラメータに対するポストトレーニングや蒸留は一切施していないと明記されている。つまり、より良い学習基盤と引き換えに、あえて劣るデフォルトを出荷することを選んだベンダーであり、これは今回のリリース全体の中で、Baseチェックポイントが誰に向けたものかを示す最も明確なシグナルである。

どちらの主張も同じ買い手を指している。すなわち、ドリフトしてはならない反復的な被写体を持つ誰かだ。どちらのベンダーもドリフトの測定値を公開しておらず、コミュニティはM​OSS-Imageを中心に構築を進めている——ComfyUIのパッケージング、各種量子化、蒸留済みLoRA——がおよそ1日以内に登場した。これは、ベンダーがトレーニング結果を一切公開していないにもかかわらず、トレーニング経路が実在することを示している。

• LoRA がどこに存在するか — K​rea 3：K​rea のプラットフォーム上のホスト型エンドポイントであり、K​rea のインフラ上で K​rea のモデルに対して学習されている。M​OSS-Image：自分の重み、自分の学習実行、自分の GPU、しかもベンダーが意図的に学習可能な状態のまま残したチェックポイント付き。

• それがあなたに何の代償をもたらすか — Krea 3: 学習の会話はライセンスの会話。MOSS-Image: 学習の会話はあなたの電気代と、誰かの一週間。

• 見返りに得られるもの — K​rea 3：呼び出せるスタイル、ただしそれは他人の稼働時間の上で。M​OSS-Image：自分が所有するチェックポイント、ベンダーが去っても動き続けるもの。

Access、そしてルーターが2ツールのパイプラインのどこに位置づけられるか

Krea 3はクローズドです。Kreaは以前にもオープンウェイトを公開しています—Krea 2 RAWとTurboはHubで公開されています—しかしKrea 3はその中に含まれておらず、KreaのFAQでは、セルフホスティングはエンタープライズプランに分類され、自社のGPU上で、ライセンス条件とハードウェアサイジングについて協議することになるとされています。つまり、判断が必要です。MOSS-Imageはダウンロードであり、そのダウンロードが製品のすべてです。

どちらもOrcaRouterのカタログには載っていません — 当社は200以上のモデルを提供していますが、この2つのどちらもその中には含まれていません — そのため、どちらもソースに直接当たることになります。K​rea 3の場合はK​rea自身のAPIと複数のサードパーティプラットフォーム、M​OSS-Imageの場合はリポジトリとご自身のハードウェアです。

このようなパイプラインでルーターが役立つのは、どちらのモデルでもない部分です。要素をフレームに配置することは通常、ベース画像用のホスト型ジェネレーター、アップスケーリング用の別個のモデル、そしてキャプション生成や判定のパスも必要とするジョブの一ステップにすぎません。そして自動フェイルオーバーを備えた数百のモデルにまたがる単一のエンドポイントと、0%のマークアップでそのまま渡されるプロバイダーの定価が、モデルの作業ではなく統合作業を取り除いてくれるのです。ルーティングDSLが重要であるのも同じ理由です。ベース画像のステップと編集のステップが2つの異なるモデルであるなら、リクエストごとにそれぞれを1つの設定で固定する方が、2つのベンダーSDKを抱え込むよりも優れています。それは配管（プラミング）であり、MOSS-Image自身のアーキテクチャは、モデルに対して配管がどれだけの価値を持つかを思い起こさせます——ベンダー最強のエンドツーエンドのレイアウト結果は、プロンプト指定の半分が完全にサードパーティのモデル上で動作するパイプラインによって生み出されたのですから。

どちらか、そしてそれを決める分岐点

既存画像の編集が成果物であり、チームが自らのレイテンシを分単位で測定しており、ボリュームの変動が大きくレンタルGPUが月の大半アイドル状態になるなら、K​rea 3を選べ。6セントで8秒未満のラウンドトリップ、文書化された精度の説明、ベンダー自身のインフラ上のLoRAエンドポイントは、その用途にとって一貫した製品であり、ローンチ価格が定価として提示されているという事実は、経済性が悪化しにくいことを意味する。以下の点を承知の上で導入しよう。それに付随するあらゆる性能数値はK​rea自身によるものであり、参照カウントは2通りに文書化されており、いかなる種類の独立したスコアも持たない——これがリーダーボードに存在しないことの説明のすべてである。なぜなら、この記事の調査が収集された前日にリリースされたからだ。

仕様から安定したボリュームで合成画像を生成していて、JSONプロンプトのバウンディングボックスのほうが誰かのUI上のボックスよりパイプラインに合い、あるいはチェックポイントを所有することが好みではなく要件だというなら、M​OSS-Imageを選ぼう。収益しきい値のないApache 2.0なら法務レビューは短く済み、Baseチェックポイントは意図的に学習可能な設計で、レイアウトスキーマは本物の仕様だ。ただし、レイテンシは自分次第であること、ダウンロードの大半はエンコーダであること、コミュニティによる量子化が存在するのは50ステップのデフォルトが遅いからであること、そしてベンダーのベンチマークはどちらも誰にも再現されていないことを承知のうえで臨もう。

損益分岐点は謎ではありません。月々のGPUコストを月あたりの生成画像数で割り、その結果を6セントと比較してください。1時間あたりの生成画像数を自信をもって見積もれないなら、その不確かさこそが答えです。K​reaを1か月間レンタルし、実際に想定している生成量を生成し、オープンな経路を構築する価値があるかどうかは請求書に教えてもらいましょう。それは、それを知るためにカードを1か月レンタルするより安上がりな実験です。

このようなリリースの背景にある、文書化されたAI障害やエージェントのインシデントは、OrcaRouter AI Incident Archiveに収集されており、各エントリには独自の情報源、重大度、信頼度グレード、異議申し立てフラグが付いています。