# ローカルLLM評価手順のまとめ

## 1. 記録から確認できる傾向（根拠）
- 入力長は1,024トークンを起点に73トークンずつ単調増加し、約30,900トークンで1,027に戻る周期性を持つ。長い入力ほど事前処理（トークナイズ＋プレフィル）時間が伸びる可能性が高い。
- 開始待ちは1秒から11秒刻みで80秒まで増減する周期を持ち、キュー待ちのばらつきをシミュレートしている。同時利用数は1〜4件で、2件以上の記録では待ち時間の変動を必ず確認項目に含めている。
- 用途は「社内文書の要約」「コードの説明」「FAQの作成」「議事録の整理」の4種が循環し、確認項目は「出力の正確性」「応答時間の変動」「GPUメモリ余裕」「ログの保存」に対応している。
- 記録00411付近で入力長が約30,900トークンから約1,000トークンへ急減しており、データリセットまたは異常値の可能性があるため、評価前に外れ値チェックが必要である（以上が記録に基づく根拠。推測は以降の手順に含める）。

## 2. 評価手順
1. **準備**：記録の入力長（1,024〜30,909トークン）に対応するテスト文書を4用途分ずつ用意し、同時利用1〜4件の4パターンを定義する。測定前にnvidia-smiでGPUメモリの空きを記録する。
2. **単発評価（同時1件）**：各用途の代表入力について、入力長を1,024 / 5,000 / 10,000 / 20,000 / 30,000トークン近傍の5段階に調整し、トークン化完了時刻と最初のトークンが出るまでの時間（Time to First Token）を計測する。入力処理時間＝リクエスト送信から最初の出力までと定義する。
3. **生成速度**：出力トークン数を総時間で割り、トークン/秒を用途別に算出する。入力長が長いほど速度が低下するかを比較する。
4. **同時利用評価**：同時2〜4件で同一モデルに並列リクエストを送り、(a) 応答時間の中央値と95パーセンタイルの差（変動）、(b) 開始待ち時間（キュー滞留）を記録する。記録の傾向に従い、同時数が増えるほど待ち時間がどう伸びるかを検証する。
5. **GPUメモリ**：各実行中にnvidia-smiを1秒間隔で取得し、ピーク使用量と残り余裕を記録する。同時4件でメモリ不足（OOM）が発生する閾値を特定する。
6. **正確性とログ**：要約・FAQ出力は元文書との一致箇所を人手で標記し、コード説明は実行可能かを確認する。全リクエストのプロンプト・応答・タイムスタンプをJSONで保存し、保存先の冗長化を確認する。
7. **報告**：入力長×同時数のマトリクスで速度・待ち時間・メモリを整理し、外れ値（入力長の急変など）を明記して推奨構成を提示する。

（約1,000文字）