← 概念辨析に戻る

Concept Contrast Fable

デプロイ入口を管理するものと計算を走らせる推論

先に結論:モデルサービスはモデルのHTTPデプロイ層——ロードバランシング、リクエストキュー、キャッシュ、タイムアウト、リトライ。推論はGPU上で実際にトークンを計算する数学的計算。サービス層のタイムアウトを推論の遅さに帰属させたり、逆にGPUを増設してキュー問題を解決しようとするのは、お金の使い方を間違えている。

モデルサービスはモデルのHTTPデプロイ層——ロードバランシング、リクエストキュー、キャッシュ、タイムアウト、リトライ。推論はGPU上で実際にトークンを計算する数学的計算。サービス層のタイムアウトを推論の遅さに帰属させたり、逆にGPUを増設してキュー問題を解決しようとするのは、お金の使い方を間違えている。

寓話

茶館のカウンター職人と裏方の茶炒り職人では、包丁の入れ方が違う

町の茶館は商売が好調で、客は朝から晩まで座っていた。カウンターの老周は注文受けを担当する。誰が先か、どの茶か、急ぐ客に順路で先に出すか、常連を割り込ませるか。後ろの老趙は茶炒りを担当する。茶葉を鍋に入れ、火加減を秒で計り、翻炒の回数を違えず、茶を出す時間は杯単位まで正確にする。

夏に客が倍になり、茶館は遅くなり始めた。主人はまず老趙に速く炒められるかと尋ねた。老趙は火を最大にし、炒りを速め、出茶量は確かに増えたが、三盞のうち一盞が焦げた——鍋の限界はここではなかった。主人はさらに老趙にもう一口の鍋を加えた。出茶量は二割も増えなかったが、カウンターの老周のところには依然として三十枚の茶牌が誰も受け取らずに積まれていた。

老周こそが本当のボトルネックだった。彼一人で、札を受け取り、順番を並べ、常連客の好みを覚え、返茶や交換をする客の札を列に差し戻さなければならない。茶を炒るのに三十秒、老周は並べ替えに四十秒余計にかけた。鍋を増やしても無駄だった——鍋が増えたとき、老周はどの鍋の茶を出すべきかすら分からなかった。

店主は詳しい人を呼んで見てもらった。その人は一目見て言った。あなたたちは二つのことを一緒くたにしている。茶炒りが遅いのに鍋を足すのは、行列が長すぎるのに窓口の人手を足すようなものだ。茶炒りが遅いのと行列が長すぎるのは二つの独立した問題で、別々に調べて別々に対処すべきだ。

老周には給仕が一人つけられた。給仕は行列の管理、注文の振り分け、返品交換の受け付け、好みの記録だけを専門に担当した。老周は金を受け取り確認するだけに専念した。その日、茶を出す速度は変わらなかったが、客が座ってから茶を飲むまでの時間は四割減った。老趙の鍋は増やさず、火も強くしなかったが、焦げた茶の割合はゼロに戻った。

冬にまた問題が起きた。遅いのではなく、完全に崩壊した——ある客が特別な工程を要する茶を十数杯注文し、老趙は一杯ごとに倍の時間を要した。後ろの数字はすべて狂った。老周のカウンターはきれいだったが、客を一人も受けられなかった——バックエンドが詰まり、カウンターが空なのは詰まりと同じだった。

茶館は最終的に二組の指標を分けて管理した。厨房ではお茶をいれる速さを管理する。一杯のお茶を鍋にかけてから出来上がるまでの時間であり、速さは鍋と火に左右される。接客側ではお茶を届ける速さを管理する。客が注文してから杯が卓に置かれるまでの時間であり、速さは待ち行列と注文の振り分けに左右される。毎週二つの表を確認し、どちらの数値が増えたかに応じて、その側の人員配置を調整する。

その後、店主は竈の後ろにシフト、保温、配膳、苦情記録をさらに追加した。一皿の料理を作れることは始まりに過ぎず、店全体が安定して料理を出せてこそサービスと言える。

モデルサービス

モデルの HTTP デプロイとリクエスト管理層で、負荷分散、リクエストのキューイング、キャッシュ、レート制限、認証、リトライを担当します。注目するのは同時接続数とリクエストのスケジューリングです。

推論

GPUやその他のアクセラレーションハードウェア上で実行される実際の数学的計算プロセスであり、入力tokenをモデルの重みを通して出力tokenに変換します。注目するのはレイテンシ、スループット、VRAM使用率です。

物語の対応

  • カウンターの老周が注文を受け列に並ぶ:モデルサービス層。リクエストのスケジューリングと待ち行列を管理する
  • 裏方の老趙が茶を炒る:推論層、実際の計算作業を実行する
  • 火を強くしすぎて焦げ茶色になった:推論側の単一カードの限界は、圧力を加えるだけでは突破できない
  • 鍋を増やしても老周はどの鍋を火から下ろすかわからない:サービス層のボトルネックは計算リソースの追加では解決できない
  • 給仕を増やして注文を振り分ける:サービス層のスケール——計算能力ではなく並行処理能力を増やす
  • 特殊工程がバックエンドを塞ぐ:推論側の遅延ボトルネックがサービス層を逆に圧し潰す
  • 二つの表、二つの指標体系:サービスと推論には独立した監視と拡張の意思決定が必要

LLM API のパフォーマンス問題の特定に落とし込む

ユーザーから応答が遅いという苦情を受けたら、まずサービスが遅いのか推論が遅いのかを切り分ける。見るべき指標は二つ。リクエストの待ち時間(ゲートウェイ到着から推論開始までの間隔)と初回トークン遅延(推論開始から最初のトークンが返るまでの時間)。待ち時間が長い——ゲートウェイを増強し、レート制限戦略を最適化するか、バッチ処理ロジックを調整する。初回トークン遅延が長い——モデルサイズ、量子化精度、KVキャッシュヒット率、GPU使用率を確認する。よくある金の使い間違い:推論遅延が高いのにAPIゲートウェイのPod数を増やしたり、待ち行列が溜まっているのにGPUをさらに購入したりすること。二つの層の最適化予算は分けて計上し、それぞれROIを見る必要がある。

京ICP备2026014272号