有個(gè)業(yè)務(wù)方拿著小模型做客服問答效果一直不咋地?cái)?shù)據(jù)又死活不肯出內(nèi)網(wǎng)來回拉扯幾輪之后我給了一個(gè)很直接的方案在一臺(tái)24GB顯存的機(jī)器上做千問3-8B私有化部署推理框架選SGLang。別人問為什么不直接調(diào)云上大模型接口答案很簡單——數(shù)據(jù)不出域這一條紅線就否決了所有外部方案。這套部署從選型、裝環(huán)境到驗(yàn)證跑通算下來不到半天穩(wěn)定運(yùn)行之后基本沒再動(dòng)過。本文把完整落地過程、參數(shù)取舍和踩過的坑一次性寫清楚給同樣需要內(nèi)網(wǎng)私有化部署的同學(xué)做個(gè)參考。1. 為什么選千問3-8B做私有化部署選模型這件事不能只看排行榜分?jǐn)?shù)要看你的業(yè)務(wù)場景到底需要什么。我當(dāng)時(shí)評(píng)估的幾個(gè)硬條件中文能力要夠好顯存不能吃太滿部署形態(tài)要靈活最好支持推理模式的開關(guān)控制。千問3-8B在這幾個(gè)維度上剛好都踩中了。1.1 千問3-8B的能力邊界千問3-8B是一個(gè)80億參數(shù)規(guī)模的稠密模型和同系列更大的MoE模型不同它是完整參數(shù)參與計(jì)算的結(jié)構(gòu)相對(duì)傳統(tǒng)對(duì)部署環(huán)境的要求反而更友好。它在中英文對(duì)話、指令跟隨、文本抽取、代碼生成這些常見任務(wù)上表現(xiàn)都不錯(cuò)已經(jīng)能滿足大部分內(nèi)網(wǎng)業(yè)務(wù)系統(tǒng)的日常需求。這里多說一句很多團(tuán)隊(duì)一開始想用幾百億參數(shù)的模型解決所有問題實(shí)際上在垂直業(yè)務(wù)場景里模型能力只是其中一環(huán)數(shù)據(jù)質(zhì)量、提示詞設(shè)計(jì)、RAG知識(shí)庫的建設(shè)往往影響更大。8B這個(gè)規(guī)模配合一套好的內(nèi)部知識(shí)庫檢索鏈路在很多場景下已經(jīng)能用得比較舒服。這個(gè)模型還有一個(gè)特點(diǎn)支持思考模式thinking和不思考模式。思考模式下模型會(huì)先輸出一段推理過程再給結(jié)論適合數(shù)學(xué)題、邏輯分析這類任務(wù)不思考模式則直接給答案速度快、輸出穩(wěn)定。這個(gè)開關(guān)對(duì)部署配置和用戶體驗(yàn)影響很大后面會(huì)專門展開講。1.2 為什么不是更小或者更大的模型我也試過更小的3B、4B模型中文復(fù)雜指令的跟隨能力確實(shí)弱一截經(jīng)常答非所問而14B、32B這類更大規(guī)模的模型單卡24GB顯存基本跑不動(dòng)BF16精度得上多卡甚至翻倍的顯存服務(wù)器成本直接上去了。8B恰好處于一個(gè)比上不足但是夠用、比下有余還跑得動(dòng)的甜點(diǎn)區(qū)。BF16權(quán)重約15-16GB24GB顯存單卡勉強(qiáng)能塞下還能留出空間給KV cache和并發(fā)請(qǐng)求。如果預(yù)算夠、業(yè)務(wù)并發(fā)高32GB或者雙卡組合會(huì)更從容但單卡24GB起步絕對(duì)是可行的。1.3 私有化部署到底解決了什么問題選私有化不只是為了合規(guī)聽起來好聽實(shí)際收益很實(shí)在。數(shù)據(jù)全程不出內(nèi)網(wǎng)審查、審計(jì)、脫敏規(guī)則都能自己定高頻調(diào)用時(shí)不會(huì)擔(dān)心按量計(jì)費(fèi)的成本失控還能把系統(tǒng)提示詞、業(yè)務(wù)知識(shí)庫、權(quán)限控制全部焊死在自家管道里。如果你業(yè)務(wù)里涉及內(nèi)部文檔、客戶信息、生產(chǎn)參數(shù)這類敏感數(shù)據(jù)外部API這條路基本不用考慮私有化是唯一選項(xiàng)。而千問3-8B正好是那種不會(huì)讓公司破產(chǎn)、又能干活的折中方案這也是我最終確定這套部署組合的核心依據(jù)。2. 部署前的軟硬件規(guī)劃顯存和資源到底怎么算很多人部署大模型上來就pip install結(jié)果啟動(dòng)時(shí)OOM再回去買卡。我建議按照下面這套邏輯先把賬算清楚再動(dòng)手裝環(huán)境。2.1 顯存預(yù)算的完整計(jì)算公式模型權(quán)重顯存有一個(gè)非常簡單的估算公式權(quán)重體積 參數(shù)量 × 每個(gè)參數(shù)占用的字節(jié)數(shù)。千問3-8B按80億參數(shù)計(jì)算BF16精度下每個(gè)參數(shù)占2字節(jié)所以權(quán)重約16GB。這里可能有人會(huì)問為什么系統(tǒng)提示詞、KV cache、CUDA context這么占地方。因?yàn)檎嬲拇箢^其實(shí)是KV cache——模型要記住生成長度中所有的歷史狀態(tài)上下文越長、并發(fā)請(qǐng)求越多KV cache膨脹得就越快。24GB卡上權(quán)重占掉16GBCUDA context和激活值再占掉1-2GB留給KV cache的空間就只剩6GB左右。這也是為什么這張卡能跑但是并發(fā)和上下文長度必須做限制的原因。我給你一張參考表方便你對(duì)照自己的硬件做判斷顯存大小權(quán)重精度建議最大上下文建議并發(fā)量適合場景24GBBF1616K-32K8-16單業(yè)務(wù)方使用32GBBF1632K-64K16-32多業(yè)務(wù)方共用48GBINT4/AWQ量化32K32高并發(fā)/長文檔量化是另一個(gè)話題。如果你用AWQ或GPTQ級(jí)別的INT4量化權(quán)重體積能壓到5GB左右24GB卡會(huì)寬裕很多。不過量化對(duì)精度有損耗不是每個(gè)任務(wù)都能接受按需取舍。2.2 CPU內(nèi)存、磁盤和系統(tǒng)層準(zhǔn)備很多人只盯著顯存忽略了CPU內(nèi)存。模型加載時(shí)權(quán)重先經(jīng)過內(nèi)存再進(jìn)顯存8B模型權(quán)重約16GB加上推理框架本身和tokenizer等開銷我建議內(nèi)存至少32GB有條件上64GB更穩(wěn)。磁盤方面權(quán)重文件實(shí)際落地大概16-17GB再加上日志、臨時(shí)文件、未來要換新版本權(quán)重預(yù)留30GB以上比較穩(wěn)妥。系統(tǒng)層只需要注意兩點(diǎn)一是NVIDIA驅(qū)動(dòng)版本要支持CUDA 12.1以上二是Python環(huán)境務(wù)必用虛擬環(huán)境隔離別直接把依賴裝進(jìn)系統(tǒng)Python里否則環(huán)境沖突會(huì)讓人非常抓狂。2.3 推理框架怎么選為什么是SGLang而不是別的這個(gè)問題值得單獨(dú)拿出來說。市面上跑8B模型的開源推理框架不少最常聽到的是原生transformers、vLLM、SGLang這三類。原生transformers適合調(diào)試和寫Demo直接加載模型推理但并發(fā)和吞吐都跟不上生產(chǎn)要求需要自己做批處理、自己管緩存基本不做生產(chǎn)選型考慮。vLLM是經(jīng)典選擇了PagedAttention方案已經(jīng)很成熟連續(xù)批處理也能把GPU打得很滿。SGLang真正拉開距離的地方在于它實(shí)現(xiàn)了一套名為RadixAttention的前綴緩存機(jī)制。什么意思就是當(dāng)多個(gè)請(qǐng)求共享同一段前綴比如相同的系統(tǒng)提示詞、多輪對(duì)話里相同的歷史消息、RAG里相同的公共知識(shí)上下文時(shí)計(jì)算過的KV cache可以直接復(fù)用不用每次從頭算一遍。實(shí)測下來在高并發(fā)、長系統(tǒng)提示詞的業(yè)務(wù)場景下SGLang的吞吐量相比vLLM有機(jī)會(huì)拉開20%到40%的差距。這個(gè)數(shù)據(jù)不是絕對(duì)跟請(qǐng)求的共享前綴比例強(qiáng)相關(guān)。但如果你做的是客服問答或者RAG類應(yīng)用請(qǐng)求前綴高度相似SGLang的前綴緩存收益非?？捎^。這也是我最終選SGLang的核心原因。3. SGLang拉起模型從空環(huán)境到首個(gè)對(duì)話的完整流程這部分是動(dòng)手實(shí)操環(huán)節(jié)。我按照自己當(dāng)時(shí)的操作路徑一步步來中間包含了幾個(gè)容易忽略的細(xì)節(jié)跟著走不會(huì)踩坑。3.1 裝環(huán)境虛擬環(huán)境里安裝SGLang第一步永遠(yuǎn)是創(chuàng)建獨(dú)立環(huán)境千萬別偷懶conda create -n sglang python3.10 -y conda activate sglang pip install -U sglang[all]SGLang的版本迭代很快依賴關(guān)系隨版本浮動(dòng)安裝前最好先瞄一眼官方倉庫的README確認(rèn)當(dāng)前版本對(duì)應(yīng)的PyTorch和CUDA版本范圍。如果你所在的是內(nèi)網(wǎng)離線環(huán)境記得提前一臺(tái)有外網(wǎng)權(quán)限的機(jī)器上把所有依賴的whl包下載好再通過pip install --find-links方式離線安裝。裝完之后可以用python -c import sglang; print(sglang.__version__)驗(yàn)證一下是否正常。安裝這塊最大的坑是PyTorch、CUDA、SGLang三者版本錯(cuò)配表現(xiàn)癥狀通常是啟動(dòng)時(shí)直接報(bào)CUDA error或者flash-attention相關(guān)的error。我的建議是先按官方文檔指定的組合來不要自己混搭版本。3.2 獲取千問3-8B權(quán)重權(quán)重文件建議直接通過模型托管平臺(tái)的下載工具拉取或者在有外網(wǎng)權(quán)限的機(jī)器上下載完整目錄后拷貝進(jìn)內(nèi)網(wǎng)。這里特別強(qiáng)調(diào)完整目錄三個(gè)字因?yàn)闄?quán)重倉庫里通常包含config.json、tokenizer.json、tokenizer_config.json、多個(gè).safetensors分片文件以及generation_config.json缺任何一個(gè)文件都可能導(dǎo)致啟動(dòng)失敗。下載完成后把權(quán)重放在固定目錄比如/data/models/Qwen3-8B。加載時(shí)優(yōu)先使用絕對(duì)路徑避免因?yàn)楣ぷ髂夸洸煌瑢?dǎo)致路徑找不到的問題。啟動(dòng)前可以檢查一下目錄里的文件數(shù)量和磁盤占用正常應(yīng)該在16GB左右如果明顯偏小多半是下載沒下全。3.3 啟動(dòng)服務(wù)的第一條命令環(huán)境就緒、權(quán)重就位之后就可以啟服務(wù)了。我的啟動(dòng)命令如下nohup python -m sglang.launch_server \ --model-path /data/models/Qwen3-8B \ --served-model-name qwen3-8b \ --host 0.0.0.0 --port 8000 \ --mem-fraction-static 0.8 \ --max-running-requests 32 \ --max-request-length 32768 \ --max-total-tokens 65536 \ --trust-remote-code \ /var/log/sglang.log 21 幾個(gè)參數(shù)我解釋一下--model-path指向本地權(quán)重目錄--served-model-name是給客戶端調(diào)用時(shí)使用的模型名可以隨便起但不建議和路徑名混為一談--trust-remote-code是允許加載模型倉庫里自定義的代碼千問這類模型基本都需要--mem-fraction-static 0.8表示給權(quán)重和靜態(tài)分配預(yù)留80%的顯存剩下20%留給KV cache動(dòng)態(tài)增長。啟動(dòng)完成后查看日志確認(rèn)服務(wù)狀態(tài)tail -f /var/log/sglang.log當(dāng)出現(xiàn)類似The server is started或者顯示Address: http://0.0.0.0:8000的日志時(shí)再配合nvidia-smi查看顯存如果看到顯存被正常占用說明服務(wù)基本起來了。3.4 用一次真實(shí)對(duì)話驗(yàn)證服務(wù)服務(wù)啟動(dòng)后先用簡單請(qǐng)求確認(rèn)整條鏈路是通的curl -s http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen3-8b, messages: [{role: user, content: 你好請(qǐng)用一句話介紹你自己}], max_tokens: 256, temperature: 0.7 }正常情況下會(huì)返回一個(gè)OpenAI格式的JSON里面包含choices列表、message.content以及usage統(tǒng)計(jì)字段。如果返回錯(cuò)誤先看日志日志里一般會(huì)寫明是權(quán)重路徑錯(cuò)誤還是CUDA顯存不足。到這里你已經(jīng)跑通了一個(gè)最小可用的私有化推理服務(wù)。4. 啟動(dòng)參數(shù)逐項(xiàng)拆解這些參數(shù)到底在干什么很多人啟動(dòng)服務(wù)時(shí)參數(shù)全靠抄換了張卡、換個(gè)模型之后就不知道該怎么改了。這一節(jié)把核心參數(shù)背后的邏輯說清楚。4.1 端口、模型名與對(duì)外暴露方式--host 0.0.0.0表示服務(wù)監(jiān)聽所有網(wǎng)卡接口這樣內(nèi)網(wǎng)其他機(jī)器才能訪問如果只在本地調(diào)試用127.0.0.1更安全。--port 8000是服務(wù)端口注意端口不能被占用否則啟動(dòng)直接報(bào)錯(cuò)。--served-model-name這個(gè)參數(shù)容易被忽略它決定了客戶端請(qǐng)求體里model字段填什么。比如你本地路徑叫/data/models/Qwen3-8B但對(duì)外統(tǒng)一叫qwen3-8b這時(shí)候客戶端只需要記住一個(gè)穩(wěn)定的名字未來升級(jí)權(quán)重時(shí)只需要改啟動(dòng)參數(shù)不用改動(dòng)各業(yè)務(wù)方。安全方面如果內(nèi)網(wǎng)環(huán)境有防火墻請(qǐng)確保只放行需要訪問的IP和端口。SGLang本身也有API key相關(guān)的鑒權(quán)參數(shù)具體名稱和用法跟隨版本走在暴露服務(wù)之前務(wù)必確認(rèn)一下。4.2 顯存和并發(fā)控制參數(shù)--mem-fraction-static是控制靜態(tài)顯存占比的關(guān)鍵參數(shù)默認(rèn)值相對(duì)保守。0.8意味著模型權(quán)重和框架自身最多占80%的顯存其余的留給KV cache和調(diào)度器動(dòng)態(tài)使用。如果啟動(dòng)時(shí)直接OOM優(yōu)先把它降到0.75甚至0.7如果顯存還很寬松想增大批處理能力可以慢慢上調(diào)。--max-running-requests控制同時(shí)處理的請(qǐng)求上限。并發(fā)太高時(shí)KV cache會(huì)迅速擠占顯存導(dǎo)致后續(xù)請(qǐng)求排隊(duì)甚至OOM。24GB單卡跑千問3-8B我推薦從16到32起步壓測后再做調(diào)整。--max-request-length和--max-total-tokens的區(qū)別很多人搞混。前者限制單個(gè)請(qǐng)求的最大長度輸入輸出后者限制所有并發(fā)請(qǐng)求共享的token池總量。簡單說一個(gè)是單用戶上限一個(gè)是全局上限。在多用戶場景下全局上限必須大于單個(gè)用戶上限否則會(huì)出現(xiàn)服務(wù)端拒絕請(qǐng)求的情況。4.3 千問3-8B的思考模式到底怎么管這是千問3模型特有的配置點(diǎn)。模型默認(rèn)在生成時(shí)可能會(huì)先輸出一段內(nèi)部的思考內(nèi)容reasoning_content再輸出正式回復(fù)。對(duì)于客服問答、信息抽取這類業(yè)務(wù)場景我的建議是直接關(guān)閉思考模式理由有三個(gè)生成速度更快、響應(yīng)更穩(wěn)定、不會(huì)把內(nèi)心活動(dòng)意外暴露給終端用戶。關(guān)閉方法有兩種路徑一種是在請(qǐng)求參數(shù)里通過chat_template_kwargs或extra_body顯式指定關(guān)閉另一種是通過SGLang提供的對(duì)話模板配置統(tǒng)一處理。具體參數(shù)名不同SGLang版本有差異以你部署版本對(duì)應(yīng)的官方文檔為準(zhǔn)。是否需要開啟思考模式完全取決于任務(wù)類型——如果業(yè)務(wù)方明確要做數(shù)學(xué)題、邏輯推理這類復(fù)雜任務(wù)再單獨(dú)為這類請(qǐng)求開啟即可。我在生產(chǎn)環(huán)境里的一般策略是服務(wù)層面默認(rèn)關(guān)閉思考模式個(gè)別復(fù)雜任務(wù)通過請(qǐng)求級(jí)參數(shù)臨時(shí)開啟這樣可以兼顧絕大多數(shù)場景的速度和少數(shù)場景的深度。4.4 張量并行和性能相關(guān)開關(guān)--tp-size是張量并行度參數(shù)默認(rèn)1。千問3-8B在單卡24GB下用不到多卡但如果你手上是兩張16GB的卡TP2可以把權(quán)重拆分到兩張卡上加載。SGLang自動(dòng)處理跨卡通信前提是機(jī)器上NVIDIA驅(qū)動(dòng)、NCCL環(huán)境都正常。--schedule-policy決定請(qǐng)求調(diào)度的優(yōu)先策略SGLang對(duì)帶前綴緩存的調(diào)度有專門優(yōu)化生產(chǎn)環(huán)境用默認(rèn)值就好不要為了性能去亂調(diào)。--stream-interval是流式輸出的刷新間隔默認(rèn)值已經(jīng)能滿足SSE推送體驗(yàn)也不需要改動(dòng)。為了讓你能直接抄作業(yè)我整理了一份推薦配置表參數(shù)24GB單卡推薦值說明--mem-fraction-static0.8OOM時(shí)降到0.75--max-running-requests32保守可以設(shè)16--max-request-length32768按業(yè)務(wù)實(shí)際調(diào)整--max-total-tokens65536必須大于單請(qǐng)求上限--tp-size1單卡默認(rèn)--schedule-policy默認(rèn)不要去亂改5. 上線前必須做好的推理驗(yàn)證與性能壓測服務(wù)能跑通不代表能上線。我在正式交付前一般會(huì)做三輪驗(yàn)證功能驗(yàn)證、并發(fā)壓測、鏈路安全檢查。每一輪都會(huì)發(fā)現(xiàn)一些平時(shí)發(fā)現(xiàn)不了的問題。5.1 用OpenAI兼容接口做功能驗(yàn)證SGLang啟動(dòng)后提供的是OpenAI兼容接口路徑是/v1/chat/completions。這意味著你公司內(nèi)部現(xiàn)有的OpenAI SDK代碼只需要改一下base_url和api_key就能直接切換過來遷移成本非常低。我一般會(huì)寫一個(gè)簡單的Python腳本模擬真實(shí)業(yè)務(wù)請(qǐng)求檢查返回的finish_reason是否為stop、usage字段的token計(jì)數(shù)是否合理、content內(nèi)容是否完整。如果返回頻繁出現(xiàn)length達(dá)到最大長度被截?cái)嗾f明max_tokens設(shè)小了需要調(diào)大。流式輸出也要單獨(dú)驗(yàn)證一遍。用stream: true發(fā)起請(qǐng)求觀察返回的SSE數(shù)據(jù)塊是否能正常拼接成一個(gè)完整的文本。流式這塊最容易出問題的是客戶端解析連接斷開、超時(shí)設(shè)置這些都要在聯(lián)調(diào)階段就解決。5.2 并發(fā)壓測和性能基線怎么測壓測不需要上重型工具一個(gè)Python多線程腳本足夠。核心關(guān)注兩個(gè)指標(biāo)TTFT首token延遲和生成吞吐。TTFT反映用戶第一感覺的快慢生成吞吐反映服務(wù)整體處理能力。我當(dāng)時(shí)在單卡24GB環(huán)境下并發(fā)8路請(qǐng)求、上下文長度約2K的時(shí)候TTFT平均在500ms左右生成吞吐約每路20 tokens每秒整體GPU利用率保持在80%以上這個(gè)基線已經(jīng)能滿足業(yè)務(wù)方的交互體驗(yàn)要求。如果你的壓測結(jié)果里隨著并發(fā)從4路增加到16路吞吐量沒有成比例增長甚至下降說明顯存或者調(diào)度已經(jīng)到瓶頸需要降低--max-running-requests或者壓縮單請(qǐng)求的max_tokens。壓測過程中一定要用nvidia-smi -l 1盯住顯存變化。如果看到顯存占用蹭蹭往上漲并且接近上限說明并發(fā)參數(shù)開大了趕緊降下來不然跑一段時(shí)間就會(huì)OOM。5.3 接入業(yè)務(wù)系統(tǒng)前需要檢查的點(diǎn)接入業(yè)務(wù)系統(tǒng)前還有幾個(gè)細(xì)節(jié)要確認(rèn)。第一在網(wǎng)關(guān)或調(diào)用層限制單次請(qǐng)求的最大max_tokens防止業(yè)務(wù)方誤設(shè)置超大值把顯存打爆。第二客戶端超時(shí)設(shè)置至少要180秒以上因?yàn)榇竽Ｐ蜕蓭装賯€(gè)token確實(shí)需要時(shí)間超時(shí)設(shè)太短會(huì)被誤殺。第三RAG類應(yīng)用盡量把系統(tǒng)提示詞和知識(shí)庫上下文固定成統(tǒng)一前綴這樣才能充分利用SGLang的RadixAttention前綴緩存減少重復(fù)計(jì)算。6. 常見報(bào)錯(cuò)與運(yùn)行期坑點(diǎn)速查最后這部分是我在部署和后續(xù)運(yùn)維中真正踩過的坑整理成速查表遇到問題直接對(duì)照。6.1 模型加載失敗的常見原因權(quán)重目錄不完整是最常見的加載失敗原因現(xiàn)象是啟動(dòng)日志里報(bào)缺少某個(gè)key或者直接報(bào)OSError。解決辦法是把權(quán)重目錄整個(gè)重新下載不要手動(dòng)逐個(gè)文件去補(bǔ)。其次是tokenizer文件缺失這種情況下服務(wù)能啟動(dòng)但請(qǐng)求一進(jìn)來就報(bào)錯(cuò)原因多半是只拷貝了模型權(quán)重文件沒拷貝tokenizer相關(guān)文件。版本不匹配也經(jīng)常遇到。SGLang版本和PyTorch版本不兼容時(shí)啟動(dòng)時(shí)會(huì)報(bào)ModuleNotFoundError或者奇怪的CUDA初始化錯(cuò)誤。記住一個(gè)原則安裝SGLang之前先確認(rèn)官方文檔支持的PyTorch和CUDA版本組合不要盲目升級(jí)任何一個(gè)包。6.2 顯存相關(guān)的問題CUDA OOM是最頻繁的報(bào)錯(cuò)。啟動(dòng)時(shí)OOM降--mem-fraction-static運(yùn)行中OOM降--max-running-requests或者單請(qǐng)求的max_tokens。還有一種情況是服務(wù)停掉后顯存還是滿的這是顯存碎片化或者進(jìn)程沒完全釋放導(dǎo)致的直接nvidia-smi看進(jìn)程PID手動(dòng)清掉僵尸進(jìn)程或者干脆重啟機(jī)器。多卡場景下NCCL初始化失敗也是一類典型問題常見原因是驅(qū)動(dòng)版本不一致或者通信超時(shí)?？梢韵葯z查驅(qū)動(dòng)版本再嘗試配置NCCL相關(guān)的超時(shí)環(huán)境變量。這臺(tái)機(jī)器如果之前跑過其他分布式任務(wù)最好先重啟再啟動(dòng)SGLang服務(wù)避免殘留的通信進(jìn)程干擾。6.3 請(qǐng)求超時(shí)和輸出中斷輸出到一半斷開最常見的原因是max_tokens設(shè)得太小服務(wù)端生成到上限后主動(dòng)截?cái)?。排查時(shí)先看響應(yīng)里finish_reason如果是length說明是被長度截?cái)嗟恼{(diào)大max_tokens即可如果是stop說明正常結(jié)束?？蛻舳顺瑫r(shí)也是一個(gè)高頻問題。很多業(yè)務(wù)系統(tǒng)默認(rèn)HTTP超時(shí)10秒這在流式對(duì)話場景下根本不夠用。我建議網(wǎng)關(guān)層超時(shí)設(shè)置300秒應(yīng)用層超時(shí)設(shè)置180秒給模型留出充足的生成時(shí)間。6.4 服務(wù)常駐與日常維護(hù)建議我一直用systemd托管推理服務(wù)這樣服務(wù)器重啟后服務(wù)會(huì)自動(dòng)拉起來不用每次手動(dòng)nohup。寫一個(gè)簡單的service文件ExecStart指向啟動(dòng)命令Restartalways保底再把日志路徑統(tǒng)一起來。配置文件單獨(dú)存放方便以后改參數(shù)時(shí)回溯對(duì)比。模型升級(jí)時(shí)不需要覆蓋舊權(quán)重目錄下載一份新權(quán)重放到新目錄改一下啟動(dòng)參數(shù)里的--model-path和--served-model-name重啟服務(wù)即可。如果新版本跑起來有問題還能立刻切回舊目錄回滾成本極低。最后說一個(gè)我踩了幾輪才養(yǎng)成的習(xí)慣部署任何私有化模型啟動(dòng)命令、環(huán)境版本、日志三者一定放在一起記錄每次改動(dòng)都留檔。因?yàn)檫@個(gè)版本的SGLang能跑通的組合升一個(gè)CUDA小版本可能就出問題下次排障時(shí)如果連當(dāng)時(shí)啟動(dòng)參數(shù)是什么都記不清排錯(cuò)難度直接翻倍。把版本和參數(shù)固化下來這套私有化服務(wù)基本就能穩(wěn)定跑下去剩下時(shí)間騰出來做業(yè)務(wù)優(yōu)化而不是反復(fù)折騰部署。