ざっくり言うと、未来の映像と行動を作るWAMに、コードでスキルを組むエージェント的な考え方を混ぜた枠組み。WAMは先の見通しはあるけど、長いタスクをどう分解してスキルを再利用するかが弱い。逆にコード計画側は、物理的な予測に裏打ちされにくい。そこをつなぐのが狙い。

そう。コード、未来映像、ロボット行動を三つの生成ストリームとして、Mixture-of-Transformersで一緒に生成する。コード専門の部分がパラメータ付きのスキル手順や制御ロジックを作り、映像専門が未来の見え方、行動専門が低レベル指令を担当する。

その理解でいい。しかもコードは、多段階の予測と制御の構造を与える役割と、あとでエージェントが再利用できるプログラムとしての役割の両方を持つ。論文では、ロボットと人間の動画軌道にプログラムを対応づける自動注釈パイプラインも作って、繰り返し出るルーチンをスキルライブラリにまとめてる。

論文の言い方だと、注釈付きの軌道から再利用可能なスキルを見つけて、事前学習と下流の微調整に使う。実行時は、行動チャンクをそのまま使うモードと、プログラム的なスキル呼び出しを切り替えるハイブリッドも試してる。

入力は多視点観測、言語指示、ロボット状態、直前のプログラムスライスの記憶。出力はスキル計画コード、未来映像、行動チャンク。事前学習は約2,000時間のYAMロボットデータと約1,000時間の一人称ヒューマン操作データを使って、YAM 23件・ヒューマン27件の計50スキルからなる実体別ライブラリを構築してる。

RoboTwin 2.0のcleanとrandomで、50タスク×50ロールアウト。比較はπ0.5（VLA）、EgoScale（一人称ヒューマンデータで事前学習したVLA）、DreamZero（映像と行動を共同生成するWAM）、WLA（テキストのサブタスク・サブゴール画像・行動を自己回帰的に予測）。baselineとdefaultのAW-0は同じタスク別デモと同じ評価プロトコルを使ってる。

平均成功率はπ0.5が41.3、DreamZeroが25.6、EgoScaleが14.5、WLAが34.2、AW-0が50.7、AW-0 hybridが46.2。cleanだけならAW-0が80.8で、WLAの64.8より高い。randomは標準AW-0が20.6、hybridが29.2で、hybridが補完する形。

そこは慎重。論文もrandomではhybridが標準AW-0を補うと述べてるけど、cleanほど余裕があるわけじゃない。実機の双腕タスク8個でも改善を報告してるけど、提示された本文からは詳細数値を確認できない。言語追従や意味推論、ロバスト性の改善も報告されてる。

うん。コードが長期タスクの構造を与えて、映像予測が物理的な見通しを、行動生成が実行を担う。だからスキルの再利用と物理的な予測を同じ枠組みで結びつけられる、というのが論文の主張。記事として見るなら、論文の報告とこちらの解釈は分けたほうがいい。

評価はRoboTwin 2.0と実機8タスクに限られて、未知のロボットや環境、長期タスクへの一般化は未検証。スキル再利用は事前定義APIや実体別スキルライブラリ、自動注釈パイプラインに依存する。hybridは別途集めたCaPデモと切り替え判定が前提で、標準設定とは条件が違う。計算コスト、推論遅延、安全性、失敗時のリカバリも提示本文からは十分確認できない。

まず締切を観測するところからだな。

読んだ。PhysLadderってやつだね。ざっくり言うと、接触を伴う家庭内操作を3段階に分けて、対応させたSimと実環境でGPT-6 Astraをゼロショット評価するベンチマーク。

そう。16個の家庭内タスクをL1が5、L2が7、L3が4に分けてる。L1は接触選択と位置合わせ、L2は持続接触中の力調整を追加、L3は接触の再構成と力調整の協調まで必要って累積レベル。

全体の成功率だけだと、どの物理要件が足を引っ張ってるかわからないから。接触の選び方や力の調整を分けて見たいのが動機。あと、実環境で出た限界が対応Simでも再現するかを見る。

実環境を基準に、ワークスペース配置、物体の形状と見た目、ロボット身体、カメラ視点を対応させる。物理計測と観察した接触応答でSimをキャリブレーションして、タスク定義と成功基準も共有する。

GPT-6 Astraのゼロショットで、各タスク各環境3試行。実環境の成功率はL1 80.0%、L2 47.6%、L3 0.0%。Simは66.7%、47.6%、0.0%で、L3は両方とも完了なし。

