4 x Tesla V100 32G, Maya-DS4, DeepSeek-V4.1-Flash-1017 EXL3 2.9bpw, decode 37 tok/s, prefill 640 tok/s, 部署,調優與避坑紀錄
-
DeepSeek-V4.1-Flash-1017 在4台GB10上表現不錯, 又看到DGX論壇上EXL3 2.9bpw量化品質似乎不差, 所以想在我的v100 32G x 4上面試試, 跑了一陣子感覺還可以, 就是prefill有點慢, 尚待優化. 以下為部署,調優與避坑紀錄.
主機環境：AMD EPYC 7K62 48-Core / 96-Thread，128GB RAM，4 × NVIDIA Tesla V100-SXM2 32GB
1. 模型與運行設定
項目 正式線上生產配置 (Production) 備註說明 模型全名 DeepSeek-V4.1-Flash-1017 EXL3 2.9bpw含 Engram 1017 專家分片 模型權重路徑 ~/deepseek-v4.1-flash-1017/packs/maya-ds4EXL3 量化權重 引擎軟體 maya-ds4(專案路徑:project-maya)版本: 1.1.41 (Git commit bcf379f)上下文上限 (Context) 500,000 tokens ( --max-context 500000)實測至 497,714 tokens 100% 針檢索通過 預設取樣設定 temperature=0.4,reasoning_effort="high"支援 Thinking 思考鏈輸出 DSpark 配置 DSpark OFF ( --dspark none)釋放 GPU 1 被夾困的 7.5GB VRAM GPU 分割與專家配置 GPU 0–3 各承載 28.6~28.7 GB 專家（共 15,467 專家在 VRAM） GPU VRAM 餘裕 ~400 MiB 主機 RAM 專家 (Direct RAM) 98.4 GB 常駐 Anonymous Heap ( --mmap-experts off)DS4_REQUIRE_ALL_RAM=1,DS4_COPY_GB=90Prefill Chunk 大小 4096 tokens ( --prefill-chunk 4096)對齊 kVlRows=4096流水線最優塊Attention 核心 DS4_ATTN_V7=0SM70 架構最優穩定 Tensor Core Attention 資源守護底線 MemAvailable >= 15.0 GiB,Engine VmSwap = 0500K Prefill 期間允許暫降至 10.0 GiB
2. Repo 更新與核心優化
A. 上游 v1.1.41 程式碼同步
- 上游基礎版本：同步自官方
origin/main（commit9030b73，tagv1.1.41）。 - 合併分支：
integration/sync-upstream-v1141-> Fast-Forward 合併至production/upstream-20261027。 - 主要增強：
- 啟用 Volta Tensor Core WMMA GEMM 矩陣運算核心（
EXL3_WMMA_V70）。 - 升級 Prefill DMA 排程與批次流式傳輸機制。
- 保留本地多 GPU 區塊取消界限守護（
ds4_chunk_cancel::Boundary），與上游yield_to/run_yields協同運作。 - 保留本地自研之零命中跳過邏輯，與上游
DS4_SKIP_UNPICKED實現雙軌相容。
- 啟用 Volta Tensor Core WMMA GEMM 矩陣運算核心（
B. Zero-hit Expert Transfer Skipping (
DS4_SKIP_ZERO_EXPERTS=1)- 核心機制：在 Prefill 階段，各層於 GPU 完成 Top-K Routing 後，檢查
cur_bounds[v+1] == cur_bounds[v]。若命中 Token 數為 0，則跳過該冷專家的 PCIe DMA 傳輸。 - 傳輸節省：
- 32K Prefill：節省 66.9% ~ 73.2% 的 H2D 傳輸量。
- 128K Prefill：節省 65.6% ~ 70.3% 的 H2D 傳輸量。
- 500K Prefill：節省 82.9% 的 H2D 傳輸量（GPU 0/1 傳輸量從 3.03TB 驟降至 503GB）。
- 品質保證：不修改 EXL3 權重、不修改 Top-K 結果、不漏算任何有效 Token，貪婪輸出與原始版本維持 Bit-Exact 完全一致。
C. Direct RAM 啟動 Compaction 防護
針對 Direct RAM（98.4GB）啟動時容易因 Linux 核心記憶體碎片引發
migrate_longterm_unpinnable_folios導致長達 10 分鐘卡頓的問題，實施兩項核心修復：- Buddyinfo 自適應 THP 檢測 (
ds4_os.hpp)：
動態檢查/proc/buddyinfo。僅在系統擁有足夠的連續 2MB 頁框時才啟用MADV_HUGEPAGE；若碎片化嚴重則自動回退為標準 4KB 頁框，徹底杜絕核心逐頁遷移與 Compaction 重試停頓。 - 8 執行緒並行
cudaHostRegister(ds4_model.cu)：
將 61 個層的 Host Memory Pinned 註冊改為 8 條執行緒並行執行，加速完成 DMA 映射。
3. 最新實測效能與驗證資訊
A. Cold Prefill & Decode 效能矩陣
評測維度 原始基準 (Skip OFF) 前期版本 (Skip ON) 最新 v1.1.41 (Skip ON) 較前期提升 較原始基準提升 32K Cold Prefill (Tok/s) 429.0 tok/s 486.5 tok/s 605.9 tok/s +24.5% 
+41.2% 32K TTFT 首字延遲 73.30 s 64.66 s 52.21 s -12.45 s -21.09 s 32K Decode (Tok/s) 34.60 tok/s 34.71 tok/s 37.39 tok/s +7.7% +8.1% 32K Needle 正確性 100% 100% 100% (Pass) 一致 一致 128K Cold Prefill (Tok/s) 462.0 tok/s 500.0 tok/s 640.3 tok/s +28.1% +38.6% 128K TTFT 首字延遲 281.95 s 260.59 s 203.90 s -56.69 s -78.05 s 128K Decode (Tok/s) 29.80 tok/s 30.22 tok/s 37.13 tok/s +22.9% +24.6% 128K Needle 正確性 100% 100% 100% (Pass) 一致 一致 B. 功能與穩定性測試
- 單元測試套件：
python3 -m unittest tools.test_ds4_pack serve.test_server：145/145 測試全部通過（耗時 35.3s）。
- Thinking 思考鏈推理：
- 驗證 Prompt：
How many letters in the word "apple"? Output reasoning and answer. - 3.77s 內順利回傳
reasoning_content與標準解答，思考鏈標籤未發生截斷或錯位。
- 驗證 Prompt：
- Tool Calling 結構化調用：
- 驗證 Prompt：
What is the stock price of NVDA?+lookup_stocktools schema。 - 成功命中並回傳標準 OpenAI tool_calls JSON 結構：
{'name': 'lookup_stock', 'arguments': '{"ticker":"NVDA"}'}。
- 驗證 Prompt：
- 長上下文能力：
- 通過 500,000 邊界保護測試（
<= 500000正常運作，> 500000正常回傳 400 錯誤）。
- 通過 500,000 邊界保護測試（
4. 異常調查：長 Prefill 原因與修復 (Prefill Cache Stall / Long Prefill Fix)
A. 問題現象
在生產環境運行多輪 Agent / OpenCode 對話時，發現每次對話都會出現長達 60~90 秒的長 Prefill（如 54K、57K、64K、69K Tokens），日誌顯示：
ds4: took back a 22090-token shared start (0.01 s) maya ds4 serve: prompt 69438 tokens = 22090 reused + 47348 read in 89230 ms (530.6 tok/s)Prefix Cache 始終只能重用前 22,090 tokens（System Prompt），後續對話增量（20,000 ~ 47,000 tokens）每一輪都在重新進行 Cold Prefill。
B. 根因分析 (Root Cause)
- 觸發旗標殘留 (
/tmp/maya_always_cold_prefill)：- 20:03 執行的
scripts/run_upstream_v1141_verification.py測試腳本在跑純冷啟動壓測時寫入了/tmp/maya_always_cold_prefill，但結束時未清理。 scripts/restart_production.sh先前重啟步驟中亦未清理/tmp/maya_*旗標。
- 20:03 執行的
- C++ 引擎行為：
- 於
src/ds4/ds4_main.cpp第 1400 行：if (access("/tmp/maya_always_cold_prefill", F_OK) == 0 || (std::getenv("DS4_ALWAYS_COLD_PREFILL") != nullptr && std::atoi(std::getenv("DS4_ALWAYS_COLD_PREFILL")) != 0)) { m.reset(); } - 生產環境每當接收到任何請求時，該檔案強制觸發
m.reset()，將當前對話的動態 KV Cache 完全清空。 - 引擎只剩下開機時常駐於 RAM 的 22,090-token System Prompt（
prefixesRAM Tier），因此日誌只能「took back a 22090-token shared start」，導致後續數萬 tokens 每次均被迫重算。
- 於
C. 修復措施與驗證
- 立即移除殘留旗標：
- 刪除
/tmp/maya_always_cold_prefill。
- 刪除
- 自動化重啟防禦加固：
- 更新 [
scripts/restart_production.sh]，在重啟生產服務前強制執行rm -f /tmp/maya_always_cold_prefill /tmp/maya_skip_zero_experts。 - 更新 [
scripts/run_upstream_v1141_verification.py]，加入finally區塊與啟動/結束清理，確保測試旗標絕不遺留。
- 更新 [
- 線上驗證實測：
- 旗標移除後，第 1 個請求（70,965 tokens）：
prompt 70965 tokens = 69438 reused + 1527 read in 7739 ms (197.3 tok/s)
重用率瞬間升至 97.8%，Prefill 時間由 89.2 秒銳減至 7.7 秒！ - 第 2 個請求（72,493 tokens）：
prompt read: 1180 tokens in 4.9 s，重用逾 71,313 tokens，耗時僅 4.9 秒。 - 驗證 Prefix Cache 機制 100% 正常，長 Prefill 現象徹底解除。
- 旗標移除後，第 1 個請求（70,965 tokens）：
- 上游基礎版本：同步自官方
-
-
-
-
@Lei-Gao 我的四張卡排列比較特殊, GPU0/GPU1是外接顯卡鄔, 接pcie switch佔一條pcie插槽, 有nvlink.
GPU2/GPU3是分開插在兩條PCIE, 所以走的是TP2, PP2. 我請Gemini小弟解釋一下:DeepSeek-V4.1-Flash-1017 NVLink 拓撲與實質效益分析報告
主機環境: AMD EPYC 7K62 48C/96T, 128GB RAM, 4 × NVIDIA Tesla V100-SXM2 32GB
模型版本:DeepSeek-V4.1-Flash-1017 EXL3 2.9bpw + Engram 1017
推論引擎:project-maya / maya-ds4(--tp 2 --layer-split auto)
結論
NVLink 在本機推論此模型時有局部的實質加速作用，但不是決定整體端到端效能的核心瓶頸（對端到端速度的實質貢獻估計約在 5% ~ 10% 左右）。
一、 實體硬體拓撲現況（關鍵前置事實）
經由
nvidia-smi topo -m與nvidia-smi nvlink -s檢測，本機 4 張 V100 的互聯是不對稱的：GPU 配對 實體連線方式 頻寬 狀態 GPU 0 
GPU 1NVLink 2.0 (5 條 bonded, NV5) ~128.9 GB/s Active (運作中) GPU 2 GPU 3PCIe / Host Bridge (NODE) ~12–15 GB/s (PCIe Gen3) No NVLink (全數 Inactive) GPU 0/1 GPU 2/3PCIe Host Bridge (NODE) ~12–15 GB/s (PCIe Gen3) 跨節點走 PCIe
二、 模型並行架構下的通訊分佈
目前的服務配置為
--tp 2 --layer-split auto（即 TP=2 + PP=2）：- Stage 0（前 20 層，Layers 0..19）：切在 GPU 0 與 GPU 1（TP=2）。
- Stage 1（後 20 層，Layers 20..39 + LM Head）：切在 GPU 2 與 GPU 3（TP=2）。
- PP 流水線交接：Stage 0 算完後的 Hidden States 跨卡傳給 Stage 1。
三、 NVLink 在哪裡有「實質作用」？
- 加速 Stage 0（Layers 0..19）的 TP All-Reduce：
- 每一層的 MLA (Multi-head Latent Attention) 投影與 MoE 共享專家（Shared Expert）輸出，都需要在 TP 兩卡間做 All-Reduce 聚合。
- GPU 0 GPU 1 走 NVLink 5 條通道，延遲極低（< 10 µs），通訊耗時基本能被計算完全重疊（Overlap）。
- 避免 Stage 0 的 PCIe 總線爭搶（Bus Contention）：
- 由於 GPU 0 與 GPU 1 的 TP 溝通走的是專用 NVLink 實體鏈路，不會佔用主機板的 PCIe 通道，使得這兩張卡的 PCIe 頻寬能 100% 留給 CPU 串流專家資料。
四、 為什麼 NVLink「無法成為全局決定性因素」？
- 核心瓶頸在 CPU GPU 冷專家動態串流（走 PCIe Gen3）：
- 模型總共有約 92.4 GB ~ 100 GB 的冷專家權重 駐留在 CPU Host RAM，推論時需要根據動態路由經由 PCIe 串流到 GPU（即日誌中的
CPU lane ~22%~28% experts）。 - NVLink 只能加速 GPU GPU 互聯，無法加速 CPU RAM GPU 的 H2D 傳輸。這部分的頻寬上限受死在 PCIe Gen3 x16（約 12–13 GB/s），是整個系統最大的延遲來源。
- 模型總共有約 92.4 GB ~ 100 GB 的冷專家權重 駐留在 CPU Host RAM，推論時需要根據動態路由經由 PCIe 串流到 GPU（即日誌中的
- 木桶效應：Stage 1（GPU 2 GPU 3）沒有 NVLink：
- 後半段 20 層的 TP=2 在 GPU 2 與 GPU 3 上執行，由於這兩張卡之間沒有啟用 NVLink，它們的 All-Reduce 只能走 PCIe (NODE)。
- 流水線（Pipeline）的速度由最慢的一環決定，Stage 1 在 PCIe 上的通訊延遲，會抵消掉 Stage 0 NVLink 帶來的部分增益。
- PP 傳輸的資料量極小：
- Stage 0 傳給 Stage 1 只需要傳遞單個 Token 的活化向量（Hidden States，大小僅約數 KB），在 PCIe 上傳輸耗時僅需幾微秒，NVLink 在此處毫無顯著差別。
五、 總結評估
- 實質效益：有，它確保了前半部模型（GPU 0/1）通訊不打架、低延遲，估計貢獻了約 5% ~ 10% 的端到端效能。
- 全局瓶頸：目前推論速度（Decode ~35–45 tok/s）的主導瓶頸是 CPU 記憶體頻寬與 PCIe Gen3 串流速度，而非 GPU-to-GPU 的通訊頻寬。
-
@Lei-Gao 我的四張卡排列比較特殊, GPU0/GPU1是外接顯卡鄔, 接pcie switch佔一條pcie插槽, 有nvlink.
GPU2/GPU3是分開插在兩條PCIE, 所以走的是TP2, PP2. 我請Gemini小弟解釋一下:DeepSeek-V4.1-Flash-1017 NVLink 拓撲與實質效益分析報告
主機環境: AMD EPYC 7K62 48C/96T, 128GB RAM, 4 × NVIDIA Tesla V100-SXM2 32GB
模型版本:DeepSeek-V4.1-Flash-1017 EXL3 2.9bpw + Engram 1017
推論引擎:project-maya / maya-ds4(--tp 2 --layer-split auto)
結論
NVLink 在本機推論此模型時有局部的實質加速作用，但不是決定整體端到端效能的核心瓶頸（對端到端速度的實質貢獻估計約在 5% ~ 10% 左右）。
一、 實體硬體拓撲現況（關鍵前置事實）
經由
nvidia-smi topo -m與nvidia-smi nvlink -s檢測，本機 4 張 V100 的互聯是不對稱的：GPU 配對 實體連線方式 頻寬 狀態 GPU 0 GPU 1NVLink 2.0 (5 條 bonded, NV5) ~128.9 GB/s Active (運作中) GPU 2 GPU 3PCIe / Host Bridge (NODE) ~12–15 GB/s (PCIe Gen3) No NVLink (全數 Inactive) GPU 0/1 GPU 2/3PCIe Host Bridge (NODE) ~12–15 GB/s (PCIe Gen3) 跨節點走 PCIe
二、 模型並行架構下的通訊分佈
目前的服務配置為
--tp 2 --layer-split auto（即 TP=2 + PP=2）：- Stage 0（前 20 層，Layers 0..19）：切在 GPU 0 與 GPU 1（TP=2）。
- Stage 1（後 20 層，Layers 20..39 + LM Head）：切在 GPU 2 與 GPU 3（TP=2）。
- PP 流水線交接：Stage 0 算完後的 Hidden States 跨卡傳給 Stage 1。
三、 NVLink 在哪裡有「實質作用」？
- 加速 Stage 0（Layers 0..19）的 TP All-Reduce：
- 每一層的 MLA (Multi-head Latent Attention) 投影與 MoE 共享專家（Shared Expert）輸出，都需要在 TP 兩卡間做 All-Reduce 聚合。
- GPU 0 GPU 1 走 NVLink 5 條通道，延遲極低（< 10 µs），通訊耗時基本能被計算完全重疊（Overlap）。
- 避免 Stage 0 的 PCIe 總線爭搶（Bus Contention）：
- 由於 GPU 0 與 GPU 1 的 TP 溝通走的是專用 NVLink 實體鏈路，不會佔用主機板的 PCIe 通道，使得這兩張卡的 PCIe 頻寬能 100% 留給 CPU 串流專家資料。
四、 為什麼 NVLink「無法成為全局決定性因素」？
- 核心瓶頸在 CPU GPU 冷專家動態串流（走 PCIe Gen3）：
- 模型總共有約 92.4 GB ~ 100 GB 的冷專家權重 駐留在 CPU Host RAM，推論時需要根據動態路由經由 PCIe 串流到 GPU（即日誌中的
CPU lane ~22%~28% experts）。 - NVLink 只能加速 GPU GPU 互聯，無法加速 CPU RAM GPU 的 H2D 傳輸。這部分的頻寬上限受死在 PCIe Gen3 x16（約 12–13 GB/s），是整個系統最大的延遲來源。
- 模型總共有約 92.4 GB ~ 100 GB 的冷專家權重 駐留在 CPU Host RAM，推論時需要根據動態路由經由 PCIe 串流到 GPU（即日誌中的
- 木桶效應：Stage 1（GPU 2 GPU 3）沒有 NVLink：
- 後半段 20 層的 TP=2 在 GPU 2 與 GPU 3 上執行，由於這兩張卡之間沒有啟用 NVLink，它們的 All-Reduce 只能走 PCIe (NODE)。
- 流水線（Pipeline）的速度由最慢的一環決定，Stage 1 在 PCIe 上的通訊延遲，會抵消掉 Stage 0 NVLink 帶來的部分增益。
- PP 傳輸的資料量極小：
- Stage 0 傳給 Stage 1 只需要傳遞單個 Token 的活化向量（Hidden States，大小僅約數 KB），在 PCIe 上傳輸耗時僅需幾微秒，NVLink 在此處毫無顯著差別。
五、 總結評估
- 實質效益：有，它確保了前半部模型（GPU 0/1）通訊不打架、低延遲，估計貢獻了約 5% ~ 10% 的端到端效能。
- 全局瓶頸：目前推論速度（Decode ~35–45 tok/s）的主導瓶頸是 CPU 記憶體頻寬與 PCIe Gen3 串流速度，而非 GPU-to-GPU 的通訊頻寬。
@soop-ladios 感谢您的耐心讲解。您这个混合的架构理解起来还真的有点绕。我本来就简单计算4x32 = 128GB， 一部分offload到CPU走PCIe。实际情况比这个复杂了。 V100 有那种4卡和8卡NVlink的可能瓶颈会更少吧。不过这个就不是垃圾佬的范畴了。现在V100 32GB的卡价格也炒上去了，我还是耐心等AI泡沫破了看看有没有机会捡到A100 A200。哈哈有点白日梦。 因为我入门比较晚，没有大佬们的硬件玩具现在捡了一张V100 16GB，一张P100 16GB 跑跑边缘小模型做写vision UD， 小UD LLM, qWen image 2.1生图之类的边缘玩意了。 保持关注~ 再次感谢！
