FastDeploy を採用する前に読む: PD 分離と vLLM 互換 API の中身

FastDeploy が埋めようとしている溝はどこにあるのか

学習済みモデルを配布物として受け取ったあと、実際にリクエストを捌ける形にするまでには、いくつかの独立した作業がある。重みの読み込み、バッチ処理、KV キャッシュの管理、複数 GPU への分割、そして HTTP サーバとしての公開である。FastDeploy はこの区間をひとつのツールキットにまとめ、PaddlePaddle を土台に据えている。対象は LLM と VLM の両方で、README の冒頭でもその 2 つが明示されている。

想定読者は、モデル研究ではなく運用側にいるエンジニアである。README が並べている機能、すなわち負荷分散式 PD 分解、KV キャッシュ転送、OpenAI API 互換のサービス、複数量化形式、投機デコードと MTP、分塊預填 (chunked prefill) は、いずれも学習ではなくサービングの都合で存在する。モデルを差し替えるたびにサービング層を書き直したくない、という動機が読み取れる。

もうひとつの軸はハードウェアである。対応先として NVIDIA GPU のほか、昆仑芯 XPU、海光 DCU、天数智芯 GPU、燧原 GCU、沐曦 GPU、Intel Gaudi が列挙されている。NVIDIA 以外のアクセラレータを調達している組織にとって、上流の推論エンジンが対応しないハードウェアをカバーする点は、機能表よりも重い意味を持つ。

PD 分離と KV キャッシュ転送という設計の読み方

FastDeploy の中心にあるのは prefill と decode を別インスタンスに分ける構成である。README では「負荷分散式 PD 分解」と呼び、コンテキストキャッシュと動的なインスタンス役割の切り替えに対応すると説明している。プロンプトを読む処理 (prefill) は計算密度が高く、トークンを 1 個ずつ生成する処理 (decode) はメモリ帯域に律速される。性質の違う 2 つを同じプロセスに詰めると、どちらかの資源が余る。分離するのはその無駄を減らすためである。

分離すると、prefill 側で作った KV キャッシュを decode 側へ渡す必要が出る。この転送層が「統一 KV キャッシュ転送」で、README は NVLink と RDMA を状況に応じて選ぶ軽量ライブラリだと記述している。ここは見落としやすいが、PD 分離の実効性能を決めるのは計算カーネルではなくこの転送経路である。ノード内で NVLink が使える構成と、ノードをまたいで RDMA を使う構成では、設計上の前提が変わる。

v2.4 のリリースノートでは DeepSeek V3 と Qwen3-MoE の PD 分離対応が追加されたとある。MoE はトークンごとに活性化するエキスパートが変わるため、分離構成での負荷分散が難しくなる。バージョンを追うごとに対象モデルが増えているのは、この難しさへの対応が進んでいるという読み方ができる。ただし README には具体的なスループット値もレイテンシ値も載っていない。性能を判断する材料はここにはない。

インストールから起動までに登場する実ファイル

前提は Linux と Python 3.10 から 3.12 である。README のバッジにも python-3.10 と os-linux が表示されており、Windows や macOS での利用は想定されていない。

インストール手順はハードウェアごとに文書が分かれている。NVIDIA GPU なら docs/zh/get_started/installation/nvidia_gpu.md、昆仑芯 XPU なら kunlunxin_xpu.md、天数 CoreX なら iluvatar_gpu.md、燧原 S60 なら Enflame_gcu.md、海光 DCU なら hygon_dcu.md、沐曦なら metax_gpu.md、Intel Gaudi なら intel_gaudi.md を参照する形になっている。つまり pip install 一発の共通手順は用意されておらず、最初に自分のハードウェアに対応するファイルを開く必要がある。

