← 最新の論文
🤖 machine learning

What actually runs: a measurement study of language model placement and decode speed on the Apple Neural Engine

Apple Neural Engineにおける言語モデルの配置とデコード速度に関する厳密な測定研究を通じて、著者は、モデルのアーキテクチャ単体ではなく、計算表現と重みのエンコーディングがアクセラレータへの常駐性とパフォーマンスを決定することを実証しており、これにより、大幅に小型かつ高速な三値モデルを実現するためにエンコーディング効率を優先する設計手順を導き出している。

原著者: Shahir M A

公開日 2026-08-25✓ Author reviewed
📖 1 分で読めます☕ さくっと読める

原著者: Shahir M A

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む

スマートフォンが会話を理解しようとしている場面を想像してみてください。そのためには、デバイス上で直接、巨大なデジタル脳である言語モデルを動かさなければなりません。これがスムーズに機能するためには、スマートフォンは汎用的なメインの脳ではなく、この種の思考のために特別に設計された、超高速なプロセッサを使用する必要があります。課題は、この特殊なプロセッサが非常に「偏屈」であることです。特定の種類の計算は実行しますが、たとえ数学的に同一であっても、それ以外の計算は拒否します。長年、開発者たちはどの計算が動作するか、そしてどうすれば速くなるかを推測しようと試みてきましたが、それはしばしば間違った経験則に頼っていました。彼らは、モデルが十分に小さければ高速なプロセッサで動作するはずだとか、数値を小さくすれば常に助けになるはずだ、といった仮定を立ててきました。しかし、誰もプロセッサが実際に何をしているのかを観察したり、モデルのサイズや数値の保存方法が速度にどのように影響するかを正確に測定したりしたことはありませんでした。

研究者の Shahir M A は、推測をやめて観察することに決めました。Apple の M1 チップを搭載したコンピュータを使用し、言語モデルがスマートフォンの特殊なプロセッサ(Neural Engine と呼ばれるもの)上で動作しようとする際に、具体的に何が起きるのかを確認するための一連の実験を構築しました。彼らは、ソフトウェアが「何をする」と言っているかを見るだけでなく、チップ内を流れる実際の電気やデータの動きを測定し、実際に何が起きているのかを確認しました。彼らは、同じ数学的演算を構築する数十通りの方法をテストし、さまざまなサイズの実際のモデルを訓練し、標準的な精度から非常に圧縮された低精度フォーマットまで、モデル内の数値の保存方法を変更しました。彼らの目的は単純でした。何がモデルを高速プロセッサに乗せるのか、そして一度乗ることができたら、どれほど速く話せるようになるのかを突き止めることでした。

彼らが最初に発見したのは、プロセッサは計算の意味には関心がなく、それがどのように書かれているかのみを気に利かせているということでした。彼らは、ある特定の正規化(モデルの数値を安定させるためのステップ)をある方法で記述すると、プロセッサは即座に受け入れ、フルスピードで実行することを発見しました。しかし、全く同じ数学的ステップを、わずかに複雑な一連の命令を用いて別の方法で記述すると、プロセッサはそれを拒絶し、スマートフォンに低速な汎用脳を使用することを強制しました。それはまるで、プロセッサが特定の「数学のダイアレクト(方言)」を話しているかのようです。もし適切な方言を使えば、プロセッサは耳を傾けますが、たとえ意味が同じでも異なる方言を使えば、プロセッサは立ち去ってしまいます。これは、開発者がどのようにコードを書くかが、数学そのものと同じくらい重要であることを意味しています。

二番目の、そしておそらく最も驚くべき発見は、モデルのサイズだけが高速プロセッサでの動作を決定するわけではないということです。研究者たちは、標準的な精度で書かれた約2,600万パラメータを持つモデルは、特殊なプロセッサで動作するには小さすぎると発見しました。そのモデルは低速な脳での実行を余儀なくされ、一単語を生成するのに1秒以上かかっていました。しかし、その全く同じモデルの内部数値を圧縮してビット数を減らしたところ、プロセッサは突然それを受け入れたのです。圧縮されたバージョンは高速プロセッサ上で動作し、1秒足らずで言葉を生成しました。実際、より小さなモデルにおいては、数値を圧縮することこそが、高速プロセッサに乗せる唯一の方法でした。プロセッサには隠れたルールがありました。小さなモデルは、圧縮されていない限り実行しないというルールです。これは、「大きなモデルほど高速なプロセッサを必要とする」という一般的な仮定を覆しました。ここでは、小さなモデルこそが、その門をくぐるために圧縮を必要としていたのです。

モデルが高速プロセッサの中に入ると、速度は数学の複雑さではなく、ほとんどすべて「どれだけのデータが移動しなければならないか」によって決まりました。研究者たちはデータの流れを測定し、モデルが単語を一つ生成するたびに、その知識を構成する数値のセット(重み)全体をプロセッサにストリーミングしなければならないことを発見しました。これは、会話がどれほど長く続こうとも、単語ごとに発生します。このため、速度はそれらの重みのビット数に直接結びついていました。圧縮された低精度の数値を使用するモデルは、データの移動量がはるかに少なかったため、より高速でした。彼らは、2ビットの数値を使用するモデルは、標準的な数値を使用するモデルよりも、単に移動するデータが少ないという理由だけで、3倍近く速いことを発見しました。モデルが使用する数学の種類(例えば、アテンションに重点を置いているか、畳み込みに重点を置いているか)は、一度プロセッサ上で動作し始めると、速度にはほとんど影響しませんでした。唯一重要だったのは、移動するデータのサイズでした。

研究者たちは、スマートフォンのための言語モデルを構築する最善の方法は、サイズからではなく、圧縮から始めることであると結論付けました。大きなモデルを作ってからそれを縮小しようとするのではなく、まず最も圧縮されたフォーマットを選択し、その上で利用可能なメモリ予算をパラメータの追加に充てるべきなのです。彼らは、特定の圧縮数学を用いた2,500万パラメータのモデルが、わずか10メガバイトのスペースに収まり、約0.6ミリ秒で単語を生成できることを発見しました。これは、開発者が通常から始める標準的な未圧縮モデルと比較して、容量は10倍小さく、速度は3倍速いものでした。この研究は、デバイス上の高速な言語モデルへの道は、モデルを大きくしたり複雑にしたりすることではなく、数学を記述する正しい方法と、数値を保存する正しい方法を選択することにあると証明しました。実際のデータの流れを測定することで、彼らは、スピードの鍵は単に高速なプロセッサを持つことではなく、いかに正確にそれを「食べさせる(供給する)」かを知ることであると証明したのです。

自分の分野の論文に埋もれていませんか?

研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。

Digest を試す →