大家好，我是 Ai 學習的老章

關(guān)于 vLLM，我之前寫過不少：

今天再來聊聊 vLLM 在 2026 年 3 月密集發(fā)布的四個重大更新——Semantic Router v0.2 Athena、NVIDIA Nemotron 3 Super 上線、P-EAGLE 并行推測解碼、以及Model Runner V2 架構(gòu)大重構(gòu)。這一波更新可以說是從底層引擎到上層編排全面開花，讓 vLLM 在 2026 年站穩(wěn)了大模型推理基座的位置。

一、Semantic Router v0.2 Athena：從路由器到系統(tǒng)大腦

第一個登場的是vLLM Semantic Router v0.2 Athena（雅典娜）。

如果你對 Semantic Router 還不熟悉，簡單說就是——它不是一個模型，它是幫你決定"這個請求該交給哪個模型處理"的智能路由層。

從 v0.1 Iris 到 v0.2 Athena，這次升級幅度相當大。

下圖是 Athena 的整體架構(gòu)概覽，可以看到從信號提取到?jīng)Q策路由再到模型選擇的完整流程：

Athena 整體架構(gòu) 1. 模型棧全面換血

Athena 把底層基座換成了新的多語言長上下文模型mmbert-embed-32k-2d-matryoshka，支持 1800 多種語言、32K 上下文。在它之上構(gòu)建了一整套分類器家族mom-multilingual-class，覆蓋意圖分類、越獄檢測、PII 檢測、事實核查和反饋檢測。

下圖展示了新的跨模態(tài)嵌入模型 multi-modal-embed-small，能把文本、圖片、音頻統(tǒng)一映射到同一個 384 維語義空間：

跨模態(tài)嵌入模型

性能提升立竿見影——在 AMD MI300X 上做了一組端到端測試：

請求大小

ONNX+GPU 平均延遲

ONNX+CPU 平均延遲

Candle+CPU 平均延遲

~500 tokens

22 ms

853 ms

1053 ms

~2000 tokens

31 ms

1814 ms

1805 ms

~8000 tokens

128 ms

4796 ms

1830 ms

ONNX+GPU 比 CPU 方案快了 40 倍，這不是理論測試，是走完 Envoy→ext_proc→SR 的真實路由鏈路。

下圖是 Athena v0.2 的模型棧全景，可以直觀看到新舊基座的替換：

Athena 模型棧全景 2. ClawOS：讓路由器變成 AI 操作系統(tǒng)

這是 Athena 最大膽的嘗試。ClawOS 把 Semantic Router 變成了一個可以編排多個 OpenClaw 智能體團隊的操作層。你可以通過自然語言對話來創(chuàng)建團隊、分配 Worker、實時協(xié)調(diào)——有點像給 AI 智能體搞了個"操作系統(tǒng)"。

下圖是 ClawOS Dashboard 的多智能體編排界面——可以看到團隊管理、Worker 分配和實時聊天協(xié)作的完整界面：

ClawOS 多智能體編排界面

雖然還是實驗性質(zhì)，但方向很清晰：**未來的 AI 推理不只是"選模型"，而是"管團隊"**。

3. 零配置上手 + Dashboard 驅(qū)動

以前搞 Semantic Router 得先寫一堆 YAML 配置。現(xiàn)在一行命令搞定：

curl -fsSL https://vllm-semantic-router.com/install.sh | bash

裝完自動啟動 Dashboard，進去配一下模型就能用。下圖是全新的 Dashboard 首次啟動引導界面：

Dashboard 首次啟動引導

Dashboard 現(xiàn)在不光能配置路由，還能可視化拓撲、回放路由決策、做評估測試。真正成了"系統(tǒng)大腦"：

Dashboard 系統(tǒng)大腦 4. AMD ROCm Yes！

AMD 用戶終于不是二等角色了

Athena 把 ROCm 做成了正式支持的部署路徑：

vllm-sr serve --platform amd

下圖展示了 AMD ROCm 端到端部署路徑，包括 GPU 直通、ONNX 加速和 CK Flash Attention 支持：

AMD ROCm 部署架構(gòu)

老章說：Semantic Router 的野心越來越大了。從 v0.1 的"請求路由"到 v0.2 的"系統(tǒng)大腦"，vLLM 開始不只做推理引擎，而是做上層編排。對于需要跑多個模型的生產(chǎn)環(huán)境來說，這東西值得關(guān)注。

NVIDIA 和 vLLM 聯(lián)手推出了Nemotron 3 Super的官方支持。先來看一組驚人的數(shù)字：

