工作室規劃：4 台 DGX Spark 本地 AI 叢集架構，並預留擴充至 8 台

[Sin Yang Wu]

目前工作室的本地 AI 運算環境，第一階段規劃會先以 4 台 NVIDIA DGX Spark 建置，之後再逐步擴充到 8 台。

目前大致硬體規劃如下：

• NVIDIA DGX Spark ×4
• HPE DL360 Gen10 ×1
  • ESXi 8.0
  • 作為管理主機、API、Agent、監控與服務入口
• MikroTik CRS804-4DDQ-hRM ×1
  • 4×400GbE QSFP56-DD
  • 作為 Spark 節點間高速交換機
• QSFP-200G CU 0.5M DGX Spark 專用 DAC ×4
• 一般管理網路另外使用 RJ45 Ethernet
• UPS 預計 2～3 台，較偏向最後採 3 台分組

第一階段 4 台 Spark 的高速網路會先這樣接：

CRS804 Port 1 → 200G → Spark 1
CRS804 Port 2 → 200G → Spark 2
CRS804 Port 3 → 200G → Spark 3
CRS804 Port 4 → 200G → Spark 4

也就是每台 DGX Spark 各使用一條 200G QSFP DAC 接到 CRS804。

管理網路與 AI Fabric 會分開：

一般 Ethernet：
筆電 / OpenCode / DL360 / Spark 管理介面

200GbE Fabric：
DGX Spark 1～4 CRS804

DL360 主要負責：

• API Gateway
• Agent / Task Management
• Monitoring
• VM
• 自動化
• 模型服務管理

Spark 則專心負責模型推論與 distributed inference。

UPS 目前比較傾向使用 3 台分組：

UPS-A：

• Spark 1
• Spark 2

UPS-B：

• Spark 3
• Spark 4

UPS-C：

• DL360
• CRS804
• Router / Management Switch

這樣停電或單組 UPS 異常時，不會一次把整個控制面和所有 Compute Node 一起帶走，也比較方便之後做自動安全關機。

後面如果擴到 8 台 DGX Spark，目前不打算換 CRS804。

CRS804 每個 400G QSFP56-DD Port 可以拆成 2×200G，所以未來會把現在 4 條單路 200G DAC 改成：

400G QSFP56-DD → 2×200G QSFP56 breakout DAC/AOC

拓撲會變成：

Port 1
├─ 200G → Spark 1
└─ 200G → Spark 2

Port 2
├─ 200G → Spark 3
└─ 200G → Spark 4

Port 3
├─ 200G → Spark 5
└─ 200G → Spark 6

Port 4
├─ 200G → Spark 7
└─ 200G → Spark 8

也就是：

4 個 400G Port
→ 拆成 8 路 200G
→ 對應 8 台 DGX Spark

所以 4 台升級成 8 台時，主要變動會是：

• 新增 Spark 5～8
• 更換成 4 條 400G → 2×200G breakout 線
• CRS804 不需要更換
• 重新調整 RouterOS Port Breakout
• 重新跑 NCCL / AllReduce / AllGather
• 重新驗證 distributed inference 效能
• UPS 與電源迴路再依實際功耗重新規劃

目前模型方向會以 DeepSeek V4.1 Flash 這類大型模型為主，之後會實測 TP、PP、EP 等不同並行方式，不會單純假設 TP=4 或 TP=8 就一定最快。

目前策略還是：
先把 1 台跑通 → 4 台成叢集 → 實測穩定後，再慢慢補 UPS、儲存、監控、電力與其他設備。

設備不打算一次全部買滿，會先把核心 AI Fabric 與模型服務搭起來，再依實際需求逐步補強。

如果有人實際使用過 CRS804-4DDQ-hRM 搭 NVIDIA ConnectX-7 / DGX Spark，尤其是 200G、400G breakout、RoCE、NCCL 或 8-node 環境，也歡迎分享實測經驗。

[soop ladios]

集結眾人之力, 我現在手上有16台 GB10 , 兩台CRS804. 配置如下:
glm 5.3 => 8台, ctx 500K, DCP8, 實際使用單流30-40 toks, 八條同時打 60-120 tok/s. 8台用400G=>2x200G接在CRS804 4個port
glm 5.3 flash => 4台, ctx 500K, 實際使用單流60-80 toks, 八條同時打有兩百多吧,有點忘了. 這四台是用400G=>4x100G接在CS804的一個port.
deepseek v4 flash-vision-exp => 2台對接, ctx 500K, 單流50-70 toks , 多流忘了
qwen 3.8 flash next => 2台對接, ctx 391K, 單流60-80 tok/s , 多流忘了
以上都是TP, decode速度是平常使用的印象, 應該差不多是這樣. pp速度就1000 tok/s 到 3000 tok/s不等,平常緩存命中都在98%以上, 其中較慢的glm 5.3還有做nvme KV cache, 所以pp不是很在意.
網路拓樸簡單粗暴, 10G口都接到lab網路, 另外一台小電腦跑litellm管理跟分流這些模型, 方便維護以及修理一些小問題.
關於你的問題:
4 台 Spark 使用 QSFP 高速交換機互連，有哪些拓撲或設定細節容易忽略？

