LLaMAがCPUでさらに高速化

2024年3月31日 @ justine's web page LLaMAがCPUでさらに高速化 Mozilla llamafile 私が書いた84個の新しい行列乗算カーネルがllamafileに組み込まれ、プロンプト/画像の読み込み速度が向上しました。llama.cppと比較して、F16およびQ8_0ウェイトをCPUで使用した場合、llamafileのプロンプト評価時間は30%から500%高速になるはずです。改善は、ARMv8.2+（例: RPI 5）、Intel（例: Alderlake）、およびAVX512（例: Zen 4）コンピューターで最も顕著です。私のカーネルは、L2キャッシュに収まる行列に対してMKLの2倍の速度を達成しますが、これはプロンプトが1,000トークン未満の場合に最も効果を発揮するため、まだ開発途上です。 背景 llamafileは、私が2023年11月にMozillaと開始したローカルLLMプロジェクトです。Cosmopolitan Libcを使用して、llama.cppを単一ファイル、クロスプラットフォームのバイナリとしてパッケージ化しており、6つのOSでAMD64とARM64で動作し、軽微な変更を加えています。コア技術を改善することで、ユーザーに最高のllama.cpp体験を提供し、両プロジェクトがより広範なオーディエンスにリーチできるようになると信じています。Mozillaは私にそのためのリソースを提供してくれています。 エンタープライズハードウェアでのパフォーマンス向上 LLMに初めて取り組んだとき、私のワークステーションは、Alpine Linux、スピンドルディスク、低速RAM、AVX2プロセッサ、GPUなしの質素なHewlett Packardでした。llama.cppの気に入っていた点は、私のような人々を気にかけてくれた最初のLLMプロジェクトだったことです。そこで私はフルタイムでボランティアとして参加し、Slarenのような人々と協力してmmap()サポートを導入しました。これにより、RAM使用量を半分に抑えつつ、ウェイトのロードが瞬時に行えるようになりました。当時はローカルLLMにとって大きな進歩でしたが、評価速度の向上にはほとんど貢献しませんでした。推論コードのほとんどはGeorgi Gerganov自身によって書かれており、それは非常に優れているため、私がそれを改善するにはさらに1年かかるでしょう。今、改善したので、古いHewlett Packardでどれだけ速くなるか見てみましょう。 LLMパフォーマンス on HP Intel® Core™ i9-9900 ($439) w/ 2200 MT/s RAM c. 2020 | プロンプトトーク/秒 | 評価トーク/秒 | モデル | ウェイト | データ型 | ハードウェア | ソフトウェア | |---|---|---|---|---|---|---| | 28 | 7 | Mistral 7b | q4_0 | Skylake | llamafile-0.7 | | 17 | 7 | Mistral 7b | q4_0 | Skylake | llama.cpp 2024-03-26 | | 12 | 7 | Mistral 7b | q4_0 | Skylake | llamafile-0.6.2 | | 32 | 4 | Mistral 7b | q8_0 | Skylake | llamafile-0.7 | | 22 | 4 | Mistral 7b | q8_0 | Skylake | llama.cpp 2024-03-26 | | 16 | 4 | Mistral 7b | q8_0 | Skylake | llamafile-0.6.2 | | 23 | 2 | Mistral 7b | f16 | Skylake | llamafile-0.7 | | 15 | 2 | Mistral 7b | f16 | Skylake | llama.cpp 2024-03-26 | | 14 | 2 | Mistral 7b | f16 | Skylake | llamafile-0.6.2 | | 205 | 26 | TinyLlama 1.1B | q8_0 | Skylake | llamafile-0.7 | | 144 | 26 | TinyLlama 1.1B | q8_0 | Skylake | llama.cpp 2024-03-26 | | 91 | 23 | TinyLlama 1.1B | q8_0 | Skylake | llamafile-0.6.2 | | 171 | 15 | TinyLlama 1.1B | f16 | Skylake | llamafile-0.7 | | 118 | 15 | TinyLlama 1.1B | f16 | Skylake | llama.cpp 2024-03-26 | | 101 | 15 | TinyLlama 1.1B | f16 | Skylake | llamafile-0.6.2 | ここでは、Skylakeにおいてllamafileユーザーは2倍の速度向上、llama.cppユーザーは50%のパフォーマンス向上が期待できることがわかります。これは特定のウェイトにのみ適用されることに注意してください。現時点では、q8_0、f16、q4_1、q4_0、f32のデータ型のみに最適化されたカーネルを記述しました。q8_0とf16は非常に堅実な選択肢だと思います。RAMが十分にある場合はf32も良いかもしれません。なぜなら、私の新しいカーネルはルールを変えるからです。それらは、クオンタイゼーションが常に解決してきたメモリ帯域幅の問題を解決するのに非常にうまく機能しており、クオンタイゼーション自体がより大きなボトルネックになる可能性があります。これは、速度のために知識を犠牲にする必要性が減るため、ローカル言語モデルの将来にとって朗報となるでしょう。 ホビイスト向けハードウェアでのパフォーマンス向上 大規模言語モデルを実行するために大きなコンピューターは必要ありません。今日店頭で入手できる最高のパーソナルコンピューターの1つはRaspberry Piです。優れた価格で良好なパフォーマンスを提供し、消費電力も非常に少ないです。 LLMパフォーマンス on $136 Raspberry Pi v5 (ARMv8.2) and v4 (ARMv8.0) | プロンプトトーク/秒 | 評価トーク/秒 | モデル | ウェイト | データ型 | ハードウェア | ソフトウェア | |---|---|---|---|---|---|---| | 62 | 5 | TinyLlama 1.1B | f16 | RPI5 | llamafile-0.7 | | 28 | 5 | TinyLlama 1.1B | f16 | RPI5 | llama.cpp 2024-03-26 | | 8 | 5 | TinyLlama 1.1B | f16 | RPI5 | llamafile-0.6.2 | | 45 | 9 | TinyLlama 1.1B | q8_0 | RPI5 | llamafile-0.7 | | 35 | 9 | TinyLlama 1.1B | q8_0 | RPI5 | llama.cpp 2024-03-26 | | 20 | 9 | TinyLlama 1.1B | q8_0 | RPI5 | llamafile-0.6.2 | | 10 | 3 | TinyLlama 1.1B | q8_0 | RPI4 | llamafile-0.7 | | 10 | 3 | TinyLlama 1.1B | q8_0 | RPI4 | llama.cpp 2024-03-26 | | 9 | 3 | TinyLlama 1.1B | q8_0 | RPI4 | llamafile-0.6.2 | | 3 | 2 | TinyLlama 1.1B | f16 | RPI4 | llamafile-0.7 | | 3 | 2 | TinyLlama 1.1B | f16 | RPI4 | llama.cpp 2024-03-26 | | 4 | 2 | TinyLlama 1.1B | f16 | RPI4 | llamafile-0.6.2 | Raspberry Piは数ヶ月前に第5版をリリースし、前モデルと比較して驚異的な速度を実現しました。また、LLMに非常に役立つARMv8.2 dotprodおよびfp16算術ISAのサポートも導入しました。これらの2つの機能だけでも、昨年llama.cppがf16ウェイトで10倍のパフォーマンス向上を達成することを可能にしました。今週、私は元々AVX512用に意図していたカーネルを使用することで、さらに2倍のパフォーマンス向上を引き出しました。強力なデータセンター機器用に設計されたカーネルが、非常に小さなRaspberry Piでもうまく機能するとは思わないかもしれませんが、両方のCPUが32個のベクトルレジスタを持っているため、実際によく適合しました。新しいARMv8.2 fp16 ISAは、llamafileがfp16ワードを使用し、ドットプロダクトの計算にKahan summationのような技術を使用しないため、通常よりも多くのエラーを導入する可能性があることに注意する価値があります。そのため、Q8_0ウェイトは、32ビットの計算タイプに符号付き8ビット整数をドットプロダクトできるdotprod ISAを使用し、エラーを吸収するため、実際にはわずかに優れたパープレキシティを持ちます。しかし、これは高速なfp16ウェイトが役に立たないという意味ではありません。この分野の多くの開発者は、その違いを些細なものと見なしています。例えば、Pi-holeでメールサーバーをセットアップし、TinyLLaMAにスパムをフィルタリングさせたいとしましょう。Postfixをシェルスクリプトを使用してコンテンツをフィルタリングするように設定することは可能であり、llamafileコマンドを実行できます。 llamafile -m TinyLlama-1.1B-Chat-v1.0.f16.gguf \ --grammar 'root ::= "yes" | "no"' --temp 0 -c 0 \ --no-display-prompt --log-disable -p "<|user|> Can you say for certain that the following email is spam? To: jtunney@gmail.com From: Federal-Tax-DebtHelp <ConfirmationEmail.inzk@janents.com> Subject: Reduce your payments to what you can afford Reduce your payments to what you can afford [IMG] [IMG] [IMG] </s> <|assistant|>" 上記のシェルスクリプトをRPI5で実行すると、3秒かかります。 jart@pi5:~/scratch$ time ./spam.sh yes real 0m3.168s user 0m10.851s sys 0m0.541s ここにはいくつかの重要なことが起こっています。 --temp 0 は乱数ジェネレータをオフにします（スパムフィルターでは即興は望ましくありません）。 ここでプロンプト評価時間がキングである理由がわかります。トークン生成速度（評価時間）は、--grammarフラグを使用してLLMに単一の「yes 」または「no 」トークンのみを出力させるため、このユースケースでは重要ではありません。元のメールをlinks -codepage utf-8 -force-html -width 400 -dump /dev/stdinでパイプ処理し、トークン数を減らし、スパマーがメールをハムに見せるために隠したHTMLコンテンツを削除しました。-c 0フラグはTinyLLaMAに最大コンテキストサイズ（2048トークン）を使用するように設定します。これは与えられる最大のプロンプトです。あまり多くのテキストをフィードしないようにするには、sed 's/ */ /g' | dd bs=1 count=7000でメールをパイプ処理して余分なスペースを削除し、サイズの上限を設定できます。 スパムフィルタリングは氷山の一角に過ぎないことに注意してください。私は常に「生成AI」は誤称だと考えてきました。なぜなら、言語モデル（より一般的に「アルゴリズム」として知られる）は、テクノロジー企業が過去に知識を抽出し、情報をキュレーションし、コンテンツをランク付けするために常に使用してきたからです。これには書き込みよりも読み込みが必要です。テクノロジー企業が運用する規模では、英語はそれほど有用ではないため、AIは伝統的にそれほど多くを話す必要はありませんでした。たとえ数エクサバイトのテキストの英語要約をそのサイズの百万分の一で生成できたとしても、それは依然としてチームが一生かけても読めないほどの単語数になります。 ゲーミングハードウェアでのパフォーマンス向上 ゲーマーは、あらゆる消費者の中で最も高い品質期待を持っています。そのため、あらゆるハードウェア構築