MobileLLM: オンデバイスのユースケース向けサブビリオンパラメータ言語モデルの最適化

 (github.com/facebookresearch)
3 ポイント 投稿者 GN⁺ 2024-07-11 | 1件のコメント | WhatsAppで共有
  • MobileLLM リポジトリは、ICML 2024 論文 “MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases” の学習コードを提供し、10億未満のパラメータ言語モデルの品質を高める設計を扱う
  • モデル設計では SwiGLU、深く細い構造、埋め込み共有、grouped-query attention を統合して MobileLLM を構成している
  • MobileLLM-125M/350M はゼロショット常識推論課題で既存の 125M/350M SoTA モデルよりそれぞれ 2.7%/4.3% の精度向上を達成し、更新版は 600M/1B/1.5B でも SoTA の結果を示している
  • 学習コードは Python 3.9 と PyTorch 2.0 以上を要求し、pretrain.sh は 1x8 GPU ノードで torchrun により開始され、ノード数やバッチサイズを増やす場合は学習率を線形に増やす必要がある
  • 1T トークン基準の学習コストは、32 基の NVIDIA A100 80G GPU で 125M は約 3 日、350M は約 6 日、600M は約 8 日、1B は約 12 日、1.5B は約 18 日かかる

MobileLLM の目的と公開範囲

  • MobileLLM は、オンデバイスのユースケース向けに サブビリオンパラメータ言語モデルを最適化する学習コードを収めたリポジトリである
  • 元となる論文は MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases で、ICML 2024 に掲載された
  • 中核的な目標は、10億未満のパラメータでも高品質な LLM を作るために、複数の設計要素を総合的に考慮することである

モデル設計要素

  • MobileLLM は次の設計要素を統合している
    • SwiGLU 活性化関数
    • 深く細い アーキテクチャ

    • 埋め込み共有

      • grouped-query attention
      • 更新版では、この設計思想がより大きなモデルにも拡張されることが示されており、MobileLLM-600M/1B/1.5B で SoTA の結果を示している

公開および後続モデルの動向

  • 2024 年 10 月 30 日に MobileLLM モデルが HuggingFace で公開された
  • 2025 年 9 月に後続研究 MobileLLM-R1 が公開された
    • 約 2T の事前学習トークン、合計 5T 未満のトークンで、MATH、GSM8K、MMLU、LiveCodeBench において Qwen3-0.6B の 36T トークン結果に匹敵、またはそれを上回る
    • コード、モデル、データ、学習レシピが公開されている
    • HuggingFace コレクションが提供されている
  • 2025 年 11 月に MobileLLM-R1.5 が公開された
    • MobileLLM-R1.5-950M は、評価されたすべての数学およびコーディングベンチマークで DeepSeek-R1-Distill-Qwen-1.5B を上回る
    • パラメータ数は 0.95B 対 1.5B でより少ない
  • 2026 年 1 月に MobileLLM-R1 が ICLR 2026 に採択された

実行と学習構成

  • 要件は Python 3.9、PyTorch 2.0 以上、pip install -r requirement.txt である
  • データ前処理は、トークン化済みデータセットを分割するか独自データセットをトークン化した後、学習ノード総数に合わせて分散する方式である
    • 各ノードは 1x8 GPU で構成される
    • データ構造は basepath/1, basepath/2, ..., basepath/#nodes 配下に xxx.jsonl ファイルを置く形式である
    • 各 jsonl の行は {"token_ids": [1,2,3,4,...]} 形式のトークン化データのキー・バリューペアである
    • 学習コードは LLM360/amber-data-prep のデータ前処理方式と互換性がある
  • pretrain.sh は 1x8 ノード設定で torchrun により学習を開始するスクリプトである
    • --nnodes やその他の設定を変更することで、Slurm や TorchX のようなマルチノード構成に合わせられる
    • スクリプトの学習率は 1x8 ノード、バッチサイズ 32 を基準としている
    • ノード数やバッチサイズを増やす場合は、学習率を 線形に増加させる必要がある
  • 実行手順は、pretrain.sh で --train_data_local_path に前処理済みデータを指定し、--input_model_filename を ./configs/{model_size}/ に設定した後、bash pretrain.sh を実行する方式である
  • Wiki 評価は、モデルをダウンロードして eval.sh のチェックポイントパスを更新した後、bash eval.sh で実行する

