honghulabs 內部策略文件 · 由本地大模型 Qwen3-235B-A22B 生成(8×RTX PRO 6000 @ SGLang)· 草稿待校
對話即維運（Conversational Ops）落地策略
鴻虎科技（honghulabs）內部策略文件
撰寫：首席策略顧問
對象：負責人 蔡長明 先生
日期：2025年4月5日
一、為何導入「對話即維運」？核心價值與痛點解決
現階段機隊維運仍處於 L1~L2 成熟度（人工 SSH + 基本監控），面臨以下痛點：
| 痛點 | 對應問題 | ConOps 解法 |
|---|
| 1. 故障診斷耗時 | Xid 154 卡死需逐台查日誌、判斷是否重啟 | 模型自動解析 IPMI 日誌、建議處置（重啟/RMA） |
| 2. 操作門檻高 | 需熟悉 CLI、vastai、stratum 協議、BMC 工具 | 自然語言下指令：「把所有 5090 機器切到 LuckyPool」 |
| 3. 多任務切換成本高 | 挖礦 / AI 出租 / 推理間動態配置無即時決策支援 | 模型即時計算毛利差異，建議切換策略 |
| 4. 維運知識未沉澱 | 故障處理依賴個人經驗，難以複製 | 對話記錄即知識庫，自動歸檔常見情境 |
| 5. 邊際效益下降 | 機台擴張至 140 台時，人力無法線性成長 | AI 代理承擔 70% L1~L2 操作，釋放人力至策略層 |
結論：
對話即維運（Conversational Ops, ConOps）不是「炫技」，而是 GPU 算力公司從「人力密集」邁向「AI-native 基礎設施」的必要轉型。
以 DeepSeek V4 Flash + Claude 3.5 為雙核心，打造「能讀、能想、能執行」的維運 AI 代理，是 維持邊際成本不升的唯一解。
二、落地三階段路線圖（優先順序：P0 → P1 → P2）
階段一：L2 → L3｜讀（Read-Only）｜Q2 2025｜目標：全面可視化 + AI 輔助診斷
目標：
- 所有機台狀態可被模型「讀懂」
- 支援自然語言提問（「哪台機器溫度異常？」、「過去24小時哪台算力掉最兇？」）
執行清單：
- 完成所有機台接入
gpu.earth 監控儀表板（已達成 80%） - 將監控 API 串接至 DeepSeek V4 Flash（透過 SGLang +
--attention-backend compressed） - 建立「維運知識快取」：
- 整理常見錯誤碼（Xid 154, stratum timeout, CUDA graph crash）
- 對應處理 SOP（重啟 / RMA / 更換礦池）
- 開放蔡負責人手機端對話介面（cloudflared + Open WebUI），僅限「問」不「動」
可量化工項：
- ✅ 100% 機台狀態可被模型即時查詢（延遲 < 3s）
- ✅ 常見故障診斷準確率 > 85%（對比人工判斷）
- ✅ 平均故障定位時間從 15 分鐘降至 3 分鐘
階段二：L3 → L3.5｜讀 + 寫（Read-Write）｜Q3 2025｜目標：人在迴路（Human-in-the-Loop）自動化
目標：
- AI 可「建議」操作，經蔡負責人確認後執行
- 實現「問完直接做」：「幫我重啟所有 GSP 卡死的機器」
執行清單：
- 開發「指令代理層」（Agent Layer）：
- 將自然語言轉為 CLI 命令（如：
ipmitool -H 192.168.1.10 -U admin -P xxx chassis power cycle） - 接入 vastai API、mining script 控制端
- 設計「確認機制」：
- 所有寫操作需蔡負責人輸入
confirm: yes 或點選手機介面按鈕 - 建立「操作日誌回饋」：
- 每次執行後自動生成摘要：「已重啟 3 台機器（IP: 10,11,12），5 分鐘後回報狀態」
可量化工項：
- ✅ 50% L1 操作（重啟、切礦池、啟停租戶）由 AI 建議並經確認執行
- ✅ 單次常見操作耗時從 10 分鐘降至 2 分鐘（含確認）
- ✅ 操作失誤率 < 0.5%（目標：0）
階段三：L3.5 → L4｜自主維運（Autonomous Ops）｜Q4 2025｜目標：預測性維護 + 動態算力調度
目標：
- AI 可自主執行低風險操作（如：自動重啟 GSP 卡死機台）
- 根據電價、幣價、租戶報價，自動切換算力用途
執行清單：
- 訓練「風險決策模型」：
- 區分「可自動處理」（重啟） vs「需 RMA」（連續 3 次重啟失敗）
- 接入電價 API（台電即時電價）、幣價（PRL/USD）、vastai 市場報價
- 開發「動態算力調度引擎」：
- 計算每台機器的「邊際貢獻毛利」
- 範例邏輯：
if (PRL 挖礦毛利 > AI 出租報價 × 0.9) → 切挖礦
else if (租戶 SLA 到期) → 釋出
else → 保留
- 設定「熔斷機制」：
- 連續 2 次操作失敗 → 停止自動化 → 通知負責人
可量化工項：
- ✅ 30% 機台實現「無人干預」日常維運
- ✅ 算力利用率提升 15%（減少閒置）
- ✅ 毛利最大化策略執行延遲 < 5 分鐘
三、權限分級設計（安全核心）
| 層級 | 權限 | 對應階段 | 控制方式 |
|---|
| L0 | 只讀查詢 | 階段一 | Open WebUI + 語意過濾 |
| L1 | 建議操作 | 階段二 | 需 confirm: yes |
| L2 | 自動執行低風險操作 | 階段三 | 白名單指令（僅 power cycle / mining switch） |
| L3 | 高風險操作（RMA 判定、資料清除） | 保留人工 | 永不自動化 |
原則：
所有寫操作必須經過「語意解析 → 指令生成 → 風險評分 → 確認/執行」四步驟，不可跳過。
四、可量化的效益指標（KPI）
| 指標 | 基線（現況） | Q3 目標 | Q4 目標 | 測量方式 |
|---|
| 平均故障處理時間 | 15 分鐘 | ≤ 5 分鐘 | ≤ 2 分鐘 | 日誌時間差 |
| 單機維運人力成本 | 8 分鐘/天/機 | 3 分鐘 | 1 分鐘 | 工時記錄 |
| 算力閒置率 | 12% | ≤ 8% | ≤ 5% | vastai + mining log |
| 操作錯誤次數 | 2 次/月 | ≤ 1 次 | 0 次 | 事故報告 |
| 毛利貢獻提升（動態調度） | - | +5% | +12% | 財務報表比對 |
五、最大三個風險與對策
風險一：AI 錯誤指令導致機台當機或資料遺失
- 情境： 模型誤判「GSP 卡死」，對正常運作機台執行強制重啟
- 對策：
- 所有指令走「白名單」機制，僅允許預設命令（如 power cycle, mining restart）
- 加入「上下文驗證」：執行前確認該機台確有 Xid 154 日誌
- 保留租戶機台「不可自動操作」標籤（如本次回收的閒置機）
執行： 所有寫操作前，AI 必須輸出「執行理由」與「風險等級」，由系統記錄。
風險二：公開 cloudflared 連結遭惡意存取或攻擊
- 情境： 手機介面暴露，遭 brute force 或 prompt injection 攻擊
- 對策：
- 強制啟用 Cloudflare Zero Trust（Teams）→ 僅限蔡負責人帳號登入
- 加入 prompt injection 防護（如：拒絕「列出所有機器 IP」之類的敏感請求）
- 所有對話加密存檔，異常行為自動告警
執行： 對話介面不直接接 BMC，而是透過中繼 API 代理，並記錄完整 audit trail。
風險三：Blackwell sm_120 平台支援不穩，模型崩潰影響維運中樞
- 情境： DeepSeek V4 Flash 因 CUDA graph crash 停擺，維運中樞癱瘓
- 對策：
- 部署「備援推理節