Each language version is independently generated for its own context, not a direct translation.
🚀 xLLM とは？「AI 交通整理と高速道路」の革命
Imagine you have a super-intelligent robot assistant (the AI) that can write stories, answer questions, and recommend products. But this robot is huge and slow.
xLLM は、この「巨大で遅いロボット」を、**「スマートな交通整理システム」と「超高速道路」**を使って、誰でも快適に使えるようにする技術です。
現在の AI 運営には 2 つの大きな問題がありました。
- 混雑と無駄： 人が多い時間（オンライン）と少ない時間（オフライン）で、サーバーの使い方が偏って、無駄な待ち時間が生まれる。
- 道路の渋滞： AI が計算する際、部品同士の連携が下手で、計算能力が十分に発揮されていない。
xLLM は、これらを解決するために**「サービス（交通整理）」と「エンジン（車そのもの）」**の 2 つの部分を完全に分離して、それぞれを最適化しました。
🚦 1. サービス層（xLLM-Service）：賢い「交通整理員」
この部分は、AI に「誰に、いつ、何を」させるかを管理する司令塔です。
🌊 潮の満ち引きを味方につける（オンライン・オフラインの共存）
- 従来の悩み： 昼間は顧客からの問い合わせ（オンライン）が殺到し、夜間は暇になります。逆に、夜間に大量のデータ分析（オフライン）をさせると、昼間にリソースが足りなくなります。
- xLLM の解決策： **「潮の満ち引きを味方につける」**です。
- 昼間（混雑時）は、顧客対応を最優先。
- 夜間（空いてる時）は、オフラインの仕事をどんどん進めます。
- すごい点： 顧客が急に来ても、オフラインの仕事を「一時的に止めて（プリエンプション）」、すぐに顧客対応に戻れるようにします。まるで、**「渋滞時に緊急車両が優先通行する」**ような仕組みです。
🧩 役割を柔軟に変える「変幻自在のスタッフ」
- 従来の悩み： 「入力処理（プレフィル）」をするスタッフと「出力生成（デコード）」をするスタッフを固定すると、どちらかが忙しくなり、もう一方が暇になることがありました。
- xLLM の解決策： **「役割の柔軟な交代」**です。
- スタッフは「入力担当」でも「出力担当」でもありません。状況に合わせて**「今、どちらが忙しそうか」を見て、その場で役割を交代**します。
- これにより、サーバーの無駄な空き時間をゼロに近づけます。
📸 画像とテキストの同時処理（マルチモーダル）
- 従来の悩み： 画像を読み込んでから文章を生成するまで、順番に処理していたため、時間がかかりました。
- xLLM の解決策： **「並行作業」**です。
- 画像を処理するチームと、文章を生成するチームが同時に動き出します。
- さらに、画像と文章の処理を「どこで分けるか」を AI が自動で判断し、最も効率的なルートを選びます。
🛡️ 故障しても止まらない「不死身のシステム」
- もしサーバーが故障しても、他のサーバーがすぐに引き継ぎ、ユーザーには「何事もなかったかのように」見せます。データ（記憶）を分散して管理し、一部が壊れても全体が止まらない仕組みです。
⚙️ 2. エンジン層（xLLM-Engine）：超高速な「車体そのもの」
この部分は、AI が実際に計算を行う「エンジン」の性能を限界まで引き上げます。
🏎️ 計算の「隙間」を埋める（パイプライン化）
- 従来の悩み： CPU（司令塔）が準備をしている間、AI 計算チップ（エンジン）は「待機中」で、時間が無駄になっていました。
- xLLM の解決策： **「次の準備をしながら走る」**です。
- 今の計算をしている間に、CPU は「次の計算の準備」を並行して行います。
- まるで、**「料理人が鍋を煮ている間に、次の材料を切っている」**ような状態です。これにより、計算の「待ち時間（バブル）」をなくしました。
🔄 通信と計算の「二重走行」
- 従来の悩み： データをやり取りする（通信）間、計算が止まっていました。
- xLLM の解決策： **「二つの車線で同時に走る」**です。
- 「計算する車線」と「データを送る車線」を分けて、同時に動かします。
- 通信の待ち時間が、計算の時間の中に隠れてしまうため、全体が速くなります。
🧠 記憶の「魔法の棚」（xTensor メモリ管理）
- 従来の悩み： 長い会話をするとき、必要な記憶（KV キャッシュ）を連続した大きなスペースに確保しないと計算できません。でも、会話の長さは毎回違うので、スペースが余ったり足りなかったりします。
- xLLM の解決策： **「論理的にはつながっているが、物理的にはバラバラ」**な記憶管理です。
- 本棚の「本棚全体」は連続しているように見えますが、実際には「空いている棚」に本を散らして置いています。
- 必要な分だけ、空いているスペースを借りて使います。これにより、メモリの無駄をなくし、より多くの会話を同時に処理できるようになりました。
🎯 予測して先回りする（Speculative Decoding）
- AI が「次は A かな？B かな？」と 1 つずつ考えるのではなく、**「A と B 両方同時に予想して、正しい方だけ採用する」**という裏技を使います。これにより、生成速度が劇的に向上します。
🏆 結果：どれくらい速くなった？
このシステムを実際にテストした結果、驚異的な性能向上が見られました。
- 他社製品との比較： 既存のトップクラスのシステム（MindIE や vLLM）と比べて、最大で 1.7 倍〜2.2 倍も速い処理速度を達成しました。
- 実社会での活躍： すでに日本の大手企業（JD.com）で、AI チャットボットや商品推薦システムとして使われており、多くのユーザーの問い合わせをスムーズに処理しています。
💡 まとめ
xLLM は、**「AI という巨大な頭脳を、無駄なく、速く、そして安定して動かすための、究極の交通整理とエンジン技術」**です。
これにより、企業はより安く、ユーザーはより速く、AI の恩恵を受けられるようになります。まるで、**「AI 社会のインフラを、新幹線レベルにアップグレードした」**ような画期的な技術なのです。
Each language version is independently generated for its own context, not a direct translation.
xLLM 技術報告書の要約（日本語）
本論文は、JD.com が開発した大規模言語モデル（LLM）推論フレームワーク「xLLM」に関する技術報告書です。xLLM は、高パフォーマンスかつ大規模なエンタープライズレベルのサービングを目的として設計され、多様な AI アクセラレータに対して深い最適化が施されています。以下に、問題定義、手法、主要な貢献、評価結果、および意義について詳細をまとめます。
1. 背景と課題
現在の主流な LLM 推論フレームワーク（vLLM, TensorRT-LLM など）は、エンタープライズレベルのサービングにおいて以下の 4 つの主要な課題に直面しています。
- ハイブリッド・動的ワークロードへの対応不足: オンライン推論（チャットボット等）とオフライン推論（データ分析等）を混在させた環境において、オンラインサービスの SLO（サービスレベル目標）を維持しつつ、オフラインタスクの処理効率を最大化するスケジューリングが困難です。特に、潮汐現象（時間帯による負荷変動）への対応が不十分です。
- 静的な PD 分離の限界: Prefill（プレフィル）と Decode（デコード）を分離するアーキテクチャ（PD Disaggregation）は一般的ですが、リソース割り当てが静的であるため、リアルタイムな負荷変動や入出力長の急激な変化に適応できず、AI アクセラレータの利用率が低下します。
- マルチモーダル推論の非効率性: 画像、音声、テキストを含むマルチモーダル推論において、エンコード、プレフィル、デコードの各フェーズに対する並列処理やきめ細かなリソース割り当ての戦略が欠如しています。
- 大規模クラスターにおける安定性と効率性: クラスター規模の拡大に伴い、ノード故障時の迅速な復旧や、分散環境における KV キャッシュの効率的な管理、MoE（Mixture of Experts）アーキテクチャにおける Expert 間の負荷偏りの解消が課題となっています。
2. 手法とアーキテクチャ
xLLM は、**「サービス層（xLLM-Service）」と「エンジン層（xLLM-Engine）」**を分離した新しいデカップルド・アーキテクチャを採用しています。
2.1 xLLM-Service（サービス層）
リソース管理とスケジューリングを担当し、以下の機能を実装しています。
- オンライン/オフラインの共配置スケジューリング: オンライン要求（低遅延必須）とオフライン要求（ベストエフォート）を同一リソースプールで共配置します。オンライン負荷がピーク時にオフラインタスクをプリエンプション（中断）し、オフピーク時にオフラインタスクをスケールアップすることで、クラスター全体の利用率を最大化します。
- ワークロード適応型 PD 分離ポリシー: 静的な PD 比率ではなく、TTFT（First Token までの時間）や TPOT（Token 生成速度）などの指標をリアルタイムで監視し、プレフィルインスタンスとデコードインスタンスの役割を動的に切り替える（Stateless インスタンス設計）ことで、負荷変動に適応します。
- ハイブリッド EPD 分離ポリシー: マルチモーダル推論（画像＋テキスト）向けに、Encode（画像エンコード）、Prefill、Decode の 3 フェーズを柔軟に分離・結合する戦略（EP-D, ED-P, E-P-D など）をプロファイリングに基づいて自動選択します。
- グローバル KV キャッシュ管理: Mooncake Store を基盤とし、分散インスタンス間での KV キャッシュの転送と再利用を管理します。HBM-DRAM-SSD の階層構造を用いて容量を拡張し、キャッシュヒット率を向上させます。
- 高速フォールト回復: ノード故障時に、KV キャッシュの再計算か移行かを最適に判断し、迅速なサービス復旧を実現します。
2.2 xLLM-Engine（エンジン層）
推論実行の計算効率を最大化するためのシステムおよびアルゴリズム最適化を行います。
- マルチレイヤーパイプライン実行エンジン:
- フレームワーク層: CPU のスケジューリングと AI アクセラレータの計算を非同期にオーバーラップし、計算のアイドル時間を排除します。
- モデルグラフ層: マイクロバッチを用いたデュアルストリーム並列化により、計算と通信（All-to-All など）をオーバーラップします。
- オペレーター層: 行列演算ユニットとベクトル演算ユニットの並列実行を最適化し、ハードウェア利用率を最大化します。
- 適応型グラフモード: 可変長の入力に対応しつつ、カーネル起動オーバーヘッドを削減するため、動的形状パラメータ化と部分グラフ（Partial Graph）モードを採用し、Eager モードと Graph モードの利点を両立させます。
- xTensor メモリ管理: 「論理的に連続、物理的に離散」な KV キャッシュ構造を導入し、メモリ割り当ての競合を解消しながら、高い計算効率とメモリ利用率を両立させます。
- アルゴリズム最適化:
- 最適化されたスペキュレイティブデコーディング: 非同期処理と MLA（Multi-Head Latent Attention）の最適化により、スループットを向上させます。
- 動的 Expert 並列負荷分散（EPLB）: MoE モデルにおける Expert 間の負荷偏りをリアルタイム統計に基づき調整します。
- 階層的 DP 負荷分散: データ並列（DP）グループ間およびグループ内の微細な負荷偏りを解消し、ストレーグラー（遅延ノード）による待機時間を削減します。
3. 主要な貢献
- 統合的な弾性スケジューリング: オンライン/オフラインワークロードの共配置と、SLO を意識した動的な PD 分離ポリシーの導入。
- マルチモーダル対応: 画像・テキスト混合入力に対する最適化された EPD 分離戦略の提案。
- フルスタック最適化: 通信・計算・ストレージを横断するマルチレイヤーパイプライン、適応型グラフモード、xTensor メモリ管理によるハードウェア効率の劇的向上。
- アルゴリズムとシステムの統合: スペキュレイティブデコーディング、動的負荷分散、生成推薦（Generative Recommendation）向けの最適化など、アルゴリズムレベルの改善をシステムに統合。
4. 評価結果
JD.com の実環境（JD.com の AI チャットボット「JingYan」、マーケティング推薦、カスタマーサービスなど）およびベンチマークデータセット（ShareGPT, Azure Code など）を用いた評価が行われました。
- スループット向上:
- Qwen シリーズモデルにおいて、MindIE と比較して最大 1.7 倍、vLLM-Ascend と比較して最大 2.2 倍 のスループット向上を達成。
- DeepSeek シリーズモデルにおいても、MindIE に対して平均 1.7 倍 のスループット向上。
- PD 分離構成での DeepSeek-R1 評価では、MindIE に対して約 34% のスループット向上（11,351 tokens/s vs 8,476 tokens/s）。
- ビジネスシナリオ:
- 「JingYan」シナリオでは、Qwen3-8B において vLLM-Ascend の約 1.6 倍、DeepSeek-V3 では vLLM-Ascend の 9 倍以上の性能を達成。
- 生成推薦タスクでは、ビーム幅（Beam Width）が大きい高負荷条件下で、MindIE に対して約 23% のレイテンシ削減を実現。
- アブレーションスタディ:
- 各最適化モジュール（非同期スケジューリング、動的 PD 分離、マルチレイヤーパイプラインなど）が個別に性能向上に寄与していることが実証されました。特に、非同期スケジューリングは小規模モデルで 17.4% のスループット向上をもたらしました。
5. 意義と結論
xLLM は、大規模 LLM のエンタープライズレベルでの導入における「コスト削減」と「計算効率の向上」という二大課題に対して、サービス層とエンジン層の両面から包括的な解決策を提供しています。
- 実用性: JD.com のコアビジネスで既に運用されており、高可用性と高スループットを両立しています。
- オープンソース: 框架は GitHub で公開されており、多様な AI アクセラレータ（特に中国国内のアクセラレータ）への対応を通じて、オープンで多様なハードウェアエコシステムの発展を促進します。
- 将来展望: 単なる推論エンジンから、生成推薦やマルチモーダル生成を含む「AI ネイティブなアプリケーションフレームワーク」へと進化させることを目指しています。
本フレームワークは、大規模モデルの推論インフラが抱える複雑な課題に対し、システム設計とアルゴリズム最適化を融合させることで、劇的な性能向上を実現した画期的なアプローチと言えます。