honghulabs 內部策略文件 · 由本地大模型 Qwen3-235B-A22B 生成(8×RTX PRO 6000 @ SGLang)· 草稿待校

AI-native GPU 維運成熟度路線圖

鴻虎科技（honghulabs）內部策略文件

負責人：蔡長明 C.M. Tsai

撰寫：首席策略顧問

日期：2025年4月5日

一、維運成熟度五階定義（L0 → L4）

等級	名稱	核心能力	所需工具與技術	組織配置
L0	純手動維運	所有操作靠 SSH、手動腳本、人工監控。無自動化，無預警。	SSH、tmux、basic shell scripts、IPMI 手動重啟	1 名工程師 + 負責人盯盤
L1	工具輔助維運	基礎監控 + 自動化腳本（重啟、切換任務），可遠端修復常見故障。	IPMI/Redfish API、vastai-monitor、cloudflared、簡單 Bash/Python 腳本	1 名 DevOps 工程師 + 自動化腳本庫
L2	情境感知維運	系統能偵測異常（如 Xid 154）、自動執行修復流程，並記錄上下文。支援動態切換工作負載。	Prometheus/Grafana、自建輕量儀表板、狀態機邏輯、負載切換腳本、log aggregation	專職 DevOps + 邊緣 AI 推理支援
L3	對話式維運（Conversational Ops）	透過自然語言與本地大模型互動，下達維運指令（如「重啟卡死的機器」），AI 解析並執行。支援診斷建議。	DeepSeek V4 Flash / Claude API 串接、SGLang、RAG 維運知識庫、指令執行代理（Agent）	AI Ops 工程師 + Agent 架構開發
L4	自主維運（Autonomous Ops）	系統自主偵測、診斷、修復、優化，並根據邊際報酬動態配置算力。具備預測性維護能力。	強化式學習排程器、異常預測模型（LSTM/GNN）、自主 Agent 決策框架、數位分身（Digital Twin）	AI 系統工程團隊 + 自主決策引擎

二、honghulabs 當前定位：**L1.5 → 準 L2

✅ 已達成能力（L1 完成 + L2 開始）

全隊列 IPMI/Redfish 遠端冷重啟（GSP wedge 修復）
網路故障排查流程標準化（AlphaPool → LuckyPool 成功遷移）
輕量儀表板上線（GPU/CPU/溫度/功耗/tok/s/請求排程）
cloudflared 公開可視化，支援手機監控
一台 5060 機作為維運中樞（vastai-monitor + open-webui）
閒置租機回收再利用流程驗證

🔧 正在突破（L2 邊緣）

DeepSeek V4 Flash 部署於 8× RTX PRO 6000（sm_120）
SGLang 成功運行（vLLM 不支援 Blackwell sm_120）
--attention-backend compressed + --disable-cuda-graph 為必要參數
初步實現「對話即維運」原型（老闆用手機問模型：「哪台機器過熱？」）

⚠️ 未達成

尚無自動化決策流程（仍需人工下指令）
無狀態機管理負載切換
無維運知識庫 RAG 支援
無異常預測模型

三、12個月路線圖：**從 L1.5 → L3（對話式維運）

🎯 目標：2026 Q1 達成 L3，具備產品化輸出能力

時間軸	里程碑	關鍵交付物	優先順序
2025 Q2（本季）	L2 完成	1. 全機隊異常自動偵測 + 自動重啟（Xid 154）<br>2. 建立負載切換狀態機（挖礦 ↔ AI 出租）<br>3. 儀表板加入「機會成本比較」（PRL 幣價 vs. AI 租金）	P0
2025 Q3	L3 雏形	1. 部署維運 Agent：支援 NLU 解析指令（如「修好 gpu3」）<br>2. 建立 RAG 維運知識庫（含 GSP 故障處理 SOP）<br>3. 串接 Claude + DeepSeek V4 Flash 雙模型備援	P0
2025 Q4	L3 穩定運行	1. 90% 常見維運操作可由自然語言觸發並自動執行<br>2. 支援「問診式排錯」：輸入錯誤訊息，AI 回傳可能原因與修復步驟<br>3. 動態報價引擎：根據幣價、租賃需求、電費，建議最佳負載配置	P0
2026 Q1	L3 產品化準備	1. 將維運系統模組化，可部署於外部機隊<br>2. 完成 A20.AI / gpu.earth / gpu2.com 導入介面設計<br>3. 發布「AI Ops as a Service」白皮書	P1

