---
title: "負載均衡（Load Balancing）"
slug: load-balancing
language: zh-TW
source: https://aiterms.tw/terms/load-balancing
updated_at: 2026-06-22
tags: [系統架構, AI推論, MLOps, 基礎設施, iPAS中級, 高可用性]
ipas_term: false
---

# 負載均衡（Load Balancing）

將運算請求分散至多台伺服器或 AI 推論節點的技術，以提升系統吞吐量、降低延遲並避免單點過載。

## 完整說明

Load Balancing（負載均衡）是一種將進入系統的工作負載動態分配給多個計算資源的技術策略。在 AI 推論系統中，負載均衡負責將使用者請求路由至最合適的 GPU 推論節點或模型服務實例，確保每個節點的資源使用率維持在健康範圍內，同時兼顧回應延遲（latency）與服務可用性（availability）。常見演算法包括輪詢（Round Robin）、最少連線（Least Connections）與加權分配（Weighted Distribution）等。

## 常見問題

### 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）。若發現某節點持續過載而其他節點閒置，應調整負載均衡演算法或權重設定。

---

來源：https://aiterms.tw/terms/load-balancing
快查頁：https://aiterms.tw/terms/load-balancing
最後更新：2026/06/22
深度解說：https://aiterms.tw/learning/what-is-load-balancing