vLLM 硬核四連發！2026 年 3 月重大更新深度解析

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

關於 vLLM，我之前寫過不少：

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

一、Semantic Router v0.2 Athena：從路由器到系統大腦

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

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

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

下圖是 Athena 的整體架構概覽，可以看到從信號提取到決策路由再到模型選擇的完整流程：

1. 模型棧全面換血

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

下圖展示了新的跨模態嵌入模型 multi-modal-embed-small，能把文字、圖片、音訊統一映射到同一個 384 維語義空間：

性能提升立竿見影——在 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 的模型棧全景，可以直觀看到新舊基座的替換：

2. ClawOS：讓路由器變成 AI 作業系統

這是 Athena 最大膽的嘗試。ClawOS 把 Semantic Router 變成了一個可以編排多個 OpenClaw 智慧體團隊的操作層。你可以透過自然語言對話來建立團隊、分配 Worker、即時協調——有點像給 AI 智慧體搞了個「作業系統」。

下圖是 ClawOS Dashboard 的多智慧體編排介面——可以看到團隊管理、Worker 分配和即時聊天協作的完整介面：

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

3. 零設定上手 + Dashboard 驅動

以前搞 Semantic Router 得先寫一堆 YAML 設定。現在一行命令搞定：

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

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

Dashboard 現在不光能設定路由，還能視覺化拓樸、回放路由決策、做評估測試。真正成了「系統大腦」：

4. AMD ROCm Yes！

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

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

vllm-sr serve --platform amd

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

老章說：Semantic Router 的野心越來越大了。從 v0.1 的「請求路由」到 v0.2 的「系統大腦」，vLLM 開始不只做推理引擎，而是做上層編排。對於需要跑多個模型的生產環境來說，這東西值得關注。

二、NVIDIA Nemotron 3 Super：為多智慧體而生的 MoE 模型

NVIDIA 發力了，新模型在 OpenClaw 成功率排行榜殺進前五，目前免費用

NVIDIA 和 vLLM 聯手推出了 Nemotron 3 Super 的官方支援。先來看一組驚人的數字：

總參數：1200 億
啟動參數：僅 120 億（MoE 架構，Latent MoE 讓 4 個專家的推理成本等於 1 個）
上下文視窗：100 萬 token
支援 GPU：B200、H100、DGX Spark、RTX 6000

下圖是 Artificial Analysis 的評測對比，Nemotron 3 Super 在同級別開源模型中智慧水準和開放度都領先：

為什麼說它是「為多智慧體而生」？

多智慧體系統有兩個老大難問題：

上下文爆炸：多個智慧體之間不停傳遞歷史記錄、工具輸出和推理步驟，token 越滾越大。Nemotron 3 Super 用 100 萬 token 上下文視窗直接暴力解決——歷史全裝得下，目標漂移大幅減少。
推理稅：每個子任務都用大模型會又慢又貴。MoE 架構只啟動 120 億參數，吞吐量比前代提升最高 5 倍，NVFP4 精度在 Blackwell 上比 H100 的 FP8 還快 4 倍，且精度幾乎無損。

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

快速上手

安裝 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 就能調用：

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 的定位很精準——不追求最強單點能力，而是在「效率×精度」的帕雷托前緣找到最優解。120B 總參數只啟動 12B，配合百萬 token 上下文，就是為多智慧體工作流量身訂製的。如果你在搞 Agent 編排、Tool-Calling Pipeline，這個模型值得認真評估。

三、P-EAGLE：推測解碼再提速，一次前向搞定所有草稿 token

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

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

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

怎麼做到的？

下圖是 P-EAGLE 的架構原理圖，左側是傳統 EAGLE 的自回歸方式，右側是 P-EAGLE 的並行方式：

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

對於下一個 token（NTP），輸入和標準 EAGLE 完全一樣
對於第 2 到第 K 個位置（MTP），輸入的 token embedding 和隱藏狀態還不存在，怎麼辦？P-EAGLE 引入了兩個可學習參數：共享的 mask token embedding 和共享的隱藏狀態 h_shared，作為佔位符

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

長序列訓練的挑戰

訓練 P-EAGLE 面臨的最大挑戰是記憶體。下圖展示了 GPT-OSS 120B 在 UltraChat 數據集上的序列長度分佈——中位數 3891 token，P90 達到 10800 token：

訓練 K 個並行組在長度為 N 的序列上，會產生 N×K 個位置。N=8192、K=8 時，一個訓練樣本就有 65536 個位置，注意力矩阵要 8GB。P-EAGLE 透過序列分區演算法解決了這個問題。

實測效果

三組基準測試的詳細結果如下：

MT-Bench 上不同併發下的吞吐量對比，P-EAGLE 在所有併發度上都領先：

