Llama2.c: 純粋なCファイルでLlama 2推論

 (github.com/karpathy)
1 ポイント 投稿者 GN⁺ 2023-07-24 | 1件のコメント | WhatsAppで共有
  • llama2.c は、PyTorchでLlama 2 LLMアーキテクチャを学習し、シンプルなCファイル run.c で推論する「fullstack」な学習・推論ソリューション
  • 中心的な焦点は ミニマリズムとシンプルさ で、Llama 2アーキテクチャをハードコードし、依存関係のない純粋なC推論ファイル1つで構成した教育用実装
  • ごく小さなLLMでもドメインを十分に絞れば高い性能を発揮できるという観点から、TinyStories ベースのサンプルモデルを提供
    • 15Mパラメータモデルは約60MBのダウンロードで、make run 後に ./run stories15M.bin で実行可能
    • 42M、110Mパラメータモデルも提供され、110MモデルはGPT-1と同じサイズだと明記されている
  • MetaのLlama 2モデルもニューラルネットワークアーキテクチャが同一のため推論可能だが、チェックポイントをMetaの手順に従って入手したうえで、export.py でllama2.c形式に変換する必要がある
    • 現在の run.c はfp32推論のみを行うため、7Bより大きいモデルを実用的にロードするのは難しい可能性が高い
    • 13B以上はポインタ演算のinteger overflowにより現在は動作せず、未修正の状態
  • int8量子化 推論は runq.c に実装されており、Q8_0方式でmatmulに参加する重みを量子化し、活性値も実行時に動的に量子化・逆量子化する
    • Llama 2 7Bのfp32 exportは26GBのファイルを作成し、version 2 quantized exportは6.7GBのファイルを作成する
    • 作者の環境ではOpenMP 64スレッド基準でfp32は4.6 tok/s、int8は14 tok/sで実行され、チェックポイントサイズは4分の1になり、速度は約3倍向上
  • 利用方法は、C推論の実行、プロンプト入力、temperatureとtop-pサンプリング制御、chatモード実行、カスタムトークナイザ指定で構成される
    • 実行例は ./run stories42M.bin -t 0.8 -n 256 -i "One day, Lily met a Shoggoth" 形式
    • chatモデルは ./run llama2_7b_chat.bin -m chat のように -m chat フラグで実行する
    • カスタムトークナイザは tokenizer.py で .bin 形式にエクスポートした後、-z フラグで指定する
  • Hugging FaceでLlama 2アーキテクチャを使うモデルは、export.py の --hf フラグで .bin ファイルにエクスポートできる
  • 学習フローは、TinyStoriesのダウンロードと事前トークン化、train.py の実行、モデルのexport後にC推論へ進む流れ
    • デフォルトのTinyStories例が、現在提供されている唯一のデータセット例
    • カスタムトークナイザの学習には sentencepiece を使用し、例として --vocab_size=4096 設定を使う
  • 性能関連のビルドは make run、make runfast、make runomp に分かれ、OpenMPビルドはmatmulとattention内部の #pragma omp parallel for を有効化し、ループ処理を複数のプロセッサに分割する
  • プラットフォーム別ビルド手順はWindows、Centos 7、Amazon Linux 2018、Mac向けに提供される
    • Windowsは build_msvc.bat または make win64 を使用
    • Centos 7とAmazon Linux 2018は make rungnu または make runompgnu を使用
    • MacのOpenMPビルドはbrewのclangをインストールした後、make runomp CC=/opt/homebrew/opt/llvm/bin/clang を使用
  • テストは pytest とCテスト make testcc を提供し、test_all.py はCとPythonで200ステップのforwardを実行して既知の期待出力と比較する
  • プロジェクトの目標は、読みやすい2つの学習コード .py ファイルとC推論コードからなるシンプルな参照実装を維持することであり、複雑なフレームワークや多数のオプションは志向しない
  • ライセンスは MIT

関連記事

