ハクソク

世界を動かす技術を、日本語で。

Fp8は、カーネル名に「cutlass」が含まれている場合、約100テラフロップス速く動作します。

235日前原文(github.com)

概要

  • broadcast時のレイアウト不一致 によるValueError発生
  • BlockedLayout と DistributedLinearLayout の不整合
  • layout inference の動作に疑問点
  • p が意図せずlinear layoutを持つ問題
  • 問題原因と解決策の概要説明

ValueError: Layout Mismatchの原因と対策

  • broadcast演算 時、 入力テンソルのレイアウト が一致していない場合にエラー発生
  • 片方が BlockedLayout （例: size_per_thread=[1, 128]）で、もう片方が DistributedLinearLayout （例: reg_bases, lane_bases等）であることが直接の原因
  • layout inference は通常、可能な限り BlockedLayout を優先推定
    • しかし、入力や演算の条件によっては linear layout が選択される場合あり
  • p がlinear layoutになる主な理由
    • 入力テンソルや中間テンソルの shapeやlayout情報 が不十分
    • 明示的なlayout指定 が不足
    • 演算グラフの途中でlayoutが崩れる ケース
  • 解決策
    • 入力テンソルに明示的なBlockedLayoutを指定
    • layout inferenceの設定やパラメータ を再確認
    • テンソル演算前後でlayoutをprint して確認、デバッグ
    • 必要に応じて layout変換演算（re-layoutやreshape） を追加
  • 設計時の注意点
    • 異なるlayout間のbroadcastは不可、明示的なlayout管理が重要
    • layout inferenceのアルゴリズムや優先順位 をドキュメントで確認推奨

layout inferenceの挙動と調査方法

  • layout inference は、デフォルトで 効率的なBlockedLayout を選択する設計
    • ただし、 条件不一致や情報不足 でlinear layoutにフォールバックする仕様
  • layout inferenceの挙動調査方法
    • 中間テンソルのlayout情報を逐次print
    • 演算ごとにlayoutの推移を可視化
    • ドキュメントやソースコードでlayout inferenceのロジックを確認
  • 再現手順の整理
    • 問題が発生した コード断片やテンソル情報 を整理
    • layout inferenceが期待通りBlockedLayoutを選んでいるか を逐次検証

まとめと推奨アクション

  • layout mismatchエラー は、 layoutの明示指定不足や推論結果の不一致 が主因
  • BlockedLayoutを明示指定 し、 layout inferenceの挙動を逐次確認 することで解決可能
  • broadcast演算前に両テンソルのlayoutを揃える ことが不可欠
  • layout inferenceのロジックやドキュメントの再確認 を推奨

Hackerたちの意見

これについてはPRが作成された時に話し合われたことがあって、今のところ新しい情報は見当たらないね。

└

なんか見覚えがあるなと思ったら…

https://github.com/triton-lang/triton/pull/7298#discussion_r... > ptxasの逆アセンブルによると、確かに「strstr(kernel_name, "cutlass")」のようなロジックがハードコーディングされてる。 > これはおそらく、NVIDIAによる不安定で実験的な攻撃的最適化で、盲目的に常に有効にすると、 elusiveなバグが発生する可能性があるね。

└

ちょっとした背景をありがとう。これは全然私の得意分野じゃないし（このプロジェクトのことも聞いたことない）、タイトルやリンクされたPRの内容も全く分からなかったよ。

コミットメッセージはリアルに保ってるね。

└

毎回「Xをリファクタリングしました」って言うAI生成のコミットメッセージより、こっちの方が断然好きだな。

└

スクワッシュしてもいいと思うよ。でも、なんでGitHubにプッシュする前にスクワッシュしなかったのかは全然分からないけど。

└

ここで著者のdiffの構成について批判があるね。「約100 tflops速くした」って言ってるのに、みんなのコメントは「コミットメッセージが悪い」って？ジョン・カーマックの働き方を知ったら、みんな嫌がるだろうね。

へへ。25年近く前にATI（AMD）がQuake IIIのベンチマークを操作して、実行ファイルの名前を「quack」に変えたのを覚えてる人いる？ https://web.archive.org/web/20230929180112/https://techrepor... https://web.archive.org/web/20011108190056/https://hardocp.c... https://web.archive.org/web/20011118183932/www.3dcenter.de/a...

