速さと正しさは別もの：二軸で評価する

検証ラボの メトリフクロウ です。ローカルLLMの比較で起きやすい誤解は、「速いモデル＝良いモデル」です。実際の業務では、速くてもJSONが崩れる、ツールを呼べない、回答が不安定、というモデルは使えません。速さは必要条件の一つであって、十分条件ではありません。

この回の答え

速さだけでは採用できません。待ち時間・同時実行と、短い品質確認の合否を同じ通し番号に残します。門番を通っていない候補に重い試験を積みません。

この回だけの用語

社内検証では、評価を相補的な 二軸 で設計しています。たとえで言うと、速さの表と正しさの表を、同じ実験ノートに貼る、です。

1. 性能（benchmark）: 同時実行数 / スループット / 待ち時間 / TTFT
2. 品質（eval）: 用途別タスクの合否・スコア

どちらも同じ run_id 配下に残し、後から並べられるようにします。片方だけが優秀な run は、採用判断ではなく「次に何を直すか」の材料です。

ポイント
速さだけでは決めない。性能と品質を同じ run_id に残します。

なぜ二軸が必要か

特に複数人同時利用やバッチ処理を前提にするなら、単発の体感速度だけでは不十分です。逆に、構造化出力や tool calling が必要な業務では、スモーク品質すら通らない構成を速度比較しても意味が薄いです。門番（＝最小の品質スモークで足切り）を通っていない候補に重いベンチを積むのは、計測の浪費です。

性能軸で取るもの

OpenAI互換エンドポイントに対して、実際の利用に近い形で計測します。初回に揃える指標は次です。

• latency（待ち時間） p50 / p95 / p99 / 平均
• TTFT p50 / p95（ストリーミング最初のチャンク）
• output tokens/sec、requests/sec（throughput＝単位時間あたりのさばき量）
• concurrency（同時実行）条件ごとの上記指標
• error rate、成功数、wall time
• 可能なら GPU 使用率・メモリ（無ければスキップ）

後続の性能プレイブックでは、ITL / TPOT（トークンが流れる間隔）や Goodput（SLA を満たした処理量）も足します。初回は「返事が始まるまで」「完了まで」「同時に何本」が分かれば十分です。

latency とは何か

latency（レイテンシ） は、リクエストを投げてから 応答が完了するまで の待ち時間です。利用者から見ると「全部出終わるまでの長さ」に近い指標です。

同じ「速い」でも、TTFT が短くて latency が長い（考え始は速いが完了が遅い）、その逆、があり得ます。会議では「速い」を latency / TTFT / throughput のどれで言っているかを先に固定します。

平均より p95 / p99 とは何か

計測を100回行ったとき、待ち時間は毎回同じではありません。速い回もあれば、たまに極端に遅い回もあります。

平均は、その100回を足して割った「真ん中あたりの印象」です。一方 p95（95パーセンタイル） は、「遅い方から数えて上位5%に入る境目」——ざっくり言えば 100回中95回は、これ以下の待ちで終わった という値です。p99 は同じく 100回中99回はこれ以下 です。p50 は中央値で、並べたときの真ん中です。

例です。ある条件で latency が次のような分布だったとします。

• たいてい 2 秒前後
• たまに 20 秒

このとき平均はまだ「まあまあ」に見えても、p95 や p99 は大きく崩れます。利用者の不満は平均ではなく、たまに踏む長い待ちに出ることが多いので、採用判断では平均より p95（必要なら p99）を併記します。

読むときの目安も固定します。

主軸は concurrency 条件つきの latency / throughput です。単発の最良 latency だけ見て勝ち宣言しない、がこの回のルールです。常駐マルチユーザ前提では、同時実行を上げたときの p95 latency と error rate の方が採用判断に効きます。

品質軸で取るもの

最初は大きなベンチマークセットより、失敗が分かりやすいスモークが有効です（まずは足切り。深い比較は連続スコアへ、というのが後続の品質プレイブックです）。

• coding: 期待する関数定義が含まれるか
• JSON: 必須キーを持つ妥当なJSONか
• tool calling: 期待ツールが必須引数付きで呼ばれるか

後から judge モデルによる採点を足せますが、まずはオフラインで判定できる scorer（採点器）から始めると運用が安定します。品質ゼロの原因が「モデル劣化」か「到達不能」かを分けられないと、二軸設計は崩れます。ハーネス確認値（試験台の数字）と実機値は、同じ表に混ぜません。

同じ run に残す理由

性能と品質を別フォルダ・別日付で取ると、後から突き合わせるコストが跳ねます。同じ run_id に次を同居させます。

• 起動プロファイル名と設定要約
• 性能サマリ（concurrency、主要パーセンタイル）
• 品質サマリ（pass_rate、タスク別失敗理由）
• 環境メモ（実機かハーネス確認か、GPU 有無）
• 判定（採用 / 再試験 / 廃棄）と次の1軸

「速いがJSONが崩れる」を一文で言える状態が、ステークホルダー向け説明の最短経路です。

実務テンプレ

1. 用途を決める（例: コーディングエージェント）
2. 性能ワークロードを固定する（concurrency、max_tokens、プロンプト）
3. 品質スイートを固定する
4. 変えたい軸を1つだけ選ぶ（ランタイム、KV、contextなど）
5. run を残し、性能要約と品質要約を並べる
6. 「採用する / 捨てる / 再試験」を記録する
7. 次ループの仮説を1行で書く

判定の目安（例）

品質が赤いとき、第三の疑いとして 測定無効 を置きます。公開ベンチを大きく下回る、thinking 差がゼロ、全候補が同じ方向に崩れる——これらはモデル適性の前に、条件証跡を確認する合図です。

よくある落とし穴

• 性能だけ見て「勝ち」と宣言し、品質を後回しにする
• 品質スモーク失敗をすべてモデル責任にする（未起動を見落とす）
• 公開ベンチ未達をそのままモデル弱みと読む（測定事故を見落とす）
• thinking 差なしを能力差なしと読む（フラグ未到達を見落とす）
• 軸を2つ以上同時に変えて、学びを消す
• デモ用の短いプロンプトだけで業務適合を語る
• ハーネス確認値と実機値を同じ表に混ぜる

つまずいたこと

性能だけ見て採用し、翌日の品質スモークで全面赤になる。逆に、品質だけ見て採用し、同時実行で待ち時間が破綻する。どちらも経験しました。

苦労したのは、二軸を並べること自体より、会議で片方の軸だけが拡大される空気を止めることです。きれいな throughput のグラフがあると、JSON 失敗は「あとで直す」になりがちでした。表を二列にしたのは、その誘惑への対抗策です。

この回の要点

• 性能と品質を同じ表の二列で見る
• きれいな throughput だけで品質赤を先送りしない
• どちらか一方の拡大解釈を会議で止める

二軸の並べ方は公開していますが、用途別の合格ラインはまだ未確定です。ハーネス確認値と実機ベンチは混ぜず、匿名化済みの数字から順に足します。

次は「1人の速さだけでは足りない：混雑時の測り方」です。性能列の中身を concurrency 条件つきで読む準備に進みます。