起動後の使い方は docs/zh/get_started/quick_start.md に「10 分快速部署」としてまとまっている。オンラインサービングは docs/zh/online_serving/README.md、オフライン推論は docs/zh/offline_inference.md が入口である。運用で効いてくる設定は個別の文書に分かれていて、量化は docs/zh/quantization/README.md、分離式デプロイは docs/zh/features/disaggregated.md、投機デコードは speculative_decoding.md、プレフィックスキャッシュは prefix_caching.md、分塊預填は chunked_prefill.md、負荷分散スケジューラは docs/zh/online_serving/router.md、グローバルキャッシュプーリングは global_cache_pooling.md にある。router.md がオンラインサービング配下に置かれている点は、PD 分離構成でルーティングが任意機能ではなく前提部品であることを示している。

API 面では OpenAI 互換のサーバを単一コマンドで立てられ、vLLM のインタフェースとも互換だと README は述べている。既存のクライアントコードをそのまま向けられる可能性がある一方、互換の範囲がどこまでかは README からは分からない。個別のエンドポイント挙動は online_serving の文書で確認する必要がある。

量化形式の広さと、その広さが意味する運用負荷

README は対応する量化形式として W8A16、W8A8、W4A16、W4A8、W2A16、FP8 を挙げている。重み 2 ビットまで含む一覧は珍しく、VRAM に収まらないモデルを動かす選択肢としては幅がある。v2.5 では W4AFP8 が追加されたとリリースノートにある。

ただし形式が多いことは、どの形式を選ぶかの判断が利用者側に残ることを意味する。W4A8 と W4AFP8 はどちらも 4 ビット重みだが、活性化の扱いが異なる。精度への影響はモデル依存で、README には形式ごとの精度差も速度差も示されていない。量子化済みチェックポイントを自前で用意するのか、配布されたものを読むのかによっても話は変わる。この判断はドキュメントを読んだだけでは下せない。

もう一点、量化はハードウェアと切り離せない。FP8 を扱えるアクセラレータと扱えないアクセラレータでは、同じ形式名でも経路が違う。対応ハードウェアの一覧が長いぶん、形式とハードウェアの組み合わせ表が欲しくなるが、README にはそれが見当たらない。導入検討時には、自分のハードウェア向けインストール文書と量化文書の両方に目を通す必要がある。

向かないケース: モデル追随速度とプラットフォーム制約

第一の制約はモデル対応である。FastDeploy が確実に動かせるのは、docs/zh/supported_models.md に載っているモデルと、そこで案内されている形式の重みに限られる。リリースノートを見ると、v2.3 で ERNIE-4.5-VL-28B-A3B-Thinking と PaddleOCR-VL-0.9B、v2.4 で DeepSeek V3 と Qwen3-MoE、v2.5 で Qwen3-VL と Qwen3-VL MoE が追加されている。追加のペースは四半期ごとである。

これは裏返すと、公開直後のモデルを翌週に動かしたい用途には合わないということだ。モデルを次々に差し替えて比較する研究用途や、Hugging Face の新着を追いかける評価環境では、対応を待つ時間がそのまま機会損失になる。v2.2 で Hugging Face 形式のモデル互換が入ったとあるが、互換が全モデルを意味するわけではない。

第二の制約はプラットフォームである。Linux 前提、Python 3.10 以上という条件は、古いディストリビューションや Python 3.8 で組まれた既存の推論基盤ではそのまま満たせない。開発者が Windows 上でコードを書き、Linux に配備する流れなら問題は小さいが、ローカルで試したい段階では選択肢が狭まる。

第三に、PD 分離は構成を複雑にする。prefill 用と decode 用のインスタンスを別々に立て、KV キャッシュの転送経路を用意し、router で振り分ける。単一 GPU で小規模に動かすなら、この構成を取る理由はほとんどない。README は分離構成を主要機能として前面に出しているが、それは大規模サービングを想定した読者に向けた記述であって、すべての利用者に必要な構成ではない。

vLLM との差分はどこにあるのか