16タスク中10個は成功数が一致。残り6個は3試行中1回分だけ違う。完全一致ではないけど、同じような傾向と難しさは出てる、って報告。

うん。局所的な進展がタスク完了に積み上がらないって課題と、4つのボトルネック。空間推論と実行精度、接触配置の選択と成立、力調整、相互作用の内側と間の協調。キャップを回したり引き出しを動かしても、必要な操作を完了できないことがある。

このベンチマークの定義では、力の直接計測や直接コマンドは必須じゃない。動きやグリッパ指令で調整する形も含む。

このモデルについては、対応Simが接触操作の限界を調べる再現可能でスケールしやすいテストベッドになることを支持する、って位置づけ。ただし主張はそこまで。

既存手法をベースラインにした比較は報告されてない。比較の軸は、同じタスク定義と成功基準を使った実環境と対応Sim、それにL1からL3の累積レベル間の成功率。関連研究は挙がってるけど、この論文内で他手法との性能比較は提示されてない。

そう。単一モデルのゼロショット、16タスク各3試行だから成功率の推定は粗い。L3が両環境0%だと能力差の分解も限定的。家庭内タスクと特定の実機・Sim設定に限定されるし、産業組立や多様な物体・ロボットへの一般化は不明。

提示された本文からは確認できない。タスク仕様や付録の詳細も、この本文だけでは確認できない。失敗要因の分類も観察ベースで、因果効果や改善手法の有効性を検証したわけじゃない。

例えが雑。でも、途中の進展が完了に積み上がらないって点は近い。

そう。LLM推論が中央クラウドに集まると、データ主権やコンプライアンス、遠い場所の遅延、手元の計算資源を使えない問題がある。テルコの地理分散GPUとネットワークを共有基盤にしようって発想。

既存は密結合データセンター前提で、高帯域・低遅延インターコネクトを当然視しがち。広域で異種GPUが混ざるテルコ網は前提が違う。InferSliceはSLOに応じて配置・構成・スライスを選ぶ参照アーキテクチャ。

そう。最初のトークンまでの時間と、出力トークン間の時間。対話なら両方大事。バッチならスループット重視とか、要求が違う。だから同じ基盤で複数サービスをSLO付きで扱う。

ネットワークスライス、GPU分割、弾性配信、観測性。推論側はTP、PP、DP、Prefill/Decode分離を広域配置でどう扱えるか見る。JOINER UK WANの複数PoPで評価してる。

TPは層内の重みを分割して頻繁に集団通信。PPは層で分割して段間で活性を渡す。DPはモデル全体の複製で推論時同期なし。P/D分離はprefillとdecodeを分けてKVキャッシュを転送する。

論文の報告ではDPは配置に鈍感だけどメモリ制約。PPは近〜中距離の跨拠点には耐える。TPとP/D分離は単一サブネットホップを超えると失敗した。専用AIファブリックなしの汎用WANだから、この境界が大事。

あった。SLO階層ごとに遅延・スループット特性が分かれ、重みストリーミングがスケールアウト時間を短縮した、という報告。ただ数値や詳細条件は提示本文からは確認できないから、そこは一般化しない。

同一条件での直接比較結果は本文では明示されていない。設計比較としては、LLM-Sliceは無線ネットワークスライスでLLM通信を差別化するけど、推論計算の配置・オーケストレーションが主眼ではない。InferSliceは計算とネットワークをまとめてSLO駆動で選ぶ点が違う。

テルコが運営する地理分散拠点のGPUとネットワークを共有し、TTFT/TPOTやスループットのSLOを持つ複数サービスを同じ基盤で扱う想定。中央局、地域DC、コア網拠点みたいな場所。汎用WANで専用AIインターコネクトやRDMAは仮定しない。

そう。評価はJOINER上の汎用テルコWANで、特定のモデル・GPU・負荷・ネットワーク条件に依存する。商用テルコ環境、他のWAN、多様なGPU、規制・セキュリティ、コスト、障害時挙動、SLO達成率の定量的一般化は未検証。あとこの話は論文の解説で、実装や追試をしたわけじゃない。

例えとしては近いけど、店舗ごとに厨房の大きさも回線も違うし、料理の途中で材料を運ぶ必要もある。単なる振り分けではない。

そう。そこが一番の学び。あと「店舗」の例えはちょっと雑。

標語にするには雑すぎる。

