Show HN: LLM推論速度を2倍に向上できる可能性 (Speeding up LLM inference 2x times (possibly))

 (asciinema.org)
1 ポイント 投稿者 GN⁺ 2024-04-19 | 1件のコメント | WhatsAppで共有

Effortとは何か?

  • Effortとは、何かを成し遂げたり目標を達成したりするために投入されるエネルギー、時間、資源を指す
  • これは、障害を乗り越えたり望む結果を得たりするために必要な努力や骨折りを意味する
  • Effortは物理的な場合もあれば、精神的な場合もある
    • 重い物を持ち上げたりマラソンを走ったりするのに使われるエネルギーのような物理的努力
    • 複雑な問題を解決したり新しい技術を学んだりするのに必要な集中力や精神力といった精神的努力
  • 個人の成長、職場、教育など、さまざまな人生の領域で成功を収めるための重要な要素である

GN⁺の意見

  • Effortは単に投入する時間やエネルギーの量だけでなく、持続性や集中力、モチベーションなどさまざまな要素が複合的に作用する概念である。したがって、一生懸命努力したからといって必ずしも成功が保証されるわけではない
  • 特に精神的なEffortを要する作業では、burn outに陥らないよう注意する必要がある。適切な休息と報酬を通じてEffortを持続できる方法を見つけることが重要である
  • 人によってEffortのかけ方は異なる場合がある。短期間に集中的に取り組める人もいれば、長期的に着実にEffortを投入できる人もいる。自分に合った方法を見つけるのが効果的である

関連記事

