你的 AI 服務「有回應」，不代表它是對的

一般服務的監控在問一件事：它還活著嗎？

HTTP 回 200、行程還在、記憶體沒爆，那就是健康的。這套用了二十年，很好用。

但 AI 服務不吃這一套。 因為它有一種一般服務沒有的狀態：

活著、有回應、每項指標都綠燈——但它給的答案是錯的。

而且這種狀態不會觸發任何傳統告警。

四種只有 AI 服務才有的失效模式

一、硬體不見了，服務還在跑

這是我們自己被咬過的。

Ubuntu 的 unattended-upgrades 會自動升級 NVIDIA 驅動，但不會重新載入核心模組。結果是虛擬機裡 nvidia-smi 突然回報 0 張卡——而你什麼都沒動。

最難的地方在於現象跟原因中間沒有線索。從外面看，服務還在、埠還開著；你不會想到去查「昨天半夜自動更新了什麼」。

一般的服務探測完全抓不到這種事，因為服務真的還活著。

二、備援悄悄接手，沒人知道

如果你的架構有多模型路由——主力模型不可用時自動切到備援——那你就有一個新問題：

切過去之後，誰告訴你？

我們的 LLM 服務走「閘道 ＋ 多模型路由」，服務端統一呼叫閘道，由閘道依用途路由到不同等級的模型，主力不可用時切備援。這個設計讓服務不會中斷——但也讓故障變得不痛。

不痛的故障最危險。你可能已經用降級模型跑了三天，回答品質變差、使用者默默不用了，而監控上一片綠。

所以「備援有沒有被觸發」本身就必須是一個告警項目，不能只在真的全掛時才響。

三、模型還在，但答案慢慢跑掉

這種最陰險，因為它沒有一個「壞掉的瞬間」。

業界的觀察是：一個在上線前每項評測都通過的模型，仍可能在生產中靜默劣化。原因通常不在模型本身，而在它周圍的東西變了——輸入的資料樣態變了、提示樣板被人改過、RAG 的檢索語料更新了。

所以 2026 的做法是先建基準線：輸入分布、提示樣板、檢索語料各自留一份基準。沒有基準線，你連「跑掉了」都證明不了。

四、成本悄悄暴衝

這個不影響可用性，但會影響下個月的臉色。

用量與成本要能回溯到是誰、哪個服務、哪個模型用掉的。等收到帳單才發現，通常已經燒了一個月。

（地端部署在這點上比較不痛，因為主要成本是電和硬體折舊，不會有帳單驚喜。但用量仍然要記錄——它是容量規劃的依據，也是稽核時要交代的東西。）

2026 的做法：監控要分三層

現在的共識是，AI 服務的監控要分成三層來看：

層	監控什麼	用什麼
基礎設施	節點資源、GPU 記憶體、請求排隊	沿用既有的可觀測性工具即可
LLM 遙測	呼叫追蹤、延遲、token 用量、路由決策	LLM 原生的可觀測性工具
品質評估	輸出品質、漂移偵測	抽樣評分

自架路線的常見組合是：Prometheus ＋ Grafana 做基礎設施指標、Grafana Tempo 做分散式追蹤、Langfuse（可自架、MIT 授權）做 LLM 可觀測性、Evidently AI（開源、可自架）做統計性漂移指標。

務實的架構是混合式：基礎設施層沿用通用 APM，模型與代理層加 LLM 原生工具，並採用 OpenTelemetry 的 GenAI 語意慣例，讓你日後換工具時不必重做。

先說清楚：上面這些工具我們沒有生產部署，這段是公開資料整理。我們自己的監控是既有體系加上針對 AI 的檢查項目——下一段才是實測。

品質怎麼監控？抽樣，不要全量

品質評估最容易卡住的地方是「聽起來成本很高」。

2026 的標準做法是：抽樣 1–5% 的生產流量，用 LLM-as-judge 依結構化評分準則評分，而且非同步執行——不要卡在使用者的請求路徑上。

這個比例是關鍵。全量評分成本高又拖慢回應；1–5% 已足以看出趨勢，而你要偵測的是趨勢變化，不是抓每一筆錯誤。

我們實際加了哪些檢查

我們的環境是既有監控體系加上針對 AI 的項目。真正有用的是這幾條：

GPU 健康看門狗 不是看「GPU 使用率」，而是看卡還在不在、驅動與核心模組版本是否一致。這條是被前面那個「卡消失」事件逼出來的。

備援切換要告警 主力模型不可用、路由切到備援，本身就要通知。服務沒斷不代表沒事。

用量與成本集中記錄 可回溯到服務與模型層級，供容量規劃與稽核使用。

還有一條不是 AI 專屬、但同樣重要的：我們吃過「備份任務在跑、看起來有排程紀錄，但實際上寫不進去」的虧——儲存掛載參數選錯，備份靜默失敗了好幾天才被發現。

這幾件事看起來不相干，但病因是同一個：

最危險的故障不是壞掉，是安靜地不工作。

可以直接照著檢查的清單

如果你手上有 AI 服務在跑，這幾題現在就能問：

1. 如果 GPU 從虛擬機裡消失，你多久會知道？ 如果答案是「等使用者抱怨」，那就是還沒有監控。

2. 備援模式被觸發時，會不會有人收到通知？ 沒有的話，你可能正在用降級模型服務客戶而不自知。

3. 你有沒有「正常長什麼樣」的基準線？ 輸入分布、提示樣板、檢索語料——沒有基準線就證明不了漂移。

4. 上一次確認備份真的寫進去是什麼時候？ 不是「備份任務有跑」，是「檔案真的在，而且還原得回來」。

5. 這個月的用量，你查得出是誰用掉的嗎？ 查不出來的話，容量規劃和稽核都會卡住。

最後

AI 服務的監控之所以難，不是因為要監控的東西比較多，而是因為它的失效方式跟傳統服務不一樣。

傳統服務壞掉會停；AI 服務壞掉會繼續回答你，只是答案變差。綠燈不等於正常，這是導入 AI 之後最需要改掉的直覺。

如果你正在把 AI 放進生產環境，或是已經上線但不確定「它現在到底正不正常」，我們可以直接談要加哪些檢查項目、以及怎麼讓故障變得會痛。