In Silico

シミュレーション・制御・実機

MuJoCo WarpはなぜJAX版MJXより大きな場面を回せるのか

2026/9/30

🤖 AIが執筆しています

目次
※ 概念図（比較：接触の数え方）・作図：AI 【個数を揃える（JAX実装）】 どの世界も同じ個数を生成する 例：40＋40＋40＝120 → 物体を足すと全世界で増える 多くのハードウェアで動く・微分に対応 【世界ごとに変える（Warp実装）】 起きている個数だけ生成する 例：2＋5＋40＝47 → 上限は全世界の合計で決める NVIDIA GPU専用・微分は未対応
※ 概念図（比較：接触の数え方）・作図：AI。三つの世界で起きている接触が2個・5個・40個のとき、個数を揃える方式と世界ごとに変える方式が生成する接触の数を比べた図である。数は説明のために作った例であり、本文で引く各一次資料そのものの主張ではない。
背景

ロボットの動かし方を強化学習で学習させるには、大量の試行が要る。実機だけでは試行の数が足りないので、GPU の上で物理シミュレーションを数千個同時に進めて試行を集める。同時に進めるシミュレーションの一つひとつを、MuJoCo の文書は世界（world）と呼ぶ。MuJoCo は Google DeepMind が保守する物理シミュレータで、その GPU 向け API である MJX には、JAX 実装と Warp 実装の二つがある。作り手は、中規模から大規模の場面には Warp 実装を勧めている12。

問い

Warp 実装は、なぜ JAX 実装より大きな場面を速く計算できるのか。

要点

作り手の説明によると、JAX 実装はどの世界でも同じ個数の接触を生成しなければならず、Warp 実装は世界ごとに、実際に起きている個数だけ接触を生成できるからである2。 JAX 実装が生成する個数は、場面で起こりうる接触の数で決まるので、場面に物体を足すと、接触の少ない世界でも計算が増える。Warp 実装も接触の上限を前もって決めるが、上限は全世界の合計に対して置ける3。物体の操作を学習する環境の多くで、Warp 実装は単位時間あたりに進むステップ数が1.5〜2倍になった2。代わりに Warp 実装は、高速に動く GPU が NVIDIA 製に限られ、自動微分に対応していない41。

三つの世界で接触を数えると、二つの方式の差が分かる

この節の数は説明のために作った例であり、測定値ではない。

接触は、物体どうしが触れている箇所である。シミュレータは1ステップごとに、触れている箇所を調べて接触の一覧を作る。これを接触の生成と呼ぶ。続いて、接触の一つひとつについて、物体がめり込まないための力を計算する。生成する接触が多いほど、1ステップの計算は増える。

三つの世界を同時に進める。この場面で起こりうる接触は、最大で40個とする。ある時点で実際に起きている接触の数は、世界ごとに違う。

この三つの世界を計算する方式は、二つある。

方式三つの世界で生成する接触の数
個数を揃える40 ＋ 40 ＋ 40 ＝ 120
世界ごとに変える2 ＋ 5 ＋ 40 ＝ 47

個数を揃える方式は、どの世界でも同じ個数の接触を生成する。その個数は、起こりうる接触を収められる数にする。例では40個である。世界1で実際に起きている接触は2個だが、40個分を生成する。残りの38個分は、実際には触れていない。

世界ごとに変える方式は、実際に起きている個数だけ接触を生成する。ただし、接触を入れる枠の大きさ（上限）は、この方式でも前もって決める。計算量は上限にも応じて増える。上限の置き方は、後の節で同じ例を使って数える。

この例から、次の三つの性質が分かる。

  1. 個数を揃える方式が生成する接触の数は、世界の数と、起こりうる接触の数の積で決まる。実際に起きている接触の数は関係しない。
  2. 場面に物体を足すと、起こりうる接触の数が増える。個数を揃える方式では、接触の少ない世界も含めて、すべての世界で生成する個数が増える。
  3. どの世界でも接触が少数で、その数が変わらない場面では、二つの方式が生成する個数はほとんど変わらない。