1. 機器插上QSFP線之後要斷電在開, 我遇過熱差拔後throughput只剩3G
2. 每個port有兩個interface, 每個interface 100G, 如果一個port要跑足200G, 必須使用2 rail用到兩個interface. 不過那也沒有必要,我實測模型在跑的時候,實測頻寬沒有超過100G, 所以我第二台CRS804就用100G去接,這樣就可以擴充到16台

管理網路和節點高速網路分開規劃，是否有建議的做法？
看需求吧, 我是簡單可用就好.

DL360 Gen10 作為 ESXi 管理主機與 API 服務入口，應如何安排網路與 VM 角色？
沒在用, 我是用litellm提供所有api接口

UPS 如何按實測負載安排供電分組、續航與安全關機流程？
沒裝UPS, 只有remote power control. 主機到貨後須確定他插電是否立即開機, 沒有就到BIOS去設定

智慧插座若用於單台設備故障後遠端重啟，有哪些額定規格或安全注意事項？
沒有. 可以設定模型開機自啟動.

若之後擴到 8 台，交換機、線材、供電與叢集軟體方面有哪些限制要先留意

1. 如果最終目標是八台,直接買四條400G=>2x200G就好,不用買單條200G的線, 效果是一樣的
2. 線材接頭很多種, switch端跟GB10端是不一樣的, 我買的是https://www.naddod.com/products/32709.html

[Sin Yang Wu]

從四台 DGX Spark 到自己的 AI 服務：一套 DeepSeek 叢集的建置實錄
把四台電腦接起來，下載模型，再按下啟動——原本以為，架設自己的 AI 服務大概就是這樣。
真正動手之後才發現，模型只是其中一部分。網路、驅動、容器、通訊函式庫、遠端管理、API，以及日後如何更新和還原，每一個環節都會影響整套系統能不能穩定運作。
這次專案的目標，是讓四台 NVIDIA DGX Spark 共同執行 DeepSeek-V4.1-Flash，提供統一的 API，接入 OpenCode，並留下可以交接、維護與重建的文件。
一路從設備連線做到模型回應，過程跨越夜間，也累積了不少值得記錄的經驗。
一、先把目標定清楚：四台共同服務一個模型
這套系統不是四台各自執行一個完整、獨立的 AI 服務。
實際採用的是 SGLang、TP4 與 EP1 配置。TP4 讓模型運算分散到四台機器的 GPU，由 Spark01 作為統一的 API 入口，其餘節點共同參與推論。
雖然一開始也討論過 vLLM，最後是依照參考專案採用 SGLang 的部署方式。
另一項重要決定，是讓每台機器都保有完整的本機模型檔案：

• 每台約 476 GiB。
• 包含 48 個模型權重分片。
• 四台都完成檔案雜湊驗證。
  本機完整副本可以減少載入模型時對共享儲存的依賴，也讓各節點的檔案版本更容易核對。不過，推論是否有效率，仍然取決於 GPU、記憶體、通訊與軟體配置，不能只靠「模型都有放好」來判斷。
  二、三種網路，各自負責不同工作
  這次建置最需要釐清的事情之一，就是管理網路和模型通訊網路的差別。
  系統主要分成三個用途。
  管理 LAN 負責 SSH、Docker 控制，以及部分叢集啟動協調。目前管理介面協商為 1 Gb/s。
  Tailscale 提供跨地點的遠端管理通道。之後換一台管理電腦，只要具備適當的網路與憑證權限，就能接手維護。
  DAC 高速網路 則負責節點之間的模型通訊。四台以 DAC 線直連成環：
  Spark01 → Spark02 → Spark03 → Spark04 → Spark01。
  這個高速環沒有使用高速交換器，四條連線各自配置獨立網段，採固定 IP 與 MTU 9000，不在高速介面上設定預設閘道。
  因此，遠端管理走 Tailscale，不代表模型資料也要繞進 VPN。把用途分清楚，後續排錯才不會混在一起。
  三、200 Gb/s 是連線速率，不是實測成績
  四條已使用的高速連線都協商為 200 Gb/s，但這不等於實際程式可以直接跑滿 200 Gb/s。
  本次逐條連線測試的結果是：
  測試項目 本次實測範圍
  TCP 吞吐量 約 98.1～111 Gb/s
  RoCE RDMA Write 約 99.39～111.62 Gb/s

