上限の4,096トークンぶんを先に確保すると、86.2%が使われないまま押さえられました。
16トークンずつなら無駄は1.3%です。同じ60GBに入る人数が30人から213人になります。
覚えておく場所を小分けに確保します。上限で押さえる形と比べて、入る人数が7.1倍になりました。
vLLMは、覚えておく場所の扱い方に工夫があります。公式はPagedAttentionによる、注意の鍵と値のメモリの効率的な管理を挙げています。
確保の単位でどれだけ変わるのか。実際に割り当てて数えました。
依頼 20,000件。上限は 4,096トークンだが、実際に使う長さはばらつく
実際に使った合計は 11,336,014トークン（1件あたり平均 567）
覚えておく場所を、何トークンぶんずつ確保するかを変えて、無駄になる量を見る
確保の単位 確保した合計 無駄になった分 無駄の割合 同じメモリで入る人数
4,096トークン 81,920,000 70,583,986 86.2% 30人
1,024トークン 26,132,480 14,796,466 56.6% 94人
256トークン 13,992,448 2,656,434 19.0% 175人
64トークン 11,958,528 622,514 5.2% 205人
16トークン 11,486,464 150,450 1.3% 213人
上限ぶんを先に確保すると、押さえた場所の86.2%が使われません。実際の平均は567トークンだからです。
16トークンずつなら無駄は1.3%です。同じ60GBに入る人数が30人から213人になりました。
※ 「同じメモリで入る人数」は、60GB を1件あたりの確保量で割った値（1トークン 0.5MB として計算）。 ※ 上限ぶんを先に確保すると、短い依頼でも上限ぶんを押さえることになる。
64から16に細かくしても、205人から213人です。効くのは大きい側を潰すところまででした。
細かくするほど管理の手間は増えます。256あたりで大半の無駄は消えています。
細かく確保するほど無駄は減るが、効くのは最初の数段階。
Efficient management of attention key and value memory with PagedAttention原文vLLM 公式ドキュメント「Welcome to vLLM」 この内容の有効期限2027-02-18
入ってきた依頼を続けて詰めます。長さがそろっている場合は、この工夫が効きません。
vLLMは、依頼を続けて詰めます。公式は入ってくる依頼の連続的な詰め合わせ、分割した前処理、接頭辞の使い回しを挙げています。
どれだけ効くのか。詰め方を変えて実際に流して比べました。
依頼 600件・同時に処理できる数 8・1トークン 8ミリ秒 出力の長さ: 85%は40〜200トークン、15%は400〜1000トークン 詰め方 平均の待ち時間 p95 最大 全体の所要 1秒あたり まとめて始めて終わる 151.36秒 260.13秒 272.69秒 326.4秒 1.84件 空いた枠から入れる 34.62秒 60.26秒 66.79秒 120.3秒 4.99件 枠が空いている時間の割合 詰め方 枠が埋まっていた時間 空いていた割合 まとめて始めて終わる 941.1秒 64.0% 空いた枠から入れる 941.1秒 2.2%
平均の待ちが151.36秒から34.62秒になりました。4.4分の1です。
理由は下の表にあります。空いていた割合が64.0%から2.2%に下がりました。
出力の長さがそろっている場合（全員150トークン） 詰め方 平均の待ち時間 全体の所要 まとめて始めて終わる 19.67秒 91.0秒 空いた枠から入れる 19.38秒 91.0秒
全員が同じ長さなら、両者はほぼ同じです。19.67秒と19.38秒で、所要は同じ91.0秒でした。
効くのは長さがばらつく場合です。長い1件が枠を占めたまま、短い依頼が待つ状況を解消しています。
この詰め方そのものの中身は連続バッチングの記事で扱いました。
Continuous batching of incoming requests, chunked prefill, prefix caching原文vLLM 公式ドキュメント「Welcome to vLLM」 この内容の有効期限2027-02-18
速く提供する部品ですが、覚えておく量は文脈の長さに比例します。人数がそのまま減ります。
vLLMは、推論と提供のための部品です。公式はvLLMは、大規模言語モデルの推論と提供のための、速くて使いやすい部品であると述べています。
速さの前に、入るかどうかが決まります。文脈の長さで何人入るのか実際に計算して数えました。
層 32・頭 32・頭あたりの次元 128・16bitで持つ場合
1トークンあたり 512 KB を覚えておく必要がある
文脈の長さ 1人あたり 8人同時 32人同時
1,000トークン 0.49 GB 3.9 GB 15.6 GB
4,000トークン 1.95 GB 15.6 GB 62.5 GB
8,000トークン 3.91 GB 31.3 GB 125.0 GB
32,000トークン 15.63 GB 125.0 GB 500.0 GB
128,000トークン 62.50 GB 500.0 GB 2000.0 GB
80GB のメモリに、重み以外で何人分入るか（重みを 16GB とする）
文脈の長さ 入る人数
1,000トークン 131人
4,000トークン 32人
8,000トークン 16人
32,000トークン 4人
128,000トークン 1人
1,000トークンなら131人入ります。128,000トークンでは1人です。
文脈を128倍にすると、人数は131分の1です。ほぼそのまま反比例しています。
最初の節の無駄と、この節の必要量は同じメモリを取り合います。上限ぶんを先取りする形では、この表の人数にすら届きません。
だから長い文脈を許す設計では、確保の単位が効いてきます。使う長さがばらつくほど、小分けの効果が大きくなります。
3つの計測はいずれも手元で書いた模型で、実際のvLLMを動かしたものではありません。1トークン8ミリ秒、1トークン0.5MBといった値は置いたもので、実機での測定ではありません。使う長さの分布も置いた形で、実際の依頼の分布とは違います。同時に処理できる数を8として固定しており、この値を変えれば詰め方の効き方も変わります。ここで見せているのは、上限ぶんを先に確保すると大半が無駄になるという点と、長さがそろっていれば詰め方の工夫は効かないという点の2つです。
vLLM is a fast and easy-to-use library for LLM inference and serving.原文vLLM 公式ドキュメント「Welcome to vLLM」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る