Qwen3.8-27B 在 vLLM 上：在一或兩顆 GPU 上於生產環境中提供服務

是的——Qwen3.8 27B 現已在生產環境中透過 vLLM 提供服務，而且在多數情況下只需單張 GPU。關鍵的版本是 vLLM 0.17.0 或更新版本：它內建官方配方、此模型所需的混合注意力（hybrid-attention）核心，以及相容 OpenAI 的 /v1 端點。若使用單張 Blackwell GPU，請執行 NVFP4 量化版——vLLM 官方配方測得其在 tensor-parallel size 1 下占用 24.6 GiB 的 VRAM。若使用單張 48GB 顯示卡，請執行 FP8。完整的 BF16 權重為 51.7GB 的 checkpoint，需要一張 80GB GPU 或兩張 48GB 顯示卡以 tensor-parallel 方式運作。確切的指令如下；第一條是單行指令。

這裡的所有資訊皆於 2026 年 8 月 15 日完成驗證，當天正是權重上線的第三天。架構、上下文與授權資訊來自 Hugging Face 上的 Qwen3.8 27B 模型卡；檢查點大小為該 repo 內 18 個 safetensors 分片的總和；vLLM 指令與 24.6 GiB 的數字則出自 vLLM 官方為此模型提供的 recipe 頁面。Qwen3.8 27B 是阿里巴巴推出的稠密型 270 億參數多模態模型——Apache 2.0 權重，於 8 月 13 日至 14 日發布——由於權重為開放式，你可以自行部署，不必租用 token。而這個 fork，正是本文真正要談的重點。

重要事實，附上來源

• 架構 — 27B 稠密（27.8B 包含視覺塔與填充詞彙表），64 層，隱藏大小 5,120，詞彙表 248,320。官方模型卡，今日驗證。

• 注意力 — 混合架構：16 個全注意力層、48 個 Gated DeltaNet 線性層，以 3:1 區塊模式排列。僅有 16 層保留持續成長的鍵值快取；其餘 48 層則改為保留固定大小的遞迴狀態。

• 上下文 — 原生支援 262,144 個 token，可透過 YaRN RoPE 擴展至約 1M。模型卡，今日已驗證。

• 輸入 — 原生文字、圖片與影片；文字輸出。vLLM 透過標準的 chat-completions API 提供這三種輸入，無需單獨的投影器檔案。

• 授權 — Apache 2.0。正是這一事實，使得「自己提供服務 vs 租用代幣」的問題得以存在。

• 權重 — BF16 檢查點總計 51.7GB，分布在 18 個 safetensors 分片中（Hugging Face，今日已驗證）。Qwe​n 也發布了專為 vLLM 建置的 FP8 與 NVFP4 檢查點。

• vLLM 需求 — 0.17.0 或更新版本，且 transformers ≥ 5.8.0。vLLM 的 recipe 頁面，今日已驗證。「任何 vLLM」並非安全指示；新版本新增的是循環層內核。

• 多 Token 預測 — 推測解碼的草稿頭內建於檢查點中，因此您無需單獨的草稿模型。vLLM 有記載此旗標；目前尚無獨立的加速數據。

GPU 階梯 — 哪種量化用在哪張顯示卡上

三種服務格式涵蓋了實際應用範圍。請依你實際擁有的VRAM來選擇，而非依據「最佳量化」來選。

• NVFP4 — 總計 24.6 GiB（權重加上 FP8 KV 快取），根據 vLLM 在 TP1 的配方。可裝入單一 Blackwell 級 GPU——實際上是 32GB 的 RTX 5090 或 B200。這是延遲最低的路徑，也是每張卡能保留最多上下文的路徑：vLLM 的配方顯示即使在 1M 上下文擴展下，仍具備 6.6M KV-token 容量。