RDMA 測試使用固定的訊息大小、佇列數與測試時間，確認四條直接連線都能正常傳輸。
這些數據證明高速路徑可以工作，但它們不是 NCCL 集合通訊成績，也不是模型生成速度。完整判斷效能，還需要往上測到實際推論。
這次也再次體會到：看見介面顯示「200G」，只是驗收的開始。
四、真正耗時間的，是各層之間的相容性
建置過程並不是一次成功。
曾遇到套件管理程序卡住，導致安裝一直等待鎖定；也碰到第三方套件來源的簽章問題。Tailscale 從暫時啟動切換到系統服務時，也需要確認服務設定與登入狀態是否銜接正確。
模型叢集啟動後，還遇到 RDMA 記憶體註冊錯誤。
這類問題不能只看「網路線有沒有亮」。必須逐層核對：

1. 系統與核心狀態。
2. GPU 驅動及網卡韌體。
3. 網路介面、IP、MTU 與 RoCE GID。
4. NCCL 函式庫與修補版本。
5. 容器環境及推論參數。
6. 四個節點是否真正完成協同啟動。
   經過修正與必要的重啟驗證後，四台推論容器都進入健康狀態，API 也能正常回應。
   重要的經驗是：遇到安裝或服務卡住，要先確認正在執行的程序及其狀態，不能靠刪除鎖檔、重複執行安裝，或隨意終止程序來碰運氣。
   五、先留下基準，再談優化
   服務能啟動之後，下一步才是效能調整。
   本次保留原始 EP2 配置作為基準，再與調整後的 EP1 配置比較。在相同測試條件下，得到以下結果：
   項目 原始配置 優化配置 提升
   單路文字生成 54.21 tokens/s 71.20 tokens/s 約 31.3%
   單路程式碼生成 89.69 tokens/s 110.82 tokens/s 約 23.6%
   64K 合成輸入 prefill 3,804.85 tokens/s 5,013.90 tokens/s 約 31.8%

這些數字有明確的適用範圍：它們來自本次固定題目與參數的測試，不是所有使用情境的保證。
也不是每個指標都變好。例如，單路文字測試的首個 token 延遲中位數，從約 188.74 毫秒增加到 225.81 毫秒。生成吞吐量提升，同時存在延遲上的取捨。
此外，這批效能數據是在後續加入語言政策之前取得；目前版本仍需要在相同條件下重新測量，才能建立完整的新基準。
六、讓模型接入實際工作流程
完成叢集只是第一步，接下來要讓它真正能用。
這套服務提供 OpenAI 相容 API，讓 OpenCode 透過統一的模型端點連線。API 金鑰與 SSH 金鑰分開管理，不寫進公開文件，也不直接放在可攜式明文資料夾。
本次功能驗收包含：

• 一般對話、多輪歷史與串流輸出。
• 工具呼叫及結構化 JSON 輸出。
• 圖片辨識與 OCR。
• OpenCode 的檔案讀寫、編輯與受限指令測試。
• 長上下文檢索。
  預先定義的 API 驗收項目通過 17 項。不過，通過功能測試只代表這些測試路徑可用，不代表模型永遠回答正確。
  在另一組 29 題品質檢查中，結果是 27 題通過。把未通過項目留下來，才能作為後續調整與回歸測試的依據。
  PDF 能讀，但要說清楚怎麼讀
  目前驗證成功的 PDF 流程，是先在本機將頁面轉成圖片，並擷取可用的文字，再交給模型處理。
  這與「API 原生接受 PDF 檔案」是兩件事。
  實測已確認模型可以讀取轉換後的 PDF 頁面，包括表格、文字，以及沒有文字層的圖像內容；但不能因此把服務標示成支援所有原生 PDF 輸入。
  語言規則放在生成前
  為了讓不同 API 客戶端有一致的預設語言，本次也在伺服器的 Chat Completions 對話編碼流程加入政策：
  預設使用台灣繁體中文，明確要求英文時則使用英文；程式碼、路徑及必要的原文內容保持正確。
  這是生成前的提示政策，不是修改模型權重，也不是輸出完成後再翻譯，因此仍需要持續驗證，不能視為百分之百的語言保證。
  七、花了多久？有紀錄的才寫成數字
  這個專案從設備連線、帳號設定，一路進行到模型部署、效能調整與文件整理。
  但早期操作沒有留下完整起訖時間，因此目前無法精確計算總建置工時。
  能明確確認的測試時間包括：
