AI 閘道器流式回應經代理後不流式了?

劣質代理會緩衝流式回應。GateLLM 原生流式透通不緩衝,並做能力正規化,不破壞 SSE 與 tool calling。

429 是限流還是配額超了怎麼區分?

z-request-id 端到端定位 + 錯誤碼正規化,區分限流 429 與配額超 429,按症狀排障不必再猜。

中級呼叫方 + 管理員

按 z-request-id 端到端定位 401 / 403 / 404 / 502 / 503 / 逾時 / 流式中斷 / 記憶體異常 —— 不必再猜。

StackOverflow 高頻:"流式回應經代理後變成一坨"、"tool calling 的 JSON 拼不起來"、"429 到底是限流還是配額超了"、"502 是閘道器還是廠商的鍋"。

AI 呼叫排障難在:多跳路徑、流式、錯誤碼不統一,出問題不知道卡在哪一跳。

GateLLM 給每個請求分配 z-request-id,端到端串聯日誌,按症狀定位:401 / 403 看鑑權與 Header ACL,404 看路由,502 / 503 看上游健康,逾時看限流與跨海,流式中斷看緩衝與 SSE,記憶體異常看設定。

錯誤碼正規化(多廠商錯誤語義統一),流式原生透通不緩衝,Token Ops 日誌可查可匯出。