ローカルSLM/閉じた環境で動作する生成AIを検証してみた (②性能指標とログの取り方編)

はじめに

ご無沙汰しております。生成AIを「社内や現場のローカルで使いたい」そんな思いからスタートした、このローカル生成AI・SLM検証シリーズ。
第一回では、OllamaとOpen WebUIを使って、閉じた環境で動作する生成AI(ローカルSLM)を構築し、その手順や構成イメージを紹介しました。
「クラウドに出せない」「ネット接続できない」――そんな制約下でも生成AIを活用できることに、興味を持っていただいた方も多かったようです。もしまだ第一回の記事をご覧になっていない方は、こちらのローカルSLM/閉じた環境で動作する生成AIを検証してみた (①環境構築編)も合わせてご覧ください。

そして今回は、その次の ”現実的な課題” に踏み込みます。「実際に動かしたこのローカルSLM、果たしてどこまで“実用レベル”なのか?」それを、数値で見える化する方法と、実際に取れたデータを交えてご紹介します。

もちろん、前回の記事を読んでいなくても大丈夫です。
「オフライン環境でも、ここまでできるのか!」と感じていただける内容になっていますので、ぜひ最後までお付き合いください。
 
【記事の要約】
読了までの時間 : 12~15分
得られるメリット : ローカルSLMにおける性能指標の可視化やログの取得方法がわかる

 

SLMの“実力”をどう測るか?

生成AIといえば、「文章の自然さ」や「賢さ」に目がいきがちですが、ローカルでの業務活用を考えた場合、それだけでは不十分です。
むしろ、重要になるのは性能指標(ベンチマーク)です。

たとえば──

  • 処理が遅すぎてストレスになる
  • GPUのメモリを食いすぎて、他のアプリが動かなくなる
  • 非GPU環境では使い物にならない

こういった“現場あるある”を避けるためにも、定量的な指標でモデルを評価することが欠かせません。

実務で重視したい 5つの指標

私が今回意識したのは、次の5つです。

指標 意味と実務での重要性
tokens/sec
どれだけ速く文章を生成できるか
(1秒あたりに生成されるトークン数、スループット設計の基礎)
初期応答時間 ユーザーが待たされる体感時間
VRAM使用量 実行できるPCやサーバーの条件把握に直結
CPU使用率 非GPU環境やエッジデバイスの負荷確認
出力自然性 実用性や読みやすさの評価基準

 
これらは、2024年に公開された「Small Language Models: Survey, Measurements, and Insights」という論文でも、SLMの評価軸としてしっかり整理されています
なお、今回はその中でも、比較的取得が容易だった「tokens/sec(生成速度)」を中心に測定を行いました。他の指標については、今後、取得方法の工夫を進め、順次可視化していく予定なので、ご理解いただければ幸いです。

 

前提条件

今回の検証は、以下のPC環境で実施しています。前回の記事と同じ構成です。

OS Windows 11 Home (24H2)
CPU AMD Ryzen AI9 HX370
メモリ 32GB
ディスク 1TB
GPU/VRAM NVIDIA GeForce RTX 4060 / 8GB

 
なお、今回の検証内容や結果は、この構成に基づくものです。環境が異なる場合は、性能傾向が変わる可能性がある点にご注意ください。

 

ローカル環境での測定の壁と工夫

「じゃあ、その数値、どうやって取るの?」これが意外とハマりどころでした。
第一回で構築したOllamaとOpen WebUIの構成だと、
  • tokens/sec(1秒あたりに生成されるトークン数)
  • 初期応答時間

といった細かなデータは、素直に取れません。
また、WebUI側のOpen WebUIを直接いじって表示させることも考えましたが、アップデート対応が大変なので現実的ではないと判断しました。(Open WebUIのリリース状況を見てもわかるように、ほぼ毎週、時には週に数回アップデートがあります。そのたびに中身を直接修正するのは、現実的ではありませんよね…)

リレー処理を導入して“外から覗く”

そこで考えたのが、OllamaとOpen WebUIの間に、リレー処理をかます方法です。
具体的には、以下のイメージです。

このプロキシで、リレー処理の中でリクエストとレスポンスを覗き見ることで、

  • プロンプト送信時刻
  • 最初の応答トークンの戻り時刻
  • トータルの生成時間
  • tokens/secの算出結果(1秒あたりに生成されるトークン数)

といったログ情報を出力する仕組みを考えてみました。

実際のコード

リレー処理で使用する「自作プロキシ」処理ですが、今回は Python を使ったシンプルなFlaskアプリケーションで実装してみました。
以下が「自作プロキシ」のコード( proxy_server.py)になります。

ポイントは、Ollamaへのリクエストを中継しつつ、必要な情報だけログに記録する部分です。
また、このプロキシ処理内で使用しているライブラリを取得する requirements.txt も用意する必要があるのでお忘れなく!( requirements.txt は上記コードと同じ場所に配置してください)

実行環境のフォルダ構成

