ハクソク

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

LLMは今や複雑になった

2026年6月20日原文(ianbarber.blog)

概要

  • Meta における2022～2023年の機械学習の潮流
  • LLMとレコメンデーションシステム の複雑化の比較
  • Attention機構 やMixture-of-Expertsなどの多様化
  • パフォーマンス最適化 と 柔軟性 の両立課題
  • Composable設計 の重要性と最新事例

Metaにおける機械学習の進化と複雑化

  • 2022年から2023年、Metaでは2つの大きな機械学習分野が進行
    • LLM（Llamaに繋がるTransformerベースのスタック）
    • レコメンデーションシステム（複雑なグラフ構造）
  • 当初、LLMは シンプルなTransformer構造 で構成
  • レコメンデーションシステムは 複雑で難解な構造 が特徴
  • 業界全体で LLMも急速に複雑化 し、Attentionバリアントの多様化が進行
    • Query grouping、Compressed、Sparse、Linear、Sliding-windowなど
  • Mixture-of-Expertsの導入により、 Feed-forward層やAttentionブロック、Residual stream まで選択的ルーティングが拡大
  • VisionやAudioエンコーダ も統合され、マルチGPU推論が一般化
    • 通信処理によるモデル内部の境界発生

レコメンデーションシステムのアーキテクチャと課題

  • レコメンデーションシステムの基本構造は 二塔型スパースニューラルネット が主流
  • 複雑さの根源は 能力向上と効率性（特に推論） の両立要求
  • 最適化が必須 となり、性能改善が直接的な必要条件へ
  • モデル定義の純粋性 を保ちつつも、実運用では リソース負荷と性能向上 が不可分
  • Attentionバリアントの交換は、 性能劣化の許容範囲 が限定的
    • 10%遅延は許容、1桁違いの遅延は不可
  • 最適化済みA と比較するには、 Bも部分的に最適化済み である必要
  • 研究開発サイクルには 柔軟性 が必須
    • 手作業の最適化と自動生成の両立が課題

Composability設計の重要性と実践例

  • Composable設計 が唯一の解決策
    • 事前に組み合わせ可能かつ検証可能な設計が求められる
  • PyTorchの FlexAttention は注目のカーネル開発事例
    • 多様なAttention操作をTritonテンプレートでカーネル自動生成
    • パフォーマンスへの影響を最小限に抑えつつ、探索と検証が容易
  • Andrej KarpathyのAnthropic参加も 自動研究ループ の発展が目的
  • Composableアーキテクチャ の本質的な簡素化が、エージェント的アプローチと同等以上に重要
  • Content UnderstandingとIntegrity に従事する小規模チームにも言及

今後の展望とまとめ

  • Composable設計 の推進が、今後のLLMやレコメンデーションシステムの発展に不可欠
  • 最適化と柔軟性 の両立を実現するための設計思想の変革
  • 研究サイクルの高速化 と 実運用性能の両立 に向けた技術進化

Hackerたちの意見

なんでこの著者は、もっと標準的なアテンションベースのLLMであるGLM 5.2（1週間前にリリースされた）とLlama 3を比較しなかったんだろう？ 2つの異なるLLMファミリーを比較して、それが違うって指摘するのは驚くべき結果じゃないし、著者が言いたいことからずれてる気がする。 https://sebastianraschka.com/llm-architecture-gallery/?compa... 見てみると、図はすごく似てるけど、主な違いはフィードフォワードがMoE（複数のフィードフォワードへのルーター）に置き換えられていて、モデルのアテンション実装が違うってことだね。

└

AIが書いたんだよね。

└

見てみると、図はすごく似てる。あなたがリンクしてるのと同じサイトに繋がってるよ。似てるのも当然だね、ソースが同じなんだから！

└

そうだね、あんまり良い比較じゃないね。MoEや複雑なアテンションアプローチ、共有レイヤー、いろいろあるけど、全部をうまく連携させるのは小さいモデルでも大変な試行錯誤だし、効率的なハードウェア利用に至るのはもっと大変だよね。

└

著者の言う通り、モデルアーキテクチャは今やずっと複雑になってる。llama.cppを使ってプロジェクトを追ってみればわかるよ。以前のモデルは常に完全に実装されてたけど、今はたくさんの最新モデルが部分的な実装しかされてない。DeepSeekv3.2は完全には実装されてないし、KimiK2.6も同様、GLM5.2+、DeepSeekv4は実装なし、MiniMaxM3はまだサポートされてない、Hy3-previewも実装なし。最新モデルは基本的な機能だけで、進んだ機能のサポートがたくさん欠けてるんだ。

└

なんでこの著者は、もっと標準的なアテンションベースのLLMであるGLM 5.2（1週間前にリリースされた）とLlama 3を比較しなかったんだろう？ 2つの異なるLLMファミリーを比較して、それが違うって指摘するのは驚くべき結果じゃないし、著者が言いたいことからずれてる気がする。この比較の全体のポイントは、LLMが以前とは全然違って見えるってことなんだ。もっと似たLLMを比較するのは、著者が言おうとしてたことからずれると思ったよ。

これはフィーチャーエンジニアリングの苦い教訓だね。技術や手法が新しいときは、特定のユースケースに適用したり、トレーニング用のデータを集めたり、リソースを増やしたりするだけで大きな成果が得られる。でも、時間が経つにつれて、その「苦い教訓」の成果はロジスティック曲線の浅い部分に達して、企業は小さな増分の成果を得るためにますます多くの努力を投資しなきゃいけなくなるんだ。

└

うまいこと言ったね、ありがとう。

└

これについては、実際には現職の利点の問題にかなり近いメッセージを受け取りました。既存の技術はパフォーマンスの最適化が進んでいて、新しい技術が自分たちの方が優れていると証明するのが難しくなっています。これはガソリンエンジンと電気エンジンの問題に似ていますね。ガソリンエンジンの周りには100年の最適化とエコシステムの発展があったので、電気モーターは優れているにもかかわらず、その巨大なエコシステムがないために苦戦しています。ただ、ここでは問題はそれほど深刻ではなくて、ソフトウェアはハードウェアよりもずっと柔軟ですし、スケーリングの法則があるおかげで、全力で取り組む前に小規模で試すことができるのが良いですね。

└

「苦い教訓」というフレーズの選択は意図的な皮肉だと思います（だって元々の概念は、ドメイン特有の知識を使わずにスケールアップすることでより良い結果が得られるってことですよね？）

  • 失礼ですが、UXの観点から、ブログ記事のタイトルだけを一覧で見られるページを追加してもらえませんか？ - https://ianbarber.blog/blogroll - https://ianbarber.blog/archive - https://ianbarber.blog/blog - https://ianbarber.blog/posts - 上記のリンクはどれも機能していません - 200ページもスクロールして、ブログ記事が何かを見るのは本当に嫌なんです。
└

笑、今のところ一番いい手は彼らのフィードを取得して、サクサク進めることかな。

Hacker Newsで議論の続きを見る