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