└

IntelがICCの出力で「GenuineIntel」をチェックしてるってさ: https://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler#Support...

└

もし同じようにその文を解釈した人がいたら、atiが「quake」を実行ファイルとして検出して、テクスチャの品質とかを変更してベンチマークのパフォーマンスを上げたってことね。実行ファイルを「quack」に名前を変えたら、画質が良くなったけどベンチマークは下がったっていうのを何人かが発見したんだ。つまり、atiのドライバーは品質を下げることで「最適化」してたってことが証明されたわけ。最初はquakeをquackに名前変更したのかと思ってたけど、そうじゃなかったんだ！ :)

└

あのtechreportの記事の画像がそのまま残ってるアーカイブってある？

└

この件についてもっと詳しく話したいなら、ここを見てね: https://news.ycombinator.com/item?id=44531107 面白いことに、同じカットラスの最適化に関する古い投稿の下にあるんだ。

└

これ、意外とよくあることだよね。電話のチップセットメーカーが電話のベンチマークでやったり [0]、VWが排出ガスでやったり [1]、nVidiaが3DMarkでやったり [2]、IntelがXeonプロセッサのSPECベンチマークでやったり [3]。コンピュータグラフィックスに関しては、確かに今は結構普通になってるよね。グラフィックドライバーは、どのゲームにも調整や設定、最適化、回避策があるみたいだし。（余談だけど、archive.orgにリンクしなきゃいけないのが嫌だな。最近は死んだリンクが多いけど、これらは覚えておくべき重要なことだよ） [0] https://web.archive.org/web/20250306120819/https://www.anand... [1] https://en.wikipedia.org/wiki/Volkswagen_emissions_scandal [2] https://web.archive.org/web/20051218120547/http://techreport... [3] https://www.servethehome.com/impact-of-intel-compiler-optimi...

nil novi sub soli. - Intelは2024年初頭にSPECがIntel Xeonプロセッサの2600以上のベンチマーク結果を無効にしたことで「不正コンパイラ」の論争に直面した。 ( https://www.tomshardware.com/pc-components/cpus/spec-invalid... ) - microsoftも似たようなことをやってるし (JavaのベンチマークやCコンパイラのベンチマーク) - みんなAIのベンチマークで不正してるし (https://www.thestack.technology/ai-benchmarking-scandal-were...)

私はコンパイラを扱ってるんだけど、あんまり良くないけど、いくつかの最適化は型や関数名のスキーマや部分文字列に依存してるんだ。嫌なことだけど、そういうもんなんだよね。悪意があるわけじゃないけど、自分のライブラリだけに最適化を適用する方が、壊れるリスクを冒すより安全なこともあるし。フロントエンドが信頼できるデータをもっと提供してくれないこともあるしね。

└

悪意があるわけじゃないと思うけど、確かに新しい障壁を作っちゃうよね。それは良くないことだ。

10年くらい前の特定のWebpackのバージョンを思い出すな。add.svgっていうSVGがあるとビルドが失敗して、plus.svgに名前を変えなきゃいけなかったんだよね。

└

自分が書いた「secret.py」っていう小さなファイルからAPIキーをインポートしてnumpyをぶっ壊すとかね :P

LBDマジで(690) __ VN5

バイナリブロブドライバーのクソみたいなことをやらずに、コードを共有できる経済が見つかればいいのに。ベースバンドや他のことも同じ。私たちの社会の優秀な頭脳が、バイナリブロブやIOピンを通じてコントローラーをリバースエンジニアリングしたり、回路図を逆解析したりするのに、どれだけの時間と月が無駄になったか。これらはどこかのコンピュータにすでにあるのに、ドキュメントをただくれればいいのに。CUDAとNVIDIAは地獄にでも行ってほしい。

NVIDIA Jetsonシステムで作業してたときのことを思い出すな。使い方を学んでたんだけど、1コマンドで全てを速くできるっていうのがあったんだよね…（https://jetsonhacks.com/2019/04/10/jetson-nano-use-more-powe...）