学習コスト

  • 1T トークンで MobileLLM を学習する際、32 基の NVIDIA A100 80G GPU 基準の所要時間は次のとおりである
    • 125M: 約 3 日
    • 350M: 約 6 日
    • 600M: 約 8 日
    • 1B: 約 12 日
    • 1.5B: 約 18 日

ゼロショット常識推論の結果

  • MobileLLM-125M は arc_easy、arc_challenge、boolq、piqa、siqa、hellaswag、obqa、winogrande の平均で 46.3 を記録した
    • OPT-125M は 42.6、GPT-neo-125M は 42.9、Pythia-160M は 42.5 である
    • MobileLLM-LS-125M の平均は 47.0 である
  • MobileLLM-350M は平均 51.3 を記録した
    • OPT-350M は 43.9、Pythia-410M は 46.6 である
    • MobileLLM-LS-350M の平均は 52.1 である
  • MobileLLM-600M は平均 54.3 を記録した
    • Qwen1.5-500M は 48.8、BLOOM-560M は 44.2、MobiLlama-800M は 50.7 である
  • MobileLLM-1B は平均 57.3 を記録した
    • Pythia-1B は 48.7、MobiLlama-1B は 55.2、Falcon-1B は 56.3、BLOOM-1.1B は 46.9、TinyLlama-1.1B は 54.2 である
  • MobileLLM-1.5B は平均 59.4 を記録した
    • GPT-neo-1.3B は 50.6、OPT-1.3B は 52.3、BLOOM-1.7B は 49.6、Qwen1.5-1.8B は 56.5 である
    • GPT-neo-2.7B は 52.8、OPT-2.7B は 55.1、Pythia-2.8B は 55.8、BLOOM-3B は 52.3 である

関連プロジェクトとライセンス

  • コードは HuggingFace の Transformers リポジトリを一部ベースにしており、同リポジトリは Apache License を採用している
  • 関連プロジェクトとして次が挙げられている
    • SpinQuant: LLM Quantization with Learned Rotations, ICLR 2025 — Paper, Code
    • LLM-QAT: Data-Free Quantization Aware Training for Large Language Models — Paper, Code
  • 次のステップとして MobileLLM-R1 と MobileLLM-R1.5 モデルが提示されている
  • MobileLLM は現在 FAIR NC ライセンスを使用している

関連記事

