vllm-project

Love seeing what the community builds on vLLM-Omni 🤩 OpenDirector: a local short-film workspace — generate, edit, export — powered by vLLM-Omni with a wide range of models. Congrats @hsliuunc! 🎬 🎥 OpenDirector: ThinkFlowLab/OpenDirector ⚡ vLLM-Omni: vllm-project/vllm-omni

D3-edgeでLLMを自動選択してみた：vLLM Semantic RouterをAWSで検証 背景 LLMをサービスで利用する際、すべての質問に大きなモデルを使う必要があるのか？ という疑問がある。 例えば、「Pythonとは何ですか？」という質問には比較的小さなモデルでも対応できそうだ。一方、「KubernetesのマルチAZ構成を設計し、障害復旧とコストのトレードオフを説明して」といった質問では、複数の条件を整理する必要があり、より大きなモデルを使いたい。 大きなモデルを常に使う構成は単純だが、推論リソースを必要以上に消費する可能性がある。そこで、質問の内容を見て適切なモデルへ振り分ける「LLMルーティング」を試した。 使用したのは、vLLM Semantic Router と、モデル選択に使える D3-edge だ。Semantic Routerがリクエストを受け、D3-edgeが「4Bと8Bのどちらで回答するべきか」を判断する。 以前は質問の複雑さをルールで判定する Complexity方式 も試したが、12問中1問を期待と異なるモデルへ振り分けた。今回は、ルールによる複雑さ判定から、D3-edgeによるモデル選択へ切り替えて検証した。 このブログの目的 確認したかったことは、次の4点だ。 自動選択： 簡単な質問を4B、複雑な質問を8Bへ振り分けられるか。 実際の動作： D3-edgeがGPU上で判断し、Semantic Routerが選択先へリクエストを転送できるか。 性能への影響： 4B固定・8B固定と比べ、応答時間やGPU使用率はどう変わるか。 回答品質： 小さいモデルを使い分けても、回答に必要な内容が含まれるか。 今回は単一GPU上での小規模なPoCであり、商用環境の負荷試験やAWS料金の削減実証ではない。 このブログの結論 D3-edgeによるモデル振り分けは、用意した12問×3回の計36件すべてで期待どおりに動作した。 また、同じEC2インスタンス上で比較したところ、8B固定よりD3-edge方式の平均応答時間が約4.3%短かった。 主な結果 実測値 D3-edgeの振り分け一致率 100%（36/36件） 8B固定の平均応答時間 11.69秒 D3-edge方式の平均応答時間 11.19秒（約4.3%短縮） 出力上限による打ち切り 0件（全3方式・108件） 簡易キーワード条件の合格率 8B固定・D3-edgeともに91.7% ただし、4Bより8Bの方が必ず正確、あるいはD3-edgeでGPUコストを削減できた、とまでは言えない。回答品質は簡易評価であり、GPU上には3モデルを常駐させているためだ。この点も含めて、以下で検証方法と根拠を整理する。 その結論を得た方法 1. AWS上に3モデルを配置 検証には、AWS EC2のg6e.2xlarge（8 vCPU、64GiB RAM、NVIDIA L40S GPU×1）を利用した。4Bと8BはそれぞれvLLMでAPIとして起動し、D3-edgeはSemantic Router側から利用する構成だ。 ここで重要なのは、D3-edgeは回答文を生成しないことだ。役割は、質問と候補モデルの説明を入力として、どちらのモデルに回答させるかを選ぶこと。実際の文章生成はQwen3 4B-AWQまたは8B-AWQが担当する。 コンポーネント 役割 vLLM Semantic Router リクエスト受付、モデル選択処理の呼び出し、転送 D3-edge 質問の内容から4B・8Bの候補を評価 Qwen3 4B-AWQ 簡単な質問を担当する小型の生成モデル Qwen3 8B-AWQ 複雑な質問を担当する大型の生成モデル 2. Semantic Routerの設定 モデル選択にはdecisionアルゴリズムを使用した。設定の重要部分を抜粋する。 config.yaml の routing.decisions 内を抜粋 - name: d3-select-model priority: 100 rules: operator: AND conditions: [] # すべてのリクエストを選択対象にする modelRefs: - model: qwen3-8b # D3-edgeが失敗した場合の先頭候補 use_reasoning: false - model: qwen3-4b use_reasoning: false algorithm: type: decision decision: deployment: d3-edge instructions: >- Choose the small model for simple requests and the larger model for complex reasoning or system design. candidates: qwen3-4b: Simple factual questions and short explanations. qwen3-8b: Multi-step reasoning, comparisons and system design. timeout_ms: 3000 conditions: []で全質問をこのルールへ通し、その先をD3-edgeが選ぶ。候補の説明文によって「どんな質問をどちらに任せたいか」を伝えている。実際の構成では、別途global.model_catalogにvllm-sr/d3-edgeを登録し、device: cuda:0で起動した。 なお、この例ではD3-edgeに問題が生じた場合に備え、先頭のqwen3-8bをフォールバック候補としている。 3. 比較条件をそろえてベンチマーク 質問を「簡単な6問」と「複雑な6問」に分け、次の3方式で比較した。 4B固定： すべての質問を直接4Bへ送る。 8B固定： すべての質問を直接8Bへ送る。 D3-edge方式： Semantic Routerに送信し、選ばれたモデルで回答する。 例えば簡単な質問は「Pythonとは？」「HTTP 404とは？」「CSVとは？」、複雑な質問は「RAG基盤の高可用性設計」「KubernetesのマルチAZ設計」「Prefill/DecodeとKV Cacheのトレードオフ」などだ。 各方式で12問を3回ずつ実行し、計108リクエストを測定した。比較条件は以下のとおり。 条件 設定 評価件数 12問 × 3方式 × 3回 = 108件 温度 temperature: 0.0 Thinking 無効化 出力上限 各質問・各方式で共通の1,024トークン 実行方法 ストリーミング、逐次実行（同時リクエストなし） GPU監視 0.2秒間隔で取得 最初の測定では、出力上限512トークンのため36件中24件が打ち切りになっていた。そこで事前に必要な出力長を確認し、上限を1,024トークンにそろえた。再測定では全108件がfinish_reason=stopとなり、上限による打ち切りは解消された。 根拠内容 1. D3-edge自身が4B・8Bを選択している まず、D3-edgeの/v1/systemone APIを直接呼び、モデル選択結果を確認した。 質問 選択モデル 選択したモデルの確率 「Pythonとは何ですか？」 4B 98.25% 「Kubernetesの高可用性設計を比較して」 8B 95.53% 「選択したモデルの確率」は、そのモデルが正答する確率ではなく、D3-edgeが候補を支持する度合いだ。 複雑な質問の応答にはaccelerator: cuda、device: cuda:0、dtype: bfloat16が含まれており、GPU上での実行も確認できた。このときのD3-edgeの計算時間は28.47msだった（1リクエストの値）。 さらに、Semantic Routerの実際のAPI応答ヘッダーでも、以下を確認した。 X-Vsr-Selected-Algorithm: decision X-Vsr-Selected-Decision: d3-select-model X-Vsr-Selected-Model: qwen3-8b X-Vsr-Routing-Latency-Ms: 29.157 これにより、D3-edgeの選択機能だけでなく、Router経由で8Bへ転送するところまで動作確認できた。 2. 3方式の比較結果 最終的な108件の測定結果がこちら。 指標 4B固定 8B固定 D3-edge方式 平均E2E（応答完了まで） 6.75秒 11.69秒 11.19秒 平均TTFT（最初のトークンまで） 66.9ms 66.9ms 67.7ms 平均TPOT（生成1トークン当たり） 30.07ms 30.15ms 30.10ms 平均出力トークン数 220.7 383.3 366.9 キーワード条件の合格率 83.3% 91.7% 91.7% 平均GPU使用率 19.5% 28.9% 24.4% 出力打ち切り 0/36 0/36 0/36 E2Eはリクエストから回答完了までの時間、TTFTは最初のトークンが届くまでの時間、TPOTはその後の1トークン生成にかかる時間を指す。 D3-edge方式は8B固定より平均約0.50秒短かった。一方、4B固定の方が平均応答は速い。これはルーティングが常に最速のモデルを選ぶ仕組みではないためだ。今回は「簡単なら4B、複雑なら8B」という方針で選んでいる。 3. どこで時間が短縮されたのか 質問の種類別に見ると、違いがわかりやすい。 質問の種類 4B固定 8B固定 D3-edge方式 簡単な質問（6問） 3.65秒 4.64秒 3.66秒 複雑な質問（6問） 9.85秒 18.73秒 18.72秒 D3-edge方式は簡単な質問では4Bと、複雑な質問では8Bとほぼ同じ時間になっている。つまり、必要に応じて生成モデルを切り替えた結果だ。 また、3方式のTPOTは約30msで大差がなかった。8B固定よりD3-edge方式の平均出力トークン数が少なかったこと（383.3 → 366.9）も、E2E短縮の一因と考えられる。 ただし、「簡単な質問なら4Bが必ず速い」というわけでもない。HTTP 404の説明では、4Bが長めの回答を生成したため、8Bの方が短時間で終了した。モデルサイズだけでなく、生成する文章の長さも速度に影響することがわかった。 4. 評価時に注意したい2つの点 ① 「品質91.7%」は回答正解率ではない 今回の品質指標は、回答に必要なキーワードが含まれるかを調べた簡易判定だ。同じ意味でも別の言い方をすると不合格になることがある。実際の正確性、設計の妥当性、説明の十分さを比較するには、人手または独立した評価モデルによる採点が必要だ。 ② Routerの約0.63msは、キャッシュの影響が考えられる 最終ベンチマークで記録されたRouter内部の平均ルーティング時間は約0.63msだった。一方、前述のD3-edge単体のGPU計算時間は約28.47ms。今回のように同じ質問を繰り返す場合、モデル選択結果がキャッシュされていた可能性が高い。 そのため、未見の質問でも毎回0.63msで判断できるとは言えない。実際のルーティングコストを評価するには、キャッシュを無効化した測定も必要になる。 5. GPU使用率は下がったが、AWS料金削減とは別 平均GPU使用率は、8B固定の28.9%からD3-edge方式の24.4%に低下した。また、概算GPUエネルギーも8B固定より約6.3%小さかった。 ただし、今回の構成では4B・8B・D3-edgeの3モデルを同じL40S上に常駐させている。実測のGPUメモリ使用ピークも3方式で同じ約34.3GiBだった。 したがって、GPU使用率や消費電力量の改善が、そのままEC2の利用料金削減につながるわけではない。クラウド費用を下げるには、同じ品質・負荷をより安価なGPU構成でさばけるか、あるいは必要なGPU台数を減らせるかまで確認する必要がある。 今回のPoCで確認できたのは、「質問に応じて生成モデルを自動選択する」仕組みの実現可能性だ。今後は、未見の質問による精度評価、キャッシュなしでのD3-edge推論時間、人手による回答品質評価、同時アクセス時のスループット比較を進めたい。 参考： vLLM Semantic Router（GitHub） ／ Decision選択アルゴリズムの公式ドキュメント