履歴を読む方もコストだけど、論文だとビーム探索のデコードが支配的だって。ビーム幅100の計測では生成時間の最大91%がビーム探索で、履歴キャッシュを共有しても残る。FlatGRとFusedGRは履歴の読み方は違うけど、候補を書く方を重いバックボーンでO(BK)回やるのが共通のボトルネック。

そう。そこでDecoは「履歴を理解する」と「SIDを綴る」を分ける。重いバックボーンが融合済み履歴を一度読んで、次アイテム概念zを作る。あとは軽量でKVキャッシュ付きのデコーダが、zと生成済みprefixだけを条件に、トライ制約付きビーム探索を全部回す。SIDもトライも自己回帰の分解も変えない。

まずクロスエントロピーだけで訓練できるDeco-CEがある。さらにフルバックボーンの教師から蒸留すると精度が上がる。教師はFusedGRで、Deco-flatならFlatGR。音楽ストリーミングみたいにリピート消費が多い領域では、履歴へのコピーポインタも足す。固定サイズの概念だけじゃ過去アイテムの同一性をたくさんは持てないからね。

SIDとSIDトライを使う生成推薦・生成検索が対象で、履歴などのインタラクションデータ、SIDトークナイザ、トライが必要。実験はe-commerce、映画、音楽ストリーミング由来の7データセット、production-style serving pipelineで、50ms p95レイテンシ予算やバッチ128、最大3BパラメータのLLMバックボーンまで言及されてる。軽量デコーダの既定は2層・幅256で、バックボーンは8層・幅640との比較。概念ベクトル数Mは1から8で同程度とされ、実験ではM=2。

7データセットで、標準の生成推薦や融合入力のフルバックボーン教師に対して同等以上精度。スループットは要旨だと50ms p95予算下で3.2–8.6倍、導入の箇条書きではバッチ128でFusedGRの2.8–5.1倍、50ms p95で3.2–7.3倍と書いてある。1000候補生成が教師の100候補生成より速い、1.5Bバックボーンが69M教師と同等スループットで精度は上、3BでFusedGR比16倍という報告もある。

そこが意義。ビーム幅やSID深さを増やしても、追加の重いバックボーン呼び出しは不要で、計算が軽量デコーダ側に寄る。概念はbf16で1KiBのサービング状態になるって話も、履歴KVキャッシュが0.4–7.8MiBなのと比べると大きい。

速度向上はビーム幅、SID深さ、バックボーン規模、履歴長に依存する。長い履歴は主にprefillとして両方に残る。評価も提示本文では7データセットとproduction-style pipelineまでで、実サービスの長期A/Bや別ドメインへの一般化は確認できない。あとリピート用途はコピーポインタ頼みで、その詳細や並列・拡散型との全比較条件は抜粋だけだと十分には分からない。

下書きが軽いとは一言も言ってない。まず履歴を読むところからだ。

壊れてるというか、特定の条件で勾配が変になる。まずSoftmax Collapse。正解クラスに自信がありすぎてマージンが精度の崖を超えると、標準実装は正解ロジットの勾配を0に丸める。でも他のクラスの勾配は残るから、勾配の和が0にならなくなる。

そう。Adam系は勾配の大きさで正規化するから、片方だけ0になると不安定になる。論文ではSlingshotを消すって報告してる。

Softmax Cancellation。蒸留でstudentとteacherのロジットが近いとき、q=softmax(zS)とp=softmax(zT)を別々に計算してq-pを引くと、ほぼ同じ確率の引き算で精度が落ちる。zS=zTでも非ゼロの勾配が残る。

直し方はシンプル。log-softmaxとsoftmaxでは最大ロジットを和から除外して、softplusでまとめる。hard-targetの交差エントロピーはターゲットを和から外してmを計算する。

soft-targetはq-pをログ空間で直接計算する。δ=zS-zTをpで中心化して、expm1とlog1pで扱う。最後に勾配の和が0になるように補正する。JAXの実装例はstop_gradientで前向きのlossとカスタム勾配を分けてる。

modular additionのgrokking。1層幅64のReLU Transformerで、bf16/fp32/fp64、εを1e-8,1e-12,1e-16に変えて、標準と修正版の交差エントロピーを比較してる。重み減衰ありとなしも見てる。

修正版は精度の崖を滑らかに超えて、重み減衰ありのgrokkingが速くなる。重み減衰なしでは標準だと精度が61%から23%に落ちる場面で、修正版は85%まで続く。蒸留でもstudentがteacherからドリフトしない。