• 總參數(shù)：1200 億

• 激活參數(shù)：僅 120 億（MoE 架構(gòu)，Latent MoE 讓 4 個專家的推理成本等于 1 個）

• 上下文窗口：100 萬 token

• 支持 GPU：B200、H100、DGX Spark、RTX 6000

下圖是 Artificial Analysis 的評測對比，Nemotron 3 Super 在同級別開源模型中智能水平和開放度都領(lǐng)先：

Nemotron 3 Super Artificial Analysis 對比 為什么說它是"為多智能體而生"？

多智能體系統(tǒng)有兩個老大難問題：

1. 上下文爆炸：多個智能體之間不停傳遞歷史記錄、工具輸出和推理步驟，token 越滾越大。Nemotron 3 Super 用 100 萬 token 上下文窗口直接暴力解決——歷史全裝得下，目標漂移大幅減少。

2. 推理稅：每個子任務都用大模型會又慢又貴。MoE 架構(gòu)只激活 120 億參數(shù)，吞吐量比前代提升最高 5 倍，NVFP4 精度在 Blackwell 上比 H100 的 FP8 還快 4 倍，且精度幾乎無損。

下圖展示了 Nemotron 3 Super 在效率和精度兩個維度上的領(lǐng)先位置：

Nemotron 3 Super 效率 vs 精度 快速上手

安裝 vLLM 后一條命令就能部署：

pip install vllm==0.17.1


 # BF16 精度，4 卡 H100 配置
vllm serve nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-BF16 \
  --kv-cache-dtype fp8 \
  --tensor-parallel-size 4 \
  --trust-remote-code \
  --served-model-name nemotron \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --reasoning-parser nemotron_v3

然后用標準 OpenAI SDK 就能調(diào)用：

from openai import OpenAI
client = OpenAI(base_url="http://127.0.0.1:5000/v1", api_key="null")


 resp = client.chat.completions.create(
    model="nemotron",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "Give me 3 bullet points about vLLM"}
    ],
    temperature=0.7,
    max_tokens=256,
)
print("Reasoning:", resp.choices[0].message.reasoning_content, 
      "\nContent:", resp.choices[0].message.content)

值得注意的是，Nemotron 3 Super 還支持Thinking Budget，可以精細控制推理時的 token 開銷——不是所有任務都需要深度思考，簡單任務省著點用。

老章說：Nemotron 3 Super 的定位很精準——不追求最強單點能力，而是在"效率×精度"的帕累托前沿找到最優(yōu)解。120B 總參數(shù)只激活 12B，配合百萬 token 上下文，就是為多智能體工作流量身定制的。如果你在搞 Agent 編排、Tool-Calling Pipeline，這個模型值得認真評估。

推測解碼（Speculative Decoding）是目前加速大模型推理最有效的技術(shù)方向之一。EAGLE 系列是這個領(lǐng)域的 SOTA 方法，vLLM 也一直在深度集成。但 EAGLE 有一個繞不開的瓶頸——草稿生成是自回歸的。你想預測 K 個 token，就得跑 K 次前向傳播。當你想預測得更多的時候，草稿模型本身的延遲反而成了新的瓶頸。

先看效果——下圖是 P-EAGLE 在 NVIDIA B200 上 SPEED-BENCH 的性能對比，一眼就能看出差距：

P-EAGLE SPEED-BENCH 性能對比

P-EAGLE 的解決方案非常直接：把自回歸草稿生成改成并行生成——一次前向傳播，輸出全部 K 個草稿 token。

怎么做到的？

下圖是 P-EAGLE 的架構(gòu)原理圖，左側(cè)是傳統(tǒng) EAGLE 的自回歸方式，右側(cè)是 P-EAGLE 的并行方式：

P-EAGLE 架構(gòu)原理

P-EAGLE 在預填充階段和普通 EAGLE 一樣，捕獲目標模型的隱藏狀態(tài)。關(guān)鍵在第二步——草稿生成階段：

• 對于下一個 token（NTP），輸入和標準 EAGLE 完全一樣

• 對于第 2 到第 K 個位置（MTP），輸入的 token embedding 和隱藏狀態(tài)還不存在，怎么辦？P-EAGLE 引入了兩個可學習參數(shù)：共享的 mask token embedding 和共享的隱藏狀態(tài)h_shared，作為占位符

所有位置一起通過 N 層 Transformer，一次性輸出所有草稿 token。

長序列訓練的挑戰(zhàn)

