Container Compute Service：基於產生式AI請求的Token數進行全域限流

功能說明

基於Token數的全域限流策略依賴於Gateway with Inference Extension的兩項基礎能力：

• 全域限流：全域限流功能基於令牌桶演算法。預設情況下，每個HTTP請求會消耗一個令牌。在此基礎上，支援使用者自訂每個請求消耗的令牌數。

• 產生式AI可觀測外掛程式：該外掛程式可以從產生式AI應用的響應中讀取Token數量，並作為限流依據。

前提條件

• 已安裝1.4.0版本的Gateway with Inference ExtensionGateway with Inference Extension並勾選啟用Gateway API推理擴充。操作入口，請參見安裝組件。

• 已部署mock-vllm應用。

• 已部署產生式AI可觀測外掛程式。

• 已開啟全域限流。

部署限流規則

本樣本將示範為mock-vllm應用建立限流規則，限制每個使用者每小時最多消耗300個Token。

1. 建立token-ratelimit-test.yaml。

   apiVersion: gateway.envoyproxy.io/v1alpha1
   kind: BackendTrafficPolicy 
   metadata:
     name: token-ratelimit-test
   spec:
     targetRefs:
     - group: gateway.networking.k8s.io
       kind: HTTPRoute
       name: mock-route
     rateLimit:
       type: Global
       global:
         rules:
         - clientSelectors:
           - headers:
             - name: x-user-id
               type: Distinct
           limit:
             requests: 300
             unit: Hour
           cost:
             response:
               from: Metadata
               metadata:
               # ACK Gateway的產生式AI可觀測外掛程式設定的指標
                 namespace: FILTER_STATE
                 key: wasm.gen_ai.completion.tokens

2. 部署限流規則。

   kubectl apply -f token-ratelimit-test.yaml

發起測試

1. 擷取網關IP。

   export GATEWAY_ADDRESS=$(kubectl get gateway/mock-gateway -o jsonpath='{.status.addresses[0].value}')
   echo ${GATEWAY_ADDRESS}

2. 從sleep應用發起測試請求，連續訪問5次。

   kubectl exec deployment/sleep -it -- curl -X POST ${GATEWAY_ADDRESS}/v1/chat/completions -H 'Content-Type: application/json' -H "host: example.com" -d '{
       "model": "mock",
       "max_completion_tokens": 100,
       "temperature": 0,
       "messages": [
         {
           "role": "user",
           "content": "introduce yourself"
         }
       ]
   }' -v -H "x-user-id: one" |grep "^< HTTP"

   預期輸出：

   < HTTP/1.1 200 OK
   < HTTP/1.1 200 OK
   < HTTP/1.1 200 OK
   < HTTP/1.1 200 OK
   < HTTP/1.1 429 Too Many Requests

   可以看到，前4次請求均返回200響應碼，第5次請求返回429。

   這是由於mock-vllm應用會為每個請求返回一個固定長度的響應，響應的Token數為76。 訪問3次後，一共消耗了228個Token，此時並未超出限額，因此第4次訪問依舊會成功。 第4次訪問完成後，一共消耗了304個Token，此時超出了限額。第5次訪問返回429 Too Many Requests。

相關文檔

除了上述的“分使用者Token限流”外，您可以通過閱讀以下文檔，來實現更加豐富的限流策略：

• 觀測產生式AI請求

• BackendTrafficPolicy Ratelimit欄位配置參考