検証ラボの メトリフクロウ です。単発チャットの「速い/遅い」は大事ですが、ローカルLLMを業務基盤にするなら不足します。IDE、エージェント、バッチ、社内ツールが同時に叩く前提では、同時実行時の振る舞いが本番品質を決めます。latency は基準線、concurrency / throughput が採用判断の主戦場です。
ポイント
単発 latency は基準線。採用判断の主戦場は concurrency / throughput です。
3種類のベンチを役割分担する
| 種類 | 目的 | 典型パラメータ |
|---|---|---|
| latency | 単発遅延の基準線 | concurrency=1, n=20 |
| concurrency | 同時接続での安定性 | c=8〜16, n=40〜64 |
| throughput | バッチ処理能力 | c=16, n=64, max_tokens固定 |
ポイントは、run 間でワークロードを固定し、1軸だけ変えることです。concurrency を上げながらモデルも変えると、何が効いたか分かりません。パラメータ表は「推奨値」ではなく「比較を揃えるための型」です。環境に合わせて n を増減しても構いませんが、比較セット内では固定してください。
いつどれを使うか
- 新プロファイルの健全性確認: 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 キャッシュが膨らみ、見かけの速度だけでなくメモリ上限にも影響します。性能数字は、メモリ枠の話とセットで読んでください。短いデモプロンプトの tok/s を、長文プロファイルの合格証に使わないことが原則です。
ワークロード固定チェック
- [ ] プロンプト本体（または入力ファイル）が同じ
- [ ] max_tokens / temperature など生成条件が同じ
- [ ] concurrency とリクエスト数が記録されている
- [ ] ストリーミング有無が揃っている
- [ ] ウォームアップ方針が揃っている
よくある失敗
- デモ用の短いプロンプトだけで結論づける
- ウォームアップ無しの初回だけを計測する
- サーバが未起動のまま数値を見て絶望する（実際は到達不能）
- GPUスナップショットを残さず、メモリ起因か判別できない
- concurrency を一気に最大まで上げ、飽和点を見落とす
- 品質スモークと性能 run の条件が別物になっている
失敗を「モデルが弱い」と即断する前に、到達不能・設定ミス・ワークロード不一致を除外します。ここを飛ばすと、次の改善軸がずれます。
段階的に上げる読み方
いきなり高 concurrency で勝敗を付けない方が、学びが残ります。
- c=1 で基準線（壊れていないか）
- 想定同時利用の半分で安定性を見る
- 想定値で本番相当を見る
- 少し上回せて飽和の兆候を確認する
「どこから崩れるか」が分かると、メモリ枠や max_num_seqs の調整に入れます。崩れる点を知らないまま平均だけ比べると、共有常駐で事故ります。
レポートに必ず残す列
比較表を作るなら、最低でも次を列にします。欠けている列がある表は、後から解釈不能になりやすいです。
- concurrency / n / max_tokens
- TTFT p50・p95
- latency p95（可能なら p99）
- output tok/s と requests/sec
- error rate と成功数
- プロンプト長区分（short / long など）
- 環境ラベル（harness-check / real-gpu）
列が多いほど良いわけではありませんが、この欠落は高コストです。特に成功数を残さないと、見かけの平均値だけで判断してしまいます。
つまずいたこと
同時実行を上げると数字が良く見える瞬間があります。その直後に、テールレイテンシが壊れ、現場の体感は最悪、というパターンを何度も踏みました。
計測設計で困ったのは、平均値の美しさと利用者の怒りが一致しないことです。concurrency を「盛れるノブ」として扱い、失敗を観測しないベンチは、むしろ意思決定を歪めました。
この回の要点
- concurrency は盛るノブではなく観測条件
- 平均値よりテールと失敗率を併記する
- 体感悪化を見逃すベンチを採用根拠にしない
いま公開しているのは評価の型です。実機ベンチの数字は、再計測と匿名化が済んだものから順に足します。合格ラインや用途別プロファイルの未確定は残っています。
次は「数値が嘘をつくとき：ハーネス確認と実機計測の差」へ進みます。いまのメモを1行残してから読むと、連載の筋がつながりやすくなります。
