オープン対クローズドモデル：実際のプロジェクトでどう選ぶか

「オープン対クローズド」の議論は、たいてい価値観の問題であるかのように論じられます。実際のプロジェクトでは、それはトレードオフの問題です。誰がモデルを制御するか、どこで動くか、あなたの利用量でいくらかかるか、そして深夜2時に何かが壊れたとき何が起きるか。そう捉えれば、判断は扱いやすくなります。本ガイドは、どこかの部族に加わらずにその判断を下す方法を示します。

まず、大半の混乱を防ぐ明確化を一つ。「オープン」はほぼ常にオープンウェイトを意味します。モデルのパラメータをダウンロードして自分で動かせる、ということです。Open Source Initiativeが定義する厳密な意味でのオープンソースを意味することはまれです。学習データと完全な学習コードは通常公開されないからです。「クローズド」は、ウェイトがプロバイダーの手元にとどまり、ホスト型APIを通じてモデルに到達することを意味します。どちらも優秀であり得ます。どちらも自動的により安全、より安価、より高性能というわけではありません。

あなたが実際に選んでいるもの

オープンウェイトモデルを選ぶとき、あなたはモデルと、それを動かす責任を引き受けています。パラメータを手に入れ、ハードウェアを選び、稼働時間、スケーリング、セキュリティパッチ適用、アップグレード経路を所有します。クローズドAPIを選ぶとき、あなたは能力を借り、運用の負担をプロバイダーに渡します。制御と引き換えに利便性を手に入れるのです。

その単一の取引――制御対利便性――が、ほぼ他のすべての考慮の下に横たわっています。残りを読むあいだ、これを念頭に置いてください。たいていの「オープンの方が良い」「クローズドの方が良い」という主張は、実のところ、誰かが制御と利便性を、あなたのプロジェクトにとって本来そうあるべき重みとは違う重みづけをしているだけだからです。

制御とデータの所在

オープンウェイトを動かす最も強い理由は、データがどこへ行くか、そしてシステムが時とともにどう振る舞うかへの制御です。

• データの所在。 あなたの入力が法的または契約上あなたのインフラを離れられないなら、自分でホストするモデルはその問題を丸ごと取り除きます。第三者には何も送られません。規制された領域では、これが判断のすべてである場合もあります。
• バージョンの安定性。 自分でホストするモデルは、足元で変わったりしません。ホスト型モデルは、プロバイダーのスケジュールで更新、廃止予定化、または提供終了され得て、振る舞いの静かな変化が、入念に調整したプロンプトを壊し得ます。自前ホスティングは、あなたが動くと選ぶまで振る舞いを凍結します。
• オフラインおよびエアギャップ利用。 システムがインターネットアクセスなしで動かなければならないなら、オープンウェイトが事実上唯一の選択肢です。

この制御の代償は、プロバイダーがやってくれていたすべて――スケーリング、パッチ適用、監視――が、今やあなたのチームの仕事になることです。

利便性、能力、そして出荷までの速さ

クローズドAPIを選ぶ最も強い理由は、その鏡像です。

• 出荷が速い。 キーさえあれば、ホスト型エンドポイントはその瞬間から利用可能です。調達すべきGPUも、調整すべき推論サーバーも、設計すべきオートスケーリングもありません。プロトタイプや初期プロダクトには、これだけで選択を正当化できます。
• 最先端はそこに先に現れがち。 最大で最も高性能な汎用モデルは、オープンウェイトとして公開される前に――あるいは公開される代わりに――ホスト型サービスとして利用可能であることが多いのです。タスクが本当に能力の頂点を必要とするなら、クローズドの選択肢がそのバーを越える唯一のものであることもあります。
• 運用上の成熟が同梱される。 レート制限、監視、安全フィルタリング、インフラのスケーリングが、あなたのために処理されます。それらの代金はトークンあたりの価格の中で払いますが、自分で構築する必要はありません。

代償は依存です。プロバイダーの価格設定、可用性、ロードマップへの依存、そしてあなたが制御できないネットワークの往復への依存です。

コストの問題を、正直に

コスト比較は、両方向で多くのチームが自分を欺く場所です。

ホスト型APIは、固定費がほぼゼロで、利用単位あたりの明確な変動費を持ちます。それは少量でムラのある利用量では素晴らしく、安定した大量利用では苦痛になり得ます。すべての呼び出しに永遠に定価を払うからです。

自前ホスティングは曲線を逆転させます。大きく、ほぼ固定のコスト――ハードウェアまたは予約済み容量、加えてそれを動かすエンジニアリング時間――を払い、それはトラフィックが少ないと無駄になり、トラフィックが多く予測可能なら見事に償却されます。損益分岐点は実在しますが、プロジェクト固有です。

