綜合應用案例：LLM API 服務監控（探索版）¶
本案例以「大型語言模型 API 服務監控」為場景，用 SRE 解決問題的視角 探索機率分布。你將扮演 SRE 工程師，從實際問題出發，逐步發現「為什麼需要這個數學工具」。
設計理念：不是「先學分布，再找應用」，而是「遇到問題 → 需要什麼資訊 → 引入數學工具」。
場景背景¶
你是某 AI 公司的 SRE 工程師，負責維運一套類似 OpenAI API 的 LLM 推論服務。
什麼是 SRE？
SRE（Site Reliability Engineering，網站可靠性工程）是 Google 在 2003 年提出的角色，核心理念是「用軟體工程的方法解決運維問題」。
| 領域 | 工作內容 |
|---|---|
| 監控告警 | 設計 metrics、建立 dashboard、設定告警閾值 |
| 可靠性 | 確保系統達成 SLO（如 99.9% 可用性） |
| 容量規劃 | 預測流量、規劃資源、成本優化 |
| 事故響應 | On-call 輪值、故障排查、寫 postmortem |
本案例中的問題正是 SRE 日常會遇到的：失敗率多高要告警？需要幾台 GPU？P99 延遲是多少？
根據歷史監控數據：
| 參數 | 符號 | 數值 | 說明 |
|---|---|---|---|
| 請求成功率 | \(p\) | \(0.95\) | 單次 API 請求成功完成的機率 |
| 平均請求率 | \(\lambda\) | \(200\) 次/秒 | 尖峰時段每秒平均請求數 |
| 平均響應時間 | \(\mu\) | \(2\) 秒 | 單次請求的完整響應時間（非流式） |
| 服務等級目標 | SLO | \(99.9\%\) 可用性 | 月度目標 |
關於響應時間的說明
本案例假設 非流式（non-streaming） 場景：客戶端等待完整回覆後才收到響應。
實際 LLM 的響應時間受多種因素影響，波動很大：
- 輸入長度：prompt 越長，prefill 時間越長
- 輸出長度：生成 token 數越多，總時間越長
- 系統負載：排隊等待時間
因此響應時間通常不是常數，而是服從某種分布（如 Gamma 或 Log-Normal）。第 3 題會深入探討這個問題。
失敗原因分類：
- GPU 記憶體不足（40%）
- 推論超時（35%）
- 模型載入錯誤（15%）
- 其他錯誤（10%）