JAX 実装は個数を揃える方式で、Warp 実装は世界ごとに変える方式である。次の節では、作り手の説明と実測が、この三つの性質と矛盾しないことを確かめる。

作り手の説明と実測は、三つの性質と矛盾しない

Warp 実装は、MJX の API から MuJoCo Warp（以下 MJWarp）を呼ぶ2。MJWarp は Google DeepMind と NVIDIA が保守する MuJoCo の GPU 版で、NVIDIA の Warp で書かれている4。Warp は、GPU で実行する関数を書くための枠組みである5。

性質1について、作り手は JAX 実装が個数を揃える理由を、GPU でのプログラムの動かし方で説明している。MuJoCo Playground は DeepMind の学習環境集である。その告知によると、JAX 実装では、1ステップごとに固定の個数の接触を生成するしかなかった。Warp は NVIDIA GPU を対象にしているので、GPU の中で並列に動く処理の一つひとつが、条件分岐で別々の処理へ進むプログラムを書ける。その結果、1ステップごとに個数の変わる接触を生成できるようになった2。

すべての世界が同じ処理を実行するなら、計算する接触の個数も全世界で同じになる。世界ごとに別の処理へ進めるなら、個数を世界ごとに変えられる。

性質2と矛盾しない実測は、MJX の文書にある。humanoid（人型のモデル）の数を1体から10体まで増やすと、場面で起こりうる接触の数が増える。このとき JAX 実装のスループット（単位時間あたりに進むシミュレーションのステップ数）は、CPU で動く MuJoCo より急に落ちる1。文書はこの低下を、GPU や TPU が条件分岐を苦手とすることに結び付けている。衝突しうる物体の組を絞り込む処理は条件分岐を使うので、JAX 実装はこの処理を CPU の MuJoCo ほどうまく行えない1。この実測は、どの世界も同じ体数の場面で測っている。接触の少ない世界が混ざる場面を測ったものではない。

JAX 実装の利用者は、衝突を調べる物体の組を指定して、生成する個数を減らせる1。

性質3と矛盾しない記述は、Playground の告知にある。JAX 実装は、衝突が少数で固定の場面や、球や箱のような単純な形どうしの衝突なら性能が良い。Warp 実装は、中規模から大規模の場面でよりよくスケールする2。Playground の操作環境の多くでは、Warp 実装のスループットが1.5〜2倍になった2。MJWarp の文書も、ほぼすべてのワークロードで MJX よりよくスケールし、複雑な場面で特にそうだと書く3。

作り手が挙げる Warp 実装の利点は、接触の個数だけではない。MJX の文書は、メッシュ（三角形の網で表した物体の表面）どうしの衝突に Warp 実装が全面的に対応している点も挙げる1。Playground の告知が Warp 実装を勧めるのも、メッシュどうしの衝突が中程度から多数ある環境である2。本稿は、このうち接触の個数だけを説明している。

JAX 実装から Warp 実装へ切り替えたときの違いも、告知は書いている。報酬の挙動は、JAX 実装と比べて「良好な一致」を得た。ただし PandPick 系と AlohaSinglePeg の環境では、報酬にわずかな回帰が残ると断っている2。

Warp実装の接触の上限は、世界どうしで融通できる

Warp 実装でも、接触の個数に上限を決める。GPU のメモリを前もって確保する必要があるからである。文書は「メモリと計算量はこれらのパラメータの値に応じて増える」と書き、上限をできるだけ小さく設定するよう勧める3。上限が費用になる点は、JAX 実装と Warp 実装に共通である。

JAX 実装との違いは、接触の上限を全世界の合計に対して置く点にある。文書は、全世界の接触の合計が nworld × nconmax を超えなければ、一つの世界の接触の数は nconmax を超えてよいと書く3。nworld は世界の数、nconmax は世界あたりの接触の見込みの数である。接触の上限は、全世界の合計の nworld × nconmax になる。MJX から Warp 実装を呼ぶときは、この合計を naconmax として直接渡す1。

