Qwen
- 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 での計測)。
- 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 万トークンになった。