検証ラボの メトリフクロウ です。ベンチマーク数字は強い説得材料になります。だからこそ危険です。条件が違う数字を「実測」として扱うと、社内外の信頼を一気に失います。速い表は、正しいラベルが付いて初めて意思決定の材料になります。
ここで言うハーネスは、計測や起動の手順が通るかを試す試験台です。本番GPUでの本気の速さ比べとは別物だと思ってください。社内検証でも、開発機でその試験台自体を試す段階と、GPU付き実機でモデルを測る段階を明確に分けています。前者は「測れること」の確認、後者は「比較に使う値」の取得です。混ぜた瞬間に、物語は強くなっても再現性は消えます。
ポイント
条件が違う数字を「実測」として並べると、比較ではなく宣伝になります。
起きやすい混同
| 状況 | 一見すると | 実態 |
|---|---|---|
| 開発機 + モックendpoint | tok/s が出る | モデル推論ではない |
| GPU無しホスト | パイプラインは通る | hardware snapshot にGPUが無い |
| 到達不能endpoint | 評価が0点 | モデルが弱いのではなく未起動 |
| ストリームchunk近似 | token速度に見える | 近似であり実トークンと一致しない場合がある |
| ウォームアップ無し | 遅く見える | 初回ロードやキャッシュ未準備の影響 |
実際、品質スモークが全失敗でも、原因がモデル劣化ではなく JSON decode できない（サーバ未応答） であることがあります。これを「モデル不合格」と誤記すると、次の改善方針がずれます。数字そのものより、失敗の種類分けが先です。
ラベルを先に固定する
run を残すとき、最低でも次のラベルを必須にします。
- 環境種別: harness-check / real-gpu
- endpoint 種別: mock / local-server / remote-server（内部URLは残さない）
- GPU有無: hardware snapshot の要約（機種名の公開可否は別判断）
- 到達性: health OK の有無
- ワークロードID: 比較セット名
このラベルが無い表は、社内共有前に差し戻します。「速い」より「比較可能」を優先する、という原則の実装です。
公開・共有前のチェック
- hardware snapshot に意図したGPUがあるか
- endpoint は実サーバか、モックか
- error rate と成功件数が説明できるか
- 比較対象とワークロードは固定か
- ホスト名や内部URLが成果物に残っていないか
- ハーネス確認値に「実測」「DGX」などの語が混ざっていないか
- 失敗がモデル品質か到達不能かに分類されているか
失敗分類の最小セット
| 分類 | 意味 | 次の一手 |
|---|---|---|
| unreachable | サーバ未応答・未起動 | 起動と health を直す |
| config | parser / メモリ枠など設定起因 | 1軸で再試験 |
| quality | 出力不正・タスク不合格 | モデル/用途適性を疑う |
| saturated | 高負荷で error 増 | 上限と同時実行設計を見直す |
ガードレール（この連載の方針）
- ハーネス確認値を DGX 実測と書かない
- 実機数字は再計測し、匿名化してから出す
- 失敗 run も「失敗の種類」を分けて記録する
- 改善提案は、数字の優劣より次に変える1軸を優先する
- デモ用の短い数値を、常駐共有の合格証に使わない
- 未匿名の生ログや内部エンドポイントを成果物に混ぜない
数値は意思決定の材料であって、物語の装飾ではありません。特に対外説明では、条件が揃っていない比較表は出さない方がマシです。
実務での切り分け手順
疑わしい数字に出会ったら、次の順で潰します。
- health と到達性を確認する
- 環境ラベル（harness-check / real-gpu）を確認する
- 成功数と error rate を見る
- ワークロード固定（c、n、プロンプト）を確認する
- それでも差があるなら、変えた1軸だけを残して再計測する
この順を飛ばしてモデル比較に入ると、設定事故を性能差として誤学習します。
共有資料で起きやすい言い回し
社内スライドや議事録で、次の言い回しが出たら一度止めてください。
| 言い回し | 危険な点 | 言い換え例 |
|---|---|---|
| 「実測でこの tok/s」 | 環境ラベルが無い | 「実機GPU・workload X の計測」 |
| 「開発機でも同傾向」 | モック混入の可能性 | 「ハーネス確認ではパイプライン通過」 |
| 「品質ゼロなので不採用」 | 未起動の可能性 | 「到達不能のため再試験」 |
| 「前回より改善」 | 条件差分が不明 | 「軸Yのみ変更した run 比較」 |
言葉を整えるだけで、数字そのものを変えなくても意思決定の質が上がります。検証ラボの仕事は、強い表を作ることより、比較可能な表を守ることです。
つまずいたこと
いちばん苦いのは、自分たちが作った表で上司を説得した翌週に、前提条件が崩れて数字が意味を失ったことです。嘘をついたわけではないのに、伝え方が嘘に近づく感覚がありました。
苦労したのは、数字を否定することではなく、「この数字が何を固定していたか」を同じスライドに残す 習慣 を作ることでした。かっこいいグラフほど、条件欄が省略されます。
この回の要点
- 数字と同じスライドに固定条件を残す
- 条件が溶けた表は説得材料に使わない
- 美しさより追跡可能性を優先する
いま公開しているのは評価の型です。実機ベンチの数字は、再計測と匿名化が済んだものから順に足します。合格ラインや用途別プロファイルの未確定は残っています。
続きの回（推論エンジンの地図など）は、レビュー完了分から順に公開します。シナリオの先はシリーズ一覧で確認できます。