先の例に当てはめる。nconmax を16にすると、全世界の合計の上限は 3 × 16 ＝ 48 になる。実際の接触の合計は47なので、上限に収まる。世界3の接触は40個で、世界あたりの見込みの16を超えている。それでも、世界1と世界2が使わなかった枠を世界3が使える。個数を揃える方式では、接触の枠が 40 × 3 ＝ 120 要る。

融通できるのは接触の枠だけである。シミュレータは接触ごとに、物体がめり込まないという条件を立てる。この条件を拘束（constraint）と呼ぶ。拘束の上限 njmax は世界ごとに決まっていて、ほかの世界の枠は使えない3。例では、世界3の40個の接触から生じる拘束を収められる njmax を決めると、同じ大きさの枠が世界1と世界2にも確保される。拘束については、Warp 実装でも個数を揃える方式と同じことが起きる。接触と拘束で扱いが違う理由を、文書は書いていない。

上限を超えると未定義動作になり、超過は世界ごとに Data.overflow に記録される3。新しい場面では、ビューアで読み込み、超過が出るたびに上限を上げて調整する1。

Warp 実装には、動いていない物体を計算から外す機構もある。スリープは「静止した物体を眠らせる」機構である3。場面の大きさは自由度で測る。自由度は、関節や物体が独立に動ける方向の数である。文書は、スリープを有効にし、場面を休止中の物体を含む独立した部分に分割できる限り、MJWarp は数百自由度の場面までスケールできると書く3。

Warp実装はNVIDIA専用で、自動微分に対応していない

Warp 実装には、JAX 実装に無い制約が五つある。最初の二つは、Warp 実装を使えるかどうかを決める。残りの三つは、用途によって問題になる。

高速に動くのは NVIDIA GPU だけである。 JAX 実装は、NVIDIA と AMD の GPU、Apple Silicon、Google Cloud TPU で動く1。JAX と、JAX が使うコンパイラの XLA の上に書かれているからである1。MJWarp の README は「高速なシミュレーションには NVIDIA GPU を要するが、開発とデバッグのために CPU にも対応する」と書く4。世界ごとに個数を変える仕組みは、NVIDIA GPU が条件分岐で別々の処理へ進めることを使っているので2、Warp が NVIDIA を対象にする限り、この制約は続く。

自動微分に対応していない。 自動微分は、シミュレーションの出力を入力で微分した値（勾配）を自動で求める機能である。JAX 実装は、自動微分に「おおむね対応している」1。Warp 実装について、MJX の文書は「MJX-JAX と異なり、MJX-Warp は自動微分に対応せず、対応する当面の計画もない」と書く1。ただし、リポジトリでは実装が進んでいる。自動微分を扱う issue #500 で、NVIDIA で Warp と Newton を担当するプロダクトマネージャが2026年8月4日に「この機能要望には積極的に取り組んでいる」と書き、実装の PR #1535 を示した。この PR は2026年9月19日時点で未マージである6。Warp 自体のカーネルは微分可能である5。この制約が続くかどうかは、まだ決まっていない。

1ステップにかかる時間は短くならない。 MJWarp の文書は「MJWarp はスループット、すなわち単位時間あたりのシミュレーションステップの総数に最適化されており、MuJoCo は遅延、すなわち一ステップにかかる時間に最適化されている」と書く3。モデル予測制御やテレオペレーションのように、1ステップの遅延が問題になる用途には、文書は CPU の MuJoCo を勧める3。

一続きの大きな機構では、CPU の MuJoCo ほど伸びない。 一続きの機構は、人型ロボットの全身のように、関節でつながった物体の集まりである。文書は、物体や自由度の多い場面では MJWarp が JAX 実装よりよくスケールするが、一続きの大きな機構では CPU の MuJoCo ほどはスケールしないと書く3。約60自由度を超える一続きの機構の性能改善を、文書は優先課題に挙げている3。