Qrita: High-performance Top-k and Top-p Algorithm for GPUs using Pivot-based Truncation and Selection Despite their importance in model sampling, efficient implementation of Top-k and Top-p algorithms poses a significant challenge as model vocabularies grow with every new model release. Existing approaches often rely on sorting, which incurs significant computation and memory overhead on GPUs, or on stochastic approaches that alter the algorithm's output. In this work, we propose Qrita, an efficient Top-k and Top-p algorithm based on a pivot-based truncation and selection. Qrita leverages pivot-based search for both Top-k and Top-p with two key techniques: 1. Gaussian-based $\sigma$-truncation, which greatly reduces the search space of the vocabulary, and 2. Quaternary pivot search with duplication handling, which halves the number of pivot search iterations and guarantees deterministic output. We implement Qrita using Triton and evaluate its performance against the Top-k and Top-p kernels of high-performance LLM execution engines such as SGLang and FlashInfer, improving end-to-end serving throughput up to 1.4$\times$ with half the memory usage, while providing the same output of stable sort-based Top-k and Top-p algorithms. Qrita is now the default Triton Top-k and Top-p sampler of vLLM, and its implementation is available at github.com/vllm-project/vllm/blob/main/vllm/v1/sa….

Anthropic's FlashProve Proves Which Model Answered You, at 70-95x vLLM's GPU Time - Book: Observability for LLM Applications - Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go - My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools - Me: xgabriel.com | GitHub --- You pay a router for a big model. A good answer comes back. Was it the model you paid for? Anthropic's Frontier Red Team says the answer itself can't tell you: "Judging from the model's output alone is unreliable, even if it produces high-quality responses." On November 2, the team published FlashProve, an open-source research prototype that produces a cryptographic proof that a reply came from one specific, committed set of model weights. The verifier never sees the weights. The post names the case it has in mind: a model "secretly substituted in by a routing service for cost reasons." It works, on one model, at a steep price. What FlashProve actually proves The README describes three steps. The provider publishes a commitment ID bound to one set of weights. For each reply, the provider's GPU produces a proof that the reply is that committed model's output. Anyone can then check the proof on an ordinary CPU with a tool called cp_verify, without the weights. The demo model is Llama 4 Maverick, a 400B-parameter mixture-of-experts model with about 17B parameters active per token, using public 4-bit weights. The authors are Roy Rinberg and Alex Allain at Anthropic, with collaborators from EPFL, MIT, StarkWare and Succinct. The README states the soundness bound: a cheating provider gets caught except with probability about q/2^124 + 2^-101 after q hash queries, a property the team proved in Lean 4. The post is careful about what that covers. The C++ verifier you'd use day to day carries no formal guarantee, though it agreed with the Lean verifier on every proof in their tests, and "we do not guarantee that all three (Lean, paper, code) match each other." !Flat vector illustration of a sealed reply envelope with a burnt-orange wax seal whose pattern matches a fingerprint on a locked vault of model weights, while a magnifying glass inspects the seal The provider commits to its weights once. Each reply then carries a proof that anyone can check without opening the vault. The price: GPU time, RAM and a short window The numbers are better than earlier attempts and still far from production. - Throughput: about 110 tokens per second on one H100. The team measured a batch of 24 requests taking about 223 seconds. - Overhead: about 72x the GPU time of vLLM serving the same 24 requests (66 to 77x across runs), and about 94x at vLLM's highest tested load. The vLLM baseline used FP8 weights on eight H100s. - Window: "Each verifier request is a window of 1,024 tokens, and each proof checks one token." The authors call 1,024 tokens "quite short" next to chat contexts. - Proof size: about 18.78 MB per proof. The client also downloads about 6.5 MB of commitment data once. - Verification: about 17 seconds on 24 CPU threads, or 21 seconds on one thread, including the offline checks. - Commitment: about 39 minutes, once per model, good for about 16 million requests before the provider recommits. Read the window bullet carefully. The 110 tokens per second works out to 24 requests of 1,024 tokens in 223 seconds, yet each proof checks one token of its window. A proof does not cover every token of the reply. For scale, the post cites VerInf, earlier work on the same model, at about 0.02 tokens per second. AlphaSignal notes that comparison mixes hardware and settings, so treat it as a rough gap, not a controlled benchmark. The hardware bar is high on the proving side. The README asks for one dedicated NVIDIA H100 80 GB, CUDA 13.2 Update 2, and gcc 13. The full Maverick route downloads a 232 GB 4-bit conversion and needs 330 GB of RAM and 245 GB of disk. What it can't do yet The post lists the limits plainly. Three matter if you were hoping to point this at your API bill. It proves greedy decoding of an integer model. In the authors' words: "A reply from a floating-point implementation, or sampled decoding, could depart at some position and no longer exactly match the computation proved." If your calls sample with a temperature above zero, they aren't covered. The architecture isn't hidden. The weights stay secret, but the system assumes an MoE architecture and exposes it. The authors note that an architecture's description "may contain intellectual-property the model provider would like to keep secret." Timing side channels "could potentially reveal information about the weights," and are out of scope. It isn't behind Claude. The post doesn't say FlashProve runs in Claude or the Claude API, and the demo is Llama 4 Maverick. It says a related Anthropic roadmap goal was met by a different project that signs inference traffic and recomputes inference on a trusted server. FlashProve "pursues the same objective by a different method." The repo is version 0.16.0 under Apache 2.0, and it's labelled "not maintained, not accepting contributions." The authors say why they shipped it anyway: "We are sharing this explicitly with the goal that others look at what we have done, take it, and improve it." Check a stored proof on a Linux box You don't need an H100 to see the verifier work. The README's first route builds cp_verify and checks an example proof on Linux with bash and g++ 13 or newer, in under 2 GB of RAM. It lists the build at 1 to 2 minutes and the check at under 2 seconds. git clone https://github.com/anthropics/FlashProve cd FlashProve verifier/build.sh E=examples/accepted-proof bin/cp_verify "$E/config" "$E/ivk" \ "$E/example.req" "$E/example.y" \ "$E/example.proof" -id "$(cat "$E/ID.txt")" Per the README, success is a last line of YES and exit code 0. Rejection is exit code 1 with NO: <name>. The example uses synthetic weights, so it shows the verifier works, not that a real model answered. I haven't run it myself. The README adds one rule for anyone building on this. Get the commitment ID "from a party your user trusts, never from the server being checked or from files sent with the proof." A proof against a commitment the router hands you proves nothing about the router. !Flat vector illustration of a switchboard operator silhouette quietly swapping a large orange gem for a small grey pebble on a conveyor, with a magnifying glass hovering over the swap The case FlashProve targets: a router serving a cheaper model than the one on the invoice. What you can do about model swaps today FlashProve is research. Your router invoice is due this month. Two things help now, and neither is proof. Narrow who can serve the request. If you route through OpenRouter, its provider selection docs let you list providers, turn off fallbacks, and filter by quantization for open-weight models: "provider": { "order": ["deepinfra"], "allow_fallbacks": false, "quantizations": ["fp8"] } The docs say that to guarantee only the top-ranked provider serves a request, "you can disable fallbacks." They also warn that "Quantized models may exhibit degraded performance for certain prompts," which is the quieter version of a model swap. Watch quality like a metric. Run a fixed set of prompts with known-good answers on a schedule, and alert when scores drift. Anthropic's point stands: output alone is an unreliable way to identify a model. A drop in eval scores still tells you something changed upstream, whether that was a swap, a new quantization, or a silent model update. Would you pay a premium per token for a proof that the model on the invoice wrote the answer? Or is provider pinning enough for your workload? --- If this was useful I build Hermes IDE, so weigh this with that in mind: it's a free, source-available desktop app for macOS, Windows and Linux that runs Claude Code, Codex and other agents side by side, each on its own branch. Download it or star it on GitHub. Until proofs like FlashProve's reach real APIs, your traces and evals are how you notice that the model behind an endpoint changed. Observability for LLM Applications covers that side: tracing LLM calls, running evals as regression tests, and catching cost and quality drift in production. If the eval-as-canary idea above is the part you'd act on, the book walks through building it. 

