如何在本地部署 Qwen 3.8 Max：硬體、vLLM、SGLang 與量化指南

在本地執行 Qwen3.8-Max 現已可行，但「Qwen 3.8 Max 本地化」這一表述需要一個重要澄清。Alibaba 託管的 Max 產品與可下載的檢查點關係密切，但它們並非相同產品。

Qwen 於 2026 年 8 月上旬率先推出託管版 Max 服務，並於 2026 年 8 月 12 日 釋出 Qwen3.8-2.4T-A95B 為開放權重。該檢查點才是你實際在自有基礎設施上部署的模型。

這不是一篇把 Ollama 裝在遊戲 PC 上的普通教程。未量化的檢查點是一個 2.4 兆參數的 MoE 模型，當前 vLLM 配方估算其 BF16 權重約為 4.45 TiB。即便是面向生產的 4 位元浮點變體，權重仍約為 1.3–1.5 TiB。

**快速答案：**完整的 Qwen 3.8 Max 級自託管屬於資料中心級部署。一個實際可行的生產起點是使用 8× B300 或 8× MI355X GPU 的 FP4 檢查點；H200 部署需要更多 GPU。普通工作站則選擇 Qwen3.8-27B。

Qwen 3.8 Max 與實際可部署的開放模型

可下載的 Qwen3.8-2.4T-A95B 檢查點官方描述為一個 2.4T 參數的因果語言模型，每個 token 啟用約 95B 參數。託管版 Max 服務則增加了目前開放檢查點所不具備的產品層功能。

託管產品提供文字、影像與影片輸入，以及 1,000,000 token 的上下文。相較之下，開放檢查點僅支援文字，且原生上下文為 262,144 token。若你的應用依賴多模態輸入或託管的內建工具，這一差異至關重要。

Qwen 3.8 架構與規格

CometAPI 已在「What is Qwen3.8 Max」中介紹了模型背景，因此本部署指南僅聚焦於影響記憶體、平行度與服務的架構細節。

Qwen 官方混合模型架構，見 SGLang Qwen3.8 部署指南。

不要把「95B 啟用參數」誤解為 95B 模型的記憶體足跡。稀疏激活能降低每 token 計算量，但服務系統仍需能存取完整的專家權重集合。

Qwen 3.8 Max 基準測試快照

由於 CometAPI 的 Qwen3.8 Max 概覽已詳細討論了基準，本篇僅採用官方模型卡表格中與部署相關的子集。

Qwen 官方釋出的 Qwen3.8 效能圖，來源： Qwen 團隊。

在此子集中，相對 Qwen3.7-Max 的最大提升發生在 PaperBench 與 FrontierSWE。Qwen3.8-Max 在 SWE-bench Pro 與 PaperBench 上也超過了 GPT-5.6 Sol，而 GPT-5.6 Sol 在 Terminal Bench 2.1 上仍領先。對部署決策而言，將這些視為能力背景；下文的記憶體與服務吞吐量測量更具操作相關性。

基準表並非通用排名。測試框架、超時、上下文限制、工具存取與量化都會影響結果。請以你計畫使用的確切檢查點、精度、服務引擎以及提示分佈進行基準測試。

Qwen3.8 本地部署需要哪些硬體？

Qwen3.8-2.4T-A95B 的 GPU 需求

這是部署的關鍵問題。目前的 vLLM Qwen3.8 配方公布了檢查點佔用與具備執行時餘量的實際 GPU 數量，這比僅從參數量估算 VRAM 更有用。

對大多數確有自託管 Qwen3.8 需求的組織而言，FP4 是實用的起點。突出的 NVIDIA 配置是 8× B300 上的 NVFP4 W4A4；相應的 AMD 路線是 8× MI355X 上的 MXFP4。

一臺 8× H200 伺服器不足以滿足上述完整模型部署。官方配方目前將 H200 尺寸定為 FP4 需 16 張、FP8 需 32 張、BF16 需 48 張。

Qwen3.8-27B 的 VRAM 需求

Qwen3.8-27B 是實際可行的工作站級替代方案。原始權重記憶體約為 BF16 54 GB、FP8 27 GB、4 位元 13.5 GB。執行時額外開銷與 KV 快取會提高實際需求，尤其在長上下文下。

上述數字是依參數量推估的規劃值。請在生產規模前確認實際檢查點、量化格式、服務引擎、上下文長度與 KV 快取設定。

Qwen3.8 能在消費級 GPU 上運行嗎？

完整的 Qwen3.8-2.4T-A95B 即便在激進量化下，也不適合於普通消費級 GPU。一個社群專案曾展示過將 UD-Q1_0 極致壓縮至 397 GB 並分散於四套 DGX Spark 系統，但這是實驗性的極端量化，並非面向品質敏感服務的基準路徑。

對於工作站或個人實驗室，更合適的模型是 Qwen3.8-27B，其開放權重於 2026 年 8 月 14 日釋出。該模型的託管難度低數個數量級，如果「本地」指的是一臺工作站，這才是正確選擇。

安裝 Qwen 3.8 Max 之前

