AWS 在 2026 年 5 月 29 日發表 SageMaker AI LLM inference observability 實作，核心觀念很直接：production LLM 不能只看基礎設施有沒有活著，也要看模型輸出是否仍然可靠。
傳統服務監控通常看 latency、error rate、CPU、memory、throughput。這些仍然重要，但 LLM 多了一層問題：endpoint 可能很健康，回答卻變差。
為什麼 LLM observability 要分成 quantity 和 quality？
AWS 把觀測分成兩種：
| 類型 | 代表指標 | 回答的問題 |
|---|---|---|
| Quantity | GPU utilization、latency、throughput、errors、CPU usage | 系統是否穩定、成本是否合理、容量是否足夠 |
| Quality | composite quality score、safety score、evaluation latency | 模型回答是否正確、安全、一致 |
這兩類訊號缺一不可。
例如：
- GPU 很健康，但模型開始給錯誤答案。
- 回答品質很好，但 GPU over-provisioned，成本過高。
- latency 正常，但 safety score 下降。
- throughput 上升，但品質因 prompt distribution 改變而退步。
Production-grade LLM observability 要把這些訊號放在一起看。
SageMaker AI endpoint 怎麼監控多模型？
AWS 示範使用 SageMaker AI endpoints with inference components。Inference components 可以讓同一個 endpoint 承載多個模型，並保留每個模型的 traffic routing、scaling policies 和 metric attribution。
這對企業很實用，因為 production 不一定只有一個模型。
可能同時有：
- 一個高品質模型處理複雜任務。
- 一個低成本模型處理簡單分類。
- 一個 open-weight model 做內部部署。
- 一個 fallback model 處理突發流量。
如果指標不能按 model component 拆開，就很難知道哪個模型造成成本、延遲或品質問題。
CloudWatch 與 Grafana 怎麼分工？
AWS 的架構使用：
- SageMaker AI endpoints with inference components。
- Amazon CloudWatch。
- Amazon Managed Grafana。
CloudWatch 接收兩種 metric namespace：
| Namespace | 內容 |
|---|---|
/aws/sagemaker/InferenceComponents/ | enhanced metrics：invocation、latency、errors、GPU/CPU utilization |
/aws/sagemaker/inference-quality/ | custom quality metrics：quality score、safety score、evaluation latency |
Grafana 則負責把 quantity dashboard 和 quality dashboard 視覺化。
這樣做的好處是，工程團隊可以同時看 infrastructure health 和 model behavior。
哪些指標最該優先看？
Quantity 指標
- Invocation count。
- P50／P95 latency。
- Error rate。
- GPU memory utilization。
- GPU compute utilization。
- CPU utilization。
- Queue 或 throttling 狀態。
- 每個 inference component 的 traffic。
這些指標回答「系統能不能撐住」。
Quality 指標
- Composite quality score。
- Safety score。
- Answer correctness。
- Faithfulness。
- Policy compliance。
- Evaluation latency。
- Model drift。
- Prompt distribution shift。
這些指標回答「系統有沒有回答好」。
為什麼單看 GPU utilization 會誤判？
GPU utilization 高，不一定代表系統有問題；可能只是流量上升。GPU utilization 低，也不一定代表浪費；可能是為了 SLA 保留 headroom。
更大的問題是：GPU 指標看不到回答品質。
一個 endpoint 可以：
- 低延遲。
- 低錯誤率。
- GPU 使用率漂亮。
- 但回答開始不符合規則。
這就是為什麼 output quality metrics 要進入 observability。
適合哪些團隊？
適合：
- 自行部署 LLM inference 的 ML platform team。
- 在 SageMaker 上跑多模型 endpoint 的企業。
- 需要控制 GPU 成本的團隊。
- 有合規或安全要求的 production AI。
- 需要比較不同模型與設定的團隊。
不一定適合：
- 只用第三方 SaaS AI 工具。
- 沒有自行管理 inference endpoint。
- 還在 prototype 階段，流量很低。
官方來源
- AWS Machine Learning Blog，Comprehensive observability for Amazon SageMaker AI LLM inference：From GPU utilization to LLM quality，2026-05-29。
結論
SageMaker LLM inference observability 的關鍵，是把 AI production monitoring 從「服務有沒有活著」提升到「服務是否仍然產生可靠輸出」。
未來 LLM 平台團隊不能只看 GPU、latency 和 errors，也要把 quality score、safety score、drift 和 evaluation signals 放進同一張監控圖。模型輸出是產品的一部分，品質退步就等於服務退步。