大規模なオープンウェイトルーティング：TrueFoundry AI GatewayにおけるGLM-5.1とClaude Opus 4.7の比較

20個の固定プロンプトを TrueFoundry AI Gateway を通して実行し、 4つの戦略を比較しました。すべての Claude Opus 4.7、すべての Z.AI GLM-5.1、 Haiku分類ルーター （簡単 → オープン、困難 → フロンティア）、および 80/20仮想モデル。この組み合わせでは、 分類ルーターによるルーティングは、 混合コストを 約31% 削減しました（全Opusモデルと比較して100万トークンあたり15.72ドル対22.72ドル）でありながら、当社のSonnet評価基準で より高いスコアを （4.94 vs 4.85)。All-openが最も安価でしたが（$3.00 / 1M）速度が遅く、品質もやや劣りました。要するに、すべてのリクエストに単一のモデル文字列を使用する必要はありません。ゲートウェイルーティングと安価な分類器を組み合わせることで、簡単なタスクで最先端の価格を支払うことなく、難しいタスクで最先端の品質を維持できます。

なぜ今これが重要なのか

オープンウェイトの 潮流 はもはや理論上の話ではありません。 GLM-5.1 のようなモデルは、 エージェント型コーディング 機能を備え、 20万トークン のコンテキストを持ち、最先端のAPIよりも一桁低い定価で提供されています。一方で、 Claude Opus 4.7 は、難しい推論におけるリファレンスであり続けています。

プラットフォームチームは、おなじみのトレードオフに直面しています。

• すべてを 最先端のモデル にルーティングする → 予測可能な品質が得られるが、大量処理時のユニットエコノミクスは苦しいものとなる。
• すべてをルーティングする オープンウェイト → 魅力的なコスト、品質のばらつき、難しいプロンプトでのレイテンシーの遅延。
• 構築する カスタムルーター → 柔軟性はあるものの、分類ロジック、フェイルオーバー、請求調整、プロバイダー間のキャッシュセマンティクスは自社で管理する必要があります。

TrueFoundry AI Gatewayはその中間に位置し、統合されたOpenAI互換APIを通じて1000以上のLLM、重みベースのルーティングを備えた仮想モデル、セマンティックキャッシュヘッダー、そして請求の正確性を保証する透明な料金指標を提供します。私たちは、1リクエストにつき1回のHaiku呼び出しというシンプルなEASY/HARD分類器が、現実的な20プロンプトのワークロードにおいて、コストと品質の両面で両極端なアプローチを上回ることができるかどうかを測定したいと考えました。

比較対象（技術概要）

オープンウェイトのベースライン: GLM-5.1

GLM-5.1 は、Z.AIの2026年4月フラッグシップモデルであり、TrueFoundryのGateway経由でアクセスできます。計画、ツール使用、複数ステップのコーディングループといった、長期的なエージェント作業を目的としています。

フロンティアのベースライン: Claude Opus 4.7

Opus 4.7 は、Anthropicの複雑な推論向け最上位モデルです。注: Opus 4.7は新しいトークナイザーを使用しており、同じテキストでも以前のClaudeモデルよりも多くのトークンを出力する可能性があります。コスト比較には、文字数ではなく測定されたトークン数を使用する必要があります。

アプリケーションレベルの分類ルーター

当社のルーターは、各プロンプトを1回の呼び出し（出力トークン約8個）でEASYまたはHARDに分類します。EASYはGLM-5.1へ、HARDはOpus 4.7へルーティングされます。品質評価には、LLMジャッジとしてClaude Sonnet 4.6を使用し（プロンプトごとのルーブリックに対して1～5で評価）、行いました。

Gateway仮想モデル (80/20)

また、Gateway内で重みベースのルーティング（UI上でオープンモデル80% / フロンティアモデル20%）に設定された仮想モデルもテストしました。これは、アプリケーションレベルの分類なしでプロバイダー側の負荷分散を測定するものであり、Haikuルーターとは異なる調整ポイントとなります。

ベンチマークについて

プロンプト: 20のタスク — 10はEASY（要約、JSON形式化、翻訳）、10はHARD（分散システムにおけるトレードオフ、SQLインジェクションレビュー、契約の曖昧さ、K8s OOMデバッグなど）。

戦略ごとの指標:

主張しなかったこと: ベンダーのSWE-benchスコア、本番環境のトラフィックパターン。
‍

ベンダーの価格設定状況（2026年5月）

GLM-5.1は、ルーティング、キャッシング、エンタープライズ割引を考慮しない定価ベースで、Opus 4.7よりも入力で約5倍、出力で約8倍安価です。興味深いのは、難しいプロンプトをフロンティアモデルに送信した後、その価格差がどれだけ維持されるかという点です。
‍

私たちの分析（20プロンプトでの実行）

100万トークンあたりのコスト（今回の実行でのトークン構成）

‍

ルーターによる振り分け（分類器）

Haikuルーターが送ったのは 20個のプロンプトのうち10個をGLM-5.1へ そして 20個のうち10個をOpus 4.7へ — このプロンプトセットでは50/50の分割でした（意図的に簡単なプロンプト10個＋難しいプロンプト10個）。トークン量も同様でした: 7,774トークン GLMでは、 10,072 Opusでは完了トラフィックとして。

レイテンシーのテールは重要です