• FP8——約26GB的權重。一張48GB顯示卡（L40S、RTX A6000、RTX 6000 Ada）即可負載，並留有上下文空間；兩張48GB顯示卡以張量並行（tensor-parallel）方式運作，則為更長的上下文或更高的並發度提供餘裕。若想取得最大的KV快取，vLLM自身的作法是在四卡GB300托盤上以TP4執行FP8。

• BF16 — 51.7GB 的權重，因此單張 80GB GPU（H100、A100 80GB、B200、GB300）或兩張 48GB 顯示卡（TP2）即可。這是參考精度的選項，也是下方 1M 上下文擴展命令實際使用的選項。

• MXFP4 — 請勿在 NVIDIA 上使用。vLLM 的 MXFP4 路徑目前缺少對線性方法的支援；相同的權重以 NVFP4 發布，這才是 NVIDIA 配方實際使用的格式。

執行它 — vLLM 命令

低延遲單 GPU 預設（NVFP4，一個 Blackwell GPU），逐字取自 vLLM 的配方：

vllm serve Inferact/Qwen3.8-27B-NVFP4 --tensor-parallel-size 1 --max-model-len 262144 --kv-cache-dtype fp8 --reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_coder

同一配方中的 FP8 指令（TP4、一個 GB300 托盤、最大的 KV 快取）：

vllm serve Qwen/Qwen3.8-27B-FP8 --tensor-parallel-size 4 --max-model-len 262144 --kv-cache-dtype fp8 --reasoning-parser qwen3

對於兩張48GB顯示卡，保留FP8指令並設定--tensor-parallel-size 2而非4。

將此附加至任一命令以啟用 MTP 推測解碼：

--speculative-config '{"method":"mtp","num_speculative_tokens":3}'

1M上下文擴展（也來自vLLM的配方）：

vllm serve Qwen/Qwen3.8-27B --max-model-len 1010000 --hf-overrides '{"text_config": {"max_position_embeddings": 1010000}}'

Point any O​penAI client at http://localhost:8000/v1 — the endpoint is a drop-in replacement. Two runtime details matter once it is up: thinking is on by default at reasoning_effort xhigh, so turn it off per request with chat_template_kwargs {"enable_thinking": false} or drop it to {"reasoning_effort": "low"} for faster answers. And the checkpoint ships temperature 1.0, top_p 0.95, top_k 20 in its generation config — pass those unless your app already overrides sampling.

vLLM 自己的頁面承諾了什麼，又沒有承諾什麼

• 尚無 27B 的吞吐量數據。截至 8 月 15 日，vLLM 的 recipe 頁面並未發布 Qwen3.8 27B 的吞吐量或延遲基準測試。「每顆 GPU 每秒 4,000+ tokens」這個流傳的數字，屬於 Qwen3.8 2.4T-A95B 在 72 顆 GPU 的 GB300 NVL72 機架上的表現，且為廠商自行回報，並非此型號的數據。你在社群中看到的每秒 token 數，是 GGUF 格式在 llama.cpp 或 Ollama 下跑出來的結果——那與 vLLM 服務是不同的執行環境、不同的工作負載。

• 「KV 快取成本低廉」的說法取決於執行環境。模型卡指出 64 層中僅 16 層保留快取，但這只有在伺服引擎確實實作 Gated DeltaNet 層時才有幫助。vLLM 0.17+ 正是實作此功能的版本；因此本文將版本固定列為首要內容，而非放在註腳。

• MTP 已內建，但此處尚未測量。草稿頭位於檢查點中，vLLM 文件也記載了該旗標，但至今尚無人發布此 27B 在 vLLM 上的獨立加速數據。請以自己的流量進行測量。

• NVIDIA 是經實測驗證的路徑。 vLLM 的設定方式是專為 NVIDIA GPU（NVFP4 和 FP8）撰寫。此混合注意力模型在 AMD Instinct 或 Intel Gaudi 上的部署仍屬實驗前沿，本文對此亦不諱言。

自己動手服務，或租用代幣

