# ローカルLLM評価手順（検証用記録の傾向を踏まえた整理）

## 1. 記録から読み取れる傾向

本記録は、部門1〜13の周期的な構成で、入力長が1レコードあたり約73トークンずつ増加し、1024〜30000トークン超まで推移している（推測：一定の増分を意図的に設定した合成データ）。同時利用数は1〜4件、開始待ちは1〜80秒で周期的に変動しており、入力長と開始待ちの間に明確な相関は確認できない。これは待ち時間が入力長ではなくキューの滞留に依存することを示唆する（推測）。なお記録00411付近で入力長が一時的に小さく戻っており、記録の断片化やセッションの分断を示す可能性がある（推測）。

## 2. 評価手順

**(1) 測定環境の固定化**
評価前にGPUドライバ、CUDA、推論フレームワーク（llama.cpp、vLLM等）のバージョンを記録し、バッチサイズ・コンテキスト長・量子化方式を固定する。温度や最大出力トークン数も統一し、再現可能な状態を作る。

**(2) 生成速度の測定**
入力長1024、2048、4096、8192、16384トークンのダミー文書を各5回ずつ実行し、秒あたり出力トークン数を記録する。入力長が2倍になるたびに速度がどう変化するか（線形か、飽和するか）をグラフ化して確認する。

**(3) 入力処理時間（prefill時間）の測定**
リクエスト送信から最初のトークンが出力されるまでのTTFT（Time To First Token）を計測する。入力長ごとのTTFT差分から、1,000トークンあたりの処理時間を算出し、長文での遅延要因を特定する。

**(4) GPUメモリの評価**
nvidia-smiまたは同等のツールで、入力長・同時実行数（1件／2件／4件）ごとのメモリ使用量をサンプリングする。同時利用4件×最大入力長でのピーク値を測定し、搭載メモリに対する余裕率（目安20%以上）を確認する。OOMが発生した場合はバッチを分割する。

**(5) 同時利用数の負荷試験**
同時利用数を1、2、4件に設定し、各条件で10リクエストを投入する。各リクエストの応答時間を記録し、同時数の増加に伴う速度低下率と開始待ち時間の増加を測定する。記録の開始待ち1〜80秒の変動を再現し、キュー待ちがサーバ側設定（同時実行数上限）由来かを切り分ける。

**(6) 確認項目ごとの検証**
出力の正確性（要約タスク）：入力文書の要点が含まれるかを人手またはLLM-as-a-judgeで採点する。応答時間の変動：同一条件での分散を算出する。GPUメモリ余裕：ピークと平均の差を確認する。ログの保存：全リクエストのタイムスタンプ・入力長・応答時間がログファイルに残ることを確認する。

**(7) 報告**
上記の測定値を表形式でまとめ、入力長・同時数・応答時間・メモリ使用量の相関を明記して提出する。