簡介面向人工智能應(yīng)用開發(fā)者與行業(yè)技術(shù)決策者聚焦中文大語言模型向行業(yè)落地的核心環(huán)節(jié)涵蓋指令數(shù)據(jù)、安全對(duì)齊數(shù)據(jù)與說明文檔適用于構(gòu)建公司級(jí)或行業(yè)級(jí)大模型應(yīng)用場景。包內(nèi)共8個(gè)文件包含三個(gè)jsonl與三個(gè)json格式的數(shù)據(jù)文件以及兩個(gè)md說明文檔整體僅3.44MB便于下載與速覽。其中jsonl/json數(shù)據(jù)多與中文指令微調(diào)、安全提示及開發(fā)者指令相關(guān)md文檔則提供使用指引。該資源上線后已有208人學(xué)習(xí)/下載適合正在搭建中文大模型訓(xùn)練環(huán)境或推進(jìn)行業(yè)應(yīng)用的讀者參考。指令數(shù)據(jù)如alpaca中文數(shù)據(jù)、安全提示集等可直接用于模型微調(diào)與對(duì)齊測(cè)試說明文檔能幫助快速理解文件結(jié)構(gòu)和調(diào)用方式為落地行業(yè)大模型提供基礎(chǔ)數(shù)據(jù)支撐與排錯(cuò)參考節(jié)省自行整理數(shù)據(jù)的時(shí)間。1. 中文大模型落地行業(yè)從解壓.zip到真能交付的最后一公里很多團(tuán)隊(duì)接觸行業(yè)大模型的第一份素材就是一個(gè).zip壓縮包。解壓、翻目錄、把模型跑起來這些步驟半天就能完成但真正的交付難點(diǎn)在壓縮包之外——怎么把中文大語言模型做成公司內(nèi)部的私有化服務(wù)讓業(yè)務(wù)方愿意把生產(chǎn)數(shù)據(jù)喂進(jìn)來讓答案經(jīng)得起追問。做AI大模型應(yīng)用的同學(xué)大多有這種體會(huì)demo能跑通不是能力業(yè)務(wù)方點(diǎn)頭才是驗(yàn)收。這篇文章按行業(yè)項(xiàng)目最常見的落地路徑展開覆蓋中文基座選型、業(yè)務(wù)數(shù)據(jù)整理、LoRA微調(diào)、vLLM部署、SSE實(shí)時(shí)渲染以及那些線上才會(huì)暴露的坑。適合準(zhǔn)備做行業(yè)大模型交付的算法工程師、平臺(tái)工程師和運(yùn)維同學(xué)也適合正在評(píng)估要不要投入的技術(shù)負(fù)責(zé)人。2. 選中文基座模型先看許可證、參數(shù)量與權(quán)重格式再動(dòng)手解包行業(yè)項(xiàng)目的選型不能在壓縮包里進(jìn)行。拿到.zip先別急著做環(huán)境配置基座選錯(cuò)后面的微調(diào)、部署、評(píng)測(cè)全都要返工。選型的先后順序應(yīng)該是先看許可證再定參數(shù)規(guī)模最后確認(rèn)權(quán)重格式。順序反了大概率會(huì)在某個(gè)周五晚上發(fā)現(xiàn)模型不能商用或者部署的時(shí)候發(fā)現(xiàn)顯存差一半。2.1 基座怎么選為什么行業(yè)項(xiàng)目優(yōu)先看中文基座國內(nèi)業(yè)務(wù)場景優(yōu)先看中文基座原因很實(shí)際。中文基座的預(yù)訓(xùn)練語料里中文占比高行業(yè)術(shù)語、中文指令遵循能力和對(duì)話模板都更貼合。英文基座在中文業(yè)務(wù)上不是不能做但往往要花更多數(shù)據(jù)去矯正語言風(fēng)格同樣的微調(diào)預(yù)算效果會(huì)打折扣。選型時(shí)第一道門檻是許可證這個(gè)必須在立項(xiàng)時(shí)確認(rèn)清楚。公司級(jí)別或行業(yè)級(jí)別的交付意味著模型要部署在多臺(tái)服務(wù)器上可能還會(huì)打包給上下游伙伴商用許可不清晰的權(quán)重文件是重大合規(guī)隱患。現(xiàn)在常見的做法是優(yōu)先選Apache 2.0這類寬松許可的中文基座系列法務(wù)審核會(huì)順暢很多交付物也能正常走采購流程。第二個(gè)看基座的中文SFT訓(xùn)練數(shù)據(jù)和對(duì)話模板。模板決定了后續(xù)數(shù)據(jù)整理的格式所以不要在「用哪套Prompt格式」上自己發(fā)明直接跟隨基座默認(rèn)的ChatML模板|im_start|和|im_end|圍起來的消息結(jié)構(gòu)后續(xù)接入推理框架和微調(diào)工具都不用改。如果基座模板和微調(diào)工具、推理框架三者不一致會(huì)出現(xiàn)「訓(xùn)練時(shí)正常部署時(shí)輸出亂七八糟」的玄學(xué)問題實(shí)際原因是模板錯(cuò)位。2.2 參數(shù)量級(jí)怎么定從業(yè)務(wù)并發(fā)和顯存預(yù)算反推參數(shù)規(guī)模不應(yīng)該從「越大越聰明」來定而是從「部署環(huán)境能提供多少顯存、業(yè)務(wù)需要多少并發(fā)」反推。下面這組對(duì)應(yīng)關(guān)系是行業(yè)項(xiàng)目里比較常用的參考具體數(shù)值在不同推理引擎下會(huì)有浮動(dòng)但量級(jí)是固定的。參數(shù)規(guī)模BF16推理顯存參考典型部署形態(tài)適用場景7B單卡24GB可跑量化后更低單機(jī)單卡vLLM或llama.cpp部門級(jí)知識(shí)問答、單業(yè)務(wù)線助手14B單卡40GB或雙卡24GB雙卡張量并行多個(gè)業(yè)務(wù)線共用一套模型服務(wù)72B多卡80GB或多卡量化多卡并行統(tǒng)一網(wǎng)關(guān)行業(yè)級(jí)底座面向全公司7B級(jí)別是目前行業(yè)落地的甜點(diǎn)位。在電氣、售后、法律這些垂直領(lǐng)域經(jīng)過良好微調(diào)的7B模型能覆蓋大量日常問答如果一次請(qǐng)求的上下文不超過兩千字單張24GB顯卡用vLLM部署7B就能扛住幾十個(gè)并發(fā)硬件成本在可接受范圍內(nèi)。14B和72B效果更強(qiáng)但對(duì)顯存、運(yùn)維的要求是指數(shù)級(jí)上升的。做這個(gè)決策時(shí)有一個(gè)容易忽視的角度業(yè)務(wù)方要的不是「最強(qiáng)模型」而是「穩(wěn)定可用的服務(wù)」。與其上72B然后因?yàn)轱@存不足把并發(fā)壓得很低不如先用7B跑通業(yè)務(wù)閉環(huán)把知識(shí)庫和提示詞工程做好等業(yè)務(wù)量明確再考慮升級(jí)。我見過不止一個(gè)項(xiàng)目死在第一步選了過大的基座導(dǎo)致推理成本超預(yù)算。2.3 拿到.zip先做三件事校驗(yàn)包、清點(diǎn)權(quán)重格式、確認(rèn)部署形態(tài)拿到別人分享的行業(yè)大模型.zip以及內(nèi)部交付的資源包先按下面的順序過一遍不要直接解壓扔進(jìn)訓(xùn)練環(huán)境。sha256sum industry_model_bundle.zip unzip -l industry_model_bundle.zip第一行是校驗(yàn)完整性第二行是列出壓縮包內(nèi)容清單。模型文件在傳輸過程中損壞并不少見損壞的權(quán)重在你訓(xùn)練或者推理時(shí)通常不報(bào)錯(cuò)而是表現(xiàn)為「生成內(nèi)容胡說八道」非常容易誤判成基座能力問題。這里多說一句zip偽加密這種解壓小坑十分鐘能解決真正花時(shí)間的是后面——確認(rèn)包里是訓(xùn)練好的完整權(quán)重還是只有一份LoRA適配器這決定了你是直接部署還是要先做權(quán)重合并。下一步是確認(rèn)權(quán)重格式。常見的有三種safetensors格式HuggingFace標(biāo)準(zhǔn)訓(xùn)練和vLLM直接加載、GGUF格式llama.cpp系引擎和端側(cè)加載、AWQ/GPTQ量化格式低顯存推理。格式本身沒有優(yōu)劣取決于你的部署形態(tài)。如果目標(biāo)環(huán)境是Linux服務(wù)器上跑vLLM選safetensors如果要做Android App集成AI大模型GGUF是端側(cè)最常用的加載格式如果只有一兩張16GB的卡還想跑7B量化格式幾乎是唯一選擇。最后建議做一次基線測(cè)試直接用未微調(diào)的基座跑20條真實(shí)業(yè)務(wù)問題把回答存下來。這組基線記錄在后面微調(diào)完成后要做對(duì)比用來判斷微調(diào)到底帶來了什么改變。這一步不要省它決定了后面所有工作有沒有參照物。3. 用Qwen2.5-7B微調(diào)行業(yè)大模型數(shù)據(jù)整理、LoRA訓(xùn)練與權(quán)重合并基座定下來后最核心的工作是微調(diào)。做行業(yè)大模型微調(diào)數(shù)據(jù)整理的優(yōu)先級(jí)永遠(yuǎn)高于訓(xùn)練參數(shù)的調(diào)整。數(shù)據(jù)不對(duì)調(diào)參只是把錯(cuò)誤答案訓(xùn)練得更流暢。如果你第一次做這個(gè)流程Qwen2.5-7B-Instruct加LLaMA-Factory是當(dāng)前走得通的組合環(huán)境配置、模型加載、數(shù)據(jù)集格式都有成熟方案周邊資料也多踩坑時(shí)容易找到對(duì)照。3.1 把行業(yè)語料轉(zhuǎn)成ChatML指令集一份最少可用的SFT樣本行業(yè)微調(diào)的數(shù)據(jù)格式直接決定訓(xùn)練能否被模型理解。中文基座大多原生支持ChatML格式也就是每條樣本包含system、user、assistant三個(gè)角色的消息序列。下面是一個(gè)設(shè)備診斷場景的SFT樣本這種形態(tài)在行業(yè)項(xiàng)目里非常典型。{messages: [{role: system, content: 你是恒泰設(shè)備的液壓系統(tǒng)診斷助理。只能依據(jù)維修手冊(cè)和設(shè)備參數(shù)回答不能編造壓力、流量等數(shù)值。}, {role: user, content: 液壓站壓力波動(dòng)超過多少M(fèi)Pa必須停機(jī)排查}, {role: assistant, content: 當(dāng)系統(tǒng)壓力波動(dòng)超過±1.5 MPa且持續(xù)10秒以上時(shí)應(yīng)停機(jī)排查溢流閥與蓄能器。}]}這里的關(guān)鍵是system里寫清角色邊界和禁止行為user保留業(yè)務(wù)原話assistant是人工校驗(yàn)過的標(biāo)準(zhǔn)答案。注意不要一條樣本里塞進(jìn)多輪對(duì)話歷史SFT樣本應(yīng)該是一問一答的原子記錄多輪能力后期用提示詞工程補(bǔ)。行業(yè)語料需要清洗比如維修工單里的口語表達(dá)、錯(cuò)別字、私聊信息都要處理剩下業(yè)務(wù)問答核心。樣本量上質(zhì)量遠(yuǎn)比數(shù)量重要。1000條經(jīng)過人工校驗(yàn)的高質(zhì)量業(yè)務(wù)問答效果通常好于10萬條從網(wǎng)頁或工單里直接扒出來的噪聲數(shù)據(jù)。這里的教訓(xùn)是不要追求數(shù)據(jù)量堆積行業(yè)項(xiàng)目的周期瓶頸往往卡在答案審核而不是語料采集上。每條assistant答案都要有可追溯依據(jù)——來自哪個(gè)手冊(cè)、哪份參數(shù)表——不然模型學(xué)到的是「看似合理的編造」?！感W(xué)」地說數(shù)據(jù)里有多少幻覺模型就學(xué)多少幻覺。3.2 用LLaMA-Factory跑一輪LoRA微調(diào)命令與關(guān)鍵參數(shù)數(shù)據(jù)集準(zhǔn)備好之后推薦用LLaMA-Factory做微調(diào)。它支持Qwen系列模型和ChatML模板可以省掉自己寫訓(xùn)練腳本的時(shí)間。常見做法是先用LoRA做嘗試LoRA只訓(xùn)練一小部分適配器參數(shù)訓(xùn)練快、顯存占用低效果不滿意可以快速換數(shù)據(jù)重來全量微調(diào)放在后面效果驗(yàn)證過再考慮。llamafactory-cli train \ --model_name_or_path /data/models/Qwen2.5-7B-Instruct \ --dataset industry_sft \ --finetuning_type lora \ --template qwen \ --output_dir /data/output/industry_7b_lora \ --num_train_epochs 3 \ --learning_rate 2e-4 \ --lora_rank 16 \ --lora_alpha 32 \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --max_length 2048 \ --logging_steps 20 \ --save_steps 500 \ --bf16 True幾個(gè)參數(shù)值得細(xì)說。lora_rank和lora_alpha控制適配器的容量行業(yè)指令數(shù)據(jù)量在幾千條時(shí)rank取16到32是常用區(qū)間rank太大容易過擬合小數(shù)據(jù)集太小則學(xué)不到位。learning_rate取2e-4是LoRA微調(diào)比較穩(wěn)妥的起點(diǎn)如果你同時(shí)混入了通用指令數(shù)據(jù)可以降到1e-4。max_length要覆蓋業(yè)務(wù)中最長的問題和答案行業(yè)場景里如果把歷史維修記錄塞進(jìn)上下文2048可能不夠要提前統(tǒng)計(jì)業(yè)務(wù)樣本的真實(shí)長度分布而不是隨手設(shè)個(gè)值。訓(xùn)練過程中l(wèi)oss曲線只是第一步門檻更重要的是每訓(xùn)練幾百步就保存一個(gè)checkpoint挑幾條固定業(yè)務(wù)問題做生成對(duì)比。畫畫loss曲線的意義有限真正要觀察的是模型回答的措辭在哪個(gè)checkpoint開始穩(wěn)定。我在實(shí)際項(xiàng)目中會(huì)下載save_steps對(duì)應(yīng)的中間產(chǎn)物手工試答幾條困難問題來判斷是繼續(xù)訓(xùn)練還是提前停。不要盲目跑滿epoch數(shù)——行業(yè)場景里L(fēng)oRA跑了兩個(gè)epoch就想吐訓(xùn)練集原話的情況非常常見。3.3 合并與導(dǎo)出從訓(xùn)練權(quán)重到生產(chǎn)可用的BF16/GGUFLoRA訓(xùn)練完成后產(chǎn)出的是一個(gè)小體積適配器文件而不是完整模型部署前需要把它合并進(jìn)基座權(quán)重。這個(gè)步驟的常見做法是使用LLaMA-Factory自帶的export功能。llamafactory-cli export \ --model_name_or_path /data/models/Qwen2.5-7B-Instruct \ --adapter_name_or_path /data/output/industry_7b_lora \ --template qwen \ --export_dir /data/output/industry_7b_merged合并之后會(huì)得到一個(gè)完整的safetensors格式模型這個(gè)模型可以直接給vLLM加載。注意--template qwen必須和訓(xùn)練時(shí)一致模板不一致會(huì)導(dǎo)致部署后回答格式錯(cuò)亂。合并完先加載起來人工試幾條再做下一步。接下來根據(jù)部署環(huán)境決定是否量化。如果目標(biāo)服務(wù)器顯存充裕單卡24GB以上直接用BF16權(quán)重跑vLLM即可效果最好如果顯存緊張或者要做端側(cè)部署常見做法是用llama.cpp的轉(zhuǎn)換腳本把合并權(quán)重轉(zhuǎn)成GGUF格式再按需壓到Q4_K_M或Q8_0量化檔位。7B模型Q4_K_M量化后權(quán)重體積大約在5GB上下普通工作站就能跑起來。這里不要追求極致壓縮行業(yè)項(xiàng)目的推理質(zhì)量比體積重要Q4_K_M優(yōu)先Q8_0次之再低的量化檔位建議先做效果對(duì)比再?zèng)Q定。4. 公司級(jí)部署vLLM拉起本地服務(wù)、SSE實(shí)時(shí)渲染與模型網(wǎng)關(guān)微調(diào)完成的模型要變成業(yè)務(wù)方能調(diào)用的API服務(wù)通常選vLLM做推理引擎。vLLM在并發(fā)場景下吞吐表現(xiàn)穩(wěn)定而且自帶OpenAI兼容接口——這意味著我們不需要為它單獨(dú)設(shè)計(jì)一套協(xié)議應(yīng)用層可以直接按/v1/chat/completions的規(guī)范來對(duì)接大幅降低集成成本。整個(gè)部署鏈路是vLLM拉起模型服務(wù)、網(wǎng)關(guān)統(tǒng)一做鑒權(quán)和限流、前端走SSE流式輸出拿到實(shí)時(shí)渲染效果。4.1 vLLM最小啟動(dòng)配置模型路徑、序列長度與并發(fā)參數(shù)先給一份最小可用的啟動(dòng)命令之后按業(yè)務(wù)規(guī)模調(diào)整參數(shù)。python -m vllm.entrypoints.openai.api_server \ --model /data/output/industry_7b_merged \ --served-model-name industry-7b \ --port 8000 \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 32--model指向合并后的模型目錄--served-model-name是客戶端請(qǐng)求時(shí)要用的模型名不必和目錄名一致內(nèi)部項(xiàng)目可以取一個(gè)業(yè)務(wù)名比如industry-7b。--max-model-len直接決定模型能接受的最大上下文長度設(shè)太大占用顯存設(shè)太小長文檔對(duì)話會(huì)截?cái)鄨?bào)錯(cuò)。我一般先用2048起步壓測(cè)時(shí)觀察業(yè)務(wù)方的真實(shí)請(qǐng)求長度再往上調(diào)。--gpu-memory-utilization 0.9意思是允許vLLM使用90%的顯存保留一部分給CUDA上下文和其他進(jìn)程這個(gè)值在大模型本地部署配置里很常用。--max-num-seqs控制并發(fā)序列數(shù)它和顯存是強(qiáng)相關(guān)的序列數(shù)越多KV cache占用越高。啟動(dòng)后可以用curl發(fā)一個(gè)請(qǐng)求驗(yàn)證服務(wù)是否正常確認(rèn)非流式接口返回正常后再測(cè)stream: true的流式參數(shù)。4.2 通過SSE流式輸出做回答實(shí)時(shí)渲染配合AbortController處理中斷大模型回答動(dòng)輒幾百字等全部生成完再返回用戶體驗(yàn)很差。行業(yè)應(yīng)用的標(biāo)準(zhǔn)做法是SSE流式輸出服務(wù)端邊生成邊推送前端收到一個(gè)詞就渲染一個(gè)詞配合abort機(jī)制處理用戶手動(dòng)停止的場景。這里涉及的技術(shù)棧封裝AI交互邏輯的核心就兩塊解析SSE事件流、正確取消請(qǐng)求。以下是前端處理SSE流式輸出的一段核心JavaScript可以直接作為應(yīng)用層集成的參考。const controller new AbortController(); const resp await fetch(/v1/chat/completions, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ model: industry-7b, messages: [{ role: user, content: 壓力波動(dòng)超過多少需要停機(jī) }], stream: true }), signal: controller.signal }); const reader resp.body.getReader(); const decoder new TextDecoder(); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); const lines buffer.split(\n); buffer lines.pop(); // 保留未完成的行等下一段數(shù)據(jù)拼齊 for (const line of lines) { if (line.startsWith(data: )) { const payload line.slice(6); if (payload [DONE]) return; // 流結(jié)束標(biāo)記 render(JSON.parse(payload).choices[0].delta.content); } } } stopBtn.onclick () controller.abort();這里的邏輯要點(diǎn)是SSE協(xié)議的數(shù)據(jù)按行分割每行以data:開頭最后以[DONE]收尾。網(wǎng)絡(luò)包不會(huì)恰好按行邊界到達(dá)所以必須聲明一個(gè)buffer變量把不完整的行留到下一次讀取時(shí)拼接這是流式渲染最容易出錯(cuò)的地方。abort的時(shí)機(jī)同樣重要用戶點(diǎn)擊停止時(shí)調(diào)用controller.abort()瀏覽器會(huì)斷開這個(gè)請(qǐng)求vLLM收到客戶端斷開后會(huì)自動(dòng)釋放對(duì)應(yīng)的KV cache資源。如果不做abort用戶反復(fù)點(diǎn)擊「停止」實(shí)際上連接還掛在服務(wù)端會(huì)占用并發(fā)序列數(shù)累積起來就會(huì)拖垮接口。4.3 私有化場景的模型網(wǎng)關(guān)鑒權(quán)、限流與調(diào)用審計(jì)行業(yè)部署和私有化交付最核心的差異在于模型不能直接暴露給所有業(yè)務(wù)方。vLLM本身不帶業(yè)務(wù)鑒權(quán)如果公司多條業(yè)務(wù)線共用一套模型服務(wù)必須在其前增加一層網(wǎng)關(guān)負(fù)責(zé)API Key鑒權(quán)、按調(diào)用方限流和請(qǐng)求日志留痕。常見做法是使用Nginx開放REST API風(fēng)格的服務(wù)并關(guān)閉代理緩沖以支持SSE。location /v1/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-API-Key $http_x_api_key; proxy_buffering off; proxy_read_timeout 120s; }proxy_buffering off這行很關(guān)鍵它保證SSE流式響應(yīng)不會(huì)被Nginx截留成一次性返回。如果這里不關(guān)前端收到的內(nèi)容會(huì)在整個(gè)請(qǐng)求結(jié)束后一次性到達(dá)流式效果等于沒有而且首字延遲會(huì)很高體驗(yàn)非常差。鑒權(quán)邏輯放在網(wǎng)關(guān)層對(duì)沒有正確API Key的請(qǐng)求直接返回401限流可以用Nginx的limit_req模塊實(shí)現(xiàn)按調(diào)用方的Key做每分鐘請(qǐng)求數(shù)限制防止某條業(yè)務(wù)線異常調(diào)用拖垮整個(gè)模型服務(wù)。日志審計(jì)在行業(yè)場景里往往被忽略但它其實(shí)是合規(guī)的前提。網(wǎng)關(guān)層記錄每次請(qǐng)求的用戶標(biāo)識(shí)、輸入摘要、模型輸出的首字延遲和完成狀態(tài)后續(xù)一旦出現(xiàn)問題能追溯到具體調(diào)用方。運(yùn)維側(cè)建議把首字延遲TTFT和每秒請(qǐng)求數(shù)這兩個(gè)指標(biāo)接到監(jiān)控上后面避坑章節(jié)會(huì)具體展開為什么TTFT比總耗時(shí)更重要。5. 行業(yè)落地避坑指南五個(gè)血淚經(jīng)驗(yàn)從顯存翻車到SSE被緩沖這里匯總一下行業(yè)項(xiàng)目里反復(fù)出現(xiàn)的五個(gè)問題每條都按「現(xiàn)象、原因、解決」來寫。這些多半在demo階段不會(huì)暴露都是上了生產(chǎn)環(huán)境之后才冒出來提前知道能省下不少排查時(shí)間。5.1 微調(diào)后「變笨」行業(yè)術(shù)語學(xué)會(huì)了通用對(duì)話能力卻崩了現(xiàn)象模型在業(yè)務(wù)問答上表現(xiàn)不錯(cuò)但大家閑聊式的提問開始答非所問甚至重復(fù)同一個(gè)句式。原因這是災(zāi)難性遺忘。SFT數(shù)據(jù)里行業(yè)樣本占比過高模型反復(fù)學(xué)習(xí)某一種回答模式把基座原本的通用能力覆蓋掉了。LoRA學(xué)習(xí)率偏高或者epoch數(shù)跑滿也會(huì)放大這個(gè)問題。解決在行業(yè)數(shù)據(jù)里混入10%到20%的通用指令數(shù)據(jù)比如日常問答、百科類對(duì)話讓模型在訓(xùn)練時(shí)同時(shí)復(fù)習(xí)通用能力。學(xué)習(xí)率從2e-4降到1e-4訓(xùn)練過程按前面說的用固定業(yè)務(wù)問題做checkpoint對(duì)比發(fā)現(xiàn)回答僵化就提前停訓(xùn)別硬跑完。這類問題一旦發(fā)生調(diào)已經(jīng)訓(xùn)練完的適配器是沒有后悔藥的只能改數(shù)據(jù)重新訓(xùn)練所以預(yù)防要比事后補(bǔ)救重要。5.2 T4上部署OOMA100卻一切正?，F(xiàn)象開發(fā)環(huán)境用的是A100部署到客戶T4 16GB顯卡上啟動(dòng)就報(bào)CUDA out of memory項(xiàng)目當(dāng)場卡住。原因顯存估算只算了權(quán)重體積。7B模型BF16權(quán)重大概15GB再加上KV cache、CUDA上下文和vLLM預(yù)分配顯存16GB根本不夠。這是本地部署配置時(shí)的經(jīng)典誤區(qū)——權(quán)重能塞下不代表推理過程能跑起來。解決兩條路。一是顯存緊張的機(jī)器上改用量化格式例如用GGUF的Q4_K_M檔位量化后再啟動(dòng)服務(wù)二是保留BF16權(quán)重但調(diào)低--max-model-len和--gpu-memory-utilization把序列長度限制在2048以內(nèi)給KV cache留出空間。更進(jìn)一步的方法是用AWQ等量化方案在vLLM里做等效推理。選型時(shí)建議先確認(rèn)客戶機(jī)器的顯存再做規(guī)模決策別等到部署階段翻車。5.3 SSE一直轉(zhuǎn)圈接口有響應(yīng)但頁面不渲染現(xiàn)象用curl請(qǐng)求后端stream: true能正?？吹綌?shù)據(jù)前端調(diào)接口頁面卻一直等像卡死一樣。原因前端代碼沒問題問題在中間的代理層。Nginx默認(rèn)開啟proxy_bufferingSSE響應(yīng)會(huì)被緩沖前端實(shí)際上要等整個(gè)流結(jié)束才拿到內(nèi)容一直在等待狀態(tài)。這類問題看起來像前端bug實(shí)際是服務(wù)器配置問題。解決在Nginx配置里加上proxy_buffering off;或者在后端響應(yīng)的HTTP頭里顯式添加X-Accel-Buffering: no。另外注意SSE對(duì)網(wǎng)關(guān)的連接超時(shí)設(shè)置proxy_read_timeout要足夠大模型生成慢的時(shí)候超過60秒就可能被切斷建議設(shè)到120秒以上。5.4 行業(yè)答案說得漂亮但數(shù)值是錯(cuò)的現(xiàn)象模型回答的語句很流利語氣也很自信但關(guān)鍵參數(shù)、法規(guī)條款、設(shè)備型號(hào)之間出現(xiàn)張冠李戴業(yè)務(wù)方一核對(duì)就發(fā)現(xiàn)問題。原因模型本質(zhì)上是「概率生成」它沒有查證能力行業(yè)知識(shí)全靠訓(xùn)練時(shí)的記憶。微調(diào)能教會(huì)它話術(shù)和表達(dá)框架但它依然會(huì)用自己的語言習(xí)慣生成讀起來像真的、實(shí)際不存在的數(shù)值。解決把檢索增強(qiáng)生成RAG接入生產(chǎn)鏈路。業(yè)務(wù)知識(shí)先入庫做向量化用戶提問時(shí)先從知識(shí)庫檢索相關(guān)片段再把檢索結(jié)果和問題一起拼進(jìn)提示詞要求模型只能依據(jù)檢索內(nèi)容回答。同時(shí)加一層兜底在提示詞里明確「如果檢索內(nèi)容里沒有答案直接回答無法確定」。模型的能力上限不是唯一的交付標(biāo)準(zhǔn)給模型提供答案依據(jù)的檢索鏈路才是行業(yè)落地的分水嶺。5.5 上線第一天就被業(yè)務(wù)方說「太慢」現(xiàn)象接口耗時(shí)曲線難看業(yè)務(wù)方反饋首字遲遲不出來并發(fā)一高直接排隊(duì)。原因看監(jiān)控時(shí)只關(guān)注了單次請(qǐng)求總耗時(shí)忽略了首字延遲TTFT和并發(fā)排隊(duì)。--max-num-seqs設(shè)置偏小會(huì)讓并發(fā)的請(qǐng)求排隊(duì)等待上一個(gè)長請(qǐng)求不結(jié)束后面的請(qǐng)求就一直卡著。解決上線前用壓測(cè)工具模擬真實(shí)流量按業(yè)務(wù)預(yù)估的峰值并發(fā)打一輪關(guān)注TTFT的P95而不是平均總耗時(shí)。根據(jù)壓測(cè)結(jié)果調(diào)整--max-num-seqs和--max-model-len必要時(shí)限制單次請(qǐng)求的上下文輪次把歷史多輪對(duì)話截?cái)喑勺罱鼛纵喴钥s短生成長度。模型服務(wù)的響應(yīng)時(shí)間分布本來就比普通接口寬提前給業(yè)務(wù)方一個(gè)「首字延遲目標(biāo)值」作為預(yù)期管理也可以避免上線后被動(dòng)挨告。6. 用一件小事守住交付品質(zhì)把行業(yè)評(píng)測(cè)集接進(jìn)更新流程行業(yè)模型上線后不是終點(diǎn)業(yè)務(wù)數(shù)據(jù)會(huì)增長話術(shù)會(huì)變化模型需要持續(xù)迭代。這個(gè)章節(jié)不是總結(jié)而是分享一個(gè)每家做落地交付的團(tuán)隊(duì)都該有的習(xí)慣建立一份自己的行業(yè)評(píng)測(cè)集并且把每次模型更新都跑一遍評(píng)測(cè)結(jié)果留下記錄再談上線。評(píng)測(cè)集不要盲目求大200條以內(nèi)即可但必須滿足兩點(diǎn)一是全部來自真實(shí)業(yè)務(wù)樣本或高頻問題二是包含一批容易翻車的困難樣例比如數(shù)值敏感的設(shè)備參數(shù)、有明確邊界條件的業(yè)務(wù)規(guī)則、用戶常見的口語化問法。標(biāo)注格式可以用一個(gè)極簡的JSONL文件每條包含問題、答案中必須出現(xiàn)的關(guān)鍵內(nèi)容、禁止出現(xiàn)的內(nèi)容。核驗(yàn)?zāi)_本用規(guī)則匹配兜底減少人工重復(fù)勞動(dòng)。import json golden [ {q: 壓力波動(dòng)超過多少必須停機(jī), must: [1.5, 停機(jī)], must_not: []}, {q: 保修期外維修怎么收費(fèi), must: [上門費(fèi), 工時(shí)費(fèi)], must_not: [免費(fèi)]}, ] def hit(pred: str, case: dict) - bool: ok_all all(k in pred for k in case[must]) bad_any any(k in pred for k in case[must_not]) return ok_all and not bad_any preds [json.loads(line) for line in open(preds.jsonl)] acc sum(hit(p[pred], golden[i]) for i, p in enumerate(preds)) / len(golden) print(facc{acc:.2%})規(guī)則腳本只能兜底每20條抽1條人工看一遍完整回答重點(diǎn)看流暢度和上下文邏輯。Checks要接進(jìn)模型更新的發(fā)布流程里模型版本發(fā)版前先跑評(píng)測(cè)集準(zhǔn)確率低于歷史平均值就攔住不發(fā)版。行業(yè)項(xiàng)目的交付穩(wěn)定比驚喜重要守住下限比追求高分更有價(jià)值。我自己的習(xí)慣是每次訓(xùn)練前把這份評(píng)測(cè)集的預(yù)測(cè)結(jié)果用git log對(duì)應(yīng)的方式存檔一份模型更新后直接對(duì)比前后差距哪些問題變好、哪些問題變差一目了然。模型微調(diào)的黑匣子特性決定了不可能每次訓(xùn)練都變好但有了這份記錄任何一次回滾都有依據(jù)。如果你正在做行業(yè)大模型落地建議從今天開始就把這個(gè)幾十條問題的評(píng)測(cè)集搭起來它會(huì)成為你的AI大模型應(yīng)用里最值錢的一份資產(chǎn)。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取