• 每台約 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 系統。
  模型能回答，是一個重要里程碑；讓下一位維護者知道它怎麼運作、出了問題怎麼查、更新失敗怎麼回復，才讓這套系統真正具備長期使用的基礎。

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

目前大致硬體規劃如下：

• 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 環境，也歡迎分享實測經驗。

互连：DGX Spark 每台的 ConnectX-7 是 200GbE（QSFP），两台可以直连；4 台就要一台支持 200GbE 的以太网交换机（不是只到 40/100G 的老 QSFP 交换机），配 DAC/AOC。走 RoCEv2 时注意 PFC/ECN 无损配置，否则 NCCL 会退化；用 nvidia-smi topo -m + NCCL all-reduce 实测带宽再放量。接口/线材以官方型号为准，管理网走 1GbE、别和东西向混跑。

别把它当成一个内存池：GB10 的 128GB 统一内存是每节点的，NVLink-C2C 只在芯片内部，跨节点不会合池。4×Spark = 4 个 128GB 节点。70B FP8（~70GB）单节点就放得下；跨节点真正有价值的是超大 MoE、长上下文并行，或每节点独立跑任务。

• 若做 TP=4，200GbE 单口（~25GB/s）在 decode 小 batch 下 all-reduce 延迟占比高，收益有限，优先 pipeline/data/expert 并行。

控制面 DL360 Gen10：合理，API/任务调度放这；模型流量别和 1GbE 管理网混跑。

供电：Spark 单台约 170–240W，4 台加交换机/DL360 整机 1kW 上下。UPS 按实测功率定：把「路由器 + 交换机 + DL360」放 UPS 做优雅关机、Spark 单独分组的思路是对的，别指望一台 UPS 扛全部。先买功率计实测峰值再算容量。

有具体型号（Spark 版本、交换机型号）贴出来，我帮你对端口/线材。