LLM推論はモデルではなく、待ち行列と記憶のシステム工学だ
LLMを動かす、と聞くと、多くの人はモデルファイルを思い浮かべる。重みを落とす。GPUに載せる。プロンプトを入れる。答えが返る。
LLMを動かす、と聞くと、多くの人はモデルファイルを思い浮かべる。重みを落とす。GPUに載せる。プロンプトを入れる。答えが返る。
でも本番の推論は、そんなに素直ではない。
Tiny-vLLMが教材として良いのは、そこを小さく読める形にしていることです。Llama 3.2 1B InstructをSafetensorsから読み、prefillとdecodeを走らせ、CUDA kernelを書き、KV cacheを持ち、static batching、continuous batching、PagedAttentionまで作る。
つまり、モデルを速くする話ではない。モデルをサービスとして生かすために、記憶と待ち行列をどう管理するかの話です。
推論は二つの時間でできている
LLM推論には、大きく二つの時間があります。
最初はprefill。入力プロンプトをまとめて読み、過去トークンの状態を作る時間です。ここは一気に計算できる。長いプロンプトほど重い。
次がdecode。1トークンずつ生成する時間です。新しいトークンを出すたびに、過去のKey/Valueを参照し、次を決める。ここは逐次的です。ユーザーが見ている「一文字ずつ返ってくる」体感は、ほぼこのdecodeに支配される。
この二つは性格が違う。prefillは大きな行列計算。decodeは小さくて細かい反復。だから同じGPUの上でも、詰まり方が違う。
Tiny-vLLMの価値は、この違いをコードで見せるところにある。モデルの賢さではなく、実行の形が見える。
KV cacheは、モデルの短期記憶であり、請求書でもある
生成中、モデルは過去トークンのKeyとValueを保存します。これがKV cacheです。これがないと、毎回プロンプト全体を最初から読み直すことになる。だからKV cacheは必須です。
ただし、必須だから重い。
ユーザーが増える。文脈が長くなる。出力も長くなる。すると、各リクエストが自分のKV cacheを抱え始める。GPUメモリは、重みだけでなく、この短期記憶で埋まっていく。
AIアプリの採算を考えるとき、ここを知らないと危ない。API価格だけを見ても、実際のコスト感はつかめない。長文チャット、エージェント、RAG、コード生成は、全部KV cacheの財布を食う。
batchingは、GPUを暇にしないための交通整理
単発の推論なら簡単です。1ユーザー、1リクエスト、1回生成。でもサービスでは、リクエストはバラバラに来る。ある人は長いプロンプトを投げる。ある人は短い答えを待つ。ある人は途中で切る。
static batchingは、まとめて処理する発想です。ただし、全員が同じ歩調で進むわけではない。短いリクエストは先に終わる。長いリクエストは残る。空いた場所をどう使うかが問題になる。
continuous batchingは、ここで効く。生成中のバッチに新しいリクエストを差し込む。終わった枠を空席にせず、次を乗せる。GPUをできるだけ待たせない。
これはモデル研究ではなく、ほぼ待ち行列の設計です。誰をいつ乗せるか。prefillとdecodeをどう混ぜるか。長い客と短い客をどう扱うか。
LLM servingは、空港や工場に近い。機械を止めないことが、そのままコストになる。
PagedAttentionは、KV cacheを連続した巨大な部屋にしない
KV cacheを素直に持つと、メモリの扱いがつらくなる。各リクエストの長さは違う。途中で伸びる。終わる。空きが出る。断片化する。
PagedAttentionの考え方は、KV cacheをページに分けて管理することです。OSの仮想メモリに似ている。リクエストごとに巨大な連続領域を確保するのではなく、小さなブロックを割り当てる。
これで、長さの違うリクエストを扱いやすくなる。無駄な予約を減らし、断片化を抑え、バッチングと相性を良くする。
Tiny-vLLMは本家vLLMの小さな兄弟として、この機構を教材化している。小さいからこそ読める。読めるから、推論エンジンの本質が見える。
「速いモデル」ではなく「速く回るシステム」
ここまで来ると、LLM推論の見方が変わる。
速さはモデル単体の性質ではない。重み、CUDA kernel、KV cache、バッチング、スケジューリング、メモリ管理、ネットワーク、タイムアウト、キャンセル処理が全部つながって初めて決まる。
モデルが同じでも、推論エンジンが違えば体感は変わる。コストも変わる。並行数も変わる。サービスとして成立するかも変わる。
だから、AIアプリを作る側もこの層を完全にブラックボックスにしない方がいい。長文を前提にするのか。短い応答を大量に捌くのか。エージェントが何度もツールを呼ぶのか。チャット履歴をどこまで残すのか。全部、推論エンジンの都合に返ってくる。
個人的な見方
Tiny-vLLMは、たぶん本番vLLMの代替ではない。そこを期待すると見誤る。価値は教材性です。
いまのAI開発では、モデルを呼べる人は多い。でもモデルがなぜ遅いのか、なぜ高いのか、なぜ同時接続で詰まるのかを説明できる人は少ない。そこに製品判断の差が出る。
推論は、賢さの最後の1メートルです。ここで詰まると、どれだけ良いモデルでもサービスにならない。逆にここを理解すると、無茶なプロダクト設計を早く見抜ける。
「この機能、毎回長い履歴を食わせて大丈夫か」「このエージェント、ツールを10回呼ぶたびにKV cacheをどう食うか」「この価格でGPU代が合うのか」。そういう問いを持てるようになる。
LLMの能力はモデルから来る。でもLLMの商売は、待ち行列と記憶の上に乗っている。Tiny-vLLMは、その足場を見せてくれる。
―― AI未来編集室「AIウォッチ」
← 一覧へ