訓練 P-EAGLE 面臨的最大挑戰(zhàn)是內(nèi)存。下圖展示了 GPT-OSS 120B 在 UltraChat 數(shù)據(jù)集上的序列長度分布——中位數(shù) 3891 token，P90 達到 10800 token：

序列長度分布

訓練 K 個并行組在長度為 N 的序列上，會產(chǎn)生 N×K 個位置。N=8192、K=8 時，一個訓練樣本就有 65536 個位置，注意力矩陣要 8GB。P-EAGLE 通過序列分區(qū)算法解決了這個問題。

實測效果

三組基準測試的詳細結(jié)果如下：

MT-Bench 上不同并發(fā)下的吞吐量對比，P-EAGLE 在所有并發(fā)度上都領(lǐng)先：

MT-Bench 吞吐量對比

HumanEval 代碼合成任務，P-EAGLE 的優(yōu)勢在高并發(fā)時依然明顯：

HumanEval 吞吐量對比

SPEED-Bench 長文本代碼生成任務，P-EAGLE 在 c=1 時加速比高達 1.69x：

Speed-Bench 吞吐量對比

一個很有意思的發(fā)現(xiàn)：P-EAGLE 在 K=7 時達到峰值性能，而 EAGLE-3 在 K=3 時就封頂了。因為并行生成不管 K 多大，前向傳播次數(shù)都是 1 次——越深的推測，P-EAGLE 的優(yōu)勢越大。

接受長度（AL）的對比更能說明問題。在 K=7 時：

• HumanEval：P-EAGLE3.94vs EAGLE-3 3.03（高 30%）

• SPEED-Bench：3.38vs 2.59（高 31%）

• MT-Bench：3.70vs 3.27（高 13%）

只需要兩步：

1. 下載（或訓練）并行版草稿頭，HuggingFace 上已有 GPT-OSS 120B、GPT-OSS 20B、Qwen3-Coder 30B 的預訓練版本

2. 加一個配置參數(shù)：

vllm serve openai/gpt-oss-20b \
  --speculative-config '{"method": "eagle3", "model": "amazon/gpt-oss-20b-p-eagle", "num_speculative_tokens": 5, "parallel_drafting": true}'

就這么簡單，"parallel_drafting": true一行搞定。

老章說：P-EAGLE 的思路很優(yōu)雅——既然草稿模型的序列生成是瓶頸，那就不序列生成了。用可學習占位符+并行 Transformer 一次搞定。代價是需要重新訓練草稿頭，但 Amazon 已經(jīng)放出了多個預訓練版本。對于生產(chǎn)環(huán)境中追求極致延遲的場景，這個升級非常值得嘗試。

如果前面三個更新是"在 vLLM 之上做加法"，那 Model Runner V2（MRV2）就是對 vLLM 核心引擎的徹底重寫。

這是自去年 vLLM V1 發(fā)布以來最大的架構(gòu)升級。官方毫不客氣地說：V1 的 model runner 積累了大量技術(shù)債，持久化狀態(tài)和模型輸入耦合、異步調(diào)度是后來打的補丁、CPU 端做了太多本該 GPU 干的活、代碼變得越來越難維護。

MRV2 圍繞三個核心原則重建：模塊化、GPU 原生、異步優(yōu)先。

1. 更好的持久化批處理 + GPU 原生輸入準備

V1 直接把持久化狀態(tài)當作模型輸入，導致布局約束和復雜的狀態(tài)管理。下圖展示了 V1 中請求順序與 Block Table 布局緊耦合的問題：

V1 持久化批處理設(shè)計

MRV2解耦了持久化請求狀態(tài)和每步輸入張量——每個活躍請求在固定大小的狀態(tài)表中有穩(wěn)定的行，每步按當前順序從中提取輸入。下圖可以清晰看到新設(shè)計如何通過 gather 操作生成正確排序的輸入：

MRV2 持久化批處理設(shè)計

更關(guān)鍵的是，輸入準備移到了 GPU 上，用 Triton Kernel 完成。input_ids、positions、query_start_loc、seq_lens這些張量現(xiàn)在直接在 GPU 上構(gòu)建，不再走 CPU。

2. 異步優(yōu)先設(shè)計

V1 的異步調(diào)度是"后來加上去的"，MRV2 把它作為核心設(shè)計約束——目標是 CPU 和 GPU 之間零同步。

下圖是標準的異步調(diào)度時序，CPU 在 step N+1 做準備的同時 GPU 執(zhí)行 step N：

異步調(diào)度時序

最直接的好處：異步調(diào)度和推測解碼終于可以干凈地共存了。下圖展示了 MRV2 如何通過 GPU 端輸入準備直接消費拒絕采樣結(jié)果，消除所有同步點：

