允中 凹非寺より 量子位 | 公式アカウントQbitAI
GPUクラスタでは、リクエストの待機行列とリソースの遊休が同時に発生することがある。
2026 CCF全国高性能計算学術大会の期間中、是石科技は新製品TokenFleet分散スケジューリングフレームワークを発表し、最適化の重点をリクエストルーティング、データセンター間の容量協調、混成負荷の制御に置き、既存の計算能力の有効産出量を高めることを試みた。
推論サービスを一座の「国産Token最適化工場」と見立てると、GPUは生産設備、推論インスタンスは作業台、業務リクエストは一枚一枚の受注書である。TokenFleetが担うのは、受注書と生産能力をマッチさせることだ。
同じ設備でも、割り当てられるタスクや配分方法が異なれば、最終的な待ち時間や基準を満たす産出量も変わってくる。大規模サービスでは、こうした生産計画を一体的に考える必要がある。
TokenFleetはクラスタの有効産出量にフォーカス
モデルのデプロイ完了後も、クラスタは多種多様な業務に同時に対応する必要がある。
複数のモデルが計算能力を共有し、異なるテナントにはそれぞれのサービス等級要件がある。短い対話は即時の応答が必要で、長文書処理にはより多くの計算とメモリが必要、オフラインのバッチタスクには完成期限がある。サービスが複数のデータセンターに分散している場合、各所の容量を協調できるかも考慮しなければならない。
単純な振り分けでは、一部のインスタンスに長い行列ができ、他の場所の容量が十分に活用されないことがある。長時間リクエストとバッチタスクが互いに圧迫し合うと、リアルタイム対話が遅くなる。タイムアウト、キャンセル、重複計算は、資源を消耗しながら合格した成果を生まない。
TokenFleetはモデル品質・サービス要件・計算能力予算が一致した条件下で、有効Token産出量を高め、単位あたり有効産出量のコストを下げる。
TokenPilotは同一モデルプール内でインスタンスを選択し、FleetMindはデータセンター間の容量協調を担当、SLOMaxは混成負荷のアドミッション、キュー制御、容量配分を担うと、3つの核心技術がそれぞれ分担している。
リクエストを誰に振り分けるか、タスクをいつキューに入れるか、データセンターの容量をどう協調させるか、最終的にはすべて同じ指標に帰着する。すなわち、成功裏に完了しサービス要件を満たす有効Token産出量である。
△図1 TokenFleetの3つのコアスケジューリング技術総覧TokenPilotはキャッシュの収益と待ち行列のコストを一緒に計算
まずリクエストの配置先について。あるリクエストは、どのインスタンスに送るべきか？
短い一問一答と長い文書では、どちらも1回のリクエストとして数えられても、消費する計算量とメモリ量は大きく異なる可能性がある。リクエスト数だけで振り分けると、各インスタンスの実際の作業量を均等にするのは難しい。
キャッシュはこの問題に新たなトレードオフをもたらす。同じ長いプレフィックスを持つリクエストを、関連するKVキャッシュを保持しているインスタンスに送れば、以前の計算結果を再利用できる可能性があり、Prefill、つまり入力内容を処理する際の重複計算を減らせる。
しかし、キャッシュヒット率の高いインスタンスでは、待ち時間が長くなることもある。リクエストが同じ場所に集中すれば、節約した計算時間が待ち時間に消える可能性がある。
TokenPilotは配置先を選ぶ際、キャッシュ再利用の収益と待ち行列のコストを同時に見積もる。入力規模、出力予算、再利用可能なプレフィックスから作業量を推定し、さらにキュー、処理中のToken、KVキャッシュの圧力、予測遅延を総合して、候補インスタンスの選別とスコアリングを行う。出力予算は制約条件であり、実際の出力長を表すものではない。
スケジューラはこれに基づいて異なるインスタンスの予想処理コストを比較し、キャッシュ再利用で節約できる計算が追加の待ち時間を相殺できるかを判断する。
△図2 TokenPilotインテリジェント推論ルーティングフレームワーク是石科技が提供するGLM5.3のチューニングデータによれば、測定されたGPUクラスタと負荷の条件下で、予測遅延ルーティングを採用した結果、P95初回Token遅延が32.4%削減、P50初回Token遅延が71.3%削減。
△表1 TokenPilot初回Token遅延チューニング結果。データ出典：是石科技の大会講演資料。改善率は（基準値－最適化値）÷基準値で計算。遅延の低下はコストの低下を直接意味するものではない。
P50は中央値レベルを反映し、P95は末尾リクエストの待ち時間の状況を反映する。このデータは測定条件における応答改善を示すものであり、コスト対効果は依然としてスループットとリソース消費を踏まえて評価する必要がある。
FleetMindはデータセンター間でもサービス容量をきちんと算定する
視点を1つのモデルプールから複数のデータセンターへと広げると、スケジューリングには容量判断という新たな層が加わる。
空闲なGPUがあっても、必ずしもすぐにリクエストを引き受けられるとは限らない。目標モデルがデプロイされているか、バージョンが一致しているか、サービスエンドポイントが準備できているか、そしてネットワーク伝送にどれほど時間がかかるかは、いずれも分流の効果に影響する。
FleetMindが注目するのは実際に利用可能なモデルサービス容量である。TokenFleetの設計では、各データセンターのモデル可用性、リアルタイム容量とネットワーク状態を集約し、まず実行するデータセンターを選択し、その後そのデータセンターのローカル意思決定エンジンが具体的な推論インスタンスを選択する。
混雑しているデータセンターで待ち行列が生じ始めると、システムは他のデータセンターに同バージョンのモデルの準備完了エンドポイントがあるか、サービスにまだ余裕があるかを評価し、その上で地域をまたぐ実行が許可された新規リクエストを引き受けられるかどうかを判断する。
分流できるかどうかは、まず権限とデータの地域制約を満たす必要がある。分流する価値があるかどうかは、オリジン取得レイテンシ、待ち行列、計算、キャッシュ、転送コストを総合的に比較する必要がある。
容量の協調にも異なる時間スケールが存在する。短周期では新規リクエストの振り先を調整し、長周期ではモデルのレプリカと事前加熱（プレウォーム）位置を調整し、容量の予約、負荷上限の感知、自動ロールバックを組み合わせて、容量のミスマッチを減らす。
△図3 FleetMindのデータセンター間実行フレームワーク。説明：A地はビジネスの入口であり、GPU容量プールには含まれない。B地は既存クラスタ、C・D地は拡張データセンターである。
TokenPilotとSLOMaxは既存クラスタ向け、FleetMindは今後新たに追加される計算力データセンターの拡張に向けたものである。データセンター間協調の目標は、ビジネス制約を満たす分散容量にホットスポットの需要を担わせ、容量のミスマッチと重複予約を減らすことである。
SLOMaxはサービス要件に応じて生産を手配する
リクエストは同じクラスタに入るが、納期・品質の要求はそれぞれ異なる。
リアルタイム対話は最初のTokenの応答と継続生成速度を重視し、長コンテキストタスクは入力処理能力とKV容量に依存する度合いが高く、オフラインバッチタスクは完了期限とスループットを重視する。これらを同じ一組のキューに入れると、リソースの取り合いが起きやすい。
長いPrefill、KV容量の圧迫、バッチ負荷は、いずれも対話型リクエストを圧迫する可能性がある。タイムアウト、キャンセル、重複実行は、一部の計算を有効な成果物に変換できない原因にもなる。
SLOMaxは入力長、出力予算、タスク種別、テナントのサービス目標を組み合わせてワークロードを識別し、等級に応じたアドミッション、プール分けされたキューイング、容量の協調を行う。対話用容量を保障し、長短リクエストの同時実行と相互干渉を制御する必要がある。
△図4 SLOMaxの分類キューと容量フィードバックのフレームワーク。説明：効果のフィードバックは容量とアドミッションの調整に用いられ、フレームワークは実行中タスクのプリエンプション能力を前提としない。
このスケジューリングの効果を測るうえで、TokenFleetは基準達成の産出量を最適化目標とする。
Goodput、すなわち基準達成出力スループットとは、テスト期間全体の中で、正常に完了し、かつ合意されたサービス要件を満たしたリクエストが生み出した出力Token総量を、テスト時間で割ったものである。タスクのカテゴリごとに達成基準を定義し、結果を報告する必要がある。
システムは達成スループット、失敗、キャンセル、重複実行の状況をスケジューリングポリシーにフィードバックし、アドミッションと容量比率を継続的に調整する。GPUがどれほど忙しいか、総スループットがどれほど高いかも、最終的な合格した成果物と併せて見る必要がある。
是石科技が示したGLM5.3の収益試算例では、フロー制御と協調スケジューリングを採用した後、総出力スループットは約1.5%増加し、達成出力スループットは約29.4%向上した達成比率は約67%から約86%に上昇した。
△表2 SLOMaxの有効Tokenスループット収益試算例。データ出典：是石科技大会講演資料。本表は収益試算例であり、達成比率は原文の丸め値をそのまま用いており、変化は約19ポイントである。
この数値群は収益試算に属し、スケジューリングが改善しようとする産出構造を示している。実際の収益は、具体的な負荷とサービス基準に照らして検証する必要がある。
同じ規模の総産出量でも、タイムアウト、キャンセル、重複計算を減らせば、より多くの基準達成Tokenを納品できる可能性がある。SLOMaxはこれらの結果をフィードバックに組み込み、その後のリソース配分の調整に用いる。
国産Token最適化工場の効率には、スケジューリングも重要
TokenFleetは推論サービスの最適化をクラスタレベルへと推し進めた。インスタンスの性能をどう各リクエストに配分するか、複数データセンターの容量をどうサービスに参加させるかは、いずれもスケジューリングがリソースとビジネス要件を結びつけることを必要とする。
是石科技（METASTONE）は独立系サードパーティのフルスタック計算力事業者であり、特定の大手モデルベンダーに依存せず、顧客にハードウェア、ネットワーク構築、スケジューリング、最適化、運営を網羅するワンストップのフルスタック計算力デリバリーサービス。
国家級計算センターに由来する豊富な経験を有し、その計算力クラスタの運行SLAは99.95%以上に達している。現在、是石科技は20000P+を超える計算力リソースを管理下に置き、10余りの超インテリジェント計算センターを運営しており、そのうち2つは国家級スーパーコンピュータセンターである。チームメンバーはこれまでにゴードン・ベル賞を3件受賞し、超大型クラスタのフルスタック技術サービス経験を蓄積している。
国産Token最適化工場をめぐり、是石科技は自社開発・自社利用によるソフトウェア能力の継続的な磨き上げを通じて、汎用的で高頻度の推論サービスをより経済的にし、国産計算力がより多くの能力を発揮できるようにすることを目指している。
以前発表されたMeta-Infer高効率推論エンジンは、単一の推論インスタンスの実行効率向上に力を注いだ。今回のTokenFleetは重点をクラスタスケジューリングに置き、リクエスト配分、容量協調、混成負荷の治理を通じて、大規模なサービスを組織する。
より多くのビジネスがTokenを使いやすく、うまく使えるようにするには、ハードウェアが計算力を提供するだけでなく、ソフトウェアが生産能力を組織する必要もある。
TokenFleetはさらに最適化を進める方向性を、1回ごとのリクエストがどのように割り当てられるか、1つひとつの容量がどのように使われるかに据えた。
*本記事は量子位が許諾を得て掲載したものであり、見解はすべて原作者に帰属する。