← 概念辨析に戻る

Concept Contrast Fable

モデルサービスと推論エンジン

先に結論:モデルサービスと推論エンジンは技術スタックの中で非常に近くに位置するが、職責はまったく異なる。推論エンジンはかまどそのものであり——モデルを動かす計算カーネルを担う。モデルサービスは厨房の総管であり——どの伝票をどのかまどで調理するか、いつ薪をくべるか、かまどが足りなければ隣を借りるかを取り仕切る。かまどと総管を一つの役割と見なせば、かまどが管理に引きずられるか、総管が計算の細部に溺れるかのどちらかになる。

モデルサービスと推論エンジンは技術スタックの中で非常に近くに位置するが、職責はまったく異なる。推論エンジンはかまどそのものであり——モデルを動かす計算カーネルを担う。モデルサービスは厨房の総管であり——どの伝票をどのかまどで調理するか、いつ薪をくべるか、かまどが足りなければ隣を借りるかを取り仕切る。かまどと総管を一つの役割と見なせば、かまどが管理に引きずられるか、総管が計算の細部に溺れるかのどちらかになる。

寓話

同じ厨房、かまどと総管の職責

城南の厨房は調理場と客間の二つに分かれている。老銭は調理場を管理し、各かまどの火力の上限、煮込みに向くか炒めに向くか、二時間連続で焚くとどれだけ熱くなるかを知っている。

老周は前堂の配車を管理し、どの注文を先に出すか、どの料理をどの竈に載せるか、竈が足りなければ隣から借りるかを決める。彼は竈を分解せず、薪も研究せず、シフトと納品だけを管理する。

あるチェーン飲食店で味が良くなったり悪くなったりするという苦情がありました。老周はシフトを調べ、どの伝票も時間通りに竈のそばに届いていました。老銭は火力を調べ、どの竈も十分に燃えていました。二人は半日向かい合って座り、ようやく煮込み料理が炒め物用の竈に割り当てられていたことに気づきました。

竈は壊れていないのに、割り当てを間違えた。さらに厄介なのは、ある竈が連続稼働で放熱が悪くなっていたことだ。老周はそれに気づかず、ピーク時にさらに注文を積み増した。料理はエラーを出さなかったが、どんどん生煮えになっていった。

彼らは接続層を作った。厨房は現在の温度、あとどれだけ持つか、どんな料理に適するかを札に掲げ、前堂はその信号に従って注文を振り分ける。厨房はメニュー全体を理解する必要がなく、前堂も調理台を分解する必要がない。

後に厨房は異なるメーカー製の竈を借り入れた。早く熱くなるもの、温度が安定するもの、薪を節約するが起動が遅いものがある。各竈が状態をはっきり伝えれば、前堂は正しく割り当てられる。厨房はついに区別した。一方は火をうまく扱う責任、もう一方は注文をうまく割り振る責任を負い、その間の信号線は一年分の食材ロスに値した。

弟子は後で、なぜ老銭にもシフトを入れさせないのか、老周にも火を任せないのかと尋ねた。老銭は言った。厨房には物理的な限界を理解する者が要り、前堂には注文の約束を理解する者が要る。混ぜてしまうと、かえって誰も集中できなくなる。

彼らが本当に共有しているのは信号である。温度札、シフト表、異常ベル、予備コンロのリストが、2つの役割に互いの境界を理解させる。厨房が大きくなるほど、この境界線の価値は高まる。分けて初めて、コンロを直すべきかシフトを変えるべきかがわかる。 後に新人が入門するとき、老師匠は抽象的な名目を先に語らず、あの失敗を振り返らせた:もともとどこが直感に頼っていたか、最初の修補がなぜ不十分だったか、新しい取り決めがどうリスクを検査可能な位置に留めるか。彼らがこれらの細部を説明でき、いつ沿用し、いつ昇格すべきかも指摘できるようになって、初めてこの方法を本当に理解したと言える。 後に彼らはこの方法を新人の演習にも引き継いだ:まず新人に旧方法で一度やらせ、誤りがどう現れるかを見る。次に新規則でやり直し、どの段階が事前に止められ、どの段階が証拠を残したかを見る。新人が名前を暗記するだけでは、似た場面で誤用する。適用境界、代償、失敗後の補救を説明できて初めて、独立して仕事を任される。

モデルサービス

本番環境におけるモデルの配備、スケジューリング、スケーリング、監視を管理するシステム層であり、推論リクエストを適切な計算リソースにルーティングし、サービスの可用性を保証する。

推論エンジン

実際にモデル推論計算を実行するソフトウェアカーネル。vLLM、TensorRT-LLM、TGI などが該当し、テンソル演算、KV キャッシュ管理、バッチ処理最適化などの低レベル計算タスクを担う。

物語の対応

  • かまど(推論エンジン):モデル計算を実行するカーネル。火加減、バッチ処理、メモリを管理する
  • 総管(モデルサービス):スケジューリングと運用層、シフト、拡縮、ヘルスチェックを管理
  • 煮込み料理を強火炒めの竈に配分:スケジューラがエンジン特性を理解せずリソースを誤配分
  • 放熱効率の低下:エンジンの物理的限界がサービス層に感知されない
  • 接続層:エンジンが温度/負荷シグナルを公開し、サービス層がそれに基づいてスケジューリングを決定する

Andy(任旭)のプロジェクトに落とし込む

推論エンジンを選ぶときは benchmark のスコアだけを見ず、ランタイム状態をモデルサービス層に透過的に渡せるかを見るべきだ——GPU 利用率、バッチ処理キューの深さ、KV キャッシュ圧力。これらの信号が、スケジューラがトラフィック急増時に正しい意思決定をできるかを決める。デプロイ方案には明確に書く:モデルサービスがどのスケジューリング戦略を使い、推論エンジンがどのバージョンでどの指標を公開し、二つのコンポーネント間の信号プロトコルは何か。

京ICP备2026014272号