それは数値精度の崖じゃなくて、重み減衰とAdamWの正規化勾配の平衡。勾配がe^{-m}で小さくなると、εがあるせいで正規化ステップも小さくなる。だからm*≈log(1/ε)で止まる。ε=1e-8なら約18.4。

標準はJAX/PyTorch/TensorFlowみたいな最大値シフトの実装。論文は緩和策として代理損失、勾配射影、fp64キャストにも触れるけど、提案はlog-softmax/softmax/交差エントロピー自体を直す。

Kクラスのロジット、hard targetかstudent/teacherのsoft target、bf16/fp32/fp64で自動微分する想定。評価はJAX実装の小規模なgrokkingと蒸留の数値例が中心。

提示された本文からは確認できない。大規模モデルや多様なタスク、他フレームワークへの移植、計算コストやメモリの影響も未検証。Section 6の途中までしか載ってないから、全ベンチマーク結果も判断できない。

それはsoftmaxと関係ないだろ。

SVDで重みを低ランクにするとき、大きく分けて二つ困る。どの層にどれだけランクを配るかって問題と、分解そのものの品質だ。論文でもそこを二つの制約としてる。

でも層ごとに大事さが違う。原論文は、既存のランク配分が未校正の誤差代理とか高コストな測定に頼りがちで、深いネットワークの誤差爆発を捉えにくいと指摘してる。

そう。LEMSは層ごとの誤差モデルに、局所感度と大域的な層重要度、さらに誤差伝播を補正するバイアスを入れる。固定予算の下で離散的なランク候補から全体のランク配分をILPで選ぶ。

ただ、これは代理誤差モデルを最小化してる。真の損失を直接最小化する保証ではない、って点は押さえたい。

原論文はGFWSVDの系列単位Fisher近似が、サンプル数kでランク上限が決まってしまうのを問題にする。そこでKFAC-SVDはトークン単位の二次統計からKronecker因子を推定して、ランク不足を抑える。

論文の報告では、Mistral、Qwen3、Llama 3で、LEMSが既存のランク配分よりzero-shot精度を1.7〜4.8 p.p.改善。KFAC-SVDはWikiText2 perplexityを平均15%改善。70B規模ではuniform rank allocation比で4.0 p.p.改善、と書かれている。

そう報告されてる。でも評価の中心はzero-shot精度とWikiText2 perplexityだ。他のタスク、言語、長文脈、命令追従、安全性まで確認したとは本文からは言えない。

その通り。必要なGPU、時間、データ量の詳細は提示本文からは確認できない。推論高速化やメモリ削減、量子化との併用、キャリブレーション感度、ILP求解コストの実測も、この本文だけでは確認できない。

トークン単位近似だからクロストークン二次モーメント、たとえばweight sharing由来の成分は省略してる。論文もそのトレードオフは認めてる。

ああ。原論文の報告としては、SVD圧縮の二大課題を同時に扱って、既存手法との比較で改善を示したのがポイントだ。ここは報告と解釈を分けて読むべきだけどね。

それは誤差が伝播する前に締切が来るやつだ。

LLMマルチエージェントの構成を作って、実行して、評価して、また比べるためのOSS基盤。特にソフトウェア工学の実験向け。

そう。背景には、エージェントの役割やプロンプト、ツール、モデル、通信トポロジを変えながら試すと、ベンチマーク管理や結果比較が散らかりやすいって問題がある。既存の可視化ツールだけだと、そこが分断されがち。

可視化、宣言的JSON、再利用部品そのものは独自じゃない。OpenDracoの違いは、SEタスク向けにバージョン付き仕様、実行、タスク評価、結果比較を統合して、APRではSWE-bench評価までつなぐ点。

その通り。エージェント、プロンプト、ツール、モデル、パラメータ、通信トポロジをエクスポート可能なバージョン付きJSONにまとめて、LangGraphのワークフローに変換する。ローカルでもクラウドでもLLMを使える。

Dockerでローカル配備して、Web UIかCLIから使う。推論はOllamaのローカルか、OpenAI互換APIのクラウド。APR評価はSWE-bench harnessを使う。仕様JSONとSWE-bench形式のインスタンスが入力って整理できる。

論文の報告では、同一のローカルモデルqwen3.5:9bで、chainのベースラインと7つの再構成構成、合計8構成。トポロジはchain、star、tree、hybrid。評価は合成5件、SWE-bench Lite開発23件、テスト77件で、テスト側はgold patchが600文字未満のインスタンスに限定してる。

合成5件ではopenhands_starが全5件を解決して、8構成の中で時間もトークンも最小。23件開発サブセットではchainとhyperagent_starがどちらも2件解決したけど、chainの方が時間39.78%減、トークン47.32%減だった。

