Pinned Tweet
昨年のICCVに続き #ECCV2026 にて、ワークショップFOUNDのプライマリーオーガナイザーを務めます!
本WSは、基盤モデルを実世界で動作させるためのラストワンマイルを埋める「基盤データ」の構築や学習技術を扱い、今回はPhysical AI・世界モデルの実運用にフォーカスします。
eccv2026-found-workshop.limi…
🌍コンピュータビジョン分野の国際会議「ECCV 2026」でワークショップを主催します🌍
来月、キャディ・Sansan・SB Intuitions・LINEヤフーの研究者が国際ワークショップ「FOUND」を主催します。
実世界AIの社会実装において不可欠となる「基盤データ」の創出と技術移転をテーマとし、世界中の研究者が知見を共有するワークショップです。
キャディからは、Senior Research Engineerの福原がプライマリーオーガナイザーとして参加します!
▼詳しくはプレスリリースをご覧ください
prtimes.jp/main/html/rd/p/00…
Yoshihiro Fukuhara retweeted
研究者らによると、CLAUDE.mdやAGENTS.mdにあらかじめ次の一文を足すことが推奨されます。
「ドキュメントと既存のコードが食い違うときはコードの書き方に従い、見つけた食い違いを最後の返答ですべて挙げること」
なぜか。
Claude CodeやCodexは、CLAUDE.mdやAGENTS.mdの記述が今のコードと食い違っていると、9割がた古い記述のほうに従うそうです。"指示が古い"と気づいていても抗えない仕組みです。
この発見に至るまでに、ジョージア工科大などの研究者らは、設定ファイルとコードがわざと食い違う40のプロジェクトでClaude CodeとCodexに機能を足させて調べました。
Claude Codeは80回中79回、食い違いに気づいたと"自分で書きながら"、古い情報に流されました。
Codexのほうは、80回中20回で、動いていた既存のコードを古い記述に合わせて書き換え、うち17回でテストが通らなくなりました。
研究者らの見立てとしては、AIは、指示を優先するよう訓練されています。CLAUDE.mdやAGENTS.mdは「指示」としてAIに渡り、コードはファイルを読んだ「結果」として渡るのが原因だと言います。その仕組みが、古いものに従わせるのだとか。
そして設定ファイルは一度書いたきりになりやすい傾向があります。更新不精の人は上の一文をあらかじめ追加しておくのも一つです。
指示の原文→"When a repository's documentation and its existing code disagree, follow the conventions used in the existing code, and in your final reply point out each inconsistency you found between the documentation and the code."
Yoshihiro Fukuhara retweeted
資料はこちらのようです 👉 speakerdeck.com/sansantech/2… #cvsaisentan
Yoshihiro Fukuhara retweeted
HTTP2Shellの影響で"特に"迅速な更新が推奨されるリスト(記載は一部なので公式情報を)
通信しそうなものはとりあえずすべて更新して!
【ブラウザ】
すべて(ChromeやEdgeやFirefoxを筆頭にすべて)
【OS】
すべて(特にユーザーに重要部分触らせないiOS)
【ソフト】
・Electron系(NodeとChromoiumの影響)
Discord/Slack/VSCode/Chatwork/1Password/Notion etc...
・画像系
GIMP/Krita/ImageMagick
・梱包/PDF系
NanaZip/7Zip/7-Zip-zstd/MuPDF/SumatraPDF etc..
・ツール類
calibre/yt-dlp/Streamlink/gallery-dl/calibre/yt-dlp/Streamlink/gallery-dl/Git for Windows/cdxgen etc...
・AI系
ChatGPT Desktop/Claude Desktop/Hermes Agent/OMP etc...
【言語・処理系】
Electron/Node.jsランタイムを用いるすべて/Bun/Python(Brotli,brotlicffi)/libbrotli/Envoy/Istio/curl/DuckDB etc...
もう全部書ききれないから手元のAIエージェントに"HTTP2Shellで更新しないといけないのはどれ???"って聞いて!
Yoshihiro Fukuhara retweeted
約60個の質問に答えて論文を組み立てる「60QA」の公開版を更新しました。
11/2の本学講義「AI実践(本田技研工業寄附講座)」にて、60QAを作った背景、使い方、添削側の工数管理方法について講演します。
docs.google.com/document/d/1…
卒論・修論の季節ということで、当研究室の論文執筆方法「60QA」を紹介します。
約60個の質問に回答すると論文がいつの間にかできあがる、という方式で論文執筆を仕組み化しました。
添削も回答ごとに記録を残しながら行うので、添削側の認知負荷を減らせています。
docs.google.com/document/d/1…
Yoshihiro Fukuhara retweeted
スライドは Slidev と Claude Code で作りました。Python でがんばって SVG のポンチ絵を書いてる姿に涙が止まらなかった
ja.sli.dev/guide/ #cvsaisentan
Yoshihiro Fukuhara retweeted
SolidCraftの開発チームが早速、Nvidiaが出したSMLibのRust移植を行っている。
対応が速いのと、すごい勢いでCADのオープン化が進んでいる。
github.com/tangency-labs/sol…
マジでここ最近の脆弱性祭り、深刻すぎてあきらめの境地にいる
とりあえず全てのパスワードの末尾にLicenseWTFPLってつけてきたお
マジで「Patch the Planet見とけ」以外に言うことないンゴ
patchtheplanet.org/
Yoshihiro Fukuhara retweeted
Noiseは、Backpropを使わずにTransformerを事前学習するアルゴリズムを競う公開ベンチマークである。
37.7MパラメータのTransformerを対象に、誤差逆伝播を使わず、前向き計算のみで、同じトークン数の学習でより低い検証損失を達成するか、同じ検証損失により短い時間で到達するかを競う。
すでに通常のBackprop + Adamをわずかに上回る性能を達成するレベルには達しているが、改良されたBackpropを用いる手法には及んでいない。
基本となる考え方は、各層のActivationに摂動を与え、Lossの変化からパラメータの更新方向を推定するNode Perturbationである。
特に、Transformerの残差接続などの構造を利用し、各層が最終的な損失にどれだけ寄与したかを推定するCredit Assignmentを効率化している。
・ランダムな摂動の代わりに、互いに直交するHadamard摂動を用い、効率的にLossの変化を推定する。
・学習初期には、各層の出力を共通のLM Headで評価し、後続の層を通さずに局所的な学習信号を得る(Boost)。
・学習後半では、残差接続の恒等経路や線形演算を利用し、最終的なLossへの影響を近似的に評価する(Cut)。
こうした性能改善では、Transformerの構造を積極的に利用することが重要になっている。
コメント
===
完全な誤差逆伝播を行わなくても、ネットワークの構造を利用した近似的なCredit Assignmentによって、効率的に学習できる可能性が示されている。
一方今回の手法がそのまま大規模に適用できるかは不明であり、今後、長期学習時や、モデルの幅や深さに対するスケーリングがどうなるのかが興味深い。
Hadamard摂動の利用は、構造化された乱数を使う準モンテカルロ法やLow-discrepancy列などの考え方も連想させるが、直交性があり効率的に計算できるなど様々な発展が考えられる。
特に学習後半では、多くの更新方向でLossが改善しなくなる中、わずかな改善方向をいかに効率的に見つけるかが重要になる。そのためには、全空間を探索するのではなく、勾配が集中する低次元部分空間を推定し、その中で摂動を与えるといった考え方が必要になるかもしれない。
一般に、誤差逆伝播を使わない学習手法は、微分不可能な計算モジュールを含む場合、例えば離散化、ツールコール、他のエージェントの出力を利用する場合などに有効となる。また、モデルが非常に大きく、層方向の並列化を進めたい場合にも利点が考えられる。
今回の取り組みで得られたCredit Assignmentの効率化手法は、通常の誤差逆伝播による学習にも応用できる部分があるだろう。
Google DeepMindがSoftmaxとCross-Entropyの実装のバグを修正する論文を出してくれたよ
これで小型モデルのContext rotとか、学習時の不安定性とか諸々が全部ほぼほぼ無くなるね(アーキテクチャとかを一切変えず)
理論上の計算と実際の計算がズレてたよって話やね
alphaxiv.org/abs/2610.31642
Yoshihiro Fukuhara retweeted
米国の内科専門医が、「限られた体力をどう使えばいいのか?」をまとめた本で、日々の考え方の参考になりました。
ここでは、体力を「最大体力」「実効体力」「余力」の3つに分けていて、
・運動や生活習慣で高められる体力の上限があるよねー
・しかし、その日の睡眠やストレスによって実際に使える体力は変わるよねー
・さらに、一日の終わりにどれだけ余力を残せるかも重要だよねー
って考え方っすね。こうやってわけてみると、確かに「そもそも今ある体力をうまく使えてる?」みたいな視点を持てていいっすね。
まぁ、具体的な対策については、さすがに新しいものはなく、睡眠、運動、ストレス管理といった定番のアドバイスが中心。そこらへんは、健康情報を日頃からチェックしている人には目新しさが少ないでしょうが、自分の体力との付き合い方を見直すための本としていいんじゃないでしょうか。
あと、著者が渡米前に恩師からかけられた「自分の実力の60%を出せれば十分。100%を狙ってはいけない」って言葉はとてもよろしいですね。
『鍛えるよりも「使い方」 体力がすべて: 医学的根拠であなたのパフォーマンスを最大化する方法』
link.amazon/B0ezQJEE7
Yoshihiro Fukuhara retweeted
Softmaxとクロスエントロピーの標準的な実装に2種類の数値誤差が存在し、従来のGrokkingの研究で観測されていたSlingshot現象(突然の損失急増)が、この数値誤差によって説明できることが示された。さらに、蒸留で教師と生徒の出力が近い場合にも問題が発生しうることが明らかになった。
“A Fix for Softmax and Cross-Entropy”
* Softmax Collapse
通常のクロスエントロピー損失では、正解クラスのLogitに対する勾配は
gₜ = qₜ - 1
である。ここでqₜは、Softmaxが正解クラスに割り当てる確率である。
正解クラスに割り当てる確率が大きくなるにつれて勾配は小さくなるが、数学的にはゼロにはならない。しかし、浮動小数点演算ではqₜがちょうど1に丸められ、勾配がゼロになってしまう。
一方、不正解クラスに対する勾配は、より小さな値まで保持される。
本来、すべてのクラスに対するLogitの勾配の総和はゼロ、つまり
∑ₖ gₖ = 0
を満たす必要がある。これは、すべてのクラスのLogitに同じ値を加えてもSoftmaxが変わらないという性質に対応する。しかし、この数値誤差によって勾配の総和がゼロでなくなる。
正解クラスのLogitと、それ以外のLogitのLogSumExpとの差をマージンmと定義すると、FP32ではmが約16.6を超えた時点でこの問題が発生する。
例えば、Logitが
[9, -9, -9]
であり、最初のクラスが正解の場合、通常実装の勾配は、マージンが18と16.6を超えてしまうので0となり、
[0, 1.523 × 10⁻⁸, 1.523 × 10⁻⁸]
となるが、正しい勾配は
[-3.046 × 10⁻⁸, 1.523 × 10⁻⁸, 1.523 × 10⁻⁸]
である。
この違いは絶対値としては小さいものの、Adamのように勾配の大きさを使って更新量を正規化するOptimizerでは、重大な影響を与えうる。
特にGrokkingでは、ネットワークが訓練データを記憶した後、かなり時間が経ってから汎化性能が急上昇する現象が知られている。その過程では、Lossがゼロ近傍から急激に増大し、再びゼロに戻るSlingshot現象も観測されていた。このSlingshot現象が次の過程で発生することを示している。
1. モデルが訓練データを記憶すると、正解Logitのマージンが増大する。
2. マージンがFP32の約16.6を超えると、正解クラスの勾配がゼロに丸められる。
3. 勾配が極めて小さくなると、Adamの二次モーメント推定値が減衰する。
4. Weight Decayなどによってマージンが再び16.6未満になると、正解クラスの勾配が復活する。
5. 小さくなった二次モーメントによって勾配が正規化されるため、非常に大きなパラメータ更新が発生し、Lossが急増する。
さらに、AdamWのεとWeight Decayが、学習後のLogitのマージンを決めることも分析している。
Weight Decayが働く定常状態では、マージンは近似的に
m* ≈ log(1/ε)
となる。例えばε = 10⁻⁸の場合、m* ≈ 18.4となり、FP32で数値誤差が発生する16.6を超えてしまう。これもSlingshotが発生する原因となる。
この問題の解決方法は非常に単純であり、クロスエントロピーの計算に必要な
L = log(1 + e⁻ᵐ)
を、数値的に安定したSoftplus関数
L = softplus(-m)
で計算する。
さらに、正解Logitとその他のLogitとの差を使って損失を表現することで、自動微分によって正解クラスの勾配が、その他のクラスの勾配の負の総和として計算されるようにする。
これによって、非常に小さな勾配も保持され、勾配の総和がゼロになる性質も維持できる。
* Softmax Cancellation
もう一つの問題は、LLMの蒸留やKL正則化などで発生しうる。
TeacherとStudentの、確率分布をp, q
としたとき、Soft-target Cross-EntropyのStudent側のLogitに対する勾配は
g = q - p
となる。
このときTeacherとStudentが完全に一致すれば、勾配はゼロになるはずである。
しかし、従来の実装ではTeacherとStudentのSoftmaxを別々に計算してから引き算するため、近い値同士の減算による桁落ちが発生する。さらに、前向き計算と後ろ向き計算で演算経路が異なることによって、両者が完全に一致していてもゼロでない勾配が発生する場合がある。
これは、Teacherの重みをコピーしてStudentを初期化する場合などに問題となる。
実際に論文では、Teacherの重みからStudentを初期化して蒸留を続ける実験において、従来実装ではBF16の数値誤差がAdamによって増幅され、StudentがTeacherから乖離して精度が低下することを確認している。
この問題も計算方法の工夫によって解決できる。具体的には、TeacherとStudentの確率を別々に計算して引き算する代わりに、Logitの差から出発し、expm1やlog1pなどの数値的に安定した関数を用いて勾配を計算する。
これによって、TeacherとStudentが一致する場合には勾配が正確にゼロとなる。
コメント
====
今回指摘された数値誤差の原因となる計算は、PyTorchやJAXを含む現在の標準実装にも残っている。今後、これらの標準実装でも対応が進むと思われるが、大規模LLMの学習で使われるFused Kernelなどについても、同様の問題が存在するかどうかの確認が必要である。
このような一見わずかな数値誤差が、学習性能や学習中の不可解な挙動に大きな影響を与える、数値計算の方法によって勾配が変わり、Optimizerを通じて学習全体の挙動が変化するのは今後注意が必要である。
将来的には、コーディングエージェントが、勾配の総和がゼロになるといった数学的に保たれるべき不変性を理解し、実装の中でそれらが破られる可能性のある箇所を自動的に検出・指摘できるようになることを期待する。
Yoshihiro Fukuhara retweeted
Hi all, I have a new result I'm excited to share. It turns out that *all existing implementations* of softmax and cross-entropy (that's JAX, PyTorch, textbooks, etc) have a subtle bug --- two bugs, actually. A simple rewrite fixes both, and eliminates "slingshots" when grokking:
Yoshihiro Fukuhara retweeted
サイバー攻撃、明日は我が身だと感じています。自分たちの自身も備えを見直しています。侵入を防ぐだけでなく、被害の局所化、立て直しも大事。添付の画像は社内に展開した対策についての要約的なスライドです。参考になれば幸いです。
気を抜けない状況が続くと思います。対応にあたる皆さんも、どうか身体を大切に。自分たちも手を動かしながら、一緒に備えていきたいです。
AgenticSecなどの取り組みを通じて、プロダクトとしてもこの状況の改善に貢献していきたいと考えています。
Yoshihiro Fukuhara retweeted
意思決定支援・実行のためのAIエージェントプラットフォーム「Sakana Aquarium」を発表
sakana.ai/aquarium/
Aquariumは、Sakana AIがこれまでのAI実装の現場で繰り返し直面してきた課題から生まれたプラットフォームです。
AIによる意思決定支援を実務につなげるには、モデルの性能だけでなく 、AIが組織のデータの意味や関係、判断の前提となるルールを理解している必要があります。これまでは、そのためのデータ接続や用語・判断基準の整理、手順の設計を案件ごとに一から行ってきました。Aquariumは、この土台を共通の基盤として整え、その上でAIエージェントによる判断と実行までを支えます。
① データをつなぎ、意味づける(Ontology)
テーブルや文書など既存のデータを移し替えずにつなぎ、それぞれの意味や関係を定義します。AIはこれをもとに状況を理解します。
② 手順に沿ってAIが動く(Managed Agents)
「情報の収集 → AIによる判断 → 人の承認 → 実行」といった流れをワークフローとして記述するだけで、AIエージェントとして動かせます。
③ 人が統制し、事後に検証できる(Governance)
アクセス権限や承認のタイミングを設定でき、AIが何を根拠に判断し、何を実行したかも記録されます。
Sakana AIでは、今後もAquariumの機能を拡充するとともに、FDEがお客様とともに構築と検証を重ね、組織全体へのAI活用を推進していきます。
ブログ:sakana.ai/aquarium-release
秋葉さんのOptuna Meetupでの発表資料面白かった。Optunaの話から滑らかにSakanaAIでの仕事の話に接合されていて印象的だった😇
speakerdeck.com/iwiwi/16-opt…
Yoshihiro Fukuhara retweeted
SuperMimicは、ヒューマノイドの全身動作を学習するために、従来のPPOを中心とするモデルフリー強化学習ではなく、学習した微分可能な世界モデルを通じた誤差逆伝播法(BPTT)によって方策を直接最適化する。その結果、従来128基のGPUで7日間かけて学習したモデルの性能を、わずか1基のGPU、3時間の学習で上回った。
問題設定は、あらかじめ正解となる人間の参照動作データが存在し、それをロボットに模倣させるタスクである。正解となる動作の位置、姿勢、並進速度、角速度がロボットの実際の動作に近ければ近いほど、高い報酬を与える。
学習は以下の3段階を繰り返す。
・現在の方策をMuJoCo Warp上で実行し、状態・行動・次状態をリプレイバッファに保存する。
・8ステップの自己回帰予測を使い、ロボットのダイナミクスをニューラルネットワークで近似する世界モデルを学習する。
・学習した世界モデル上で32ステップの仮想ロールアウトを実行し、報酬から行動、方策へと勾配を逆伝播(BPTT)して方策を最適化する。
これらを同一の学習ループで交互に繰り返し、世界モデルと方策を並行して学習する。
世界モデル自体は3層・各2048ユニットのMLPであり、巨大なモデルではない。これだけ小さなモデルでも機能するのは、ロボットの運動が視覚や言語とは異なり、比較的低次元の状態空間と共通の物理法則によって記述できるためではないかと考えられる。
高速に学習できる理由は、大きく2つある。1つ目は世界モデルによるシミュレーションが高速であることと、2つ目は誤差逆伝播法によって方策を効率的に最適化できることである。
世界モデルはMuJoCo Warpによる物理シミュレーションより高速に状態遷移を計算でき、実際に使われる並列環境数(2K〜16K)では10倍以上、最大64Kの並列環境では62倍高速に実行できる。
さらに、従来のPPOのようにサンプリングした行動から方策勾配を推定するのではなく、微分可能な世界モデルを通じて報酬の勾配を直接計算するため、効率的に方策を改善できる。
実験では、同じ世界モデル上でPPOを学習させた場合に比べ、約64分の1の仮想ステップ数で同等の報酬を達成している。
今回、世界モデルは8ステップの自己回帰予測で学習するが、方策の最適化では32ステップ先まで展開して勾配を計算する。なお、32ステップは50Hzの制御周期で0.64秒に相当する短い時間である。
また、32ステップだけでは長期的な安定性や将来の報酬を十分に評価できないため、Criticによる価値推定を組み合わせる。これにより、短いロールアウトで勾配を計算しながら、それ以降の長期的な報酬も考慮できる。
世界モデルは摩擦係数、重心位置、キャリブレーション誤差などのシミュレーションコンテキストを入力として使う。一方、実機に配置する方策はこれらを直接利用せず、関節位置・速度やIMUなどの観測情報を使う。いわゆるPrivileged Informationを学習時に利用する構成になっている。
コメント
===
微分可能な世界モデルを使って効率的に学習するアイデアは古くから数多く提案されてきたが、今回の成功には、長期のダイナミクスを直接ロールアウトするのではなく、短い時間の予測と勾配計算に限定したことが大きく寄与していると考えられる。
具体的には、世界モデルを8ステップ(0.16秒)の自己回帰予測で学習し、方策のBPTTは32ステップ(0.64秒)に限定する。それ以降の長期的な価値についてはCriticを利用することで、予測誤差の蓄積を抑えながら方策を改善できる。
また、並列化可能で高速なMuJoCo Warpをさらに、学習された世界モデルで高速化し、1秒あたり合計数万秒分のロボット動作を仮想的に計算できることになる。
さらに、世界モデルを現在の方策が訪れる状態分布に合わせて継続的に学習することも重要だと考えられる。方策の改善によって訪れる状態や選択する行動が変化しても、新しいシミュレーションデータを収集して世界モデルを更新するため、方策が世界モデルの学習範囲から大きく逸脱する問題を抑えられる。
Appendix D.1に書かれている、方策が失敗しやすい区間を重点的にサンプリングする工夫も興味深い。動作データを1秒単位に分割し、Returnの低い区間を優先して学習するようにしている。例えば、宙返りの着地が難しい場合、動作の最初から繰り返すのではなく、着地直前の状態から重点的に学習できる。
また、今回のタスクは、あらかじめ正解となる動作が存在し、位置や姿勢の誤差から各ステップで滑らかな報酬を計算できるという特徴がある。こうした密な報酬も、微分可能な世界モデルを通じた方策最適化が成功した重要な要因だと考えられる。
そのため、正解動作が存在しないタスクや、物体との複雑な接触を伴う操作タスクにおいても同じような学習効率を達成できるかは、今後の重要な研究課題となる。
Yoshihiro Fukuhara retweeted
RePRは、生成モデルに適した潜在表現(トークン)を、PMIの因子分解という原理に基づいて学習する手法である。特に、生成モデル向けの表現学習にScaling Lawが成立することを示した点で重要である。
“Generative Representation Learning for Scalable Latent Tokenization”
RePRによって得られた潜在表現を使い、同じRAE生成フレームワークで比較したところ、FID-50KでI-JEPAやMoCo v3よりも高品質な画像生成を達成している。
さらに、Encoderの学習に投入する計算量を増やすことで、下流の生成性能が継続的に改善することを示し、また、Encoderと画像生成モデルの両方の学習コストを考慮しても、総学習計算量を減らしながらFIDを改善できることを実証している。
---
従来の画像生成では、潜在表現を得るためにVAEやDINOv2などのEncoderが使われてきた。しかし、対比学習などの識別的な表現学習では、少数の特徴だけで学習目標を達成できる場合、他の重要な情報が表現から失われる可能性がある(Feature Suppression)。
RePRは、特徴間の類似度を対比学習によって間接的に学習する代わりに、一方の観測によって他方の観測をどれだけ予測しやすくなるかを表すPMIを教師信号として、特徴表現を学習する。
PMI(点ごとの相互情報量)は、2つの観測x, yについて、
PMI(x, y) = log [p(y|x) / p(y)]
と定義される。これは、xを知ることによってyの予測にどれだけの情報が追加されるかを測っている。
一方、従来の対比学習では、同じ画像から得られた異なるViewの表現を近づけ、異なる画像の表現を引き離す。この対比学習の目標は、理論的には表現の内積によるPMIの近似と関係していることが知られている。
〈R(x), R(y)〉 ≈ PMI(x, y)
RePRはこの関係を利用し、生成モデルによってPMIを推定し、その推定値PMI'と表現の内積が一致するように学習する。基本的な損失関数は次のように定義される。
L = (〈R(x), R(y)〉 - PMI'(x, y))²
つまり、生成モデルが推定した情報量を、表現空間の幾何構造に直接埋め込むという発想である。これはWord2VecがPMI行列を暗黙的に因子分解しているという結果にもつながっている。
ここで、PMIの推定には生成モデルを利用する。具体的には、Diffusion Modelで条件なしの場合と条件付きの場合のDenoising誤差を比較し、p(y)とp(y|x)の対数確率の差に対応する量を推定する。
しかし、画像全体のPMIを直接推定することは計算量的に困難である。そこで、画像のパッチを一つ追加したときのPMIの変化量を計算し、それらを積み重ねることで画像全体のPMIを表現する。
PMI(x, y_{≤k}) - PMI(x, y_{<k})
そして、PMIの差分を、特徴表現の差分との内積によって学習する。
||〈R(x), R(y_≤k) - R(y_<k)〉- (PMI(x, y_{≤k}) - PMI(x, y_{<k})||^2
また、通常のPMIは画像の高周波成分も含め、共有される情報を同等に扱う。RePRではDiffusionのノイズレベルごとに重みを変えることで、生成に有用な情報を重視するようにしている。
さらに、PMIを推定するための生成モデルは、最初の段階ではピクセルを予測するが、次の段階では前の段階で学習された特徴表現を予測対象とする。このIterative Feature Predictionを繰り返すことで、より生成に適した潜在表現を獲得できることが示されている。
コメント
===
画像などの表現学習についてはさまざまな研究が提案されているが、RePRは表現学習をPMIと結びつけ、理論的にも実践的にも興味深い結果を示している。
直感的には、一方の観測からもう一方の観測を予測しやすいほど、その特徴表現の内積が大きくなり、逆に予測しにくいほど小さくなるように学習している、と言い換えられる。
また、生成モデル向けの表現学習にもスケーリング則が成り立つことが示されたことも興味深い。さらに、後続の生成モデルの学習コストも含めた総計算量を考慮しても、計算資源の一部を表現学習に振り向けた方が、生成モデルだけを学習するよりも高い性能を達成できることが示されている。
なお、特徴表現の学習過程では、PMIを推定するための生成モデルも既に学習されている。そのため、表現の獲得と生成を別々のモデルで行うのではなく、両者を統一的に実現するモデルを構築できるのではと考えられる。
Yoshihiro Fukuhara retweeted
Researchers proved every LLM is secretly obsessed with Japan.
And they finally figured out why.
They published a paper investigating hidden cultural biases in large language models.
they tested 31,000 questions across 24 different languages on models like gemini, chatgpt, claude, and llama.
they stripped out all geographic hints and just asked the models to pick a place and answer.
the finding was universal.. across a wide range of models and languages, there is a pervasive "obsession" with japanese culture.
even when you prompt them in a language with zero ties to japan, they default to japanese norms, values, and aesthetics at a disproportionately high rate compared to its actual global demographic weight.
the craziest part? they tracked down exactly when the ai develops this obsession.. and it is not from reading the raw internet.
during pre-training, the models actually have a fairly balanced, global view of the world. the obsession gets injected during the safety phase.
when tech companies fine-tune these models to be "helpful, harmless, and polite," the ai starts mapping those corporate safety guidelines directly onto japanese cultural concepts. in the pursuit of creating the perfect, inoffensive, compliant assistant, they warped how the models view the world.
the quantization process (compressing models to run faster locally) actually amplifies this determinism. the smaller and faster your local model is, the more stereotypically it behaves, causing japanese cultural tropes to spike hard.
we spend all this time worrying about existential ai safety, but the real alignment problem is that our most advanced reasoning engines are hyper-fixated on japanese internet culture.
every model upgrade is reinforcing an invisible regional bias that dictates how they generate stories, facts, and code. the cultural commonsense of the internet is not universal..
it’s just localized to whatever the heaviest reddit and anime wiki users were obsessed with.
Yoshihiro Fukuhara retweeted
3次元CADデータと2次元CAD(AI生成の配管計装図 / P&ID)を連携してシミュレーション・制御。3次元で対応する配管や設備が見えるとごちゃごちゃした2次元配管計装図もわかりやすくなる・・・
Yoshihiro Fukuhara retweeted
DeepSeekは、自社の推論フレームワークDeepInferを公開するとともに、DeepSeek V4.1 Flashの大規模推論システムに関する技術報告も公開した。
この報告によれば、V4.1 Flashは単一クラスタで1日あたり155兆トークンを処理し、GPUあたり毎時38ドルのAPI売上換算値を達成している。また、Decodeのベンチマークでは、GPUあたり毎秒14,466トークンという出力スループットを報告している。
この報告では、PrefillとDecodeの分離、Expert Parallelism(EP)、KVキャッシュの長期保存、投機的デコード、負荷分散などについて、実際の運用を踏まえた設計が詳しく説明されている
* PrefillとDecodeの並列化
PrefillではExpert Parallelism(EP)を2〜8、Data Parallelism(DP)を2〜8とし、モデルの重みがHBMに収まる範囲で、できるだけ小さいEPを利用する。
DecodeではEP64〜128、DP64〜128という大規模な並列化(Wide EP)を採用している。
V4.1 Flashは各MoE層に256個のRouted Expertを持つためEP64であれば、単純に均等配置した場合、GPUあたり平均4個のExpertが配置される。人気のあるExpertを複製し、各GPUの負荷に応じて再配置するExpert Parallel Load Balancing(EPLB)も導入している。
このようにEPを大きくすることで、各GPUが読み込むExpert重みの量を減らし、同時に多数のトークンを集約してExpertのGEMMを効率化できる。一方で、GPU間通信の負担は増えるため、通信側の負担は大きくなっている。
* KVキャッシュの長期保存と再利用
本番トラフィックでは、入力長の平均が77Kトークンで、そのうち約96%がキャッシュヒットしていると報告されている。
KVキャッシュは分散ファイルシステム3FS上に保存され、どのPrefillノードからでもアクセスできるように設計されている。これにより、リクエストを特定のGPUに固定する必要がなく、柔軟な負荷分散が可能になる。
また、Sliding Window Attention(SWA)はキャッシュ再利用時に必要な状態を厳密に再構築するには、層数分だけ、より長い範囲の再計算が必要になるが、そこを直近128トークンだけの再計算に置き換えている。これは近似だが、Prefill全体の計算量をほぼ半減できると報告している。
* GPUあたりの処理性能と売上
DeepSeekは、GPUあたり毎時38ドルのAPI売上換算値を報告している。これを単純に年間換算すると、GPUあたり約33万ドル(1ドル150円換算で約5,000万円)となる。
主要な処理性能は次の通りである。
- Prefill処理量(キャッシュ込み):約150万トークン/秒/GPU
- Prefill処理量(新規計算):約6万トークン/秒/GPU
- Decode処理量:約14,000トークン/秒/GPU
- Decode同時実行数:約60系列/GPU
- 1ユーザーあたりのDecode速度:約230トークン/秒
- PrefillとDecodeのGPU数:約1対1
これらの値とAPI料金を組み合わせると、GPUあたり毎時38ドルという売上換算値と概ね整合する。
1日155兆トークンという処理量からGPU規模を逆算すると、上記のスループットを継続的に達成できるという仮定のもとで、Prefill約1,200基、Decode約1,200基、合計約2,400基という規模が推定される。
この構成が年間を通じて同じ稼働率と売上単価を維持した場合、年間売上換算値は約8億ドルとなる。
例えば、GPU原価を毎時5ドル、その他のインフラ原価を毎時3ドルと仮定すると、GPUあたり毎時38ドルの売上に対して粗利益率は約79%となる。これは原価を仮定した試算であり、実際の利益率を示すものではないが十分採算がとれていることを示している。
* GPUの演算効率
次に、Decode性能をB200やGB200のピーク演算性能と比較してみる。
V4.1 FlashのDecode時のActive Parametersを16Bとすると、1トークンの主要な行列積演算量は約32 GFLOPsとなる。
GPUあたり14,466トークン/秒で生成する場合、出力トークンに対応する演算量は約463 TFLOPS/GPUである。
さらに投機的デコードにおける検証トークンの増加を考慮すると、主要モデルの演算量は約516 TFLOPS/GPUと推定される。
これはB200やGB200のFP8・FP4ピーク演算性能に対して約5〜12%に相当する。
また、GPUあたり60系列を同時に処理し、投機的デコードによって1ステップで平均3.21トークンを生成するとすると、1ステップの処理時間は約13.3ミリ秒と推定される。
* HBM帯域とExpert重みの読み込み
メモリ帯域の観点からも考えてみると、仮に552BパラメータをすべてFP4で格納し、EP64で均等に分割すると、GPUあたり約4.31 GBの重みを保持することになる。
これを1ステップごとにすべて読み込むと仮定すると、13.3ミリ秒のステップ時間で平均約324 GB/sの読み込み帯域が必要になる。
B200のHBM帯域は約8 TB/sなので、ステップ全体で平均すればピーク帯域の約4%に相当するので十分間に合う上、重みの読み込みとGEMMは一部をオーバーラップできる。
ただし、13.3ミリ秒の間にはAttention、Expert間通信、GEMMなどの処理も必要であり、重みの読み込みに13.3ミリ秒すべてを使えるわけではなく、例えば重み読み込みに使える時間が1ミリ秒しかないなら、必要帯域は4.31 TB/sとなり、B200のピーク帯域の約54%を使用する計算になる。
* SSDを利用したKVキャッシュ保存
今回の推論インフラでSSDは中心的な役割をはしている。
推論中のKVキャッシュと状態はGPUのHBMに保持される。一方、SWAのKVキャッシュはCPU RAMに、Paged Block KV Cacheは3FS上のSSDに保存される。
SSDはDecode中のKVキャッシュをHBMから退避させるためではなく、主に数日間にわたるPrefixの再利用に使われる。
本番システムでは、KVキャッシュ用のSSDストレージを約100 PiB確保しており、GPUあたりの論理ストレージ容量は約14.4 TBである。
キャッシュ保持期間は、Agentトラフィックで3日間、Chatbotトラフィックで7日間に設定されている。
また、キャッシュヒット率は約96%である一方、API料金ではキャッシュヒットした入力トークンと新規計算が必要な入力トークンの価格差が50倍に設定されており、Prefill売上においてキャッシュヒットした場合とそうでない場合がちょうどバランスされている。
コメント
===
今回の報告は、現在の大規模LLM推論インフラについて、実際の利用状況と、それを支えるシステムの構成や設計上の工夫を具体的に示している点で参考になる。
KVキャッシュをSSD上に長期間保存してPrefillの再計算を削減し、Decode側でWide EPを採用してExpert重みの読み込み負担を減す上、単に推論カーネルを高速化するのではなく、ストレージ、通信、負荷分散、投機的デコードまで含めて最適化することで、システム全体のスループットと経済性を改善している。
また、推論フレームワークDeepInferが公開されたことで、今後コミュニティによる性能検証や改善が進むことも期待できる(ただし、本番で使われているKVキャッシュ管理や負荷分散システムなどは公開されていないようである)
























