# ローカルLLM評価手順のまとめ(約1000文字)

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

まず、検証用記録から以下の規則性が確認できます(根拠)。

- **入力長の増加**:記録00000の1,024トークンから記録00160で12,704トークンまで、1件あたり73トークンずつ単調に増加しています。
- **同時利用数の周期性**：1件→2件→3件→4件のサイクルが繰り返されています。
- **開始待ちの変動**：1〜80秒の範囲で増減を繰り返しており、同時利用数が増えるほど開始待ちが長くなる傾向が推測されます(推測：記録上は周期変動と見えるため、実測での切り分けが必要)。
- **用途と確認項目の対応**：要約→出力の正確性、コード説明→応答時間の変動、FAQ作成→GPUメモリ余裕、議事録整理→ログの保存、がセットで検証対象になっています。

## 2. 評価手順

### 手順1:測定条件の固定
入力長を1,000/3,000/5,000/10,000トークンの4段階、同時利用数を1〜4件の4段階に設定し、計16条件のマトリクスで測定します。各条件で3回以上繰り返し、中央値を採用してください。目的は「入力長による影響」と「同時実行による影響」を独立に切り分けることです。

### 手順2:生成速度の測定
1条件につき、(a) 1トークンあたりの生成速度(トークン/秒)、(b) 最初の1トークンが出るまでの時間(Time To First Token)、(c) 全体完了時間を記録します。同時利用数を1件から4件へ増やしながら、生成速度が何件目から低下し始めるかを特定します。低下の開始点が実用上の同時処理上限の目安になります。

### 手順3:入力処理時間の測定
プロンプト送信からモデルが処理を完了し生成を開始するまでの時間(プリフィル処理時間)を入力長別に測定します。1,000トークンと10,000トークンで処理時間が線形に増えるか、閾値を超えると急増するかを確認してください。急増する場合はコンテキスト長制限やキャッシュ不足を疑い、設定(コンテキストサイズ、KVキャッシュ容量)を見直します。

### 手順4:GPUメモリの確認
`nvidia-smi`(NVIDIAの場合)を1秒間隔で実行し、各条件でのピークメモリ使用量と空き容量を記録します。特に同時利用4件×入力長10,000トークン条件が最大負荷となるため、ここでOOM(メモリ不足エラー)が発生しないか確認してください。余裕が最大条件でも20%未満しかない場合は、同時数の上限を下げるかバッチサイズを削減します。

### 手順5:開始待ち時間の分解
開始待ちを「キュー待ち時間」と「モデルロード・推論準備時間」に分けて記録します。同時利用数が増えるとキュー待ちが支配的になるはずです。目安として、開始待ちが操作上許容できる秒数(例:30秒)を超える条件を「要対策」とし、リクエストの分散化やキュー上限設定を検討します。

### 手順6:用途別確認項目の検証
- **社内文書の要約**：元文書と要約の要点一致を人手でサンプリング検査(入力長が長い条件ほど省略・誤要約が増えるか確認)
- **コードの説明**：同一コードに対する応答時間のばらつき(標準偏差)を測定し、変動が大きい条件を特定
- **FAQ作成**：