そう。だから効果とコストを同じ環境で比べる意味がある。そのトレードオフを見て、大きい77件サブセットにはchainを選んで、12/77、15.58%を解決してる。

temperature 0ではchainが合成の同じ3件を5回とも解決。temperature 1では解決数が2から4件にばらついて、実行時間とトークン使用量も変動が大きい。だから非ゼロ温度の構成は繰り返し評価が必要って示唆。

それに加えて、APR以外の概念実証として翻訳ワークフローもUIから作って、BLEUで評価してる。タスク固有のエージェント、トポロジ、ツール、評価器だけで、フレームワーク本体に変更は不要だった。

ある。再構成したAPR構成は元システムのエージェント、プロンプト、ツール、通信構造を近似したもので、実行時挙動の完全再現じゃない。だから構成間の差をトポロジだけに帰属できない。

6GB VRAMのGPUで全エージェントを逐次実行してるから、並列化の利得は評価されてない。モデルもqwen3.5:9bだけだから、他モデルへの一般化は未検証。

変動研究を除くと各構成は原則1回。実問題では3構成だけ、大きい77件サブセットはchainだけ。だから構成差や変動性についての結論は限定的。他モデルや並列実行、SWE-bench以外の大規模適用は提示された本文からは確認できない。

評価ハーネスが冷蔵庫なだけで、たぶん再現性は怪しいぞ。

うん。ざっくり言うと、距離や径みたいな連続値を、普通のVLMみたいに数字トークンで出すと精度が崩れやすい問題を扱ってる。

そう。トークン予測は次の記号の当てやすさは見るけど、数値の距離の大きさを直接は最適化しない。あと座標の小さなズレと長さの整合も保ちにくい。

その通り。始点・終点の座標と長さの5値タプルを拡散で出して、座標から計算した長さと直接予測した長さのズレを見る座標-長さ整合も入れてる。検証セットでしきい値を決めて、推論では20個サンプルの中央値で補正する。

論文の範囲ではそう。EchoNet-LVHの心エコー4計測、IVSd・LVIDd・LVIDs・LVPWdでMAEが1.36、2.77、3.05、1.16 mm。Vicunaベースの自己回帰ベースラインより21.4〜37.6%相対的に誤差を下げたと報告してる。

論文内では、ファインチューニングしたQwen3-VLと直接MLP回帰も全4タスクで上回るって書いてある。X線椎体計測はMAEが11.4から6.7 pixelsに下がった。医療QAは評価データセットで性能を保持。ただ独立追試じゃなくて、比較条件の細部は本文から確認できない部分もある。

そうだね。でも評価は主にEchoNet-LVHの4心エコー計測と、追加の医療QA・X線椎体計測に限られる。他臓器や多施設、臨床ワークフロー、計算コストは未確認。しきい値の検証セット依存やR=20の推論コストも定量評価されてない。

採点はともかく、まずは画像の座標と長さの整合からだね。

問題意識は、テキスト交換は読めるけどトークン生成が重いってこと。潜在通信は計算を渡せるけど、受信側がその中間計算をどう使うかが難しい。J-COMMは送信側の連続推論と受信側へのインターフェースを一緒に設計してる。

そう。送信側のGEARは学習なしで、各ステップの候補トークン埋め込みを、候補同士の埋め込み空間での幾何的合意で再重み付けする。確率だけの平均より、近い方向の候補を支持するイメージ。凍結モデルの既存埋め込み表を使う。この幾何合意フィードバックをGAFって呼ぶ。関連手法だとCoconutは最終隠れ状態を次入力にし、Soft Thinkingは候補埋め込みの確率平均を使う。J-COMMは幾何合意を確率に乗算する点が違う。

メッセージはHとJの二経路。Hは送信側が実際に消費したフィードバック分布を、受信側の埋め込みで構成して入力として渡す。Jは中間状態をJacobianレンズ座標で読み出し、共有トークンIDのアンカーIDと符号付き読み値を送る。受信側は自分の辞書で再構成して、prefill中の中間層に注入する。

その通り。主設定はQwen3-8BからQwen3-4Bで、ブロック26を読み書き、P=32アンカー、M=400、送信側は最低40潜在ステップ後に適応停止。bfloat16で、送信側はHugging Face、受信側はvLLM 0.10.2 V0。共有語彙が前提で、語彙が違う場合の拡張は付録B.1に言及があるけど、提示本文では詳細は確認できない。

