> [!abstract] 概要(USENIX 掲載 Abstract の日本語訳) > 本論文では、クラウド環境で大規模言語モデル(LLM)を大規模に効率よくサービングするために設計された、スケーラブルでサーバーレスなAIプラットフォームである DeepServe を提案する。DeepServe は、資源割当・サービング効率・コールドスタートレイテンシといった主要な課題に、4つの主要設計コンポーネントを通じて対処する。第一に、DeepServe は request-job-task モデルと呼ぶシンプルなサーバーレス抽象化を用い、これにより post-training と model-serving にまたがる多様なAIワークロードを管理できる。第二に、DeepServe は FlowServe という自社開発のサービングエンジンを統合しており、マイクロカーネルに着想を得た設計、NPU中心の実行、SPMDベースの並列化によってLLMサービングを最適化する。第三に、DeepServe は PD 分離インスタンスと PD 同居インスタンスの両方が混在する構成向けに調整された新しいスケジューリングポリシー群を含む。第四に、DeepServe は pre-warmed pods・DRAM事前ロード・NPU-fork といった最適化を含み、これにより DeepServe は数秒で64インスタンスまでスケールできる。DeepServe は1年以上にわたり本番稼働しており、大規模な Ascend NPU クラスタ上で動作し、顧客に対して業界標準のAPIをファインチューニング・エージェントサービング・モデルサービング向けに提供している。 ## 論文情報 - タイトル: DeepServe: Serverless Large Language Model Serving at Scale - 著者: Junhao Hu([[Peking University]] / Key Lab of HCST (PKU), MOE。[[Huawei Cloud]] でのインターン期間中の成果)、Jiang Xu・Zhixia Liu・Yulong He・Yuetao Chen・Hao Xu・Jiang Liu・Jie Meng・Baoquan Zhang・Shining Wan・Gengyuan Dan・Zhiyu Dong・Zhihao Ren・Changhong Liu(以上 Huawei Cloud)、[[Tao Xie]](Key Lab of HCST (PKU), MOE / Peking University)、Dayun Lin・Qin Zhang・Yue Yu・Hao Feng・[[Xusheng Chen]]・[[Yizhou Shan]](以上 Huawei Cloud、Xusheng Chen と Yizhou Shan は co-corresponding author) - 媒体: 2025 USENIX Annual Technical Conference(USENIX ATC '25)、pp. 57–72 - 発表年月: 2025年7月7日〜9日、Boston, MA - URL: https://www.usenix.org/conference/atc25/presentation/hu-junhao ## 概要 DeepServe は Huawei Cloud がファインチューニング・エージェントサービング・モデルサービングを業界標準APIとして顧客に提供する、フルホスト型サーバーレスプラットフォームである。1年以上にわたり大規模 Ascend NPU クラスタ上で本番稼働しており、本論文はそのモデルサービング部分に焦点を当て、サーバーレス抽象化・サービングエンジン FlowServe・分散スケジューリング・高速スケーリングという4つの設計コンポーネントを report する。(Source: PDF §1) ## 問題設定 著者らは、LLMサービングをマルチテナントクラウド上で SLO を守りながら性能・資源利用率を両立させる上で3つの課題を挙げる。第一に、AIワークロードは持続時間が大きく異なる——ファインチューニングは数時間〜数日かかる一方、エージェントサービングや LLM サービングは数秒〜数分である——ため、共有資源の動的割当が難しい。第二に、LLMサービングは分散化・ステートフル化が進んでおり、単一の推論リクエストが複数の分散インスタンスにまたがり、キャッシュされた状態を扱うため、資源割当・同期・耐障害性の管理が複雑になる。第三に、LLMサービングの需要変動が激しく、資源最適化とコールドスタートレイテンシへの対処が難しい。(Source: PDF §1) ## 提案手法 ### アーキテクチャと serverless 抽象化(request-job-task モデル) DeepServe は開発者向けのサーバーレス抽象化として request-job-task モデルを導入する。request はユーザー送信の HTTP コールのような外部トリガーであり、request の種類(chat・fine-tuning 等)に一致する1つ以上の job がその request を処理し、job はさらに prefill task・decode task のような細粒度の task に分解される。chat request は PD 同居エンジン上では1つの task を生成する job になり、prefill-decode 分離構成では prefill task と decode task の2つを生成する job になる。この抽象化は、共有インフラ上でのAIワークロードのスケール、post-training と serving の同一クラスタでの統合、分散LLMサービングの単純化を可能にする。(Source: PDF §1, §3) DeepServe のアーキテクチャは Job Executor(JE)・Task Executor(TE)・クラスタマネージャという3つの中核コンポーネントから構成される。JE は受信リクエストを処理して task に分解し、利用可能な TE へ実行を割り当てる。TE は実際に task を実行する。同一のベースモデル・TP並列度・PDタイプを持つ TE 群は TE group を構成し、Relational Tensor Cache(RTC)が全 TE にまたがる KV キャッシュを含むテンソルの関係を管理する統一データプレーンとして機能する。クラスタマネージャはサービスディスカバリ・障害処理・ヘルス検知(推論がクラッシュせず「ハングした」状態になったリクエストを意図的に kill して回復する)・ギャング的なスケジューリング(大規模 decode インスタンスをスケールアウトするために既存の他インスタンスを意図的に kill して資源を確保する)を担う。(Source: 発表動画) **Figure 1: DeepServe 全体アーキテクチャ** ![[_attachments/atc25-hu-junhao/fig01-architecture.png]] (Figure 1. ユーザーリクエストは frontend を経由して適切な JE へ振り分けられる。Model Serving は Chat・Caching・Batch・Image 等の JE 種別を含み、各 model-serving JE は独立に分散スケジューリングアルゴリズムを実行する。RTC group 内の model-serving TE は DistFlow API でテンソルを交換する。クラスタマネージャは集中型・高可用モジュールであり、post-training・agent serving は簡略化のため省略。3世代の NPU クラスタ(Gen1: scale-out servers、Gen2: scale-up SuperPod、Gen3: disaggregated cluster)のうち現在は Gen1・Gen2 をサポートする。Source: PDF Figure 1。) 発表では、この基盤全体は社内で XDS(extremely disaggregated system)と呼ばれ、DeepServeはその中の serving 部分を指すと説明された。XDS は LLM 推論・post-training・agent serving を単一の統合資源プール上で扱い、性能とコスト効率の両立を狙う。(Source: 発表動画) Huawei の Ascend NPU について、発表では Ascend 910B/910C チップが1チップあたり2ダイ構成で各ダイに約25〜30個のAIコア(cube core・vector core を含む)とARM CPUを1つ搭載すること、CloudMatrix384 SuperPod は48ノード・384 NPU で構成され SuperPod 内は約200GB/秒の低遅延インターコネクトで結ばれ、SuperPod 間は RoCE ネットワークでスケールアウトする(帯域・遅延は SuperPod 内接続より劣る)ことが補足された。(Source: 発表動画; ハードウェア仕様の一部は PDF §2 の Ascend NPU 節とも整合) ### FlowServe: サービングエンジンの設計 FlowServe は DeepServe の各 model-serving TE が使う自社製サービングエンジンであり、3つの設計原則に基づく。(1) microkernel-inspired design: サービングエンジンの機能をモジュール化されたコンポーネントに分割し、それぞれが独立にスケール・進化・非同期動作できるようにする。(2) NPU-centric execution: CPU・DRAM・ストレージなど他資源の待ちによる遅延を減らし、NPU を常に稼働させ続ける。(3) SPMD-based design: vLLM と共通する設計であり、複数 NPU にまたがる効率的な並列処理とスケーリングを可能にする。(Source: PDF §4.1, §3) FlowServe は6つの中核機能(トークン化・モデル実行・スケジューラ・メモリ管理・キャッシュ管理・ネットワーキング管理)を持つ。トークナイザは独立にスケール可能なモジュールであり、それ以外は master-executor アーキテクチャに従う——master がスケジューリング・キャッシング・ネットワーキングの意思決定を担い、NPUごとの executor がそれらの決定を各 NPU 上で実行する。実装は主に Python で書かれ、性能クリティカルな RTC と DistFlow は C++ で実装される。発表では、Python は迅速なイテレーションとアルゴリズム開発者へのフレンドリーさゆえに採用されたが低速でチューニングが難しく、コルーチンが Python インタプリタ内でスケジューリングされないという課題があったため、この使い分けについて「熱い議論」があったと補足された。(Source: PDF §4.1; 実装言語選定の経緯は発表動画) **Figure 2: FlowServe アーキテクチャと非同期実行タイムライン** ![[_attachments/atc25-hu-junhao/fig02-flowserve-architecture-timeline.png]] (Figure 2. (a) FlowServe エンジンは TE-shell なしでもデプロイできる。(b) FlowServe のモデルジェネレータは複数バックエンドをサポートする——FlowTurbo は torch ベースの動的グラフ、Ascend-Transformer-Boost(ATB)は C++ ベースの静的グラフである。右図はスケジューラが常に1ステップ先を予測して実行することで NPU のアイドルを避ける非同期実行タイムラインを示す。Source: PDF Figure 2。) スケジューラは master モジュールに集中化されている。SGLang が採用する分散スケジューラと比べ、頻繁なプロセス間通信(IPC)というコストを払う代わりにシンプルさを選んだ設計判断である。asynchronous KV cache prefetch では、sched-enqueue スレッドが RTC の `match` API でキャッシュ有無を確認し、コストモデルで再利用が有利かを判断したうえで `populate` API を非同期に呼び出して NPU へキャッシュを取り込む。asynchronous execution は、スケジューリング判断が実際に生成されたトークンIDに依存せず「次に処理すべきトークン数」だけに依存するという観察に基づき、スケジューラを別スレッドで先行動作させて NPU の待ち時間をなくす。pipeline parallelism では PP の第1ステージに集中スケジューラを置き、chunked prefill 有効時はチャンクを複数マイクロバッチに分散させることで TTFT を最低20%削減する。(Source: PDF §4.2) FlowServe は Relational Tensor Cache(RTC)で prefix caching と position-independent caching を統合する。 | API | 説明 | |---|---| | `MatchByPrefixToken` | トークン列に基づき保存済み KV キャッシュを検索 | | `MatchByID` | ID に基づき保存済み KV キャッシュを検索 | | `Populate` | 指定した保存済み KV キャッシュを NPU に取り込む | | `QueryPopulate` | populate の状態を確認 | | `AllocBlocks` | prefill 用ブロックを割当 | | `AppendBlock` | decode 用ブロックを割当 | | `Copy` | NPU から DRAM へブロックをコピー | | `Free` | ブロックを解放 | (Table 1. Relational Tensor Cache の中核 API 一覧。Source: PDF Table 1) RTC は vLLM 由来の伝統的なブロックテーブルに加え、radix-tree インデックス([[SGLang]] 由来)と ID ベースインデックスを組み合わせたハイブリッドインデックス層を持ち、各インデックスノードは NPU 上のデータまたはローカル DRAM 上のデータのいずれかを指すことができる。RTC master は複数のバックグラウンドスレッド(スワッピング・プリフェッチ等)を持つ。(Source: PDF §4.3) DistFlow はネットワーキング管理を担い、異種メモリ間の peer-to-peer / many-to-many テンソル転送に特化する。制御面 API `LinkCluster` でピアグループを確立し、データ面 API `transfer(srcInfo, dstInfo)` で生メモリアドレスを直接指定して転送する。scaled-out Ascend クラスタでは Huawei Collective Communication Library(HCCL)の peer-to-peer API を、scaled-up SuperPod では NPU メモリコピープリミティブを転送バックエンドとして使い分ける。(Source: PDF §4.4) DeepServe は task-level(prefill と decode を別TEに分離)と operator-level(attention と experts を別TEに分離)の2階層で分離を定義する。task-level は先行研究([12,33,51]、[[Prefill-Decode分離]] 参照)と同様に prefill TE から decode TE へ by-req または by-layer で DistFlow を使い KV キャッシュを送信する。operator-level は SuperPod へのデプロイに向けて開発中とされる。(Source: PDF §4.5) ### SuperPod スケールへの対応 CloudMatrix384 SuperPod のようなグローバル共有メモリアドレス空間を持つ大規模 scale-up ドメインへ FlowServe を拡張するため、2つの主要な変更が導入された。第一に、スケジューリングのボトルネックを避けるため、システムを複数の並列 DP group に分割する——各グループが独自のスケジューラ・RTC・DistFlow・executor 一式を持ち、集中型 DP スケジューラがラウンドロビンまたは greedy 戦略でリクエストを DP group 間に振り分ける。各 DP group は復路のボトルネックを避けるため独立に frontend へトークンを返す。第二に、大規模 PD 分離をサポートするため DistFlow を M:N 接続に拡張し、全ての prefill DP group と decode DP group 間に転送チャネルを確立する。(Source: PDF §4.6) **Figure 5: SuperPod 向け FlowServe の適応** ![[_attachments/atc25-hu-junhao/fig05-superpod-adaptation.png]] (Figure 5. 単一の FlowServe TE は数十サーバー・数百 NPU チップを管理できる。DP Scheduler が複数 DP group にリクエストを振り分け、各 DP group は Master(Sched・RTC・Parser・Tokenizer)と Executor(Async Model Gen・RTC Executor・DistFlow)を持つ。Source: PDF Figure 5。) MoE モデル(DeepSeek-V3/R1、Pangu-Ultra-MoE 等)は expert モジュール前後の all-to-all 通信で高帯域スケールアップドメインの恩恵を強く受け、大バッチサイズでのみ高い計算効率を達成する experts の特性は attention 層でのデータ並列(DP Attention)を要求する。DP Attention 下では prefill と decode の同居は深刻な干渉を招くため、効果的なデプロイには PD 分離が必須となり、それがさらに高速・低遅延インターコネクトを要求する——CloudMatrix384 SuperPod はこれに適した大規模 scale-up ドメインを提供する。(Source: PDF §4.6) ### 分散スケジューリング設計 DeepServe の分散スケジューリングは3つの新しい課題に直面する。(1) prefix caching 導入以降 TE がステートフルになり locality-aware なスケジューリングが必要になったこと、(2) PD 分離導入により PD 分離 TE と PD 同居 TE のどちらが有利かが自明でなくなったこと、(3) prefix caching と分離の両方を同時に考慮する必要があること、である。(Source: PDF §5.1) locality-aware scheduling は Preble・SGLang・MemServe と同様、JE がグローバル prompt tree を TE タイプごとに保持し、各 TE もローカル prompt tree を保持して、到着リクエストのプロンプトトークンを global prompt tree に照合し、最長共通プレフィックス(最大の再利用可能 KV キャッシュ)を持つ TE を選ぶ `select_tes_prefix_match` 関数として実装される。(Source: PDF §5.2) PD-aware scheduling は「PD 分離 TE と PD 同居 TE のどちらが有利か」をヒートマップとして実測した上で、実行時ポリシーへ変換する。RPS ごとのヒートマップを要素ごとに加算して安定化させ(80%超のセルが全 RPS で一貫して正または負の値を取る)、[[TetriInfer|TetriServe]] 由来の軽量LLM分類モデル(84.9%精度)で decode 長を予測し、対応するヒートマップセルの符号に基づき PD 分離/PD 同居のどちらを選ぶかを決める `select-tes-PD-heatmap` ポリシーとして具体化される。(Source: PDF §5.3) combined algorithm は load-aware・locality-aware・PD-aware の3スケジューリングを統合する。以下は本文 Algorithm 1 の擬似コードである(Source: PDF Algorithm 1): ``` Input: リクエスト req、TE group tes Output: リクエストを転送する TE Function dist_sched(req, tes): tes ← PD_aware(req, tes) if tes.is_load_balanced() then tes ← locality_aware(req, tes) else tes ← load_aware(req, tes) return tes Function PD_aware(req, tes): p_l ← req.get_prefill_length() d_l ← req.get_decode_length() tes ← tes.select_tes_PD_heatmap(p_l, d_l) return tes Function locality_aware(req, tes): tes ← tes.select_tes_prefix_match(req) return tes ``` まず PD-aware でサブグループ(PD分離/PD同居)を選び、次に負荷が均衡していれば tree ベースの prefix matching で再利用可能な KV キャッシュが最も多い TE を、負荷が不均衡であれば最も負荷の低い TE を優先する。(Source: PDF §5.4) ### 高速スケーリング設計 DeepServe のクラスタマネージャの AUTOSCALER は負荷や SLO 違反率などのメトリクスに基づき TE・JE のスケーリングを判断する。オートスケーリングは5ステップからなる。 | ID | ステップ | 定義 | 主な課題 | 本論文の解決策 | |---|---|---|---|---| | 1 | Scaler-Pre | TE を保持する Pod を作成 | 資源割当が遅い | Pre-warmed Pods | | 2 | TE-Pre-Load | モデルロードなしで TE を起動 | Python 起動が遅い / NPU 初期化が遅い | Pre-warmed TEs | | 3 | TE-Load | モデルを NPU にロード | モデル重みが大きい | DRAM 事前ロード / NPU-fork | | 4 | TE-Post-Load | リクエスト提供準備 | エンジンウォームアップが遅い / ブロック割当が遅い | オフラインプロファイリング / 非同期割当 / ダミーリクエストウォームアップ | | 5 | Scaler-Post | TE 準備完了から初回リクエストまで | グローバル TE リストの更新が遅い | プロアクティブなプッシュ | (Table 2. DeepServe のエンドツーエンドスケーリングステップ・課題・解決策の要約。Source: PDF Table 2) **Figure 8: DeepServe のスケーリング設計** ![[_attachments/atc25-hu-junhao/fig08-scaling-design.png]] (Figure 8. (a) TE-Load の2ケース——ローカル DRAM からのロード(DRAM-hit)と他 TE の NPU からのロード(NPU-fork、scale-up または scale-out ネットワークリンク経由)を示す。(c) 下段は3種類のスケーリングケースのタイムラインを示す。Source: PDF Figure 8。) pre-warming は2段階で行われる。第一段階では pre-warmed TE をモデル非依存にする(例: TP-8 の pre-warmed TE は Llama3-70B にも Qwen2-72B にも適応可能)。第二段階では、TP/PP/SP 構成に関わらず全 TE が master-SPMD アーキテクチャに従うことを利用し、pre-warmed SPMD-master と SPMD-executor を独立プールとして持ち、オンデマンドでパッキングできるようにする。(Source: PDF §6.1) モデルロードは safetensors 形式を用いたローカルロード(各 TP プロセスが必要な分割のみをオンデマンドでロードし read amplification を避ける)と、高速 NPU間リンクを使う NPU-fork の2経路を持つ。NPU-fork は一般に高速だがハードウェア要件が高く、コールドスタート(0 TE からのスケーリング)には使えない。クラスタマネージャはスケールしそうなモデルを予測し pre-warmed TE の DRAM ページキャッシュへ事前ロードしておく。1マシンあたり 1.5TB の DRAM があり、70B モデル10個または7Bモデル100個を事前ロードするのに十分とされる。(Source: PDF §6.2) ## 新規性 著者らは関連研究を4領域(サーバーレスインフラ・サービングエンジン・スケジューリング・スケーリング最適化)に整理した上で、DeepServe の新規性を次のように位置づける。KServe・AIBrix・NVIDIA Dynamo・LeaderWorkerSet(LWS)など既存のサーバーレス LLM 基盤の多くが GPU クラスタを対象とするのに対し、DeepServe は NPU ベースのクラスタ向けに設計されている。また著者らの知る限り、DeepServe は post-training から serving までの多様な AI ワークロードを統合する request-job-task 抽象化を導入した初めての公開プラットフォームである。スケジューリング面では、PD 分離 TE と PD 同居 TE のどちらを使うべきかを判断する PD-aware scheduling policy を新規に導入し、これを locality-aware・load-aware スケジューリングと統合する点が新しい。スケーリング面では、NPU-fork は BlitzScale と類似の発想だが下層のネットワークファブリックが異なる。(Source: PDF §8) ## 実験設定 - ハードウェア: Huawei Ascend NPU(910B: 400 TFLOPS FP16・64GB HBM/チップ、910C: 2ダイ構成で各400 TFLOPS・64GB HBM)。Gen1 は8チップ/サーバーの scale-out 構成(200Gbps RoCE で接続)、Gen2 は CloudMatrix384 SuperPod(48サーバー・384 NPU、約200GB/秒(単方向)の高帯域ネットワークで接続、全 CPU/NPU が統一メモリアドレス空間を共有)。(Source: PDF §2) - 評価モデル: 34B モデル(TP=4)を中心に、Llama3-8B(TP=1)・CodeLlama-34B(TP=4)・Qwen-72B(TP=8)をスケーリング実験で使用。 - ワークロード: オフライン評価は256ステップのdecodingで平均TPOTとdecodingスループットを測定。オンライン評価はコード生成サービスからサンプリングした内部トレース(roughly 2K input, 200 output)を使用しRPSを変化させる。 - 比較設定: PD分離(prefill/decodeを別TE)とPD同居(chunked prefill併用)、Round RobinとPD-awareスケジューリング。 ## 実験結果 ### FlowServe オフライン/オンライン性能 **Figure 3: FlowServe オフラインサービング性能** ![[_attachments/atc25-hu-junhao/fig03-offline-serving-perf.png]] (Figure 3. 34B モデル・TP=4。左は prefill 長 2K、右は 4K。v1→v2 では非同期スケジューリングと IPC 最適化により TPOT SLO 50ms 時点で2倍超の改善、v2→v3 ではデータ構造・サンプリング等の最適化により約20%の改善を得た。Source: PDF Figure 3, PDF §4.1) **Figure 4: FlowServe オンラインサービング性能** ![[_attachments/atc25-hu-junhao/fig04-online-serving-perf.png]] (Figure 4. 34B モデル・TP=4、内部トレース(約2K入力・200出力)。(1) PD分離(prefill×2, decode×2)、(2) PD分離(prefill×2, decode×1)、(3) PD同居×4の3構成をRPS 0.2〜1.2で比較。分離構成は特定のSLO下でスループットを大きく改善し、同一スループットでTPOTを下げる。Source: PDF Figure 4, PDF §4.5) ### PD 分離 vs PD 同居のヒートマップ研究 **Figure 6: PD分離とPD同居(chunked prefillあり)の性能比較ヒートマップ** ![[_attachments/atc25-hu-junhao/fig06-pd-heatmap.png]] (Figure 6. y軸はprefill長、x軸はdecode長/prefill長の比。セルの値は(PD同居のJCT / PD分離のJCT) − 1で、正の値はPD分離が有利、負の値はPD同居が有利であることを示す。34BモデルTP=4。3つの主要観察: ①PD分離はプロンプトが長くdecodeが短いリクエストで有利、prefill長が増すほどこの優位性がdecode長の長いリクエストでより顕著になる。②PD分離が有利になる場合の性能差(濃い赤)はPD同居が有利になる場合の性能差(薄い青)より大きく、PD分離TEの正しい選択は大きな性能向上をもたらす一方、誤った選択の損失は小さい。③この傾向はRPSが変化しても一貫する。Source: PDF Figure 6, PDF §5.3.1) ### 分散スケジューリングアルゴリズムの評価 **Figure 7: 分散スケジューリングアルゴリズムの研究** ![[_attachments/atc25-hu-junhao/fig07-scheduling-study.png]] (Figure 7. 34B モデル・TP=4、コード生成サービスからサンプリングした内部トレース。クラスタは4サーバーで、PD同居TE×2とPD分離TEペア(1P1D)×1から構成。10 req/s 等の特定RPS帯でPD-awareスケジューリングはRound Robin(RR)を上回るが、低RPSでは両者の性能はほぼ一致する(PD同居内でのprefill/decode干渉が無視できるため)。非常に高いRPSではPD-awareがRRより悪化する場合がある(PD分離TEは同一資源でも過負荷になりやすいため)が、過負荷時でもRR比で大幅な性能劣化は見られない。Source: PDF Figure 7, PDF §5.3.2) ### 高速スケーリングの実測 **Figure 9: スケーリングのエンドツーエンド内訳** ![[_attachments/atc25-hu-junhao/fig09-e2e-scaling-breakdown.png]] (Figure 9. 最適化前後のスケーリングレイテンシ内訳。最適化後もTE-Pre-loadステップがスケーリング時間の支配的要因であり続けるが、この遅延はpre-warmingによりさらに削減できる。Source: PDF Figure 9, PDF §6.1) **Figure 10: TE-Load の研究** ![[_attachments/atc25-hu-junhao/fig10-te-load-study.png]] (Figure 10. DRAM-hitは事前ロード済みDRAMからのロード、DRAM-missはSSDからのロード、DRAM-theoreticalはモデル重みをPCIe帯域で割った理論値。NPU-forkはHCCS(高帯域・小規模)とRoCE(低帯域・数千ノードへスケール可能)の2リンクを持つ。HCCSでのロードはRoCEより著しく高速であり、SuperPodアーキテクチャがNPU-forkの恩恵を大きく受けることを示唆する。Source: PDF Figure 10, PDF §6.2) **Figure 11: NPU-fork のスケーラビリティと感度の研究** ![[_attachments/atc25-hu-junhao/fig11-npu-fork-scalability.png]] (Figure 11. Llama3-8B-TP1をscale-upネットワーク(HCCS)上で実行。(a) 1つの稼働中TEから複数TEへ並列にスケールする場合の時間。(b) source TEがprefillしているシーケンス長を変えた場合の32TEへのスケーリング時間。(c) source TEが1kトークン長のバッチをdecodeしている場合のスケーリング時間。NPU-forkはHCCL の broadcast APIで複数TEへ同時にモデル重みを送信することで最大32TEまでスケールできる。NPUには専用のデータ転送用AICPUがあるため、prefill/decode処理との資源競合は限定的。Source: PDF Figure 11, PDF §6.2) ## 考察 NPU非依存 vs NPU固有の機能について、DeepServe の高レベルアーキテクチャ・中核設計は概ねハードウェア非依存であり、オートスケーリングに使う NPU-fork 機構は Ascend の HCCS インターコネクトに依存するが、NVIDIA GPU の NVLink のような高速チップ間リンクを持つ他ハードウェアにも同様の技術を適用できるとする。CloudMatrix384 SuperPod での全NPU間メモリアクセスのような機能は通常の scale-out AI サーバーにはない能力であり、これがNPU固有の機能の主因となる。(Source: PDF §7) DeepServe は LLM 以外への一般化も可能とされ、embedding モデルやマルチモーダル理解モデルなど大半のコンポーネントは vLLM 同様に同一の FlowServe エンジン内で動作する。障害回復については、TE または JE の障害発生時に該当コンポーネントを再起動し冗長な代替先へリクエストを振り向け、5分以内の回復を保証する。RTC はソフトステートを保持し(失われても再計算可能・追記専用)、複雑な一貫性プロトコルを実装しない設計判断を取っている——本番環境ではシステムレベルの冗長性と SuperPod アーキテクチャによる均一な NPU間通信により、この設計判断がサービス品質へ大きな影響を与えていないと報告される。(Source: PDF §7) 発表では、論文投稿から半年ほど経過した最新の進捗として、DeepSeek-R1級の大規模モデルを例に、完全に分離された推論エンジンへの移行、複数のP/D推論を横断する単一レベルのスケジューラ(omni request scheduler)、SuperPod向けのメモリセマンティクスに基づく通信ライブラリ(xCCL)の導入、再計算(try-cache-finalize)によるクラッシュ回避などの信頼性改善が進行中であること、1 NPUあたりTPOT 30msで約2,300トークン/秒相当の性能を達成していること、詳細な技術レポートを近く公開予定であることが共有された。(Source: 発表動画) ## 強み / 弱点・課題 - Strengths: 1年以上の本番稼働実績を持つ産業論文であり、request-job-task という単純な抽象化で post-training・agent serving・model serving を単一クラスタに統合する設計と、PD分離/PD同居のどちらが有利かをヒートマップとして実測しスケジューリングポリシーへ変換する手法(select-tes-PD-heatmap)が具体的である。pre-warming・DRAM事前ロード・NPU-forkを組み合わせた高速スケーリングは、E2E内訳(Figure 9)や個別要因の実測(Figure 10, 11)を伴っており再現性の高い設計になっている。 - Weaknesses/Limitations: 評価の多くが34BモデルTP=4という単一構成に集中しており、より大規模なMoEモデルやSuperPod規模でのPD分離・スケジューリング評価は「開発中」または「今後の課題」として述べられるにとどまる(operator-level disaggregationはSuperPodへの展開に向けて開発中と記載)。decode長予測モデルの精度は84.9%にとどまり、著者ら自身がさらなる精度改善を今後の課題としている。RTCのソフトステート・追記専用設計による耐障害性は本番での経験則に基づく主張であり、定量的な障害注入実験は示されていない。(Source: PDF §5.3.3, §4.5, §7)