1. 為什么我要自己造一個 LLM 推理網關1.1 從一次線上事故說起去年年底我在幫一個內部工具做 AI 能力接入。架構很簡單前端一個聊天框后端一個 Go 服務收到請求后轉發(fā)給上游的大模型接口拿到流式響應再吐回給瀏覽器。上線第一周沒什么問題第二周開始陸續(xù)有用戶反饋“回答到一半就卡住了”“刷新之后重新問一遍才行”。我去翻日志發(fā)現(xiàn)兩類報錯反復出現(xiàn)。一類是stream disconnected before completion: idle timeout waiting for SSE另一類是上游返回400: {type:missing_session_id,message:error from provider}。前者說明流式連接在傳輸過程中被靜默掐斷了后者說明會話狀態(tài)在轉發(fā)鏈路上丟了。這兩個問題單獨看都不復雜但它們暴露的是同一個根因我把“轉發(fā)”這件事想得太簡單了。一個真正能扛住生產流量的 LLM 推理網關至少要解決四件事SSE 流式轉發(fā)的正確性、客戶端斷開時的級聯(lián)取消、上游生產速度超過下游消費速度時的背壓控制、以及會話與錯誤狀態(tài)的一致性維護。這四件事在普通 HTTP 轉發(fā)里幾乎不用考慮但在 LLM 場景下全部變成了一等公民。這篇文章就是我把這套網關從零重寫一遍的完整記錄包含設計取舍、關鍵代碼結構、參數計算和踩過的坑。1.2 這個網關到底解決什么問題先把定位說清楚。它不是模型推理框架不負責加載權重、不做 batch 調度它站在客戶端和上游推理服務之間干的是“流量治理”的活。你可以把它理解成一個專門為流式 LLM 響應優(yōu)化的反向代理層。它要解決的核心痛點有這么幾個。第一LLM 響應是逐 token 生成的一個請求可能持續(xù)幾十秒甚至幾分鐘傳統(tǒng)的“收完再轉發(fā)”模式完全不可用必須邊收邊轉。第二用戶隨時可能關掉頁面或點“停止生成”這時候如果網關不主動取消上游請求上游會繼續(xù)燒算力成本直接翻倍。第三上游生成速度快、下游網絡慢的時候如果沒有背壓機制內存里的緩沖區(qū)會無限膨脹最后 OOM。第四SSE 協(xié)議本身對連接中斷很敏感任何中間環(huán)節(jié)的超時設置不當都會導致“流斷在半路”。適合讀這篇的人正在做 AI 應用后端、需要自己搭一層網關的 Go 開發(fā)者被 SSE 斷流問題折磨過的同學以及想理解“級聯(lián)取消”和“背壓”這兩個詞在真實系統(tǒng)里到底怎么落地的人。不需要你是 Go 專家但至少要寫過 HTTP 服務知道 goroutine 和 channel 大概是怎么回事。1.3 技術選型為什么是 Go為什么是 SSE選 Go 的理由很直接。這個網關的本質是高并發(fā) I/O 密集型轉發(fā)每個請求都要維持一條長連接同時可能有成百上千個請求在飛。Go 的 goroutine 在這種場景下幾乎是降維打擊——每個連接一個 goroutine寫起來像同步代碼跑起來是異步性能內存占用還低。換成 Java 要處理線程池和回調地獄換成 Node 單線程又怕 CPU 密集的解析拖垮事件循環(huán)。Go 的net/http標準庫對流式響應的支持也很成熟Flusher接口直接就能把緩沖區(qū)刷給客戶端。選 SSE 而不是 WebSocket是因為 LLM 的場景是單向流式推送。客戶端發(fā)一次請求服務端持續(xù)推 token不需要雙向實時通信。SSE 基于普通 HTTP天然穿透各種代理和負載均衡實現(xiàn)成本低瀏覽器端EventSource或者fetch加流讀取都能處理。WebSocket 雖然更靈活但要處理握手升級、心跳保活、幀解析對這個場景來說是過度設計。熱搜詞里有人問“web socket 和 sse”的區(qū)別一句話總結需要服務端主動推、且只需要單向推選 SSE需要雙向低延遲交互選 WebSocket。2. 整體架構與核心設計思路2.1 三層結構接入層、轉發(fā)層、上游適配層我把網關拆成三層每層職責單一方便單獨測試和替換。接入層負責和客戶端打交道解析請求、校驗參數、建立 SSE 響應頭、管理客戶端連接的生命周期。這一層最關鍵的是拿到一個context.Context它會在客戶端斷開時被 cancel這個 context 會一路往下傳成為級聯(lián)取消的源頭。轉發(fā)層是核心負責從上游讀取流、解析 SSE 事件、寫入下游。它要同時監(jiān)聽兩個方向上游的數據到達、下游的寫入完成。這里我用一個io.Pipe或者帶緩沖的 channel 來解耦讀寫速率背壓邏輯就藏在這個緩沖區(qū)的大小和阻塞行為里。上游適配層負責和具體的推理服務對接拼裝請求體、處理鑒權、解析不同廠商的響應格式。因為不同上游的 SSE 事件格式不一樣有的用data:有的用event:加data:這一層做歸一化把上游格式轉成統(tǒng)一的內部事件結構再交給轉發(fā)層。這樣分層的好處是換上游只需要改適配層背壓和取消邏輯完全不用動。我實測下來接一個新的上游服務適配層大概 100 行代碼就能搞定。2.2 級聯(lián)取消一個 context 串起整條鏈路級聯(lián)取消這個詞聽起來玄乎本質就是一個取消信號沿著調用鏈往下傳每一層都響應它。在 Go 里就是context.Context的 cancel 機制。具體到我的網關客戶端發(fā)起請求接入層用r.Context()作為根 context。這個 context 在客戶端斷開連接時會被 HTTP server 自動 cancel。轉發(fā)層拿著這個 context 去請求上游用的是http.NewRequestWithContext。于是當客戶端斷開根 context 被 cancel上游請求的 context 也跟著 cancelhttp.Client會立即關閉到上游的連接。上游服務收到連接關閉也就停止生成了。這里有個坑我踩過如果你用的是自己管理的http.Client并且設置了連接池cancel 之后連接不一定會立刻關閉可能會被復用。解決辦法是在請求上游時給 context 加一個明確的超時并且確保Transport的DisableKeepAlives在長連接場景下配置正確。另外goroutine 泄漏是級聯(lián)取消沒做好的典型癥狀——客戶端斷了但讀上游的 goroutine 還阻塞在Read上。我的做法是每個轉發(fā) goroutine 都select監(jiān)聽ctx.Done()一旦收到信號立即返回。2.3 背壓讓快的一方等一等慢的一方背壓是流式系統(tǒng)里最容易被忽略、出問題又最致命的一環(huán)。想象一個場景上游模型生成速度是每秒 100 個 token下游用戶的網絡只能每秒接收 20 個 token。如果沒有背壓網關內存里會堆積越來越多的未發(fā)送數據一個請求堆幾 MB一千個并發(fā)就是幾個 GBOOM 是遲早的事。背壓的核心思想是用阻塞傳遞壓力。當緩沖區(qū)滿了寫入方就應該阻塞直到消費方騰出空間。在 Go 里帶緩沖的 channel 天然支持這個語義ch - data在緩沖滿時會阻塞當前 goroutine。我把上游讀到的每個 SSE 事件寫進一個容量固定的 channel下游從 channel 里讀并寫回客戶端。channel 滿了上游讀取 goroutine 就阻塞自然就“背壓”到了上游——因為我不再從上游 socket 讀數據TCP 接收窗口會逐漸縮小最終上游的發(fā)送也會被阻塞。緩沖區(qū)容量怎么定這是個需要計算的參數。我按“單事件平均大小 × 期望緩沖事件數”來估。實測一個 token 事件大約 200 字節(jié)到 1KB我取 512 字節(jié)均值。如果希望緩沖 64 個事件容量就是 32KB 左右。但 channel 存的是事件對象不是字節(jié)所以我按事件個數設容量64 到 128 之間比較合適。太小會導致頻繁阻塞、吞吐下降太大則失去背壓意義、內存風險上升。3. SSE 流式轉發(fā)的核心實現(xiàn)細節(jié)3.1 SSE 協(xié)議要點與常見誤區(qū)SSE 的協(xié)議格式其實很簡單但細節(jié)坑很多。一個標準的事件長這樣event: message data: {content: 你好} data: {content: 世界}注意幾個點。第一每個字段后面跟一個冒號和空格然后才是值。第二事件之間用空行分隔也就是連續(xù)兩個換行符。第三data:可以出現(xiàn)多次會被拼接成多行數據。第四注釋行以冒號開頭常用來做心跳?；睢Ｗ畛Ｒ姷恼`區(qū)是換行符處理。SSE 規(guī)范要求用\n但有些上游用\r\n如果你解析時不兼容就會把\r當成數據的一部分導致 JSON 解析失敗。我的做法是解析前統(tǒng)一把\r\n替換成\n。另一個誤區(qū)是忘記 flush。Go 的http.ResponseWriter默認會緩沖你不調用Flusher.Flush()數據就卡在緩沖區(qū)里客戶端一直收不到表現(xiàn)就是“流不動”。每個事件寫完后必須 flush這是硬性要求。還有一個容易被忽略的點響應頭必須設置Content-Type: text/event-stream并且要禁用各種中間層的緩沖。我一般還會加上Cache-Control: no-cache和X-Accel-Buffering: no后者是給 Nginx 看的告訴它不要緩沖這個響應。熱搜里那個curl sse的調試方法很實用用curl -N就能看到實時的流式輸出-N是禁用 curl 自己的緩沖。3.2 上游讀取逐行掃描與事件組裝從上游讀 SSE 流我用的是bufio.Scanner逐行讀。為什么不一次性ReadAll因為流是持續(xù)的ReadAll會一直等到連接關閉那就完全失去流式意義了。掃描的邏輯是讀一行如果是空行說明一個事件結束把累積的data字段組裝成完整事件發(fā)出去如果是以data:開頭去掉前綴存起來如果是event:開頭記錄事件類型其他行忽略。這里要注意bufio.Scanner默認的單行長度上限是 64KB如果上游某個事件特別大比如返回了很長的 JSON會報token too long。解決辦法是用scanner.Buffer把上限調大我一般設成 1MB。組裝事件時有個細節(jié)多個data:行要用\n連接這是規(guī)范要求。我見過有人直接用拼接不加換行結果 JSON 里少了換行導致解析出錯。另外上游可能在流中間插入心跳注釋行以:開頭這些要直接跳過不能當成數據。3.3 下游寫入錯誤處理與優(yōu)雅收尾往下游寫的時候最怕的是寫了一半客戶端斷了。這時候Write會返回錯誤你必須立即停止并且觸發(fā)取消上游。我的處理是每次Write都檢查 error一旦非 nil就 cancel 根 context 并 return。同時Flush也可能出錯同樣要檢查。優(yōu)雅收尾指的是流正常結束時要發(fā)一個明確的結束事件。有些客戶端依賴特定的結束標記來判斷“生成完成”。我一般會發(fā)一個event: done加空 data或者直接關閉連接。但要注意關閉連接前要確保所有緩沖數據都 flush 出去了否則最后幾個 token 會丟。我踩過一次坑上游發(fā)完最后一個 token 后立即關閉連接我的掃描循環(huán)退出但最后一個事件還在 channel 里沒被下游消費結果用戶看到的是“回答少了一個字”。解決辦法是掃描循環(huán)退出后先關閉 channel讓下游把剩余事件消費完再結束響應。4. 級聯(lián)取消與背壓的落地實現(xiàn)4.1 取消信號的傳播路徑與 goroutine 管理一個請求進來我至少會起兩個 goroutine一個讀上游一個寫下游。這兩個 goroutine 通過 channel 通信。取消信號要從根 context 傳到這兩個 goroutine。讀上游的 goroutine 里scanner.Scan()是阻塞的它不響應 context。所以我不能只靠select ctx.Done()因為 Scan 卡住的時候 select 根本沒機會執(zhí)行。解決辦法是在單獨的 goroutine 里做 Scan主循環(huán) select 監(jiān)聽結果 channel 和 ctx.Done()?；蛘吒唵谓o上游請求設置 context當 context cancel 時底層的resp.Body會被關閉Scan()會返回 false循環(huán)自然退出。這是最干凈的做法依賴http.Client對 context 的支持。寫下游的 goroutine 里Write和Flush也可能阻塞下游網絡慢。這時候如果客戶端斷開Write會返回錯誤goroutine 退出。但如果它阻塞在 Write 上context cancel 不會直接中斷它。所以我在寫之前會先select檢查一次 ctx寫完再檢查一次盡量縮短阻塞窗口。極端情況下依賴 HTTP server 的連接關閉來中斷 Write。goroutine 泄漏的排查我用go tool pprof看 goroutine profile如果發(fā)現(xiàn)某個函數對應的 goroutine 數量持續(xù)增長基本就是泄漏了。常見原因是 channel 沒人讀導致發(fā)送方永久阻塞或者 context 沒傳到位。4.2 背壓緩沖區(qū)的容量計算與動態(tài)調整前面說了用帶緩沖 channel 做背壓容量我定在 64。但這個值不是拍腦袋來的我做了個簡單的計算。假設單個事件平均 512 字節(jié)64 個事件就是 32KB。單請求內存占用 32KB 緩沖 goroutine 棧約 8KB 其他開銷算 50KB。1000 并發(fā)就是 50MB完全可控。如果容量設成 1024單請求就是 512KB1000 并發(fā) 512MB風險就大了。所以 64 是個內存和吞吐的平衡點。但固定容量有個問題不同上游的生成速度差異很大。有的模型每秒吐 200 個 token有的只有 10 個。對慢上游64 的緩沖綽綽有余對快上游可能頻繁觸發(fā)背壓。我的優(yōu)化思路是根據上游響應頭里的速率提示或者前 N 個事件的到達間隔動態(tài)調整容量。不過實測下來固定 64 在大多數場景已經夠用動態(tài)調整的復雜度收益比不高我就沒上。如果你要接的上游特別快可以調到 128 或 256但要同步監(jiān)控內存。還有一個細節(jié)channel 關閉的時機。讀上游的 goroutine 結束時關閉 channel寫下游的 goroutine 用for range ch消費channel 關閉后循環(huán)自動退出。這樣不需要額外的 done 信號邏輯很干凈。但要注意關閉 channel 的只能是發(fā)送方多個發(fā)送方時要用sync.Once或者 WaitGroup 保證只關一次。4.3 超時策略idle timeout 與總超時的配合熱搜里那個idle timeout waiting for SSE報錯根因就是超時設置不當。LLM 流式響應有個特點首 token 可能等很久但 token 之間間隔很短。如果你設一個總超時 30 秒那長回答直接被砍如果你設一個 idle 超時多久沒數據就斷那首 token 等待期可能誤傷。我的策略是雙超時。一個 idle timeout比如 60 秒只要 60 秒內有任何數據到達就重置一個總超時比如 10 分鐘兜底防止請求永遠掛著。idle timeout 用time.Timer實現(xiàn)每次讀到數據就Reset?？偝瑫r直接用 context 的WithTimeout。這里有個坑time.Timer的Reset在 Go 1.23 之前有競態(tài)問題需要先Stop再 drain channel。Go 1.23 之后Reset語義修正了可以直接用。如果你用的是老版本記得處理這個細節(jié)。另外idle timeout 觸發(fā)后要發(fā)一個明確的錯誤事件給客戶端而不是直接斷連這樣前端能給出友好提示。5. 常見問題排查與避坑實錄5.1 流斷在半路從現(xiàn)象到根因的排查路徑“流斷在半路”是我遇到最多的問題排查起來有一套固定路徑。第一步確認是上游斷還是下游斷。看日志里最后一條成功轉發(fā)的事件如果上游還在發(fā)但下游沒收到問題在下游寫入或網絡如果上游本身就不發(fā)了問題在上游或網關到上游的連接。第二步檢查超時配置。idle timeout和中間層Nginx、負載均衡的超時都要看。Nginx 默認proxy_read_timeout是 60 秒如果你的 idle timeout 也是 60 秒兩者疊加可能提前觸發(fā)。我一般把網關的 idle timeout 設得比中間層小讓網關先感知、先處理。第三步看連接是否被復用。HTTP/1.1 的 keep-alive 在長連接場景下可能導致連接被錯誤復用尤其是上游返回了不完整的響應時。我一般對上游請求設置Connection: close或者禁用 keep-alive犧牲一點性能換穩(wěn)定性。第四步抓包確認。用tcpdump或者 Go 的httptrace看 TCP 層的 FIN/RST 是誰先發(fā)的。這一步能定位到具體是哪一端的連接被關閉。5.2 會話丟失與 400 錯誤的處理熱搜里那個missing_session_id的 400 錯誤本質是會話狀態(tài)在轉發(fā)鏈路上沒有正確傳遞。LLM 服務通常用 session id 來關聯(lián)多輪對話的上下文。如果網關在轉發(fā)時丟了 header 或者 cookie上游就找不到會話。我的處理是接入層把所有和會話相關的 header比如X-Session-Id、Authorization、Cookie原樣透傳到上游不做任何過濾。同時如果上游返回 400 且錯誤信息里提到 session我會在網關層記錄一條明確的日志包含請求 id 和原始 header方便排查。還有一種情況是上游要求 session id 在請求體里而不是 header 里。這時候適配層要做轉換從 header 提取出來塞進 body。這個邏輯因上游而異我把它做成可配置的用配置文件描述“從哪取、放到哪”。5.3 常見問題速查表現(xiàn)象可能原因排查方法解決方向流不動客戶端無數據忘記 Flush檢查寫入后是否調用 Flush每個事件后強制 Flush流斷在半路idle timeout 或中間層超時對比網關和 Nginx 超時配置網關超時設小先感知回答少最后一個字channel 關閉時機不對檢查掃描退出后是否消費完剩余事件先關 channel 再結束響應內存持續(xù)增長背壓失效或 goroutine 泄漏pprof 看 goroutine 和 heap檢查 channel 容量和 context 傳遞400 missing session會話 header 丟失對比客戶端和上游收到的 header透傳會話相關 headerJSON 解析失敗換行符或 data 拼接問題打印原始事件內容統(tǒng)一換行符多行 data 用 \n 連接上游不停止生成級聯(lián)取消未生效檢查上游請求是否用了根 context用 NewRequestWithContext5.4 幾個我踩過的獨家坑第一個坑bufio.Scanner的默認緩沖太小。上游返回一個大的 JSON 事件時直接報錯退出表現(xiàn)就是流突然斷。調大scanner.Buffer的 max 到 1MB 解決。第二個坑http.Flusher不是所有 ResponseWriter 都支持。如果你用了某些中間件包裝了 ResponseWriter可能拿不到 Flusher。我的做法是在接入層用類型斷言檢查拿不到就報錯絕不靜默降級。第三個坑context 傳遞時被意外覆蓋。有一次我在適配層里用context.Background()新建了請求結果級聯(lián)取消完全失效客戶端斷了上游還在跑。排查了半天才發(fā)現(xiàn)是這里。教訓是任何地方新建 context 都要問自己“這個 context 的父級是誰”。第四個坑channel 容量設太大反而更慢。我一度把容量調到 1024 想提升吞吐結果發(fā)現(xiàn)延遲反而上升了因為數據在緩沖區(qū)里排隊客戶端要等更久才看到第一個 token。背壓緩沖區(qū)不是越大越好它影響的是延遲和內存的權衡。6. 性能驗證與后續(xù)可擴展方向6.1 壓測方法與關鍵指標驗證網關性能我用的是自己寫的一個壓測工具模擬 N 個并發(fā)客戶端每個客戶端發(fā)一個請求并持續(xù)讀取流直到結束。關鍵指標有三個首 token 延遲TTFT、吞吐每秒完成請求數、內存占用。TTFT 反映的是網關引入的額外延遲。理想情況下網關的 TTFT 應該和直連上游差不多額外開銷在毫秒級。我實測下來網關引入的 TTFT 增加在 5ms 以內可以接受。吞吐方面單機 8 核跑 1000 并發(fā)CPU 占用在 40% 左右瓶頸主要在上游的生成速度而不是網關本身。這說明網關的轉發(fā)邏輯沒有成為瓶頸。內存占用是重點觀察對象。1000 并發(fā)下RSS 穩(wěn)定在 200MB 左右沒有持續(xù)增長說明背壓和 goroutine 管理是有效的。如果看到內存曲線一直往上走那一定是哪里泄漏了。6.2 可以繼續(xù)做的優(yōu)化第一個方向是連接池優(yōu)化。目前對上游用的是默認 Transport連接復用策略可以調優(yōu)比如設置MaxIdleConnsPerHost來匹配并發(fā)量減少建連開銷。第二個方向是多上游負載均衡。現(xiàn)在只接一個上游如果要做高可用需要加一層選擇邏輯根據上游的健康狀態(tài)和負載來分發(fā)請求。這塊可以結合健康檢查和加權輪詢。第三個方向是可觀測性增強。目前只有基礎日志可以加 Prometheus 指標暴露活躍連接數、背壓觸發(fā)次數、取消次數等方便做容量規(guī)劃和告警。第四個方向是請求級別的限流。防止單個用戶占用過多并發(fā)影響其他人?？梢杂昧钆仆八惴ò从脩艟S度限流。這套網關我從零寫到現(xiàn)在大概迭代了三個版本第一版只做了基本轉發(fā)第二版加了取消和背壓第三版做了分層重構和錯誤處理完善。每一版都是被真實問題逼出來的。如果你也在做類似的東西我的建議是先把級聯(lián)取消和背壓這兩個基礎打牢它們決定了系統(tǒng)的下限SSE 的細節(jié)處理決定了上限。別急著加功能先把流的正確性做扎實后面擴展起來才不痛苦。