核心概念
Hugging Face 於 2026 年 7 月 8 日發布技術部落格，宣布 transformers vLLM 後端（--model-impl transformers）現已能與原生 vLLM 實作並駕齊驅——在多個 LLM 架構的基準測試中，transformers 後端達到甚至超越原生 vLLM 的推論吞吐量。
雙重實作的歷史負債
過去，開發者必須為同一個模型架構維護兩份程式碼：
- Transformers 實作：Hugging Face 的參考實作，支援訓練、評估、RL rollout
- vLLM 原生實作：為高吞吐量推論優化的客製化版本
這種雙軌並行消耗大量維護成本，且每個新架構都必須等待 vLLM 社群完成優化移植，才能在生產環境發揮最大性能。本次更新從根本解決了這個問題。
技術實現：torch.fx + AST 雙引擎
Transformers vLLM 後端的高性能源自兩個核心技術組合：
- torch.fx 靜態圖分析：對模型計算圖進行靜態分析，自動識別可優化的操作模式，包括 attention 的 QKV projection、MoE 的 expert dispatch 等
- AST 程式碼重寫：在執行時直接修改 Python 源碼，將多對一操作映射到 vLLM 高效 kernel，包括：
MergedColumnParallelLinear：支援 Tensor Parallelism 的合併線性層QKVParallelLinear：並行 attention 的 QKV 合併- Expert Parallelization（EP）：MoE 模型的專家並行分發
重要特性：優化後的模型仍完全支援 torch.compile 與 CUDA Graphs，且不需要對模型定義層做任何改動，原有 transformers 程式碼可直接用於推論。
覆蓋範圍
- 支援 transformers 函式庫內的 450+ 架構，新模型自動獲得加速
- 限制：linear attention 架構暫不支援（開發中）；Hub 上的自訂模型需符合 transformers 規範撰寫才可運作
關鍵要點
性能驗證（Qwen3 系列基準測試）
以下測試在完全相同條件下比較三種模式：native（原生 vLLM）、before（優化前 transformers 後端）、after（本次 PR 後），結果三個模型均達到或超越原生吞吐量：
| 模型 | 規模 | 硬體配置 |
|---|---|---|
| Qwen3-4B | 稠密模型 | 單 GPU |
| Qwen3-32B | 稠密模型 | 2×GPU（Tensor Parallel） |
| Qwen3-235B-A22B-FP8 | MoE 235B 參數 | 8×H100（Data + Expert Parallel） |
使用方式（僅需加一個 flag）
# 安裝
uv pip install --upgrade vllm --torch-backend auto
# 稠密模型，單 GPU
vllm serve Qwen/Qwen3-4B --model-impl transformers
# 搭配 Tensor Parallelism
vllm serve Qwen/Qwen3-32B --model-impl transformers --tensor-parallel-size 2
# MoE 模型 + Data + Expert Parallelism
vllm serve Qwen/Qwen3-235B-A22B-FP8 --model-impl transformers \
--data-parallel-size 8 --enable-expert-parallel
--model-impl transformers 與現有並行配置（TP、DP、EP）完全相容，不改變服務架構，可直接疊加在既有部署設定上。
訓練與推論統一的深層價值
同一份 transformers 代碼，現在可以跨越整個 ML 生命週期：
- 預訓練（FSDP / DeepSpeed）
- 監督微調（SFT）
- 強化學習 rollout（TRL、OpenRLHF）
- 生產推論（vLLM 服務）
對 RLHF / RLAIF 流程尤其關鍵——policy model 更新後不再需要手動同步兩份不同實作之間的差異，消除了一類常見的工程 bug 來源。
實務應用
縮短新架構部署週期
模型作者只需在 transformers 完成實作，即自動獲得生產級推論性能，無需等待 vLLM 社群維護對應的優化版本。這使新架構從研究發表到可部署的時間大幅壓縮。
ML 基礎設施維護簡化
企業或研究團隊維護自訂模型時，只需維護一份 transformers 實作，vLLM 後端自動從中衍生優化路徑，大幅降低長期維護負擔。
相關技術：vLLM V0 升級 V1：強化學習訓練的後端正確性優先原則、HF Jobs × vLLM：零基礎設施的按需 LLM 推論端點、Delta Weight Sync in TRL：異步強化學習的百倍同步壓縮、非同步連續批次推論：LLM 推論的 CPU GPU 並行加速
延伸觀點
vLLM vs TGI 的推論性能差距（arxiv 2511.17593，2025-11）
一項針對 vLLM 與 HuggingFace TGI 的對比研究指出，vLLM 在高並發場景下的吞吐量可達 TGI 的 3.7–24 倍。關鍵差異在於 PagedAttention 的記憶體架構：vLLM 透過消除碎片化將記憶體消耗降低 19–27%，GPU 利用率達 85–92%（TGI 為 68–74%）。這項數據與 HF 部落格的性能聲明一致，兩個來源均強調 vLLM 在高並發批次場景的壓倒性優勢。
研究也指出 TGI 仍有一席之地：對首字延遲（TTFT）要求嚴苛的即時對話應用，TGI 的低 TTFT 設計更為適合；量化模型部署（INT4/INT8）的支援也較成熟。因此，transformers 後端的意義不只是性能平權，更在於讓模型作者能在不放棄 HF 生態兼容性的前提下，針對特定場景選擇最適合的部署策略。
生態演化路徑（vLLM 官方部落格，2025-04）
vLLM 官方在 2025 年 4 月初步整合 transformers 後端時，核心訴求是解決模型支援缺口——新架構在 transformers 上線後，不需等待 vLLM 社群完成同等移植。當時的整合尚未達到原生速度，主要依靠 PagedAttention 和 continuous batching 提供加速。2026 年 7 月 HF 部落格所記錄的 torch.fx + AST 優化，是這條路線的里程碑：正式消弭了「相容性」與「效能」之間的取捨，使 transformers 實作成為 vLLM 推論的一等公民。
兩個來源共同揭示的方向：LLM 推論基礎設施的未來趨勢，是以少數高品質的開源實作為核心（transformers 作為模型定義層），搭配可插拔的優化後端（vLLM、TGI、TensorRT-LLM），而非每個系統各自維護一套完整模型庫。
反向連結
以下頁面引用了本頁：