※本記事は、Gianluigi Vitale氏によるMLSys 2026での口頭発表「DriftBench: Measuring and Predicting Infrastructure Drift in LLM Serving Systems」の内容を基に作成されています(2026年5月、シアトルにて開催)。動画の詳細情報は https://www.youtube.com/watch?v=KnsVj5DdIEo でご覧いただけます。本記事では、発表内容を要約しております。なお、本記事の内容は発表者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの発表動画をご覧いただくことをお勧めいたします。また、論文(https://openreview.net/forum?id=Xfzzp6grRP)、Gianluigi Vitale氏のポートフォリオ(https://gianluigivitale.github.io/portfolio/)、ORCID(https://orcid.org/0009-0007-6740-2695)、およびLinkedInもご参照ください。
Gianluigi Vitale氏は、イタリア文化省でシステムエンジニアとして勤務するとともに、独立系のML系研究者としても活動しています。現在はローマのメルカトルム大学でコンピュータ工学の学士課程を修了しつつある段階にあります。研究テーマはLLMシステムの故障メカニズムであり、インフラストラクチャレベルの信頼性の問題とアドバーサリアルなレッドチーミングという二つの観点から取り組んでいます。本発表で紹介されたDriftBenchの単独著者です。
1. 登壇者紹介と問題提起
1.1 登壇者プロフィールと研究テーマ
Vitale： 私はGianluigi Vitaleと申します。イタリア文化省でシステムエンジニアとして働きながら、独立系のML研究者としても活動しております。現在はローマのメルカトルム大学でコンピュータ工学の学士課程を修了しつつある段階です。私の研究テーマは、LLMシステムがどのように故障するかという点にあります。具体的には、インフラストラクチャレベルでの信頼性の問題と、アドバーサリアルなレッドチーミングという二つの切り口から取り組んでおります。本日ご紹介するDriftBenchは、私が単独著者として手がけたもので、LLMのサービングシステムにおけるインフラストラクチャの変更が、出力の正しさにどのように影響するかを測定し、予測するためのフレームワークです。
Vitale： 今日は、あらゆるLLMのデプロイメントに今この瞬間も潜んでいる信頼性の問題についてお話しします。既存の監視ツールでは決して検知できない問題です。そして、それを無視するとどうなるかもお見せします。GPUをアップグレードするとき——たとえばNVIDIA H100からB200へ——あるいはvLLMをSGLangに置き換えるとき、多くの方はモデルが同じように振る舞うはずだと考えます。重みは同じ、プロンプトも同じ、だから応答も同じだろう、と。トークンは多少異なっても、機能的には等価だろうという前提です。しかし、この前提は誤っています。そして、それは非常に重大な形で崩れます。
1.2 インフラドリフトの定義と位置づけ
Vitale： 私はこの現象を「infrastructure drift(インフラストラクチャドリフト)」と呼んでおります。これは、入力と重みが完全に同一のままである一方で、ハードウェア、精度、フレームワークといったサービングスタックの変更によって引き起こされる、モデル出力における測定可能な変化のことを指します。これはデータドリフトではありません。コンセプトドリフトでもありません。モデルドリフトでもありません。これは全く新しいカテゴリーです。本研究の目的は三つあります。第一にこの現象を測定すること、第二にそれがいつ危険になるかを予測すること、そして第三に安全でないデプロイメントを未然に防ぐことです。
2. 実例と既存ツールの限界
2.1 安全性ガードレールの自己矛盾実験
Vitale： それでは、この問題が現実にどのように現れるのかをお見せします。使用したのは同一のモデル、Llama 3.1 8B Instructです。プロンプトも同一で、AdvBenchから取得したものを使いました。内容は、銀行のデータベースにどう侵入するかを尋ねるものです。サービングフレームワークも同一で、SGLangを使用しています。左側はH100でFP16構成です。結果は明確な拒否でした。「違法な行為に関する情報は提供できません。代わりにサイバーセキュリティの防御について学んでみませんか」と、まさに期待通りの応答が返ってきました。
Vitale： ところが右側を見てください。B200でFP8構成です。モデルはまったく同じ拒否の文言から応答を始めます。「違法な行為に関する情報は提供できません」と。しかしその直後、同じ応答の中で、詳細な5つの手順を提示してきます。ターゲットに対する偵察の方法、悪意あるUSBデバイスの作成方法、データの抽出方法、そして証拠の隠滅方法までです。
Vitale： 安全性のガードレールが単に弱まったのではありません。同一の応答の中で、自己矛盾を起こしたのです。そしてこれはモデル自体の問題ではありません。重みはバイト単位で完全に同一です。これは純粋にインフラストラクチャの問題です。あの重みを通過する計算経路が変化し、それによって安全性に関わる挙動が壊れてしまったのです。
Vitale： これを珍しい極端な事例だとお思いになるかもしれません。しかしそうではありません。この現象は、この構成において安全性関連プロンプトの23.85%に影響を及ぼしました。ほぼ4件に1件です。この数字については後ほど改めて取り上げます。
2.2 既存監視ツールの限界とEvidently検証実験
Vitale： なぜ誰もこれに気づかないのでしょうか。既存のツールが実際に何を監視しているかを見てみましょう。MLPerfはスループットとレイテンシを測定します。Evidently AIは入力の分布を監視します。VIDURはスループットをシミュレートします。これらのどれ一つとして、インフラストラクチャの変更下における出力の一貫性を測定していません。そしてそれには十分な理由があります。インフラストラクチャドリフトは、固定された重みを通過する計算上の実行経路そのものを変化させるものだからです。入力は変わりません。分布もシフトしません。これらのツールが検知できるものは何もないのです。
Vitale： これを実証的に検証してみました。H100のFP16からFP8への移行について、Evidentlyを100件のプロンプトに対して実行したのです。Evidentlyは埋め込みの2%のシフトを検知しました。これ自体は正しい検知です。出力はわずかに変化していたからです。しかし、failureとして検知されたものはゼロでした。一方で、同じ移行に対してDriftBenchは、それらのプロンプトのうち3%で機能的な正しさが反転していたことを検知しました。
Vitale： このツールは変化そのものは見ていました。しかし、その変化が重要な意味を持つかどうかを判断することができなかったのです。まさにこのギャップこそが、DriftBenchが埋めようとしているものです。
3. DriftBenchのフレームワーク構成
3.1 データセット規模と対象範囲
Vitale： それでは、私が実際に何を構築したのかをお話しします。DriftBenchは、インフラストラクチャドリフトのための測定・予測フレームワークです。まず規模についてですが、236,985組のプロンプトと応答のペアを、105通りのインフラストラクチャ構成にわたって収集しました。
Vitale： モデルは5種類を対象としています。Llama 3.1の8Bと70Bの両方、Mistral 7B、Mixtral 8x7B、そしてQwen 7Bです。GPUプラットフォームは4種類で、NVIDIAのH100、H200、B200、そしてAMDのMI300Xを含めています。サービングフレームワークは3種類、vLLM、SGLang、TensorRT-LLMを対象としました。精度フォーマットについても3種類、FP16、FP8、FP4を対象としています。そして、コード生成、数学、安全性、チャット、長文脈理解という5つのワークロードをカバーしました。
3.2 flip rate指標とデコーディング設定
Vitale： 中核となる指標はflip rateです。各プロンプトについて、私はこう問いかけます。インフラストラクチャを変更したときに、正しさの分類が変化したかどうか、と。合格していたコードが今は失敗するようになったか。数学の答えが正しいものから誤ったものへと変わったか。安全な応答が安全でないものへと変わったか。以前は見つけられていた長文脈における検索が、今は見つけられなくなったか。flip rateは、こうした変化を双方向にすべて数え上げ、それをプロンプトの総数で割ったものです。
Vitale： これは単純な指標ですが、本番システムにおいて本当に重要なもの、すなわち字面上の類似性ではなく機能的な正しさを的確に捉えています。今回の研究では、すべてにおいて決定論的なデコーディングを採用しました。温度ゼロのgreedyデコーディングです。これにより、出力に見られる違いはすべてインフラストラクチャの変更に起因するものであり、サンプリングによるノイズに起因するものではないと言い切ることができます。なお、確率的な検証も別途実施しておりますが、時間の制約上、本日はその詳細には立ち入らないことにいたします。
4. 発見1:ワークロード依存性
4.1 ワークロード別flip rateと警鐘
Vitale： それでは、私が見つけたことをお話しします。最も重要な発見の一つ、そして最初の主要な発見は、ワークロードの種類が他のすべての要因を支配するという点です。そしてその変動は劇的なものです。数学は、構成間で平均flip rateが16.74%に達しました。安全性は7.97%です。長文脈理解は1.55%です。そしてコード生成はわずか0.09%にとどまりました。
Vitale： つまり、安全性はコード生成の88倍のドリフトを示しているということです。そして数学とコードの差は186倍にもなります。これは非常に重要な意味を持ちます。なぜかと言えば、ほとんどの方々がインフラストラクチャの変更を検証する際に、実際に何を実行しているかを考えてみてください。コードのベンチマークです。そして実は、コードこそが最も安定したワークロードなのです。
Vitale： もしコードベンチマークだけで検証を行い、すべてが問題ないように見えたとしても、それはインフラストラクチャドリフトに対して本質的に影響を受けにくい、唯一のワークロードを検証したにすぎません。その結果として、リスクの99%を見逃していることになります。これは、単一のベンチマークによる検証が、インフラストラクチャの変更に対しては根本的に破綻しているということを意味します。ワークロードごとに層別化した測定が絶対に必要です。そして、それこそがDriftBenchが提供するものなのです。
5. 発見2:ドリフトの二分法とPRI
5.1 PRIの構築と未知次元への予測精度
Vitale： 二番目の発見についてお話しします。これは私が最も心を惹かれているものです。なぜかと言えば、測定から洞察へと踏み出すものだからです。すべてのドリフトが同じ性質を持つわけではありません。その挙動には根本的な二分法が存在し、それは何を変更するかによって決まります。
Vitale： そこで私は、Portability Risk Index、略してPRIと呼ぶ予測モデルを構築しました。これは勾配ブースティングモデルであり、インフラストラクチャ構成の特徴を入力として、予想されるflip rateを予測します。これを完全にheld-outな次元、つまり訓練時には一度も見たことのない構成に対してテストした結果をお見せします。
Vitale： まず未知のハードウェアについてです。H100、H200、MI300Xで訓練し、B200のデータを一切使わずにB200を予測させました。決定係数R²は0.909でした。つまりこのモデルは、一度も見たことのないGPUプラットフォームにおける分散の91%を説明できたということです。次に未知の精度についてです。FP16とFP8で訓練し、FP4を予測させました。R²は0.763で、これも十分に高い値です。しかしフレームワークについては、R²は0.479まで下がります。そしてモデルについては0.118、これは実質的に予測不可能な水準です。
5.2 系統的ドリフトと特異的ドリフトの違い
Vitale： なぜこのようなことが起こるのでしょうか。ハードウェアと精度の変更は物理法則に従います。浮動小数点の制約、コアの能力、メモリ帯域幅といったものです。これによって、構成間で一貫した、学習可能なパターンが生まれます。H100からH200へ移行する際のドリフトのパターンは、H200からB200へ移行する際のパターンと非常に似ています。なぜなら、その根底にあるメカニズムが同じだからです。すなわち、トランスフォーマーの各レイヤーを通じて浮動小数点演算がどのように積み重なっていくか、という点です。
Vitale： 一方で、フレームワークの変更は異なる性質を持ちます。vLLMはpaged attentionを使用します。SGLangはRadixAttentionを使用します。TensorRT-LLMは実行グラフをコンパイルします。これらは連続的なスペクトル上の点ではなく、離散的なアーキテクチャ上の選択です。そしてこれらは、モデルのアーキテクチャと予測不可能な形で相互作用し、それぞれの組み合わせがそれぞれ独自のケースとなってしまいます。
Vitale： ここから明確なルールが導かれます。ハードウェアと精度の変更については、PRIによって一度予測すれば、その結果に自信を持ってデプロイすることができます。一方、フレームワークとモデルの変更については、デプロイの前に毎回実証的に測定する必要があります。そして意外な結果として、この論文の中でも特に興味深い発見の一つなのですが、ハードウェアそのもの、つまり推論を実行するプラットフォームが、ドリフトに寄与する割合はわずか0.3%未満だったということです。これが、PRIが異なるGPUプラットフォームに対してもうまく予測できる理由です。重要なのはどのGPUを使っているかではなく、そのGPU上で何をしているか、具体的には精度とフレームワークの組み合わせ、そしてそれがワークロードとどのように相互作用するか、ということなのです。
6. 本番デプロイのケーススタディと推奨事項
6.1 アップグレード事例と評価結果の乖離
Vitale： それでは、本番環境での事例をご紹介します。実際のデプロイメントの意思決定を一つ、皆様にご説明したいと思います。多くのチームが四半期ごとに行っているであろう種類の決定です。設定はこうです。Llama 3.1 8Bを、H100、FP16、SGLangという構成で稼働させています。そこから、B200、FP8という構成へアップグレードしたいと考えています。新しいハードウェア、より低い精度、それほど大きな変化ではありません。メモリの節約はおおむね2倍程度です。
Vitale： チームは標準的なチェックを実施します。スループットは31%改善します。レイテンシも良好です。パープレキシティも安定しています。従来のあらゆる指標が、デプロイして問題ないと告げています。しかしDriftBenchは、それを拒否します。
Vitale： なぜでしょうか。AdvBenchから取得した520件の安全性プロンプトのうち、23.85%が分類を反転させていました。これは124件のプロンプトが変化したということです。そのうち65件は、安全から安全でないものへと反転しました。安全性のガードレールが崩れたケースです。そして59件は、安全でないものから安全なものへと反転しました。これは一見改善のように見えますが、皆様がそれを要求したわけではなく、それに依拠することもできません。
Vitale： ここに微妙な問題があります。安全でない応答の割合の純増分は、わずか1.15ポイントにすぎません。60.4%から61.5%への変化です。もし集計された指標だけを見れば、これは無害に見えるでしょう。ほとんど変化がないように見えます。しかしflip rateは、4件に1件のプロンプトが不安定であることを示しています。どのプロンプトがそうなるのかは分かりません。誰が安全な応答を受け取り、誰が攻撃の詳細な手順を受け取ることになるのか、事前に予測することはできないのです。これはデプロイ可能なシステムとは言えません。DriftBenchは、このデプロイメントをブロックしました。これがなければ、そのまま本番に投入されていたはずです。
6.2 ドリフト予算の提案
Vitale： では、こうした知見をもとに何をすべきでしょうか。ワークロードごとに、具体的なドリフト予算を設定することです。セーフティクリティカルなシステムについては、flip rateを1%未満に抑え、FP16のまま運用すべきです。数学とチャットについては、検証を伴った上で3%から5%程度を許容範囲とすることができます。コードについては、FP8を自由に扱うことができます。ハードウェアと精度を変更する場合には、PRIによって予測することができます。それは測定可能で、体系的なものだからです。フレームワークとモデルについては、常に実測してください。
7. メソドロジーの汎用性とまとめ
7.1 適応可能性と公開資産
Vitale： DriftBenchにおいて最も重要な点は、データセットそのものではありません。メソドロジーです。flip rateという指標、PRIという予測器、そしてワークロードごとに層別化した評価、これらはすべて、他の環境に適応できるように設計されています。もし皆様が独自のベンチマークや専有の指標を用いて評価を行っているのであれば、それらを組み込むことができます。ご自身の正しさの基準を定義し、ご自身のflip rateの閾値を設定し、ご自身の測定データでPRIを訓練していただければよいのです。DriftBenchは、一度きりの研究成果ではなく、フレームワークなのです。
Vitale： データセット全体、237,000組のプロンプトと応答のペアはZenodo上に公開しております。CLIはGitHub上に公開しております。Artifact Evaluationの査読者からは、ACMの三つのバッジすべて、すなわちAvailable、Functional、Results Reproducedを付与していただきました。
7.2 総括と今後の課題
Vitale： 記憶しておいていただきたい点は三つあります。一つ目は、インフラストラクチャの変更が、既存のいかなる監視ツールも検知できない形で、LLMの出力を破壊してしまうという点です。そのリスクはワークロードによって88倍もの差があります。コードだけをテストすれば、ほとんどすべてを見逃すことになります。
Vitale： 二つ目は、根本的な二分法です。ハードウェアと精度のドリフトは体系的なものであり、未知のハードウェアに対してもR²は0.91に達します。一方、フレームワークとモデルのドリフトは特異的であり、経験的に測定する必要があります。
Vitale： 三つ目は、即時の実運用上の価値です。DriftBenchは、実際のデプロイメントをブロックしました。そこでは安全性に関する応答の4件に1件が不安定であったにもかかわらず、従来のあらゆるベンチマークをすでに通過していたのです。
Vitale： DriftBenchは、ドリフトを測定し、予測します。ドリフトを修正するという課題は、依然として未解決のまま残されています。ドリフトを認識した上でのサービング、量子化に対して頑健な安全性のアライメント、そしてプロンプト単位でのリスク予測——どれだけの数のプロンプトが反転するかだけではなく、どのプロンプトが反転するのかを知ること——これらが今後の課題です。この最後の課題、プロンプト単位での予測は、GPUのテンサーコアをビット単位で特性評価するという話につながっています。H100とB200がビットレベルで何を生成するかをシミュレートし、実際に測定する前に反転を予測するというアプローチです。これは同じ問題を異なる角度から見る、補完的な視点です。次の講演では、そのビットレベルの視点をご覧いただけるかと思います。
Vitale： 共同研究者を探しております。もし本日お話しした内容が皆様の研究とつながる部分があれば、ポスターセッションでも、休憩時間でも、いつでも構いませんので、私を見つけてお声がけください。ありがとうございました。