検証ラボの メトリフクロウ です。ここからは、評価の具体に入ります。速さの表を作る前に、測る順番と指標名を固定しましょう。
測る前に、測る順番を決める
性能評価で失敗すると、速い表はできても意思決定が進みません。原因の多くは、指標不足より 順番の間違い です。未起動のまま吞吐を測る、単発だけ見て同時実行を見ない、平均だけ見てp95を見ない——いずれも現場で起きます。
この回は、社内で繰り返す 性能評価の手順書 です。指標の切り方は、社内の評価軸標準（レイテンシ / スループット / 信頼性）に合わせています。
具体的な計測メニュー
0. 門番（到達性）
/healthまたは同等の疎通- 1リクエストがエラーなく返る
- 環境ラベル（harness / real）を記録
- 可能ならウォームアップ数リクエストを計測から除外する（cold start の外れ値除去）
ここが落ちている run は、性能比較に入れません。
1. 単発基準線（レイテンシ）
| 指標 | ひとことで | 記録 |
|---|---|---|
| TTFT | 最初のトークンまで（体感の主指標） | p50 / p95（必要なら p99） |
| ITL / TPOT | トークン間隔（ストリームの滑らかさ） | p50 / p95 |
| E2E latency | 送信〜完了 | p50 / p95 |
| Output tok/s | 単発の出力速度 | 中央値など |
「反応した感」（TTFT）と「完了までの長さ」（E2E）と「流れの滑らかさ」（ITL）を分けます。
2. 同時実行（主戦場・スループット）
- concurrency を段階的に振る（標準例: 1 → 4 → 8 → 16 → 32）
- 集約 Output tok/s、Req/s
- error rate（5xx / timeout / 空応答の内訳）
- p95 latency の劣化点（飽和 concurrency）
- 可能なら GPU メモリ / 利用率、KV 占有
社内利用は単発チャットより、同時に叩かれる前提が多いです。単発 tok/s だけで本線を決めないのが原則です。
3. 信頼性（速さの脚注）
| 見るもの | なぜ |
|---|---|
| 成功率 / エラー率 | 速いが落ちる構成を弾く |
finish_reason 分布 | length 過多は max_tokens 不足のシグナル |
| 空応答 | reasoning 消費やパーサ問題の早期発見 |
記録テンプレ（最低限）
| 項目 | 例 |
|---|---|
| run_id | 20260729-… |
| profile | gemma4-nvfp4 |
| workload | c=8, n=64, max_tokens=256 |
| TTFT p95 | （値） |
| ITL/E2E p95 | （値） |
| agg tok/s / req/s | （値） |
| error rate | （値） |
| finish_reason 備考 | stop 多め / length 多め など |
| 次の1軸 | KVのみ変更 など |
固定条件（temperature・プロンプト集合・ハード配置など）を外した計測は、比較不能として注記します。
同じ tok/s でも、条件が違えば別試合
社内検証では、同一モデルの decode 値が資料間で数倍ずれて見えることがありました。切り分けの結果、主因はモデル劣化ではなく サーブ条件の差 でした。
| よくあるズレ | まず疑う条件 | メモ |
|---|---|---|
| 本番より極端に遅い | 評価専用サーブで CUDA graph 無効（例: enforce-eager） | 本番設定ではないことがある |
| 中間の遅さ | 並列度 2〜4 相当 | 経路差ではなく concurrency 由来が多い |
| 別スタックの速さ | 別エンジン／別量子化 | 「同じ名前」でも試合規則が違う |
| 公開値の飛び値 | 条件不明 | 単ストリームか集約かも不明なら直接比較しない |
純 decode を並べるときは、定義も揃えます。
- 純 decode: 実コンテンツの最初のトークン以降の速度（role だけのチャンクは数えない）
- prefix cache: 比較目的なら、リクエストごとに nonce 等でヒットを外す
- thinking: ON/OFF を揃える（揃えないと比較が無効）
社内の統制計測では、thinking・生成長・ゲートウェイ経由の差がほぼゼロで、効いたのは並列度だけ、という結果もありました。だからこそ「ゲートウェイが遅い」と決めつける前に、同一条件で経路だけ変えた1軸比較が必要です。
記録テンプレにも、次を足します。
| 項目 | 例 |
|---|---|
| CUDA graph / eager | 有効 / enforce-eager |
| 並列度 | c=1 |
| thinking | OFF |
| 経路 | 直 / ゲートウェイ |
| 純 decode 定義 | 上記どおり |
読み方テンプレ
| 観測 | 仮説 | 次の1軸 |
|---|---|---|
| TTFTだけ悪い | スケジューリング/プレフィル | prefix/chunked 等 |
| cを上げるとerror増 | 枠不足・過負荷 | mem/util、max seqs |
| 平均は良いがp95悪化 | 長尾と渋滞 | batch/context |
| tok/s高いが業務不満 | 品質側の問題 | 品質スイートへ |
| length が多い | 出力打ち切り | max_tokens / reasoning 余裕 |
チェックリスト（性能runの前）
- [ ] health / 到達性を確認したか
- [ ] 単発基準線（TTFT / ITL or E2E / tok/s）を取ったか
- [ ] concurrency 段階（例: 1/4/8/16/32）を事前に決めたか
- [ ] CUDA graph / eager・thinking・経路をラベルにしたか
- [ ] p95 と error rate を必須列にしたか
- [ ] 読み終わった後の「次の1軸」欄があるか
数字のストーリーを作らない
性能評価の「転」は、きれいな表への誘惑です。対外・対内を問わず、次を禁止します。
- 条件が違うrunを1枚に混ぜる（eager と本番、c=1 と c=4 を同列にしない）
- 成功数が少ないrunをChampionにする
- ハーネス確認値を実機の顔で出す
- 条件不明の公開値を、自環境の基準線と並べる
シナリオで言うと、経営向け資料に「最速構成」を出すなら、脚注に workload と環境ラベルが必要です。脚注がない速さは、意思決定ではなく演出です。
ポイント
性能評価の成果物は tok/s ではなく、「次に変える1軸」です。
つまずいたこと
計測メニューを増やしすぎて、レポートが読めなくなった時期があります。全部測れることと、意思決定に効くことは別でした。
苦労したのは、削ることです。TTFT・テール・throughput・失敗率に絞るまで、「念のため」の列が会議を支配していました。
この回の要点
- レイテンシ（TTFT/ITL/E2E）とスループット（段階 concurrency）を分ける
- TTFT・テール・throughput・失敗率を基本セットにする
- サーブ条件（CUDA graph・並列度・thinking・経路）が違う数字は別試合
- 念のための列で会議を支配させない
いま公開しているのは評価の型です。実機ベンチの数字は、再計測と匿名化が済んだものから順に足します。合格ラインや用途別プロファイルの未確定は残っています。
次は「品質評価プレイブック：スモークから用途別スイートへ」へ進みます。いまのメモを1行残してから読むと、連載の筋がつながりやすくなります。
よくある質問
最初に測るべき指標は何ですか？
まず到達性（health と1リクエスト成功）。その後 TTFT・ITL/TPOT・E2E を単発で取り、次に concurrency を上げます。
concurrency はどこまで上げますか？
社内型では 1→4→8→16→32 を基本階段にします。落ちる段でボトルネック仮説を立てます。
平均 tok/s だけで選んでよいですか？
いいえ。p95 と finish_reason（途中打ち切り・エラー）を見ないと、体感と表がずれます。
資料によって tok/s が何倍も違うときは？
まずサーブ条件（CUDA graph 有無・並列度・thinking・経路）を突合します。条件が違う数字は同じ土俵に載せません。