「記事は見たけど、自分の環境で動かせないと意味がない」そんな方のために、今回私が検証したフォルダ構成の全体イメージを載せておきます。(フォルダ構成内のコメント先頭に (*) があるフォルダは、新規で作成する必要があります)

この構成であれば、必要なファイルを同じ階層にまとめておけるので、環境再現や構成管理が非常に楽になります。ぜひ参考にしてみてください。

Dockerイメージ化と実行手順

次に、上記で作成した「自作プロキシ」を含めてリレーさせるように、以下のように compose.yaml を用意します。
(自作プロキシが上記「実際のコード」で作成した proxy_server.py となります。また、既存の構成がない場合でも、この内容で新規作成すれば問題ありません)

ポイントは、Open WebUIのリクエストをプロキシ(proxyコンテナ)経由にすることです。
この構成なら、Open WebUIのバージョンアップがあって内部仕様が変わっても、プロキシで外側からリクエストを見ているため、ログの取得に影響しにくい構成になります。

 

実際に取れたログとその考察

リレー処理を挟んだ結果、以下のようなログが取れました。(ログは抜粋して表示してます)

今回検証したのは、以下の4つのローカルSLMモデルです。それぞれの特徴と、実際に取得できた平均トークン生成速度(tokens/sec)は次の通りでした。
モデル名 パラメータ規模 特徴・備考 平均 tokens/sec
qwen2.5vl:7b 7B 軽量・高速モデル 35.7
gemma3n:e4b 12B相当(最新) gemma3系の最新世代、最適化モデル 20.5
gemma3:12b 12B 標準的な中量モデル、バランス型 14.7
gemma3:27b 27B 高精度寄りの大型モデル、低速 4.0
※ 平均値は小数第2位まで、四捨五入
 
考察まとめ
この検証結果から、以下のことが見えてきました。
 
qwen2.5vl:7b
群を抜いて高速で、トークン生成速度は 35〜38 tokens/sec 程度を記録した。
軽量モデルならではのメリットを最大限に活かせるため、ローカル環境でのチャットボットや簡易生成タスクには最適といえる。
gemma3:12b
トークン生成速度は約 13〜15 tokens/sec で、中量モデルとしては標準的な結果であった。
qwen2.5vl:7b と比べると速度面では劣るが、より安定した出力品質や汎用性の高さが期待でき、処理時間と品質のバランスを重視する場面では有力な選択肢となる。
gemma3n:e4b 最適化世代という特徴通り、同じ12Bクラスでも約20〜22 tokens/sec と、旧世代の gemma3:12b より明確に高速化されている。
速度と品質のバランスが取れており、現実的な業務用途で最も扱いやすい中量モデルの一つといえる。
gemma3:27b トークン生成速度は約 3.8〜4.2 tokens/sec と、他モデルと比べて圧倒的に低速である。
その代わり、出力品質や精度重視の大型モデルであり、リアルタイム性を必要としない高品質生成タスク(文書要約、テキスト生成など)では十分に価値を発揮する。ローカル環境で使う場合は、運用用途を見極めた上で導入を検討する必要があるといえる。
 
また、今回出力した内容以外にも、リレー処理上のログの出力内容を修正することで、出力させる情報のカスタマイズが可能です。
 
このように、
  • モデルごとの推論時間
  • トークン生成速度(tokens/sec、1秒あたりに生成されるトークン数)
といった客観的な数値をもとに、ローカルSLMの実用性や適用範囲を見極める判断材料を得ることができました。
 
 

まとめと次の展開

今回の検証から得られたポイントは以下の通りです。

 ✅ ローカルSLMの実力を、数値で“見える化”できた
 ✅ プロダクト側を改造せず、ログを外から自由に加工できる構成が組めた
 ✅ 実用性や限界を、感覚ではなくデータで判断できるようになった

次回の展開

次は、さらに実業務に寄せた以下のテーマにも踏み込みたいと考えています。

  • ローカルSLMとRAGの実務レベル活用
  • ビジョンモデルやオフィス文書対応の検証
  • 特に、社内で多用されるExcelやPowerPoint、PDFの要約・活用性の評価

生成AIは“魔法”ではなく、“現実的なツール”です。だからこそ、我々としては、こうした地道な検証を積み重ねて、現場にフィットする使い方を今後も模索していこうと思います。

それでは、また次回もお楽しみに!

お問い合わせ先

執筆者プロフィール

Kiuchi Tomoyuki
Kiuchi Tomoyukitdi デジタルイノベーション技術部
社内の開発プロジェクトやクラウド・データ活用の技術サポートを担当しています。データエンジニアリングやシステム基盤づくりなど、気づけばいろんなことに首を突っ込んできましたが、やっぱり「まずは試してみる」がモットー。最近は、ローカル生成AIやコード生成AIといった、開発現場ですぐ役立つ生成AIの活用にハマり中。もっと楽に、もっとスマートにものづくりできる世界を目指して、あれこれ奮闘しています。

関連記事