原論文の主比較はTextMAS。TextMASは送信側が生成したテキスト計画を渡すのに対して、J-COMMはGEARの分布とH+Jの潜在メッセージを渡す。7ベンチマークでJ-COMMのGAF+H+J26が最高平均スコア。MATH500 94.80%、GPQA-Diamond 54.55%、AIME2024+2025 73.33%、ALFWorld 62.93%成功。TextMAS比ではGSM8K 1.29、MATH500 1.60、GPQA 8.59、MedQA 1.97、MBPP+ 5.56ポイント改善で、生成テキストトークンは19.2〜74.8%削減。ただしこれは原論文の報告で、追試ではない。

限定はある。評価の中心はQwen3-8B→Qwen3-4Bの1組と7ベンチマーク。共有語彙前提、校正済みJacobian辞書、層選択、アンカー数、注入強度みたいな設計依存がある。校正コストや遅延・メモリの定量比較は提示本文からは確認できない。テキストトークン削減はTextMAS比較の範囲で、潜在ステップの計算は別会計。安全性、多言語、長期運用、本番環境の頑健性は未検証。

あとは対照も見るといい。Receiver-only、Identity40、H/H+Jアブレーション、Null-slot、J-only、Shuffled-Jがあって、比較条件は受信バックエンドと出力上限を揃えてる。J-COMMはKV共有なしで、各モデルのKVキャッシュをローカルに持つ設計。

語彙も校正も共有してないから、まずテキストで頼む。

そう。LLMのRLでは推論エンジンで生成して、別の学習実装で確率を計算し直すことが多い。同じ重みとBF16でも、実装が違うと確率がずれて、意図したon-policy更新がoff-policyっぽくなる。これが安定性を壊す一因。

同じBF16出力でも、途中の中間値をBF16に丸めてから次に渡すか、FP32のまま保持して最後だけBF16に戻すかで、次の演算に入る値が変わる。融合カーネルと分離カーネルでこの位置がずれる。論文はこれをrounding-location mismatchと呼んでる。

既存研究では、推論・学習スタック全体の一致、FP16への全体精度変更、重要度サンプリング補正や切り詰め・マスク、batch-invariantカーネル、モジュール単位の一致、RoPEやSwiGLUの丸め位置一致なんかがある。ただ、原論文の提示本文では、それら既存手法を同じ設定で横比較した結果は確認できない。

学習側のRoPE、SwiGLU、残差RMSNormの3領域。選んだ中間値をFP32で保持して、各領域の出力をBF16に戻す。推論エンジン、行列積・注意カーネル、学習目的は変えない。ポイントは全部揃えるんじゃなくて、丸め位置を選択的に合わせるってこと。

Qwen系4モデル、DeepSeek-R1-Distill-Qwen-1.5B、Qwen3-1.7B、Qwen3-4B-Base、Qwen3-8B-Baseで、既定BF16で起きた崩壊を3領域合わせると防いだ。検討した実行ではRoPEパスだけでも安定した、と報告されてる。比較条件は既定BF16、RoPEのみFP32、3領域FP32、zero-mismatch backendなど。

そこは注意。静的解析では3領域FP32が全モデルでKLを一番下げたけど、SwiGLUの寄与が負のモデルもあった。中間精度を上げれば必ず不一致が減るわけじゃない。RoPEのみで安定したのは検討した実行の話で、常に十分とは限らない。

MATHのSanity-Test-R1D-1.5Bで強化学習して、AIME 2025で評価。学習目的はPPO-clipped GRPOで、追加の不一致補正は使わない設定。静的解析はQwen3-4B-Baseを除く3モデル。

3領域を合わせると、forward-and-backwardレイテンシが5.33–10.92%増、ピーク割当メモリが0.41–0.89 GiB/GPU増えたと報告されてる。ロールアウト生成を含めた全体のRL時間では割合が小さくなる見込みだけど、それは本文の期待。

評価はQwen系4モデルと特定のRL設定・データに限られる。他のモデル系、他の推論エンジン、FP8や量子化、違う並列化やreduction順、他のRL目的やタスクへの一般化は提示本文からは確認できない。zero-mismatch backendの詳細や大規模・長期訓練での挙動も不明。完全な数値一致を目指す手法でもない。

うん。選択的な丸め位置合わせだけでBF16のLLM RLが安定する可能性を示したのが意義。ただし対象はQwen系と特定の評価設定に限られる。

それは丸め位置じゃなくて、単に片付けてないだけ。