很多人第一次看到 RPS，會把它理解成一個很單純的數字：每秒有多少 request 進來。

這個理解沒有錯，但太薄了。

真正有用的理解是，RPS 不是只有流量大小，而是系統壓力開始被放大的第一條線。 當請求量還在服務容量以內，使用者通常感覺不到什麼問題；一旦請求量超過 capacity，系統不會立刻爆炸，而是先開始排隊，接著延遲變長，最後才出現 timeout、限流、錯誤率上升或成本突然變醜。

RPS 是什麼

RPS 是 Requests Per Second，也就是每秒請求數。

如果一個 API 在一秒內收到 100 次請求，它的 incoming RPS 就是 100。這個指標常被拿來描述網站、API、推理服務、資料服務或任何網路系統承受的流量。

但只看 RPS 本身，其實很容易誤判。

因為同樣是 100 RPS，背後可能是完全不同的壓力：

• 100 個很小、很快完成的請求
• 100 個每個都要查很多資料的請求
• 100 個都會打到下游 API 的請求
• 100 個都會觸發 AI 推理、長上下文或 GPU 工作的請求

所以 RPS 不是單獨看的數字，它要跟 每個請求的成本、系統容量、排隊狀態、延遲與錯誤率 一起看。

Capacity 才是 RPS 開始有意義的地方

假設一個服務穩定能處理 120 RPS。

當 incoming RPS 是 40、80、100 時，系統可能都很輕鬆。CPU、資料庫連線、GPU、worker pool 都還有餘裕，使用者看到的是正常回應。

但當 incoming RPS 變成 160，問題不會神奇消失。多出來的請求一定要去某個地方：

• 排進 queue
• 等 worker 有空
• 等資料庫連線
• 等 GPU batch
• 被限流
• timeout 後失敗

這就是為什麼 capacity 很重要。RPS 只有跟 capacity 放在一起，才看得出系統是健康、接近滿載，還是已經超載。

Queue 是延遲上升前最早出現的警訊

很多系統事故一開始不是錯誤率先上升，而是 queue 先變長。

請求進來的速度大於處理速度時，系統會先把多出來的工作排隊。短時間尖峰可能還好，queue 消化完就結束；但如果尖峰持續太久，queue 會越堆越高。

這時候使用者看到的不是「系統掛了」，而是「怎麼越來越慢」。

這也是很多人只看平均延遲會被騙的原因。平均值可能還可以，但 P95、P99 已經開始變醜，代表尾端使用者正在等很久。

RPS 太高不一定代表成功，也可能代表成本正在失控

對內容網站來說，高 RPS 通常是好事，代表流量進來了。

但對 API、SaaS、AI 服務來說，高 RPS 只是一半的故事。另一半是：每個 request 要花多少成本。

如果每個 request 都很便宜，高 RPS 是規模化。

如果每個 request 都會觸發昂貴查詢、模型推理、外部 API、檔案處理或人工審核，高 RPS 可能代表你正在快速燒錢。

AI 產品尤其明顯。很多 AI 功能不是「多一個 request」這麼簡單，而是多一次 token 成本、模型延遲、context 傳輸、工具呼叫、資料庫查詢與重試風險。

所以真正要看的不是「我們能不能扛 1000 RPS」，而是：

• 1000 RPS 時，P95 latency 是多少？
• queue depth 有沒有持續上升？
• error rate 是不是開始變高？
• 每個 request 的成本是多少？
• 下游系統會不會先被打爆？
• 限流策略會不會保護核心服務？

好的 RPS 設計，不是無限擴容

很多人一看到 RPS 上升，第一反應是加機器。

有時候這是對的，但不一定是最划算的。

比較好的設計會先問：

• 哪些 request 可以 cache？
• 哪些 request 可以合併？
• 哪些 request 應該排隊，而不是同步等？
• 哪些使用者或任務要優先處理？
• 哪些流量應該被 rate limit？
• 哪些下游服務需要 bulkhead 隔離？

這些問題比「再加幾台機器」更接近產品經營。因為你不是只在追求數字好看，而是在決定哪些請求值得被服務、哪些請求可以慢一點、哪些請求應該被拒絕。

一句話總結

RPS 的意思是每秒請求數，但它真正的價值不是拿來炫耀流量，而是幫你看見系統壓力如何開始累積。

當 RPS 低於 capacity，系統只是忙；當 RPS 長時間高於 capacity，queue、latency、error rate 和 cost 就會一起長出來。

所以不要只問「這個系統能扛多少 RPS」。

更好的問法是：在多少 RPS 之後，使用者體驗、系統穩定性和單次服務成本會開始變壞？