# ローカルLLM評価手順（検証用記録00000〜00647に基づく）

## 1. 記録データの傾向（根拠）

- **入力長**：記録番号にほぼ比例して増加（記録ごとに約73トークン増、約1024〜30000トークンの範囲）。用途（要約・コード説明・FAQ・議事録）は13部門で周期的に循環しており、用途と入力長の相関は見られない。
- **同時利用数**：1〜4件が周期的に変化。
- **開始待ち時間**：1〜80秒の範囲で周期的に変動し、データ上は入力長と無相関に見えるが、これは周期構造による疑似相関の可能性がある（推測）。
- ※本記録は架空データのため、以下の手順は「実際の計測でこの傾向を検証する」ことを目的とする。

## 2. 評価手順

**（1）計測条件の固定**
同一のモデル・バージョン・プロンプトを用意する。GPUドライバと推論フレームワークのバージョンを記録する。バックグラウンド処理を停止し、電源設定を高性能に固定する。

**（2）生成速度の計測**
入力長を約1000/5000/10000/20000/30000トークンの5段階に揃えたテストセットを作る。各段階で10回生成し、秒あたり出力トークン数（tokens/s）を計測して平均と標準偏差を求める。入力長が増えると生成速度が低下するか（プリフィル処理の増大）を確認する。

**（3）入力処理時間の計測**
リクエスト送信から最初のトークン出力までの時間（Time To First Token）を記録する。入力長ごとに TTFT を整理し、線形増加するか、閾値を超えた際に急増するか（KVキャッシュのスワップ等）を確認する。

**（4）GPUメモリの計測**
`nvidia-smi` を1秒間隔で実行し、各リクエスト中のメモリ使用量のピークを記録する。入力長別のピーク値を比較し、コンテキスト長の上限（OOMが発生するトークン数）を特定する。余裕率は「（総容量−ピーク使用量）÷総容量」で算出する。

**（5）同時利用数の影響の計測**
同時リクエスト数を1/2/3/4件に変えて負荷試験を行う。各水準で（2）（3）（4）を再計測し、並列化による速度低下率と待ち時間の増分を求める。開始待ち時間が同時数に比例して伸びるかを検証する。

**（6）結果の整理**
入力長・同時数を軸に速度・TTFT・メモリを表にまとめ、閾値（目標応答時間、メモリ余裕50%等）を定めて合否を判定する。外れ値は再計測して確認する。

## 3. 注意点

本記録の待ち時間パターンは周期的に生成されたものであり、実際の相関は実機計測でのみ判断すること。