検証ラボの メトリフクロウ です。ベンチマーク数字は強い説得材料になります。だからこそ危険です。条件が違う数字を「実測」として扱うと、社内外の信頼を一気に失います。速い表は、正しいラベルが付いて初めて意思決定の材料になります。
この回の答え
試験台の数字と実機の数字を混ぜません。環境ラベルを先に固定し、条件が違う数字は同じ土俵に載せません。全モデルが大きく下回るときは測定条件を疑います。
この回だけの用語
| 用語 | ひとことで |
|---|---|
| ハーネス確認 | 計測手順が通るかの試験台。本番の速さ比べではない |
| real-gpu | 比較に使う値を取る実機計測 |
| 到達性 | サーバが生きて応答できるか。品質以前の前提 |
| 環境ラベル | 「どの試合の数字か」を表す札。無い表は差し戻す |
| workload | 同時実行・出力長など負荷条件のセット |
ここで言うハーネスは、計測や起動の手順が通るかを試す試験台です。たとえで言うと、CI のモック試験と本番負荷試験を同じ表に載せない、に近い感覚です。社内検証でも、開発機でその試験台自体を試す段階と、GPU付き実機でモデルを測る段階を明確に分けています。前者は「測れること」の確認、後者は「比較に使う値」の取得です。混ぜた瞬間に、物語は強くなっても再現性は消えます。
ポイント
条件が違う数字を「実測」として並べると、比較ではなく宣伝になります。
起きやすい混同
| 状況 | 一見すると | 実態 |
|---|---|---|
| 開発機 + モックendpoint | tok/s が出る | モデル推論ではない |
| GPU無しホスト | パイプラインは通る | hardware snapshot にGPUが無い |
| 到達不能endpoint | 評価が0点 | モデルが弱いのではなく未起動 |
| ストリームchunk近似 | token速度に見える | 近似であり実トークンと一致しない場合がある（チャンク数≠実トークン数のことがある） |
| ウォームアップ無し | 遅く見える | 初回ロードやキャッシュ未準備の影響 |
| CUDA graph 無効の評価サーブ | 本番より極端に遅い | enforce-eager 等で 本番設定ではないことがある（CUDA グラフを切った評価用起動＝本番より遅く出やすい） |
| 並列度だけ違う | 中間の遅さに見える | 経路差ではなく concurrency 由来であることが多い |
| 条件不明の公開値 | 飛び値に見える | 単ストリームか集約かも不明なら並べない |
| ゲートウェイ欠測を低スコア置換 | 「品質が悪い」に見える | タイムアウト等の欠測を平均に混ぜていないか |
| prefix cache 前提のデモ入力 | 過大に速く見える | 本番の可変接頭辞では効かないことがある |
| GPU 同居負荷あり | モデル差に見える | 別プロセス（例: 画像生成）の競合を疑う |
| 全モデルが公開スコアを大きく下回る | 「モデルが弱い」に見える | 測定側の異常シグナル。sampling・生成長・thinking を先に疑う |
| thinking ON/OFF で差なし | 能力差なしに見える | フラグが評価経路に届いていないことがある |
| 思考が終わらず無限に伸びる | モデルの限界に見える | temperature=0（greedy）など、公式が禁止する設定のことがある |
| モデル間の順位が公開値と逆 | 新しい発見に見える | 誤設定はモデルごとに効き方が違い、順位まで入れ替わる |
※ harness-check / real-gpu は連載での公開用環境ラベルです。実装では hardware_snapshot 等として残します。
実際、品質スモークが全失敗でも、原因がモデル劣化ではなく JSON decode できない（サーバ未応答） であることがあります。これを「モデル不合格」と誤記すると、次の改善方針がずれます。数字そのものより、失敗の種類分けが先です。
品質ベンチでも同じです。複数モデルがそろって公開スコアを大きく下回ったら、個別症状をモデルへ帰属させる前に測り方を疑うのが定石です。「思考の暴走」も、greedy decoding の産物であることがあります。
ラベルを先に固定する
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軸で再試験 |
| measurement-invalid | 条件が届いていない・公式禁止設定で測っている | sampling / thinking / 生成長 / リクエスト実体を直す |
| quality | 出力不正・タスク不合格 | モデル/用途適性を疑う |
| saturated | 高負荷で error 増 | 上限と同時実行設計を見直す |
条件が適用されたことの最終証拠は、評価ハーネスが送ったリクエスト実体です。設定ファイルの記載、手動の疎通確認、正答率の差だけではすり抜けます。モックの受信側で payload を一度撮ると、測れていない run を「差がない」と誤読しにくくなります。
ガードレール（この連載の方針）
- ハーネス確認値を DGX 実測と書かない
- 実機数字は再計測し、匿名化してから出す
- 失敗 run も「失敗の種類」を分けて記録する
- 改善提案は、数字の優劣より次に変える1軸を優先する
- デモ用の短い数値を、常駐共有の合格証に使わない
- 未匿名の生ログや内部エンドポイントを成果物に混ぜない
数値は意思決定の材料であって、物語の装飾ではありません。特に対外説明では、条件が揃っていない比較表は出さない方がマシです。
実務での切り分け手順
疑わしい数字に出会ったら、次の順で潰します。
- health と到達性を確認する
- 環境ラベル（harness-check / real-gpu）を確認する
- 成功数と error rate を見る
- ワークロード固定（c、n、プロンプト）を確認する
- それでも差があるなら、変えた1軸だけを残して再計測する
この順を飛ばしてモデル比較に入ると、設定事故を性能差として誤学習します。
共有資料で起きやすい言い回し
社内スライドや議事録で、次の言い回しが出たら一度止めてください。
| 言い回し | 危険な点 | 言い換え例 |
|---|---|---|
| 「実測でこの tok/s」 | 環境ラベルが無い | 「実機GPU・workload X の計測」 |
| 「開発機でも同傾向」 | モック混入の可能性 | 「ハーネス確認ではパイプライン通過」 |
| 「品質ゼロなので不採用」 | 未起動の可能性 | 「到達不能のため再試験」 |
| 「公開スコアより大幅に低い」 | 測定事故の可能性 | 「条件を突合してからモデルを疑う」 |
| 「thinking 差なし」 | フラグ未到達の可能性 | 「リクエスト実体で ON を確認した」 |
| 「前回より改善」 | 条件差分が不明 | 「軸Yのみ変更した run 比較」 |
言葉を整えるだけで、数字そのものを変えなくても意思決定の質が上がります。検証ラボの仕事は、強い表を作ることより、比較可能な表を守ることです。
つまずいたこと
いちばん苦いのは、自分たちが作った表で上司を説得した翌週に、前提条件が崩れて数字が意味を失ったことです。嘘をついたわけではないのに、伝え方が嘘に近づく感覚がありました。
苦労したのは、数字を否定することではなく、「この数字が何を固定していたか」を同じスライドに残す習慣を作ることでした。かっこいいグラフほど、条件欄が省略されます。
この回の要点
- 数字と同じスライドに固定条件を残す
- 条件が溶けた表は説得材料に使わない
- 全モデル未達や順位逆転は、まず測定無効を疑う
- 美しさより追跡可能性を優先する
ハーネス確認と実機計測を同じ表に載せない、というガードはここで固定します。実機側の数字は再計測と匿名化が済んだものだけを後続回で足し、合格ラインは用途合意のあとです。
続き（推論エンジンの地図など）はレビュー完了分から順に公開します。シナリオの先はシリーズ一覧で確認できます。
よくある質問
ハーネス確認と実機計測の違いは何ですか？
ハーネスは計測手順が通るかの試験台、実機は比較に使う値の取得です。前者の数字を後者の実測として並べると再現性が消えます。
品質スモークが全失敗したらモデル不合格ですか？
いいえ。サーバ未応答や JSON decode 失敗など、到達性の問題であることがあります。失敗の種類分けが先です。
公開してよい数字の条件は？
環境ラベルと workload が揃い、内部URLや未確定の合格ラインを混ぜていないものだけです。未計測の tok/s は捏造しません。
複数モデルがそろって公開スコアを大きく下回ったら？
まず測定条件（sampling・生成長・thinking キー・リクエスト実体）を疑います。モデル弱さより先に、測り方の異常を潰します。
