7 業種の実例、すべて採点済み。

これらは、当社が引き受けられること自体が珍しい案件です。モデルはお客様自身のハードウェア上で動き、第三者には何も届きません。以前はその代償が安定性でした。現在のモデルではそうではありません——ローカルの列は、ホスト型 2 モデルの優秀な方と問題ごとに互角で、しかもどちらより速く答えます。

多くの組織はこちらに該当し、その多くが自覚していません。これらのデータには所在地の制約がないため、承認済みのホスト型モデルが適切です——運用するものがなく、購入するハードウェアもなく、立ち上げも早い。必要のないインフラを売るのではなく、そう申し上げます。

多くの組織にプライベートモデルは必要ありません。そう申し上げます。ポリシーが承認済みの AI 事業者を既に許しているなら、ホスト型のフロンティアモデルが最も手間がかかりません。購入する GPU もなく、運用するものもなく、精度は上のとおりです。多くのお客様に対しては引き続きこれが既定です。ただし、これらの問題において最速ではありません。

当社がしないのは、その選択に何の帰結もないふりをすることです。その構成では、プロンプトとエージェントが読み取ったクエリ結果が、お客様と当該事業者との契約に基づいてモデル提供事業者へ送信されます。多くのワークロードではこれは完全に許容範囲で、既存のベンダー審査で既にカバーされています。そうでないものもあり、それこそ当社が扱える点で珍しいケースです。

ホスト型——当社の既定

運用するものがなく、購入するハードウェアもなく、トークン単位の課金です。ここで計測した単一構成としては最も精度が高い——ただし差はわずかです。データはモデル提供事業者に届きます。多くのお客様に、多くの場合適します。

お客様のハードウェア上

データを本当に社外へ出せない場合に。第三者には何も届かず、ハードウェアが揃えばトークン単位の費用もありません。精度はどのオープンモデルを動かすかに大きく依存します。ローカルの列は 1 台のマシン上で動く 36B の混合エキスパートモデルで、30B のコーダーモデルからこれに移したことで、ホスト型との差は完全に埋まりました。つまり教訓は「より大きなモデルなら良くなる」ではありません。どのモデルか、そしてどう調整されているかが、規模よりはるかに重要でした。

併用

配備が成熟すると通常これが正解です。制限データはローカル、それ以外は承認済み API 経由。ベンダー単位ではなくユースケース単位で決めます。

後から切り替える

構成 1 行です。一度選んだら固定されるわけではなく、当社に固定されるわけでもありません。

ひとつ、明らかな思い込みを覆す結果があります。以前の計測では、ホスト型の 2 モデルはローカルより精度が高く、そして遅かった。その遅さはモデルではなく往復回数によるものだと考えていました——これはエージェントのループで、スキーマを発見し、テーブルを説明し、クエリを実行するまでに複数回の呼び出しが必要で、モデルがホスト型ならそのたびにインターネットを越えます。ローカルモデルを入れ替えて、その読みを検証しました。現在のモデルは、ホスト型の優秀な方と問題ごとに互角で、応答は約 230 秒。相手は 391 秒と 403 秒です。コストは往復回数でした。「ホスト型は速く、ローカルは安全」という整理は元から単純すぎました——これらの問題では、いまローカルの方が速いのです。

OpenAI 20–21/21 × 3 · 374–411s DeepSeek 21/21 × 3 · 329–591s Local 20–21/21 × 4 · 215–242s

結果はモデル、ハードウェア、そして実行ごとに変わります。ここに挙げた各モデルは複数回採点しており、表の数値は単発の計測ではなくそれらの実行の範囲と中央値です——ただしすべて同じ日の計測であり、保証ではありません。同じローカルモデルが同じ問題を、ある実行では正解し次の実行では間違えるのを見ています。表が単一の結論ではなく実行回数を数えているのは、まさにそのためです。特定のモデルが重要なら、誠実な答えはウェブの表を信じるのではなく、この採点済みの問題を実際にそのモデルへ当てることです——お客様のスキーマ上で、ご一緒に行います。