本機模型接入閘道：我們在三次 502 之後學會的事

上個月我們給內部知識庫加了一個本機 Qwen 推論服務，第一次聯調很順，第二次開始出問題：同樣的請求，有時 8 秒回傳，有時掛 60 秒後直接 502。把日誌翻出來看，不是模型的問題，是我們接入方式的問題。

**第一個坑：把直連位址寫死在業務程式碼裡。** 第一次我們讓三個業務模組各自 `http://192.168.x.x:port/v1/chat/completions` 直連推論容器。重啟一次容器、換一個連接埠，三處程式碼全要改。後來我們加了一個本機閘道（單連接埠代理，負責鑑權、模型路由、逾時控制），業務側只認一個位址。閘道掛掉是顯性故障，直連掛掉是隱性故障——每個業務模組自己默默逾時，最後表現為「功能偶爾不可用」，除錯要翻三個專案的日誌。

**第二個坑：逾時設得太寬。** 最初逾時給的是 120 秒，一次 OOM 重啟期間，請求全部卡滿 120 秒才失敗，上游連線池被打滿，連不依賴模型的功能都變慢了。我們把推論呼叫逾時壓到 15 秒，配一個同模型的備用路由（雲端），15 秒內沒回傳就切備用。切流以後整體 P95 反而降了，因為慢請求不再佔用執行緒。

**第三個坑：沒有最小驗證用例。** 聯調時我們用了一句「你好」測通了就上線。但「你好」走的是最短路徑：沒有工具呼叫、沒有長上下文、沒有串流輸出。真正出問題的是串流回應——推論容器在長輸出中途斷開時，閘道沒有正確關閉上游連線，客戶端拿到半截 JSON。後來我們固定了一個五用例的煙霧測試腳本：短問、長上下文、串流、工具呼叫、超長輸出截斷，每次改閘道設定後先跑煙霧測試再切流量。

**第四個坑：健康檢查是假的。** 最初的「健康檢查」只是看容器是不是在跑。容器活著不代表模型可用——權重載入失敗、顯示記憶體碎片化、後端 worker 卡死，容器狀態都顯示 Up。我們改成每 30 秒發一個 8 token 的最小真實推論請求，連續兩次失敗就摘除該路由並告警。真實探針上線的第二天，就抓到一次「容器 Up 但 60 秒無回應」的假健康狀態。

**第五個坑：重試把故障放大。** 閘道早期對逾時請求自動重試 3 次，一次後端變慢，請求量瞬間翻三倍，直接把本來就慢的後端壓垮，故障範圍從「偶爾逾時」擴大到「全面不可用」。後來我們把重試策略收緊：只對明確的 429/503 重試一次，逾時不重試，直接走備用路由。

共同的教訓：**推論服務是依賴，不是功能**。它和資料庫一樣，要做逾時、重試、降級和監控，而不是假設它永遠線上。現在閘道側就四塊東西：鑑權、路由表、逾時與切流、真實請求探針。核心只是一個代理行程加一個設定頁面。

真正複雜的是認清楚：本機推論的優勢是成本可控、資料不出內網，代價是它也會掛，而且經常掛得悄無聲息。把它當一個會失效的依賴來設計接入層，比糾結模型本身能省下大部分除錯時間。