1件のコメント

 
GN⁺ 2023-07-24
Hacker News のコメント

  • HN に上がっているのを見て面白いと思った :) もとのチェックポイントは MacBook Air M1 で -O3 コンパイルすると、予想よりずっと速い 100 tok/s で動いたので、今はさらに大きい 44M モデルを学習中
    それでも対話的に実行できそうで、もしかすると 7B Llama モデルも手の届くところにあるのでは、という気がする

    • nanoGPT を少し改造して、TinyStories の GPT-4 生成 2GB データで 12M モデルを事前学習してみたところ、結果はかなり驚くものだった
      その後 Wikipedia で少し適応させると、平滑化した n-gram モデルよりずっと賢く、ずっと小さい、もっともらしいデタラメ生成器になった。小さな LLM はさまざまな領域で主流になりそうで、次の目標は Llama2 7B を 10〜100M に縮小しつつ、大きく愚かにならないようにすること
    • いつもながら、この取り組みには刺激を受ける。初心者質問だが、派手な GPU のない普通の Linux サーバーで、趣味の Web アプリに組み込める適度なサイズの LLM を動かすには、最も実用的な道筋は何だろうか
      Linode のようなところで GPU インスタンスを借りるのは通常の Web アプリ用サーバーよりずっと高いが、完全に無理な領域なのか、それともこうしたアプローチや別の方法が現実的な道なのかを知りたい
    • 小さな Llama-2 モデルと小さな GPT-2 モデルの相対的な品質/性能について、初期の印象があるか気になる
    • Python ではなく 純粋な C のトレーナーも作れると思うか気になる
    • こうしたモデルを自宅の機材、M1、クラウドのどこで学習させているのか気になる

  • llama.cpp で知られる Georgi Gerganov が Emscripten でブラウザ上で動かしたバージョンがある: https://ggerganov.com/llama2.c/
    進行中の Twitter スレッドはこちら: https://twitter.com/ggerganov/status/1683174252990660610
    オリジナルもこの取り組みも本当に素晴らしく、ごく小さなモデルを使った概念実証に近いが、ローカルファーストの LLM は特に興味深い。ローカル推論で Web アプリを作れるという発想が良い
    最適化、より小さなモデルの研究、部分ダウンロード、WebGPU 活用へとつながれば、プライベートなローカル LLM ベースのアプリを作る新しい方法の出発点になり得る。最上位 GPU の大規模クラスタでホストされる LLM と同じ能力は難しいだろうが、この方式が開くユースケースは多い

    • 最初のリンクでは、かなり奇妙な出力が出た。最初はそれらしい童話のように始まるが、誤字が増えて支離滅裂に崩れ、外国語や技術/プログラミング用語が混ざって出てくる感じ
      たとえば “Once upon a time...” で始まり、Lily と Timmy の話のように見えたものが、“Butterfly would pauseWhy”、“TextField”、querySelector、HttpRequest、複数言語の断片が入り混じり、完全に壊れた出力へと変わっていく

  • 気になる人向けに Rust 版もある。リリースモードで 106 tokens/second くらい出る
    https://github.com/garrisonhess/llama2.c/blob/517a1a3e487f31...

    • 別の Rust 版もある。先月から作業している candle ML ライブラリを使っていて、ブラウザでも実行可能: https://laurentmazare.github.io/candle-llama2/index.html
      Web ではない版は GPU を完全にサポートしているが、まったくミニマルではない
    • Rust ではよく見られるように、既にあるものを、可能だからというだけでそのまま写経し、何の利点ももたらさない場合がある
      ときには、プロジェクト改善に向けたコミュニティの努力を分散させてしまうこともある

  • これがどれほど大胆な動きなのか、理解している人は多くないように思う
    Andrej は OpenAI（MSFT）から高額な報酬を受け取りながらも、Apple、Facebook、そして何よりオープンソース運動を助けている。それでも彼を追い出すのは難しいはずで、そうなればすぐ Tesla や xAI に行けるからだ

  • Llama-2 は創作作業には使えないほど安全フィルタリングが強いと感じる: https://i.imgur.com/GFY0wSL.png

    • 個人的には、「安全」という名目で、むしろ 180 度回ってヘイト的、あるいは否定的なステレオタイプを強化しかねないほどフィルタリングが強いと思う: https://i.imgur.com/xkzXrPK.png および https://i.imgur.com/3HQ8FqL.png
      ただし、この現象は Llama2-70b-chat TGI Hugging Face で 2 通目のメッセージとして送った場合にだけある程度再現でき、プロンプト方式の側におかしな部分があってこうした挙動が生じている可能性もある。自分でモデルを動かして追加調査することはまだできていない
    • 事前学習モデルがあるなら、instruct/chat モデルは使わないほうがよい
      Chat/instruct は第三者ユーザーに配布しやすく、プロンプトが単純で、安全策が入っているという利点があるが、自分で使うには事前学習モデルより本当にかなり劣る。この点で Llama 2 は OpenAI より有利かもしれない。OpenAI は GPT-3 の事前学習モデルを廃止し、今後は chat モデルだけを提供する方向に見えるからだ
    • 想像してみると、Casca と Brutus が Caesar を刺すのではなく、彼の権力乱用の可能性や独裁的傾向について丁寧に向き合う、という形になる
    • フィルタリングが過剰なのは「llama-2」全体ではなく、Llama-2 chat だ
    • 「倫理的 AI」の人たちは押しのけるべきだ。彼らが本当に厄介な存在になりつつあることは、ますます明らかになっている
      安全ハサミはいらない。自分のサーバーで動くものを制限するのは構わないが、自分のコンピュータで思いどおりに改変して使えないモデルは渡さないでほしい

  • Andrej がより詳しく投稿している内容はこちら: https://twitter.com/karpathy/status/1683143097604243456?s=46...

  • ちなみに、この方面に興味があるなら、このコードは WASI SDK できれいにビルドでき、修正なしで Wasm ランタイム上で動作する

  • ニューラルネットワークを実行するには、どれくらいのメモリが必要なのか気になる
    ディスクから最初の2層だけを読み込み、すべてのノードの活性値を計算した後で第1層を捨て、第3層を読み込んで再び計算し、その後で第2層を捨てる、というやり方で十分なのだろうか？ そうなら、メモリは2層分を保持できるだけあればよいのか気になる

    • Hugging Face の TheBloke が、人気モデルの量子化版ごとのメモリ要件を文書化している: https://huggingface.co/TheBloke
      要約すると、最大 RAM は量子化方式によって変わり、おおよそ 7B モデルは 4〜8GB、13B モデルは 8〜15GB、30B モデルは 13〜33GB、70B モデルは 31〜75GB の範囲になる
    • 自分で読み込んで捨てる処理をする必要はない。ネットワーク全体を mmap して、OS に任せればよい
    • 可能ではあるが、そうするとディスク帯域幅に制限されることになる
    • O(N²) のTransformer 推論では、すべての活性値をキャッシュする必要があると理解している

  • ふと思ったのだが、現在の LLM は確率分布を返し、乱数サンプラーがその中から1つを選んで出力に付け加え、それを繰り返している
    その代わりに、乱数が分布を近似する N 個のトークンを選び、LLM に N 個の新しい分布を生成させ、それらを何らかの方法で結合して、結合分布から再び N 個のトークンを選ぶ、ということは可能だろうか？

    • ほとんど**ビームサーチ（beam search）**のように聞こえるし、実際によく使われる生成手法である: https://en.wikipedia.org/wiki/Beam_search
      例は https://huggingface.co/docs/transformers/internal/generation... で見られる
    • 研究してみる価値のある方向に聞こえるが、おそらく2トークンよりずっと先まで生成する必要がありそうだ。20トークン程度を見るとしても、LLM を N^20 回実行したくはないだろうから、次の20トークンの組み合わせの中から代表的なサンプルを200個ほど選ぶようなやり方のほうがよさそうだ
      ただし、それをどうやるかは分からない
    • 初心者だが、その発想は気に入った。答えは分からないが、実験してみることはできそうだし、おそらく研究者がすでに試している可能性が高い
      もちろん、トークン生成ごとにN倍の計算量が必要になる。上位 N 個を選ぶか、必要ならロジットに温度調整を適用して N 個をサンプリングできる

  • これは教育用なのか？ llama.cpp とこのプロジェクトの成功を見ると、業界は PyTorch、TensorFlow、ONNX Runtime のような汎用フレームワークではなく、リリースされるモデルごとに別個のソースコードを持つ方向へ進んでいるように見える

    • これは完全に教育用に見える
      そして、そうではない。名前とは違って llama.cpp は llama だけをサポートしているわけではない。完全なカスタム実装でもなく、より汎用的な ggml テンソルライブラリ/フレームワークの上に作られている
    • フレームワークの中でもモデルごとに別個のソースコードはある。モデルはフレームワークの基本要素を組み合わせたカスタムコードであり、純粋にフレームワークだけで作られるものではないからだ。探索的研究の本質がそういうものだ
      ただし、うまく機能するモデルが見つかると、その進展は次のフレームワークのバージョンに取り込まれることが多い。だから TensorFlow には CNN、GRU、TransformerEncoder のような基本要素が生まれ、同時に汎用性を犠牲にして速度を得る特定ハードウェア向け実装も作られる
    • シングルスレッドなので、教育用と見るのが妥当だ