限流與排隊：流量尖峰時怎麼不整個垮掉

一般 Web 服務在超載時會變慢；模型服務在超載時會全部變慢——因為所有請求共享同一批 GPU 記憶體與批次槽位。結果是每個人都等很久，沒有人拿到結果。

三道閘

1. 入口限流：依使用者或 API 金鑰限制每分鐘請求數，超過直接回 429。
2. 佇列上限：等待中的請求超過上限就拒絕新請求，而不是無限排隊。
3. 單請求上限：限制輸入長度與 max_tokens，避免單一巨大請求佔住資源。

MAX_QUEUE = 200

async def handle(req):
    if queue.qsize() >= MAX_QUEUE:
        return JSONResponse({'error': 'server_busy',
                             'retry_after': 5}, status_code=503,
                            headers={'Retry-After': '5'})
    return await queue_and_wait(req)

快速失敗比慢慢等好

使用者等 40 秒後拿到逾時錯誤，體驗比 2 秒內收到「系統忙碌，請稍後再試」差得多，而且前者還白白消耗了資源。

分級服務

• 互動式請求優先，批次任務可以延後。
• 付費使用者較高配額——這也是限流最自然的商業用途。
• 尖峰時自動降級：改用較小的模型、縮短輸出上限。