Closed5

[論文] DeepFlow: Serverless Large Language Model Serving at Scale

論文
kun432kun432

論文

https://arxiv.org/abs/2501.14417

Claude-3.5-Sonnetによる落合プロンプトの結果

DeepFlow: スケーラブルでサーバーレスな大規模言語モデルサービング

どんなもの？

DeepFlowは、Huawei Cloudが開発した、大規模言語モデル(LLM)を効率的にサービング(推論実行)するためのサーバーレスAIプラットフォームです。主な特徴は以下の4つのコンポーネントです:

  1. リクエスト-ジョブ-タスクモデルと呼ばれるサーバーレス抽象化により、学習後処理やモデルサービングタスクを管理
  2. マイクロカーネルのような設計思想、NPU中心の実行、SPMD(Single-Program-Multiple-Data)ベースの並列処理を採用したFlowServeと呼ばれる独自のサービングエンジン
  3. PD(Prefill-Decode)分散/集約型の両設定に対応したスケジューリングポリシー
  4. プレウォームドポッド、DRAMプリロード、NPU-forkなどの最適化により、数秒で最大64インスタンスまでスケール可能

DeepFlowは1年以上にわたり、大規模なAscend NPUクラスタ上で本番稼働しており、ファインチューニング、エージェントサービング、モデルサービングなどの業界標準APIを提供しています。

先行研究と比べてどこがすごい？

DeepFlowの革新的な点は以下の通りです:

  1. 統合的なサーバーレス抽象化: 既存のサーバーレスAIプラットフォームと異なり、学習後処理からモデルサービングまでの多様なAIワークロードを単一の抽象化で管理できます
  2. 効率的なサービングエンジン: FlowServeは、マイクロカーネル設計とNPU中心の実行により、高スループットと低レイテンシーを実現しています
  3. 柔軟なスケーリング: プレウォームドポッドやNPU-forkなどの最適化により、数秒での高速なスケーリングを実現し、従来のシステムよりも迅速にリソースを調整できます
  4. 実証された実用性: 1年以上の本番運用実績があり、実際の大規模環境での有効性が確認されています

技術や手法の肝はどこ？

DeepFlowの核となる技術は以下の3点です:

  1. サーバーレス抽象化設計:

    • ユーザーからのHTTPリクエストを内部ジョブに変換し、さらに小さなタスクに分解
    • ジョブ実行者(JE)とタスク実行者(TE)による2層アーキテクチャで効率的に処理

  2. FlowServeエンジン:

    • マイクロカーネルのような設計で各機能をモジュール化
    • NPUを最大限活用する実行戦略
    • 関係型テンソルキャッシュ(RTC)による効率的なキャッシュ管理

  3. スケーリング最適化:

    • プレウォームドポッドによる起動時間の短縮
    • DRAMプリロードによるモデルロード時間の削減
    • NPU-forkによる高速なモデルコピー

どうやって有効だと検証した？

論文では以下の方法で有効性を検証しています:

  1. FlowServeのパフォーマンス評価:

    • 34Bモデルを使用した実験で、TPOTが50msの場合、v1からv2で2倍以上のパフォーマンス向上
    • v2からv3で約20%の追加的な改善を確認

  2. スケーリング性能の評価:

    • Llama3 8B、CodeLlama 34B、Qwen 72Bの3つのモデルで検証
    • 最適化前後での起動時間の比較により、大幅な改善を確認
    • NPU-forkの効果を異なるネットワークリンク(HCCS、RoCE)で比較

議論はある？

論文では主に以下の点について議論されています:

  1. PD分散型vs PD集約型の選択:

    • 入力長や出力長によって最適な構成が異なることを示す詳細な分析
    • 実行時の動的な選択の重要性

  2. スケーリングの課題:

    • モデルサイズの増大に伴うロード時間の増加
    • ネットワーク帯域幅の制約による影響

次に読むべき論文は？

論文中で重要な関連研究として以下が挙げられています:

  1. サービング効率化関連:

    • vLLM (SOSP 2023) - PagedAttentionによる高スループット化
    • SGLang (2023) - RadixAttentionによるキャッシュ再利用
    • LightLLM (2024) - 非同期実行によるスループット改善

  2. スケーリング最適化関連:

    • PipeSwitch (OSDI 2020) - モデルスイッチング最適化
    • BlitzScale (2024) - パラメータロード中のスループット改善
kun432kun432

ちょっとQA

Q: ソースコードは公開されていますか？

論文中にソースコードの公開に関する明確な記述はありませんでした。しかし、以下の点から推察できます：

  1. 論文では、DeepFlowはHuawei Cloudの商用プロダクトとして開発・運用されていることが明記されています。

  2. 特に、以下の記述があります：