Anthropic売上170億ドル、支出の約束は約8,950億ドル 2026年11月3日（火）のAIニュース完全解説版。図解を見れば本文を読まなくても分かる形にしています。 今日いちばん驚いたのは、Anthropicの数字なんですよ。3か月の売上が約170億ドルなのに、約束した支出は約8,950億ドル。しかも、自分を育てるAIに「とても近い」という報道まで出ました。他にも、新聞社がブラウザの会社を訴えた話、マインクラフトでAIチームがつまずいた実験、公開AIの話まで。経営者も個人も、自分の仕事に置き換えて読んでみてください。 1. 売上170億ドル、支出の約束は約8,950億ドル 図解（完全解説版） 先に結論を言います。Anthropicの稼ぐ力はとんでもない。でも、それ以上にとんでもないのが、先に約束した支出なんですよ。 CNBCが、Anthropicの改訂S-1を報じました。S-1っていうのは、アメリカで上場するときに出す届出書類のことです。第3四半期の売上はおよそ170億ドルで、前の年の同じ時期から約1,127%増。ところが、購入や借り受けで約束した支出は約8,950億ドルなんです。しかも、そのほぼ全部が計算資源と設備。つまり、AIを動かす力の仕入れです。 3か月の売上の50倍以上ですよ。飲食店で言えば、お客さんが増え続けると信じて、巨大な厨房を先に押さえたお店じゃないですか。ただし、四半期ごとの売上の伸びは144%から47%に落ち着いてきました。これでも十分すごい数字ですけど、上場後は、この賭けを回収できるかを投資家が見ていくことになります。 売上の大きさと、約束の大きさは、セットで見てください。経営者の皆さんは、AIが本気の投資対象だと知ったうえで、料金や使える量はまだ動くものだと思って計画を立ててください。個人で学んでる人は、AI企業のニュースを見るときに「いくら稼いだか」だけじゃなく、「いくら使うと約束したか」まで見る癖をつけましょう。僕も毎朝ニュースを読むとき、ここを見るようにしてます。短期の派手な数字より、長期で回収できるかのほうが大事なんです。 出典: cnbc.com 2. Anthropic、自分を育てるAIに「とても近い」 図解（完全解説版） ちょっと怖い話からいきますね。AIが、自分で自分を育てられるようになる。その地点にとても近いと、Anthropicが警告したってTechCrunchが報じてるんです。 この地点を、RSIって呼びます。AIが自分を訓練するのがうまくなりすぎて、能力の伸びが一気に加速するポイントのことです。AIの破滅を心配する人たちは、これを「もう戻れない大惨事」と見ています。先に正直に言うと、確信度は中です。今回は報道の見出しと要約までの確認で、Anthropicがどんな根拠で言っているのかまでは読めていません。 例えるなら、先生なしで、自分で自分の家庭教師になれる生徒です。一度それができたら、賢くなる速さそのものが変わるじゃないですか。だから注目されてるんです。 じゃあどうするか。僕は20歳のとき甘い投資話に乗って痛い目を見たので、うまい話ほど裏を取るのが体に染みてるんですよ。これ、怖い話でも同じです。「近い」と「来た」は別の話です。経営者の皆さんは、AIの計画を一度決めて終わりにせず、見直す日をこまめに決めておいてください。個人で学んでる人は、煽る見出しだけで判断せず、元の発表まで読む練習をしましょう。短期で怖がるより、長期で変化を追い続ける人のほうが強いですよ。 出典: techcrunch.com 3. NYTなどがBraveを提訴、記事の無断収集の疑い 6コマ漫画（案内役: ゼロ） ここなんですよ。AIの学習に使う記事は、いったい誰のものなのか。この話がまた裁判になりました。 TechCrunchとThe Vergeによると、ニューヨーク・タイムズなどの報道機関が、ウェブブラウザBraveの会社を訴えました。ブラウザっていうのは、ネットを見るためのソフトのことです。指摘されているのは、著作権のある記事を機械で集め、AIの学習に使ったり、Anthropicなどの顧客に配ったりした疑い。有料記事の壁を越えられるようにした疑いもあります。ここで勘違いしないでほしいのは、まだ疑惑の段階だってこと。訴えの相手と報じられているのはBrave側で、Brave側の言い分は今回確認できていません。 例えるなら、塾の有料プリントを集めて、別の場所に配ってたんじゃないかと言われている状態です。ね、作った側からしたら黙っていられないでしょ。 記事や文章は、AI時代の大事な仕入れ品なんです。経営者の皆さんは、自社のブログや事例記事がどう使われているか、AIに資料を作らせるときに元の記事の権利を確かめているか、一度見てみてください。個人で学んでる人は、有料記事を丸ごとAIに貼る前に、ちょっと立ち止まってほしいんですよ。僕は毎朝AIのニュースを自分の仕組みで集めて読んでますけど、どの話にも元の書き手がいるんですよね。短期の手軽さより、長期の信頼です。 出典: techcrunch.com 4. 50体のAIチーム、マイクラで文明づくりに失敗 6コマ漫画（案内役: ゼロ） この話、僕はちょっと笑っちゃったんですよ。AIも、人が増えるとお役所仕事になるらしいんです。 Tom's Hardwareが報じたのは、ゲームのマインクラフトの中で、AIエージェントの群れに文明づくりをさせた実験です。AIエージェントっていうのは、指示すると自分で動いて仕事を進めるAIのこと。ところが50体のチームは、官僚主義に陥って身動きが取れなくなり、失敗したと伝えられています。確信度は中です。今回確認できたのは報道の見出しまでで、実験の細かい条件までは読めていません。 例えるなら、お祭りの準備より、誰が何を決めるかの話し合いに時間がかかってしまう町内会です。ね、心当たりあるでしょ。賢い人が集まっても、進め方が決まっていなければ前に進まないじゃないですか。 数が増えるほど、決め方のほうが大事になります。経営者の皆さんは、AIを増やす前に、誰が決めて、どこまで任せるかをはっきりさせてください。僕の会社でも、AIに任せる範囲と、誰が記録を見るかを先に決めてから任せています。個人で学んでる人は、いきなり何体も動かさず、まず1体に1つの仕事を任せて、うまくいく形を覚えるのがおすすめです。短期で数を増やすより、長期で回る形を作ったほうが、結局は速いんですよ。 出典: tomshardware.com 5. 公開AI「Beam-1.0」、動かす道具が対応 図解（完全解説版） 誤解しないでほしいんですけど、これは「すごいAIが誰でも手軽に使える」って話じゃありません。でも、見ておく価値はあるんですよ。 Reflectionという会社の初の公開モデル、Beam-1.0が、vLLMの新しい版に対応しました。公開モデルっていうのは、中身が公開されていて、自分の環境で動かせるタイプのAIのこと。vLLMは、そのAIを動かすための道具です。GitHubの更新情報には、規模が501Bで、実際に動くのは23Bと書かれています。Bは、AIの大きさを表す単位だと思ってください。確信度は中で、実際の使い心地や、皆さんの仕事で役に立つかまでは確認できていません。 例えるなら、とても大きな図書館なのに、一度に開く本はその一部だけ、という作りです。全部を毎回開かないから、大きさのわりに動かしやすくなる。賢いやり方でしょ。 Reflectionは、太平洋時間の11月3日朝8時から質問会を開くと告知しています。発表より、実際に動くかどうかです。経営者の皆さんは、外に出しにくいデータを扱う業務があるなら、質問会の内容を見て候補に入れるか考えてください。個人で学んでる人は、すぐ動かそうとしなくて大丈夫。「AI本体」と「動かす道具」は別物だと知るだけで、ニュースの見え方が変わります。僕も毎朝のニュースは、ここを分けて読んでます。短期の話題性より、長期で使えるかを見ていきましょう。 出典: github.com/vllm-project/vllm/releases/tag/v0.33.0… まとめ 短期で見れば、AIの派手な数字に目を奪われます。でも長期で効くのは、元の発表を読んで、書き手の権利を大事にして、小さく任せて確かめる癖なんですよ。今日の話を一つ、自分の仕事に置き換えるところから始めましょう。 この記事は、公式ブログ・研究者の発信・掲示板（Hacker News など）・X の一次情報を毎朝集めて、非エンジニアにも分かる形にまとめています。 今日読んだ全件リストは別途保管しています。