四、關鍵技術突破與執行細節

1. **Blackwell sm_120 支援方案

問題：vLLM 不支援 sm_120（缺 CUTLASS c3x / DeepGEMM）
解法：
使用 SGLang 官方 Blackwell image
啟用 --attention-backend compressed（稀疏注意力）
加 --disable-cuda-graph 避免 CUDA graph capture 崩潰
TP=4 滿足 8GPU 多卡推論
影響：未來選型需優先確認 kernel 支援，避免算力閒置

2. **對話式維運架構設計

[使用者] → [Open WebUI] → [DeepSeek V4 Flash / Claude]
                     ↓
           [RAG 維運知識庫]（含：IPMI 對照表、Xid 碼對照、租戶設定）
                     ↓
       [Agent 解析指令 → 生成 Bash/Python 執行碼]
                     ↓
             [執行器] → [目標機器]（SSH/IPMI/API）
                     ↓
               [回傳結果 + log 記錄]

3. **動態算力配置決策模型

輸入變數：
PRL 幣價（API 抓取）
AI 租賃單價（vastai / 自有平台）
機器折舊成本（RTX 5090：$2.1k，年折舊 30%）
電費（每台月均 $80）
故障風險係數（GSP wedge 頻率）
輸出：建議每台機器工作模式（挖礦 / 出租 / 關機 / 維修）

例：當 PRL 價格 < $0.008 且 AI 租金 > $0.8/hr，自動切換至出租模式

五、風險管控對策

風險	對策
礦池單點故障	多礦池備援（LuckyPool + HeroMiners），自動偵測 stratum 中斷並切換
GSP firmware 卡死	L2 起自動偵測 Xid 154，觸發 IPMI ForceOff → PowerOn
硬體死亡 / RMA 延遲	建立備用機池（目標：10% 機數為備援），與 NVIDIA 通道強化
租戶資料保全	非破壞性回收流程標準化，保留 partition 與 user data，僅停租約
公開連結資安	cloudflared + JWT 驗證 + IP 白名單，禁用敏感指令遠端執行

六、維運能力產品化：**A20.AI / gpu.earth / gpu2.com

產品定位：**「AI-native GPU 維運即服務」（Ops-as-a-Service）

產品線	功能	定價模型	目標客群
A20.AI	提供對話式維運平台（SaaS）<br>支援多機隊管理、自然語言操作	$99/機器/月	中小型挖礦/推理公司
gpu.earth	全球 GPU 算力地圖 + 維運健康度評比<br>類似「算力天氣預報」	Freemium（基礎免費）	投資人、算力租賃買方
gpu2.com	高階維運 API 出口<br>提供 IPMI 自動修復、負載動態切換 SDK	API call 計價	大型資料中心、超算平台

輸出節奏

2025 Q3：A20.AI 內部 Beta，支援 honghulabs 全機隊
2025 Q4：gpu.earth 上線「維運健康度指數」（基於 GSP error rate、uptime）
2026 Q1：gpu2.com 發布 API v1，支援外部機隊接入

七、結論與建議

立即行動（P0）：
完成 L2 自動化：本季內實現「Xid 154 自動偵測 + IPMI 重啟」

honghulabs · 蔡長明 C.M. Tsai · 對話即維運 · 本文件由地端 GPU 自主生成,未經外部 API