搜尋意圖： 如果你在找「負載平衡器 是什麼」或「負載平衡器 和相近概念差在哪」，先看這頁的短定義、完整說明與延伸比較。
TL;DR： 將進入的網路請求或運算工作分配到多台伺服器的基礎設施元件，避免單點過載並提升系統可用性。
實用情境： 適合用在閱讀 AI 文章、產品文件或和同事討論時，先用一頁快速對齊概念。
下一步： 先讀完定義，再往下看延伸比較與對應工具，把概念轉成實際應用。
將進入的網路請求或運算工作分配到多台伺服器的基礎設施元件，避免單點過載並提升系統可用性。
負載平衡器（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 服務架構的必要知識。
常見問題
為 AI 推論服務設計負載平衡器時，和一般 Web 服務有什麼不同？
AI 推論（特別是 LLM 推論）有幾個特殊性需要考量。第一，請求處理時間差異極大，短提示詞和長文件摘要的延遲可能差數十倍，因此應優先考慮「最少連線」或「最短回應時間」等動態策略，而非簡單的輪詢。第二，GPU 記憶體是珍貴資源，過載不只是 CPU 或頻寬問題，還涉及 GPU 記憶體溢出（OOM）導致服務崩潰的風險，健康檢查需要包含 GPU 狀態監控。第三，LLM 的流式輸出（streaming）要求負載平衡器支援長連線（keep-alive）和 Server-Sent Events，不能在回應完成前過早關閉連線。第四，模型冷啟動時間較長，新實例加入輪換前需要較長的暖機等待期。
負載平衡和 API Gateway 有什麼區別？
兩者功能有重疊但定位不同，在現代架構中通常共存。API Gateway 是應用層的入口，主要職責包含 API 認證授權、速率限制（Rate Limiting）、請求/回應轉換、API 版本管理、以及監控記錄。負載平衡器的核心職責是流量分發到後端伺服器群，以提高可用性和吞吐量。一般架構是：客戶端 → API Gateway（負責身份驗證、限流）→ 負載平衡器（負責請求分發）→ 多個後端實例。部分雲端服務（如 AWS ALB）同時具備 L7 負載平衡和部分 API Gateway 功能，邊界有時會模糊，但核心用途仍有差異。
什麼是健康檢查（Health Check），為什麼對 AI 服務特別重要？
健康檢查是負載平衡器定期向後端伺服器發送探測請求（如 HTTP GET /health），確認伺服器是否正常運作的機制。如果某台伺服器在連續幾次探測中沒有回應或回應異常，負載平衡器會將其標記為不健康並停止分配新請求，待恢復後再重新加入。對 AI 服務特別重要的原因有：第一，模型載入到 GPU 記憶體需要數秒甚至數分鐘，健康檢查可確保只有模型完全就緒的實例才接收請求；第二，GPU OOM（記憶體不足）可能導致推論服務僵死但 HTTP 端口仍開著，深度健康檢查（如測試一個實際的推論請求）比單純的 TCP 連線檢查更能發現此類問題；第三，在自動縮放場景中，健康檢查決定了新實例何時可以接流量，直接影響服務的無縫擴展。