LLM API 高可用高擴展，部署方式怎麼選？
某企業提供大型語言模型（LLM）API 服務，需支援高併發請求與流量波動，同時要求服務不中斷並具備故障容忍能力。若以高可用性與可擴展性為主要設計原則，下列哪一種部署方式較為適當？
某企業提供 LLM API 服務，需要支援高併發請求與流量波動，同時要求服務不中斷並具備故障容忍能力。設計原則是高可用性與可擴展性。
問你：以高可用性與可擴展性為主要設計原則，哪一種部署方式較為適當？
一句話總結
建立多個服務實例並透過負載分散分流請求，才能同時實現高可用（某一實例故障不影響整體）和高擴展（流量大時增加實例數量）。
先感受問題：AI API 服務該怎麼讓它不怕壞、不怕擠？
假設你是「智算雲端」公司的架構師，你的產品是提供 LLM API 給幾百家企業客戶使用。這些客戶在辦公時間瘋狂呼叫 API，尖峰時每分鐘幾萬次請求；晚上使用量下降到只剩百分之一。
問題有兩個。第一個問題是「可用性」：如果你只有一台伺服器在跑服務，那台伺服器當機，所有客戶的服務就全部中斷，那你的客戶就要跳腳。第二個問題是「擴展性」：如果尖峰時一台伺服器撐不住幾萬次請求，怎麼辦？
答案就是：不要靠一台，開好幾台，再用一個「負載分散器（Load Balancer）」把進來的請求分配給不同的機器。這樣任何一台機器壞了，負載分散器自動把流量引到其他機器，服務照樣正常運作。
只靠一台機器，會有哪些問題
- 單點故障（Single Point of Failure）：一台機器壞了，整個服務就掛掉。高可用性的第一原則就是消滅單點故障
- 無法水平擴展：一台機器的算力有上限。遇到流量尖峰，只能買更貴的機器（垂直擴展），而不能平行增加機器（水平擴展），成本效益差
- 維護即中斷：系統更新或維護時，整台機器要停機，服務就中斷
- 浪費資源：低流量時，高效能的單一機器大部分算力閒置，但你還是要付費
- 故障容忍能力為零：任何硬體故障、網路問題、OS 崩潰都會直接影響所有使用者
多實例加負載分散怎麼解決高可用和高擴展
「智算雲端」把 LLM API 服務部署成這樣：
多個服務實例：同時跑 10 個 LLM API 服務（10 個實例），每個實例是相同的服務複本。使用者的請求進來，不是打到同一台機器，而是先打到負載分散器。
負載分散（Load Balancing）：負載分散器把進來的請求按照各實例的負載情況分配出去。流量大的時候，10 個實例同時工作；某一個實例壞了，負載分散器自動把流量導向其他 9 個，服務不中斷。
彈性擴縮容（Auto Scaling）：流量高峰時自動新增實例（從 10 個增到 20 個）；流量低谷時自動縮減（從 10 個降到 3 個），省成本。
這個架構同時實現了：故障容忍（某一實例掛掉不影響整體）、高可用（服務持續不中斷）、可擴展（流量大就加機器）。
這就是選項 B 講的：建立多個模型服務實例並透過負載分散機制提供服務。
技術版：高可用性與可擴展性的設計原理
高可用性（High Availability, HA）是指系統在預定時間內持續正常運作的能力，通常以「N 個 9」表示（如 99.9% 的時間可用 = 一年停機時間不超過 8.76 小時）。實現高可用的核心手段是「冗餘（Redundancy）」：不依賴任何單一組件，每個關鍵組件都有備援。
可擴展性（Scalability）分兩種：垂直擴展（Scale Up）指升級單台機器的規格；水平擴展（Scale Out）指增加機器數量。LLM 服務通常用水平擴展，因為增加實例比買更貴的單一機器更靈活、更具成本效益。
負載分散（Load Balancing）是把進入的請求分配到多個服務實例的機制。負載分散器也需要高可用設計（通常用一對互備的負載分散器），否則負載分散器本身就成了單點故障。
為什麼出題者要考這題：AI 應用規劃師在規劃企業 AI 服務時，需要理解服務架構的基本原則。高可用和可擴展是企業級服務的基本要求，選錯架構會導致服務不穩定或成本失控。
為什麼其他選項是錯的
A採用單一高效能虛擬機（VM）集中部署，以提升資源使用效率
把所有運算集中在一台超強的虛擬機上，資源集中、效率最高。
單一虛擬機是典型的「單點故障」架構，完全違反高可用性的設計原則。一台 VM 故障，所有服務中斷。此外，單一 VM 有算力上限，無法水平擴展應對流量波動。「資源使用效率」不是高可用設計的優先考量。
以為「集中就是高效」的人。集中部署確實在資源利用率上有一定優勢，但完全犧牲了可用性和擴展性，在企業級服務中不可接受。
C將推論任務改由用戶端設備分擔，以降低伺服器負載壓力
讓使用者的手機或電腦自己跑 LLM 推論，不靠中央伺服器。
大型語言模型的推論需要大量 GPU 算力，一般用戶端設備根本沒有能力執行（幾百億參數的模型需要數十 GB 顯存）。這不是現實可行的方案。而且把模型部署到用戶端設備，安全性和版本管理都是大問題。
聽說過「邊緣運算（Edge Computing）」的人，以為把運算移到用戶端是未來趨勢。邊緣運算適合小型模型（如手機 APP 的輕量 AI），不適合大型 LLM。
D使用 FTP 協議傳輸請求與回應，以減少服務通訊負擔
用 FTP（檔案傳輸協定）傳送 API 的請求和回應，減少通訊開銷。
FTP（File Transfer Protocol）是設計來傳輸檔案的協定，完全不適合 API 的即時請求回應場景。AI API 服務使用 HTTPS/REST API 或 gRPC 協定，不用 FTP。這個選項是個明顯的幹擾項，說明這題的考點在「架構選擇」不在「協定知識」。
對網路協定完全不熟悉、看到「減少通訊負擔」就覺得合理的人。FTP 在這個場景根本不適用，是設計來誤導的選項。
同個考點下次怎麼變形
「高可用性（High Availability）」和「高可靠性（High Reliability）」有什麼差別？
聽起來都是「不容易壞」，有差嗎？
高可用性指「服務持續可存取」的時間比例，強調的是服務層面的連續性；高可靠性指「系統不發生故障」的能力，強調的是硬體和軟體層面的穩定性。兩者相關但不相同：高可靠性可以減少故障次數，高可用性透過冗餘設計讓就算發生故障服務也不中斷。
「水平擴展（Scale Out）」和「垂直擴展（Scale Up）」各適合什麼情境？
要讓服務能處理更多請求，是加強一台機器還是多加幾台？
垂直擴展（買更強的機器）適合資料庫這類難以分散的系統，有上限且成本高。水平擴展（多加幾台）適合無狀態的 API 服務（如 LLM API），可以無限增加實例，成本線性增長，彈性高。LLM API 服務的正確選擇是水平擴展加負載分散。
為什麼 AI API 服務需要設計「故障容忍（Fault Tolerance）」？
機器壞掉不是很少見的事嗎？為什麼要特別設計？
在大型分散式系統中，機器故障不是罕見事件，而是常態。一個有幾百台伺服器的系統，每天都會有少數機器出現各種問題（硬碟故障、網路抖動、記憶體錯誤）。設計故障容忍就是接受「故障一定會發生」，然後讓系統在故障發生時自動繞過問題，使用者感知不到中斷。
負載分散器本身壞掉怎麼辦？這不也是單點故障？
加了負載分散器，但負載分散器自己壞了，服務不還是全掛？
確實是個好問題。高可用設計通常會讓負載分散器本身也是高可用的，方法是部署一對（或多個）互備的負載分散器，透過 VRRP（虛擬路由冗餘協定）等機制，一台故障另一台自動接管。整個系統要逐層消滅單點故障。
「彈性擴縮容（Auto Scaling）」如何解決流量波動問題？
流量不固定，要一直讓很多台機器開著等待嗎？
Auto Scaling 根據即時流量自動增減實例數量。設定規則如「CPU 使用率超過 70% 就新增一個實例；低於 20% 就移除一個實例」。流量高峰自動擴容，尖峰過後自動縮容，只在需要的時候付費，兼顧效能和成本。這是雲端服務的標準做法。
想再往下看，這 5 個
- AI負載平衡（Load Balancing for AI）將 LLM 推論請求分配到多個服務實例的機制，某一實例故障時自動轉移流量，是高可用 LLM API 的核心基礎設施
- 自動擴展（Auto Scaling）根據即時流量自動增減服務實例數量，高峰時擴容、低谷時縮容，解決 LLM API 流量波動與成本控制的矛盾
- 模型服務化（Model Serving）將訓練好的 LLM 部署為可接受請求的服務端點，多實例部署是 Model Serving 實現高可用的標準架構選擇
- 推論最佳化（Inference Optimization）降低 LLM 每次推論的延遲與算力消耗，搭配負載分散讓單一 API 服務在高併發場景下仍能保持低延遲回應
- 容器化技術（Containerization）將模型服務打包成可快速複製部署的容器，是水平擴展多個 LLM 服務實例時最常用的底層基礎設施技術