← 最新の論文
💻 computer science

DriftSched: Adaptive QoS-Aware Scheduling under Runtime Token Drift for Multi-Tenant GPU Inference

本論文は、実行時のトークン推定誤差を修正するためにオンラインフィードバックメカニズムを利用する、マルチテナントLLM推論のためのQoSを考慮したスケジューリングフレームワークであるDriftSchedを提示し、適応的なキャリブレーションが推定精度を大幅に向上させる一方で、最短ジョブ優先(SJF)スケジューリングポリシーがエンドツーエンドおよびテイルレイテンシの最も大幅な削減をもたらすことを実証している。

原著者: Kathiravan Palaniappan

公開日 2026-06-03
📖 1 分で読めます☕ さくっと読める

原著者: Kathiravan Palaniappan

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む

あなたは、キッチン(GPU)とシェフが一人しかいない、非常に人気のあるレストランを経営していると想像してください。あなたには3種類の顧客がいます。

  1. VIP(プレミアム): 料理を早く提供してほしいと考えており、追加料金を支払う意思もあります。
  2. 常連客(スタンダード): 普通の食事を求めています。
  3. 大量注文客(バッチ): 大規模なケータリング用のトレイを注文していますが、待つことは気にしません。

問題は、キッチンが圧倒されてしまうことです。注文が積み重なり、ある人は永遠に待ち続け、別の人は素早く提供されるといった状況が発生します。シェフは次に誰のために料理を作るかを決めなければなりません。これは「スケジューリング」と呼ばれます。

コアとなる問題:ワークロードの推測

誰を次にサーブするかを決めるために、スケジューラーは各注文の作業量を把握する必要があります。

  • それはシンプルなサラダ(短いジョブ)でしょうか?
  • それとも、複雑なフルコースの食事(長いジョブ)でしょうか?

もしスケジューラーの推測が外れると、混乱が生じます。もし大量注文の大きなオーダーが小さいと勘違いして、VIPのクイックな前菜よりも先に提供してしまったら、そのVIPは待ちすぎてしまいます。これは「ワークロードの誤分類(Workload Misclassification)」と呼ばれます。

2つの推測方法

論文『DriftSched』では、注文の大きさを推測する2つの方法をテストしています。

  1. 「怠慢な推測」(空白によるプロキシ): 例えば、注文票の単語数を数えるようなものです。単語が10個ならおそらく小さく、100個なら大きいと判断します。これはホストにとって速くて簡単ですが、不正確です。短い文章でも調理は複雑かもしれませんし、長い文章でも単純かもしれません。
  2. 「専門家による推測」(トークナイザー対応): ホストが実際にレシピを読み、材料や手順が正確にいくつあるかを知っている状態です。これは正確ですが、ホストが計算するために少しの時間と労力を要します。

解決策:DriftSched

DriftSchedは、このレストランを管理するスマートなシステムです。これには「適応型キャリブレーション(Adaptive Calibration)」(またはEMA)という特別な機能があります。

このように考えてみてください。もしホストが「怠慢な推測」を使い、「テクニカルレポート」の食事に時間がかかることを一貫して過小評価していると気づいた場合、DriftSchedはその間違いから学びます。システムはこう言います。「ああ、テクニカルレポートを小さいと推測するたびに、実際には20%長く時間がかかっている。次は、予測値に20%を足しておこう」。

時間が経つにつれて、「怠慢な推測」は、実際にキッチンで何が起きたかに基づいてエラーを修正するため、まるで「専門家による推測」と同じくらい優れたものになります。

5つのスケジューリング戦略

論文では、次に誰に食事を提供するかを決めるための5つのルールをテストしました。

  1. FIFO(先入れ先出し): 標準的なチケット列のようなものです。来た順番に処理されます。公平ですが、もし大量注文客が巨大な注文を持って前にいたら、あなたは永遠に待ち続けることになります。
  2. 優先順位(Priority): VIPが常に列の最前線に割り込みます。常連客や大量注文客は待ちます。VIPにとっては素晴らしいですが、他の全員にとっては最悪です。
  3. 重み付け(Weighted): 折衷案です。VIPには50%、常連客には30%、大量注文客には20%の割合でサーブされます。全員にチャンスがありますが、VIPの方が多くもらえます。
  4. SJF(最短ジョブ優先): シェフは、誰が注文したかに関わらず、常に次に最も小さく、最も早い注文を選びます。もし大量注文客が小さなサイドディッシュを頼んでいれば、それがVIPのメインコースよりも先に作られます。
  5. エイジング優先度(Aging Priority): 優先順位付けに似ていますが、大量注文客が待ちすぎると、彼らのチケットに優先度を高める「スタンプ」が付与され、彼らが飢え死にする(待ち続ける)のを防ぎます。

彼らは何を見出したのか?

1. 正確さは重要だが、戦略の方が重要である
「専門家による推測(トークナイザー)」を使うことは「怠慢な推測(空白)」よりも優れています。しかし、次に誰を選ぶかという「スケジューリング・ポリシー(ルール)」の方が、注文の大きさをどれほど正確に推測できたかよりも、待ち時間に 훨씬 大きな影響を与えます。

2. SJFはスピードの王様である
**SJF(最短ジョブ優先)ルールが最も速かった。これは標準的な列(FIFO)と比較して、平均待ち時間を約42%**削減しました。なぜなら、すべての小さくて素早い注文を先に片付けることで、キッチンが忙しく効率的に動き続け、巨大な注文の後ろで多くの人が待たされることがなくなるからです。

3. 優先順位はVIPの王様である
もしあなたがVIPを喜ばせたいのであれば、**優先順位スケジューリング(Priority Scheduling)**がベストです。VIPの待ち時間はわずか約77秒でしたが、大量注文客の待ち時間は約427秒でした。一方で、SJFは誰が注文したかを気にしません。単にその注文がどれだけ小さいかだけを気にします。実際、SJFの下では、大量注文客の注文がたまたま小さかったために、VIPよりも早く提供されることもありました。

4. 「怠慢な推測」は修正可能である
システムの自己修正機能(EMA)はうまく機能しました。「怠慢な推測」を使用している場合、システムは予測値を調整することを学習し、エラーを約**40%**減少させました。しかし、すでに「専門家による推測(トークナイザー)」を使用している場合、自己修正はあまり役に立ちません。なぜなら、推測値はすでに正確だからです。

結論

  • 全体的なサービス速度を上げたいなら: **SJF(最短ジョブ優先)**を使用してください。キューを最も早く片付けられます。
  • 最も重要な顧客を守りたいなら: 優先順位スケジューリングを使用してください。他の人々を待たせることになっても、VIPが最初に提供されることを保証します。
  • 完璧な推測にこだわりすぎないこと: 注文にどれくらいの時間がかかるかの大まかな見積もりを使用していたとしても、選ぶスケジューリング・ルール(SJFか優先順位か)の方が、最終的な待ち時間に対してはるかに重要です。ただし、もし正確に推測できる(トークナイザーを使用する)のであれば、システムはよりスムーズに動作します。

要するに、顧客をどのように並べるかは、注文のサイズをどれほど完璧に推定できるかよりも重要であるということです。

自分の分野の論文に埋もれていませんか?

研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。

Digest を試す →