# ローカルLLM評価手順（検証用運用記録の傾向に基づく整理）

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

**根拠のある事実**：入力長は記録00000の1024トークンから記録00160時点でおよそ12,700トークンまで、1レコードあたり約73トークンずつ単調に増加しています。用途は「社内文書の要約」「コードの説明」「FAQの作成」「議事録の整理」の4種が循環し、同時利用数は1〜4件で周期的に変動しています。開始待ち時間は1〜80秒の範囲で周期的なパターンを示します。

**推測**：開始待ち時間の周期変動は同時利用数の増加に伴うキュー待ちの影響である可能性が高いと考えられます（記録上は相関しか確認できず、因果は未検証です）。

## 2. 評価手順

### ステップ1：測定条件の固定
- 入力長を1024・4096・8192・12288トークンの4段階に設定し、各段階で3回ずつ測定する。
- 同時利用数を1件・2件・4件の3条件で実施し、それぞれ開始待ち時間（リクエスト送信から最初のトークン生成まで）を秒単位で記録する。

### ステップ2：生成速度の測定
- 秒あたり生成トークン数（tokens/sec）を、入力長ごと・同時数ごとに計測する。
- 出力の正確性確認が必要な用途（要約など）では、生成速度だけでなく出力内容の検証も併せて実施する。

### ステップ3：入力処理時間の測定
- プロンプト送信から処理開始までの入力エンコード時間を計測する。入力長が約73トークンずつ増える記録パターンを踏まえ、入力長と処理時間の線形関係を回帰分析で確認する。

### ステップ4：GPUメモリの監視
- `nvidia-smi` または同等のツールで、推論中のメモリ使用量を1秒間隔で記録する。
- 同時利用数4件時のピークメモリがGPU搭載量の80%を超える場合はバッチサイズを削減する。

### ステップ5：同時利用数の影響評価
- 同時数を1→2→4と増やした際の応答時間の変動（中央値と95パーセンタイル）を比較する。
- 応答時間のばらつきが2倍を超える場合は、キュー制御またはサーバー側の同時実行上限の設定を見直す。

### ステップ6：ログの保存
- 上記の全測定値をCSV形式で保存し、部門別・用途別・入力長別に集計可能な形で残す。

## 3. 合格基準（推奨）
開始待ち60秒以内、生成速度の変動幅±20%以内、メモリ余裕20%以上を維持できる構成を以て合格とする。