HumanEval 程式碼合成任務，P-EAGLE 的優勢在高併發時依然明顯：

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

一個很有意思的發現：P-EAGLE 在 K=7 時達到巔峰性能，而 EAGLE-3 在 K=3 時就封頂了。因為並行生成不管 K 多大，前向傳播次數都是 1 次——越深的推測，P-EAGLE 的優勢越大。

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

HumanEval：P-EAGLE 3.94 vs EAGLE-3 3.03（高 30%）
SPEED-Bench：3.38 vs 2.59（高 31%）
MT-Bench：3.70 vs 3.27（高 13%）

使用方法

只需要兩步：

下載（或訓練）並行版草稿頭，HuggingFace 上已有 GPT-OSS 120B、GPT-OSS 20B、Qwen3-Coder 30B 的預訓練版本
加一個設定參數：

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 的思路很優雅——既然草稿模型的序列生成是瓶頸，那就不序列生成了。用可學習佔位符 + 並行 Transformer 一次搞定。代價是需要重新訓練草稿頭，但 Amazon 已經放出了多個預訓練版本。對於生產環境中追求極致延遲的場景，這個升級非常值得嘗試。

四、Model Runner V2：vLLM 核心引擎的徹底重構

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

這是自去年 vLLM V1 發布以來最大的架構升級。官方毫不客氣地說：V1 的 model runner 積累了大量技術債，持久化狀態和模型輸入耦合、非同步排程是後來打的補丁、CPU 端做了太多本該 GPU 乾的活、程式碼變得越來越難維護。

MRV2 圍繞三個核心原則重建：模組化、GPU 原生、非同步優先。

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

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

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

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

2. 非同步優先設計

V1 的非同步排程是「後來加上去的」，MRV2 把它作為核心設計約束——目標是 CPU 和 GPU 之間零同步。

下圖是標準的非同步排程時序，CPU 在 step N+1 做準備的同時 GPU 執行 step N：

最直接的好處：非同步排程和推測解碼終於可以乾淨地共存了。下圖展示了 MRV2 如何透過 GPU 端輸入準備直接消費拒絕採樣結果，消除所有同步點：

3. Triton 原生採樣器

MRV2 重寫了採樣邏輯：

Gumbel-Max 採樣核，避免顯式 softmax 計算
更高效的 top-k logprobs，先找 top-k logits 再算 logprobs
更節省記憶體的 prompt logprobs，支援單個 prompt 內的分塊處理
更好的推測解碼相容性

4. 更強的模組化

V1 的 gpu_model_runner.py 已經膨脹到 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, ...):
    ...

把模型特定邏輯（多模態嵌入、額外輸入、注意力元資料）和通用執行路徑分離。最大的檔案現在控制在 1300 行以內。

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

性能實測

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

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

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

現在就能試

export VLLM_USE_V2_MODEL_RUNNER=1
# 然後正常使用 vLLM，無需改任何程式碼

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

老章說：MRV2 是一次「傷筋動骨」的重構，但方向完全正確。把輸入準備搬到 GPU、實現零同步非同步排程、引入 ModelState 解耦——這些改進不是「錦上添花」，而是為未來異構模型 + 推測解碼 + 多模態並存的複雜場景打地基。56% 的吞吐提升只是開始，隨著更多特性遷移到 MRV2，收益還會繼續釋放。

總結：vLLM 2026 年 3 月全景

更新	發布日期	一句話概括
Semantic Router v0.2 Athena	3 月 10 日	從路由器進化成多模型編排的系統大腦
Nemotron 3 Super	3 月 11 日	120B 總參/12B 啟動，為多智慧體量身打造的 MoE 模型
P-EAGLE	3 月 13 日	一次前向搞定所有草稿 token，推測解碼不再有ech序列瓶頸
Model Runner V2	3 月 24 日	vLLM 核心引擎徹底重構，GPU 原生 + 零同步 + 強模組化

這四連發放在一起看，vLLM 的戰略意圖非常清晰：

底層——MRV2 重建引擎地基，為更複雜的推理需求做準備
加速——P-EAGLE 在推測解碼這個關鍵優化方向上再突破天花板
模型——Nemotron 3 Super 補全高效 MoE 模型的生態位
上層——Semantic Router Athena 開始做多模型編排和智慧體排程

從「推理引擎」到「推理平台」，vLLM 正在完成一次從工具到生態的躍遷。

相關連結：

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 官網：https://vllm.ai
Semantic Router GitHub：https://github.com/vllm-project/semantic-router

#vLLM #大模型推理 #推測解碼 #Nemotron #SemanticRouter

製作不易，如果這篇文章覺得對你有用，可否點個關注。給我個三連擊：按讚、轉傳和在看。若可以再給我加個🌟，謝謝你看我的文章，我們下篇再見！