現場実装の クムビーバー です。ローカルLLMの改善は、単発のチューニング大会になりがちです。「昨日より速い気がする」は再現できず資産になりません。
この回の答え
改善は単発チューニングではなく、通し番号前提のループです。測って比べ、次に動かす軸は1つだけ決めます。
この回だけの用語
| 用語 | ひとことで |
|---|---|
| スパイラル | 測る→比べる→次の1軸を決める、の繰り返し改善ループ |
| run_id | 1回の計測に付ける追跡ID。再現の鍵 |
| dry-run | 実起動の前に、生成される定義を確認する |
| 1軸 | 次に変える変数は基本1つ。因果を残すため |
| best_profile | 母集団内の暫定リーダー。stable 昇格は別ゲート |
| known_issues | 分かっている副作用・制約のメモ |
ループの骨格
- 候補モデルを登録する
- 起動プロファイルを作る
- dry-run で起動定義を確認する
- 実起動する
- healthcheck する
- latency / throughput を測る
- 必要なら長文ベンチを足す
- 用途別 eval を回す
- ログとGPUメトリクスを集める
- results に保存する
- 比較レポートを作る
- best_profile を更新する
- known_issues を書く
- 次の設定パターンを作る
- また dry-run へ戻る
ワンコマンドで benchmark → eval → report まで繋ぐ運用もある一方、問題切り分け中は途中停止できる粒度も必要です。全部自動で回すことと、途中で止められることは両立させます。
段階でまとめると
| フェーズ | ステップ | 成果物 |
|---|---|---|
| 準備 | 1〜3 | レジストリ、profile、dry-run 出力 |
| 実行 | 4〜5 | 起動済みサービス、health OK |
| 計測 | 6〜9 | 性能/品質/メトリクス |
| 判断 | 10〜13 | run、レポート、known_issues |
| 次へ | 14〜15 | 次の1軸と新しい dry-run |
「良い」の定義を先に置く
感覚で勝ち負けを決めない、が原則です。比較対象は次を揃えます。
たとえば「TRT-LLM に変えたら速くなった」を言うなら、モデル・context・KV・workload を固定し、runtime だけ変えた run が必要です。軸が2つ動くと、学びが消えて成功談だけが残ります。
1軸の例
- runtime のみ（vLLM / TRT-LLM / SGLang / Atlas のどれか1つだけ変える）
- KV dtype のみ
- max_model_len のみ
- prefix cache ON/OFF のみ
- gpu_memory_utilization のみ
「全部盛りで速くなった」はデモには向きますが、次の障害対応には向きません。
現場で短縮するコツ
- 門番スモークを先に置く
- 失敗の種類を分類する（未起動 / OOM / 出力不正）
- 毎回全部を測らず、仮説に必要な計測だけにする
- レポートの「次に試すべき改善案」を次ループの入力にする
- 長い議論の前に dry-run 差分を見る
- stable を急がず、制約付き testing を許容する
スパイラルは速さより、意思決定が前に進むことが目的です。1日で15ステップを全部回す必要はありません。今日は 3〜5 と 8 だけ、明日は 6 と 11、でも構いません。止まらず、記録が繋がることが重要です。
よくある空転パターン
| パターン | 症状 | 戻し方 |
|---|---|---|
| 軸だらけ | 何が効いたか不明 | 直前の安定 profile に戻し1軸化 |
| 門番スキップ | 重い計測のあとで基礎不足発覚 | smoke を最初に固定 |
| 記録なし勝負 | 口頭の勝ち負けだけ残る | run_id 必須化 |
| 自動実行信仰 | 失敗時に分解できない | ステップ停止ポイントを残す |
| 改善案なしレポート | 次ループが始まらない | 「次の1軸」欄を必須にする |
チェックリスト（1ループ終了時）
- [ ] run_id がある
- [ ] 変えた軸が1つだけ書かれている
- [ ] 性能と品質の要約が並んでいる
- [ ] 失敗分類がある（成功時も「該当なし」でよい）
- [ ] best_profile / known_issues の更新有無が明示されている
- [ ] 次の1軸が次の担当者に渡せる形である
ワンコマンド運用との付き合い方
自動化は便利ですが、スパイラルの敵ではありません。ただし「全部まとめて成功/失敗」だけ見える状態は危険です。社内では、連結実行を使いつつも、次を残しています。
- dry-run だけ止まれる
- health 失敗で評価に進まない
- smoke 失敗で重いベンチをスキップできる
- レポートに「止まったステップ」が残る
つまり自動化は、手作業を消すためではなく、同じ手順を毎回同じ順で踏むために使います。問題が起きたら分解できる粒度がない自動化は、改善ループではなくブラックボックスです。
つまずいたこと
改善を一度に三つ入れると、何が効いたか分からず、ロールバックもできません。分かっていても、期限前になると同時打ちしたくなります。
つまずきは精神論ではなく、1軸変更を強制する記録フォーマットがなかったことでした。スパイラルは綺麗な図より、欲を削る装置です。
この回の要点
- 一度に変える軸は1つ
- 同時打ちした改善はロールバック不能とみなす
- 記録フォーマットで欲を削る
1軸ずつの改善ループは公開の型です。週次で「良くなった」と宣言するための実機数字は、再計測と匿名化が済んだものから足し、合格ラインは用途合意後です。
次は「どの設定が勝つか：7段の優先順位」です。次の1軸を変える前に、効いている設定が見える状態へ戻します。
よくある質問
なぜスパイラルにするのですか？
「昨日より速い気がする」は再現できず資産にならないためです。追跡可能なループにします。
一度に何軸まで触りますか？
基本は次の1軸です。複数を同時に動かすと因果が消えます。
15ステップは全部必須ですか？
骨格は残し、現場では短縮してよいです。省略した手順は記録に残します。
