2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ローカル LLM で AI コーディング支援環境を構築する④ (ベンチマーク結果)

2
Posted at

はじめに

!!!!! モデルおよびコードの利用は自己責任でお願いします !!!!!

本稿は「ローカル LLM で AI コーディング支援環境を構築する」シリーズの第4回です。今回は Bonsai-8B を実際に動かし、ベンチマーク結果から見えた傾向を整理することをテーマにしています。

前回から紆余曲折がありましたが、一通りのベンチマーク結果を取得できました。本稿では数値そのものよりも「どういう傾向に見えたか」という観点で結果を整理しています。

なおベンチマーク結果については環境依存・条件依存が非常に強いため、あくまで本稿内での参考値としてご覧ください。ここで示す結果がモデルの優劣を示すものではない点をあらかじめご承知おきください。

モデル

Bonsai-8B Qwen2.5-Coder-7B Qwen2.5-Coder-3B Qwen2.5-Coder-1.5B Qwen2.5-7B Mistral-7B
ツール カスタム llama Ollama Ollama Ollama Ollama Ollama
パラメーター 8.19B 7.62B 3.09B 1.54B 約 7B 約 7B
系統 汎用モデル(Qwen3-8B ベース) コード特化 コード特化 コード特化 汎用モデル 汎用モデル
補足 今回の検証の主役 コード生成性能比較用の上位モデル枠 モバイルワークステーションでギリギリ実用になるライン確認用 同程度のメモリ使用量の軽量モデル枠 汎用用途の比較モデル 汎用用途の比較モデル

環境

モバイルワークステーション Azure 仮想マシン
仮想マシンサイズ - Standard NC4as T4 v3
GPU NVIDIA T500×1(VRAM 4GB) NVIDIA T4 ×1(VRAM 16GB)
CPU Core i7-1165G7(4 core) AMD EPYC 7V12(vCPU 4 core)
メモリ 32 GB 28 GB
ディスク SSD(NVMe) Standard SSD

ベンチマークツール

本稿では、以下のベンチマークツールを使用しています。

EvaPlus

主にコード生成タスクを対象としたベンチマークです。

LMEval

汎用的な言語モデル評価フレームワークです。本稿では以下のタスクを使用しています。

  • gsm8k: 数値推論・段階的思考(Chain of Thought)が必要な問題群
  • ifeval: 指示追従性や制約条件の守られ方を見るための評価

EvaPlus の結果と考察

ベンチマーク結果

項目 Bonsai-8B Bonsai-8B Qwen2.5-Coder-7B Qwen2.5-Coder-3B Qwen2.5-Coder-3B Qwen2.5-Coder-1.5B Qwen2.5-Coder-1.5B
環境 モバイルWS Azure VM Azure VM モバイルWS Azure VM モバイルWS Azure VM
base 0.756 0.744 0.872 0.829 0.841 0.683 0.701
base+extra 0.707 0.695 0.841 0.787 0.805 0.628 0.646
実行時間 01:34:19 00:15:43 00:18:33 00:42:29 00:10:53 00:25:35 00:07:00
VRAM 使用量 2323 MB 10661 MB 4883 MB 2385 MB 7323 MB 1447 MB 3945 MB

考察

実行環境はスコアにほぼ影響しない

モバイルワークステーションと Azure 仮想マシンで同一モデルを実行した結果を比較すると、base / base+extra のスコア差はいずれも 0.012 以内に収まっており、実質的に同等です。実行時間には大きな差が出ていますが、「正しくコードを書けるか」という観点では実行環境の影響は軽微であり、EvaPlus の結果はモデル差が支配的と考えられます。

コード特化モデルはパラメーター規模を逆転し得る

Qwen2.5-Coder-3B(3.09B)は、Bonsai-8B(8.19B)よりもパラメーター規模が小さいにもかかわらず、base / base+extra の両指標で上回っています。VRAM 使用量も同程度でありながら、実行時間は半分以下です。

