検証ラボの メトリフクロウ です。単発チャットの「速い／遅い」は大事ですが、ローカルLLMを業務基盤にするなら不足します。IDE、エージェント、バッチ、社内ツールが同時に叩く前提では、同時実行時の振る舞いが本番品質を決めます。
この回の答え
1人の速さではなく、混んだときの崩れ方を測ります。待ち時間は基準線、同時実行と処理量が主戦場です。条件ラベルを残します。
この回だけの用語
| 用語 | ひとことで |
|---|---|
| 待ち時間（latency） | 1本のリクエストが終わるまでの長さ。基準線 |
| 同時実行（concurrency） | 何本を同時に叩くか。盛るノブではなく観測条件 |
| スループット（throughput） | 単位時間あたりのさばき量（トークン毎秒やリクエスト毎秒） |
| TTFT | 返事が始まるまで。混雑時に崩れやすい体感指標 |
| p95 | 遅い側の境目。現場の不満は平均よりここに出やすい |
| max_num_seqs | 同時に並べられるリクエスト上限のノブ |
ポイント
単発 latency は基準線。採用判断の主戦場は concurrency / throughput です。
3種類のベンチを役割分担する
| 種類 | 目的 | 典型パラメータ |
|---|---|---|
| latency | 単発遅延の基準線 | concurrency=1, n=20 |
| concurrency | 同時接続での安定性 | 段階例: c=1→4→8→16（必要なら32）、n=40〜64 |
| throughput | バッチ処理能力 | 既定例: c=16, n=64, max_tokens固定 |
ポイントは、run 間でワークロードを固定し、1軸だけ変えることです。concurrency を上げながらモデルも変えると、何が効いたか分かりません。
パラメータ表は「推奨値」ではなく「比較を揃えるための型」です。環境に合わせて n を増減しても構いませんが、比較セット内では固定してください。トークン毎秒は並列度込みで読む（c=1 と c=16 の数字は別試合です）。
いつどれを使うか
- 新プロファイルの健全性確認: latency → 短い concurrency
- 常駐共有の可否判断: concurrency を段階的に上げる
- 夜間バッチや一括要約: throughput を主軸に
- 長文用途: 入力長を明示した別スイートを用意
読むべき指標
- TTFT: ユーザーが「反応した」と感じるまでの時間
- latency パーセンタイル: 平均だけでなく p95 / p99
- output tokens/sec: 生成速度の比較軸
- requests/sec: 同時利用耐性の比較軸
- error rate: 飽和点や設定ミスの兆候
- 成功数 / 試行数: 分母を残さないと比較が歪む
「平均は良いが p95 が崩れる」「tok/s は高いが error が増える」は、採用判断で特に重要です。現場の不満は平均ではなく長尾に出ます。
| 観測 | 仮説の置き方 |
|---|---|
| c を上げると p95 だけ崩れる | スケジューリングや KV 圧迫を疑う |
| tok/s は高いが error 増 | 飽和。採用前に上限を決める |
| TTFT だけ悪い | prefill / prefix / 初回ロードを疑う |
| 全部悪い | まず到達性・health・ワークロード固定を疑う |
長文脈を測るとき
coding 用途と long-context 用途では、入力長を揃えないと比較になりません。長文側を見るときは、プロンプト長や max_tokens を明示し、可能なら同じ入力ファイルで揃えます。
コンテキストを伸ばすとキーバリューキャッシュ（KV）が膨らみ、見かけの速度だけでなくメモリ上限にも影響します。性能数字は、メモリ枠の話とセットで読んでください。短いデモプロンプトのトークン毎秒を、長文プロファイルの合格証に使わないことが原則です。
ワークロード固定チェック
- [ ] プロンプト本体（または入力ファイル）が同じ
- [ ] max_tokens / temperature など生成条件が同じ
- [ ] thinking の実効（キー名・ON/OFF）と経路（直 / 入口）が同じ
- [ ] concurrency とリクエスト数が記録されている
- [ ] ストリーミング有無が揃っている
- [ ] ウォームアップ方針が揃っている
吞吐比較で temperature を固定することと、品質比較で temperature=0 にしてよいことは別問題です。reasoning 品質側の測定衛生は、品質プレイブックと「数値が嘘をつくとき」側を見てください。
よくある失敗
- デモ用の短いプロンプトだけで結論づける
- ウォームアップ無しの初回だけを計測する
- サーバが未起動のまま数値を見て絶望する（実際は到達不能）
- GPUスナップショットを残さず、メモリ起因か判別できない
- concurrency を一気に最大まで上げ、飽和点を見落とす
- 品質スモークと性能 run の条件が別物になっている
- ゲートウェイ経由の欠測（タイムアウト等）を「低いスコア」に置換して平均を歪める
- prefix cache が効く固定接頭辞だけで測り、本番の可変入力を忘れる
- 同じ GPU に別ワークロード（例: 画像生成）が同居しているのに、モデル差と誤診する
失敗を「モデルが弱い」と即断する前に、到達不能・設定ミス・ワークロード不一致・同居負荷を除外します。
段階的に上げる読み方
いきなり高 concurrency で勝敗を付けない方が、学びが残ります。
- c=1 で基準線（壊れていないか）
- 想定同時利用の半分で安定性を見る
- 想定値で本番相当を見る
- 少し上回せて飽和の兆候を確認する（32 以上は本番影響を見てから）
「どこから崩れるか」が分かると、メモリ枠や max_num_seqs の調整に入れます。崩れる点を知らないまま平均だけ比べると、共有常駐で事故ります。
レポートに必ず残す列
比較表を作るなら、最低でも次を列にします。欠けている列がある表は、後から解釈不能になりやすいです。
- concurrency / n / max_tokens
- TTFT p50・p95
- latency p95（可能なら p99）
- output tok/s と requests/sec
- error rate と成功数
- プロンプト長区分（short / long など）
- 環境ラベル（ハーネス確認 / 実機）
列が多いほど良いわけではありませんが、この欠落は高コストです。特に成功数を残さないと、見かけの平均値だけで判断してしまいます。
つまずいたこと
同時実行を上げると数字が良く見える瞬間があります。その直後に、テールレイテンシが壊れ、現場の体感は最悪、というパターンを何度も踏みました。
計測設計で困ったのは、平均値の美しさと利用者の怒りが一致しないことです。concurrency を「盛れるノブ」として扱い、失敗を観測しないベンチは、むしろ意思決定を歪めました。
この回の要点
- concurrency は盛るノブではなく観測条件
- 平均値よりテールと失敗率を併記する
- 体感悪化を見逃すベンチを採用根拠にしない
同時実行の測り方は公開できますが、特定マシンの tok/s 表はこの回では出しません。テールと失敗率を含む実機値は、再計測と匿名化が済んだものから足します。
次は「ベンチ数字が嘘をつくとき：試験台と実機を混ぜない」です。concurrency 条件をメモしたまま読むと、嘘の切り分けが早くなります。
よくある質問
単発が速ければ十分ですか？
いいえ。業務では同時実行が前提です。混雑時の p95 と error rate を見ないと採用判断になりません。
concurrency の数字はどう振りますか？
型の例は 1→4→8→16。32 は余力があれば。一気に最大まで上げず、崩れる段を残します。
