返回 Dr. KiWi

歷史週報 / Founder Weekly archive

排算力,也要排電力

依作者核准的歷史週報內容轉載;批次日期不代表社群平台實際發表日期。

研發方向:仍在技術與合作評估階段,尚未部署,也不是可對客戶承諾的功能。

作者
Steve
期號日期
官網刊出
原始社群發表日期
未確認
研發方向 / R&D concept排算力,也要排電力Schedule compute. Schedule power.Compute ↔ Power · concept only
重新設計的概念封面,不是原始圖卡。
這週在討論 AI-EDC 的技術方向時,我一直在想: 我們忙著幫算力找電,有沒有可能,也讓算力配合電力安排? 我們正在評估一個研發方向:把不同資料中心的算力工作排程,和能源調度放在一起考慮。目前還在技術與合作評估階段,沒有完成實際驗證,也還不是可以對客戶承諾的功能。 但把問題拆開之後,我覺得這件事值得做。 過去談資料中心,通常先問需要多少 MW、能簽多少 PPA、儲能要裝多大。真正開始看工作負載,才會發現,同樣是用電,每一項工作的條件差很多。 即時推論有延遲要求,不能因為電價高就叫客戶等一下。GPU 訓練能不能延後,要看任務期限、進度保存與恢復的成本,以及設備是否有空檔。跨站移轉,還有資料搬移和資安限制。 UPS 留給緊急狀況的備援容量,也不能直接拿去算交易收益。 這些條件沒有確認清楚,模型算出再漂亮的節費數字,我都不會放心。 如果省了電費,卻讓客戶的工作逾時,那不是最佳化,只是把成本轉到另一個地方。 所以我對 KiWi 下一階段 AI-EDC 的要求很明確:先把服務承諾與不能動的負載定義清楚,再確認剩下多少彈性可以運用。 能源端要看懂 15 分鐘用電、PPA 供應與儲能狀態;算力端要知道工作期限、設備條件與服務品質。兩邊不能各算各的,最後才發現彼此做不到。 接下來真正要花時間的,是資料能不能取得、誰有控制權、指令怎麼執行,以及結果怎麼驗證。 這些工作不太適合拿來做漂亮的簡報,但少做一項,現場就可能多一個問題。 創業做到現在,我越來越在意這種接口。很多機會不是來自再多一個功能,而是把原本各自運作的兩個系統,接到真的能一起工作。 排算力,也要排電力。 但順序不能錯:先守住算力服務,再談電網彈性。 讓每一度電,都更有智慧。 Steve #KiWiNewEnergy #AIEDC #AI算力中心 #儲能 #PPA #智慧能源 #能源管理 #MakingEverykWhSmarter

外部連結為作者個人頁面,並非原始貼文連結。