Together AI、金融企業のコーディングエージェント向けGLM-5.2運用事例を公開
基本情報
| 項目 | 内容 |
|---|---|
| 公開元 | Together AI |
| 公開日 | 2026-09-18 |
| 出典の種類 | 公開元の一次情報(公式ブログの一次情報) |
収集・肉付けの時点で当サイトのコードが確定させた値です。日付はJST。
概要
Together AIは、グローバルな金融企業が社内のコーディングエージェント向け推論基盤として、Mixture-of-Experts（MoE）モデル「GLM-5.2」を専用推論基盤「Dedicated Model Inference（DMI）」上で稼働させた事例を公表しました。多数のエンジニアが利用することで発生する業務時間帯特有の急激なバースト負荷に対し、NVIDIA B200 GPUを56基用いたマルチレプリカ構成（256K文脈長）などを採用して並行性を確保し、セルフサービス型の運用とリアルタイムな構成変更によってキューイング遅延に対処した構成と運用実績が示されています。
主張と根拠
発表資料の中心的な主張は、長文脈を扱うコーディングエージェントの推論運用においては、単純なトークンスループット（TPS）の最大化よりも、急激なトラフィック集中に耐えうる並行性（concurrency）の確保と、プリフィル（prefill）処理の滞留を防ぐルーティング制御が重要であるという点です。
資料では、対象となった金融企業におけるコーディングアシスタントのトラフィック特性として、以下の測定値が提示されています。
- 入力シーケンス長（ISL）：
- p50: 約81,000トークン – p90: 約163,000トークン – p95: 約178,000トークン
- リクエスト頻度（RPS）：
- p50: 3 RPS – p90: 6 RPS – p95: 7 RPS
このワークロードは、エンジニアの勤務時間中にトラフィックが集中し、リクエスト数自体は比較的低頻度（低TPS）でありながら、1リクエストあたりの入力プロンプトが巨大で並行性が急増する「ピーク負荷型」の特性を持ちます。従来の静的なキャパシティ計画では、複数チームが同時にエージェント利用を増やした際のバースト予測が困難であり、事前割り当てされた容量に対してプリフィル処理能力やKVキャッシュの空きが枯渇し、複数分にわたるリクエストの滞留（キューイング）が発生していました。
発表者の測定および運用記録によると、GLM-5.2の運用過程において、レプリカ数を減らして1レプリカあたりのチップ数を増やす形へエンドポイント構成を変更した際、数日後にプリフィル容量が100%近くに達する障害が発生しました。この際、リクエストのキュー滞留時間は1〜3分に達し、デコードスループットは約5 tokens per second（tokens/sec）まで崩壊しました。
メトリクスAPIを通じた調査では、合計192秒を要した1つの低速リクエストの処理内訳を追跡した結果が示されています。このリクエスト自体は250,000トークンのプロンプト長でしたが、処理時間の大部分は計算性能不足（Compute-bound）によるものではなく、他リクエストに起因する230万トークン（2.3Mトークン）の保留中プリフィルバックログの後方でキュー待ちしていたことが判明しました。
この問題に対し、再デプロイを行わずにライブ設定変更を実施した結果が報告されています。具体的には、DMIのデフォルト設定であるハッシュベースのキャッシュルーティングポリシーから、調整済みの「キャッシュセッション認識ルーティングポリシー（cache-session-aware routing policy）」へ変更し、さらにワーカーあたりの最大インフライト閾値（max-inflight-per-worker threshold）を拡張することで、ダウンタイムなしの同日中に復旧を完了させました。
また、ハードウェア構成の選定に関しても根拠が示されています。初期検証段階ではGLM 5.1を用い、8〜16基のB200 GPUで並行性テストを実施して基準を満たしたため、本番環境へ移行しました。その後、GLM-5.2への移行に伴い、256K文脈長で56基のB200 GPU（4基のB200×14レプリカ）を用いる構成が配備されました。評価の過程では1M（100万）文脈長への拡張も検討されましたが、文脈長を1Mへ倍増させるとピーク負荷時に必要な並行性のヘッドルームが削られるというトレードオフが確認されたため、同社は256Kおよび512Kの設定を維持する選択を行っています。
前提条件
本事例で示された構成および検証結果が成り立つ条件は、資料に基づくと以下の通りです。
- 対象モデル：GLM-5.2（Mixture-of-Experts構成のモデル。先行検証段階ではGLM 5.1を使用）
- 対象ハードウェア：
- 本番運用環境：NVIDIA B200 GPU 計56基（1レプリカあたり4基のB200 × 14レプリカ構成） – 初期検証環境：8〜16基のB200 GPU
- 稼働基盤・ソフトウェア：
- Together AI Dedicated Model Inference（DMI） – API、UI、CLIを通じたエンドポイントライフサイクル制御（作成、サイジング、スケーリングポリシー変更）およびメトリクスAPI
- 設定パラメータ・構成：
- 文脈長（Context Length）：256K（一部評価において512Kも検討、1M文脈長は並行性の制約から不採用） – ルーティング設定：調整済みのキャッシュセッション認識ルーティングポリシー（cache-session-aware routing policy、初期状態はハッシュベースのcache-aware-by-hash） – 並行処理設定：拡張されたワーカーあたりの最大インフライト閾値（max-inflight-per-worker threshold）
- 対象ワークロードのトラフィック特性：
- 入力シーケンス長（ISL）：p50が約81Kトークン、p90が約163Kトークン、p95が約178Kトークン – リクエスト頻度（RPS）：p50が3、p90が6、p95が7 – トラフィック傾向：エンジニアの業務時間帯に集中する急峻なバースト特性、低TPSかつ高同時実行性
手元で再現できる範囲
本資料で示されている運用構成を個人のPCや一般的な小規模オンプレミス環境でそのまま再現することはできません。
- 再現に必要な手順や推論コード、設定スクリプトそのものは公開されていません。本資料はTogether AIが提供する商用専用推論基盤「Dedicated Model Inference（DMI）」上での事例報告であり、推論エンジンの内部実装やクラスタのオーケストレーション詳細コードは含まれていません。
- 使用されているハードウェアがデータセンター向けのNVIDIA B200 GPUを最大56基使用する極めて大規模なインフラに限定されています。
- 読者が手元で参照できる要素は、長文脈（256Kトークン以上）を扱うコーディングエージェントにおいて、スループットよりも並行性とKVキャッシュの管理がボトルネックになりやすいという設計上の知見や、文脈長を過大に引き上げると並行実行能力が低下するというトレードオフの挙動に関する記述に限られます。
資料が触れていないこと
本事例を客観的に評価する上で必要となる以下の情報については、資料中に記載がありません。
- GLM-5.2の具体的な総パラメータ数、アクティブパラメータ数、および適用された重み量子化（FP8、FP4、INT4等）の有無や形式
- クライアント企業となったグローバル金融企業の具体的な企業名や展開地域
- B200ノード間のインターコネクト仕様（NVLinkやネットワーク帯域など）や、具体的なホストマシンの仕様
- DMIプラットフォームの利用にかかったインフラ費用、および他社クラウド推論環境や自社構築環境と比較したコスト効率のデータ
- キャッシュセッション認識ルーティングポリシーの具体的なアルゴリズムや実装の詳細、および「max-inflight-per-worker」の具体的な数値設定
- 第三者による再現性検証や、他社モデル（オープンウェイトの他社MoEモデル等）との同一環境下における性能比較