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

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

**根拠のある事実**
- 入力長は記録00000の1024トークンから記録00160の12704トークンまで、1記録あたり73トークンずつ増加している。
- 同時利用数は1〜4件で周期的に変動し、用途(要約・コード説明・FAQ作成・議事録整理)と確認項目も4パターンで循環している。
- 開始待ち時間は同時利用数と相関している傾向がある(例：同時4件では待ちが長くなる場面が多い)。

**推測(記録だけでは確定しない点)**
- 開始待ちの増加は同時利用数だけでなく、入力長の増大によるプリフィル処理時間の影響も含んでいる可能性がある。
- 部門ごとの違いは負荷パターンの違いを模したものであり、実際の部門特性を示すものではない。

## 2. 評価手順

### 手順1: 測定条件の固定
各記録の条件(入力長・同時利用数・用途)を再現できるプロンプト一式を用意する。入力長は1024トークン起点で73トークン刻みの系列を確認し、同一条件で3回以上繰り返して平均を取る。

### 手順2: 生成速度の測定
タイムスタンプ機能付きでローカルLLMを実行し、出力トークン数÷生成秒数でトークン/秒を算出する。同時利用1件と4件でそれぞれ測定し、同時実行時の速度低下率を比較する。要約・コード説明・FAQ作成・議事録整理の各用途で出力長が異なるため、用途ごとに集計を分けること。

### 手順3: 入力処理(プリフィル)時間の測定
リクエスト送信から最初のトークン生成開始までの時間を記録する。入力長1024と12704で比較し、トークン数あたりの処理時間(ミリ秒/トークン)を算出する。73トークン増加ごとの時間差が線形か、コンテキスト長の閾値を超えると急増するかを確認する。

### 手順4: GPUメモリの監視
nvidia-smi等を1秒間隔で記録し、ピーク使用量と余裕率を測定する。入力長と同時利用数を組み合わせた4×4の条件で最大ピークを特定する。同時4件・最大入力長でOOM(メモリ不足)が発生するかを必ず確認し、発生する場合はバッチサイズの上限を記録する。

### 手順5: 開始待ち(キューイング)時間の評価
リクエスト受付から実行開始までの待ち時間を同時利用数別に集計する。同時1件と4件の待ち時間差からキューのボトルネックを評価し、待ち時間が応答時間全体に占める割合を算出する。

### 手順6: 応答時間の変動評価
同一条件の複数回実行結果から標準偏差を求める。コード説明など対話用途では変動が大きいと実用性が下がるため、平均値だけでなくばらつきを報告する。

### 手順7: 付随確認
- 出力の正確性：要約タスクで原文との一致度を人手または別LLMで判定する。
- ログの保存：全測定結果をタイムスタンプ付きで保存し、条件再現できるようにする。

## 3. 報告形式
入力長×同時利用数のマトリクスで、生成速度・プリフィル時間・ピークメモリ・待ち時間の4指標を表形式でまとめ、限界条件(最大入力長・最大同時数)を明記する。