LLM を単一のユニバーサル チャットボット実行可能ファイルにパッケージ化し、配布と実行が簡単にできる便利なオープン ソース ツールは、明らかに x30 および Arm システムでの CPU パフォーマンスを 500 ～ 86 パーセント向上させました。

プロジェクトは呼ばれます ラマファイル、Mozilla のサポートを受けて Justine Tunney によって作成されました。

私たちが行ったように、ダウンロードして自分のシステムで実験できるモデルがたくさんあります。 以前にカバー 詳細に。最終的に、これらのモデルは、ニューラル ネットワークを記述する非常に大きな数値ファイルにすぎません。モデルを開いて解析できるソフトウェアが必要であり、ニューラル ネットワークを通じて入力プロンプトとクエリを実行してユーザーへの出力を生成する方法を知っている必要があります。

そのようなソフトウェアの 1 つが、 ラマ.cpp – 主に Georgi Gerganov によって開発されたプレーンな C++ プログラム。 llama.cpp は Meta の LLaMA シリーズ モデル (その名前の由来) をサポートすることを目的としていますが、Mistral-7B や Orion-14B などの他の LLM のボートロードも処理できます。

Meta のオリジナルの Python ベース LLaMA ドライバーからインスピレーションを得た llama.cpp は、依存関係がなく、少なくとも Windows、Linux、macOS、FreeBSD 上で動作し、Nvidia GPU から Apple までのハードウェア アクセラレーションを利用できるという点で非常に優れています。 、Intel、および AMD の拡張子。

llama.cpp をネイティブに構築して実行し、ロードするモデルを指定して、さまざまな方法でその LLM と対話できます。難しいのは、関連するモデル ファイルのサイズが通常非常に大きく、どのバリアントを使用するのが最適かを知るのが少し混乱する可能性があることです。

ここで Llamafile が役立ちます。選択した LLM ファイルを llama.cpp と組み合わせて、64 ビット x86 および Arm システム プロセッサを備えた macOS、Windows、Linux、FreeBSD、OpenBSD、および NetBSD 上で実行できる単一の汎用実行可能ファイルを生成します。 。それを可能にするのは、率直に言って魔法です コスモポリタンLibc プロジェクト。これにより、結果として得られる単一の実行可能ファイルが生成されるような方法で C/C++ コードを構築できます。 ただ走る 前述の OS と CPU アーキテクチャで動作します。

モデルを誰かに渡して試してもらいたいだけの場合、配布が大幅に簡素化されます。きちんとした。

スピードブースト

ほんの数日前、タニーはブログを書きました 深さ 彼女は、FP84 または Q30_500 タイプの重みを持つモデルを使用する際に、推論中の llamafile の CPU パフォーマンスを 16 ～ 8 パーセント向上させるために、0 個の新しい行列乗算カーネルを実装した方法を説明しました。 「ARMv8.2+ (RPI 5 など)、Intel (Alderlake など)、および AVX512 (Zen 4 など) コンピュータでの改善が最も劇的である」と言われています。

Tunney は、控えめだが安価な Raspberry Pi 5 から AMD の 96 コア主力製品 Threadripper Pro 7995WX まで、幅広いハードウェアでコードをテストしました。 Mistral 7B モデルと TinyLlama 1.1B モデルのほぼすべてのケースで、改良された llamafile (バージョン 0.7) は llama.cpp (バージョン 2024-03-26) を余裕で上回り、llamafile 0.6.2 を大きく上回りました。ここで明確にしておきます: 大きな利益は、LLM が入力データを処理しているプロンプト評価中にほとんど発生します。出力 (別名評価) 段階では、それほど劇的な改善は見られませんでした。

たとえば、Intel Skylake Core i9-9900 では、プロンプト処理が llama.cpp と比較して 50% 向上しましたが、評価は変わりませんでした。