MRV2 推測解碼異步優(yōu)化 3. Triton 原生采樣器

MRV2 重寫了采樣邏輯：

• Gumbel-Max 采樣核，避免顯式 softmax 計算

• 更高效的 top-k logprobs，先找 top-k logits 再算 logprobs

• 更節(jié)省內(nèi)存的 prompt logprobs，支持單個 prompt 內(nèi)的分塊處理

• 更好的推測解碼兼容性

V1 的gpu_model_runner.py已經(jīng)膨脹到6700 行。MRV2 引入了ModelState抽象接口：

class ModelState(ABC):
    def add_request(self, ...):
    def remove_request(self, ...):
    def get_mm_embeddings(self, ...):
    def prepare_inputs(self, ...):
    def prepare_attn(self, ...):
    def prepare_dummy_inputs(self, ...):
    ...

把模型特定邏輯（多模態(tài)嵌入、額外輸入、注意力元數(shù)據(jù)）和通用執(zhí)行路徑分離。最大的文件現(xiàn)在控制在1300 行以內(nèi)。

這對 DeepSeek、Qwen、Kimi 等不同模型系列的開發(fā)者來說太重要了——你只需要關(guān)心自己模型的ModelState，不用讀幾千行無關(guān)代碼。

性能實測

用小模型 Qwen3-0.6B 在 GB200 上跑（故意用小模型放大 CPU 開銷的影響），吞吐量直接從 16K 飆到 25K：

MRV2 吞吐量提升 56.2%

推測解碼場景：4 卡 GB200 + GLM-4.7-FP8 + MTP=1，TPOT 降低 6.3%：

MRV2 TPOT 對比

提升來自零同步設(shè)計——推測解碼啟用后 CPU-GPU 同步點完全消除。

現(xiàn)在就能試

export VLLM_USE_V2_MODEL_RUNNER=1
# 然后正常使用 vLLM，無需改任何代碼

不過需要注意，MRV2 目前還是實驗性質(zhì)，v0.18.0 中有幾項功能暫不支持：線性注意力模型（Qwen3.5、Nemotron 3 Super）、Eagle/Eagle3/MTP 之外的推測解碼方法、LoRA 等。

老章說：MRV2 是一次"傷筋動骨"的重構(gòu)，但方向完全正確。把輸入準備搬到 GPU、實現(xiàn)零同步異步調(diào)度、引入 ModelState 解耦——這些改進不是"錦上添花"，而是為未來異構(gòu)模型+推測解碼+多模態(tài)并存的復雜場景打地基。56% 的吞吐提升只是開始，隨著更多特性遷移到 MRV2，收益還會繼續(xù)釋放。

更新

發(fā)布日期

一句話概括

Semantic Router v0.2 Athena

3月10日

從路由器進化成多模型編排的系統(tǒng)大腦

Nemotron 3 Super

3月11日

120B 總參/12B 激活，為多智能體量身打造的 MoE 模型

P-EAGLE

3月13日

一次前向搞定所有草稿 token，推測解碼不再有序列瓶頸

Model Runner V2

3月24日

vLLM 核心引擎徹底重構(gòu)，GPU 原生+零同步+強模塊化

這四連發(fā)放在一起看，vLLM 的戰(zhàn)略意圖非常清晰：

• 底層——MRV2 重建引擎地基，為更復雜的推理需求做準備

• 加速——P-EAGLE 在推測解碼這個關(guān)鍵優(yōu)化方向上再突破天花板

• 模型——Nemotron 3 Super 補全高效 MoE 模型的生態(tài)位

• 上層——Semantic Router Athena 開始做多模型編排和智能體調(diào)度

從"推理引擎"到"推理平臺"，vLLM 正在完成一次從工具到生態(tài)的躍遷。

• Semantic Router v0.2 Athena：https://vllm.ai/blog/v0.2-vllm-sr-athena-release

• Nemotron 3 Super：https://vllm.ai/blog/nemotron-3-super

• P-EAGLE：https://vllm.ai/blog/p-eagle

• Model Runner V2：https://vllm.ai/blog/mrv2

• vLLM 官網(wǎng)：https://vllm.ai

• Semantic Router GitHub：https://github.com/vllm-project/semantic-router

制作不易，如果這篇文章覺得對你有用，可否點個關(guān)注。給我個三連擊：點贊、轉(zhuǎn)發(fā)和在看。若可以再給我加個，謝謝你看我的文章，我們下篇再見！