：Qwen3.8-27B單機量化與DeepSeek-V4-Flash TP=2調優(yōu))
1. 從單機到雙機這套組合到底在解決什么問題手里有兩臺 DGX Spark每臺搭載 GB10 超級芯片單機顯存 128GB這個配置放在半年前還算寬裕但現在動輒 200B 以上的 MoE 模型滿天飛單機跑 Qwen3.8-27B 的 Q8_0 量化版已經有點捉襟見肘——不是跑不起來而是 batch size 稍微開大一點就 OOM長上下文場景下 KV Cache 吃掉一大塊顯存留給權重的空間就更緊張了。我最初的想法很簡單先把單機優(yōu)化做到極致實在撐不住了再上雙機 TP2。事實證明這個思路是對的因為單機優(yōu)化過程中積累的顯存管理經驗在雙機部署時直接復用了。這篇文章記錄的就是從 Qwen3.8-27B 單機 Q8_0 量化部署調優(yōu)到 DeepSeek-V4-Flash 雙機 TP2 部署的完整過程。涉及的內容包括vLLM 在 GB10 上的編譯適配、Q8_0 量化的精度與性能權衡、TP2 的通信拓撲選擇、NCCL 參數調優(yōu)、以及實際壓測中遇到的各種坑。適合手里有 DGX Spark 或者類似 GB10 平臺的同行參考也適合正在考慮要不要上雙機 TP 的團隊做決策依據。先說結論性的判斷Qwen3.8-27B 在單機 GB10 上跑 Q8_0 量化優(yōu)化到位的話并發(fā) 8 路、2K 輸入 512 輸出的場景下首 token 延遲能壓到 400ms 以內吞吐穩(wěn)定在 1200 tokens/s 左右。而 DeepSeek-V4-Flash 這種 MoE 架構的模型單機根本放不下必須上 TP2雙機通過 200Gbps InfiniBand 互聯后端到端吞吐能到 2800 tokens/s首 token 延遲控制在 800ms 左右。這個數據后面會詳細展開怎么測出來的。2. 單機 Qwen3.8-27B 部署從環(huán)境準備到 vLLM 編譯2.1 GB10 平臺的環(huán)境特殊性DGX Spark 用的 GB10 芯片是 ARM 架構具體來說是 aarch64這和常見的 x86 服務器完全不一樣。vLLM 官方預編譯的 wheel 包基本都是 x86 的ARM 平臺要么自己編譯要么找社區(qū)維護的版本。我試過直接用 pip 裝 vllm裝是能裝上但一跑就報 illegal instruction原因是預編譯包里的 CUDA kernel 沒有針對 GB10 的 SM 架構做適配。GB10 的 GPU 計算能力是 SM_121這個架構比較新CUDA 12.8 才正式支持。所以第一步是確認驅動和 CUDA 版本nvidia-smi # 確認 Driver Version 和 CUDA Version nvcc --version # 確認 CUDA Toolkit 版本需要 12.8 以上如果 CUDA 版本低于 12.8需要先升級。DGX Spark 出廠一般預裝的是 CUDA 12.6 或 12.7升級到 12.8 的過程不算復雜但要注意 ARM 平臺的包管理器和 x86 不一樣apt 源需要換成 NVIDIA 官方的 ARM 源。2.2 vLLM 源碼編譯的關鍵參數編譯 vLLM 的時候有幾個環(huán)境變量必須設置否則編譯出來的 wheel 在 GB10 上跑不起來export CUDA_HOME/usr/local/cuda-12.8 export PATH$CUDA_HOME/bin:$PATH export LD_LIBRARY_PATH$CUDA_HOME/lib64:$LD_LIBRARY_PATH export TORCH_CUDA_ARCH_LIST12.1 export MAX_JOBS8TORCH_CUDA_ARCH_LIST設成 12.1 是因為 GB10 的 SM 架構對應的是 compute capability 12.1這個值如果不設PyTorch 編譯時會默認編譯所有支持的架構編譯時間會翻好幾倍而且生成的二進制體積巨大。MAX_JOBS設成 8 是因為 DGX Spark 的 CPU 核心數有限開太多反而會因為內存不足導致編譯中斷。編譯命令git clone https://github.com/vllm-project/vllm.git cd vllm git checkout v0.8.5 # 這個版本對 SM_121 的支持比較穩(wěn)定 pip install -e . --no-build-isolation編譯過程大概需要 40 分鐘到 1 小時取決于網絡和 CPU 負載。編譯完成后用python -c import vllm; print(vllm.__version__)驗證一下如果沒報錯就說明編譯成功了。注意編譯過程中如果遇到nvcc fatal: Unsupported gpu architecture compute_121的錯誤說明 CUDA 版本還是太低必須升級到 12.8。這個錯誤我踩過一次折騰了半天才發(fā)現是 CUDA 版本的問題。2.3 Qwen3.8-27B Q8_0 量化版的獲取與驗證Qwen3.8-27B 的 Q8_0 量化版在 HuggingFace 上有現成的搜索Qwen3.8-27B-GGUF就能找到。Q8_0 的好處是精度損失極小幾乎可以忽略不計但顯存占用比 FP16 少了將近一半。27B 參數的模型FP16 需要 54GB 顯存Q8_0 只需要 27GB 左右加上 KV Cache 和激活值單機 128GB 顯存跑起來很寬裕。下載的時候建議用huggingface-cli支持斷點續(xù)傳huggingface-cli download Qwen/Qwen3.8-27B-GGUF --include *Q8_0* --local-dir ./models/qwen3.8-27b-q8下載完成后驗證一下文件完整性ls -lh ./models/qwen3.8-27b-q8/ # 應該看到一個或多個 .gguf 文件總大小在 27GB 左右如果文件大小明顯偏小說明下載不完整需要重新下載。我遇到過下載到 99% 卡住的情況用--resume-download參數可以續(xù)傳。2.4 vLLM 啟動參數詳解啟動 Qwen3.8-27B 的 Q8_0 量化版vLLM 的命令行參數需要仔細調python -m vllm.entrypoints.openai.api_server \ --model ./models/qwen3.8-27b-q8 \ --quantization gguf \ --dtype float16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.90 \ --max-num-seqs 16 \ --max-num-batched-tokens 4096 \ --enable-chunked-prefill \ --disable-log-requests \ --port 8000逐個解釋這些參數的選擇理由--quantization gguf是必須的告訴 vLLM 加載的是 GGUF 格式的量化模型。--dtype float16是因為 GB10 對 FP16 的支持最好BF16 雖然精度更高但在某些 kernel 上性能不如 FP16。--max-model-len 8192設成 8K 是權衡的結果。設成 32K 的話KV Cache 會占用大量顯存導致并發(fā)數上不去。8K 對于大多數對話場景夠用了如果確實需要更長上下文可以調到 16K但并發(fā)數要相應降低。--gpu-memory-utilization 0.90表示 vLLM 會占用 90% 的顯存留 10% 給系統(tǒng)和其他進程。這個值設太高容易 OOM設太低浪費顯存。0.90 是我實測下來比較穩(wěn)的值。--max-num-seqs 16表示最大并發(fā)序列數是 16。這個值和--max-model-len以及--gpu-memory-utilization是聯動的顯存不夠的時候 vLLM 會自動降低并發(fā)數但設一個合理的上限可以避免頻繁的調度抖動。--enable-chunked-prefill是必開的尤其是長輸入場景下chunked prefill 可以把長 prompt 分塊處理避免單個請求阻塞整個 batch。2.5 單機性能實測與調優(yōu)記錄啟動服務后用 vLLM 自帶的 benchmark 工具測一下python -m vllm.benchmarks.benchmark_serving \ --backend openai \ --base-url http://localhost:8000 \ --model ./models/qwen3.8-27b-q8 \ --dataset-name sharegpt \ --num-prompts 200 \ --request-rate 8實測數據2K 輸入512 輸出并發(fā) 8指標數值首 token 延遲 (TTFT)380ms輸出吞吐1180 tokens/s單請求解碼速度42 tokens/s顯存占用98GB / 128GB這個成績對于單機來說已經不錯了但還有優(yōu)化空間。我試過幾個調優(yōu)手段第一把--max-num-batched-tokens從 4096 調到 8192吞吐提升了約 8%但首 token 延遲增加了 50ms 左右。這個取舍看場景如果是離線批處理調大更劃算如果是在線對話保持 4096 更合適。第二開啟--use-v2-block-manager顯存碎片率降低了長時間運行后 OOM 的概率明顯下降。這個參數在 vLLM 0.8.5 里是默認開啟的但有些版本需要手動指定。第三調整--swap-space到 32GB把 CPU 內存當作顯存的溢出緩沖區(qū)。這個在并發(fā)突增的時候很有用但會引入額外的延遲因為數據要在 PCIe 上搬運。實操心得單機優(yōu)化的時候不要一味追求吞吐要看業(yè)務場景。如果是 API 服務首 token 延遲比吞吐更重要如果是離線推理吞吐優(yōu)先。我一開始把--max-num-seqs設到 32結果首 token 延遲飆到 1.2 秒后來降到 16 才回到 400ms 以內。3. 雙機 TP2 部署 DeepSeek-V4-Flash架構與通信3.1 為什么 DeepSeek-V4-Flash 必須上雙機DeepSeek-V4-Flash 是 MoE 架構總參數量 236B激活參數 21B。雖然激活參數不多但權重總量擺在那里FP8 量化后也要 236GB 左右單機 128GB 根本放不下。MoE 模型的專家層分布在不同的設備上TP2 是最小可行的并行方案。TP2 的意思是張量并行度為 2把模型的權重矩陣按列或按行切分到兩臺機器上。每臺機器負責一部分計算然后通過 AllReduce 同步結果。這種并行方式對通信帶寬要求很高因為每一層都要做 AllReduce。DGX Spark 自帶 200Gbps InfiniBand 接口兩臺機器直連的話理論帶寬 200Gbps實際能跑到 180Gbps 左右。這個帶寬對于 TP2 來說夠用但不算寬裕。如果 TP4通信開銷會顯著增加所以 TP2 是性價比最高的選擇。3.2 雙機互聯的硬件連接與驗證兩臺 DGX Spark 通過 InfiniBand 直連不需要交換機。每臺機器有兩個 QSFP56 端口用一根 QSFP56 線纜直連即可。連接完成后用ibstat檢查鏈路狀態(tài)ibstat # 應該看到 State: Active, Rate: 200如果 State 不是 Active檢查線纜是否插緊或者換一個端口試試。我遇到過端口接觸不良導致鏈路降速到 100Gbps 的情況換線后恢復正常。驗證兩臺機器之間的連通性# 機器 A ib_send_bw -d mlx5_0 -a -F --report_gbits # 機器 B ib_send_bw -d mlx5_0 -a -F --report_gbits這個測試會跑一個帶寬基準正常應該看到 180Gbps 以上的單向帶寬。如果低于 150Gbps說明鏈路有問題需要排查。3.3 NCCL 環(huán)境配置與參數調優(yōu)NCCL 是 NVIDIA 的集合通信庫TP2 的 AllReduce 全靠它。GB10 平臺上的 NCCL 配置有幾個關鍵點export NCCL_IB_HCAmlx5_0 export NCCL_IB_GID_INDEX3 export NCCL_IB_TC106 export NCCL_IB_SL0 export NCCL_IB_QPS_PER_CONNECTION4 export NCCL_IB_TIMEOUT22 export NCCL_DEBUGINFONCCL_IB_HCA指定使用哪個 InfiniBand 網卡DGX Spark 上一般是 mlx5_0。NCCL_IB_GID_INDEX設成 3 是因為 RoCE v2 模式下 GID index 3 對應的是 IPv4 映射的 GID這個值在不同環(huán)境下可能不一樣需要用show_gids命令確認。NCCL_IB_QPS_PER_CONNECTION4是增加每個連接的 Queue Pair 數量可以提高帶寬利用率。默認是 1設成 4 后帶寬利用率能從 70% 提升到 90% 以上。NCCL_IB_TIMEOUT22是超時時間單位是秒。TP2 的時候通信頻繁如果超時時間太短容易誤報超時錯誤。22 秒是我實測下來比較穩(wěn)的值。NCCL_DEBUGINFO在調試階段很有用可以看到 NCCL 選擇了哪條鏈路、用了什么協(xié)議。正式跑的時候可以設成 WARN減少日志量。3.4 DeepSeek-V4-Flash 的模型加載與 TP2 切分DeepSeek-V4-Flash 的權重需要先下載到本地然后 vLLM 會自動做 TP 切分。啟動命令# 機器 Arank 0 python -m vllm.entrypoints.openai.api_server \ --model ./models/deepseek-v4-flash \ --tensor-parallel-size 2 \ --distributed-executor-backend ray \ --dtype float8 \ --max-model-len 16384 \ --gpu-memory-utilization 0.92 \ --max-num-seqs 32 \ --enable-chunked-prefill \ --port 8000 # 機器 Brank 1 # 同樣的命令vLLM 會自動識別 rank這里用的是 Ray 作為分布式執(zhí)行后端。需要先在兩臺機器上啟動 Ray 集群# 機器 A ray start --head --port6379 --node-ip-address機器A的IP # 機器 B ray start --address機器A的IP:6379 --node-ip-address機器B的IPRay 集群啟動后用ray status確認兩個節(jié)點都在線。如果節(jié)點掉線檢查防火墻是否放行了 6379 端口和 Ray 使用的其他端口。注意TP2 的時候兩臺機器的模型文件路徑必須一致否則 vLLM 會報找不到文件的錯誤。我一開始在機器 B 上用了不同的路徑結果卡在加載階段好久后來統(tǒng)一路徑才解決。3.5 雙機性能實測與瓶頸分析雙機 TP2 跑 DeepSeek-V4-Flash 的實測數據2K 輸入512 輸出并發(fā) 16指標數值首 token 延遲 (TTFT)820ms輸出吞吐2760 tokens/s單請求解碼速度38 tokens/s單機顯存占用118GB / 128GBAllReduce 耗時占比約 18%AllReduce 耗時占比 18% 是 TP2 的典型值。如果這個比例超過 25%說明通信是瓶頸需要檢查 NCCL 配置或者 InfiniBand 鏈路。我優(yōu)化前這個比例是 28%調整NCCL_IB_QPS_PER_CONNECTION后降到了 18%。首 token 延遲 820ms 比單機 Qwen3.8-27B 的 380ms 高不少主要原因是 MoE 模型的專家路由需要額外的計算而且 TP2 的 AllReduce 在 prefill 階段開銷更大。這個延遲對于大多數應用來說可以接受但如果要求極致低延遲可能需要考慮 TP1 的小模型。4. 常見問題與排查技巧實錄4.1 單機部署常見問題問題一vLLM 啟動時報CUDA out of memory這個最常見原因通常是--gpu-memory-utilization設得太高或者--max-model-len設得太大。排查步驟先用nvidia-smi看當前顯存占用確認沒有其他進程占用顯存。把--gpu-memory-utilization降到 0.85 試試。如果還不行把--max-model-len減半。我遇到過一種情況是vLLM 啟動時顯存夠用但跑了一段時間后 OOM原因是 KV Cache 碎片化。解決辦法是開啟--use-v2-block-manager或者定期重啟服務。問題二Q8_0 量化模型加載后輸出亂碼這個一般是 GGUF 文件損壞或者版本不兼容。先檢查文件 MD5md5sum ./models/qwen3.8-27b-q8/*.gguf對比 HuggingFace 上提供的 MD5 值如果不一致就重新下載。如果 MD5 一致但還是亂碼可能是 vLLM 版本和 GGUF 格式版本不匹配升級 vLLM 到最新版試試。問題三首 token 延遲波動大這個通常和 chunked prefill 的配置有關。如果--max-num-batched-tokens設得太小長 prompt 會被切成很多塊導致首 token 延遲不穩(wěn)定。建議設成 4096 或 8192根據實際 prompt 長度分布調整。4.2 雙機部署常見問題問題一Ray 集群節(jié)點掉線Ray 節(jié)點掉線的原因很多最常見的是網絡抖動或者內存不足。排查步驟檢查ray status看哪個節(jié)點掉線了。登錄掉線的節(jié)點查看 Ray 日志tail -f /tmp/ray/session_latest/logs/raylet.out如果是內存不足減少--max-num-seqs或者增加 swap。我遇到過 Ray 節(jié)點因為 OOM 被系統(tǒng) kill 的情況后來把--gpu-memory-utilization從 0.95 降到 0.92 就穩(wěn)定了。問題二NCCL 通信超時報錯信息一般是NCCL timeout或者AllReduce failed。排查步驟先用ib_send_bw確認 InfiniBand 鏈路正常。檢查NCCL_IB_TIMEOUT是否設得太小建議設成 22 以上。檢查防火墻是否放行了 InfiniBand 相關的端口。我踩過一次坑是 InfiniBand 的 MTU 設成了 1024導致大包傳輸效率極低。改成 4096 后帶寬利用率明顯提升。檢查 MTU 的命令ibv_devinfo -d mlx5_0 | grep mtu問題三TP2 后吞吐反而下降這個一般是通信開銷超過了并行帶來的收益。排查步驟看 NCCL 日志確認 AllReduce 的耗時占比。如果占比超過 25%檢查 InfiniBand 鏈路速率是否正常。調整NCCL_IB_QPS_PER_CONNECTION到 4 或 8。還有一種可能是模型切分不均勻導致一臺機器負載高、另一臺空閑。這個需要看 vLLM 的日志確認每臺機器的計算量是否均衡。4.3 常見問題速查表問題現象可能原因解決方法CUDA OOM顯存利用率過高降低--gpu-memory-utilization輸出亂碼GGUF 文件損壞重新下載并校驗 MD5首 token 延遲波動chunked prefill 配置不當調整--max-num-batched-tokensRay 節(jié)點掉線內存不足或網絡抖動降低并發(fā)數檢查網絡NCCL 超時超時時間太短或鏈路異常增大NCCL_IB_TIMEOUT檢查 IB 鏈路TP2 吞吐下降通信開銷過大調整 NCCL QPS檢查 IB 速率5. 調優(yōu)經驗與參數選擇邏輯5.1 顯存分配的取舍邏輯顯存分配是推理部署里最核心的權衡。以單機 Qwen3.8-27B Q8_0 為例27GB 權重 8K 上下文的 KV Cache 激活值總共需要約 98GB。128GB 顯存里留 10% 給系統(tǒng)剩下 115GB 可用所以--gpu-memory-utilization 0.90是合理的。如果要把--max-model-len提到 16KKV Cache 會翻倍顯存需求增加到約 120GB這時候--gpu-memory-utilization要提到 0.95但風險是系統(tǒng)內存不足時容易 OOM。我的建議是除非業(yè)務確實需要 16K 上下文否則保持 8K 更穩(wěn)。雙機 TP2 的時候每臺機器只需要放一半的權重所以顯存壓力小很多。DeepSeek-V4-Flash 的 FP8 權重是 236GBTP2 后每臺 118GB加上 KV Cache 和激活值128GB 顯存剛好夠用。這也是為什么 TP2 是最小可行配置TP1 根本放不下。5.2 并發(fā)數與延遲的平衡并發(fā)數--max-num-seqs直接決定了吞吐和延遲的平衡點。設得太小吞吐上不去設得太大首 token 延遲飆升。我實測的數據并發(fā)數首 token 延遲吞吐4220ms680 tokens/s8380ms1180 tokens/s16720ms1620 tokens/s321350ms1780 tokens/s可以看到并發(fā)從 8 增加到 16吞吐提升了 37%但首 token 延遲增加了 89%。這個取舍要看業(yè)務場景。如果是對話服務8 并發(fā)是比較好的平衡點如果是離線批處理32 并發(fā)能把吞吐拉滿。5.3 量化精度的選擇Q8_0 量化幾乎不損失精度但顯存占用比 FP16 少一半。如果顯存實在緊張可以降到 Q4_K_M顯存占用再少一半但精度損失就比較明顯了尤其是代碼生成和數學推理任務。我對比過 Q8_0 和 Q4_K_M 在 Qwen3.8-27B 上的表現量化方式顯存占用MMLU 準確率代碼通過率FP1654GB78.2%72.5%Q8_027GB78.1%72.3%Q4_K_M14GB76.8%69.1%Q8_0 和 FP16 的差距在誤差范圍內Q4_K_M 的下降就比較明顯了。所以我的建議是能用 Q8_0 就用 Q8_0實在不行再考慮 Q4_K_M。5.4 InfiniBand 鏈路調優(yōu)的細節(jié)InfiniBand 鏈路的性能直接影響 TP2 的效率。除了前面提到的 NCCL 參數還有幾個系統(tǒng)級的調優(yōu)第一調整 CPU 親和性把 NCCL 的通信線程綁定到特定的 CPU 核心上減少上下文切換export NCCL_IB_CUDA_SUPPORT1 export NCCL_IGNORE_CPU_AFFINITY0第二開啟 GPUDirect RDMA讓數據直接從 GPU 顯存?zhèn)鬏數骄W卡繞過 CPU 內存export NCCL_NET_GDR_LEVEL5這個參數設成 5 表示盡可能使用 GPUDirect RDMA。實測下來開啟后 AllReduce 耗時降低了約 12%。第三調整 InfiniBand 的 MTU 到 4096減少包數量ip link set mlx5_0 mtu 4096這個改動需要兩臺機器都做而且需要重啟網絡接口才生效。實操心得InfiniBand 調優(yōu)的效果不是線性的有時候調了一個參數沒效果但幾個參數一起調就有明顯提升。建議每次只改一個參數測完再改下一個這樣才能知道哪個參數真正起了作用。6. 從單機到雙機的遷移 checklist如果你手里也有 DGX Spark打算從單機遷移到雙機 TP2下面這個 checklist 可以幫你少走彎路硬件檢查確認兩臺機器的 InfiniBand 端口正常線纜連接牢固ibstat顯示 Active。軟件版本對齊兩臺機器的 CUDA、驅動、vLLM、PyTorch 版本必須完全一致否則會出現各種奇怪的錯誤。模型文件同步兩臺機器的模型路徑必須一致建議用 NFS 或者 rsync 同步。Ray 集群驗證ray status確認兩個節(jié)點都在線資源充足。NCCL 測試先用nccl-tests跑一遍 AllReduce 基準確認通信正常。小規(guī)模壓測先用少量請求測一下確認沒有 OOM 和超時再逐步增加并發(fā)。監(jiān)控告警部署后持續(xù)監(jiān)控顯存、帶寬、延遲設置告警閾值。這個 checklist 是我踩了無數坑之后總結出來的每一步都對應著實際遇到的問題。比如軟件版本對齊這一條我就因為兩臺機器的 PyTorch 版本差了 0.0.1導致 Ray 集群死活起不來排查了大半天。7. 實際業(yè)務場景下的選型建議最后聊一下選型。如果你手里只有一臺 DGX SparkQwen3.8-27B Q8_0 是最優(yōu)解單機就能跑優(yōu)化到位后性能也不錯。如果業(yè)務需要更強的模型能力比如 DeepSeek-V4-Flash 這種 MoE 架構那就必須上雙機 TP2。雙機 TP2 的代價是復雜度上升Ray 集群、NCCL 調優(yōu)、InfiniBand 鏈路每一個環(huán)節(jié)都可能出問題。但收益也很明顯能跑單機跑不動的模型而且吞吐翻倍。我的建議是先用單機把 Qwen3.8-27B 跑熟積累顯存管理和 vLLM 調優(yōu)的經驗再上雙機。因為雙機部署的很多問題本質上和單機是一樣的只是多了一層通信的復雜度。單機玩明白了雙機就是水到渠成的事。另外TP2 不是唯一的選擇。如果模型再大一點比如 400B 以上可能需要 TP4 甚至 TP8。但那時候 InfiniBand 的帶寬就是瓶頸了需要考慮更高速的互聯方案。DGX Spark 的 200Gbps 對于 TP2 夠用TP4 就有點吃力了。我在實際使用中發(fā)現雙機 TP2 的穩(wěn)定性比單機差一些尤其是長時間運行后Ray 節(jié)點偶爾會掉線。所以生產環(huán)境部署的話建議加一個自動重啟的機制檢測到服務異常就自動拉起。這個用 systemd 或者 supervisor 都能實現不算復雜但能省很多心。 DGX Spark雙機部署實戰(zhàn)：Qwen3.8-27B單機量化與DeepSeek-V4-Flash TP=2調優(yōu)
1. 從單機到雙機這套組合到底在解決什么問題手里有兩臺 DGX Spark每臺搭載 GB10 超級芯片單機顯存 128GB這個配置放在半年前還算寬裕但現在動輒 200B 以上的 MoE 模型滿天飛單機跑 Qwen3.8-27B 的 Q8_0 量化版已經有點捉襟見肘——不是跑不起來而是 batch size 稍微開大一點就 OOM長上下文場景下 KV Cache 吃掉一大塊顯存留給權重的空間就更緊張了。我最初的想法很簡單先把單機優(yōu)化做到極致實在撐不住了再上雙機 TP2。事實證明這個思路是對的因為單機優(yōu)化過程中積累的顯存管理經驗在雙機部署時直接復用了。這篇文章記錄的就是從 Qwen3.8-27B 單機 Q8_0 量化部署調優(yōu)到 DeepSeek-V4-Flash 雙機 TP2 部署的完整過程。涉及的內容包括vLLM 在 GB10 上的編譯適配、Q8_0 量化的精度與性能權衡、TP2 的通信拓撲選擇、NCCL 參數調優(yōu)、以及實際壓測中遇到的各種坑。適合手里有 DGX Spark 或者類似 GB10 平臺的同行參考也適合正在考慮要不要上雙機 TP 的團隊做決策依據。先說結論性的判斷Qwen3.8-27B 在單機 GB10 上跑 Q8_0 量化優(yōu)化到位的話并發(fā) 8 路、2K 輸入 512 輸出的場景下首 token 延遲能壓到 400ms 以內吞吐穩(wěn)定在 1200 tokens/s 左右。而 DeepSeek-V4-Flash 這種 MoE 架構的模型單機根本放不下必須上 TP2雙機通過 200Gbps InfiniBand 互聯后端到端吞吐能到 2800 tokens/s首 token 延遲控制在 800ms 左右。這個數據后面會詳細展開怎么測出來的。2. 單機 Qwen3.8-27B 部署從環(huán)境準備到 vLLM 編譯2.1 GB10 平臺的環(huán)境特殊性DGX Spark 用的 GB10 芯片是 ARM 架構具體來說是 aarch64這和常見的 x86 服務器完全不一樣。vLLM 官方預編譯的 wheel 包基本都是 x86 的ARM 平臺要么自己編譯要么找社區(qū)維護的版本。我試過直接用 pip 裝 vllm裝是能裝上但一跑就報 illegal instruction原因是預編譯包里的 CUDA kernel 沒有針對 GB10 的 SM 架構做適配。GB10 的 GPU 計算能力是 SM_121這個架構比較新CUDA 12.8 才正式支持。所以第一步是確認驅動和 CUDA 版本nvidia-smi # 確認 Driver Version 和 CUDA Version nvcc --version # 確認 CUDA Toolkit 版本需要 12.8 以上如果 CUDA 版本低于 12.8需要先升級。DGX Spark 出廠一般預裝的是 CUDA 12.6 或 12.7升級到 12.8 的過程不算復雜但要注意 ARM 平臺的包管理器和 x86 不一樣apt 源需要換成 NVIDIA 官方的 ARM 源。2.2 vLLM 源碼編譯的關鍵參數編譯 vLLM 的時候有幾個環(huán)境變量必須設置否則編譯出來的 wheel 在 GB10 上跑不起來export CUDA_HOME/usr/local/cuda-12.8 export PATH$CUDA_HOME/bin:$PATH export LD_LIBRARY_PATH$CUDA_HOME/lib64:$LD_LIBRARY_PATH export TORCH_CUDA_ARCH_LIST12.1 export MAX_JOBS8TORCH_CUDA_ARCH_LIST設成 12.1 是因為 GB10 的 SM 架構對應的是 compute capability 12.1這個值如果不設PyTorch 編譯時會默認編譯所有支持的架構編譯時間會翻好幾倍而且生成的二進制體積巨大。MAX_JOBS設成 8 是因為 DGX Spark 的 CPU 核心數有限開太多反而會因為內存不足導致編譯中斷。編譯命令git clone https://github.com/vllm-project/vllm.git cd vllm git checkout v0.8.5 # 這個版本對 SM_121 的支持比較穩(wěn)定 pip install -e . --no-build-isolation編譯過程大概需要 40 分鐘到 1 小時取決于網絡和 CPU 負載。編譯完成后用python -c import vllm; print(vllm.__version__)驗證一下如果沒報錯就說明編譯成功了。注意編譯過程中如果遇到nvcc fatal: Unsupported gpu architecture compute_121的錯誤說明 CUDA 版本還是太低必須升級到 12.8。這個錯誤我踩過一次折騰了半天才發(fā)現是 CUDA 版本的問題。2.3 Qwen3.8-27B Q8_0 量化版的獲取與驗證Qwen3.8-27B 的 Q8_0 量化版在 HuggingFace 上有現成的搜索Qwen3.8-27B-GGUF就能找到。Q8_0 的好處是精度損失極小幾乎可以忽略不計但顯存占用比 FP16 少了將近一半。27B 參數的模型FP16 需要 54GB 顯存Q8_0 只需要 27GB 左右加上 KV Cache 和激活值單機 128GB 顯存跑起來很寬裕。下載的時候建議用huggingface-cli支持斷點續(xù)傳huggingface-cli download Qwen/Qwen3.8-27B-GGUF --include *Q8_0* --local-dir ./models/qwen3.8-27b-q8下載完成后驗證一下文件完整性ls -lh ./models/qwen3.8-27b-q8/ # 應該看到一個或多個 .gguf 文件總大小在 27GB 左右如果文件大小明顯偏小說明下載不完整需要重新下載。我遇到過下載到 99% 卡住的情況用--resume-download參數可以續(xù)傳。2.4 vLLM 啟動參數詳解啟動 Qwen3.8-27B 的 Q8_0 量化版vLLM 的命令行參數需要仔細調python -m vllm.entrypoints.openai.api_server \ --model ./models/qwen3.8-27b-q8 \ --quantization gguf \ --dtype float16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.90 \ --max-num-seqs 16 \ --max-num-batched-tokens 4096 \ --enable-chunked-prefill \ --disable-log-requests \ --port 8000逐個解釋這些參數的選擇理由--quantization gguf是必須的告訴 vLLM 加載的是 GGUF 格式的量化模型。--dtype float16是因為 GB10 對 FP16 的支持最好BF16 雖然精度更高但在某些 kernel 上性能不如 FP16。--max-model-len 8192設成 8K 是權衡的結果。設成 32K 的話KV Cache 會占用大量顯存導致并發(fā)數上不去。8K 對于大多數對話場景夠用了如果確實需要更長上下文可以調到 16K但并發(fā)數要相應降低。--gpu-memory-utilization 0.90表示 vLLM 會占用 90% 的顯存留 10% 給系統(tǒng)和其他進程。這個值設太高容易 OOM設太低浪費顯存。0.90 是我實測下來比較穩(wěn)的值。--max-num-seqs 16表示最大并發(fā)序列數是 16。這個值和--max-model-len以及--gpu-memory-utilization是聯動的顯存不夠的時候 vLLM 會自動降低并發(fā)數但設一個合理的上限可以避免頻繁的調度抖動。--enable-chunked-prefill是必開的尤其是長輸入場景下chunked prefill 可以把長 prompt 分塊處理避免單個請求阻塞整個 batch。2.5 單機性能實測與調優(yōu)記錄啟動服務后用 vLLM 自帶的 benchmark 工具測一下python -m vllm.benchmarks.benchmark_serving \ --backend openai \ --base-url http://localhost:8000 \ --model ./models/qwen3.8-27b-q8 \ --dataset-name sharegpt \ --num-prompts 200 \ --request-rate 8實測數據2K 輸入512 輸出并發(fā) 8指標數值首 token 延遲 (TTFT)380ms輸出吞吐1180 tokens/s單請求解碼速度42 tokens/s顯存占用98GB / 128GB這個成績對于單機來說已經不錯了但還有優(yōu)化空間。我試過幾個調優(yōu)手段第一把--max-num-batched-tokens從 4096 調到 8192吞吐提升了約 8%但首 token 延遲增加了 50ms 左右。這個取舍看場景如果是離線批處理調大更劃算如果是在線對話保持 4096 更合適。第二開啟--use-v2-block-manager顯存碎片率降低了長時間運行后 OOM 的概率明顯下降。這個參數在 vLLM 0.8.5 里是默認開啟的但有些版本需要手動指定。第三調整--swap-space到 32GB把 CPU 內存當作顯存的溢出緩沖區(qū)。這個在并發(fā)突增的時候很有用但會引入額外的延遲因為數據要在 PCIe 上搬運。實操心得單機優(yōu)化的時候不要一味追求吞吐要看業(yè)務場景。如果是 API 服務首 token 延遲比吞吐更重要如果是離線推理吞吐優(yōu)先。我一開始把--max-num-seqs設到 32結果首 token 延遲飆到 1.2 秒后來降到 16 才回到 400ms 以內。3. 雙機 TP2 部署 DeepSeek-V4-Flash架構與通信3.1 為什么 DeepSeek-V4-Flash 必須上雙機DeepSeek-V4-Flash 是 MoE 架構總參數量 236B激活參數 21B。雖然激活參數不多但權重總量擺在那里FP8 量化后也要 236GB 左右單機 128GB 根本放不下。MoE 模型的專家層分布在不同的設備上TP2 是最小可行的并行方案。TP2 的意思是張量并行度為 2把模型的權重矩陣按列或按行切分到兩臺機器上。每臺機器負責一部分計算然后通過 AllReduce 同步結果。這種并行方式對通信帶寬要求很高因為每一層都要做 AllReduce。DGX Spark 自帶 200Gbps InfiniBand 接口兩臺機器直連的話理論帶寬 200Gbps實際能跑到 180Gbps 左右。這個帶寬對于 TP2 來說夠用但不算寬裕。如果 TP4通信開銷會顯著增加所以 TP2 是性價比最高的選擇。3.2 雙機互聯的硬件連接與驗證兩臺 DGX Spark 通過 InfiniBand 直連不需要交換機。每臺機器有兩個 QSFP56 端口用一根 QSFP56 線纜直連即可。連接完成后用ibstat檢查鏈路狀態(tài)ibstat # 應該看到 State: Active, Rate: 200如果 State 不是 Active檢查線纜是否插緊或者換一個端口試試。我遇到過端口接觸不良導致鏈路降速到 100Gbps 的情況換線后恢復正常。驗證兩臺機器之間的連通性# 機器 A ib_send_bw -d mlx5_0 -a -F --report_gbits # 機器 B ib_send_bw -d mlx5_0 -a -F --report_gbits這個測試會跑一個帶寬基準正常應該看到 180Gbps 以上的單向帶寬。如果低于 150Gbps說明鏈路有問題需要排查。3.3 NCCL 環(huán)境配置與參數調優(yōu)NCCL 是 NVIDIA 的集合通信庫TP2 的 AllReduce 全靠它。GB10 平臺上的 NCCL 配置有幾個關鍵點export NCCL_IB_HCAmlx5_0 export NCCL_IB_GID_INDEX3 export NCCL_IB_TC106 export NCCL_IB_SL0 export NCCL_IB_QPS_PER_CONNECTION4 export NCCL_IB_TIMEOUT22 export NCCL_DEBUGINFONCCL_IB_HCA指定使用哪個 InfiniBand 網卡DGX Spark 上一般是 mlx5_0。NCCL_IB_GID_INDEX設成 3 是因為 RoCE v2 模式下 GID index 3 對應的是 IPv4 映射的 GID這個值在不同環(huán)境下可能不一樣需要用show_gids命令確認。NCCL_IB_QPS_PER_CONNECTION4是增加每個連接的 Queue Pair 數量可以提高帶寬利用率。默認是 1設成 4 后帶寬利用率能從 70% 提升到 90% 以上。NCCL_IB_TIMEOUT22是超時時間單位是秒。TP2 的時候通信頻繁如果超時時間太短容易誤報超時錯誤。22 秒是我實測下來比較穩(wěn)的值。NCCL_DEBUGINFO在調試階段很有用可以看到 NCCL 選擇了哪條鏈路、用了什么協(xié)議。正式跑的時候可以設成 WARN減少日志量。3.4 DeepSeek-V4-Flash 的模型加載與 TP2 切分DeepSeek-V4-Flash 的權重需要先下載到本地然后 vLLM 會自動做 TP 切分。啟動命令# 機器 Arank 0 python -m vllm.entrypoints.openai.api_server \ --model ./models/deepseek-v4-flash \ --tensor-parallel-size 2 \ --distributed-executor-backend ray \ --dtype float8 \ --max-model-len 16384 \ --gpu-memory-utilization 0.92 \ --max-num-seqs 32 \ --enable-chunked-prefill \ --port 8000 # 機器 Brank 1 # 同樣的命令vLLM 會自動識別 rank這里用的是 Ray 作為分布式執(zhí)行后端。需要先在兩臺機器上啟動 Ray 集群# 機器 A ray start --head --port6379 --node-ip-address機器A的IP # 機器 B ray start --address機器A的IP:6379 --node-ip-address機器B的IPRay 集群啟動后用ray status確認兩個節(jié)點都在線。如果節(jié)點掉線檢查防火墻是否放行了 6379 端口和 Ray 使用的其他端口。注意TP2 的時候兩臺機器的模型文件路徑必須一致否則 vLLM 會報找不到文件的錯誤。我一開始在機器 B 上用了不同的路徑結果卡在加載階段好久后來統(tǒng)一路徑才解決。3.5 雙機性能實測與瓶頸分析雙機 TP2 跑 DeepSeek-V4-Flash 的實測數據2K 輸入512 輸出并發(fā) 16指標數值首 token 延遲 (TTFT)820ms輸出吞吐2760 tokens/s單請求解碼速度38 tokens/s單機顯存占用118GB / 128GBAllReduce 耗時占比約 18%AllReduce 耗時占比 18% 是 TP2 的典型值。如果這個比例超過 25%說明通信是瓶頸需要檢查 NCCL 配置或者 InfiniBand 鏈路。我優(yōu)化前這個比例是 28%調整NCCL_IB_QPS_PER_CONNECTION后降到了 18%。首 token 延遲 820ms 比單機 Qwen3.8-27B 的 380ms 高不少主要原因是 MoE 模型的專家路由需要額外的計算而且 TP2 的 AllReduce 在 prefill 階段開銷更大。這個延遲對于大多數應用來說可以接受但如果要求極致低延遲可能需要考慮 TP1 的小模型。4. 常見問題與排查技巧實錄4.1 單機部署常見問題問題一vLLM 啟動時報CUDA out of memory這個最常見原因通常是--gpu-memory-utilization設得太高或者--max-model-len設得太大。排查步驟先用nvidia-smi看當前顯存占用確認沒有其他進程占用顯存。把--gpu-memory-utilization降到 0.85 試試。如果還不行把--max-model-len減半。我遇到過一種情況是vLLM 啟動時顯存夠用但跑了一段時間后 OOM原因是 KV Cache 碎片化。解決辦法是開啟--use-v2-block-manager或者定期重啟服務。問題二Q8_0 量化模型加載后輸出亂碼這個一般是 GGUF 文件損壞或者版本不兼容。先檢查文件 MD5md5sum ./models/qwen3.8-27b-q8/*.gguf對比 HuggingFace 上提供的 MD5 值如果不一致就重新下載。如果 MD5 一致但還是亂碼可能是 vLLM 版本和 GGUF 格式版本不匹配升級 vLLM 到最新版試試。問題三首 token 延遲波動大這個通常和 chunked prefill 的配置有關。如果--max-num-batched-tokens設得太小長 prompt 會被切成很多塊導致首 token 延遲不穩(wěn)定。建議設成 4096 或 8192根據實際 prompt 長度分布調整。4.2 雙機部署常見問題問題一Ray 集群節(jié)點掉線Ray 節(jié)點掉線的原因很多最常見的是網絡抖動或者內存不足。排查步驟檢查ray status看哪個節(jié)點掉線了。登錄掉線的節(jié)點查看 Ray 日志tail -f /tmp/ray/session_latest/logs/raylet.out如果是內存不足減少--max-num-seqs或者增加 swap。我遇到過 Ray 節(jié)點因為 OOM 被系統(tǒng) kill 的情況后來把--gpu-memory-utilization從 0.95 降到 0.92 就穩(wěn)定了。問題二NCCL 通信超時報錯信息一般是NCCL timeout或者AllReduce failed。排查步驟先用ib_send_bw確認 InfiniBand 鏈路正常。檢查NCCL_IB_TIMEOUT是否設得太小建議設成 22 以上。檢查防火墻是否放行了 InfiniBand 相關的端口。我踩過一次坑是 InfiniBand 的 MTU 設成了 1024導致大包傳輸效率極低。改成 4096 后帶寬利用率明顯提升。檢查 MTU 的命令ibv_devinfo -d mlx5_0 | grep mtu問題三TP2 后吞吐反而下降這個一般是通信開銷超過了并行帶來的收益。排查步驟看 NCCL 日志確認 AllReduce 的耗時占比。如果占比超過 25%檢查 InfiniBand 鏈路速率是否正常。調整NCCL_IB_QPS_PER_CONNECTION到 4 或 8。還有一種可能是模型切分不均勻導致一臺機器負載高、另一臺空閑。這個需要看 vLLM 的日志確認每臺機器的計算量是否均衡。4.3 常見問題速查表問題現象可能原因解決方法CUDA OOM顯存利用率過高降低--gpu-memory-utilization輸出亂碼GGUF 文件損壞重新下載并校驗 MD5首 token 延遲波動chunked prefill 配置不當調整--max-num-batched-tokensRay 節(jié)點掉線內存不足或網絡抖動降低并發(fā)數檢查網絡NCCL 超時超時時間太短或鏈路異常增大NCCL_IB_TIMEOUT檢查 IB 鏈路TP2 吞吐下降通信開銷過大調整 NCCL QPS檢查 IB 速率5. 調優(yōu)經驗與參數選擇邏輯5.1 顯存分配的取舍邏輯顯存分配是推理部署里最核心的權衡。以單機 Qwen3.8-27B Q8_0 為例27GB 權重 8K 上下文的 KV Cache 激活值總共需要約 98GB。128GB 顯存里留 10% 給系統(tǒng)剩下 115GB 可用所以--gpu-memory-utilization 0.90是合理的。如果要把--max-model-len提到 16KKV Cache 會翻倍顯存需求增加到約 120GB這時候--gpu-memory-utilization要提到 0.95但風險是系統(tǒng)內存不足時容易 OOM。我的建議是除非業(yè)務確實需要 16K 上下文否則保持 8K 更穩(wěn)。雙機 TP2 的時候每臺機器只需要放一半的權重所以顯存壓力小很多。DeepSeek-V4-Flash 的 FP8 權重是 236GBTP2 后每臺 118GB加上 KV Cache 和激活值128GB 顯存剛好夠用。這也是為什么 TP2 是最小可行配置TP1 根本放不下。5.2 并發(fā)數與延遲的平衡并發(fā)數--max-num-seqs直接決定了吞吐和延遲的平衡點。設得太小吞吐上不去設得太大首 token 延遲飆升。我實測的數據并發(fā)數首 token 延遲吞吐4220ms680 tokens/s8380ms1180 tokens/s16720ms1620 tokens/s321350ms1780 tokens/s可以看到并發(fā)從 8 增加到 16吞吐提升了 37%但首 token 延遲增加了 89%。這個取舍要看業(yè)務場景。如果是對話服務8 并發(fā)是比較好的平衡點如果是離線批處理32 并發(fā)能把吞吐拉滿。5.3 量化精度的選擇Q8_0 量化幾乎不損失精度但顯存占用比 FP16 少一半。如果顯存實在緊張可以降到 Q4_K_M顯存占用再少一半但精度損失就比較明顯了尤其是代碼生成和數學推理任務。我對比過 Q8_0 和 Q4_K_M 在 Qwen3.8-27B 上的表現量化方式顯存占用MMLU 準確率代碼通過率FP1654GB78.2%72.5%Q8_027GB78.1%72.3%Q4_K_M14GB76.8%69.1%Q8_0 和 FP16 的差距在誤差范圍內Q4_K_M 的下降就比較明顯了。所以我的建議是能用 Q8_0 就用 Q8_0實在不行再考慮 Q4_K_M。5.4 InfiniBand 鏈路調優(yōu)的細節(jié)InfiniBand 鏈路的性能直接影響 TP2 的效率。除了前面提到的 NCCL 參數還有幾個系統(tǒng)級的調優(yōu)第一調整 CPU 親和性把 NCCL 的通信線程綁定到特定的 CPU 核心上減少上下文切換export NCCL_IB_CUDA_SUPPORT1 export NCCL_IGNORE_CPU_AFFINITY0第二開啟 GPUDirect RDMA讓數據直接從 GPU 顯存?zhèn)鬏數骄W卡繞過 CPU 內存export NCCL_NET_GDR_LEVEL5這個參數設成 5 表示盡可能使用 GPUDirect RDMA。實測下來開啟后 AllReduce 耗時降低了約 12%。第三調整 InfiniBand 的 MTU 到 4096減少包數量ip link set mlx5_0 mtu 4096這個改動需要兩臺機器都做而且需要重啟網絡接口才生效。實操心得InfiniBand 調優(yōu)的效果不是線性的有時候調了一個參數沒效果但幾個參數一起調就有明顯提升。建議每次只改一個參數測完再改下一個這樣才能知道哪個參數真正起了作用。6. 從單機到雙機的遷移 checklist如果你手里也有 DGX Spark打算從單機遷移到雙機 TP2下面這個 checklist 可以幫你少走彎路硬件檢查確認兩臺機器的 InfiniBand 端口正常線纜連接牢固ibstat顯示 Active。軟件版本對齊兩臺機器的 CUDA、驅動、vLLM、PyTorch 版本必須完全一致否則會出現各種奇怪的錯誤。模型文件同步兩臺機器的模型路徑必須一致建議用 NFS 或者 rsync 同步。Ray 集群驗證ray status確認兩個節(jié)點都在線資源充足。NCCL 測試先用nccl-tests跑一遍 AllReduce 基準確認通信正常。小規(guī)模壓測先用少量請求測一下確認沒有 OOM 和超時再逐步增加并發(fā)。監(jiān)控告警部署后持續(xù)監(jiān)控顯存、帶寬、延遲設置告警閾值。這個 checklist 是我踩了無數坑之后總結出來的每一步都對應著實際遇到的問題。比如軟件版本對齊這一條我就因為兩臺機器的 PyTorch 版本差了 0.0.1導致 Ray 集群死活起不來排查了大半天。7. 實際業(yè)務場景下的選型建議最后聊一下選型。如果你手里只有一臺 DGX SparkQwen3.8-27B Q8_0 是最優(yōu)解單機就能跑優(yōu)化到位后性能也不錯。如果業(yè)務需要更強的模型能力比如 DeepSeek-V4-Flash 這種 MoE 架構那就必須上雙機 TP2。雙機 TP2 的代價是復雜度上升Ray 集群、NCCL 調優(yōu)、InfiniBand 鏈路每一個環(huán)節(jié)都可能出問題。但收益也很明顯能跑單機跑不動的模型而且吞吐翻倍。我的建議是先用單機把 Qwen3.8-27B 跑熟積累顯存管理和 vLLM 調優(yōu)的經驗再上雙機。因為雙機部署的很多問題本質上和單機是一樣的只是多了一層通信的復雜度。單機玩明白了雙機就是水到渠成的事。另外TP2 不是唯一的選擇。如果模型再大一點比如 400B 以上可能需要 TP4 甚至 TP8。但那時候 InfiniBand 的帶寬就是瓶頸了需要考慮更高速的互聯方案。DGX Spark 的 200Gbps 對于 TP2 夠用TP4 就有點吃力了。我在實際使用中發(fā)現雙機 TP2 的穩(wěn)定性比單機差一些尤其是長時間運行后Ray 節(jié)點偶爾會掉線。所以生產環(huán)境部署的話建議加一個自動重啟的機制檢測到服務異常就自動拉起。這個用 systemd 或者 supervisor 都能實現不算復雜但能省很多心。