"DEEPFLOW is Huawei Cloud's fully-hosted and serverless platform" (p.1)

  1. 商用プロダクトであることから、現時点ではクローズドソースであると考えられます。

もし詳細な情報や最新の状況を知りたい場合は、Huawei Cloudの公式ドキュメントやリソースを確認することをお勧めします。

Q: 何かしらコード実装に言及されている箇所はありますか？

はい、論文中でいくつかの実装に関する具体的な言及があります。主要な箇所を抜き出してまとめます：

  1. メインの実装言語とコンポーネント

    • FlowServeは主にPythonで実装
    • RTCとDistFlowモジュールはC++で実装

    "We implement FLOWSERVE primarily in Python, with RTC and DistFlow written in C++." (p.4)

  2. モデルローディングの実装詳細

    • safetensorsフォーマットを使用
    • テンソルを連続したブロックとして保存し、メモリに直接マッピング可能
# モデルローディングの例（論文から推測される実装）
def load_model(tp_rank):
   # 各TPプロセスは必要な部分のみを必要に応じてロード
   partition = load_partition_on_demand()
  1. KVキャッシュのプレフェッチ実装の概要
# スケジューラーでの非同期KVキャッシュプレフェッチの例
def sched_enqueue(request):
   # RTCのmatch APIを呼び出してキャッシュをチェック
   cache_info = rtc.match(request)
   if cache_info.needs_prefetch:
       # 非同期でキャッシュをプリフェッチ
       rtc.populate(cache_info)

  1. RTCのコアAPI
    論文のTable 1に記載された主要なAPI：

    • MatchByPrefixToken
    • MatchByID
    • Populate
    • QueryPopulate
    • AllocBlocks
    • AppendBlock
    • Copy
    • Free

  2. DistFlowの実装に関する言及

    • HCCLのピアツーピアAPIを使用
    • スケーラブルなスレッディングモデルを採用
    • 同期のボトルネックを回避する設計

これらの実装の詳細は主に論文のセクション4（FlowServe: an Efficient Serving System）で説明されています。ただし、これらは概念的な実装例であり、実際の商用システムでの実装とは異なる可能性があります。

Q: DeepFlowの実装の参考にしたものなどは言及されていますか？

はい、論文では複数の既存システムやアプローチを参考にしたことが言及されています。主な参考文献や影響を受けた実装について、以下にまとめます：

  1. サービングエンジンの設計面での参考実装：

    • vLLM v1アーキテクチャ

    "This is similar to the recent vLLM v1 architecture" (p.4)

    • SGLangのゼロオーバーヘッドスケジューラー実装

    "It is similar to the new zero-overhead scheduler introduced in SGLang-v0.4.0" (p.5)

  2. ネットワーキング実装（DistFlow）の参考：

    • データセンターRPCライブラリの設計原則

    "DistFlow follows design principles proposed by seminal data-center RPC libraries" (p.6)

    • 具体的には以下のライブラリの設計を参考：
      • MooncakeトランスファーエンジンのAPI設計
      • RDMAの実装アプローチ
      • HCCLの集合通信API

  3. キャッシング実装（RTC）の参考：

    • vLLMのブロックテーブル実装

    "RTC includes a traditional block table, originally proposed by vLLM" (p.6)

    • SGLangのRadix-treeインデックス実装
    • MemServeのキャッシュ再利用アプローチ

  4. スケジューリングアルゴリズムの参考：

    • Preble、SGLang、MemServeのローカリティ認識スケジューリング
    • vLLMとSGLangの非同期実行設計
    • Orcaのイテレーションレベルスケジューリング
    • Sarathiのチャンクプリフィル処理

これらの参考実装は主に以下の目的で活用されています：

  1. 既存のベストプラクティスの採用
  2. 実績のある設計パターンの活用
  3. 既知の問題に対する解決アプローチの参考

ただし、DeepFlowは単なる既存実装の組み合わせではなく、これらを参考にしながら、Huawei CloudのAscend NPU環境に最適化された独自のアーキテクチャを設計・実装しています。

モデル以外のアプリケーション実行についても考慮されていますか？

はい、論文ではLLMのサービング以外のアプリケーションについても言及があります。特に以下の点が記載されています：

  1. 対応するワークロードの種類：

    • ファインチューニング（Fine-tuning）
    • エージェントサービング（Agent serving）
    • モデルサービング（Model serving）

    "DEEPFLOW has been in production for over a year, operating on a large Ascend NPU cluster and providing industry-standard APIs for fine-tuning, agent serving, and model serving to our customers." (p.1)

  2. 対応するモデルタイプ：

    • 大規模言語モデル（LLM）
    • 大規模マルチモーダルモデル（LMM）
    • 埋め込みモデル（Embedding models）

    "This section presents FLOWSERVE, our in-house serving engine for large language models (LLM), large multimodal models (LMM), and embedding models." (p.4)

