搜尋意圖： 如果你在找「負載均衡 是什麼」或「負載均衡 和相近概念差在哪」，先看這頁的短定義、完整說明與延伸比較。
TL;DR： 將運算請求分散至多台伺服器或 AI 推論節點的技術，以提升系統吞吐量、降低延遲並避免單點過載。
實用情境： 適合用在閱讀 AI 文章、產品文件或和同事討論時，先用一頁快速對齊概念。
下一步： 先讀完定義，再往下看延伸比較與對應工具，把概念轉成實際應用。
將運算請求分散至多台伺服器或 AI 推論節點的技術，以提升系統吞吐量、降低延遲並避免單點過載。
Load Balancing（負載均衡）在 AI 系統工程中是一個橫跨基礎設施層與模型服務層的核心議題。隨著大型語言模型與深度學習推論服務的普及，負載均衡的設計直接影響系統能否在高並發場景下穩定提供服務。
基礎概念與重要性
負載均衡的根本目的是避免資源浪費與熱點問題（Hotspot）。當 AI 服務的請求量超過單一節點的處理能力時，若無負載均衡，流量會集中於同一台伺服器，造成回應時間暴增甚至服務中斷。相對地，系統中若有部分節點閒置，算力也被白白浪費。負載均衡器（Load Balancer）介於使用者請求與後端服務叢集之間，透過特定演算法動態分配流量，使整體系統資源得到有效利用。
常見負載均衡演算法
在實務部署中有多種負載均衡策略可選用。輪詢法（Round Robin）是最簡單的策略，依序將每個請求分配給下一個節點，適合所有節點處理能力相近且請求複雜度均一的情況。加權輪詢（Weighted Round Robin）為每個節點設定不同的權重，讓處理能力較強的節點承接更多流量，適合異質硬體環境（如混用 A100 與 T4 GPU 的叢集）。最少連線法（Least Connections）將新請求路由給目前活躍連線數最少的節點，適合請求處理時間差異較大的場景（如不同長度的 LLM 推論請求）。隨機法（Random）在節點能力相近時可產生接近均勻的分配，實作簡單且無中央狀態維護成本。IP 雜湊法（IP Hash）根據客戶端 IP 決定路由，確保同一用戶的請求持續落在同一節點，適合需要會話親和性（Session Affinity）的有狀態服務。
AI 推論場景的特殊挑戰
相較於傳統 Web 服務，AI 推論的負載均衡面臨幾個獨特挑戰。第一是請求異質性（Request Heterogeneity）：LLM 推論的延遲高度依賴輸入序列長度與生成 token 數，同樣一個 API 請求可能耗時 0.5 秒或 30 秒，簡單的輪詢策略會導致長請求節點積壓嚴重。第二是 GPU 記憶體狀態：LLM 服務常使用 KV Cache（鍵值快取）儲存中間計算結果，若負載均衡器將同一對話的不同輪次路由到不同節點，KV Cache 無法複用，導致計算浪費與延遲上升。第三是批次聚合（Batching）：許多 GPU 推論框架（如 NVIDIA Triton、vLLM）支援動態批次（Dynamic Batching），可將多個請求合併成一個 GPU 批次以提高 GPU 利用率；負載均衡器需配合這個機制，避免過早分散流量導致批次難以形成。
現代 AI 推論叢集的負載均衡架構
在規模化 AI 部署中，負載均衡通常以多層架構實現。第一層是全域流量入口層，由雲端供應商的 L4/L7 負載均衡器（如 AWS ALB、GCP Cloud Load Balancing）處理 HTTPS 流量，提供 SSL 終止、DDoS 防護與地理位置路由。第二層是服務網格層，在 Kubernetes 叢集內部以 Istio 或 Envoy 等 Service Mesh 工具管理微服務間的東西向流量，支援流量百分比切分（Canary Deployment）與熔斷器（Circuit Breaker）。第三層是推論引擎內部的批次管理，如 vLLM 的 PagedAttention 機制與 Continuous Batching，在單一節點內優化多個請求的 GPU 使用效率。
與高可用性設計的關係
負載均衡是高可用性（High Availability，HA）架構的核心元件之一。透過健康檢查（Health Check）機制，負載均衡器持續探測後端節點的存活狀態；一旦偵測到節點異常（如 GPU OOM、推論服務崩潰），立即停止向該節點路由新請求，並等待節點恢復後再重新加入。這種自動故障轉移（Automatic Failover）機制確保單一節點故障不影響整體服務可用性，常見目標是達到 99.9% 甚至 99.99% 的服務可用率。
在 iPAS 考試中的考點
在 iPAS AI 應用規劃師中級考試中，Load Balancing 通常出現在 AI 系統架構設計與基礎設施規劃的題目中。考生需要理解：如何根據 AI 推論請求的特性選擇合適的負載均衡策略；在異質 GPU 環境中如何設定加權分配；以及負載均衡在 MLOps 部署管線中扮演的角色。理解負載均衡有助於在實際 AI 專案中規劃能處理峰值流量的系統架構。
實務選型考量
選擇負載均衡方案時，需同時評估吞吐量目標（每秒請求數 QPS）、延遲要求（P50/P95/P99 延遲）、會話親和性需求、成本預算以及與現有基礎設施的相容性。對於中小規模 AI 服務，Nginx 或 HAProxy 已足夠；對於大規模 LLM 服務，通常需要結合雲端負載均衡服務與 vLLM 等專為 LLM 最佳化的推論框架，以同時解決流量分配與 GPU 利用率的雙重問題。
常見問題
LLM 推論服務的負載均衡為什麼不能直接套用傳統 Web 的輪詢策略？
傳統 Web 服務的請求處理時間通常相近（毫秒級），輪詢策略能產生均勻分配。但 LLM 推論的延遲高度依賴輸入長度與生成 token 數，一個短問題可能 0.5 秒回應，一個長篇生成任務可能需要 30 秒。若使用純輪詢，長任務節點會持續積壓新請求，而短任務節點則閒置，導致部分節點過載、整體 P95 延遲大幅上升。較適合 LLM 場景的策略是最少連線法或基於佇列深度的動態路由。
KV Cache 與負載均衡的衝突如何解決？
LLM 服務為了加速多輪對話，會在節點本地快取前幾輪的 KV（Key-Value）中間計算結果。若負載均衡器在同一對話的不同輪次將請求路由到不同節點，目標節點沒有前輪的 KV Cache，需要重新計算，造成延遲上升與算力浪費。解決方案有兩種：一是使用帶會話親和性的負載均衡策略（Session Sticky），確保同一 session 的請求落在同一節點；二是採用分散式 KV Cache 共享架構（如 Mooncake、SGLang 的 Prefix Cache 機制），讓跨節點的快取也能被複用。
如何評估 AI 推論叢集的負載均衡是否正常運作？
正常運作的負載均衡表現在以下指標上：各節點的 GPU 利用率差異應在合理範圍內（如 ±15%）；節點間的活躍請求數應大致均衡；整體 P95 延遲應穩定而非隨機抖動。實務上可透過 Prometheus + Grafana 監控面板追蹤各節點的請求隊列深度（Queue Depth）、GPU 記憶體使用率（VRAM Usage）及每秒生成 token 數（Token/s Throughput）。若發現某節點持續過載而其他節點閒置，應調整負載均衡演算法或權重設定。