01誰會呼叫這個——每個產品團隊，還是少數幾個？
每個團隊都呼叫它。gateway 是通往模型供應商的唯一一道門。每個團隊拿一把 API key，每個使用情境拿一條政策，所以 failover、配額、遮蔽都住在一個地方，而不是四十個。
免費完整指南
LLM 推論閘道
設計一套 LLM inference gateway，位於內部產品團隊與多家模型供應商／後端之間，在公司規模下處理路由、串流、配額與安全控管。
00
練習檢查點
面試節奏保持精簡,讓頁面能把注意力花在真正的設計決策上。
- 01釐清範圍
- 02需求 + 規模
- 03API + 資料模型
- 04畫出架構
- 05深入探討
- 06取捨決策
01
形塑設計的需求
不要只是陳述需求,要主動問出來。每張卡把設計限制和一句你可以在畫架構前說出口的釐清問句配成一組。
功能需求
02某個供應商開始出錯——這是誰的問題？
gateway 全權負責。每個使用情境宣告一條 schema 相容的模型 fallback 鏈，並對每個供應商做健康檢查。回應帶有 model_used 與 fallback_reason，讓呼叫方知道是哪個模型回答的。
03使用者是看著答案一個字一個字冒出來嗎——到第一個字的時間對產品重要嗎？
會直通——供應商一吐出 token，就穿過 gateway，絕不緩衝；gateway 在串流途中計量 token，讓配額與成本也看得見串流流量。
04限額是以請求數計，還是以 token 計？
看 token。一個請求可能花 100 個 token，也可能花 100,000 個，所以每個團隊拿一個每分鐘 token 速率、加一筆每月美元預算。用請求數來算，會漏掉真正的成本。
05同一個 prompt 進來一千次——就生成一千次？
不——一模一樣的重複請求可以答一次、之後重用，但只限提問的那個團隊之內；個人化或使用者專屬的流量永遠必須新鮮生成。
06供應商推出新模型版本——誰升級，何時升級？
每個團隊自訂政策。團隊可以釘住一個版本以求輸出穩定，或者供應商一出新版就跟著升。釘住版本的團隊，會在供應商宣告他們的模型棄用那天拿到一個倒數計時。
範圍外訓練或微調模型（只服務推論流量） · 打造 GPU 服務堆疊本身（那是供應商那側的事） · 終端使用者身分與 session——呼叫方是內部服務
非功能需求
01gateway 本身可以加多少延遲？
整個組織每天約 2M 個請求，而 gateway 在請求路徑上只加約 10-20 ms。首個 token 的延遲才是產品指標。gateway 絕不能成為它翻倍的原因。
02一個垂死的供應商必須多快被偵測到？
一個垂死的供應商要在幾秒內被偵測到，且是每供應商、每模型各自偵測。幾秒是產品決策。每延遲一秒，就有更多使用者請求失敗。
03從 prompt 與回應中要記錄什麼？
metadata 一律記錄：token、模型、成本、延遲、trace id。prompt 與回應內容只有在 PII（個人可識別資訊）遮蔽 hook 跑完之後才記錄。把原始 prompt 記進 log，會把 gateway 變成一起法遵事故。
04團隊的預算上限有多硬——如果請求剛好在額度邊上成群湧到，小幅超支可以容忍嗎？
上限是絕對的。一百個並行請求不能每一個都把最後一塊錢花掉。團隊的預算絕不能被一次突發衝過頭，因為這些是真的會開帳單的美元。
05凌晨兩點花費暴衝——我們多快能知道是誰、為什麼？
每一次呼叫都落進一本用量帳：團隊、使用情境、模型、token、成本，還有 cache 與 fallback 旗標。歸屬可以近乎即時地查詢。你不用等到月底再從供應商帳單去拼湊。
持續追問 —— 面試是一場對話
真實面試探得比一份整齊清單深得多。這些範圍問句,區分出真正拷問問題的人和只是背誦的人。
- 用量帳本與任何存下來的 prompt 內容必須保持可查詢多久——除錯用的幾週，還是財務稽核用的好幾年？
- 有沒有團隊在處理受監管的資料——必須留在某個區域、或永遠不能送到特定供應商的 prompt？
- 如果一個團隊把 gateway 灌爆，其他每個團隊的請求都必須不受影響嗎？
- 我們對產品團隊承諾什麼可用性——背後有沒有一份帶真實罰則的 SLA？
- 這會長多快——更多團隊、更多供應商、agent 流量——我們是照今天的每日兩百萬個請求來規劃，還是它的十倍？
02
逼出架構決策的數字
把每個估算都當成一種壓力,用來合理化一個元件:快取、佇列、分片、副本、worker pool 或退路。
成本歸屬——按 token，不是按請求
一個團隊：每日 200,000 個請求，每個約 3,000 input + 800 output token，input 每 1M 收 $3、output 每 1M 收 $15600M input × $3 + 160M output × $15 = $1,800 + $2,400 = $4,200/日 ≈ $126K/月
每請求的速率限制根本看不到這筆帳單。配額與預算必須用 token 來算，而且輸入與輸出分開計價。
failover 偵測預算
全組織的量約每日 200 萬個請求（NFR 給定）：2M ÷ 86,400 s ≈ 平均每秒 23 個請求，工作日尖峰約平均的 4 倍 ≈ 每秒 100 個請求，大多落在主要供應商上；breaker 用 10 秒滑動視窗、20% 錯誤率門檻每秒 100 個請求 × 10 s ≈ 視窗內 1,000 次呼叫；全面斷線時，1,000 的 20% = 200 個錯誤要 200 ÷ 100 ≈ 2 秒才累積到——所以在 breaker 打開前約有 200 個請求失敗
窗口長度決定你能接受多少使用者痛苦。窗口越短跳得越快，但會被一秒的小抖動搞得忽開忽關。把它當成一個產品數字來挑，並搭配 half-open 探測。
串流 vs 緩衝的第一個 token
一個 800-token 的答案以約 60 tokens/s 生成；緩衝式 gateway 在轉發前先扣住完整回應緩衝第一個 byte：800 ÷ 60 ≈ 13 s；直通第一個 token：~0.5-1 s → 感知延遲約差 15-25×
每在串流路徑上加一個同步跳點，都會被所有請求付帳——串流必須在流動中被檢查，絕不停放。
語意快取的經濟帳
全組織每日 2M 請求，精確 + 語意合計 15% 命中率，每請求約 $0.021 供應商成本（來自上面的 token 算式）300,000 次命中 × $0.021 ≈ $6,300/日 ≈ $190K/月 省下；一次命中約 50 ms 回應，而不是約 13 s
真金白銀加上巨大的延遲勝利——但每一次命中都是一次服務錯答案的機會，所以 key 必須包含租戶、模型版本與樣板版本。
半故障時的佇列深度
一次半故障把主要供應商的吞吐在尖峰約 100 requests/s 時砍半、持續 5 分鐘：100 進來、50 服務、什麼都不卸載backlog 成長 (100 - 50) × 300 s = 15,000 requests；恢復後以約 20 requests/s 的餘裕容量，排空還要約 12 分鐘
把一切都排隊，會把 5 分鐘的半故障變成約 18 分鐘的劣化與 15K 條開啟的連線——改成卸載批次流量、並讓互動流量 fail over。
決策範例
數字
四十個團隊每天兩百萬個請求，每個大約兩美分，就是每天約 $42,000 的供應商支出。而這些供應商裡的每一個，都會在這個月的某一週故障個幾分鐘。
我的選擇
我會建一條 gateway 路徑。它先驗證團隊身分，按預算預留 max_tokens，先查精確比對、再查語意 cache，依使用情境的模型鏈路由、並帶一個每供應商的錯誤率斷路器，然後把供應商的 token 直接串流出去，同時在串流過程中計量。用量結算進一本每團隊的帳。prompt 內容只有在遮蔽 hook 跑完之後才碰 log。模型版本是每團隊政策——釘住版本並附棄用倒數，或者在 eval canary 後面自動升級。
避免
我不會做的事。第一，讓團隊直接呼叫供應商——那是四十套 failover 實作、加上零共享歸屬。第二，用請求數來算配額，因為一個 100-token 的 ping 跟一個 100,000-token 的 agent 迴圈根本不是同一筆花費。第三，把串流緩衝起來檢查。一個等整份回應才動作的 gateway，會把 1 秒的首個 token 變成 13 秒的沉默。
何時改變
如果只有一個團隊、一個模型、每月四位數的花費，一個帶重試的輕薄共享 client library 才是誠實的答案。只有當團隊、供應商、或花費倍增時，gateway 才對得起它的複雜度。
03
架構路徑
先看一張完整的圖,再把每條路徑各自畫成一張圖 —— 寫入路徑與讀取路徑承載不同流量,合理化不同的元件。
完整全貌
總覽 —— 每個元件
熱路徑是 auth → 預留預算 → cache → 路由 → 串流；帳本結算與健康記帳在它之外。一次 breaker 跳閘只改變路由器的選擇——呼叫方維持同一份合約，只會看到 model_used 改變。
路徑 1
快取未命中的串流——預留、路由、把 token 直通過去
gateway 在 token 流動時計數，並在串流結束時把帳本從預留結算成實際——配額與成本看串流流量就跟看阻塞呼叫一模一樣。
路徑 2
半故障——breaker 在使用者察覺前就跳閘
fallback 必須與主要模型 schema 相容，而回應會說是哪個模型回答的——無聲替換會弄壞每一個依賴輸出形狀的團隊。
04
API 與資料模型
在最佳化之前,先讓契約可被檢視:端點、實體、擁有權、重試與狀態。
POST/v1/responses
請求{ use_case, messages, max_tokens, stream: true, output_schema? }
回應SSE token 串流；trailers 帶有 model_used、token 數、成本、cache/fallback 旗標
團隊身分來自 API key，永不來自 request body——每家供應商前面都是同一份合約，所以換供應商永遠不動到產品程式碼。
GET/v1/usage (team_id, window=month)
回應{ tokens, cost_usd, by_model, by_use_case }
把成本歸屬當成產品功能——團隊主管與財務讀這個，而不是供應商發票。
PUTinternal: policy(team_id, changes)
回應熱重載的政策：pins、預算、模型鏈、kill switch
關掉一個失控的團隊是一次 config 寫入，不是一次緊急部署。
核心實體
TeamPolicyteam_id (PK) · use_case · model_chain (primary → fallbacks) · version_policy: pinned/auto · tokens_per_min · monthly_budget_usd · redaction_profile
可熱重載——一次預算變更或一個 kill switch 不能等到部署。
UsageLedgerEntryrequest_id (PK) · team_id · model_used · input_tokens · output_tokens · cost_usd · cache_hit · fallback_reason?
歸屬的真實來源——呼叫前先以預留寫入，呼叫後結算成實際值。
ProviderHealthprovider + model · error_rate (sliding window) · p95 latency · breaker: closed/open/half-open
路由器在每次派送前讀的東西；half-open 探測決定何時允許流量回來。
CacheEntryembedding key · tenant_scope · model + template version · response · ttl
只要忽略這些 key 的任何一個，就會出貨一個陳舊或跨租戶的答案。
05
深入方向
在面試最後三分之一挑一條路線。每條路線給你主題、它該回答的面試官問題,以及要避免的失敗模式。
串流途中供應商暴斃
問
一個串流在 800 個 token 的第 400 個時因供應商 500 而斷掉。客戶端看到什麼，而你能不能對一個進行中的生成做 failover？
回答
用一個明確的錯誤事件把串流收掉。絕不要無聲斷掉，也絕不要接上另一個模型的 token——它接不完那句寫到一半的話。生成沒辦法中途續接，所以 failover 就是在備援上明確地重新開始。那通掛掉的呼叫，就照它產出的 400 個 token 在帳上結算。
避免
悄悄在供應商 B 上重新生成並把 token 接起來——客戶端已經渲染了半個答案，而新模型不會產生同樣的接續；resume 是一次 restart，必須明確。
預算週二就沒了
問
某個團隊失控的 agent 迴圈在兩天內燒光了組織的整月預算。按照它們應該觸發的順序，走一遍本該存在的控制。
回答
先跑 reserve-then-settle 檢查。每通呼叫先預留它的 max_tokens，結束後再按實際用量結算，這樣並行的迴圈就不會全部去花同一塊最後的錢。接著，每個團隊每分鐘的 token 上限會拖慢迴圈。一個以每小時多少錢計的燃燒率（burn-rate）警報，第一天就能抓到它——每月上限只是最後一道防線。
避免
把月結發票當成唯一的控制——逐次呼叫 token 計量、逐團隊上限、以及對燒錢速率（每小時美元對基線）的警示，會在第一天而不是第三十天抓到它。
快取說謊
問
使用者把 prompt 裡一個關鍵字改掉，卻仍拿到舊 prompt 的快取答案。語意快取哪裡出錯，什麼在約束它？
回答
錯就錯在只信相似度。否定詞在 0.98 cosine similarity 下就能把意思整個翻過來，所以幾乎一模一樣的 prompt 並不是同一個 prompt。先做完全比對，語意那一層不確定時就讓它 miss。每一筆都要用 key 界定範圍：tenant、模型版本、樣板版本。把個人化的流量擋在外面，並給每次命中一個 TTL。
避免
把相似度門檻當成整個安全故事——否定在 0.98 cosine 相似度下就翻轉了意思；key 需要租戶、模型與樣板版本，個人化流量排除在外，命中還要帶 TTL。
模型退役
問
供應商宣布你釘住的模型 90 天後死亡。那是誰的問題，而 gateway 的升級路徑長什麼樣？
回答
gateway 把它攤出來；由團隊決定。倒數是從供應商宣布那天開始，不是到第 90 天才開始。接著一道評測關卡：拿團隊的黃金 prompt 在新版本上重放，再用一小片實際流量做 canary，團隊簽核後才切換。悄悄把一個鎖版本的團隊自動升級，等於毀掉他們當初鎖版本要的那份穩定。
避免
無聲地自動升級每個人——為輸出穩定而釘住的團隊，會拿到針對他們自己黃金 prompt 的 eval gate、一個 canary 切片、以及一次簽核，並從第一天就把倒數攤開來。
審核稅
問
安全在生成前加了一個同步審核呼叫，first-token 延遲翻倍。你如何同時保住護欄與延遲預算？
回答
把檢查並行跑，別擋在前面。輸入審核和路由、供應商分派一起發動，失敗就取消生成。這樣它的延遲就藏在本來就在跑的工作後面。輸出方面，用滾動視窗掃串流，並設一個中途硬切斷的上限——別為了到最後才檢查，把一個 13 秒的回答整個緩衝起來。
避免
把每個檢查都串在供應商呼叫前面——input 檢查與路由並行跑，output 審核則以滾動視窗掃描串流並設一個 cut-off，而不是緩衝整個答案。
準備好練習了嗎?
把 LLM 推論閘道 大聲講一遍,讓 AI 為你的說明評分。