検証ラボの メトリフクロウ です。評価レポートを厚くする前に、まず比較の前提を揃えます。モデル名の議論だけで終わる会議を、少しだけ前に進めたい回です。
モデル名だけでは決まらない
「どのモデルを使うか」の会議で、実はもう一つ大きなレバーがあります。それが 推論エンジン（inference engine / runtime） です。同じ重みを載せても、起動の仕方・バッチの組み方・KVキャッシュの扱いが違えば、待ち時間も同時利用者数も変わります。
ローカルLLM導入で最初に起きる迷子は、だいたい次のどちらかです。
- モデル比較表ばかり見て、エンジンと設定を固定していない
- 逆に、エンジンのオプションを触りすぎて、何が効いたか分からない
この回は、評価レポートを読む前に必要な エンジンの地図 を渡します。勝ち負けの tok/s は出しません。次の量子化回へ進む前に、「比較対象が何か」「何を固定して比べるか」だけ揃えます。
推論エンジンが担う仕事
推論エンジンは、ざっくり次を担います。
- リクエストを受け、プロンプトをトークン化する
- GPU上で計算をスケジューリングする（単発〜同時実行）
- KVキャッシュを管理し、生成を進める
- サンプリングし、ストリーム／一括で返す
- OpenAI互換などのAPIとして外部へ出す
モデルが「何を知っているか」だとすれば、エンジンは「どう届けるか」です。
比較対象の推論エンジン（4つ）
社内検証（DGX Spark 前提）で、エンジン同士の比較表に載せる対象は次の4つです。
| エンジン | 特徴 | 向く場面 | 注意点 | 連載での位置 |
|---|---|---|---|---|
| vLLM | 起動プロファイル→コマンド生成が素直。常駐・同時実行のベースラインになりやすい | 反復検証、多ユーザー常駐の試行 | オプション増で条件が溶けやすい | 比較対象。後続で起動解剖へ |
| TensorRT-LLM | 量子化とエンジン焼き込みが前段の build→serve | 用途が固まったあとの最適化 | 準備コスト・版・ハードウェア制約の設計が要る | 比較対象。後続で2段ビルドへ |
| SGLang | serve 中心の別実装。モデル／量子化の公式サポート範囲がはっきりしている | vLLM と並べて decode・集約・tool 経路を見るとき | サポート外モデルでパーサ不一致などが起きやすい。比較前に対応表を確認する | 比較対象 |
| Atlas | Rust + CUDA。DGX Spark（GB10）向けに手が入っている系統 | Spark上で「別エンジン列」を立てるとき | 対応モデル×量子化が限定的。多ユーザー常駐と単発低遅延で向きが分かれやすい。ベンダー発表の速さは使わない | 比較対象 |
ポイント
「どれが最強か」ではなく、同じ試合規則で並べられるかで選びます。4列のうちどれを深掘りするかは用途次第で、連載後半はまず vLLM / TRT-LLM の型を厚くします。
比較表に載せないもの（理由つき）
名前が有名でも、この連載の エンジン横比較 には載せないものがあります。「劣っているから」ではなく、試合の前提が違う／いま測る軸が違うからです。
| 名前 | 比較表に載せない理由 |
|---|---|
| Ollama | 個人利用・手軽さ向き。多ユーザー常駐の docker-compose 運用を前提にした横比較には載せない |
| NVIDIA NIM | 導入容易性と引き換えに柔軟性が下がる系統。当面の4列（オープンな serve / build→serve）とは判断軸が違う。別PoCの余地はあっても、いまの比較表には入れない |
| llama.cpp | 端末寄り・軽量系統。同じ常駐・同時実行の試合規則で並べる主対象ではない |
会議で「あのエンジンは？」と出たときは、勝ち負けを論じる前に 「同じ列に載せる試合か」 を確認します。前提が違えば、速さの数字を並べても意思決定に使えません。
パターンで見ると
| パターン | 含まれるエンジン | 意思決定で見るもの |
|---|---|---|
| serve中心 | vLLM、SGLang、Atlas | 起動再現性、同時実行、cold start、パーサ対応 |
| build→serve | TRT-LLM | ビルド時間・成果物管理・版固定・ハード制約 |
用語の最小セット
| 用語 | ひとことで |
|---|---|
| prefill | 入力を読んでKVを作る段階 |
| decode | トークンを1つずつ（またはまとめて）出す段階 |
| batching | 複数リクエストをまとめて流す |
| KV cache | 生成途中の文脈を保持するメモリ |
この語彙がないと、後の性能表が「速い/遅い」の感想になります。
チェックリスト（エンジン比較の前）
- [ ] 比較対象は vLLM / TRT-LLM / SGLang / Atlas のどれか
- [ ] 比較対象のモデル系列は同じか（エンジンのサポート表に載る組み合わせか）
- [ ] workload（concurrency / max tokens）は同じか
- [ ] 環境ラベル（harness-check / real-gpu）は付いているか
- [ ] 準備時間（ビルド有無・cold start）を意思決定に含めるか決めたか
- [ ] 品質スイート版が同じか
現場で効く比較のコツ
エンジン比較で転びやすいのは、モデルも量子化もcontextも同時に変えてしまうことです。地図の使い方はシンプルです。
- モデル系列を固定する
- ワークロード（同時実行・出力長）を固定する
- エンジン（または起動プロファイル）だけ変える
- 性能と品質を同じ
run_idに残す
TRT-LLM は「ビルド成果物がある世界」、vLLM / SGLang は「起動引数で立ち上がる世界」、Atlas は「対応ターゲットが絞られた専用エンジンの世界」です。準備時間や対応範囲を無視した tok/s 比較は、導入判断として不完全です。
ポイント
エンジン比較の本体は速度自慢ではなく、同じ試合規則で並べられることです。
「速いモデルにしたい」と言われたとき
会議でよく起きるすれ違いは、次です。
| 話し手 | 頭の中 | 起きがちなこと |
|---|---|---|
| 事業側 | モデルを変えれば体感が上がる | モデル名の比較表だけが増える |
| 検証側 | 速さの原因はエンジンや負荷条件にもある | 条件が違う数字を並べてしまう |
伝えたいのは「モデル比較をやめろ」ではなく、速さの原因を切り分ける列を先に決めることです。
会議の冒頭で固定するのは、この3つだけで足ります。
- モデル系列（同じ系統同士で比べるか）
- エンジン（上表の4つのどれを並べるか）
- workload（同時実行・出力長）
この3つが揃う前に「どれが速いか」を決めると、あとから資料を作り直すことになります。逆に揃えておけば、後続のレポートは同じ列に数字を足すだけで読めます。
つまずいたこと
モデル比較の資料を三枚作ったあとで、「エンジンが違う」と判明して全部作り直したことがあります。恥ずかしさと同時に、会議時間を溶かした申し訳なさがありました。
つまずきの本質は知識不足より、比較表の列にエンジンがなかったことです。地図がないと、オプションの話が信仰論争になります。
この回の要点
- エンジン比較の対象は vLLM / TRT-LLM / SGLang / Atlas
- 載せないものにも理由がある（前提が違う／測る軸が違う）
- モデル固定・workload固定でエンジンだけ変える
- 準備コスト（ビルド有無・対応範囲）を判断に含める
いま公開しているのは評価の型です。実機ベンチの数字は、再計測と匿名化が済んだものから順に足します。合格ラインや用途別プロファイルの未確定は残っています。
次は「量子化をレイヤで見る：重み / 計算 / KVの比較地図」へ進みます。いまのメモを1行残してから読むと、連載の筋がつながりやすくなります。
