摘要： AWS示範Qwen3.8-2.4T-A95B經NVFP4量化後，權重約從4.8TB壓到1.2TB，可在配備8張NVIDIA B300的單一SageMaker HyperPod節點上運行。文章說明混合注意力、vLLM關鍵參數與Inference Operator的權重下載、排程、健康檢查和自動擴展角色。這條路線降低硬體門檻，但ml.p6-b300需透過Flexible Training Plan預留容量，營運責任仍由團隊承擔。
聽到開源模型有 2.4T 參數，多數人的第一反應是要租一整排 GPU 機櫃才裝得下；AWS 的示範卻證明，一個節點就足以應付。訣竅在 NVFP4 量化：權重由 4.8TB 縮到 1.2TB，恰好在 ml.p6-b300 的 2.1TB 總記憶體之內。對打算自託管前沿模型的團隊來說，這說明硬體門檻比想像中低。
單節點為何跑得動
Qwen3.8-2.4T-A95B 是 Qwen-Max 等級的開源釋出版本，總參數 2.4T，但每個 token 實際只動用 95B。架構走混合設計：其中 69 層為 Gated DeltaNet 線性注意力，靠固定大小的遞迴狀態運作，不會隨上下文拉長而膨脹；真正會把 KV-cache 撐大的只有 23 層 full attention。長上下文推論的記憶體負擔因此顯著減輕。
改用 NVFP4 量化之後，權重約占 1.2TB；再把 KV-cache、遞迴狀態與 activation 一併算入，單一 p6-b300 節點還剩 500–700GB 可分配給批次處理。AWS 的文章強調，相較於 BF16 要吃掉 4.8TB，這樣的做法務實許多。
vLLM 的關鍵配置
實際部署時，vLLM 指令裡有幾個不能忽略的 flag：
vllm serve Inferact/Qwen3.8-2.4T-A95B-NVFP4 \
--tensor-parallel-size 8 \
--quantization nvfp4 \
--load-format fastsafetensors \
--trust-remote-code \
--enable-prefix-caching \
--moe-backend auto \
--reasoning-parser qwen3 \
--enable-auto-tool-choice \
--tool-call-parser qwen3 \
--speculative-config '{"method":"mtp","num_speculative_tokens":1}' \
--served-model-name Qwen3.8在多輪 agent 對話中，--enable-prefix-caching 尤其關鍵：system prompt 與歷史內容會反覆出現，有了快取就能省下大量重複計算。--speculative-config 則啟用原生 Multi-Token Prediction，靠 draft head 加快解碼，不必另外再掛一個小模型。
營運端的取捨
選好硬體只是起點。SageMaker HyperPod 以 EKS 作為控制平面，部署則靠 Inference Operator 的 CRD 來描述，權重下載、排程、健康檢查與自動擴展都交由它處理。問題在於 ml.p6-b300 無法用 on-demand 直接開啟，必須透過 Flexible Training Plan 預留容量。這代表你得先承諾一定份量的 GPU 時間，比較適合推論需求已經穩定的團隊。
和先前談過的細模型優勢對照，2.4T 模型站在光譜的另一端：它的價值不在省錢，而是把 frontier 能力拉進自家基礎設施。當 agent 工作負載需要長程規劃與複雜工具呼叫時，自託管能避開 per-token API 費用，付出的代價則是營運複雜度。
實際上的評估
AWS 引用的是 NVIDIA Day-0 基準，也就是 GB300 NVL72 在 FP8 下的數字：每顆 GPU 超過 4K tokens/sec，每位使用者超過 350 tokens/sec。換成單一 p6-b300 節點跑 NVFP4，吞吐量會按比例打折，但應付中等並發的生產推論仍然足夠。至於供應商基準，Qwen3.8 在 PaperBench 與 IFBench 上表現強勁，SWE-bench Pro 和 Toolathlon 則還有進步空間。
正在評估開源前沿模型的團隊，可以把這篇當成一條已經走通的路：容量規劃、量化選擇到 vLLM 參數都有人驗證過。下一步要回答的是，你的工作負載是否真需要 2.4T 參數，或者規模小一點的模型就足以解決問題。