> [!abstract] 概要(arXiv abstract の日本語訳) > 大規模言語モデル(LLM)の推論は、オフラインのワークロードから継続的に運用されるソフトウェアサービスへと進化してきた。しかし根本原因分析は依然として難しい。単一のリクエストが、推論エンジン、Python/C++ バックエンド、ホスト CUDA API、GPU カーネル、分散通信にまたがるためである。既存のプロファイラは生のタイムラインを提示するにとどまり、ログベースの診断はクロスレイヤーの実行セマンティクスとリクエストレベルの構造をしばしば見落とす。我々は TELLER を提示する。これは非侵入的な、トレースとログを認識する LLM 推論の根本原因分析フレームワークである。TELLER はまず、モデルバイナリを変更することなく NVTX/CUPTI トレースとサービスログを収集し、次にリクエスト単位のコールチェーン木を再構成してログ行を対応する実行ステップに整列させる。我々は、親子構造・時間的順序・通信関係を保持する依存関係考慮型の causal-context slice を導入し、そのようなスライスをパレント・深さ・持続時間の属性を持つコンパクトな構造トークン列へ圧縮する Trace Pair Encoding(TPE)トークナイザを導入する。これらの表現の上に、TELLER は数値的な候補箇所特定と、異常ステップの予測・疑わしいオペレータの局所化・自然言語説明の生成を同時に行うマルチモーダルな根本原因モデルとを組み合わせる。マルチノード GPU 推論ワークロードでの実験は、圧縮と精度の明確なトレードオフを示す。すなわち、中程度の TPE ボキャブラリはステップあたりのトレース長を 80% 以上削減しつつ、水平(ノード間通信)ビューと垂直(ノード内実行)ビューの双方で最良の全体性能を達成する一方、より積極的な圧縮は診断品質を大きく損なう。低障害事前確率下での分析・強化されたベースライン・モダリティのアブレーション・説明品質の検査・トレーシングオーバーヘッドに関するさらなる分析は、TELLER が LLM 推論の根本原因分析に対する実用的なトリアージおよびエビデンス局所化の基盤を提供することを示している。 ## 論文情報 - タイトル: TELLER: Non-intrusive Cross-Layer Root-Cause Analysis for LLM Inference - 著者・所属: Ruilin Xu*, Junyi Li*, Pengfei Chen†✉, Zongxuan Xie†([[Sun Yat-sen University]]、広州、中国)。* は同等貢献、† は Corresponding authors 表記(謝辞では Pengfei Chen を corresponding author と明記) - 媒体: 41st IEEE/ACM International Conference on Automated Software Engineering(ASE '26)、2026年10月12–16日、ミュンヘン、ドイツ。査読受理 2026-06-18(投稿 2026-03-26) - arXiv ID: 2608.01975(cs.SE、投稿日 2026-08-03) - DOI: 10.1145/3832783.3837440 - コード・データ: figshare artifact(doi:10.6084/m9.figshare.33142493.v1、[37]) ## 概要 LLM 推論はエンジン・Python/C++ バックエンド・CUDA ホスト API・GPU カーネル・分散通信という深いソフトウェア/ハードウェアスタックにまたがるため、単一の障害の根本原因特定が難しい。TELLER は NVTX/CUPTI ベースの非侵入トレーシングとサービスログの収集、リクエスト単位のコールチェーン再構成、依存関係考慮型のスライス抽出、構造保存型のトレース圧縮(TPE)、トレースとログを統合したマルチモーダル診断モデルという一連のパイプラインで、この課題に取り組む。TELLER 自身は「これで自動修復まで完結する」とは主張せず、稀・曖昧・高インパクトなインシデントには依然として人間または専門ツールによる検証が必要な、初期トリアージ・エビデンス局所化のフィルタとして位置づけられている(§1)。 ## 問題設定 入力は、あるリクエスト $q$ のあるステップ $s$ について、クロスレイヤーで再構成されたコールチェーン木 $C_q(s) = (V_q(s), E_q(s))$(エンジン・フロントエンド/バックエンドオペレータ・ホスト API 呼び出し・GPU カーネル・通信イベントをノードとして含む)と、対応する整列済みログ集合 $L_q(s) = \{\ell_1, \dots, \ell_m\}$(各 $\ell$ はタイムスタンプとメッセージを持つ)の組 $x_s = (C_q(s), L_q(s))$ である。出力はトリプレット $f_\theta(x_s) = (\hat y_s, \hat r_s, \hat O_s)$ で、$\hat y_s$ はステップレベルの異常判定/障害ラベル、$\hat r_s$ は自然言語の根本原因説明、$\hat O_s \subseteq V_q(s)$ は疑わしいオペレータ/通信イベントのエビデンス集合である。論文は 4 つの要件を掲げる: (R1) バッチングと非同期性下でのリクエストレベル帰属、(R2) 生トレース全体でなくコンパクトな要約、(R3) バイナリ変更なしの非侵入デプロイ、(R4) エンジン・ワークロード・障害カテゴリを跨いだ転移可能性。 ## 提案手法 - **アーキテクチャ**: 図1(下記埋め込み)が示すように、TELLER は大きく二段のパイプラインからなる。左半分(Non-Intrusive Tracing of LLM Inference)は決定論的でシステム指向: NVTX/CUPTI で収集した生イベントを、コールチェーン再構成とログ整列によりリクエスト単位の垂直・水平トレースへ変換する。右半分(Fault Diagnosis & Root Cause Analysis)は表現・モデル指向: 疑わしい領域を局所化し causal-context slice を圧縮埋め込みへ変換して、テキストログと結合しトランスフォーマーデコーダで LLM 推論エラー種別とシステム根本原因を予測する。この分離により、オンライントレーシングのオーバーヘッドを抑えつつ、同一の収集トレースを複数の診断タスクに再利用でき、低レベル計装の寄与と学習された推論の寄与を切り分けられる(§3.1)。 - **非侵入クロスレイヤー収集**: ターゲットコマンドはトレーシングラッパーを通じて起動され、環境変数と動的ライブラリのプリロードで CUPTI/NVTX サポートを注入する。計測対象プログラム自体は変更されない。(1) Python レベルでは import 時ラッピングで NVTX フックを動的インストールし、vLLM のようなエンジンではステップレベルのラッパー関数がリクエスト識別子を NVTX メッセージに符号化して低レベル実行から request-level serving context への意味的アンカーを作る。(2) 各ワーカープロセスは CUPTI コールバック/アクティビティレコードをロードし、CUDA ランタイム呼び出し・ドライバ呼び出し・GPU カーネルを、開始/終了タイムスタンプ・PID/TID・ホスト起動とデバイスカーネルを結びつける相関 ID とともに捕捉する。(3) 同一実行から stdout/stderr またはサービスログを並行して収集し、タイムスタンプ(および利用可能ならリクエスト ID)で後から整列できるようにする(§3.2)。 - **リクエスト単位のコールチェーン再構成とログ整列**(Algorithm 1): 4 段階からなる。① イベント正規化: 各イベント $e=(\text{type}, \text{name}, \text{pid}, \text{tid}, \text{id}, \text{cid}, \text{fields})$ を共通の時刻基準 $\tau(e)$ に正規化(NVTX はタイムスタンプ、ランタイム/ドライバは開始時刻、カーネルは GPU 開始時刻を使用)。② レンジ再構成: プロセス・スレッド対ごとにイベントを $\tau$ でソートし、スタックスキャンで NVTX push/pop を対応づけ、包含関係 $r_1 \prec r_2 \iff r_2.\text{start} \le r_1.\text{start} < r_1.\text{end} \le r_2.\text{end}$ から階層フォレストを復元する。③ ホスト・デバイス束縛: レンジ区間内のホスト呼び出し $\text{host}(r)$ を紐付け、スレッド ID と相関 ID の一致でカーネルをホスト呼び出しに束縛する $\Gamma(a) = \{k \in K \mid (a.tid, a.cid) = (k.tid, k.cid) \land \tau(a) \le \tau(k)\}$。ステップレベル NVTX レンジが含むリクエスト集合 $Q(s)$ の各 $q$ について、垂直・水平の子孫をリクエスト固有のツリー $C_q(s)$ へ射影する。④ ログ整列: 各ログ行を $\ell = (\text{ts}, \text{rid}, \text{level}, \text{msg})$ に正規化し、リクエスト ID が使える場合はそれで、そうでなければステップ区間 $I(s)$ との時間重複でログを紐付ける($L_q(s) = \{\ell \mid \text{rid}(\ell)=q \lor \text{ts}(\ell) \in I(s)\}$、小さな許容窓を持つ)(§3.3)。 - **候補局所化と依存関係考慮型 causal-context slicing**: まず軽量な数値段階で探索空間を刈り込む。各オペレータインスタンス $x$ について自己時間・ランタイム/ドライバ時間と回数・カーネル回数と合計・概算転送バイト数・ストリームオーバーラップ・通信サイズから特徴ベクトル $\phi(x) \in \mathbb{R}^d$ を構築し、log(1+·) 変換とロバスト標準化の後、オペレータファミリごとに混合ガウス分布(GMM)を当てて異常スコア $a(x)=1-\rho(x)$($\rho(x)$ は責任質量)を得る。最も自信の低い分位点を集約してファミリレベルの疑わしさ $A_{s,t}$ を求め、疑わしいファミリ集合 $\tilde O_s$ を得る。次に、これをインスタンスレベルの依存関係考慮型サブグラフへ精緻化する。親子エッジ $E_p$・同一ステップ内の近傍イベント間の時間継起エッジ $E_t$・計算/通信間の通信結合エッジ $E_c$ を用い、ノード $v$ の関連度を $R_s(v) = \alpha \mathbb{1}[v \in I_s] + \beta \mathbb{1}[\exists u \in I_s: (u,v) \in E_p \lor (v,u) \in E_p] + \gamma \max_{u \in I_s} \exp(-\Delta t(u,v)/\tau_0) + \eta \mathbb{1}[\exists u \in I_s: (u,v) \in E_c]$ と定義し、$R_s(v) \ge \kappa$ を満たすノードに $h$ ホップの祖先を加えて causal-context slice $G_s = (V_s, E_s)$ を構成する(§3.4)。 - **Trace Pair Encoding(TPE)**(Algorithm 2): causal-context slice をモデルに渡す前に、深さ優先探索でステップ/スライスを `[STEP, name, FE, name, BE, name, RT, name, K, name, ...]` の記号列 $X$ にシリアライズし、各ノードに親インデックス $P$・持続時間 $\Delta$・深さ $D$ の側チャンネルを付与する。BPE スタイルの隣接ペアマージを行うが、通常の部分語トークナイザと異なり、頻出隣接ペア $(w_i, w_{i+1})$ を新トークン $w_i'$ に置き換える際、親インデックスは左トークンのものを継承し($p_i' = p_i$)、持続時間は加算し($\Delta_i' = \Delta_i + \Delta_{i+1}$)、深さは維持する($d_i' = d_i$)。これにより木構造とタイムバジェットを破壊せずに頻出実行モチーフを再利用可能な記号へ圧縮できる。目標ボキャブラリサイズに達するまでマージを繰り返し、`vocab.json`/`merges.json`/tokenizer メタデータを出力する(§3.5)。 - **構造・時間認識トレースエンコーダ**: TPE の出力トークン $i$ の初期表現は $h_i^{(0)} = E_{\text{tok}}(w_i) + E_{\text{depth}}(d_i) + \text{MLP}_\Delta(\log(1+\lambda \Delta_i))$。親インデックスが誘導するグラフ上で $L$ 層のグラフ畳み込み $H^{(\ell+1)} = \sigma(\hat A H^{(\ell)} W^{(\ell)})$(自己ループを加えた正規化隣接行列 $\hat A$)を適用し、トークンレベルの状態をステップ単位にプールして下流バックボーンの隠れ次元へ射影する(§3.6)。 - **マルチモーダル根本原因モデル**: 二つの変種を提供する。(i) **MoT(dual-head log–trace model)**: ログストリームを因果言語モデルバックボーンで、トレースストリームを上記エンコーダで符号化し、各層で連結して共有 causal self-attention $\tilde H^{(\ell)} = \text{Attn}([H_{\log}^{(\ell)}; H_{tr}^{(\ell)}], M_{\text{causal}})$ を通した後、モダリティ別の FFN で分離。トレースストリームはプールされて障害種別ヘッド $p(y_s|x_s) = \text{softmax}(W_f \bar H_{tr})$、ログストリームは LM ヘッドで説明を自己回帰生成する。(ii) **単一ストリームモデル**: `<fault_type>ŷs</fault_type> ◦ r̂s` という単一系列を自己回帰的に生成し、閉じた分類ヘッドに縛られないため転移・ゼロショット的設定に有利。本論文の主要な end-to-end 結果はすべて MoT を用いる(§3.7)。 ## 新規性 既存プロファイラ(Nsight Systems・PyTorch Profiler)はカーネル・ランタイム API のタイムラインを提示するが、リクエスト単位の根本原因を直接返さない。古典的な教師なし異常検知(KMeans・DBSCAN・Isolation Forest・GMM)は安定した数値シグナルを与えるが意味解釈が弱い。ログベース/LLM ベースの診断(RobustLog・LAnoBERT・Logs2Graphs・MAD-GAN 等)はテキスト症状に対する強力な推論力を持つが、GPU カーネル・CUDA 起動・通信パターンを無視する傾向がある。TELLER はこれらを「低レベル実行エビデンス」「構造的実行コンテキスト」「意味的診断手がかり」を接続する単一の trace–log 表現の上に統一する点が新規性である(§1, §2.2)。特に TPE は、通常の部分語トークナイザ(BPE/SentencePiece)が可読テキストの再利用可能な断片を学習するのに対し、型付き実行イベント([STEP]/[FE]/[BE]/[RT]/[K] 等)という異なる原子記号を対象に、親・持続時間・深さという構造側チャンネルを圧縮の下でも保存する点で trace 特化のトークナイザとして新しい(§3.5)。 ## 実験設定 - **環境**: デュアルノード GPU クラスタ。各ノードは Intel Xeon Gold 6326 CPU @2.90GHz、128GB RAM、NVIDIA A40(48GB)×3、ConnectX-6 NIC(クラスタ全体で GPU 6基)。vLLM で Qwen3-8B をオンライン(本番類似のリプレイ・バッチング・並行性)/オフライン(再現性重視の制御リプレイ)の両設定で提供(§4.1)。 - **データセット**: SGLang・Torch FSDP・vLLM v0・vLLM v1 offline・vLLM v1 online の 5 設定から 300 リクエストトレース、合計 2,482 実行ステップ・563 万クロスレイヤーノードを構築(表1)。57.7% が正常、42.3% が障害あり。障害注入は memory/resource(20.5%)・CUDA/kernel(21.3%)・runtime/driver(20.5%)・communication/network(18.1%)・scheduling/software(19.7%)の5カテゴリで、遅延・リソース/競合予算・スロットリング水準・リンク遅延/損失・スケジューリング撹乱といった機構固有のパラメータを制御する。分割はリクエスト非交差(request-disjoint)の 80/10/10 だが、同一ワークロード・run・障害注入キャンペーン由来の相関トレースはスプリットを跨ぐ可能性があり、報告数値は「分布内推定」として解釈すべきとしている(§4.2)。 - **比較対象**: 古典的教師なし(KMeans・DBSCAN・Isolation Forest・GMM)、古典的教師あり(SVM・Random Forest・XGBoost、構造化特徴を与えた強化版含む)、ログ/深層系列ベースライン(Robustlog・LAnoBERT・Logs2Graphs・MAD-GAN)、プロンプトのみベースライン(数値候補フィルタリングを外し LLM に構造化要約から直接推論させる)(§4.3)。 - **評価指標**: ステップレベル Accuracy/Precision/F1、オペレータレベル局所化の Macro Precision/F1/Jaccard(全ステップ集計)と Macro+(オペレータ陽性ステップのみ集計)、説明品質(障害種別正当性・エビデンスロケータ妥当性・因果一貫性・実行可能性・文の完全性、および BLEU-1〜4)、低事前確率下の Recall/F1/AUPRC/AUROC(§4.4)。 ## 実験結果 - **RQ1(既存手法比較、表2)**: 水平ビューで TELLER は Accuracy 0.930・Precision 0.945・F1 0.916 と全ベースライン中最良。オペレータレベル局所化(Macro/Macro+)でも同様に最良(例: Macro F1 0.806、Macro+ F1 0.898)。垂直ビューでも Accuracy 0.911・F1 0.900・Macro F1 0.792 で最良帯に位置する。古典的教師なし手法(KMeans/DBSCAN/Isolation Forest/GMM)は Accuracy が 0.43〜0.55 台にとどまり、ログベース深層手法(Robustlog 等)はステップレベルでは競合するがオペレータレベル局所化で大きく劣る(Macro F1 0.2〜0.4台)。表4 の追加実験では、プロンプトのみ推論(H Step F1 0.668)や構造特徴を与えた強化古典分類器(LinearSVM/RF/XGB、H Step F1 0.34〜0.40)は TELLER(0.916)に遠く及ばず、フルの trace–log パイプラインの寄与を裏づける。 - **RQ2(TPE 圧縮とRCA性能、表3・表6)**: ボキャブラリ 256 では平均 361.43 イベント/ステップ(6.20倍圧縮・83.88% 削減)まで圧縮しつつ、水平/垂直の両ビューで Step Acc 0.930/0.911・Op Macro F1 0.806/0.792・BLEU-1 0.910/0.908 と最良を維持する。512(25.90 イベント/ステップ・98.84% 削減)では Step F1 が 0.727/0.636 に、Op Macro F1 が 0.173/0.163 に急落し、1024(3.88 イベント/ステップ・99.83% 削減)ではさらに悪化する(Step F1 0.531/0.458、Op Macro F1 0.138/0.138)。オペレータレベル局所化が圧縮に最も敏感で、説明品質(BLEU)の劣化はより緩やかである。表5 のモダリティ寄与実験では、trace w/ log(Fault Acc 0.743・Macro F1 0.476)が w/o trace(0.667/0.292)・w/o log(0.653/0.446)を上回り、両モダリティの併用が最良。 - **RQ3(汎化、表7)**: SGLang(H Step F1 0.908)・Torch FSDP(0.907)・vLLM v0(0.901)・vLLM v1(0.912)で H/V Step F1・H/V Op F1+ とも安定した性能を示す。 - **RQ4(展開条件、表8〜10)**: 低事前確率下でも 10% prior で H/V F1 0.807/0.883 を維持(表8)。参照説明品質チェック(表9)は全体スコア 0.968(異常正当性・障害種別正当性が満点 1.000、因果一貫性が最低の 0.900)。トレーシングオーバーヘッド(表10)は wall time +9.8%(64.77s→71.15s 相当)、CPU 使用率 +8.8%、最大常駐メモリ +3.25%、スワップなし。 ## 考察 著者らは TELLER を「本番向けの決定的診断器」ではなく「トリアージ・エビデンス局所化の基盤」として明確に位置づける。障害注入データセットは大規模本番クラスタの反復パターンに基づいており網羅性・再現性・精密な trace–log 整列を持つが、実インシデントはより長く・ノイズが多く・絡み合っている可能性があるとし、低事前確率での再サンプリング結果は AUPRC の期待どおりの感度低下を示す。ボキャブラリ感度分析は明確な傾向を示すものの、最適点はエンジン・ワークロード・バックボーンによって変わりうるとし、現時点の結論は「TPE は有用だが、圧縮を限界まで押すより構造の保存の方が重要」と述べるにとどめている。汎化についても、A40 デュアルノード + Qwen ベースの主構成に加え SGLang・Torch FSDP・複数 vLLM バージョンでの追加検証はエンジン非依存の挙動を支持するが、より大規模クラスタ・新しい GPU・長時間稼働のマルチテナントワークロードでの挙動は将来課題としている。データ分割についても、例レベルではリクエスト非交差だが同一ワークロード/run/注入由来のサンプルがスプリットを跨いで文脈を共有しうるため、分布内推定が楽観的である可能性、また説明品質監査がラベルとトレースエビデンスに対する照合であり独立・盲検の専門家評価ではない点を明示している(§7)。ケーススタディ(§6)では、AI21 Labs が報告した実際の vLLM 障害——GPU メモリ圧迫下で新規到着の Mamba リクエストにスケジューラが 1 トークンのみ割り当て、attention backend がこれを decode シグナルと誤認して decode パス(`selective_state_update`)へルーティングし、本来の prefill カーネル(`selective_scan_fwd_kernel`)の代わりに実行してしまい、キャッシュから stale な SSM 状態を読む——を再現している。単一レイヤーのツールではカーネル(プロファイラ)かスケジューリングメタデータ(ログ)のいずれか一方しか見えないのに対し、TELLER の再構成コールチェーンは新規リクエストのエンジンメタデータ・decode へのバックエンドルーティング・decode カーネルのデバイス実行を同一リクエストについて同時に示し、同一バッチ内の正常な prefill リクエストが prefill カーネルを実行している事実と対比させることで、クロスレイヤーの矛盾から根本原因を直接特定できることを実証する。 ## 強み / 弱点・課題 **強み** - モデルバイナリ・サービングエンジンのソースコード・アプリケーションロジックを変更しない非侵入設計でありながら、GPU カーネル・CUDA API・通信という下位レイヤーまで捕捉する(§7 の "non-intrusive" の定義)。 - TPE により親子構造・持続時間・深さを保存したまま構造トークン列に圧縮でき、単純な部分語圧縮や生ノード列よりコンパクトかつ構造忠実(§3.5)。 - SGLang・Torch FSDP・vLLM v0/v1 という複数の推論エンジン/バックエンドで一貫した性能を示し(表7)、特定エンジンへの過学習でないことを裏づける。 - 実際の本番障害(AI21 Labs 報告)を再現するケーススタディを持ち、合成障害注入だけでなく実世界の障害クラスへの適用可能性を示す(§6)。 **弱点・課題(論文が明示するもの)** - 主評価は障害注入ベースの制御されたベンチマークであり、本番のインシデント事前確率(rare)を反映していない。低事前確率の再サンプリングでも本番の希少性・雑音・絡み合いを完全には模擬できない(§7)。 - 例レベルではリクエスト非交差だが、同一ワークロード/run/注入キャンペーンに由来するサンプルがスプリットを跨ぐ可能性があり、報告精度は分布内推定として楽観的でありうる。ワークロード/run 非交差の評価は将来課題(§7)。 - 説明品質の監査はラベルとトレースエビデンスに対する照合であり、独立・盲検の専門家評価ではない(§7)。 - 検証されたのはデュアルノード A40 クラスタと Qwen ベースのサービングスタックが中心で、より大規模クラスタ・新しい GPU 世代・長時間稼働のマルチテナントワークロードでの挙動は未検証(§7)。 - TPE の圧縮–精度トレードオフの「最適点」がエンジン・ワークロード・バックボーンに依存して変わりうることが示唆されており、512 や 1024 語彙という「積極的圧縮」設定は今回のデータでは一貫して性能を大きく損なう(表3)。 ## 図表 **Figure 1: TELLER の全体アーキテクチャ** ![[_attachments/arxiv-2608.01975/fig01-teller-architecture.png]] (Figure 1. TELLER はまず LLM 推論の非侵入クロスレイヤートレーシングを行い(左上: エンジン/フロントエンドの NVTX、CUDA ランタイム/GPU カーネルの CUPTI アクティビティ、stdout/stderr)、次にリクエスト単位のコールチェーンとログ整列を再構成し(左下)、疑わしい causal context を抽出・圧縮し(右下: Trace Pair Encode Tokenizer & Text Tokenizer)、最後にマルチモーダル障害診断で LLM 推論エラー種別と根本原因を予測する(右上: Transformer Decoder)。Source: Figure 1, PDF page 4.) **Table 2 抜粋: 既存手法との比較(水平ビュー、抜粋)** | Method | Step Accuracy | Step F1 | Op Macro F1 | Op Macro+ F1 | |---|---|---|---|---| | TELLER (ours) | 0.930 | 0.916 | 0.806 | 0.898 | | Robustlog | 0.874 | 0.771 | 0.384 | 0.597 | | LAnoBERT | 0.882 | 0.783 | 0.381 | 0.672 | | MAD-GAN | 0.819 | 0.706 | 0.382 | 0.579 | | KMeans | 0.457 | 0.611 | 0.244 | 0.533 | (Table 2 より一部抜粋。全項目は原論文参照。Source: Table 2, PDF page 6.) **Table 6: TPE 圧縮統計** | Vocab size | Avg. events/step after TPE | Compression× | Reduction | |---|---|---|---| | 256 | 361.43 | 6.20 | 83.88% | | 512 | 25.90 | 86.56 | 98.84% | | 1024 | 3.88 | 577.81 | 99.83% | (Table 6. 圧縮率が上がるほど診断精度が急落する(表3参照)——「圧縮率が高いほど良い」とは限らないことを示す核心的な結果。Source: Table 6, PDF page 7.)