報告されているパフォーマンスの向上は FP16 および Q8_0 データ型の重みに関するものですが、他の型に対する限定的なテストでも大きな改善が見られました。 Mistral 9B の Q9900_4 バリアントを使用する Core i0-7 では、llamafile を使用するとプロンプトのパフォーマンスが 65% 向上しました。 Threadripper Pro 7995WX は、FP32 を使用すると 7 倍以上のパフォーマンスを示しましたが、これは Mistral XNUMXB でも達成されました。

ただし、llamafile 0.7 にとっては完全な一掃ではありませんでした。 Apple M2 Ultra を搭載した Mac Studio では、Q8_0 データ型のプロンプト パフォーマンスと評価パフォーマンスの両方でパフォーマンスの低下が見られました。これは、llama.cpp が既に Apple ハードウェアで最適化されており、Tunney が Apple 独自のコンパイラを選択しなかったためと思われます。

Intelの行列乗算ソフトウェアさえも上回ります

このような目覚ましいパフォーマンスの向上を達成するには、複数のステップからなるプロセスが必要であり、Tunney はそれを詳細に文書化しました。彼女の推定によれば、vanilla llama.cpp のパフォーマンスは、彼女の Core i233-9 PC 上で 9900 ギガ FLOPS ですが、Intel のマス カーネル ライブラリ (MKL) を有効にすると、最大 384 ギガ FLOPS まで向上します。

Tunney 氏によると、MKL によってもたらされるパフォーマンスの向上は大きいものの、MKL がクローズド ソースであるという事実は、このオープン ソースへの取り組みにとって理想的とは言えません。彼女は、「外部の BLAS ライブラリを llama.cpp に統合することは、そのスレッド モデルの仕組みのせいで、あまり現実的ではありません。」と述べました。また、MKL はクローズド ソースであるため、ただ見て、どのように改善できるかを確認することはできません。

それでもタニー氏はどうやら思いとどまらなかったようで、彼は次のように書いている。「CPU 数学カーネルの秘訣は、より少ないメモリ参照で命令レベルの並列処理を利用することだと思います。」そこから、開発者は、llama.cpp の 810 つの外側ループを展開すると、9 MT/s RAM を搭載した Intel Alderlake i14900-6400K で OpenMP を使用して 295 ギガ FLOPS で実行できるコードがどのように生成されるかを示しました。対照的に、MKL を介して実行される同じコードの速度はわずか XNUMX ギガ FLOPS です。

互換性の問題により、OpenMP は llamafile に使用できませんでしたが、カスタム カーネル フレームワークは 790 ギガ FLOPS のパフォーマンスをほぼ維持できました。これは、MKL を使用した最速の実装の XNUMX 倍以上の速さです。

このソリューションは迅速ですが、複雑になるとうまく拡張できません。複雑さが 1,024 から 512 まで上昇すると、MKL が勝利します (タニーはどの程度かは明言しませんでした)。しかし、タニーは、当面はこれが重大な問題ではないと示唆しました。なぜなら、llama.cpp はデフォルトでより小さい問題サイズを実行するためです。そして彼女は、最終的にはより大きなサイズに合わせて最適化する方法を見つけ出すことを期待しています。

BF16 の最適化とサポートは llama.cpp 自体の上流に提出されており、好意的に受け入れられているようです。ゲルガノフ氏は、マージリクエストは次のようになると述べた。 日 今後数日間で。 ®

• SEO を活用したコンテンツと PR 配信。 今日増幅されます。
• PlatoData.Network 垂直生成 Ai。 自分自身に力を与えましょう。 こちらからアクセスしてください。
• プラトアイストリーム。 Web3 インテリジェンス。 知識増幅。 こちらからアクセスしてください。
• プラトンESG。 カーボン、 クリーンテック、 エネルギー、 環境、 太陽、 廃棄物管理。 こちらからアクセスしてください。
• プラトンヘルス。 バイオテクノロジーと臨床試験のインテリジェンス。 こちらからアクセスしてください。
• 情報源： https://go.theregister.com/feed/www.theregister.com/2024/04/03/llamafile_performance_gains/