【ITニュース解説】Benchmarking Gemma 4 E2B on CPU with llama.cpp: A Practical Local AI Experiment

近年、人工知能（AI）技術の進化は目覚ましく、私たちの仕事や生活に大きな影響を与えている。特に大規模言語モデル（LLM）は、文章の生成や質問応答など、多岐にわたるタスクで活用が進む。しかし、これらのAIモデルを動かすには高性能なコンピューターや、クラウドベースのサービス利用が一般的であり、常にインターネット接続が必要であったり、コストがかかったりする課題がある。この実験は、そうした課題を解決し、手元のコンピューター、つまりローカル環境でAIモデルを快適に動かすための実践的な取り組みである。

目標は、クラウドサービスに頼らず、自分自身のコンピューターでAIチャットボットを動かしたり、ビジネス文書や技術文書のドラフトを作成したり、簡単な表計算分析をAIに手伝ってもらったりすることだ。また、様々なコンピューターでAIモデルを効率的に動かすための方法を学ぶことも目的の一つである。コンピューターの性能、特に中央演算処理装置（CPU）は機種によって大きく異なるため、一つの設定がすべてのコンピューターで最適に動作するわけではない。そこで、どんな環境でも適用できるような基本的な評価方法を確立し、最適な設定を見つけるための第一歩として、この実験が行われた。

この実験で使われたコンピューターは、一般的なオフィス環境でも見かけるような、比較的性能が限られたマシンである。CPUはAMD Athlon 3000Gというモデルで、同時に実行できる処理の流れ（論理スレッド）が4つ、実際にデータを計算する部分（物理コア）は2つという構成だ。グラフィック機能もCPUに内蔵されたものを使っている。AIを動かすための環境としては、Windows上でLinuxのプログラムを実行できるWSL (Windows Subsystem for Linux) を使用し、WSLに割り当てられたメモリは5GBに制限されていた。AIの処理を担うソフトウェアは「llama.cpp」というもので、特に「llama-server」というプログラムを使ってCPUだけで推論（AIに考えさせる処理）を実行した。

AIモデルとしては「Gemma 4 E2B」というGoogleが開発したモデルの「GGUF」形式のファイルが使われた。GGUFは、AIモデルを効率的にCPUで実行するために特別に最適化されたファイル形式の一つである。「Q4_K_XL」という表記は、モデルの情報を「量子化」という技術で軽量化し、少ない計算資源で動かせるようにしたことを意味する。命令チューニング（instruction-tuned）されているため、ユーザーの指示を理解し、それに沿った応答を生成するように訓練されている。この実験の目的は、このモデルがこの特定のコンピューター上で、どのような設定で動かせば最も効率的になるかを理解することであった。

最初のステップとして、基本的な設定でllama-serverを起動し、AIがどれくらいの速度で情報を生成できるかを測定した。AIが情報を生成する速度は「トークン/秒」という単位で表される。トークンとは、AIが扱う最小単位の情報のことで、英語なら単語や記号、日本語なら単語や漢字一文字などがこれに相当する。最初の設定では、平均して1秒あたり約4.6トークンを生成できることが分かった。

次に、この生成速度を向上させるために、AIの動作に関わるいくつかの設定（パラメーター）を変更してテストした。特に重要なのは、CPUが同時に処理できる流れの数を示す「スレッド数」と、AIが一度に処理するデータのまとまりの大きさを示す「バッチサイズ」である。例えば、CPUの論理スレッド数が4つなので、そのうち3つをAIの生成処理に、4つをバッチ処理に割り当てる設定を試したところ、速度は約5.9〜6.1トークン/秒に向上した。しかし、すべての論理スレッドである4つのスレッドを生成処理に割り当てても、必ずしも性能が向上するわけではなく、今回のテストでは逆に少し遅くなる場合もあった。これは、スレッド数を増やしすぎると、かえって処理の連携が複雑になり、オーバーヘッドが生じる可能性があることを示唆している。これらの初期のテストは、あくまで最適な設定を探るための「探索的」なものであり、厳密な科学的検証とは異なる点に注意が必要だ。

さらに、AIの動作を細かく制御するための様々なパラメーターを追加してテストを行った。例えば、「-ngl 0」という設定は、AIの推論処理をグラフィック処理装置（GPU）ではなく、すべてCPUで行うことを明示的に指示するものだ。また、「--cache-type-k q8_0」と「--cache-type-v q8_0」は、AIが以前の会話履歴を記憶するための「キャッシュ」のデータ形式を量子化されたものに指定し、メモリの使用量を抑えながら効率を上げることを目指す。その他にも、AIの応答の多様性を調整する「温度（--temp）」や「トップP（--top-p）」、「トップK（--top-k）」といったサンプリングに関するパラメーターも設定したが、これらは主に生成されるテキストの品質や特性に影響を与えるものであり、直接的に性能を向上させるものではない。これらのパラメーターを一度に複数追加した結果、生成速度は約6.4トークン/秒に達した。しかし、複数のパラメーターを同時に変更したため、どのパラメーターが具体的に速度向上に寄与したかを特定することは難しい。

これまでの探索的なテストの中で、最も良い結果を出した構成では、約6.6トークン/秒という生成速度を記録した。この設定は、生成スレッド数を3、バッチ処理スレッド数を4、AIが一度に考慮できる情報の量を示す「コンテキストサイズ」を2048、そしてバッチサイズを128と32にするというものだった。これに、前述のCPUのみで推論を行う設定や、キャッシュの量子化設定、サンプリング設定などが加わる。この構成は現在のところの「暫定的な最適設定」であり、普遍的にすべての環境で最良であると断言できるものではない。特にバッチ設定は、AIがプロンプト（ユーザーからの入力）を処理する速度と、その後のトークンを生成する速度に異なる影響を与える可能性があるため、より詳細な検証が必要である。