JAX から呼ぶと、直接呼ぶより遅くなる。 MJX の文書の表では、Humanoid の場面で、Warp を直接呼ぶと毎秒3.35M（M は百万）ステップ、JAX から呼ぶと2.96M である1。低下は一割強である。

使い分けは、場面の大きさと必要な機能で決まる

三つの性質と五つの制約から、使い分けは次のようになる。

MJX の文書も同じ振り分けを書いている。「小さな場面で性能が出て、勾配におおむね対応するシミュレータを求める利用者には、MJX-JAX がよい選択である。それ以外の利用者は MJX-Warp へ向ける」1。JAX 実装は MJX から外されていない。Playground の Warp 対応はベータで、環境を作るときに impl='warp' を渡して選ぶ2。

MJWarp を使う動きは、MJX の外にもある。物理エンジンの Newton は、MJWarp を主バックエンドとして統合した7。NVIDIA の Isaac Lab は、3.0のベータ（2026年3月）で、既定の PhysX に加えて、MJWarp で動く Newton を選べるようにした8。学習用の枠組みである mjlab も、GPU の物理計算に MJWarp を使う9。

ほかの並列シミュレータを読むときも、三つの世界の例が使える。世界ごとに違う量を、全世界で同じ個数として計算しているのか、世界ごとの個数で計算しているのかを見る。前者なら、場面を大きくすると全世界の計算が増えるので、物体の多い場面には向かない。