vLLM now has PLE disk offload support on nightly

vLLM・SGLang・TensorRT-LLMをクラウドGPUで動かしたら、それぞれの個性が見えてきた この記事で分かること Qwen3-8Bを、L4 24GB 1台の上でvLLM・SGLang・TensorRT-LLMに載せ、同じリクエストを送った。揃えたつもりの条件が、5か所で揃っていなかった。どれもベンチマークの数字に入り込む。 速さの順位は載せない（速さは自分の条件で測ってほしい）。すべてこの版・L4（sm_89）での話である。エンジンを選びたいだけなら「エンジン別の要点」と最後の「私の使い分け」へ。 エンジン別の要点 エンジン 知っておくこと vLLM 0.31.0 L4ではQwen/Qwen3-8B-FP8が重みだけFP8（W8A16）で動く SGLang 0.5.21 ツール定義に項目が足され、入力が増える。L4・8B bf16は--mem-fraction-staticの自動値では起動しない（0.87で動いた） TensorRT-LLM 1.2.1 L4ではQwen/Qwen3-8B-AWQ・-FP8をそのまま読めない。KVが足りないと黙って待たせる。キャッシュを消すAPIが無い 用語 用語 意味 KVキャッシュ 生成中のリクエストが、それまでのトークンの計算結果を置いておくGPUメモリ。容量をトークン数で数え、同時に処理できる本数の上限を決める プリフィル 入力（プロンプト）をまとめて読み込む最初の段階。入力が長いほど重い TTFT Time To First Token。送ってから最初の1トークンが返るまでの時間 W8A16／W8A8 重み（Weight）と計算時の値（Activation）のビット数。W8A16は重みだけ8bitで計算は16bit 追い出し（preemption／retraction） KVが足りなくなったとき、処理中のリクエストをいったん外すこと。後でやり直す RadixAttention SGLangのプレフィックスキャッシュ。木構造で、任意のトークン位置まで一致を使い回す（vLLMは決まった長さのブロック単位） sm_89／Ada／Hopper NVIDIA GPUの世代。L4はAda（sm_89）、H100はHopper（sm_90） ModelOpt NVIDIAの量子化ツール。TensorRT-LLM向けの量子化モデルを作る 条件 項目 値 モデル Qwen3-8B（bf16、AWQ 4bit、FP8） GPU NVIDIA L4 24GB 1台（sm_89、AWS g6.xlarge）。ドライバ 595.112.07、CUDA 13.2 エンジン vLLM 0.31.0 / SGLang 0.5.21 / TensorRT-LLM 1.2.1（trtllm-serve、PyTorchの経路） リクエスト /v1/chat/completions。ツール定義10個（ケースごとに40個から選ぶ）＋日本語の質問。システムプロンプトなし、thinkingオフ、質問の末尾にリクエストごとの識別子 max_tokens／最大の文脈長 512／8,192 測った並行数 AWQ・FP8は1と16。bf16は1（16は載らない：3節）。SGLang bf16は容量の確かめで8も 送ったケース 200ケースのうち20ケースを繰り返し送った（並行数1で80件） プレフィックスキャッシュ 3エンジンとも既定で有効。区切り（エンジン×チェックポイント×並行数×測定の種類）ごとにサーバーを起動し直す エンジン別 vLLM SGLang TensorRT-LLM 入力長 最大／中央値（200ケース） 2,591／2,310 2,691／2,410 2,591／2,310 ツールパーサー hermes qwen（Qwen25Detector） qwen3 バッチの上限 max_num_seqs 256・max_num_batched_tokens 2048 max_running_requests 2048 max_batch_size 2048・max_num_tokens 8192 チャンク化プリフィル 有効 有効（4096） 無効 CUDA graph FULL_AND_PIECEWISE 有効 バッチ1〜32・64・128 バッチの上限はどれも並行数16より大きい。 1. 入力：SGLangだけトークン数に差が出た 同じリクエストでusage.prompt_tokensを比べると、SGLangだけ全ケースで+100トークンだった。 // 送ったもの（{…}は省略） {"type": "function", "function": {"name": "search_master", "description": "…", "parameters": {…}}} // テンプレートに渡るもの {"type": "function", "function": {"description": "…", "name": "search_master", "parameters": {…}, "strict": false}, "defer_loading": null} エンジン toolsの扱い prompt_tokens vLLM 型に通すが、テンプレートに渡す長さは変わらない 送ったまま手元でテンプレートに通した長さと一致 SGLang model_dump()で項目を足し、キーの順が変わる +100 TensorRT-LLM — vLLMと一致 書き換えを再現する関数を書き、1,200件でSGLang自身のmodel_dump()と突き合わせて違いは0件だった。確かめるなら、テンプレート適用後の文字列（vLLMなら/tokenize）の差分を取る。 切り替えるオプションは無い。 揃えるならクライアントから足した形で送る（他エンジンの入力も変わる）。今回はそのまま測った。 効き方：プリフィルが重くなる／KVの見積もりがずれる（3節）／精度にも混ざる。ツールが多いほど差は大きい。パーサーも3つとも別の実装で、読み損ねは精度の差として出る。 2. 量子化：「FP8」が同じ意味ではない エンジン 起動時の警告 vLLM Weight-only FP8 compression will be used leveraging the Marlin kernel. SGLang Using default W8A8 Block FP8 kernel config. Performance might be sub-optimal! 「FP8で比べた」表は、重みだけ8bitと計算も8bitが混ざりうる。起動ログのカーネル名で確かめる。 vLLMがL4でW8A16になるのは、カーネルの候補を順に試し、最初に使えるものを選ぶため（vllm/model_executor/kernels/linear/init.pyのinit_fp8_linear_kernel）。 CUTLASSのブロックFP8のカーネルはsm_90・sm_100・sm_120向けしか無い（csrc/.../c3x/scaled_mm_blockwise_sm*_fp8.cu）。--linear-backendで変えられるはずだが試していない。 TensorRT-LLM 1.2.1・L4では、公開の次の2つを読めなかった。 チェックポイント 読めない理由 代わり（ModelOpt 0.37.0） Qwen/Qwen3-8B-AWQ（AutoAWQ形式） load_hf_quant_configにawqの分岐が無い --qformat int4_awq Qwen/Qwen3-8B-FP8（ブロック単位） 対応表で、ブロック単位FP8はAda（sm_89）が対応外（HopperとBlackwell sm100/103は対応）。モデル側の表でもQwen3は対応外なので、H100でも使えない --qformat fp8 --kv_cache_qformat none 2つで約56分かかった。nvidia/Qwen3-8B-FP8はKVまでFP8になるため使わなかった（KVの型の上書きは試していない）。TensorRT-LLMだけチェックポイントが別物なので、量子化した構成はエンジン間で比べず、各エンジン内でbf16との精度差だけ確かめた。 3. 容量：同じGPUでも載る量が違う 名前の似たメモリ設定が、何に対する割合かが違う（L4は約22.5GiB〔23,034MiB〕、Qwen3-8B bf16の重みは15.27GiB）。 | weights | KV | act | rest | GPU |===============|==============|=========|======| vLLM |<---------------- 0.92 ---------------->| SGLang |<----------- 0.87 ----------->| TRT-LLM |<-------- 0.9 x free --------->| act＝活性化など計算中の作業領域（プリフィルの中間結果、CUDA graph）。rest＝エンジンの外で使われる分の余白。模式図で、長さは比率どおりではない。 エンジン 割合の対象 割合に含むもの 値 KVの容量（トークン） 容量を直接指定するなら vLLM GPU全体 重み＋KV＋活性化 0.92（既定） 30,240 --kv-cache-memory-bytes（指定すると0.92は無視される） SGLang GPU全体 重み＋KV（活性化は外） 0.87（手で決めた） 26,813 --max-total-tokens TensorRT-LLM 重みと活性化を確保した後の空き KVだけ 0.9（既定） 約32,800 kv_cache_config.max_tokens（割合と両方なら小さいほう） 揃えたいなら割合ではなくトークン数で直接指定する（オプション名は版で変わりやすい）。今回は既定に近い状態を測るため揃えていない。 KV 1トークン = 36層 × KVヘッド8 × 128次元 × K/V 2 × 2バイト = 144KiB 1本の最大 = 入力2,691（SGLang） + max_tokens 512 + 余裕1 = 3,204 並行数8 = 3,204 × 8 = 25,632（+100前は 3,104 × 8 = 24,832） 並行数16 ≒ 51,300 → bf16は3エンジンとも載らない 全リクエストが最大長まで伸びても入るかで数え、入らない組み合わせは測っていない。 SGLangは自動値（0.684）で起動しなかった。 自動値＝（GPUの容量−作業領域の見積もり）÷GPUの容量（srt/arg_groups/memory_hook.py）。 作業領域の見積もり（L4） 大きさ 固定の分 512MiB プリフィル chunked_prefill_size 4,096トークン×1.5MiB＝6GiB（係数1.5はソースで「経験的な値」） 並列化の分 128MiB（1GPU） CUDA graph デコードの最大バッチ48×2MiB＋プリフィルの分 合計 約7.1GiB（23,034MiB×(1−0.684)） ValueError: Loaded weights leave no GPU memory for the KV cache under --mem-fraction-static=0.684. 並行数8が載る値を0.01刻みで探した（0.01あたり約1,590トークン）。 割合 KVの容量 並行数8（25,632） KV以外の残り 追い出し 0.684（自動） 起動しない — — — 0.84 22,047 載らない 1.82 GB — 0.86 25,224 載らない 1.40 GB — 0.87 26,813 載る 1.11 GB 0回 +100前なら0.86で足りたが、1節の+100で408トークン足りなくなり0.87にした。0.88以上は試していない。 4. 溢れたとき：追い出すか、黙って待たせるか 方式 エンジン 混んだとき遅れる場所 見える指標 追い出す vLLM・SGLang 生成の途中（ストリーミングが止まる） vllm:num_preemptions／sglang:num_retracted_requests_total 待たせる TensorRT-LLM 最初の1トークン（TTFT） 無い。numActiveRequestsで見る TensorRT-LLMは「入力長＋max_tokens」ぶんを先に確保するので、max_tokensを大きく付けるほど同時に受け入れる本数が減る。並行数16で送っても中では8本しか走っていないことがある。空きに合わせて詰め込むMAX_UTILIZATIONもある（処理中のリクエストが一時停止しうる。試していない）。 今回は/metricsを2秒ごとに読み、numActiveRequestsの最大が送った本数に届いたことを確かめた。溢れる組み合わせは測っていない（3節）。 5. 観測：そのまま読むと誤判定になる エンジン 癖 対処 SGLang キャッシュヒットが0だとprompt_tokens_detailsごと出ない 無ければ0 SGLang num_retracted_requests_totalは初回の追い出しまで出ない ゲージnum_retracted_reqsがあれば0回 TensorRT-LLM kvCacheStatsはenable_iter_perf_statsが要り、1件処理するまで空 短いリクエストを1件送ってから読む TensorRT-LLM その1件で、測定の最初のリクエストがcached_tokens=1になった（<|im_start|>を共有。partial reuseが既定で有効なので、32トークンのブロックの一部でも当たる） 書式を通さない/v1/completionsで送る TensorRT-LLM 反復ごとの統計は読むたびに消える 測定中に2秒ごとに読む 「読めなければ0」にしていたら誤った結論を出していた。「読めなければ止める」作りにしていたので気づけた。 エンジン キャッシュの消し方 vLLM POST /reset_prefix_cache（VLLM_SERVER_DEV_MODE=1） SGLang POST /flush_cache TensorRT-LLM APIなし。再起動 キャッシュがどれだけ効くかは、送るケースの数とKVの容量で大きく変わる。今回は20ケース（入力の合計45,957トークン）を繰り返し送った。 チェックポイント KVの容量（トークン） 20ケースぶんが cached_tokens／入力（3エンジンとも同程度） bf16 26,813〜32,800 収まらず、一周する前に追い出される 3.6〜4.7%（当たるのは先頭の書式 約50トークンだけ） AWQ・FP8 76,096〜99,552 収まり、2周目からツール定義ごと当たる 並行数1で約75%、16で約82% 効いているのは並行数ではなく、量子化で空いたKVの容量である。量子化した構成の速さには、計算が軽くなった分とキャッシュに当たった分が混ざりうる。ケースの数・繰り返し方とKVの容量を並べて確かめたい。 6. 動かすまで 版がぶつかるので、仮想環境をエンジンごとに分け、クライアントはHTTPだけで話す。 エンジン torch transformers vLLM 2.13.0+cu132 5.17.0 SGLang 2.13.0 5.12.1 TensorRT-LLM 2.9.1+cu130 4.57.3 問題 対処 TensorRT-LLM環境でModelOptが動かない（NumPy<2固定と最新pyarrowが衝突） pyarrow<22 TensorRT-LLM FP8が起動中にsegfault（原因不明、再実行で通過） — そのとき親プロセスが残り、20分待ち続けた ログにSegfault encountered等が出たら即失敗にして1回だけ再起動 まとめ：比較を作る・読むときのチェックリスト 確かめること 確かめ方 モデルに届く入力は同じか usage.prompt_tokensを並べる。テンプレート適用後の文字列を比べる ツールパーサーは何か 起動オプションを書く 量子化の計算は何か 起動ログのカーネル名・警告 量子化のチェックポイントは同じか 対応表とソースで、使うGPUで読める形式か確かめる KVの容量はいくつか 割合ではなくトークン数で見る。揃えるなら直接指定する 溢れたら何が起きるか 追い出しカウンタと同時実行数。max_tokensも書く 指標が読めないときの扱い 読めなければ止める キャッシュの状態 有効か、区切りごとに消すか、cached_tokensはいくつか。ケースの数・繰り返し方とKVの容量も書く 私の使い分け（推奨案） 速さではなく、導入の手間・設定の素直さ・観測しやすさで決めた。 当てはまる範囲：24GBクラスのGPU1台・8B級・同時8本程度まで。大きいGPUや70B級ではメモリ（3節）と量子化の対応（2節）が変わる。 推奨 想定するユースケース 決め手 気をつけること vLLM 社内チャットやRAGのPoC。公開モデル（量子化版を含む）を差し替えて評価する 公開チェックポイントをそのまま読める（2）。既定の設定で起動し、追い出しがカウンタで見える（3・4） L4のFP8はW8A16（2） SGLang 同じツール定義・システムプロンプトを先頭に付けるエージェントやバッチ処理 RadixAttention（用語）。L4でもFP8がW8A8（2）。※今回は共有部分が短く、実測ではない（5） 入力が増える（1）。割合を手で決める（3）。指標が0で出ない（5）。共有部分の長い順に処理するlpmは既定ではない（既定fcfs） TensorRT-LLM モデルを固定して長く運用する本番API 処理中のリクエストが途中でやり直しにならない（4）。量子化は最初の1回で済む 量子化を作り直す（2）。混むとTTFTが伸びるので、SLAがTTFTなら自分で測る（4）。キャッシュを消すAPIなし（5） 迷ったらvLLMで基準を作り、チェックリストで条件を揃えてから他と比べる。 付録：起動コマンド vLLM 0.31.0（bf16。AWQ・FP8はモデル名だけ替える。VLLM_SERVER_DEV_MODE=1 を付けて起動） vllm serve Qwen/Qwen3-8B --served-model-name Qwen/Qwen3-8B \ --host 127.0.0.1 --port 8000 \ --enable-auto-tool-choice --tool-call-parser hermes \ --enable-prompt-tokens-details --max-model-len 8192 SGLang 0.5.21 python -m sglang.launch_server --model-path Qwen/Qwen3-8B --served-model-name Qwen/Qwen3-8B \ --host 127.0.0.1 --port 30000 \ --tool-call-parser qwen --enable-metrics --enable-cache-report \ --mem-fraction-static 0.87 --context-length 8192 TensorRT-LLM 1.2.1（ModelOptで作ったAWQ。bf16はQwen/Qwen3-8B） echo "enable_iter_perf_stats: true" > trtllm-serve.yaml trtllm-serve ~/models/Qwen3-8B-int4-awq-modelopt \ --host 127.0.0.1 --port 8001 --backend pytorch \ --tool_parser qwen3 --config trtllm-serve.yaml --max_seq_len 8192 出典 SGLang v0.5.21：github.com/sgl-project/sglang/tree/v0.5.21 （srt/entrypoints/openai/serving_chat.py・protocol.py・usage_processor.py、srt/observability/metrics_collector.py、srt/function_call/function_call_parser.py、srt/arg_groups/memory_hook.py） TensorRT-LLM v1.2.1：github.com/NVIDIA/TensorRT-LLM/tree/v1.2.1 （tensorrt_llm/commands/serve.py、llmapi/llm_args.py、_torch/model_config.py、_torch/modules/linear.py、cpp/tensorrt_llm/executor/jsonSerialization.cpp、docs/source/features/quantization.md） ModelOpt 0.37.0：github.com/NVIDIA/Model-Optimizer/tree/0.37.0 （examples/llm_ptq/hf_ptq.py） vLLM v0.31.0：github.com/vllm-project/vllm/tree/v0.31.0 （vllm/config/cache.py、vllm/engine/arg_utils.py、vllm/model_executor/layers/quantization/fp8.py、vllm/model_executor/kernels/linear/init.py・scaled_mm/marlin.py・cutlass.py・flashinfer.py・deep_gemm.py・b12x.py、vllm/utils/flashinfer.py、vllm/platforms/cuda.py、vllm/model_executor/layers/quantization/utils/w8a8_utils.py、csrc/libtorch_stable/quantization/w8a8/cutlass/c3x/、vllm/entrypoints/openai/chat_completion/protocol.py、vllm/v1/metrics/loggers.py）、起動ログ vLLM プレフィックスキャッシュの設計：docs.vllm.ai TensorRT-LLM スケジューラの方針（GUARANTEED_NO_EVICT／MAX_UTILIZATION）：nvidia.github.io SGLang サーバー引数：docs.sglang.io 、new_token_ratioはsrt/managers/schedule_policy.py nvidia/Qwen3-8B-FP8：huggingface.co PagedAttention：Kwon et al., SOSP 2023。RadixAttention：Zheng et al., NeurIPS 2024