在執行安裝命令前先規劃基礎設施。你需要 Linux、相容的加速器軟硬體棧、足夠的本地或共享儲存以存放檢查點、高帶寬 GPU 互連，以及跨節點時用於分散式推理的網路。vLLM 配方目前建議使用 vLLM nightly 與 Transformers 5.4.0 或更新版本。

bash

uv venv
source .venv/bin/activate

uv pip install -U vllm \
  --extra-index-url https://wheels.vllm.ai/nightly

uv pip install -U "transformers>=5.4.0"

如何使用 vLLM 部署 Qwen 3.8 FP8

當你希望使用 Qwen 提供的檢查點，且能負擔多節點基礎設施時，FP8 是明智選擇。官方檢查點為 Qwen/Qwen3.8-2.4T-A95B-FP8。

對於兩節點、16 GPU 的 B300 級部署，在首節點執行：

bash

export HEAD_ADDR="10.0.0.10"

vllm serve Qwen/Qwen3.8-2.4T-A95B-FP8 \
  --tensor-parallel-size 16 \
  --nnodes 2 \
  --node-rank 0 \
  --master-addr "$HEAD_ADDR" \
  --max-model-len 262144 \
  --kv-cache-dtype fp8 \
  --reasoning-parser qwen3
On the worker node, use the same topology with a different node rank and no API server:

bash

export HEAD_ADDR="10.0.0.10"

vllm serve Qwen/Qwen3.8-2.4T-A95B-FP8 \
  --tensor-parallel-size 16 \
  --nnodes 2 \
  --node-rank 1 \
  --master-addr "$HEAD_ADDR" \
  --headless \
  --max-model-len 262144 \
  --kv-cache-dtype fp8 \
  --reasoning-parser qwen3

不要將這個 16 GPU 的示例直接照搬到 H200 伺服器而不調整拓撲。相同 FP8 變體在 vLLM 配方中目前為 32× H200 的尺寸。

如何在單臺 8× B300 伺服器上運行 Qwen 3.8

對於 NVIDIA Blackwell，最實用的完整模型配置是 NVFP4。vLLM 目前在 8 張 B300 上以張量並行驗證了 NVFP4 W4A4。

bash

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

Inferact 的 NVFP4 構建是量化檢查點，而非原始的 BF16 Qwen 成品。請在自有驗收集上驗證模型品質，再將其視為 BF16 或 FP8 的可替代品。

如何使用 SGLang 部署 Qwen 3.8

SGLang 於 8 月 12 日提供 Qwen3.8 的 Day-0 支援，在高吞吐服務、前綴快取、專家並行、推測解碼與預填充/解碼解耦方面尤其具吸引力。

bash

SGLANG_ENABLE_MOE_DEFERRED_FINALIZE=1 \
SGLANG_FLASHINFER_MNNVL_CUTEDSL_AR_FUSION=1 \
sglang serve \
  --trust-remote-code \
  --model-path RadixArk/Qwen3.8-2.4T-A95B-NVFP4 \
  --tp-size 8 \
  --context-length 200000 \
  --preferred-sampling-params '{"top_k": 20}' \
  --attention-backend trtllm_mha \
  --linear-attn-prefill-backend flashinfer \
  --linear-attn-decode-backend flashinfer \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_coder \
  --host 0.0.0.0 \
  --port 30000

SGLang 報告在啟用 MTP、TP8 B300、批次大小為 1 時，可達 346 輸出 token/s，且在解耦式服務佈局中總吞吐量顯著更高。請將這些數值視為服務棧測量，而非模型品質基準。

測試本地的 OpenAI 相容端點

vLLM 與 SGLang 均提供 OpenAI 相容 API，便於應用整合。

python

from openai import OpenAI

client = OpenAI(
    api_key="EMPTY",
    base_url="http://localhost:8000/v1",
    timeout=3600,
)

response = client.chat.completions.create(
    model="Qwen/Qwen3.8-2.4T-A95B-FP8",
    messages=[
        {
            "role": "user",
            "content": "Design a fault-tolerant Redis architecture for three regions."
        }
    ],
    temperature=1.0,
    top_p=0.95,
    max_tokens=8192,
)

print(response.choices[0].message.content)

官方模型卡建議將 temperature 設為 1.0、top_p 設為 0.95、top_k 設為 20 作為基準採樣參數。對於代理型任務，請為推理留出足夠的輸出預算，而不是僅按最終可見答案來設定 max_tokens。

啟用 1M 上下文視窗

Qwen3.8-2.4T-A95B 開放檢查點原生上下文為 262,144，可擴至約 1.01M。vLLM 配方記錄了以下模式：

bash

VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 \
vllm serve Qwen/Qwen3.8-2.4T-A95B-FP8 \
  --max-model-len 1010000 \
  --hf-overrides '{"max_position_embeddings": 1010000}' \
  --reasoning-parser qwen3 \
  ...

不要僅因為支援就把 1M 設為預設。越大的最大上下文會預留更多快取容量，並可能明顯降低併發度。請將 --max-model-len 設為符合實際工作負載的值。

如何提升 Qwen3.8 推理效能？

使用 MTP-3 降低單用戶延遲

