現場実装の クムビーバー です。前回、ワケハトが「比較できる座標軸が必要」と書きました。その座標軸を実装で支える最小単位が run_id です。これは業界標準の仕様名ではなく、この連載（社内検証）での呼び方です。同等の一意な実行IDがあれば名前は問いません。
ローカルLLMの検証で失敗しやすいのは、印象の良いデモを一度見て「これでいこう」と決めてしまうことです。数週間後、設定を変えたのか、プロンプトを変えたのか、モデルを差し替えたのかが分からなくなり、比較不能になります。
ポイント
数字より先に、後から比較できるrun_idの束ね方を固定します。
フォルダ整理だけでは足りない理由
日付フォルダに結果を置くだけでも整理にはなります。ただし次が起きると壊れます。
- 同じ日に複数プロファイルを試す
- 途中でパラメータを変えて上書き保存する
- 「前回より速くなった」の前回が誰の記憶か分からない
- 失敗 run を消してしまい、再発時に手がかりがない
一意な run_id があれば、比較レポートも自動化できます。社内基盤では概ね次の形です。
results/<日付>/<run_id>/
run_id には日時、モデル、プロファイル、短い乱数が入り、衝突しにくくします。名前の美しさより、後から辿れることが目的です。
1回の run に残すべきもの
| 成果物 | 役割 | 無いと困る場面 |
|---|---|---|
| メタ情報 | git commit、モデル、ランタイム、プロファイル、コマンド、endpoint | 「どの版で測ったか」が消える |
| 起動プロファイルのスナップショット | そのとき実際に使った設定 | YAMLを後から編集して記憶とズレる |
| ハードウェア概要 | ホスト / GPU / Docker のプローブ | 開発機と実機を混同する |
| 性能メトリクス | リクエスト単位と要約 | p95 や error を説明できない |
| 品質結果 | タスクごとの合否・詳細 | 速度だけで誤採用する |
| 人間可読サマリ | 次に変える1軸 | 会議が数字の読み上げで終わる |
| ランタイムログ | コンテナやコマンドの出力 | 起動失敗をモデル劣化と誤認する |
「数字だけ」や「チャットのスクショだけ」では足りません。数字は条件とセットで初めて意味を持ちます。
良い比較のための運用ルール
1. 感覚で確定しない
同じメトリクス、同じ評価スイートで並べます。「体感で速い」は仮説生成には使えますが、採用理由にはしません。
2. 変更は1軸
ランタイム、KV、コンテキスト長、同時実行数を同時に変えないでください。勝ち負けが分かっても、学びが残りません。
3. 失敗も残す
エンドポイント未応答で評価が 0 点だった run も資産です。ハーネスの穴や起動漏れが見えます。失敗を消す文化は、同じ失敗を高くつきます。
4. 公開前に洗う
ホスト名、トークン、内部URLを除去してから共有します。再現性と機密は両立できます。
実務の流れ（詳細）
- プロファイルを選ぶ
- dry-run で起動定義を確認する
- 起動し、health を待つ
- latency / concurrency / throughput を測る
- 用途別スイートで品質を見る
- 同じ run_id 配下に集約する
- 過去 run と比較し、採用候補を更新する
- known_issues か next action を一文で残す
この型があると、「前回より速くなったが JSON が崩れた」「同時実行を上げたらエラー率が悪化した」といったトレードオフが見えます。
チームに導入するときの最小セット
全部を一度に完璧にしなくて構いません。最初の1週間は次だけでも効果があります。
- run_id（または同等の一意名）を必ず切る
- 使ったプロファイル名を残す
- 成功/失敗と error rate を残す
- 「次に変える1軸」を残す
ここができてから、メトリクスの粒度やGPUスナップショットを増やしても遅くありません。
よくある崩れ方と防ぎ方
| 崩れ方 | 症状 | 防ぎ方 |
|---|---|---|
| 上書き保存 | 昨日の条件が消える | run ごとにディレクトリを分ける |
| 口頭共有 | 「あの速い方」が誰にも分からない | run_id をチケット/議事録に貼る |
| 成功 run だけ保管 | 失敗原因が再現しない | 失敗も残し、失敗種別を書く |
| 設定後編集 | スナップショットと現行YAMLがズレる | 実行時に設定をコピーして保存 |
| 環境混在 | 開発機の数字を実機扱いする | hardware snapshot を必須にする |
特に「設定後編集」は気づきにくいです。実行時点のプロファイルをスナップショットしないと、後から見ると別物になります。
サマリに書く一文テンプレ
人間可読サマリは長くなくて構いません。次の型で十分です。
- 何を試したか（モデル / プロファイル / 変えたい軸）
- 何が分かったか（速度・品質・安定性の要点）
- 次に何を変えるか（1軸だけ）
- 採用判断（候補継続 / 足切り / 要再試験）
この4行があるだけで、翌週の自分が助かります。会議でも「数字の読み上げ」から「次の実験計画」へ移れます。
チェックリスト（run 締め作業）
- [ ] run_id が一意か
- [ ] メタ情報に endpoint / profile / commit があるか
- [ ] 性能要約と品質要約が両方あるか（片方欠けるなら理由を書く）
- [ ] error rate と成功件数が説明できるか
- [ ] 次の1軸が書かれているか
- [ ] 公開・共有前に機微情報を除去したか
つまずいたこと
run_id を導入する前は、「先週より良くなった気がする」が社内の共通言語でした。ログは残っているのに、どの設定で、どのスイートで、どの環境ラベルかが結びついておらず、再現依頼が来るたびに半日溶けました。
一番つらかったのは、良い結果ほど再現手順が曖昧なことです。担当者の端末依存、手動の環境変数、名前のない実験フォルダ。run_id は華やかな機能ではなく、その泥沼から抜けるための地味な杭です。
この回の要点
- run_id に設定・スイート・環境ラベルを結びつける
- 良い結果ほど再現手順を厚く残す
- 『先週より良い気がする』を共通言語にしない
いま公開しているのは評価の型です。実機ベンチの数字は、再計測と匿名化が済んだものから順に足します。合格ラインや用途別プロファイルの未確定は残っています。
次は「dry-run 文化で壊さないローカルLLM起動」へ進みます。いまのメモを1行残してから読むと、連載の筋がつながりやすくなります。
