AI 基礎設施 · 多租戶算力平台 · 導入服務
AI 資料中心與企業算力的
規劃、建置與營運服務。
本公司提供策略規劃、架構設計、系統整合、多租戶控制平面建置、計量與帳務機制，以及事故處理與維運交接等完整服務，協助企業將 AI 專案自試點階段推進至正式營運。
01產業現況
企業對 AI 的投入持續擴大，落地執行的能力仍待補強。
依人工智慧基金會調查，台灣企業的 AI 化指數一年之內自 36.77 分上升至 46.32 分。成長主要來自使用人數的增加，核心流程的實際改變仍相當有限。
6.6%
已將 AI 整合至核心流程的企業
其餘多數仍處於工具試用階段
61.8%
AI 使用行為發生於組織治理範圍之外
使用紀錄與成本歸屬均待建立
29.17
人才策略構面得分，為六項構面中最低
44.7% 的企業尚未建立 AI 培訓計畫
資料來源：人工智慧基金會（AIF）《2026 台灣產業 AI 化大調查》
算力基礎設施面臨的問題更為具體。
可用算力來自五項機制的系統支撐：使用權限、配額上限、當期用量、成本歸屬與故障處理。五者到位之後，機房方能回答最基本的成本歸屬問題：本月成本由哪一部門、哪一專案、哪一次訓練所產生。
02服務定位
本公司承接 AI 導入的最後一哩。
AI 專案能否落地，關鍵多在於診斷完成、工具就位之後，是否有一個明確的單位承接後續實作。
策略顧問
提出診斷後即行交棒
提供路線圖、成熟度評估與投資試算，交付成果止於文件層級。實作階段的風險由客戶自行承擔。
技術供應商
提供工具後即行交棒
提供 GPU、叢集、模型服務與監控平台等單項產品。將其整合為可營運、可計費、可查核的系統，通常不在合約範圍內。
睿算
承接至系統正式上線
本公司提供架構設計、系統整合、租戶隔離、法遵稽核、計量帳務、事故處理流程與團隊交接等服務，將專案自試點推進至正式營運，並完成維運能力移交。
本公司專注於系統整合與營運能力建置。交付成果為一套客戶得以自行營運的系統，並包含維持其運作所需的文件、測試與人員訓練，營運能力完整留在客戶端。
03導入層級
依專案規模，提供三種層級的導入方案。
本公司以三個層級對齊專案期待、投入人力與時程。分級依據為專案跨越的組織單位數量；跨越的單位越多，關鍵瓶頸越常落在組織協調。
單一流程優化
適用於單一部門、單一流程與單一明確指標的情境。導入期 8 至 12 週可見成果，風險可控，適合作為導入起點並建立內部參考案例。
跨部門流程改善
涉及兩個以上單位，牽動資料歸屬與 KPI 分配。技術難度中等，主要工作在於權責界定與介面協商。
全企業層級轉型
涵蓋共用算力、統一的資料與模型治理，以及成本分攤機制。此層級須以基礎設施為前提，否則各專案將重複建置。
04AI 資料中心
多租戶 AI 資料中心平台
本平台為全企業層級轉型所需的基礎設施，亦為睿算的主力產品。透過單一控制平面，使多個租戶與多類工作負載共用同一批 GPU 資源，並同時管理隔離、配額、計量與稽核。
核心設計原則
首要交付成果為控制平面。平台管理員、租戶管理員、開發者、NOC、財務與稽核等六種角色，均須能於平台中完成各自作業。後端引擎日後得予替換，控制平面則建議一次到位。
五層執行底座：自機房設施至自動化營運
所有服務均運行於同一套五層底座，由下而上依序為機房設施、實體伺服器、資源池、工作排程、監控與自動化營運。各層級具備獨立的職責、指標與運作規則。
第5層 · 監控與自動化營運
- 職責
- 接收服務指標與事件、收斂告警、執行閉環自動化與值班流程
- 指標
- 流程面：事故回應時間、修復時間、告警噪音比、自動化成功率
- 不變式
- 每項自動化動作均須留存「觀察 → 判斷 → 核准 → 執行 → 驗證」的完整紀錄，並支援回放
七類可交付服務
七類服務的性質差異甚大，惟共用同一套身分、計量、事件與基礎設施。每次請求先由租戶目錄解析租戶、服務方案、部署單元與隔離政策，再由各服務策略組成工作規格，交付對應的介面卡執行。
| 服務 | 跨越層級 | 核心執行鏈 | 計量單位 |
|---|---|---|---|
| AI 模型訓練與推論 | 資源池 → 監控營運 | 租戶與配額判定 → Kueue／Volcano／Slurm → vLLM／SGLang | GPU 時數、Token 數、首字延遲 |
| HPC | 實體伺服器 → 監控營運 | 實體主機基線 → Slurm／MPI → Lustre | 節點時數、佇列等待 |
| IaaS | 機房設施 → 監控營運 | 電力額度判定 → Ironic／OpenStack／Kubernetes | vCPU 時數、儲存量、頻寬 |
| 資料處理與 ETL | 資源池 → 監控營運 | 物件儲存與資料表格式 → Airflow／Argo → Spark／Ray | 掃描位元組、任務時數 |
| 邊緣 AI | 實體伺服器 → 監控營運 | 零接觸供裝 → K3s／KubeEdge → 推論執行期 | 裝置數、上線時數 |
| 安全與模型保護 | 實體伺服器 → 監控營運 | 機密運算 → 模型加密與簽章 → 存取稽核 | 受保護模型數、稽核事件 |
| 自動化管理 | 機房設施 → 監控營運 | 訊號收斂 → 處置流程控制器 → 介面卡致動 | 事件數、人工介入率 |
四項共用介面
控制平面提供四項介面，七類服務共用同一組。容許差異之處僅有兩項：工作規格的組成方式，以及介面卡對後端的轉譯方式。
租戶識別介面（ITenantContext）
解析租戶、服務方案、部署單元與隔離政策
共用之後，租戶解析維持單一套邏輯，權限判定的正確性只需驗證一次。
配額政策介面（IQuotaPolicy）
配額、優先權與預算判定
共用之後，配額得以跨服務加總，租戶用量維持在單一上限之內。
計量介面（IMetering）
用量紀錄統一進帳
共用之後，帳單得以完整對帳，單一租戶的總支出隨時可查。
事故介面（IIncident）
事件規格化、去重與派送
共用之後，同一次故障收斂為一則事故，值班路徑維持一致。
隔離等級採光譜式設計
標準隔離與高隔離為同一套平台的兩種服務方案，控制平面與 API 完全一致，差異僅在隔離深度。升級與否亦採逐層決定。常見組合為資源池以上維持標準隔離，實體伺服器與機房設施採專屬配置，因法規要求多落於實體層。
| 層級 | 標準隔離 | 高隔離 | 升級時機 |
|---|---|---|---|
| 第5層 監控與自動化營運 | 以租戶標籤過濾的服務指標與事故；共用告警路由 | 專屬監控儀表板組織；獨立告警路由與升級通報 | 租戶需自有值班流程，或事故資訊不得與他人呈現於同一介面 |
| 第4層 工作排程與資源調度 | 共用叢集佇列、配額與優先權，與其他租戶公平共享 | 專屬佇列與保留容量；群組排程與拓樸保證 | 訂有明確的完工時間承諾，或訓練工作需多節點同時啟動 |
| 第3層 資源池與供裝 | 命名空間與網路政策；資料庫共用結構描述 | 專屬節點池或叢集；每租戶獨立的虛擬網路與網段 | 法規不允許資料與運算與他人共用同一實體節點 |
| 第2層 實體伺服器與韌體 | 共用節點池，清理後再移交下一租戶 | 專屬裸機，不與他人輪替；韌體版本鎖定並留存稽核證據 | 須證明該硬體未經他人使用，或需固定韌體版本 |
| 第1層 機房設施與電力 | 共用機櫃的電力額度，依配額分攤可用容量 | 專屬機櫃與電力配額；獨立冷卻與供電迴路 | 用電量足以影響鄰櫃，或合約載明供電可用度承諾 |
!各層級的資源、事件與用量均須可追溯至租戶識別碼。
跨租戶操作僅得經由明確授權的平台層級權限執行，且該操作本身留存稽核紀錄。租戶識別碼為所有資料表、事件與計量記錄的必要欄位，由系統於查詢層強制帶入。
!運算層不得僅以命名空間作為隔離手段。
Kubernetes 的命名空間提供邏輯邊界；安全邊界則由網路層與主機層隔離提供，因同一台主機上的容器共用作業系統核心。高隔離方案兩者兼備，並將控制平面與租戶資料平面分離。
計量與帳務：以用量紀錄為共同基準
GPU、Token、儲存、網路、電力與事故處理成本，均以不可修改的用量紀錄入帳，再依版本化價格計算。營運與財務因而共用同一套數字。
同一事件僅入帳一次
每筆用量以「來源系統＋資源類別＋計量項目＋來源單號」四項組成唯一識別。同一筆用量重送十次，仍僅入帳一次。
三項時間分別記錄
計量時間、接收時間與結算時間各自獨立。延遲抵達的資料依關帳政策計入下一期，或另開更正單，歷史紀錄維持原狀。
價格表採版本化管理
調價時建立新版本並標註生效區間。任何一期帳單均得依當期價格版本重算，結果一致。
GPU 時數的分母先行界定
名目容量、已配置容量、實際執行、有效產出、扣除電力限制後的容量，為五項不同數字，各自對應不同的計價情境。界定清楚後，利潤與帳單即可逐筆對得起來。
用量以更正事件沖銷
用量紀錄一經接收即定版，後續調整一律以更正單沖銷。關帳快照寫入防竄改儲存，供後續稽核比對。
事件管理與自動化
本子系統的核心價值在於訊號收斂，以及使自動化於可控範圍內執行；發送通知僅為其中最基本的一環。
告警與事故須分離
告警為訊號層的收斂單位，依去重鍵合併；事故為人員與自動化的處置單位，得包含多則告警。兩者混用的徵狀，為同一次故障開出數十件事故，或事故已關閉而底層告警仍持續發出。
通知回呼僅得送出動作請求
通知回呼的職責限於送出動作請求。處置流程控制器接手後驗證允許清單、租戶與部署單元範圍、冷卻時間及當前狀態，再以短期憑證呼叫介面卡。生產環境的控制權因此始終保留在受稽核的路徑上。
恢復以重新觀察服務指標為準
動作執行完畢後重新觀察指標，確認恢復始得以同一去重鍵關閉。此步驟為狀態流程的必經轉移。
自動化先行建議模式
先以建議模式上線，確認判斷正確後再切換為實際執行，並具備遲滯、冷卻、下限、人工核准與完整稽核。此設計使自動化的影響範圍始終維持在可預期的區間內。
實體網路基礎設施
軟體平台將機房設施層呈現為「可用電力」單一數字，該數字的來源為實體網路的工程設計。本公司同時承接這一段的設計與圖說交付。
- 需求
- 設計（AutoCAD）
- BOM
- 施工
- 竣工圖
- DCIM
- 可用電力容量
- 工作排程配置
四類設計交付物
機櫃立面圖、光纖幹線單線圖、纜線排程表與 BOM。每次建置或擴充均須產出上述四類，設計階段即可完整涵蓋施工所需資訊。
BOM 為設計完整性的檢查表
BOM 每一列均對應一張圖號，圖面與採購清單逐項對齊，設計缺口於採購階段即可發現。
五項驗證規則
光模組數量為埠數乘二，並含 A／B 雙路徑；光功率預算須逐鏈路驗算，SR4 於 OM4 上限 100 公尺；交付時光纖使用率不得超過 60%；備品率常用件 5 至 10%、長前置期件 25%。
路徑分離須於施工階段落實
兩條路徑全程使用獨立線槽，雙路徑的可用度保證方能成立。此項列入竣工驗收。
交付里程碑
自建模至正式營運分為五個階段，各階段均訂有可驗收的成果。每一階段須通過租戶隔離與計量一致性的自動測試，方得進入下一階段。
- 0UML 與基線2 週領域詞彙、UML 圖說、架構決策紀錄、租戶隔離威脅模型、介面資訊架構
- 1多租戶 UI 與控制平面8 週登入、租戶、專案、角色、資源目錄、配額、工作負載基本流程
- 2計量與營運8 週GPU 與 Token 計量、帳單預覽、服務水準目標、告警、事故與稽核
- 3多引擎與自動化10 週Kubernetes／Slurm／推論介面卡、資源預約、建議模式自動化營運
- 4生產化8–12 週HA、DR、效能、資安、金流、專屬租戶與正式營運
05實施方法
四階段實施方法，各階段均訂有明確交付成果。
每一階段均訂有具體產出。階段結束時，客戶將取得可獨立審查、亦可移交他人接續的交付成果。
診斷
盤點現有工作流、資料資產與算力現況，辨識價值密度最高的環節。交付：現況架構圖、瓶頸清單與價值排序。
排序
選定 2 至 3 個使用情境，將成功標準訂為可量測的驗收條件。交付：使用情境規格、驗收條件與 ADR。
建置
執行系統整合、租戶隔離、計量接線、法遵稽核與值班流程建立。交付：可運行的系統、契約測試與操作手冊。
規模化
自試點推進至生產環境，包含 HA、DR、效能調校、成本模型與團隊交接。交付：正式營運環境，以及具備自主維運能力的團隊。
06服務對象
服務對象為 AI 資料中心營運商，以及自建算力的大型企業。
兩類客戶所面對的技術問題本質相同：一批昂貴且供給受限的 GPU 資源，須同時服務多個互不信任的使用者，且每一度電與每一個 Token 均須可歸屬。差異僅在租戶為外部客戶或內部單位。
對象一
AI 資料中心營運商
對外銷售算力的機房、電信業者、雲服務商與 SPV。租戶為付費客戶，帳單精確度與隔離證明直接影響營收與合約風險。此類客戶需要一套得以開立帳單、通過稽核並對外承諾 SLA 的控制平面。
對象二
自建算力的大型企業
製造、金融、醫療、研究機構與政府單位。租戶為內部事業單位與研究團隊，核心問題在於共用 GPU 時的分配公平性、優先權判定與成本分攤，以及稽核時能否證明資料未跨部門流出。
台灣的算力建置規模已有明確數字
303 → 468 MW
台灣資料中心裝置容量
2026 至 2031 年，年複合成長率 9.09%
450 MW
台灣 AI 資料中心規模（2029 年推估）
國家科學及技術委員會推估
US$1.6B
台灣資料中心市場規模（2030 年）
2025 年為 US$810M，年複合成長率 14.6%
資料來源：Mordor Intelligence《Taiwan Data Center Market》、國家科學及技術委員會
服務項目
本公司提供下列十項服務，以可交付項目計價並逐項驗收。服務區分為兩類：面向租戶的營運側服務，支撐帳單開立與對外 SLA 承諾；面向機房的平台側服務，支撐同一批 GPU 資源安全地提供予多個客戶。
營運側｜面向租戶
租戶開通與配額管理
核心提供自助申請、服務方案選擇、配額核發與預算上限設定。開通時程由數週縮短至數小時，各步驟均留存紀錄。
算力計費與帳單
就 GPU 時數、Token 數、儲存量、網路與能耗分別計價。價格採版本化管理，任何一期帳單均得重算出相同結果。
工作負載提交與排程可見性
提供 Console、SDK 與 API 三種入口。佇列位置、預估等待時間、預估成本與遭阻擋的原因均明確顯示。
SLA 與租戶狀態頁
提供 SLO、降級策略與事故時間軸。細節僅對受影響租戶開放，平台端則檢視彙總資料，租戶身分維持隔離。
隔離證明與稽核報表
自共用命名空間至專屬實體主機，各級別均得產出可提交法遵與客戶的隔離證據與清除證明。
平台側｜面向機房與 NOC
容量與電力規劃
核心建立電力、冷卻、空間與纖數四個維度的容量模型，以 DCIM 為單一真相來源。竣工圖回寫流程亦納入交付範圍。
排程與資源池治理
提供公平共享、優先權、群組排程與拓樸感知放置。電力上限自機房設施層傳遞至排程決策，使工作配置於供電充裕的機櫃。
事故收斂與值班
建立訊號去重、事故分組、升級政策與標準處置程序，將數百則告警收斂為少數事故，使值班人員得以有效處理。
閉環自動化營運
先以建議模式驗證判斷正確，再切換為實際執行。具備遲滯、冷卻、下限與人工核准，決策過程支援回放。
裸機生命週期與退租清理
涵蓋供裝、韌體基線與健康檢查，至退租時清除磁碟、GPU 記憶體、主機管理控制器帳密與暫存金鑰，並留存清除證明。
07關於睿算
策略、AI 專業與工程建置，整合於同一團隊。
睿算為 AI 基礎設施與導入服務公司。本公司將顧問業界定問題的方法，與基礎設施團隊的實作能力整合於同一團隊，使策略與實作在同一組人手上完成銜接。
先建模，再實作
多租戶系統的成敗多取決於租戶邊界、狀態機與補償流程是否界定清楚。本公司因此自 UML 著手，先行確立各角色的權限範圍、資料歸屬與恆常條件，以及控制平面對各資料平面的工作交付方式。
架構維持供應商中立
Kubernetes、Slurm、OpenStack 與 vLLM 均置於介面卡之後，核心領域維持中立。客戶更換後端引擎時，控制平面與帳務邏輯得以完整沿用。
交付可稽核的系統
每項自動化動作、每一筆用量、每一次跨租戶操作均留存證據。事故檢討時，系統得完整說明何人在何種條件下執行了何種操作。
將營運能力移交客戶
本公司以完成移交為專案目標。結案時交付文件、契約測試、操作手冊，以及一支受過訓練、得以獨立維運的團隊。
- ·生產能力以生產環境的驗證結果為準
- ·待第二種實作出現後，再行抽象
- ·以模組化單體起步，透過事件與介面卡保留日後拆分的空間
- ·所有長流程均具備工作流視圖：目前狀態、等待對象、失敗原因與可重試動作
- ·配額不足時，一併說明適用政策與申請途徑
08聯絡
歡迎與本公司洽談導入需求。
若貴公司正規劃 AI 資料中心、評估多租戶算力平台，或現有 AI 專案停留於試點與上線之間，歡迎與本公司聯繫。初次討論無須準備簡報，說明目前遭遇的具體問題即可。
- 公司
- 睿算 Acumina Computing
- 服務範疇
- AI 資料中心平台 · 企業算力導入
- 所在地
- 台灣