1件のコメント

 
GN⁺ 2024-07-11
Hacker News のコメント

  • 小型モデルは少し改善されたものの、オンラインモデルと同じ用途に使うにはまだ力不足に見える。それでも漸進的な進歩自体は悪くない。
    15億パラメータモデルはかなり大きな飛躍に見えるし、より大きなモデルにも大差で勝っている。なぜもっと大きくしなかったのかは分からない。Raspberry Pi 程度のハードウェアに収まる、より効率的なモデルはゲームチェンジャーになり得る。記憶では TinyLlama 7B もかろうじて動く程度だった

    • もっと小さな言語モデルでも、音声認識システムの一部としては有用そうだ。曖昧だったりノイズがあったりする状況で、どの単語が発話されたのかを絞り込むのに言語モデルが役立つ可能性がある
    • こうしたモデルが Instagram アプリに組み込まれ、ユーザー端末上の計算で広告ターゲティングに使われるところを想像すればよい。そうすれば Facebook は、はるかに多くのデータを、より低いコストとはるかに低い訴訟リスクで見ることができる。
      この用途では、小型モデルをクラウドモデルと比較するのは公平ではない。小型モデルの精度が少し上がるだけでも意味があり、そのまま売上につながり得る
    • Raspberry Pi が次段階のローカル LLM に適した目標なのかはよく分からないし、WebLLM のようなエンジン経由での Web 配布も検討に値する https://github.com/mlc-ai/web-llm
      7B モデルが Raspberry Pi で「よく動く」としても、個人的には Web ベースのインターフェースでダウンロードして実行するには 7B モデルは少し大きい。一方で、まともな 125M モデルなら Web ページ上で動かせるし、ローカルブラウザにダウンロードする時間や帯域コストも過度ではない
    • Llama-3-8b は Raspberry Pi でよく動く

  • 必ずモバイル端末上になければならないのか？ ニッチな用途ではあるが、リソースをあまり食わないなら、ゲームでNPC の会話をもっと面白くするのに使えそうだ。
    さらに良いのは、何らかの形でチューニングして、会話が NPC の振る舞いやアクションに影響するようにできることだ

    • その会話は本当に面白いだろうか？ 会話量は増やせるだろうが、プレイヤーが興味を持つだけの基盤があるのかは疑問だ。例えば村人が地域の風景や他の NPC との関係について語ることはできるかもしれないが、彼らが描写するものが実際のゲーム内には存在しない可能性がある。個人的には、NPC が存在しないものを作り話し始めたら違和感がありそうだ。
      ゲームデータで LLM を学習させ、NPC が実際のゲーム世界を説明するようにすることは想像できる。ただ、それが人間にセリフを書かせるより安くなるには、どの程度の規模が必要なのか分からない。Ubisoft くらいの規模なら可能かもしれない。知る限り Ubisoft も AI によるライティングを調査してきたが、主に戦闘中の掛け声のような、非常に反復的で実質的にはノイズに近い用途だ
    • NPC により多くの背景ストーリーと、より複雑な振る舞いが生まれれば面白そうだ。ただし何であれ行動に影響し得るので、テストはほぼ不可能に近くなりそうだ

  • 今 iPhone でこうしたモデルを動かせるアプリは何がある？ 知っているのは MLC だけだが、そこには古いモデルが3つしかない

  • より深く、より細くするやり方をどこまで押し進められるのか気になる。どこかの時点で FFN 全体が L2 キャッシュに収まると、性能がかなり跳ねる領域が出てきそうだ

    • Meta FAIR の別の研究は、精度を維持しながら性能を上げるには、むしろ深い層を枝刈りすべきだと示唆している https://arxiv.org/html/2403.17887v1
      だとすると、このアプローチが通用する小規模ネットワークの限界点があるはずだ。そうでなければ結果が互いに矛盾している。あるいは、この新しいモデル群をはるかに改善できるという意味かもしれない
    • Google の EfficientT5 論文の結果を思い出す https://arxiv.org/abs/2109.10686。そこではこれを「DeepNarrow」と呼んでいる

  • 何か見落としているのかもしれないが、知識蒸留のようなものはここで役に立たないのか？

    • 論文ではそれを試したと書かれている: https://arxiv.org/abs/2402.14905
      関連部分の HTML ディープリンク: https://ar5iv.labs.arxiv.org/html/2402.14905#S3.SS5
      「これまでは次トークンをハードラベルとして使い、小さなモデルをゼロから学習してきた。知識蒸留（KD）も探索した……残念ながら KD は学習時間を増やし（2.6〜3.2倍遅くなり）、ラベルベースの学習と同程度か、それより低い精度を示した（詳細は付録）。」

  • 今まさに端末内での wake-word 風の音声認識が必要だ。Raspberry Pi 4B で動かせて WER が最も低いモデルは何だろう？ DIY 在庫管理システム向けに openWakeWord を見ている

  • 小さなモデルは、線形ヘッドとトークン埋め込みの間の埋め込み共有／重み共有で、サイズを最も大きく削減しているように見える。そこからさらに削減する研究が進んでいるのか気になる

    • LM-head が単に反転した埋め込み行列という意味なら、それはすでに GPT-2 で行われていたことだ
      残念ながら、これについて見つけたのは、大きなモデルは別レイヤーでメリットを得るという程度だった。ただし Discord のどこかで見た話なので、読むべき論文はないし、個人的な直感としては大きなモデルにも効くはずだと思う。結局 GPT-3 も GPT-2 を拡大したものだった
      個人的な実験では、モデルにより難しい課題を与えると、よりよく学習した。共有された重みはその一つかもしれないし、マルチトークン予測もそうかもしれず、bitnet もそう見なせる。ドロップアウトも同じだ

  • デスクトップで生成 AI ではなく、ただのデスクトップ AIならどうだろう。自分のすべてのファイル、メール、ノートを整理し、自分のデータから情報を検索できるようにしてくれるとよい

  • いいね。これを Windows PC 向けモデルの学習にも使えるのだろうか。RAM が多くない

    • モデルの学習は OS に依存しない。RAM はサイズ次第で、この程度ならより少ない GPU RAM でファインチューニングするのがずっと容易になると思う
      それでも最終的な目標は、こうしたモデルをダウンロードするか、ファインチューニング費用を払って受け取ったうえで、最適化されたニューラルネットワークチップ経由で使う方向になる可能性が高い
      今は、いつそうなるかという問題に近い。最新の Windows 認証もすでに何らかのニューラルネットワークチップを要求しているし、私の Google Pixel 8 Pro も小さなモデルをホストできる。Pixel は安いスマホではないが、補助プロセッサは大きな GPU よりはるかに安いはずだ

  • 興味深くはあるが、より優れたオートコンプリート以外に用途が何なのか気になる

    • tiny-agent のように、狭い領域のタスク向けにファインチューニングできそうだ https://bair.berkeley.edu/blog/2024/05/29/tiny-agent/
      Apple が向かっているように見えるアプローチが気に入っている。日常的なタスクはファインチューニングされた小さなモデルが処理し、自信を持って処理できないものはデバイス外の大きなモデルに渡す方式だ。低信頼度の回答を出すべき例を含む学習セットを作り、事実上「助けを求める」に相当する出力を追加して、その選択肢を選ぶように学習させられそうだ。小さなモデルなら複数を並列に動かし、さらに別のモデルがリクエストを適切な専門家へルーティングすることもできる
    • メールを読む、メールに返信する、予定を入れる、サービスの API を使う、といったことだ
      基本的に、知識ではなく行動が必要なあらゆるタスク。「妻に遅れると知らせて」と言えば、設定済みの魔法のような方法で何らかのサービスとやり取りして処理するような形だ
      Siri はインターネットなしでもホームオートメーションをかなりうまくこなすが、昔の Google アシスタントや Alexa はまったくそうではなく、オフラインで可能だったこともなかったように思う。これはローカルファーストでうまく動作するアシスタントを可能にする
    • Siri のようなローカルエージェントが簡単なタスクを処理し、より複雑なリクエストはルーティングできる
    • デバイス関連のタスク向けにファインチューニングできる。言い換えれば、デバイス上のアプリケーションやサービスが持つあらゆる機能を、小さなモデルも実質的に利用できる
      ユーザーのリクエストを自然言語の形で該当するアプリケーションに渡し、アプリケーション群を調整できる。デバイス機能を超えるリクエストはクラウドモデルに送れる。デバイスとのやり取りの仕方を変えられるので強力だ
    • スマホで Google AI をテストしてみたが、ブラウザを開いた状態でページを読んでくれと頼むと、インターネットにアクセスできないと答えた
      望む AI アシスタントは、1) 英語と私の母語を理解し、2) 自分が Android や KDE/Linux 上で実行されていることを認識し、「Android 設定のアプリケーションセクションを開いて」「ブラウザで開いているページを読んで」「いま開いているポップアップのテキストを読んで」といった命令を理解し、公開 API で OS と統合されているべきだ。大手 AI 企業は、とくに多言語ユーザーにより良いアシスタントを売る形で競争できる
      3) モデルは小さくあるべきで、地理、歴史、音楽バンドのような知識は知らなくてもよい。ユーザーが質問するタスクは、検索エンジンやオンライン LLM に渡す選択肢があればよい