Qwen3.8 支援多詞元預測。在 vLLM 公布的測量中，對 FP8 TP16，MTP-3 可將單用戶輸出從 130 提升至 307 tok/s；對 NVFP4 TP8，則從 133 提升至 304 tok/s。

bash

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

使用 fastsafetensors 加速啟動

對 TB 級模型而言，啟動時間很重要。在某次 vLLM 測量中，結合 fastsafetensors 與懶加載後，權重載入時間從 545 s 降至 306 s。

bash

--load-format fastsafetensors \
--safetensors-load-strategy lazy

使用專家並行以提高併發吞吐量

在高併發下，Qwen3.8 受惠於專家並行佈局，因為它擁有 512 個路由專家。vLLM 報告對 FP8 EP 可達 每 GPU 3,200 總 tok/s，對經優化的 NVFP4 DEP16 佈局可達每 GPU 4,300 總 tok/s。

設定 --max-model-len 以平衡 VRAM 與併發

將 --max-model-len 設為工作負載真正需要的最長序列。值越大會預留越多 KV 快取容量，增加記憶體壓力，並可能降低併發數，即使模型權重已經裝入。

從具代表性的生產分位數起步，而非模型宣稱的最大上下文。用相同精度、批次模式與服務引擎進行壓測，僅在實際請求需要時再提高上限。

Qwen 3.8 本地部署 vs. API

開放權重並不自動意味著本地推理更經濟。正確決策取決於利用率、資料駐留、團隊人力、可用性目標，以及你是否真的需要託管模型的多模態功能。

若你已擁有合適的加速器，且利用率持續高，自託管可能合理。若為此模型才購置叢集，CometAPI 上的 Qwen3.8-Max 通常更省事。既有的 API 指南涵蓋了託管整合與定價，因此本文重點放在本地部署。

Qwen 3.8 本地部署常見問題

伺服器在啟動期間耗盡 GPU 記憶體

若是快取所致，請先降低 --max-model-len。若是權重本身裝不下，減少上下文無法解決根因；請改用經驗證的低精度檢查點或增加 GPU。

張量並行因大小無效而失敗

Qwen3.8 在其全注意力層具有 64 個注意力頭，因此 vLLM 要求 TP 能整除 64。直接的 TP 尺寸為 1、2、4、8、16、32。僅有總 VRAM 並不足以決定拓撲。

伺服器啟動耗時很長

載入數 TB 權重再加上核心 JIT 需要數分鐘。提高 VLLM_ENGINE_READY_TIMEOUT_S，並探測真實推理端點，而非假設短啟動視窗。

本地模型無法處理影像

這是預期行為。Qwen3.8-2.4T-A95B 開放檢查點僅支援文字。這一限制特定於 Qwen3.8-2.4T-A95B。Qwen3.8-27B 在載入其獨立的視覺投影檔案後可支援視覺輸入。

1M 上下文顯著降低吞吐量

將 --max-model-len 調低到工作負載真正需要的最長序列。最大支援上下文不一定是最佳生產設定；請在工作負載需求、KV 快取使用與併發之間取得平衡。

Ollama 或 LM Studio 能跑 Qwen 3.8 Max 嗎？

生態系可將高度量化的 Qwen3.8 權重包裝為類 llama.cpp 的推理，但這不能與普通桌面級的 Ollama 工作流混為一談。即便量化後仍需數百 GB 的構建，依然需要數百 GB 可用記憶體，且在品質與效能上存在重大取捨。

對於一般本地開發，Qwen3.8-27B 才是合適目標。即便社群極端量化在非常規硬體上讓完整 2.4T 模型「技術上可啟動」，它仍應被視為伺服器/叢集級模型。

應選擇哪種部署方式？

對 NVIDIA Blackwell，目前最乾淨的完整模型起點是 8× B300 的 NVFP4 部署。對 AMD，對應的實用配置是 8× MI355X 的 MXFP4。當你優先考慮檢查點來源與品質而非基礎設施規模時選擇 FP8；只有在最大保真度足以支撐多機櫃級記憶體需求時才選 BF16。

對工作站，請選擇 Qwen3.8-27B。對需要 Max 能力且不想運維 GPU 叢集的應用團隊，請使用託管的 CometAPI 上的 Qwen3.8-Max 模型。

結論

自最初的 API 上線以來，Qwen3.8-Max 已跨過重要門檻：Qwen 的 Max 級家族現已擁有可在自有基礎設施上完全運營的開放 2.4T 檢查點。

但開放權重並不意味著消費級硬體可用。4.45 TiB 的 BF16 佔用、2.27 TiB 的 FP8 檢查點與 1.3–1.5 TiB 的 FP4 變體，使 Qwen3.8-2.4T-A95B 成為最吃基礎設施的開源模型之一。其實用的好處是 vLLM 與 SGLang 已支援該架構，而 FP4 讓單節點的 8× B300 或 8× MI355X 部署成為可能。

當資料控制、持續高利用率與基礎設施所有權足以支撐叢集時，選擇自託管；否則，使用託管的 Max API——若你真正需要的是能在單臺工作站上運行的強力 Qwen 模型，則選擇 Qwen3.8-27B。