NCCL Roadmap Nov 2026 - Jan 2027 の解説 はじめに ! NCCL 奥がふかすぎる。。。。にゃ。。。 NVIDIA が公開した NCCL Roadmap: Nov 2026 - Jan 2027 (GitHub Issue #2486) から、大規模分散学習・推論に携わるエンジニアが押さえるべきポイントを解説します。前回のロードマップの解説は「NCCL Roadmap Aug-Oct 2026 の解説」、そこで挙げた項目の現在までの実装状況は「NCCL 2.32.3 でロードマップはどう実装されたか」にあります。GIN の基本は前回の解説を前提にします。 この記事では、新しい概念の GENK と Flow、AWS EFA と GIN の現状、注目機能 2 つを扱います。調査は 2026 年 10 月 29 日に行い、まだリリースされていないコードは、staging ブランチを次のリリースの候補とみなして読んでいます。 実装状況の確かめ方 NVIDIA/nccl、aws-ofi-nccl、amazon-contributing/DeepEP、NVIDIA/nccl-extensions の公開ブランチを手元に取得し、commit の履歴とソースを読んで確かめました。PR と Issue の状態 (open か、マージされたか、閉じた日) は GitHub で確かめています。記事のソースへのリンクは、確かめたときの commit に固定しています。 NCCL は master、staging、dev の 3 本のブランチを公開していて、staging には 2.32.5-1 の版番号を付けた commit があり、その後に 2.32.6a0 に上がっています。ロードマップは「Coming Soon: NCCL 2.32 Update 1」の版番号を書いていませんが、この記事では staging のコードをその候補として読みます。 今回のロードマップの項目のうち、この記事で扱うものと、前回のロードマップの近い項目は次のとおりです。対応は筆者の読みです。 今回のロードマップの項目 前回のロードマップの近い項目 General Kernels (GENK) Unify legacy kernels using Device API Flow Device API More Device API primitives GIN Backend Improvements GIN backend improvements CFT を使う階層型カーネル Compute Fabric Transport (CFT) through Device API New Enqueue Pipeline Legacy and symmetric-kernel host-side unification ロードマップには、内部のメモリの削減、RAS の進み具合の監視、RMA の profiling など、この記事で扱わない項目もあります。 Device API とは何か NCCL の API の全体像 ロードマップの項目を説明する前に、まず背景知識として NCCL の API を整理します。NCCL の API は、Host API、Device API、plugin API の 3 つに分けられます。Host API と Device API の仕様は NCCL の公式文書にあり、この記事の表はその章立てに沿っています。plugin API は公式文書の API の章には無く、リポジトリの plugins ディレクトリに plugin の種類ごとの説明があります。 API 何をするか 例 Host API CPU から呼んで、communicator (通信に参加する GPU の集まり) の作成や集団通信を NCCL に頼みます。集団通信では、NCCL がアルゴリズムを選び、NCCL のカーネルを GPU で起動します。利用者の計算は別のカーネルです ncclCommInitRank、ncclAllReduce Device API 利用者が書いた CUDA カーネルの中から、ほかの GPU との通信を直接呼びます (2.28 から)。計算と通信を 1 つのカーネルに入れられます。使う前の準備には Host API を使います GIN、LSA plugin API NCCL のほうから呼ぶ、下の部品の差し替え口です。ネットワークへの送受信や、アルゴリズムの選択の調整などを、NCCL の外の実装に任せます net、GIN。説明は plugins にあります。aws-ofi-nccl は EFA 用の plugin 誰が NCCL を呼ぶか NCCL を呼ぶのは、多くの場合アプリ自身ではなく、間に入るフレームワークやライブラリです。主な呼び手を、ソースで確かめた範囲で並べます。 呼び手 どう呼ぶか 使う API PyTorch の torch.distributed (backend "nccl") C++ の ProcessGroupNCCL が、ncclAllReduce などを直接呼びます Host API PyTorch の backend "nccl4py" (torch.distributed._nccl4py) Python で書いた backend が、nccl4py を通して呼びます。init_process_group("nccl4py") で選びます Host API nccl4py NVIDIA の公式の Python の bindings。Cython で libnccl を呼び、PyTorch の tensor や CuPy の配列をそのまま渡せます。実験的な CuTe DSL の部品もあります 主に Host API vLLM の PyNccl Python の ctypes で libnccl を読み込んで呼びます Host API PyTorch の symmetric memory の演算、DeepEP、NCCL EP 自分の CUDA カーネルの中から通信を呼びます。準備には Host API で window (次の節で説明します) を登録し、device communicator を作ります Device API と Host API aws-ofi-nccl など NCCL のほうから呼ばれます。NCCL が EFA などのネットワークに送るときの下の部品です。InfiniBand には NCCL に組み込みの経路もあります plugin API Device API は何のためにあるか Host API で通信を頼むと、通信は NCCL のカーネル 1 回分の単位になり、利用者の計算とは別のカーネルになります。計算の途中で決まった相手に少しずつ送りたい場合や、計算と通信を細かく重ねたい場合には、この単位が粗すぎます。たとえば MoE のトークンの振り分けでは、どのトークンをどの GPU に送るかが計算の途中で決まります。 Device API は、利用者のカーネルの中から、ほかの GPU のメモリへ直接データを動かせるようにするための API です。NCCL の Device API の例は、計算と通信を分けて順に行う従来のやり方に対して、カーネルの中で両方を細かく混ぜることで、待ち時間を減らし処理量を上げられると説明しています。 GPU のカーネルからほかの GPU に届く経路はいくつかあり、Device API は経路ごとに部品を用意しています。同じノードで NVLink や PCIe の P2P でつながった相手には、相手のメモリを普通の読み書きの命令で触れます (LSA)。NVLink のスイッチが複数の宛先への書き込みや足し合わせを引き受けられるシステムでは、Multimem を使います。ノードをまたぐ相手には、NIC を通して put (相手のメモリへの書き込み) や get (相手のメモリからの読み出し) を出します (GIN)。どちらも、相手が何も呼ばない片側通信です。CFT は、相手のメモリを番地 (ポインタ) で触る代わりに、CUDA が用意する宛先の番号 (logical endpoint) とオフセットを指定して put や get を出す部品で、Blackwell 以降の GPU で使えます。これらと組み合わせて使う、足し合わせやコピーの部品 (reduce と copy) も用意されています。 GIN の仕組みは、前回の解説の「GIN とは何か」で説明しました。LSA は後の GENK と Flow の節で、CFT は注目機能の節で扱います。Multimem と reduce と copy の部品は、この記事では詳しく扱いません。 どの部品を使う場合も、準備は利用者が CPU で Host API を呼んで行います。通信に使うバッファを、全ランクで同じ形に対応付けた領域 (symmetric memory window) として登録し、カーネルが使う資源を指定して device communicator を作り、それを渡して自分のカーネルを起動します。手順の例は NCCL の文書にあります。GIN を使うカーネルは、NCCL を更新したら作り直す必要があると文書は書いています。次の節からは、この Device API の上に加わる新しい部品とカーネルを見ていきます。 GENK と Flow とは何か ! GENK と Flow は、まだリリースされておらず staging と dev にだけあるコードです。この節は staging の実装から読み取った内容で、リリースまでに変わる可能性があります。staging で試すには、ビルドのときに SYM_GENK=1 を指定し、実行のときに NCCL_SYM_GENK_ENABLE=1 を設定する必要があります。 概要 Flow は、前の節の LSA と GIN の上に作られた、集団通信の部品を提供する Device API です。ロードマップは Flow を「LSA と GIN の両方で動く、高水準の Device API」と説明しています。LSA は前の節で触れた、相手の GPU のメモリを普通の読み書きの命令で触る部品です。 GENK (General Kernels) は、NCCL が自分の Ring と Tree の集団通信を、この Flow の上で作り直したカーネルの一群です。Ring では AllGather、ReduceScatter、Broadcast、Reduce、AllReduce を、Tree では AllReduce を実装しています。 前回のロードマップには「Unify legacy kernels using Device API」という項目がありました。筆者は、GENK をこの項目につながる取り組みと読んでいます。今回のロードマップは、選んだプラットフォームで GENK を既定にし、古いカーネルを置き換えるとしています。あわせて性能モデルを 1 つにまとめ、どの実装を選ぶかを同じ物差しで決めるとしています。 staging では、NCCL 自身が同じ Flow で集団通信を組んでいます。Flow がリリースに入れば、利用者も NCCL の内部と同じ部品で通信カーネルを書けます。 NCCL の集団通信には、GENK の前から 2 種類のカーネルがあります。 legacy kernels: NCCL に最初からある Ring や Tree のカーネルです。経路の違いは、CPU の側が準備する transport (NVLink や PCIe の P2P、ネットワークなど) が受け持ち、ネットワークでは CPU の proxy スレッドが NIC に渡します。 symmetric カーネル: 全ランクが同じ形で登録したバッファ (symmetric memory window) を集団通信に渡したときに使える、新しいカーネルです。相手のバッファの番地が分かるので、Device API の LSA などで相手のメモリを直接読み書きします。いまあるものは、NVLink の直結を前提に、場面ごとに作り込まれています (表の「特化した symmetric カーネル」)。 GENK は、symmetric カーネルと同じ Device API の作りで、legacy kernels と同じくらい広い経路で動くものです。Ring で隣の GPU にデータを渡す場面で比べると、次のようになります。 隣の GPU との経路 legacy kernels 特化した symmetric カーネル GENK NVLink 動く 動く 動く (LSA) PCIe の P2P 動く 使えない 動く (LSA) 別のノード (ネットワーク) 動く 一部の種類だけ動く (GIN) 動く (GIN) 表は、Hopper 以降の GPU で GENK を有効にした場合についてソースから読んだもので、動かして確かめたものではありません。PCIe の行は CUDA P2P が使える場合、GENK のネットワークの行は GIN Proxy (GPU の代わりに CPU のスレッドが NIC に送る GIN のバックエンド) が使える場合です。 特化した symmetric カーネルは、PCIe だけでつながったノードでは候補から外れます。GENK では、隣の GPU ごとに Flow が LSA か GIN かを実行時に選ぶので、同じカーネルのまま NVLink でも PCIe でもネットワークでも動きます。staging のカーネルの選択にも「特化したカーネルは NVLink の直結を要するが、GENK は CUDA P2P の LSA や GIN も使える」というコメントがあります。 利用者の側の例もあります。NCCL の Device API の例には、Transformer の RMSNorm の計算を ReduceScatter と AllGather の通信と 1 つのカーネルにまとめるものがあり、いまは LSA、Multimem、GIN を直接使って、受け取り、足し合わせ、送り出しを書いています。Flow は、NCCL 自身が集団通信に使うこの受け取り、足し合わせ、送り出しの部分を、部品として提供します。 NCCL の文書の Device API の章には、Flow と GENK の説明はまだありません。Flow の使い方は、ヘッダの説明にまとまっていて、Flow processor を足した commit が入口になります。GENK は、カーネルを足した commit と、NCCL の選択に組み込んだ commit が出発点です。 図で [API] のタグを付けた Flow processor、LSA connection、GIN connection は、アプリのカーネルからも呼べる Device API です。cost model、legacy kernels、specialized symmetric kernels、GENK は NCCL の中の部品です。 GIN の signal とは GIN の put は片側通信で、受け手は何も呼ばないので、データがいつ届いたかを自分では知れません。signal は、それを知らせるための、受け手の側に置かれた数です。送り手が put に signal を付けると、データが届いたあとに受け手の数が増え (たとえば 1 増え)、受け手はその数が目標に達するまで待ってから読みます。GIN の基本は、前回の解説の「GIN とは何か」で説明しました。 signal には strong と weak の 2 種類があります。weak signal が「読んでよい」と約束するのは、その signal を付けた put のデータだけです。strong signal は、同じ相手に同じ context (GIN の通信の通り道の 1 本) で先に出した put のデータもすべて読めると約束します。そのため、最後の put にだけ signal を付ければ済みます。 EFA の送り方の SRD は、書き込みが届く順番を保ちません。そのため、最後の put に付けた signal が届いても、前の put のデータが届いたとは限りません。EFA の上の経路のうち、GPU から直接送る EFA GDA が提供するのは weak signal だけです (次の節で説明します)。一方、Flow の GIN の接続は strong signal を必要とします。 AWS EFA 関連アップデートと現在の課題 EFA の 2 つの GIN の経路と signal の種類 ! GENK と Flow の GIN の接続は strong signal を必要とします。EFA の上で strong signal を提供するのは GIN Proxy だけで、GPU から直接送る EFA GDA は weak signal しか提供しません。そのため、EFA の複数ノードで GENK を使うなら Proxy の経路になります。 EFA で GIN を使うときは、使う経路 (GIN のバックエンド) が、カーネルの必要とする種類の signal を提供するかを先に確かめます。NCCL は、カーネルが求める種類の signal を提供できないバックエンドを使わず、提供できる別のバックエンドがあればそちらに切り替え、無ければエラーにすると説明しています。EFA で使う GIN の経路として、ここでは 2 つを比べます。1 つは NCCL の GIN Proxy で、CPU のスレッドが aws-ofi-nccl の RMA の機能を通して EFA に送ります。もう 1 つは EFA GDA で、GPU のカーネルが EFA の送信キューに直接依頼を書きます。aws-ofi-nccl の文書によると、EFA GDA は NCCL_GIN_TYPE=5 で明示したときに使われます。同じ文書は、明示しなければ NCCL 2.31 は EFA で Proxy を使うと書いています。インスタンスやドライバなどの要件も同じ文書にあります。 2 つの経路は、提供する signal が違います。NCCL の Proxy は、strong signal と VA signal (登録した仮想アドレスに置く signal) を使えると報告します。EFA GDA については、aws-ofi-nccl が strong signal も VA signal も使えないと報告し、NCCL の側も番号で指す indexed signal だけを受け付けます。EFA GDA の signal は、EFA の NIC が届いた書き込みを数えるカウンタで作られています。aws-ofi-nccl の文書は、signal と counter の合計が EFA のデバイスあたり 512 個までであることも、制限に挙げています。 図の矢印は、使い手が必要とする signal をバックエンドが提供するかを示します。矢印はソースと文書から描いたもので、どの経路が選ばれるかや、動かした結果を示すものではありません。図の DeepEP の ordered は届く順番を前提にする上流のカーネル、unordered は順番を前提にしない amazon-contributing のフォークのカーネルです。 GENK はノードをまたぐ通信に使う GIN のバックエンドとして Proxy を指定しているので、staging のコードを読む限り、GENK が EFA の上で複数ノードの通信をするなら Proxy の経路を通ります。一方、aws-ofi-nccl の文書は、EFA GDA を使うときに symmetric の GIN カーネルを無効にするよう書いていて、この設定 (NCCL_SYM_GIN_KERNELS_ENABLE=0) にすると複数ノードの GENK は候補から外れます。つまり、EFA GDA を使う設定 (NCCL_GIN_TYPE=5 と NCCL_SYM_GIN_KERNELS_ENABLE=0) では複数ノードの GENK は使われず、複数ノードで GENK を試すときは、この 2 つの環境変数を設定せずに Proxy の経路で動かします。 aws-ofi-nccl v1.22.0 で、EFA GDA の Get がタグの付いた版で使えるようになった Get は、GPU のカーネルが、ほかの GPU のメモリの中身を、持ち主に何もさせずに読み出す操作です。たとえば、手元の番号を見て、ほかの GPU が持つ表の行を取り出すような使い方ができます。Get の意義は「NCCL 2.32.3 でロードマップはどう実装されたか」で説明しました。 その記事の時点では、NCCL 2.32.3 には Get が入っていましたが、aws-ofi-nccl の側の対応はタグの無い master にしかありませんでした。2026 年 10 月 22 日 (日本時間) の v1.22.0 は、NCCL 2.32 が使うキューの形への対応と、Get の完了を数える修正を含む最初のタグです。これで、NCCL 2.32 と aws-ofi-nccl v1.22.0 という、タグの付いた版どうしに、EFA GDA の Get に要る変更がそろいました。v1.22.0 のリリースノートは Get に触れておらず、筆者は動かして確かめていません。 ただし、EFA GDA の Get には、完了を知らせる signal や counter を付けられません。読み出しが終わったかは、出した依頼をまとめて待つ Flush で確かめます。 MoE の通信ライブラリ (DeepEP と NCCL EP) の動き MoE のトークンを担当の expert に配り (dispatch)、計算結果を集める (combine) 通信のライブラリにも動きがありました。DeepEP と NCCL EP はこの同じ役割の候補で、どちらも下で NCCL を使います。DeepEP は 2026 年 9 月 29 日の V2.5 で NVSHMEM への依存を取り除き、ノードをまたぐ通信は NCCL の GIN だけになりました。要件は NCCL 2.32.3 以降です。EFA で DeepEP を動かす取り組みは amazon-contributing/DeepEP のフォークにあり、その詳細は別の記事で整理してみます。 NVIDIA の NCCL EP は NVIDIA/nccl-extensions に移り、NCCL の staging からは、nccl_ep と nccl_m2n のディレクトリが消されました。 注目機能 2 選 CFT を使う階層型カーネル CFT (Compute Fabric Transport) は NCCL 2.31 で Device API に加わった部品で、嬉しさは 2 つあります。1 つ目は、カーネルから直接届く相手を、LSA の範囲より広げられる見込みがあることです。LSA で届く相手は、CUDA P2P で相手のメモリを普通の読み書きの命令で触れる相手 (LSA team) に限られます。CFT は相手を番地ではなく CUDA が配る宛先の番号で指すので、届く範囲は、CUDA が「この番号で届く」と報告する範囲で決まります。前回のロードマップも、CFT を、logical endpoint で届く範囲の相手を宛先の番号で指す通信の形と説明していました。ただし、リリースされた版では、CFT で届く相手の集まり (CFT team) の大きさは既定で LSA team と同じです。 2 つ目は、受け手に届いたことを早く知らせる書き込みがあることです。CFT の普通の put や reduce で受け手に知らせるときは、データを書いたあと、書き込みの完了を確定させ (fence)、合図のフラグを書きます。これが counted な書き込みで、フラグの代わりに、NCCL_WIN_CFT_COUNTED を付けて登録した window の中のカウンタを使います。カウンタはデータより後に進むことが保証されているので、送り手は fence とフラグの書き込みを省けます。staging の文書は、これを低遅延のための操作と説明しています。受け手は、カウンタを見てからデータを読む間に fence を入れる必要があります。 仕組みは次のとおりです。CFT の宛先の番号は、CUDA 13.3 で加わった logical endpoint という仕組みです。NCCL は CPU の側で、宛先の番号を確保し、そこに各 GPU のバッファを結び付けておきます。カーネルは、送りたいデータを shared memory に置き、宛先の番号とオフセットを指定して put を出し、そのあと完了を確かめます。 dev では、CUDA 13.4 以降で CUDA が「logical endpoint で届く範囲」を報告すると、CFT team をその範囲から作ります。その範囲は LSA の範囲の倍数でなければならず、LSA より広い範囲を 1 つの CFT team にできる作りです。NCCL の文書は、CFT がどの物理的な経路を通るかを書いていません。NCCL EP の CFT を使う経路は、1 つの NVLink のドメインの中だけを対象にしています。 ロードマップは、この CFT を使って、AllGather、ReduceScatter、AlltoAll の階層型カーネルを作るとしています。階層型は、近い GPU の間と遠い GPU の間で通信を分ける作りで、LSA の範囲と、それより広い CFT team の範囲を使い分けることになると筆者は読んでいます。master、staging、dev を調べた範囲では、CFT の宛先の集まりの階層の種類は 2.32.3 のコードに定義されていますが、それを使う集団通信のカーネルは見当たりませんでした。 CFT とは CFT が使えるのは、ハードウェア、ドライバ、CUDA が logical endpoint と fabric 用の命令に対応したシステムだけで、例の barrier のプログラムは CUDA 13.3 と SM_100 を要件に挙げています。CFT team を CUDA の報告する範囲 (clique) から作る変更は、dev の 2026 年 9 月 28 日の commit で入り、master と staging にはまだありません。 NCCL EP には、CFT の counted な書き込みで低遅延の dispatch を送る経路が、NCCL_EP_LL_CFT=1 で選んだときだけ使われる形で、2026 年 9 月 16 日の commit から main に入っています。 New Enqueue Pipeline: 呼び出しから起動までを 3 つの層に分ける enqueue は、アプリが呼んだ集団通信や put を、カーネルやコピーの起動に変える NCCL の中の流れです。ロードマップは、これを管理 (Management)、準備 (Preparation)、スケジューリング (Scheduling) の 3 層に分け、制御の流れを簡単にし、カーネルの最適化をしやすくするとしています。 管理と準備の層を含む基本の枠組みは 2.31.2 から入っていて、その時点のスケジューリングの層は既存の経路に戻すだけでした。いまの staging と dev でも、新しい流れは既定で無効です。dev では、Preparation の tuning ですべての集団通信のアルゴリズムやプロトコルを先に選び、classification でその結果だけを使って起動の経路を振り分ける形にしました。経路ごとのスケジューラは、それぞれの仕事を stream ごとに 1 つのキューにまとめます。dev の commit では、新しい流れの symmetric のスケジューラが起動するのは特化した symmetric カーネルだけで、GENK は自分用の device communicator の準備が要るので、従来の流れの symmetric カーネルのスケジューラから起動されます。 まとめ staging の GENK は、Hopper 以降の GPU でビルドと環境変数で有効にすると NVLink、PCIe、ネットワークのどの経路でも同じカーネルが候補になり、EFA の複数ノードでは strong signal を提供する GIN Proxy の経路を使います。CFT を使う階層型カーネルは部品だけが公開コードにあり、New Enqueue Pipeline は枠組みが既定で無効のまま dev で進んでいます。

⚡ Serve LLMs faster and cheaper with vLLM's PagedAttention, continuous batching and a drop-in OpenAI-compatible API. 🔗 vllm-project/vllm Credits: vllm-project/vllm #vllm #python #llm

Numbers from the open vLLM RFC: vllm#63626