負載平衡器 是什麼？
Load Balancer：負載平衡器 的完整解釋
將進入的網路請求或運算工作分配到多台伺服器的基礎設施元件，避免單點過載並提升系統可用性。
負載平衡器（Load Balancer）是現代雲端架構與 AI 服務部署中不可或缺的基礎設施元件。當 AI 應用需要服務大量用戶、提供穩定的推論延遲，並在部分伺服器故障時仍能持續運作時，負載平衡器就扮演著交通指揮的角色。
負載平衡器的核心功能是「請求分發」。它位於用戶端（客戶端）與後端伺服器群（server pool）之間，接收所有進入的請求，再依照設定的分配策略轉發到不同的後端實例。從用戶端的角度看，它只與一個固定的 IP 位址或域名互動；負載平衡器背後的多台伺服器對用戶端而言是透明的。
常見的負載平衡演算法有以下幾種：
輪詢（Round Robin）是最簡單的策略，依序將請求分配給每台伺服器，每台伺服器輪流接收相同數量的請求。適合各伺服器性能相近、請求處理時間均勻的場景。
加權輪詢（Weighted Round Robin）在輪詢基礎上為每台伺服器設定權重，性能較強的伺服器獲得更多請求。適合後端伺服器規格不一致的情況，例如混合不同 GPU 型號的推論集群。
最少連線（Least Connections）將新請求分配給當前活躍連線數最少的伺服器，適合請求處理時間差異較大的場景，如 AI 推論請求（不同長度的提示詞處理時間可能差異數倍）。
IP 雜湊（IP Hash）根據客戶端 IP 位址計算雜湊值，確保同一個客戶端的請求始終路由到同一台伺服器，適合需要保持會話狀態（session affinity）的應用。
最短回應時間（Least Response Time）選擇當前平均回應時間最短且活躍連線最少的伺服器，在 AI 推論場景中常用於動態適應不同 GPU 的負載狀態。
從 AI 應用部署的角度，負載平衡器有幾個特別重要的考量：
GPU 工作負載的特殊性：AI 推論任務（特別是大型語言模型的推論）消耗大量 GPU 記憶體與算力，且不同請求的處理時間差異極大（短提示詞可能毫秒完成，長文件摘要可能需要數十秒）。傳統基於請求數量的輪詢策略在此情況下效果欠佳，以連線數或回應時間為基礎的策略更為適合。
模型服務的熱身問題：大型模型（如 LLM）在首次載入 GPU 記憶體時需要「熱身」時間，負載平衡器的健康檢查（health check）機制應等待模型完全就緒後才將實例加入輪換，避免請求在模型尚未載入完成時送到新實例。
批次推論（Batch Inference）的整合：部分 AI 推論服務器（如 NVIDIA Triton Inference Server、vLLM）支援動態批次（dynamic batching），將多個請求合併成一個批次後同時推論，提高 GPU 利用率。負載平衡器需要與此機制配合，避免過度細分請求導致批次效益喪失。
水平擴展（Horizontal Scaling）與自動縮放（Auto Scaling）：在請求量暴增時，雲端平台可以自動啟動新的 AI 推論實例，負載平衡器需要即時感知新實例加入並開始分配流量；在負載降低時，新實例則被移除。這種彈性能力是 AI 服務成本控制的關鍵。
負載平衡器在架構上可分為第四層（L4）與第七層（L7）兩種類型。L4 負載平衡器在 TCP/UDP 層運作，效能高但無法感知 HTTP 協議細節；L7 負載平衡器（如 Nginx、AWS ALB）在應用層運作，可以根據 HTTP 請求的路徑、Header 或內容進行更細粒度的路由，例如將不同模型版本的請求路由到不同的實例群。
在 AI 應用的微服務架構中，負載平衡器通常是 API Gateway 的下游，或與服務網格（Service Mesh，如 Istio）整合，實現更精細的流量控制，如金絲雀部署（Canary Deployment，逐步將部分流量切到新版模型）與藍綠部署（Blue-Green Deployment，零停機切換模型版本）。
IPAS AI 應用規劃師考試中，負載平衡器相關考題通常考核考生對 AI 服務可靠性、擴展性設計的理解，以及基本的雲端基礎設施概念。理解負載平衡器如何與 GPU 集群配合，是規劃可擴展 AI 服務架構的必要知識。