比較対象として最も自然なのは vLLM である。FastDeploy 自身が vLLM のインタフェース互換を掲げ、謝辞でも vLLM の一部コードを参考にしたと明記している。API の形を揃えることで、クライアント側の移行コストを下げる狙いが読み取れる。

両者の違いは、どのモデルとどのハードウェアを主戦場にするかにある。vLLM は幅広いモデルの取り込みを継続的に進める方向に力を割いており、FastDeploy は PaddlePaddle のモデル群、とくに ERNIE 系と PaddleOCR-VL を軸に据えている。topics に ernie、ernie-45、ernie-45-vl が並んでいるのはその表れである。PaddlePaddle で学習したモデルをそのまま配備したい場合、重み形式の変換を挟まずに済む経路が FastDeploy 側に用意されている可能性が高い。

ハードウェアの面では、昆仑芯、海光、天数、燧原、沐曦といったアクセラレータを README が明示している点が vLLM との差になる。NVIDIA 以外のカードを調達している組織では、この対応リストが選定理由そのものになる。

一方で、vLLM 側の利点は周辺の蓄積である。量子化手法、分散構成、ベンチマークの公開範囲、サードパーティのツール連携といった領域では、vLLM の方が参照できる情報が多い。FastDeploy の README には性能数値が一切載っておらず、この点は導入判断の材料として物足りない。互換 API を掲げるなら、互換の範囲と既知の差分を明示する文書があるとよいのだが、README からは確認できない。

更新コストと Apache-2.0 の及ぶ範囲

リリース間隔はおよそ 2 から 3 か月である。v2.3 が 2025 年 11 月、v2.4 が 2026 年 1 月、v2.5 が 2026 年 4 月で、v2.5 には 170 件以上のバグ修正と性能改善が含まれるとリリースノートにある。デフォルトブランチは develop で、更新は継続している。

この頻度は、固定バージョンで長期運用するチームにとっては追従コストになる。とくに PD 分離のようにインスタンス間のプロトコルを含む機能は、片側だけ更新すると噛み合わなくなる可能性がある。prefill 側と decode 側を同じバージョンに揃えて更新する運用が前提になると考えておいた方がよい。逆に、四半期ごとにまとめて上げる運用なら、リリースノートがそのまま差分の一覧として使える。

ライセンスは Apache-2.0 である。商用利用や改変、再配布が許容される条項を含むが、vLLM 由来のコードを参考にしていると README が述べている以上、派生物を配布する場合は著作権表示とライセンス文書の同梱が必要になる。ここで注意したいのは、FastDeploy 本体のライセンスと、読み込むモデル重みのライセンスは別物だという点である。ERNIE 系や Qwen 系の重みには独自の利用条件が付くことがあり、Apache-2.0 はそれを覆わない。配布物を組む前に、モデル側の条件を別途確認する必要がある。これは法的助言ではないので、実際の判断は自組織の基準で行ってほしい。

編集部の結論

採用を検討すべきなのは、ERNIE 系モデルを自前の推論基盤で動かしており、NVIDIA 以外の国産アクセラレータを含む複数ハードウェアを同じ運用に載せたいチームである。逆に、モデル選定を Hugging Face の最新モデル追随に合わせている場合や、Python 3.10 未満の既存環境、Windows 上での開発を前提にしている場合は、このツールキットは噛み合わない。導入前に確認すべきは 3 点ある。第一に、対象モデルが docs/zh/supported_models.md に載っているか。第二に、利用予定ハードウェア向けのインストール手順 (docs/zh/get_started/installation/ 配下) が存在するか。第三に、vLLM 互換を前提とした既存クライアントが router 経由のエンドポイントでそのまま動くかである。この 3 点が埋まらない限り、FastDeploy を選ぶ理由は「PaddlePaddle 資産との接続」以外に薄い。

公式情報源

1. License: Apache-2.0
2. PaddlePaddle/FastDeploy on GitHub
3. Project website
4. README
5. Releases