テック解説半導体AI投資

MangoBoostのDPUは何をオフロードするか：RoCEとNVMeの境界を検証

MangoBoostのBoostXを製品資料とSDKで確認し、RoCE AI、NVMe/RDMA target、GPU間P2Pを別の経路として整理する。400GbEの理論転送下限を再計算し、CPU削減とGPU性能向上を混同しない評価表を示す。

25th Sep 2026
CPU、DPU、GPU、NVMe間のデータ経路と400GbEの理論転送下限を示す図

MangoBoostのBoostXを製品資料とSDKで確認し、RoCE AI、NVMe/RDMA target、GPU間P2Pを別の経路として整理する。400GbEの理論転送下限を再計算し、CPU削減とGPU性能向上を混同しない評価表を示す。

Sponsored affiliate banner

「MangoBoost DPUがCPUを解放してGPUを速くする」と読むと、ネットワークとストレージのどちらで待ち時間が減るのかが曖昧になる。私が今回確かめたかったのは、製品の宣伝文句を実際のデータ経路へ戻せるかという点だ。2026年9月25日時点の製品ページとSDKを照合し、経路ごとに確認する。

要点読者が確認できること
製品の境界BoostX RoCE AI、NRT、Baseは同じFPGA基盤の異なるカード
オフロードの境界RoCE AIはGPU間通信、NRTはNVMe/RDMA target。MLPerfの推論値からDPUの効果は単独では分からない
計算の境界400Gb/sは64GiB転送の理論下限を約1.37秒にするが、実効性能を保証しない

以前のAI半導体スタートアップ比較では、d-Matrix、TetraMem、MangoBoost、Enfabricaなどの企業群を並べ、DPUを「計算の外側」と分類した。本稿はその内側を、公開資料で再現できる範囲まで細分化する。MangoBoostを推論の中立レイヤーとして論じた記事の投資仮説も、まず何をオフロードする製品なのかを確定してから読みたい。

※本稿は各社の公開情報（発表資料・製品ページ・論文・報道）をもとにした、外部からの個人的な見立てです。

RoCE AIの公称400Gb/sとNRTの公称200Gb/sから計算した64GiB転送の理論下限。実測値ではない

「一つのDPU」ではなく三つの製品経路

現行のBoostX製品概要は、RoCE AI、NRT、Baseを同一のFPGA基盤を共有する別カードとして列挙する。RoCE AIはAIクラスタのRDMA通信、NRTはNVMe/RoCEv2 target、Baseはカスタムdataplane用だ。製品資料の「最大400GbE」は共通基盤のネットワークインターフェース上限であり、NRTの表示は200GbE。全製品で400Gb/sの実効速度が出るという意味ではない。

ここを分けると、CPUオフロードという言葉の主語がはっきりする。

経路公開資料で確認できる機能CPU/GPUについて言えることまだ確認できないこと
GPU ↔ RoCE AI ↔ GPUFPGAベースのRoCEv2、2×200GbE、GPUメモリへのP2P RDMAホストメモリを中継しない経路を構成できる個別ワークロードで節約したCPU時間、学習完了時間
NVMe ↔ NRT ↔ ネットワークNVMe-oF RDMA target、namespaceとlistenerの制御I/O dataplaneをカード側に置けるGPUまでの端から端の速度とCPU削減量
管理クライアント ↔ OPI bridgestorage APIのgRPC制御面作成・設定とI/O経路を分けられるnetworking/security APIの提供時期
LLMBoost ↔ MI300XMLPerf Inference v5.0への提出推論ソフトを含むシステム結果が存在するその結果の何割がDPUに由来するか

RoCE AIのSDK概要は2×200GbEとPCIe Gen5 x8を2本、GPU P2P対応を明記する。NRTの手動設定資料はtarget transportをRDMAに限定し、subsystemごとのI/O queueのデフォルトを32とする。これらは異なる用途の仕様であり、数字を一つの「DPU速度」として合算できない。

Sponsored affiliate banner

400GbEから分かるのは転送時間の下限だけ

帯域の最大値を記事で使うなら、同じ単位に戻してから議論したい。64GiBのデータを、プロトコル overheadも混雑もゼロという仮定で移す場合の下限を計算する。これは私の計算で、MangoBoostの実測値ではない。

gib = 64
bytes_to_move = gib * 1024**3
for link_gbps in (200, 400):
    seconds = bytes_to_move * 8 / (link_gbps * 1_000_000_000)
    print(f"{link_gbps} Gb/s: {seconds:.3f} s minimum")