這就是 Apache 2.0 的用武之地。Qwen3.8 27B 沒有按 token 計費的授權費用，所以唯一真正的問題在於你是擁有硬體還是租用 token。

• 自行托管（本文）——你只需為 GPU 付費一次，之後的每個 token 都是免費的。你已擁有的 RTX 5090 使 NVFP4 指令成為零邊際成本的端點，且資料不會離開本機。如果你必須租用 GPU，雲端 5090 或一對 A6000 就是成本項目，而整個論點只有在你已擁有顯示卡或有持續的用量時才成立。

• 租用代幣——因為權重是開放的，多個主機都在運行，價格底線就是硬體成本。Qwen3.8 27B 今天已在 OrcaRouter 上線，每百萬輸入代幣 0.33 美元、每百萬輸出代幣 2.40 美元——沒有需要轉嫁的供應商加價，因為 OrcaRouter 是在自己的基礎設施上運行開放權重——而且這些開放權重也支撐了一個速率受限的免費層級，每請求收費 0 美元，超過上限時會回傳 HTTP 429。以具代表性的一個月 1000 萬代幣、70% 為輸入來計算，付費層級約為 9.51 美元。

• 決策規則——如果你已經擁有 GPU，就自架；如果必須購買或租用，在副專案用量下 API 很快就會打平，而且同一個 OpenAI 相容用戶端可以指向任一端點，所以遷移時程式碼不需變動。

當 vLLM 是錯誤的答案時

• 你只是一個人，用一台筆電——vLLM 是伺服引擎，不是桌面應用程式。對單一使用者的本機執行來說，搭配 Q4 GGUF 的 llama.cpp 或 Ollama 更簡單，只需要 24GB 顯示卡，而不需要 Blackwell GPU；我們的「如何在本地執行 Qwen3.8-27B」指南會從頭到尾帶你走完這條路。

• 您需要保證吞吐量且零運維——自行託管意味著您要自行承擔告警、佇列和故障轉移的責任。如果您不希望「API 掛了」這句話出現在您的詞彙中，那就改為租用 Token，讓別人替您營運整個系統。

• 你確實需要完整的約 1M 上下文，且具備前沿品質 — 那就是 Qwen3.8 2.4T-A95B 的工作，由 vLLM 或 SGLang 在 72 顆 GPU 的 GB300 NVL72 機架上提供服務。Qwen3.8 27B 在一或兩顆 GPU 上無法與之匹配；我們關於 2.4T 的部署文章解釋了為什麼該模型屬於不同類別的問題。

• 您使用的是較舊的24GB顯示卡 — NVFP4是Blackwell格式；在Ampere（RTX 3090）或Ada（RTX 4090）這類24GB顯示卡上，FP8路徑是vLLM的選項，再往下，llama.cpp下的GGUF量化則是務實的終點。同一模型在24GB顯示卡上是另一回事。

• 您必須在一張卡上實現最大的併發服務——上述單 GPU 預設值只是起點，並非生產環境的最終型態。請根據您自身的請求組合調整 --max-num-seqs、KV 快取與 MTP 配置，之後才能宣告完成。

底線

Qwen3.8 27B 是少數能在生產環境中由 vLLM 以單張 GPU 服務的稠密 27B 模型。更新到 vLLM 0.17.0+，然後為 32GB Blackwell 顯示卡拉取 NVFP4 量化版本（24.6 GiB），FP8 量化版本則用於單張 48GB 顯示卡或兩張卡以張量並行（tensor-parallel）方式執行，BF16 則保留給 80GB GPU。指令都是一行就能搞定，端點與 O​penAI 相容，而且因為權重採用 Apache 2.0 授權，你可以自行部署，或是以每百萬 token $0.33/$2.40 的價格租用，還有免費方案——兩種方式使用同一套客戶端程式碼。唯一還沒有人做到的，是針對 vLLM 上的 27B 提出獨立的吞吐量數據，所以啟動之後，先預留一個小時做基準測試，再向任何人承諾延遲數字。