実際にこのAIモデルをオフィス業務で試すために、マレー語で社内システムの定期メンテナンスに関する覚書を作成するよう指示するプロンプトを与えてみた。AIは指示に従い、セキュリティパッチの適用、パッケージの更新、ログ監視、不適切なメンテナンスのリスク、そしてメンテナンスを運用計画に含めることの推奨など、関連性の高い内容を含む覚書を生成した。このテストでは、約6.0トークン/秒の速度で、126トークンのプロンプトから391トークンの文書を約65秒で生成できた。生成された文書は、正式な形式で内容も適切であったが、プロンプトにはない「2024年5月26日」という特定の日付を勝手に生成してしまうという注意点も明らかになった。これは、ローカルAIであっても、生成された情報には誤りや根拠のない詳細が含まれる可能性があるため、実際の業務で利用する際には必ず人間による内容確認と修正が必要であることを示している。このことから、AIアシスタントの評価は、生成速度のような「性能」と、生成された情報の正確性や適切さのような「品質」という二つの側面から行うべきであることが強調される。

今回の測定は、様々な設定を試行錯誤しながら行ったものであり、厳密な科学的ベンチマークとは異なるため、結果はまだ予備的なものだ。プロンプトの内容や出力の長さが毎回同じではなかったり、複数のパラメーターを同時に変更したりしたため、個々の設定が性能にどう影響するかを正確に判断することは難しい。より信頼性の高いベンチマークを行うには、毎回同じプロンプトと出力制限を使用し、コンピューターとAIモデルを常に同じ状態から開始させ、各設定で複数回テストを実行し、その中央値や平均値を記録するといった厳密な手順が必要となる。また、AIがプロンプトを理解する速度と、実際にテキストを生成する速度を分けて測定することや、AI動作中のメモリ使用量、CPUの使用率、熱の状態なども詳細に監視することが重要だ。

この実験の最終的な目標は、今回の経験をもとに、異なるCPU世代やコア数、メモリ制限を持つ様々なコンピューターで、AIモデルを効率的に動かすための再現可能な評価方法を確立することである。そのためには、各コンピューターのハードウェア情報、使用したソフトウェアのバージョン、AIモデルの詳細、そして設定パラメーター、性能指標、リソース使用量、さらに生成されたテキストの品質まで、詳細なデータを記録していく計画だ。

推奨されるテスト手順としては、まず今回の実験で得られた暫定的な最適設定を基準として、一度に一つのパラメーターだけを変更しながら検証を進める。例えば、CPUの特性に合わせてスレッド設定を細かく調整したり、AIが一度に記憶できる情報量（コンテキストサイズ）を変更してメモリ消費と性能への影響を比較したり、バッチサイズがプロンプト処理と生成速度にどう影響するかを詳細に調べたりする。さらに、キャッシュの種類を変えてメモリ使用量と速度、安定性、出力品質の変化を測定することも含まれる。そして最後に、実際のオフィス業務（チャットボット、文書作成、表計算分析）を模した一連のタスクを各マシンで実行し、単なるベンチマークの数値だけでなく、実用性に基づいた最適な構成を見つけることを目指す。

これまでの初期実験から、いくつかの重要な教訓が得られた。まず、CPUのみの一般的なコンピューターでも、構造化されたビジネス文書をAIに生成させることが可能であることだ。最高速度は6.6トークン/秒という結果だが、より厳密な評価が必要である。次に、CPUのスレッド数をただ増やせば性能が向上するわけではないこと、そしてAIの応答の多様性を調整するサンプリングパラメーターは、性能向上ではなく望ましい応答特性を得るために選ぶべきであることが分かった。コンテキストサイズやバッチ設定、キャッシュの種類といったAIの動作に関わる主要なパラメーターは、それぞれ個別にその影響を評価することが重要だ。また、特に性能が限られたコンピューターでは、メモリ使用量やCPUの熱安定性も重要な考慮事項となる。AIが生成する情報の正確性は、生成速度とは別に厳しく評価する必要があり、スプレッドシート分析のような複雑なタスクでは、スプレッドシート全体をAIに渡すのではなく、必要な情報だけを抽出してAIに提示するなど、賢いデータの扱い方が求められる。

結論として、この実験は、Gemma 4 E2Bモデルをllama.cppを使って、一般的なCPUハードウェアで動かすための基礎を築いた。現在の暫定的な最適設定は、生成スレッド3、バッチスレッド4、コンテキストサイズ2048、そしてバッチ設定128と32という組み合わせで、探索的テストでは最高約6.6トークン/秒を記録した。しかし、この実験の真の目標は、単一のコンピューターの性能を最大化することではなく、様々なCPU構成を持つ複数のコンピューターで、実用的なAIアシスタントを動かすための再現性のある方法を確立することにある。最終的な成功は、応答性が高く、質の良い下書きを作成でき、文書作成や基本的なデータ分析を人間のレビューのもとでサポートできるような、日常業務に役立つローカルAIアシスタントを実現することだ。ベンチマークの初期探索フェーズは完了し、今後はより体系的なテストと新しいマシンでの検証が待たれる。