数字に関係なく成り立つ原則がいくつかあります。

• 遊休容量は自前ホスティングの隠れた税金。 時間単位で借りるGPUは、千件のリクエストを処理しようとゼロ件だろうと同じ費用がかかります。トラフィックがとがっているなら、ホスト型の価格は、見出しの呼び出し単価が高くてもしばしば勝ります。
• エンジニアリング時間は推論コストの一部。 推論スタックを健全に保つ人々の給与は、実在する費目です。チームは決まってそれを忘れ、それから「無料」のウェイトがなぜ高くついたのか不思議がります。
• 総コストは定価ではなく稼働率で決まる。 トークンあたりのAPI価格と時間あたりのGPU価格を直接比べてはいけません。両方を、あなたの想定負荷における有用なリクエストあたりのコストに換算しましょう。

ライセンスは脚注ではない

オープンウェイトモデルでは、構築する前に――後ではなく――ライセンスを読みましょう。「オープン」という言葉は幅広い条項をカバーし、中には商業的に重要な義務を伴うものもあります。

一部のオープンウェイトのリリースは、MITやApacheに精神の近い寛容なライセンスを使い、広範な商業利用を許可します。他は、一定の規模を超える利用を制限したり、特定の用途を禁じたり、派生モデルに条件を付けたりするカスタムまたはコミュニティライセンスを使います。Open Source Initiativeは、ライセンスを測る物差しが欲しいならオープンソースの正典的な定義を維持しており、Hugging Faceのようなモデルハブは各モデルの傍らにライセンスを表示するので、早めに確認できます。

根強いルール。ダウンロードできるモデルが、自動的に、あなたが意図する仕方で使う許可を得たモデルであるとは限りません。ライセンスを、能力やコストと同列のゲート要件として扱いましょう。

判断の枠組み

これらの問いを順に進みましょう。最初に明確な答えを出す問いが、しばしば事を決めます。

1. 厳格なデータ所在またはオフライン要件はあるか。 入力がインフラを離れられないなら、オープンウェイトと自前ホスティングへ強く傾けます。
2. タスクは能力の頂点を必要とするか。 はいなら、オープンウェイトモデルが実際にバーを越えるか確認します。最先端のホスト型モデルだけが越えるなら、選択肢は素早く絞られます。
3. 利用量のプロファイルは。 少量でムラがあるならホスト型が有利。多く、安定し、予測可能なら自前ホスティングが有利――それを動かすチームがいれば、です。
4. 運用能力はあるか。 推論を確実に動かすのは本物のエンジニアリングです。その能力がないか望まないなら、ホスト型APIは妥協ではありません。正しい選択です。
5. ライセンスは意図する規模での意図する利用を許可するか。 ここでの「いいえ」は、他のあらゆる好みを覆します。

能力が五つのゲートのうちの一つにすぎず、めったに決め手にならないことに注目してください。たいていの実際のプロジェクトは、生のモデル品質が絵に入ってくるずっと前に、データ規則、利用量、チームの能力で決まります。

どちらか一つに絞る必要はない

単一の二者択一という枠組み自体が罠です。成熟したシステムは頻繁に両方を混ぜます。一般的で理にかなったパターンは、簡単で大量のリクエストの大半をより安価な自前ホスト型のオープンモデルへ振り分け、本当に難しいケースだけをより高性能なホスト型APIへエスカレーションすることです。別のパターンは、ホスト型APIでプロトタイプしてプロダクトを検証し、利用量と要件が明確になったら定常状態のワークロードを自前ホストのウェイトへ移行することです。二つの選択肢は道具であって、陣営ではありません。ワークロードの各部分に合う方を使いましょう。

まとめ

オープン対クローズドは、制御と利便性のあいだの取引であって、美徳の競争ではありません。オープンウェイトは、運用とライセンスレビューを所有する代償に、データの所在、バージョンの安定性、オフライン運用を与えます。クローズドAPIは、依存と呼び出し単価の代償に、速さ、最先端の能力、管理されたインフラを与えます。五つのゲートの枠組み――所在、能力のバー、利用量のプロファイル、運用能力、ライセンス――で判断し、厳格な要件に先に語らせましょう。そして二つを混ぜられることを忘れないでください。最良のアーキテクチャは、しばしば安価な仕事を一方へ、難しい仕事をもう一方へ振り分けるのです。

出典に関する注記：ライセンス条項と特定のオープンウェイトのリリースの可用性は頻繁に変わるため、本ガイドは現行のモデルを名指しせず、根強い原則を説明しています。構築する前に、必ずモデルのページで実際のライセンスを読んでください。