PyTorchで書いたMLPの速度に疑問を持ったとき、何を根拠に改善を判断するか。
Profiling in PyTorch (Part 2): From nn.Linear to a Fused MLP は Hugging Face ブログのプロファイリングシリーズ第2回。nn.Linear で構成した標準的な MLP を torch.profiler で計測し、ボトルネックの所在を可視化しながら、カーネル融合（kernel fusion）による fused MLP への移行を実演する。GPU上での演算コストが、コードの見た目とはまったく異なる場所にあることを数字で示す内容だ。
nn.Linearが隠すコスト
nn.Linear は行列積・バイアス加算・活性化関数をシンプルに繋ぐ。コードの見通しはよいが、プロファイラを通すと別の景色が現れる。各演算は独立したCUDAカーネルとして実行され、そのたびにGPUのHBM（高帯域メモリ）とデータをやり取りする。演算の速さよりも、メモリのラウンドトリップが支配的なコストになる——これが計測によって初めて可視化される構造だ。
融合が効く理由
カーネル融合は複数の演算を1つのカーネルにまとめる手法。行列積の直後に活性化関数を同一カーネル内で処理すれば、HBMへのアクセスは一度で済む。プロファイラが「ここがメモリバウンド」と示した後なら、融合を導入する根拠は明確だ。勘でなく計測が、選択を正当化する。
最適化の前にプロファイリングを行う——という順番は、実は逆に理解されがちだ。プロファイリングは「どこを速くするか」を決める作業ではなく、「なぜ遅いか」の前提を壊す作業でもある。torch.profiler で見えてくるのはコードの問題ではなくアーキテクチャ上の選択の問題——その視点の転換が、fused MLP への移行を単なる速度改善ではなく、構造的な判断として位置づける。
出典: Profiling in PyTorch (Part 2): From nn.Linear to a Fused MLP — Hugging Face Blog
関連記事
- Making secret scanning more trustworthy: Reducing false positives at scale
- GitHub availability report: May 2026
- Our new community investments in Virginia support local jobs and expand energy affordability.
参考文献
コメント