# ローカルLLM評価手順(検証用記録00000〜00648の分析に基づく)

## 記録から読み取れる傾向
- 入力長は約1,024トークンから約30,900トークンまで単調増加し、途中(記録00411以降)で再び小さくなる周期がある。
- 同時利用数は1〜4件で周期的に変化し、開始待ち時間は1〜80秒でほぼ規則的に推移している。
- 用途は「社内文書の要約」「コードの説明」「FAQの作成」「議事録の整理」の4種が固定の確認項目(出力の正確性/応答時間の変動/GPUメモリ余裕/ログの保存)と対応して循環している。
- これらは生成した架空データであり、待ち時間と入力長の相関は設計上の規則性から来るもので、実機の挙動とは限らない点に注意する。

## 評価手順
1. **測定条件の固定**： プロンプト長を1,000/5,000/10,000/20,000/30,000トークンの5段階に用意し、同時利用数を1件・2件・3件・4件の4水準で実施する。各条件につき3回以上繰り返して平均を取る。
2. **生成速度の測定**： 1リクエストあたりの出力トークン数をカウントし、総生成時間で割ってトークン/秒を算出する。入力長を変えながら同条件で比較し、長文時の低下有無を確認する。
3. **入力処理時間の測定**： リクエスト送信から最初のトークンが返るまで(タイム・トゥ・ファースト・トークン)を計測する。これはプレフィックス処理・KVキャッシュ構築時間に相当し、入力長に対して線形かどうかをプロットで確認する。
4. **GPUメモリの確認**： `nvidia-smi` を1秒間隔で記録し、ピーク使用量と余裕を記録する。同時利用数を1→4件へ増やしながら、メモリがバッチ数に比例して増えるか、オーバーフロー(空き不足エラー)が起きる直前の同時数を特定する。
5. **同時利用数の違いの評価**： 同時数を増やした際のトークン/秒の合計(スループット)と、1リクエストあたりの応答時間の伸びを分けて記録する。開始待ちが秒単位で大きく伸びる場合はキュー待ちがボトルネックと判断する。
6. **品質確認**： 用途別に、要約は出力の正確性(元文書との照合)、コード説明は応答時間の変動、FAQ作成はGPUメモリ余裕、議事録整理はログの保存確認をチェック項目として評価する。
7. **結果の整理**： 入力長×同時数のマトリクスで速度・メモリ・待ち時間を表にまとめ、許容可能な運用条件(例：同時4件で待ち60秒以内か)を明示する。