把模型下載下來、看到 GPU 開始吃 VRAM，再從 Web UI 成功問出第一個問題，通常是架設地端生成式 AI 最有成就感的一刻。

但如果今天不是「我自己的電腦跑得動」，而是一套要讓多人長期使用的地端 AI 平台，真正麻煩的事情其實才剛開始。

模型能載入，不代表下一個使用者來的時候還有 GPU；API 回 HTTP 200，不代表第一個 token 不會等很久；服務今天能啟動，也不代表模型、資料庫、檔案與設定真的能在事故後恢復。更現實一點：GPU 沒爆，不代表 CPU、RAM、磁碟 I/O 或資料庫不會先把整個平台拖垮。

所以這 30 天，我不打算再寫一套「如何安裝 Ollama、vLLM 或 Web UI」的教學。

我想處理的是另一個問題：

一台「可以跑 AI」的伺服器，要經過哪些工程工作，才能變成一個「可以被長期營運」的 AI 平台？

這也是整個系列的起點。

PoC 證明的是「能不能跑」，營運關心的是「能不能一直跑」

在 PoC 階段，我們最在意的通常是功能：

• 模型能不能載入？
• API 能不能回應？
• Web UI 能不能正常對話？
• GPU 有沒有被使用？

這些問題都重要，但它們主要回答的是：Happy Path 能不能走通。

一旦開始提供多人使用，問題就會換一個層級：

• 同時有多個 request 時，延遲會變成什麼樣子？
• 一個大型模型吃掉大部分 VRAM 後，Embedding、ASR 或其他 workload 還能不能工作？
• Request 排隊時，我看不看得到 queue？
• 模型服務掛掉時，前端會得到什麼結果？
• 系統碟剩下 10% 時，有沒有告警？
• PostgreSQL 有備份，但真的還原過嗎？
• 更新模型或容器版本失敗，可以回到上一版嗎？
• 如果整台主機需要重建，多久可以重新提供服務？

這些問題沒有一個可以靠「服務有啟動」回答。

Google SRE 對監控的定義很直接：不是只看機器有沒有活著，而是持續蒐集、處理與呈現系統的量化資訊，包括 request、error、latency 與資源狀態。換句話說，Production 不是一個部署完成的狀態，而是一組持續被量測與驗證的能力。

AI 平台和一般 Web 服務最大的不同：資源競爭更複雜

一套地端 AI 平台通常不只跑 LLM。

常見的 workload 可能同時包含：

這裡最麻煩的地方是：大家搶的不是同一種資源。

LLM 可能先把 VRAM 用完；資料庫可能因為 Storage I/O 變慢；下載或載入模型可能把磁碟打滿；ASR 與 Embedding 又可能在某些時間突然需要 GPU。單看任何一個 container 都可能是健康的，但整體使用體驗仍然可能很差。

所以後續我不會只問「GPU 使用率多少」，而會從四個層次觀察：

以 vLLM 為例，官方就提供 num_requests_running、num_requests_waiting、KV Cache 使用率、TTFT、Inter-token Latency 與 End-to-end Latency 等 production metrics。這些訊號比「GPU 有沒有吃滿」更接近使用者真正感受到的服務品質。

單一服務正常，不代表平台正常

假設今天 Web UI 可以打開，LLM API 也還活著。

平台算健康嗎？不一定。

一條簡化的請求鏈可能是：

User
  ↓
Web / API
  ├──→ Embedding ─→ Vector / Database
  ├──→ ASR ───────→ GPU
  └──→ LLM ───────→ GPU / Model Storage

所以一次「AI 回答失敗」可能根本不是模型壞掉。

它可能是：

1. Disk I/O 太高，模型載入變慢。
2. Database connection pool 用完。
3. GPU VRAM 被另一個模型占住。
4. Queue 堆積，但健康檢查仍然回 200。
5. 某個相依服務 timeout，前端最後只顯示 generic error。

這也是為什麼 Day 2 我會先做 Dependency Map / Failure Domain，而不是急著裝更多監控工具。