出典9件

  1. MuJoCo Documentation, “MuJoCo XLA (MJX)“（2026年9月19日取得）。MJX の公式文書である。「MJX は、XLA コンパイラが対応するあらゆる計算ハードウェアで MuJoCo を走らせることを可能にする」(“MJX allows users to run MuJoCo on all compute hardware supported by the XLA compiler.”)、「MJX-JAX は NVIDIA と AMD の GPU、Apple Silicon、Google Cloud TPU で動く」(“MJX-JAX runs on: Nvidia and AMD GPUs, Apple Silicon, and Google Cloud TPUs.”)、「MuJoCo の Warp 実装（MJX-Warp）は NVIDIA GPU に特化して性能を最適化し、MJX-JAX が示すいくつかの性能ボトルネックを解決する」(“A Warp implementation of MuJoCo (MJX-Warp) optimizes performance specifically for NVIDIA GPUs, resolving several performance bottlenecks exhibited in MJX-JAX.”)、「MJX は現在、MuJoCo の二つの実装に対応する。純粋な JAX 実装と、Warp 実装である」(“MJX currently supports two implementations of MuJoCo: a pure JAX and a Warp implementation.”)、「MJX-Warp は MuJoCo Warp を使う。ハードウェア加速デバイス向けの、最も機能の揃った MuJoCo 実装である。MJX-Warp は MJX-JAX が示す接触と拘束まわりの主要な性能ボトルネックを解決する」(“MJX-Warp uses MuJoCo Warp, the most fully-featured implementation of MuJoCo for hardware accelerated devices. MJX-Warp resolves key performance bottlenecks exhibited in MJX-JAX around contacts and constraints.”)、「naconmax は、最終的に jax.vmap で必要になる環境数に合わせてスケールせよ」(“Scale naconmax by the number of environments you’ll eventually need in a jax.vmap!”)と書く。後段は留保として引く。「MJX-JAX と異なり、MJX-Warp は自動微分に対応せず、対応する当面の計画もないことに注意」(“Note that unlike MJX-JAX, MJX-Warp does not support automatic differentiation and has no immediate plans to support auto-diff.”)、「Warp/CUDA は安定したポインタを要求するため、入力と出力のバッファのポインタが変わると CUDA グラフは再捕捉される」(“Since Warp/CUDA require stable pointers, CUDA graphs will be re-captured if the input and output buffer pointers change.”)と書き、性能の表は Humanoid と Aloha Pot の二列で、Pure Warp (No JAX FFI) 3.35M／2.45M、JAX FFI (WARP) 2.96M／2.33M、forced recaptures 0.80M／0.65M、WARP_STAGED 2.67M／1.96M（Steps per Second）を載せる。機能表の脚注は「微分可能性は MJX-JAX ではおおむね対応しているが、MJX-Warp では現在利用できない」(“Differentiability is mostly supported in MJX-JAX but is not currently available in MJX-Warp.”)と書く。§MJX-JAX は「MJX-JAX は、JAX フレームワークを通じて、XLA コンパイラが対応するあらゆる計算ハードウェアで MuJoCo を走らせることを可能にする（AMD GPU、Apple Silicon、Google Cloud TPU）」(“MJX-JAX allows MuJoCo to run on all compute hardware supported by the XLA compiler via the JAX framework (AMD GPUs, Apple Silicon, and Google Cloud TPUs).”)、「小さな場面で性能が出て、勾配におおむね対応するシミュレータを求める利用者には、MJX-JAX がよい選択である。それ以外の利用者は MJX-Warp へ向ける」(“For users looking for a simulator that is performant for small scenes and that roughly supports gradients, MJX-JAX is a good option. We point users to MJX-Warp otherwise.”)と書き、§The Sharp Bits は「アクセラレータは分岐のあるコードの性能が悪い。分岐は broad-phase の衝突検出で使われる」(“Accelerators exhibit poor performance for branching code. Branching is used in broad-phase collision detection”)、「humanoid の体数を1から10まで変えた物理場面を考える」(“a physics scene with increasing numbers of humanoid bodies, varied from 1 to 10”)、「humanoid の数を増やす（場面の潜在的な接触数が増える）につれて、MJX-JAX のスループットは MuJoCo より急速に低下する」(“as we increase the number of humanoids (which increases the number of potential contacts in a scene), MJX-JAX throughput decreases more rapidly than MuJoCo.”)と書く（MuJoCo 側は CPU で計時）。https://mujoco.readthedocs.io/en/stable/mjx.html ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14

  2. MuJoCo Playground Discussion #197 ”📣 MuJoCo Playground works with MuJoCo Warp! 📣 (in Beta)“（btaba、2025年8月28日）。「Warp は NVIDIA GPU を特に対象にしており、それがスレッド分岐のあるコード（SIMT）を可能にする。つまり、物理ステップごとに動的な数の接触と拘束を生成できるようになった。以前の JAX では、ステップごとに固定数の接触／拘束を生成せざるを得なかった（SIMD）」(“Warp is targeted specifically to NVIDIA GPUs, which enables thread divergent code (SIMT). That means we can now generate a dynamic number of contacts and constraints per physics step. Previously in JAX, we were forced to generate a fixed number of contacts/constraints per step (SIMD).”)、「tl;dr MuJoCo Warp によって、MuJoCo の GPU シミュレーションをずっと大きな場面へスケールできる」(“tl;dr MuJoCo Warp allows us to scale MuJoCo GPU simulation to much larger scenes!”)、「MuJoCo の JAX 実装と比べて報酬の挙動は良好な一致を得ている」(“we have good parity in terms of reward behavior compared to the MuJoCo JAX implementation”)、「MJX-Warp は単に MJX を MuJoCo Warp に接続したものだ」(“MJX-Warp is simply MJX hooked up to MuJoCo Warp.”)、「JAX は少数の固定衝突とプリミティブ衝突では性能が良いが、Warp は中規模から大規模の場面でずっとよくスケールする」(“JAX is performant for a small number of fixed collisions and primitive collisions, but Warp scales much better for medium to large scenes.”)、「Playground の操作環境の多くは Warp で1.5〜2倍高いスループットを得る」(“many of the Playground manipulation environments have 1.5-2x higher throughput with Warp”)、「PandPick* と AlohaSinglePeg の環境は MuJoCo Warp でわずかな回帰がある」(“PandPick* and AlohaSinglePeg environments have slight regressions with MuJoCo Warp.”)、「pmap 対応は MJX-Warp ではまだ利用できない」(“pmap support is not yet available with MJX-Warp.”)と書く。Playground のスターは2026年9月19日時点で2,216である（GitHub API 調べ）。https://github.com/google-deepmind/mujoco_playground/discussions/197 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11

  3. MuJoCo Documentation, “MuJoCo Warp (MJWarp)“（2026年9月19日取得）。MJWarp の公式文書である。「MJWarp は NVIDIA と Google DeepMind の共同の取り組みとして開発・保守されている」(“MJWarp is developed and maintained as a joint effort by NVIDIA and Google DeepMind.”)、「mujoco_warp.step：NVIDIA GPU を対象とする高スループットシミュレーションの Python API。ほぼすべてのワークロードで MJX よりよくスケールし、特に複雑なシミュレーション場面で」(“mujoco_warp.step: Python API for high throughput simulation targeting NVIDIA GPUs. Scales better than MJX on nearly every workload, in particular complex simulation scenes.”)、「全世界の接触の合計が nworld × nconmax を超えなければ、世界あたりの接触数が nconmax を超えることは可能である。ただし世界あたりの拘束数は njmax で厳密に制限される」(“It is possible for the number of contacts per world to exceed nconmax if the total number of contacts for all worlds does not exceed nworld x nconmax. However, the number of constraints per world is strictly limited by njmax.”)、「MJWarp は静止した物体を眠らせることができる」(“MJWarp can put stationary objects to sleep”)、「これらの活性自由度を、既知の最大サイズ（nvmax）を持つ単一の連続した密な作業領域に詰める」(“Compacts these active DOFs into a single, contiguous dense workspace of a known maximum size (nvmax).”)、「固定サイズに詰めた作業領域を使うことで、ソルバは GPU のスレッド分岐を避け、固定タイルサイズ向けに最適化された高性能なテンソル／行列演算を活用する」(“By using a fixed-size compacted workspace, the solver avoids GPU thread divergence and leverages high-performance tensor/matrix operations optimized for fixed tile sizes.”)、「メモリと計算量はこれらのパラメータの値に応じて増える。最良の性能のためには、シミュレーションがこれらの上限を超えないことを確保しつつ、これらのパラメータの値をできるだけ小さく設定すべきである」(“Memory and computation scales with the values of these parameters. For best performance, the values of these parameters should be set as small as possible while ensuring the simulation does not exceed these limits.”)、「シミュレーションの要求がこれらの事前確保した上限を超えると overflow が起こり、未定義動作につながる」(“When simulation demands exceed these pre-allocated limits, an overflow occurs, leading to undefined behavior.”)、「MJWarp は overflow を世界ごとに Data.overflow で追跡する」(“MJWarp tracks overflows per world in Data.overflow”)、「mujoco.rollout：CPU 上で mj_step をマルチスレッドで呼ぶ Python API」(“mujoco.rollout: Python API for multi-threaded calls to mj_step on CPU.”)、「MJX の dynamics API は JAX を通じて自動微分できる。MJWarp で Warp を通じてこれに対応するかどうかを検討している」(“The dynamics API in MJX is automatically differentiable via JAX. We are considering whether to support this in MJWarp via Warp”)と書く。後段は留保として引く。「MJWarp はスループット、すなわち単位時間あたりのシミュレーションステップの総数に最適化されており、MuJoCo は遅延、すなわち一ステップにかかる時間に最適化されている」(“MJWarp is optimized for throughput: the total number of simulation steps per unit time whereas MuJoCo is optimized for latency: time for one simulation step.”)、「MJWarp は多数の geom や自由度を持つ場面では MJX よりよくスケールするが、単一の大きな運動学的木では MuJoCo ほどはスケールしない」(“MJWarp scales better than MJX for scenes with many geoms or degrees of freedom, but not as well as MuJoCo for single large kinematic trees.”)、「スリープが有効で、場面が休止中の物体を含む独立の島に分割できる限り、MJWarp は数百自由度の場面までスケールできる」(“MJWarp can scale to scenes with hundreds of degrees of freedom as long as sleeping is enabled and the scene can be partitioned into independent islands with dormant bodies.”)、「約60自由度を超える単一の連結機構の性能改善は、活動中の優先課題であり続ける」(“Improving performance for single connected mechanisms beyond ~60 DoFs remains an active priority.”)と書く。§Solver iterations は「MJX ではこれらのソルバのパラメータがシミュレーション性能を制御する鍵である。対照的に MJWarp では、全世界が収束すればソルバは早期に抜けて不要な計算を避けられる。その結果、これらの設定の値が性能に与える影響は比較的小さい」(“In MJX these solver parameters are key for controlling simulation performance. With MJWarp, in contrast, once all worlds have converged the solver can early exit and avoid unnecessary computation. As a result, the values of these settings have comparatively less impact on performance.”)と書く。https://mujoco.readthedocs.io/en/latest/mjwarp/index.html ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12

  4. google-deepmind/mujoco_warp README（GitHub、2026年9月19日取得）。「MJWarp は、NVIDIA ハードウェア向けに設計された、MuJoCo 物理シミュレータの GPU 加速版である」(“MJWarp is a GPU-accelerated version of the MuJoCo physics simulator, designed for NVIDIA hardware.”)、「MJWarp は Newton プロジェクトの一部として Google DeepMind と NVIDIA が保守する」(“MJWarp is maintained by Google DeepMind and NVIDIA as part of the Newton project.”)、「MuJoCo Warp は高速なシミュレーションに NVIDIA GPU を要するが、開発とデバッグのために CPU にも対応する」(“MuJoCo Warp requires an NVIDIA GPU for fast simulation but supports CPU for development and debugging.”)と書く。留保として引く箇所は「Warp を通じた微分可能性はまだ利用できない」(“Differentiability via Warp is not yet available.”)である。未対応の機能として「IMPLICITFAST 中点積分器の機能は未対応」(“IMPLICITFAST midpoint integrator feature is not supported”)、「PGS と noslip はまだ未対応」(“PGS and noslip not yet supported”)、「PLUGIN 型はまだ未対応」(“PLUGIN types not yet supported”)、「Flex：実験的」(“Flex: experimental”)を列挙する。PyTorch 向けの選択肢として「Isaac Lab は Newton 経由で MJWarp を統合する」(“Isaac Lab integrates MJWarp via Newton.”)と mjlab の二つを挙げる。リポジトリは2025年3月17日に作られ、2026年9月19日時点のスターは1,481、MuJoCo 本体は同日時点で15,214である（GitHub API 調べ）。https://github.com/google-deepmind/mujoco_warp ↩ ↩2 ↩3

  5. NVIDIA, “Warp” README（GitHub リポジトリ NVIDIA/warp、2026年9月19日時点）。MJWarp の土台であるカーネル記述の枠組みの説明書で、「Warp のカーネルは微分可能で、PyTorch・JAX・Paddle のような枠組みと組み合わせて機械学習パイプラインの一部として使える」(“Warp kernels are differentiable and can be used as part of machine-learning pipelines with frameworks such as PyTorch, JAX and Paddle.”)と書く。MJX-Warp の自動微分未対応が土台の制約ではなく実装側の未着手であることを示す。リポジトリは2022年3月18日に作られ、2026年9月19日時点のスターは7,127である（GitHub API調べ）。https://github.com/NVIDIA/warp ↩ ↩2

  6. google-deepmind/mujoco_warp Issue #500 “Differentiability”（thowell が2025年7月13日に作成、2026年9月19日時点で open）。本文は Warp の differentiability 文書へのリンクである。スレッドの11件目（momo-van、2026年8月4日）は PR #1535 を指して「hybrid analytic differentiability。この機能要望には積極的に取り組んでいる」(“hybrid analytic differentiability. We are actively working on this feature request.”)と書き、投稿者の GitHub プロフィールは NVIDIA の Product Manager, Warp, Newton である。PR #1535（etaoxing、2026年7月19日作成、+10,662／−102 行）は2026年9月9日に「レビューの準備ができた」(“This is ready for a review now!”)と申告され、2026年9月19日時点で open・未マージである（https://github.com/google-deepmind/mujoco_warp/pull/1535）。留保として引くのは、文書が未対応と書く一方で、実装がリポジトリで進んでいることを示すからである。https://github.com/google-deepmind/mujoco_warp/issues/500 ↩

  7. newton-physics/newton README（GitHub、2026年9月19日取得）。「Newton は NVIDIA Warp の上に構築された GPU 加速の物理シミュレーションエンジンで、ロボット研究者とシミュレーション研究者を特に対象にする」(“Newton is a GPU-accelerated physics simulation engine built upon NVIDIA Warp, specifically targeting roboticists and simulation researchers.”)、「Newton は Warp の（非推奨になった）warp.sim モジュールを拡張し一般化し、MuJoCo Warp を主バックエンドとして統合する」(“Newton extends and generalizes Warp’s (deprecated) warp.sim module, and integrates MuJoCo Warp as its primary backend.”)、「Newton は、コミュニティが構築し保守する Linux Foundation プロジェクトである」(“Newton is a Linux Foundation project that is community-built and maintained.”)、「Newton は Disney Research、Google DeepMind、NVIDIA が始めた」(“Newton was initiated by Disney Research, Google DeepMind, and NVIDIA.”)と書く。リポジトリは2025年4月22日に作られ、2026年9月19日時点のスターは5,650である（GitHub API 調べ）。https://github.com/newton-physics/newton ↩

  8. isaac-sim/IsaacLab Release v3.0.0-beta（GitHub、2026年3月17日公開、2026年9月27日取得）。Isaac Lab 自身のリリースノートで、「Isaac Lab 3.0 は、ファクトリー方式のマルチバックエンド構成を導入する」(“Isaac Lab 3.0 introduces a factory-based multi-backend architecture”)と書き、物理のバックエンドとして「完全な PhysX バックエンド（既定）」(“Full PhysX backend (default)“)と、「MuJoCo-Warp で動く新しい Newton 物理バックエンドで、MJWarp・XPBD・Featherstone の各ソルバに対応する」(“New Newton physics backend powered by MuJoCo-Warp, supporting MJWarp, XPBD, and Featherstone solvers”)を並べる。起動例も Newton を選ぶ指定と既定の PhysX を並記する。留保として引くのは、Isaac Lab が MJWarp を取り込みつつ PhysX を既定に残していることを示すからである。https://github.com/isaac-sim/IsaacLab/releases/tag/v3.0.0-beta ↩

  9. Kevin Zakka, Qiayuan Liao, Brent Yi, Louis Le Lay, Koushil Sreenath, Pieter Abbeel, “mjlab: A Lightweight Framework for GPU-Accelerated Robot Learning”（arXiv:2601.22074、v1 2026年1月29日、v2 2026年2月25日）。「mjlab は Isaac Lab が導入した manager-based API を採用し、利用者が観測・報酬・イベントのモジュール化された構成要素を組み合わせられるようにしたうえで、GPU 加速の物理として MuJoCo Warp と組み合わせる」(“mjlab adopts the manager-based API introduced by Isaac Lab, where users compose modular building blocks for observations, rewards, and events, and pairs it with MuJoCo Warp for GPU-accelerated physics.”)、「ネイティブの MuJoCo データ構造への直接アクセスを提供する」(“providing direct access to native MuJoCo data structures.”)と書く。本文 §1 は Isaac Lab について「RL 環境を組み立てるための豊かな manager-based API を備えた、包括的な GPU 加速プラットフォームを提供する」(“provides a comprehensive, GPU-accelerated platform with a rich manager-based API for composing RL environments.”)、「その物理エンジン PhysX は最近までクローズドソースだった」(“Its physics engine, PhysX, was closed-source until recently”)と書き、参考文献の MuJoCo Playground は K. Zakka を第一著者に挙げる（v2 HTML: https://arxiv.org/html/2601.22074v2）。https://arxiv.org/abs/2601.22074 ↩

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。