Llm
- vLLM 最適化の技法: GPU・CPU・メモリ・I/O の律速を測定から切り分ける
vLLM の推論が遅いとき、何を測り、どの比較で原因を確定するか。同期 D2H、PP の受信順序、小さい GEMV、pinned RAM、コールドな mmap 読み出しの実測を使い、TTFT・ITL・throughput から GPU・CPU・メモリ・I/O の律速を切り分ける手順を説明する。
- 125B MoE を 32GB 2 枚で運用する vLLM 最適化編
RTX 5090 を 2 枚持つ利用者から、Qwen3.8-Flash-Next を 32 GB 2 枚で動かせるかと質問を受けた。重み 62.3 GiB は 2 枚に収まらないため、使用頻度の低い routed expert を 1 枚あたり 3 GiB ホスト RAM に置く。expert の選び方、VRAM とホスト RAM にまたがる 1 本の expert テーブル、実行時の expert の入れ替えにより、decode は退避なしの 97.7 tok/s に対して 91.5 tok/s になった (RTX 3090 での計測)。
- FP8 / NVFP4 の weight-only 推論で RTX 3090 が失っているものは無い
FP8 / FP4 のテンソルコアが使われるのは、アクティベーションも FP8 / FP4 に量子化したときだけである。weight-only (A16) では、RTX 3090 も Blackwell も BF16 のテンソルコアで計算する。vLLM のコード、5090 用にビルドされた SASS、3090 での実測 (カーネル時間・クロック固定・Nsight Compute) で根拠を示し、3090 が実際に失っているもの (W8A8 / W4A4 の prefill の演算上限) と、想定される反論への回答をまとめる。
- 125B MoE を 3090 3 枚で運用する vLLM 最適化編
前回 80 tok/s で動作した Qwen3.8-Flash-Next を実運用に入れたところ、初回の TTFT が 100 秒、prefix caching を有効にすると KV 容量が 3 割減少、本番構成の decode は 60〜70 tok/s だった。1 並列 95-99 tok/s、4 並列 243 tok/s、画像入力、MTP 対応までに追加したパッチ 11 本の内容と、試して採用しなかった案をまとめる
- 125B MoE を 3090 3 枚で運用する vLLM編
51.2B の n-gram テーブルを抱えた 125B-A6B MoE を、RTX 3090 3 枚で 262,144 コンテキスト・80 tok/s で運用する。KV キャッシュの大半はホスト RAM に置ける。ストックの vLLM ではそもそも起動しないので、その壊れている箇所を全部書く
- vLLM は INT5〜7 を動かせる
vLLM は INT5/6/7 の重みをネイティブに実行できる。この強さと、 embed_tokens / lm_head を 量子化してもロスが少ない結果を解説する。
- Qwen3.8-flash-Nextを 3090 x3で 314 万コンテキストで使う
Qwen Sparse Attention は、文脈がどれだけ長くても1ステップで読むトークン数が変わらない。このおかげで、KVキャッシュはホストRAMに置ける。同じGPU 3枚のまま上限が 23.4 万から 314 万トークンになった。