如果連「服務依賴誰」都沒有畫清楚，Grafana 就算有一百張 panel，事故發生時仍然不知道先查哪裡。

備份成功，不等於真的可以復原

AI 平台還有一個常被忽略的問題：狀態散落在很多地方。

至少可能包括：

• PostgreSQL / 應用資料
• 使用者與權限設定
• Application configuration
• Prompt / Workflow configuration
• Object / File Storage
• Secret
• Model metadata
• 大型模型檔與 cache

每一種資料的恢復策略都不同。

例如模型權重未必需要每天備份，只要能從可信來源重新取得；但資料庫如果少掉一天資料，影響可能完全不同。

所以後續談備份時，我不會用「pg_dump 有成功」當結論。

真正要問的是：

我能不能從備份重新建立服務？實際花多久？最多可以接受遺失多少資料？

也就是把 RPO（Recovery Point Objective）與 RTO（Recovery Time Objective）變成真的可測量目標，而不是只停留在名詞。

這 30 天，我會用 SRE 的方式看 AI 平台

我希望這個系列和一般安裝筆記最大的差別，是每個結論都盡量留下證據。

後面的文章會固定用這個結構：

問題
 ↓
假設
 ↓
Baseline
 ↓
實驗 / 故障注入 / 設定變更
 ↓
Metrics / Logs / Screenshot
 ↓
結果
 ↓
Trade-off
 ↓
能不能恢復？能不能重現？

例如不是只寫：

Prometheus 很適合監控 AI 平台。

而是去回答：

GPU OOM 發生前，Metrics 能不能看到前兆？哪一個訊號最早出現？

也不是只寫：

vLLM 效能比較好。

而是固定模型、輸入與併發條件後，實際比較：

• TTFT
• P50 / P95 latency
• Throughput
• VRAM
• Queue length
• Error rate

如果結果和原本假設不一樣，也保留。

因為對維運來說，「我原本以為瓶頸是 GPU，結果其實是 Storage」往往比成功截圖更有價值。

我先替這個系列定下五個問題

接下來 29 天，所有文章其實都在回答下面五件事：

1. 看得見嗎？

平台慢下來之前，我能不能看到 queue、VRAM、latency、I/O 或 error 的變化？

2. 撐得住嗎？

負載增加、多模型共存或資源競爭時，平台在哪個點開始失去服務品質？

3. 壞了知道為什麼嗎？

出事後能不能靠 Metrics、Logs、Traces 與事故時間線找到 root cause，而不是靠重開機解決？

4. 壞了救得回來嗎？

模型服務、資料庫、儲存或整台主機失效後，能不能在可接受時間內恢復？

5. 下次可以不要再犯嗎？

事故之後能不能把結果變成告警、容量規則、Runbook、Postmortem 或架構調整？

如果 30 天結束時，這五題都有實測結果，那這套系統才算真正從「能跑 AI」往「能營運 AI」前進了一段距離。

今天的結論

Day 1 我沒有打算證明哪個模型比較快，也沒有安裝新的工具。

今天先建立一個之後不會改變的判斷基準：

模型成功輸出，只能證明功能路徑成功；平台能不能被營運，要看它是否可觀測、可容量規劃、可處理故障、可安全變更，而且真的能復原。

從明天開始，我會先把地端 AI 平台拆開，畫出服務之間真正的 Dependency 與 Failure Domain。

因為在開始監控以前，我得先知道：

到底有哪些東西會壞，以及一個地方壞掉會拖誰一起下水？

下一篇：Day 02｜先畫清楚故障域：一台 AI 主機到底有哪些依賴

參考資料

1. Google SRE, Monitoring Distributed Systems
   https://sre.google/sre-book/monitoring-distributed-systems/
2. vLLM Documentation, Production Metrics
   https://docs.vllm.ai/en/latest/usage/metrics/

本系列僅使用去識別、可公開的架構與實驗結果；不公開內部網路位址、帳號、密鑰或未公開的系統設定。