オープンウェイトのみの場合、 最も遅いp50で、 (20.1秒) と、極端な p95 (約115秒) でした。これは、難しいプロンプトに対するGLMの長い完了がテールを支配したためです。Opusのみの場合、 p50で最も速く、 (9.1秒) で、p95は中程度 (約21秒) でした。分類器はp50でその中間に位置し (14.9秒)、p95は約26秒でした。

品質対コスト：分類器のスイートスポット

• ルーター vs 全Opus： 約31%低く、 統合された100万トークンあたりのコスト (15.72ドル vs 22.72ドル) で、 より高い 平均評価スコア (4.94 vs 4.85) でした。20個のプロンプトに対する総費用は、審査員とルーターのオーバーヘッドがGLMの節約分を相殺したため、実質的に同じでした (約0.28ドル)。ボリュームが増えれば、トークンあたりの差はさらに大きくなります。
• ルーター vs 全オープン： ~5.2× 100万トークンあたりのコストは高いが、 +0.19 品質ポイント。難しいプロンプトが重要である場合、最も安価なものが最善とは限りません。
• 仮想80/20: 100万トークンあたり7.19ドル 定価ブレンド見積もりでは、しかし品質は（4.50）両方のベースラインを下回りました。タスク認識のない重みベースのルーティングは、このワークロードにおける分類の代替にはなりません。実際のバックエンドの組み合わせは ゲートウェイメトリクスで検証してください。仮想モデルIDだけでなく。

これらの結果が重要な理由

1. 分類は、フロンティアコンプリーションと比較して安価です。 難しいタスクにおける1,024トークンのOpusコンプリーションと比較すると、リクエストごとのHaiku呼び出しはノイズに過ぎません。ルーターの経済性は、簡単なトラフィックがボリュームの大部分を占め、かつ誤ルーティングが稀な場合に機能します。
2. 定価は請求額とは異なります。 Gatewayは、異なるプロバイダーを経由してルーティングしたり、キャッシングを適用したり、料金を交渉したりする場合があります。当社は公開されている定価を 測定されたトークン に適用しました。FinOpsのガードレールを設定する前に、 ゲートウェイメトリクス → 生データダウンロード と照合してください。
3. レイテンシーと品質は密接に関連しています。 p95レイテンシーがSLOを侵害する場合、トークンを31%削減しても意味がありません。当社のオープンウェイトベースラインは、たった1つの誤ったルーティング決定（難しいプロンプトをGLMにのみ送信するなど）がテールレイテンシーを急増させる可能性があることを示しました。
4. 2つのルーティングパターン、2つの結果。 アプリケーションレベル 簡易/複雑 ルーティングはこのセットにおいて品質とコストを最適化しました。UIレベル 80/20仮想モデル 運用上のシンプルさのために最適化されていますが、ここでは品質が劣りました。段階的な展開には役立ちますが、タスク認識型ルーティングの完全な代替にはなりません。

プラットフォームチーム向けの実践的なヒント

1. フロンティアモデルとオープンウェイトモデルのペアから始めましょう 1つのGatewayベースURLを介して接続します。モデル文字列を変更することでモデルを切り替えられます。プロバイダーごとにSDKをフォークする必要はありません。
2. 仮想モデルの重みに複雑さを加える前に、安価な分類器（Haikuなど）を追加してください。プロンプトのゴールドサブセットで誤ルーティング率を測定しましょう。
3. プロンプトのティアリストを公開する （簡単/難しい）あなたの評価基準に合わせたもの — 当社の20プロンプトセットはテンプレートであり、実際の運用分布ではありません。
4. Gateway Metricsでコストを照合するノートブックの見積もりではなく。生の請求CSVをエクスポートし、トレースメタデータで結合してください。
5. ルーティングが安定した後でセマンティックキャッシュを導入する — 簡単で言い換えられたプロンプトに対するセマンティックキャッシュは、通常キャッシュのROIが現れる場所です（このベースライン実行では測定されていません）。

TrueFoundry AI Gatewayがこれを可能にした方法

• 統合されたOpenAI互換API — 1つのクライアント、Gatewayを指すbase_url。GLM、Opus、Haiku、Sonnetで同じコードパス。
• 仮想モデル — アプリケーションの変更なしに、重みベースの80/20ルーティング (ドキュメント).
• セマンティックキャッシュ — 類似性に基づく応答の再利用 (ドキュメント).
• 可観測性 — トークン使用量、レイテンシー、コストのヘッダー（照合用）。高スループットのプロキシシナリオにおいて、ゲートウェイ層で1 vCPUあたり約3～4ミリ秒のレイテンシーと350以上のRPS。

まとめ

GLM-5.1のようなオープンウェイトモデルは、 GLM-5.1 容易なトラフィックを獲得するために価格設定されています。 Claude Opus 4.7 難しいプロンプトでは依然としてその価値を発揮します。両者の差は十分に大きく、 モデルのマーケティングよりもルーティングが重要である.

20のプロンプトハーネスを通じた当社のテストでは、 TrueFoundry AI Gateway、 Haiku分類器ルーター が最高の総合的な結果となりました。 全Opus利用時と比較して、100万トークンあたりの統合コストを約31%削減、さらに 平均評価スコアも高く（4.94対4.85）全オープンモデルがコストの下限を維持し、全Opusモデルはp50レイテンシにおいて品質と速度の上限となりました。

‍