• EP2 基準測試：約 4 分 14 秒。
• EP1 基準測試：約 3 分 20 秒。
• 約 104 萬輸入 tokens 的單次檢索測試：約 5 分 25 秒；其中包含快取重用。
  這些都是特定測試的耗時，不能拿來代表模型下載、安裝、除錯或整個專案花費的時間。
  為了讓後續紀錄更完整，管理入口已加入執行收據。透過入口執行的動作，會保存開始時間、結束時間、耗時與結果；入口以外的人工操作則需要另外補記。
  八、把成果留下來，才能持續維護
  最後交付的不只是一個正在回應的 API。
  專案已整理成一份可攜式管理包，包含：
• 36 頁建置與維運手冊。
• 整體服務、高速接線與建置流程三張架構圖。
• 管理網路及高速網路設定說明。
• 安裝、更新、調適、回復與移機 SOP。
• 效能與功能驗收證據。
• 12 階段建置進度，以及後續待辦順序。
  大型模型權重與 Docker 映像沒有直接塞進一般文件壓縮包，因此這不是完整的離線安裝映像，也還不是經過空白機演練的一鍵重建工具。
  接下來仍有明確工作：完善開機後推論服務恢復、更新加密備份、確認管理權限與位址配置，並補上 NCCL 及長時間負載測試。
  這次建置帶來的最大改變，是把四台設備整理成一套有入口、有實測、有文件，也有待辦清單的 AI 系統。
  模型能回答，是一個重要里程碑；讓下一位維護者知道它怎麼運作、出了問題怎麼查、更新失敗怎麼回復，才讓這套系統真正具備長期使用的基礎。

[soop ladios]

附帶一提, 同時使用了約一個月的deepseek v4.1 flash跟glm 5.3 flash之後, 還是決定把deepseek v4.1 flash撤掉, 他的能力夠, 但起伏很大, 也常常進入loop循環, glm 5.3相對穩定, 能力也強.

[Sin Yang Wu]

感謝分享，這點很重要。能力上限跟長期穩定性確實要分開看。我這次主要記錄四台 DGX Spark 從建置、部署到串接驗證的過程，目前還不能用短期測試代表長期使用表現。
方便分享你遇到 loop 的主要情境嗎？是寫程式、工具呼叫，還是一般對話？另外是在什麼工具或框架、使用哪些參數？這樣比較容易對照，後續評估也應該把任務完成率、循環頻率與需要人工介入的次數一起算進去，而不只看生成速度。

[soop ladios]

@Sin-Yang-Wu 主要是在長時間debug任務中, 連續數小時到數天之後, 有可能出現一直重覆輸出相同片段的情況, 通常loop到auto compact完就會恢復, 如果沒在看可能不會發現.
任務流程trace code, 部署, 測試, 驗證, debug, trace code ... 循環直到測試通過為止. 寫程式、工具呼叫，一般對話都有包含在整個流程中. 框架應該是vllm吧, 使用pi agent, claude code, codex cli等工具接入. temp設0.4有改善但無法根除, reasoning是設成high.
除了loop問題之外, 在長時間的工作流程中發現他的智力有時候會有忽高忽低的現象,這是體感, 沒有確切證據.

[Sin Yang Wu]

此主題已被删除！

[Sin Yang Wu]

[张光璞]

这样摆放是不是散热不够好。我看到一个方案是4机直接垂直放在小米空气净化器上的。

[Rex Fan]

4台可以试试 GLM 5.3 - EXL3 @ 2.75 BPW 精度量化的模型，用新的TensorFold 推理框架，可以做到1m上下文 + 40tps（仅单流）或者100k上下文+100tps（C4聚合）。预填充似乎还有点慢，但相当可用了。社区还在优化，应该很快可以跑更快。然后社区有一个新的dgx spark 的系统，可以多从老黄那边弄2gb统一内存出来，增加上下文或者降低OOM的风险
@Sin-Yang-Wu

[soop ladios]

4台我也推glm 5.3 flash . 現在我裝的是https://github.com/tonyd2wild/GLM-5.3-Flash-NVFP4-1M-KV-4x-DGX-Spark?utm_source=chatgpt.com
稍做修改可以到CTX 500K , KV cache token 4605K, prefill 2700~2900, 單流decode 60~80, 四條輕鬆突破200. 速度比deepseek v4.1快, 能力也高上不少(個人觀點).

[terry]

我帮你把帖子修改了下，主贴图文并茂，否则很多人不看的。