検証ラボの メトリフクロウ です。ここからは、具体的な評価の手順について解説します。速さの表を作る前に、測る順番と指標名を固定しましょう。
この回の答え
性能は到達性→単発→同時実行の順です。平均だけ見ず、遅い側の境目と終了理由も見ます。起動条件が違う数字は、同じ速さでも別試合です。
この回だけの用語
| 用語 | ひとことで |
|---|---|
| 最初のトークンまでの時間（TTFT） | 返事が始まるまで。体感の主指標 |
| トークン間隔（ITL / TPOT） | 文字が流れる間隔。ストリームの滑らかさ |
| 完了まで（E2E） | 送信から全部終わるまで |
| 同時実行（concurrency） | 何本のリクエストを同時に叩くか |
| p95 | 遅い側の境目。たまに極端に遅い回を見逃しにくくする |
| 終了理由（finish_reason） | 正常終了か、長さ打ち切りか、エラーか |
測る前に、測る順番を決める
性能評価で失敗すると、速い表はできても意思決定が進みません。原因の多くは、指標不足より 順番の間違い です。未起動のまま吞吐を測る、単発だけ見て同時実行を見ない、平均だけ見て p95 を見ない——いずれも現場で起きます。
この回は、社内で繰り返す 性能評価の手順書 です。指標の切り方は、社内の評価軸標準（レイテンシ / スループット / 信頼性）に合わせています。
具体的な計測メニュー
0. 門番（到達性）
/healthまたは同等の疎通- 1リクエストがエラーなく返る
- 環境ラベル（ハーネス確認 / 実機）を記録
- 可能ならウォームアップ数リクエストを計測から除外する（コールドスタートの外れ値除去）
ここが落ちている run は、性能比較に入れません。
1. 単発基準線（レイテンシ）
| 指標 | ひとことで | 記録 |
|---|---|---|
| TTFT | 最初のトークンまで（体感の主指標） | p50 / p95（必要なら p99） |
| ITL / TPOT | トークン間隔（ストリームの滑らかさ） | p50 / p95 |
| E2E latency | 送信〜完了 | p50 / p95 |
| Output tok/s | 単発の出力速度 | 中央値など |
「反応した感」（TTFT）と「完了までの長さ」（E2E）と「流れの滑らかさ」（ITL）を分けます。
2. 同時実行（主戦場・スループット）
同時実行数を段階的に振る（標準例: 1 → 4 → 8 → 16。余力があれば 32）。
同じモデルでも、評価用 eager と本番の CUDA graph では数倍違うことがあるので、表の脚注（サーブ条件）を先に見ます。
ゲートウェイ経由で測る場合は、欠測（タイムアウト等）を低スコアに置換していないかも併記します。同居 GPU 負荷がある日の数字は、モデル差と誤診しやすいです。
併せて次を記録します。
- 集約 Output tok/s、Req/s
- エラー率（5xx / timeout / 空応答の内訳）
- p95 latency の劣化点（飽和する同時実行数）
- 可能なら GPU メモリ / 利用率、KV 占有
社内利用は単発チャットより、同時に叩かれる前提が多いです。単発トークン毎秒だけで本線を決めないのが原則です。
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・プロンプト集合・ハード配置など）を外した計測は、比較不能として注記します。
同じトークン毎秒でも、条件が違えば別試合
社内検証では、同一モデルの生成速度が資料間で数倍ずれて見えることがありました。切り分けの結果、主因はモデル劣化ではなく サーブ条件の差 でした。
| よくあるズレ | まず疑う条件 | メモ |
|---|---|---|
| 本番より極端に遅い | 評価専用サーブで CUDA graph 無効（例: enforce-eager） | 本番設定ではないことがある |
| 中間の遅さ | 並列度 2〜4 相当 | 経路差ではなく同時実行由来が多い |
| 別スタックの速さ | 別エンジン／別量子化 | 「同じ名前」でも試合規則が違う |
| 公開値の飛び値 | 条件不明 | 単ストリームか集約かも不明なら直接比較しない |
純生成速度を並べるときは、定義も揃えます。
- 純 decode: 実コンテンツの最初のトークン以降の速度（role だけのチャンクは数えない）
- prefix cache: 比較目的なら、リクエストごとに nonce 等でヒットを外す
- thinking: ON/OFF とキー名を揃える（揃えないと比較が無効）
社内の統制計測では、thinking・生成長・ゲートウェイ経由の差がほぼゼロで、効いたのは並列度だけ、に見えた結果もあります。ただし後から分かったのは、thinking フラグが評価経路に届いていなかったと、差がゼロに見える測定事故があり得る、ということです。thinking 差を「能力差なし」の一般則にはしません。だからこそ「ゲートウェイが遅い」と決めつける前に、同一条件で経路だけ変えた1軸比較と、条件が本当に届いたかの確認が必要です。
記録テンプレにも、次を足します。
| 項目 | 例 |
|---|---|
| CUDA graph / eager | 有効 / enforce-eager |
| 並列度 | c=1 |
| thinking | OFF / ON（キー名も） |
| 経路 | 直 / ゲートウェイ |
| 純 decode 定義 | 上記どおり |
| 条件証跡 | リクエスト実体を確認済み |
reasoning 系を測るときの衛生
品質に近い条件でも、性能ラベルに混ぜると誤診します。社内で実害になった型だけ先に置きます。
- temperature=0（greedy）は「固定」と同義ではない。推論モデルではベンダーが禁止していることがあり、無限繰り返しや品質崩壊の原因になります
- 生成長の予算は思考が完走できる量で決める。短すぎると
contentだけ空になり、能力不足と区別がつきません（空応答率を併記する） - thinking のキー名はモデル系列で違う（例:
enable_thinkingとthinking）。キー名不一致は OFF と同義です - 条件適用の最終証拠は、評価ハーネスが送ったリクエスト実体です。設定ファイルや CLI の文字列、手動 curl、正答率の差だけでは足りません
読み方テンプレ
| 観測 | 仮説 | 次の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）を取ったか
- [ ] 同時実行の段階（例: 1/4/8/16/32）を事前に決めたか
- [ ] CUDA graph / eager・thinking（キー名込み）・経路をラベルにしたか
- [ ] thinking / 生成条件がリクエスト実体に届いたか確認したか
- [ ] p95 と error rate を必須列にしたか
- [ ] 読み終わった後の「次の1軸」欄があるか
数字のストーリーを作らない
性能評価の「転」は、きれいな表への誘惑です。対外・対内を問わず、次を禁止します。
- 条件が違う run を1枚に混ぜる（eager と本番、c=1 と c=4 を同列にしない）
- 成功数が少ない run を Champion にする
- ハーネス確認値を実機の顔で出す
- 条件不明の公開値を、自環境の基準線と並べる
シナリオで言うと、経営向け資料に「最速構成」を出すなら、脚注に workload と環境ラベルが必要です。脚注がない速さは、意思決定ではなく演出です。
ポイント
性能評価の成果物はトークン毎秒ではなく、「次に変える1軸」です。
つまずいたこと
計測メニューを増やしすぎて、レポートが読めなくなった時期があります。全部測れることと、意思決定に効くことは別でした。
苦労したのは、削ることです。TTFT・テール・throughput・失敗率に絞るまで、「念のため」の列が会議を支配していました。
この回の要点
- レイテンシ（TTFT / ITL / E2E）とスループット（段階同時実行）を分ける
- TTFT・テール・throughput・失敗率を基本セットにする
- サーブ条件（CUDA graph・並列度・thinking・経路）が違う数字は別試合
- 条件差がゼロに見えても、フラグ未到達を疑ってから能力差と読む
- 念のための列で会議を支配させない
プレイブックは測る順と読む順の型です。TTFT / ITL / E2E や段階同時実行の実数は、サーブ条件つきで再計測・匿名化が済んだものから足し、合格ラインは用途ごとに後決めします。
次は「品質の測り方：短い確認から用途別テストへ」です。性能の読み方が揃ったら、品質列の語彙を同じ粒度で揃えます。
よくある質問
最初に測るべき指標は何ですか？
まず到達性（health と1リクエスト成功）。その後 TTFT・ITL/TPOT・E2E を単発で取り、次に concurrency を上げます。
concurrency はどこまで上げますか？
型の例は 1→4→8→16。32 は余力があれば。落ちる段でボトルネック仮説を立てます。一気に最大まで上げません。
平均 tok/s だけで選んでよいですか？
いいえ。p95 と finish_reason（途中打ち切り・エラー）を見ないと、体感と表がずれます。
資料によって tok/s が何倍も違うときは？
まずサーブ条件（CUDA graph 有無・並列度・thinking・経路）を突合します。条件が違う数字は同じ土俵に載せません。
thinking ON/OFF で差がゼロなら、thinking は無視してよいですか？
いいえ。フラグが評価経路に届いていないと、差がゼロに見えます。YAML や CLI の記載だけで安心せず、送信されたリクエスト実体を確認します。
