讓 AI 資料中心看得見：模組化設施的 3D 場址探索
2026 年 10 月 26 日 · 閱讀時間 7 分鐘
一個以公開資料為主、前端以 three.js 打造的模組化 AI 資料中心場址模擬器（非官方）。參考 NVIDIA DSX POD 與技嘉 GADU，在瀏覽器中比較不同氣候與規模下的空間、能耗與成本估算，並可匯出 OpenUSD，在 NVIDIA Omniverse 中開啟。
AI 應用快速發展，背後需要大量運算能力。如何更快速地建置 AI 資料中心，正成為 AI 基礎設施發展的重要課題。
10 月 21 日，NVIDIA 執行長黃仁勳在 GTC Berlin 主題演講中介紹了 DSX POD，一種將運算、網路與冷卻設備預先整合至模組化設施中的 AI 資料中心方案，希望縮短現場部署所需的時間。這場演講讓我重新思考一個問題：當 AI 基礎設施能以模組化方式快速擴展時，我們該如何理解它對實際場址的需求？
資料中心的規模經常以 MW 或 GW 表示，但容量數字很難直接呈現設備占用的空間、不同地區的氣候條件，以及能源需求與成本之間的關係。這些問題也牽涉土地、電力與工程等不同面向，讓不同背景的參與者能夠理解彼此的考量，是規劃過程中值得探索的一環。
模組化設計正逐漸成為 AI 資料中心建置的主流方向。除了 NVIDIA 的 DSX POD，技嘉也在今年 COMPUTEX 台北國際電腦展展出了貨櫃式的GADU，把運算、冷卻與配電整合在可運輸的單元中。
因此，我以模組化 AI 資料中心為題，開始了一個探索計畫。我參考 NVIDIA DSX POD 與技嘉 GADU 等基礎設施方案，嘗試製作一個可以在瀏覽器中操作的原型，讓使用者切換不同地區、調整設備配置，並比較空間、氣候、能耗與成本估算的變化。
我選擇用互動式 3D 場址模擬來探索這個問題，並進一步嘗試將模型匯出為 OpenUSD，讓它能在 NVIDIA Omniverse USD Composer 中開啟。過程中，我也開始處理模型配置、資料一致性、效能與匯出驗證等實作問題。
我想探索的是，如何將複雜的規格與數據轉化為更容易理解、操作和比較的體驗，以及如何將這個設計構想實際做成可操作的原型。
以下記錄這次探索的設計思路、實作過程，以及目前仍存在的限制。
從產品問題出發
我希望這個工具能讓使用者直接調整條件，觀察不同選擇帶來的影響，而不必先理解複雜的設備規格或閱讀大量文件。
因此，整個介面圍繞三個主要操作設計：
- 選擇場址：比較不同地區的氣候條件。
- 配置設備：調整 DSX POD 與 GADU 的產品組合和規模。
- 比較結果：透過 3D 場址、能耗估算與成本資訊，理解不同配置的差異。
場址依柯本氣候分類（Köppen climate classification）挑選，涵蓋五種具代表性的氣候：熱帶雨林（柔佛，Af）、熱沙漠（鳳凰城，BWh）、濕潤亞熱帶（達拉斯，Cfa）、溫帶海洋性（都柏林，Cfb）與濕潤大陸性（奧斯陸，Dfb），再加上台灣本地的桃園（Cfa）。使用者可以切換地點和設備規模，查看場地配置如何改變，並比較不同條件下的能源需求與預估成本。
氣候資料也刻意選了較長的區間：2005 到 2024 年共 20 年的逐時資料，橫跨數次聖嬰與反聖嬰循環，包括 2009、2015 與 2023 年的強聖嬰。極端天氣不會每年出現，只看一兩年的平均，容易低估最熱的時刻。因此工具在判斷散熱方式時，除了看 20 年的平均，也看最差的一年：只要有任何一個小時排不掉熱，就會加入輔助冰水機。至於沒有再往更早的年份延伸，是因為氣候持續暖化，較涼的年代反而會讓人低估未來的熱浪。
設計上的重點，是讓 3D 視圖與數據資訊互相補充。模型協助使用者理解空間尺度與設備排列，儀表板則呈現較難單靠視覺判斷的數值。使用者可以在兩者之間切換，不必自行拼湊分散的資訊。
讓 3D 模型成為可操作的介面
3D 在這個專案中不只是展示畫面，也是主要的互動方式。
使用者可以旋轉視角、觀察設備排列，並在調整配置後查看結果。我也特別考量瀏覽器與不同螢幕尺寸的使用情境，讓工具能在桌面與手機上操作。
數位孿生平台裡的完整模型通常很難直接放進網頁。像 Omniverse 這類工具的場景與渲染，需要工作站等級的 GPU 支撐，要放到網頁上多半得在伺服器端渲染再把畫面串流出去，一般瀏覽器與手機很難直接承受。因此前端我選擇用 three.js，搭配簡化過的模型，在使用者自己的瀏覽器中渲染，完整的模型結構則留給 OpenUSD 匯出。這樣不需要安裝任何軟體，手機也能直接開啟；渲染的工作由使用者自己的裝置負擔，網站本身只需要提供靜態檔案，不必為每位訪客準備一台 GPU 伺服器。整個場景的模型檔加起來約 200 KB，載入也相對輕量。
這部分需要在視覺呈現、互動反應與效能之間取得平衡。設備數量增加後，如果每個物件都各自進行完整的繪製與更新，操作體驗便容易受到影響。因此，實作過程也包含對場景呈現方式與渲染效能的調整。
畫面中也加了一些微動態，例如散熱模組上方上升的熱氣，以及設備上閃爍的指示燈，讓場址看起來是一座正在運轉的設施。為了不讓這些效果拖累效能，我沒有把它們放進 3D 場景裡逐幀計算，而是疊在 3D 畫面上方的一層網頁元素：熱氣是幾顆預先畫好的柔邊光點，指示燈是小光點，動畫只改變位置與透明度，交給瀏覽器的合成器處理。3D 場景本身只在視角移動或配置改變時才重新繪製，畫面靜止時就不再運算；這些效果該出現在畫面上的哪個位置，也只在鏡頭移動時重新計算，而且只顯示離鏡頭最近的一部分。因此動畫可以持續播放，裝置卻不必一直重繪整個場景。
對我而言，這是很有意思的一次探索：3D 模型不一定只能存在於專業建模軟體裡，也可以成為一般使用者透過瀏覽器就能操作的產品介面。
從場址探索延伸到 OpenUSD
另一個目標，是讓模型不只停留在瀏覽器中。
OpenUSD 提供一種描述與組織 3D 場景的方式，讓不同物件與相關資料能以結構化形式組合，並延伸到其他 3D 工具與工作流程。
因此，我將匯出功能納入產品流程，讓使用者可以把目前的場址配置輸出成 USD 檔案，再於 NVIDIA Omniverse 的 USD Composer 中開啟。
這也讓我重新思考產品的交付形式。除了在介面中呈現結果，能否讓使用者把資料與模型帶到下一個工作環境，同樣會影響這個工具的實際用途。
我完成了 USD 匯出流程，並確認產出的檔案可以在 USD Composer 中開啟，也通過 Omniverse Asset Validator 的檢查。這代表目前的檔案結構與基本匯出流程符合相關工具的檢查要求，至於模型是否符合實際工程需求，仍需要另外驗證。
讓資料與模型保持一致
這個原型同時涉及場址配置、設備規格、氣候資料與計算結果。當同一份配置需要在不同環境中呈現時，如何確保數據與模型彼此一致，是我在實作中需要處理的問題。
我建立了基本的自動化檢查，確認不同配置下的設備數量與相關結果能夠對應，也測試了多種規模，避免只在少數案例中看起來正常。
過程中也遇到過設備排列與數量計算不一致的問題。這提醒我，即使畫面看起來合理，也不能直接假設背後的資料正確。對於需要同時呈現視覺與數據的產品，驗證流程也是產品品質的一部分。
目前的限制
這個專案目前是一個用來探索場址配置、能耗與成本關係的互動式原型，並非正式的工程模擬系統。
能耗與成本結果依據目前採用的資料、假設與簡化模型估算。實際資料中心還會受到設備規格、負載變化、冷卻設計、電價與建置條件等因素影響，因此目前的數值適合用於初步比較，不應直接作為工程決策依據。
同樣地，OpenUSD 匯出與驗證通過，也不等於模型已具備完整的工程資訊或數位孿生能力。這次完成的是一條可操作、可匯出並能在指定工具中開啟的原型工作流程，後續仍有許多可以深化的方向。
從設計到實作
這次專案讓我有機會把過去累積的經驗，延伸到 3D、空間資料與新的技術工作流程。
從使用者如何理解資訊、如何調整條件，到如何比較結果與延續使用模型，每個環節都需要同時考量產品體驗與技術限制。建築與都市設計、BIM 的背景幫助我理解空間和模型，而過去五年的產品設計經驗則讓我持續從操作流程、資訊層次與使用情境檢視整體方案。
我也在過程中學習 OpenUSD，並運用 AI 輔助開發完成原型實作。對我而言，這不只是一次 3D 技術的嘗試，也是一個把新技術轉化為可操作產品的練習。
專案成果：瀏覽器端互動式 3D 場址模擬、場址與設備配置、能耗及成本估算，以及可於 NVIDIA Omniverse USD Composer 開啟的 OpenUSD 匯出流程。
接下來，我希望繼續探索 3D 模型、資料與互動介面之間的關係，並思考如何讓這類工具更容易理解、比較與延伸到實際工作流程。