https://yennj12.js.org/yennj12_blog_V4/tags/rate-limiting/Recent content in Rate Limiting on YennJ12 Engineering BlogHugo -- gohugo.ioen-usThu, 04 Jun 2026 16:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part23-ratelimit-fairshare-zh/Thu, 04 Jun 2026 16:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part23-ratelimit-fairshare-zh/傳統 SaaS 的限流是「每分鐘最多 1,000 個請求」。 AI SaaS 的限流問題是「每分鐘最多 100 萬個 Token，但一個用戶的一個請求就可能用掉 50 萬 Token」。 請求次數限流，在 AI 系統裡完全失效。 面試情境 面試官： 「你的 B2B SaaS 將 Agent 系統開放給上千家企業使用。Gemini API 有嚴格的 TPM/RPM 限制。如果某個大客戶突然發起高頻查詢，把整個 GCP 專案的 Quota 耗盡，導致其他客戶全部收到 429 Too Many Requests。你如何在架構端設計 Fair-Share 與 Token 預算控制系統？」 一、核心問題：為什麼 AI 限流和傳統 API 限流完全不同 傳統 API 的資源消耗模型： 每個請求的成本大致相同 GET /users/123 ≈ GET /orders/456 ≈ 相同的計算資源 → 限制「請求次數（RPM/RPS）」就夠了 AI API 的資源消耗模型： 請求 A：「你好！」 → input: 50 tokens, output: 30 tokens = 80 tokens 請求 B：「請分析這份 200 頁的合約並翻譯成英文」 → input: 150,000 tokens, output: 50,000 tokens = 200,000 tokens 請求 B 消耗的資源是請求 A 的 2,500 倍！ 如果只限制請求次數（RPM）： → 請求 B 讓整個系統的 Token Quota 瞬間耗盡 → 其他 99 個正常用戶全部 429 問題量化（Gemini 1.