網易首頁 > 網易號 > 正文申請入駐

vLLM 硬核四連發！

2026-03-27 22:31:47　來源: Ai學習的老章

北京舉報

分享至

大家好，我是 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 的整體架構概覽，可以看到從信號提取到決策路由再到模型選擇的完整流程：

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 的模型棧全景，可以直觀看到新舊基座的替換：

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

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

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

ClawOS 多智能體編排界面

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

3. 零配置上手 + Dashboard 驅動

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

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

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

Dashboard 首次啟動引導

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

Dashboard 系統大腦 4. AMD ROCm Yes！

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

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

vllm-sr serve --platform amd

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

AMD ROCm 部署架構

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

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

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 在同級別開源模型中智能水平和開放度都領先：

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

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

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

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

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

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 SPEED-BENCH 性能對比

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

怎么做到的？

下圖是 P-EAGLE 的架構原理圖，左側是傳統 EAGLE 的自回歸方式，右側是 P-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 在所有并發度上都領先：

MT-Bench 吞吐量對比

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

HumanEval 吞吐量對比

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

Speed-Bench 吞吐量對比

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

接受長度（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%）

使用方法

只需要兩步：

下載（或訓練）并行版草稿頭，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 布局緊耦合的問題：

V1 持久化批處理設計

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

MRV2 持久化批處理設計

更關鍵的是，輸入準備移到了 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 端輸入準備直接消費拒絕采樣結果，消除所有同步點：

MRV2 推測解碼異步優化 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：

MRV2 吞吐量提升 56.2%

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

MRV2 TPOT 對比

提升來自零同步設計——推測解碼啟用后 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，推測解碼不再有序列瓶頸

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

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

特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。

Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.