この結果から、コーディング支援用途においてはパラメーター規模よりもコード生成向けの最適化の有無が性能を左右していると考えられます。コーディング支援用途でモデルを選定する際は、コード特化モデルを優先するのが妥当な判断になります。

Bonsai-8B のモバイルワークステーションでの実行時間について

Bonsai-8B はモバイルワークステーション環境で VRAM 使用量が 2323 MB に抑えられている一方、実行時間は 1 時間半以上と今回比較したモデルの中で最長です。

VRAM 使用量が小さいにもかかわらず実行時間が長い理由として、VRAM に収まりきらない演算が CPU にオフロードされている可能性が考えられます。モデルの量子化方式やバックエンドの実装によってはレイヤー単位でオフロードが発生し、GPU-CPU 間のデータ転送がボトルネックになるケースが知られています。
今回はプロファイリングまでは実施していないため、詳細は次回の分析で確認する予定です。


LMEval の結果と考察

ベンチマーク結果

LMEval では「汎用モデルとしての基礎能力」を見る目的で、 2 つのタスクを Azure 仮想マシン上で実行しました。

項目 Bonsai-8B Mistral-7B Qwen2.5-7B
gsm8k(exact match) 0.755 0.455 0.775
ifeval(inst strict) 0.387 0.535 0.761
実行時間 00:51:35 00:55:16 00:51:45
VRAM 使用量 10661 MB 4919 MB 4885 MB

※ gsm8k は flexible-extract / 5-shot の exact match、ifeval は inst_level_strict_acc を代表値として記載しています。

考察

gsm8k:同クラスと同水準

gsm8k では Bonsai-8B(0.755)は Qwen2.5-7B(0.775)に近い水準であり、数値推論・段階的思考の観点では同規模モデルと同等の基礎性能を持っていると考えられます。

ifeval:同クラスに対して明確な差がある

LMEval の inst_level_strict_acc では Bonsai-8B(0.387)、Qwen2.5-7B(0.761)と約 2 倍の差が出ています。一方 PrismML の公式評価では Bonsai-8B の IFEval スコアは 0.798 と報告されており、今回の測定値とは大きく異なります。
IFEval には prompt_level / inst_level、strict / loose の組み合わせで 4 通りの指標があり、どの指標を使うかによってスコアが大きく変わることが知られています。今回の LMEval 測定条件(inst_level_strict_acc)での指示追従性は低い結果となりましたが、測定条件の違いによる乖離の可能性も考えられます。

VRAM 使用量の異常値について

Bonsai-8B の Azure VM での VRAM 使用量(10661 MB)は、同等パラメーター規模の Qwen2.5-7B(4885 MB)の約 2 倍に相当しており、他のモデルと比較して突出しています。これは EvaPlus でも同様の傾向が見られました。

考えられる要因として、Bonsai-8B に使用しているカスタム llama バックエンドと Ollama の KV キャッシュ確保戦略の差異、もしくはモデルの量子化形式の違いによるメモリレイアウトの差が挙げられますが、現時点では確定的な原因を特定できていません。
次回、詳細なリソース使用量の分析として明らかにしていく予定です。


おわりに

今回の結果を整理すると、以下の点が確認できました。

  • コーディング支援を主目的とする場合はコード特化モデルを選ぶのが合理的
  • gsm8k では同クラスと同水準、ifeval では劣化しているが公式評価ではこちらも同水準。判断が難しいですが、本稿ではほぼ同水準としておきます。
  • Bonsai-8B はモバイルワークステーション環境では低 VRAM に収まる一方、 Azure VM 環境では VRAM 使用量が突出して大きい。
  • 全ベンチマークを通じて処理時間はパラメーター規模にほぼ比例する傾向を確認。ただし Bonsai-8B は低 VRAM 環境では処理時間の増大が発生、 CPU オフロードの影響が考えられる。

次回は引き続き Bonsai-8B を取り上げて、リソース使用量分析にて Azure VM 環境での VRAM 使用量の突出と低 VRAM 環境における処理時間増大の原因を明らかにしていく予定です。

本稿を読んでいただきありがとうございました。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?