1件のコメント

 
GN⁺ 2024-04-19
Hacker News の意見

  • アルゴリズムの核心は、実行中にパラメータを枝刈りし、各グループ内で枝刈り対象の重みの絶対値の順位によって重要度の低い重みを決めて 0 にし、重み行列を疎にすることのように見える
    モデルの枝刈りで検索すると多くの結果が出てくるし、https://arxiv.org/abs/2305.11627 も「大きさベースの枝刈り」をベースラインとして扱い、https://arxiv.org/pdf/2301.00774.pdf を引用している
    論文がベースラインを雑に実装しておいて自分たちの手法を誇示したり、数学用語を大量に使って飾り立てたりするやり方はあまり好きではない。元記事のブログ記事は、背景知識がほとんどない人にも手法をはるかに分かりやすく伝えている

    • この1か月は、研究をできるだけ再現可能で信頼できるものにすることに費やした。元の実装は非常に非効率で、Metal/GPU の行列積演算が速くなった後も、ベンチマークをしやすくするため、残りの実装をできるだけ Llama.cpp に近づけるのに多くの時間を使った
      言及された論文のアプローチは静的な方式に見えるし、20〜50% の結果で実際の計算を高速化するアルゴリズムは提示していないように思う。そこが難しい部分の大きな割合を占めていた。いつか時間を取って関連文献をきちんと読み通すつもりだ
      最終的には、人々がコメントに投稿した論文とともに引用ページを追加したい。近いうちに誰かが、このアルゴリズムをすでに整理している記事を見つけるかもしれないとも思っている
      開発中に gpt-4 にも聞き、Google 検索もしてみたが、見つかったものは概ね静的なものか、全体の次元/レイヤーを任意に削除してから再学習するものだった。このアイデアと正確に一致するものは見つけられなかった
    • 「数学用語を大量に使って自分たちの手法を飾り立て、ベースラインをお粗末に実装する」というのは、悪い論文の兆候に見える
      文章が密で理解しにくいほど、その中に粗悪な科学を隠している可能性が高くなる

  • GPU 実装部分のこの一文がよかった
    「GPU プログラミングが初めての読者は、ここでこう尋ねるかもしれない――これはどう動くのか？
    GPU プログラミング経験のある読者は、こう尋ねるかもしれない――いったいどうやってこれが動くのか？」

    • 理解したところでは、メモリ読み出しなどいくつかの点を、一般に正しいアプローチと考えられている方法とは逆に実装する必要があった
      Metal を実際によく知っている人に、このコードをレビューしてもらえたらうれしい。今回が初めての GPU プログラミングの試みだった

  • 「行列をひっくり返し、要素を行単位でソートしてから、乗算をその方向から見直してみよう。賢い人たちはこれを圧縮疎行（CSR）形式と呼ぶ。これで乗算するには、ベクトルの 1 を取り出して 256 を掛け、出力ベクトルの 3 行目に加える、という具合に進める。では、最も低い値がある最後の列を切り落とすと何が起きるかを見てみよう。」
    CSR が乗算回数を減らす仕組みと、これがどう噛み合うのか気になる

    • 質問を言い換えてもらえる？ うまく理解できなかった

  • この方式は半構造化スパース性、いわゆる 2:4 スパース性に似ているように見えるので、明示的に比較する価値がありそうだ。ざっと見たところ、この手法は Apple Silicon に最適化されており、75% のスパース性で約 2 倍の速度、入力に応じてランタイムに適用される動的方式で、スパース性の度合いを選べる
    一方、2:4 半構造化スパース性は、スパース Tensor Core を持つ GPU、つまり Nvidia Ampere 以降に最適化されており、50% のスパース性で約 2 倍の速度、モデルの保存状態で適用される静的方式であり、50% のスパース性ではこの手法より結果が悪い可能性が高い
    見てみたい比較は、半構造化スパース性の 50% スパース性・2 倍高速化の結果と、この手法の 75% スパース性・2 倍高速化の結果だ

    • 確認してくれてありがとう。もっと多くのテストが早く出てくることを私も期待している
      Apple Silicon を選んだのは開発しやすかったからだ。このアルゴリズムが他のアーキテクチャでも良い性能を出せる可能性はある

  • CSR を使ったことがある立場からすると驚きはない。より新しい形式の中には、block ELL のようにハードウェア特性により合うものもあるかもしれない
    そうした形式は、結合されない読み出しや gather を避けられるが、コードはより厄介になる

    • CSR 経験者にようやく会えてうれしい
      bucketMul は結合されない読み出しがほとんどなく、通常の CSR とは異なるデータ構造を使っている。ここで説明している: https://kolinko.github.io/effort/bucketmul.html
      各行列行を 16 個の部分に分け、どの部分を読むべきかを選択する。書き込みは完全に線形だ
      ただ、今自分の言っていることが筋の通った話なのかはよく分からない。今日は少し遅いし、長い一日だった

  • 良いアイデアで、良い記事です。自分もニューラルネットワーク推論におけるスパース性の分野を扱っているのですが、知っておくとよさそうな点がいくつか思い浮かびました
    密な行列ベクトル積の実装と比べると、このアルゴリズムはアルゴリズム上の複雑さを増す一方で、メモリトラフィックを減らします。行列ベクトル積は通常メモリがボトルネックなので、メモリアクセスを減らせばスループットが上がります。ただしバッチサイズが1より大きくなると、もはやメモリアクセスがボトルネックではなくなり、速度向上はかなり早く消えてしまう可能性が高いです
    比較対象としては、同じモデルだけでなく、2倍速いアーキテクチャの別モデルも見てみたいです。たとえば13BパラメータのLLMにこの手法を50%スパース性で適用した場合に7BパラメータのLLMと比べてどうか、基準ビット幅の半分に量子化した同じLLMと比べてどうかが気になります。同じ時間内に既存の推論フレームワークより高い忠実度の出力を示せるなら、興味深い論文ネタになりそうです
    乗算を省略するので、近似誤差は実際の結果よりも常に絶対値が小さくなる方向に偏る可能性が高いです。その系統的な誤差を補正する補正項を加えられるなら、性能がもう少し良くなりそうです

    • アルゴリズムの複雑さが実際に増えるわけではありません。乗算は O(effrt * inDim * outDim)、ディスパッチ計算は O(inDim)、カットオフ地点の探索は O(~inDim * log inDim) です
      ビッグO記法はGPU処理にはあまり向いていませんが、この場合はおおむね合っています
      主な問題はGPUのアーキテクチャ上の制限です。このアルゴリズムは従来方式よりもレジスタ/スレッドグループ/キャッシュメモリを多く必要とし、それが主なボトルネックになります。また、すべての乗算が異なるバケットを使うため、MoEモデルのように処理を並列化するのは単純ではありません
      より大きなアーキテクチャについては、実質13BモデルであるMixtralでかなりテストしており、私の感触ではそこでずっとよく持ちこたえます。effortに対する推論速度も維持され、effortに対する品質は20〜25%ではなく12〜16%まで、読める結果を維持します。テストは限定的で、Mistral実装を入れているうちにMixtral実装を壊してしまったので確かなデータはありませんが、近いうちに直す予定です
      直感的には、モデルが大きいほどeffortをより多く削れると見ています
      乗算を省略するとバイアスが生じるだろうというのは、私も最初はそう推測していましたが、直感に反してそうではありませんでした。グラフはいくつかありますが、まだ公開用には準備できていません
      行列の値が正と負に均等に分布しているため、特定のしきい値以降では結果値のドリフトは大きくありません

  • 素晴らしそうです。ただ、15msの遅延は60Hz垂直同期の16.7msに近いです
    トークンごとに画面を更新しているなら、どこかで同期がかかっている原因かもしれません

    • それではありません。CPUとGPUの処理は別々に測定していて、15msはカーネル呼び出しの間で発生しています。テキストを出力しなくても発生します
      それでもアイデアありがとう。最初のコミュニティ貢献として受け取ります :D

  • 本当に素晴らしく、オープンな貢献です。llama.cppがこれを実装するか注目して見ていくつもりです
    CPU推論を高速化する方法を探していたのですが、effortというアイデアが本当に気に入りました

    • これを開発するのはマラソンのようで、メインページに載ってうれしいです
      名前はchatgptが提案しました。このアプローチを認識できないと言っているので、本当に新しいものなのかもしれません
      llama.cppや他のプロジェクトにも連絡してみたいですし、実装されるとうれしいです。自分でllamaにパッチを書こうかとも考えましたが、C++とそのプロジェクトの規模は私には手に余りました
      CPU推論も同様に速くなるはずです。さらに重みの一部だけ、たとえば重要度の低いものをスキップして70%だけロードできるので、以前より少ないVRAMでモデルを実行できるはずです。ただしQ8実装はまだ必要です
      面白いことに、llama.cppとベンチマークを比較しようとしたとき、MB Air 16GBでの7B/FP16の速度を見つけられませんでした。通常の方法では実行不可能だからです。Effortなら可能です
      同様に、96GB M2でフル解像度ながら切り詰めたMixtralを動かしました。通常はRAM 114GBが必要ですが、重みの75%だけロードしたところスムーズに動作しました。今は実装を少し壊してしまい、ゴミのような出力を出しているので修正が必要です

  • 良い記事です。単純な量子化と比べてVRAMあたりの性能がどうなのか、本当に気になります
    クロスプラットフォーム版を実装する計画があるのかも気になります

    • VRAMあたりの性能は大きくは良くありません。依然としてすべての重みを使うものの、常に全部使うわけではない構造だからです
      もちろん重みのロード量を減らすこともできますが、重みを20〜30%を超えて削ると品質が急速に悪化するようです
      つまり、このアルゴリズムは推論時間をVRAM使用量から切り離します
      それでも、effortを使えば75%に切り詰めたQ8がQ6より良い結果を出せるのかは、私も気になります
      ただし、実装を十分に磨いてきちんとテストするには、まだ数週間はかかりそうです

  • この方式は再学習しませんが、こうしたアプローチと量子化を併用し、後で追加学習すれば、失われた品質を一部取り戻せるのか気になります
    こういうものを見るのは楽しいですし、今後性能とコストがどれほど改善され得るのかを頭の中で描けてよいです。オープンソースで開発してくれてありがとうございます

    • ぱっと見では可能そうです。読んだ限りでは、量子化で品質を一部取り戻す主な方法は2つあります
      1つは後から行う事後学習で、もう1つは学習中に量子化しつつ、活性値と勾配は全精度のままにする量子化認識学習です