ただし、論文の主な焦点はLLMのサービングに当てられており、他のアプリケーションやモデルタイプについての詳細な説明や評価は限定的です。特に：

  • 実験評価セクションではLLMのサービングのみが取り上げられています
  • エージェントサービングやファインチューニングの具体的な実装詳細は説明されていません
  • マルチモーダルモデルや埋め込みモデルの具体的なユースケースや性能評価は含まれていません

このことから、DeepFlowは様々なAIワークロードに対応可能なように設計されているものの、主にLLMのサービングに最適化されていると考えられます。

kun432kun432

論文の引用にこんなのが関連として記載されていた

https://github.com/kserve/kserve

KServe

KServeは、予測および生成機械学習（ML）モデルを提供するためのKubernetesカスタムリソース定義を提供します。これは、標準化されたデータプレーンプロトコルを使用して、Tensorflow、XGBoost、ScikitLearn、PyTorch、Huggingface Transformer/LLMモデル用の抽象度の高いインタフェースを提供することにより、プロダクションモデルのサービングのユースケースを解決することを目的としています。
オートスケーリング、ネットワーキング、ヘルスチェック、サーバ設定の複雑さをカプセル化し、GPUオートスケーリング、Scale to Zero、Canary Rolloutsのような最先端のサービング機能をMLのデプロイメントにもたらします。KServeは、予測、前処理、後処理、および説明可能性を含む、シンプルでプラグイン可能な、プロダクションMLサービングのための完全なストーリーを可能にします。KServeは様々な組織で利用されています。

なぜKServeなのか？

  • KServeは、Kubernetes上で予測および生成AIモデルを提供する、標準的なクラウド非依存のモデル推論プラットフォームです。
  • 生成モデル用のOpenAI仕様を含む、MLフレームワーク全体にわたって、高性能で標準化された推論プロトコルを提供します。
  • CPUとGPUのスケール・トゥ・ゼロを含む、リクエストベースのオートスケーリングによる最新のサーバーレス推論ワークロードをサポートします。
  • ModelMesh を使用して、高いスケーラビリティ、高密度パッキング、インテリジェントなルーティングを提供します。
  • 推論、前処理/後処理、モニタリング、説明可能性のためのシンプルでプラグイン可能な本番環境でのサービス提供。
  • InferenceGraph を使用したキャナリーロールアウト、パイプライン、アンサンブルのための高度な展開。
Q: Kserveに言及されているようですが。

はい、論文中でKServeへの言及がありますが、非常に限定的です。具体的には以下の箇所で触れられています：

  1. 関連研究（Related Work）のServerlessの項目で、オープンソースの実装例として言及されています：

    "industry solutions such as AWS SageMaker and Azure ML [23], and the open-source KServe [17], providing practical implementations."

  2. 参考文献[17]として以下が挙げられています：

    "[17] KServe. KServe. https://github.com/kserve/kserve."

しかし、論文ではKServeの具体的な実装の詳細や、DeepFlowとKServeの詳細な比較、あるいはKServeの設計からどのような影響を受けたかについては言及されていません。

KServeは単に、サーバーレスMLモデルサービングの既存実装の一例として挙げられているだけで、DeepFlowの設計や実装に直接的な影響を与えた主要な参考システムとしては扱われていないようです。むしろ、前述のvLLM、SGLang、Mooncakeなどのシステムからより多くの影響を受けていることが論文から読み取れます。

kun432kun432

アプリケーションのフレームワークや、モデルの効率的な実行環境、みたいなものは増えつつあるが、「トータル」でこれらをデプロイ・管理するようなフレームワークはまだ見当たらないように思う。

Kubernetesがそれらに最適なのでは？とは思うのだが、じゃあそれぞれのコンポーネントのマニフェストを自分で設計して全部書くのか？と考えると、それもまた面倒な感もあってこれらを包括的にやってくれるようなフレームワークが欲しくなるのではないだろうか？

この辺が気になっている。それぞれの方向性は違うと思うのだけど。

https://x.com/_philschmid/status/1887422689855316146

https://docs.restack.io/introduction

https://github.com/ray-project/ray?tab=readme-ov-file

https://github.com/run-llama/llama_deploy

このスクラップは2025/02/10にクローズされました