開源 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 線性注意力，只用固定大小的遞迴狀態，不隨上下文增長；只有 23 層 full attention 會讓 KV-cache 變大。這讓長上下文推論的記憶體壓力大幅下降。
搭配 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--enable-prefix-caching 對多輪 agent 對話尤其重要，因為 system prompt 和歷史會重複，快取能省下大量重算。--speculative-config 啟用原生 Multi-Token Prediction，用 draft head 加速解碼，不需要另外掛一個小模型。
營運層面的取捨
硬體只是第一步。SageMaker HyperPod 用 EKS 當控制平面，透過 Inference Operator 的 CRD 來描述部署，處理權重下載、排程、健康檢查和自動擴展。但 ml.p6-b300 需要透過 Flexible Training Plan 預留容量，不是 on-demand 就能開。這代表你要先承諾一定量的 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 參數，還是小一點的模型就能解決問題。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。