結果は200Gb/sで約2.749秒、400Gb/sで約1.374秒。帯域を2倍にすると、この単純な転送下限は半分になる。一方、実際の転送にはEthernet/RDMA overhead、PCIe、SSDやGPUメモリ、packet loss、輻輳制御が入る。複数ノードのジョブ全体には演算と同期もあるため、ジョブ時間が半分になるという推論は成り立たない。

また、GPU統合のSDK説明は重要な留保を付けている。同ページに載る実験結果の多くは旧RNICプラットフォームで得られ、BoostX RoCE AIの測定値へ今後更新予定だという。掲載の帯域グラフを現行カードの確定性能として引用しない。

Sponsored affiliate banner

実装で確認する順番：経路、計測、対照群

SDKが示すP2P経路には前提がある。GPUとRoCE AIカードを同じPCIe switchの下に置き、ドライバーとGPU側のメモリ登録条件を満たす必要がある。SDKによれば、NVIDIA GPUではnvidia-peermemが必要で、AMD GPUではROCmRDMAの経路を使う。ACSの設定もP2Pに影響するが、検証環境での変更は運用管理者が安全性と分離要件を確認して判断すべきだ。ここでは設定変更を実行したとは主張しない。

比較実験を組むなら、カードを入れた構成と対照構成でGPU、CPU、SSD、switch、ドライバー、モデル、batch size、payload、並列数を揃える。最低限、次を同時に記録する。

  1. RDMA P2Pが成立したか。perftestのGPU bufferテストとNCCL/RCCLログで経路を確認する。
  2. 同じpayloadでthroughput、p50/p99 latency、CPU core-secondsを測る。
  3. storage workloadならNRT targetのI/O queue、SSD台数、namespace、listenerを記録する。
  4. 最後に学習または推論ジョブの完了時間とGPU idle比率を比較する。

この順序なら「NICの公称帯域」と「GPUジョブの改善」を飛躍なく接続できる。CPU使用率だけが下がりジョブ時間が変わらない場合も、DPUの役割はCPU余力や分離にあるかもしれない。逆にジョブが速くなっても、ストレージ・ネットワーク・推論ソフトのどの変更が効いたかは、単一要因の対照試験がなければ不確実だ。

Sponsored affiliate banner

公開ベンチマークを読むときの落とし穴

MLCommonsのInference v5.0結果にはMangoBoostのMI300X/LLMBoost提出がある。これは提出条件下のシステム結果を確認する一次資料だ。しかし提出名はDPUを単独で比較したA/B試験ではない。「MLPerfの値＝BoostXが生んだ改善」とは読めない。GPU数、モデル、scenario、software stackをそろえない他社行との単純な倍率比較も避ける。

もう一つは「セキュリティも今すべてオフロード済み」という読み違い。MangoBoostのOPI bridge資料は、OPI APIで現在カバーするのはstorageで、networkingとsecurityはplannedと記す。この記述はOPIの公開API範囲についてであり、会社全体の製品機能が存在しないことまで証明しない。確認できた範囲をそこで止める。

現時点で最も堅い結論は、BoostXがFPGA基盤の実際のハードウェアカードで、RoCE通信とNVMe targetの異なる経路を扱うことだ。CPU削減、GPU稼働率、費用対効果は、ワークロードと対照群を定義して初めて比較できる。製品説明から投資判断までの間には、測定の一段が残っている。

なお、同じFPGA基盤でもファームウェア、PCIe配置、SSD構成、software stackが変われば結果は変わる。評価表には製品名だけでなくカード型番と測定環境を残したい。これを省くと、後から別の構成で再測定しても改善の原因を追えない。

参考資料

次号の記事案

  • RoCEの輻輳制御を検証する — 同じpayloadとfan-inでp99 latencyを測り、packet sprayingの効果と限界を切り分ける。
  • NVMe-oF targetのqueue budgetを設計する — subsystem、queue、SSD台数を固定した再現可能な負荷試験を組む。
  • GPU idle時間の測定表を作る — DPU導入前後でnetwork、storage、compute待ちを別々に記録する。

本稿は情報提供を目的とし、特定銘柄の売買を推奨しません。生成AIの支援を受けて作成し、公開一次資料を確認しました。詳細は免責事項をご覧ください。

Sponsored affiliate banner