本地 AI 智能體這個(gè)事我前后折騰了大半年從最開始拿一臺(tái)舊筆記本硬跑 7B 模型到后來在一臺(tái)單卡機(jī)器上把一整套多模型協(xié)作的批量任務(wù)流水線跑通中間踩的坑比寫過的代碼還多。LM Studio 這類工具把本地加載模型這件事的門檻壓得很低點(diǎn)幾下就能對(duì)話但真要把本地 AI 智能體當(dāng)成生產(chǎn)工具用起來尤其是多模型協(xié)調(diào)加批量任務(wù)這種組合光會(huì)點(diǎn)界面是不夠的。你要面對(duì)的是顯存怎么分、模型怎么換、上下文怎么截、并發(fā)開多少、失敗了怎么續(xù)——這些問題沒有一個(gè)能在圖形界面里找到答案。這篇內(nèi)容適合兩類人一類是已經(jīng)在本地跑過單模型對(duì)話想往智能體方向再走一步的另一類是手里有一批重復(fù)性文本任務(wù)想用本地模型批量處理、又不想把數(shù)據(jù)往外送的。我會(huì)把 LM Studio 當(dāng)成一個(gè)模型服務(wù)器來看待圍繞多模型協(xié)調(diào)和批量任務(wù)這兩條主線把選型邏輯、接口細(xì)節(jié)、流水線設(shè)計(jì)、以及那些只有真跑起來才會(huì)暴露的問題一條條攤開講。代碼用 Python接口走 OpenAI 兼容格式你可以直接抄去改。1. 先把賬算清楚本地智能體的顯存預(yù)算與延遲底線動(dòng)手之前我最想勸的一件事是先別急著寫代碼先拿張紙把賬算清楚。本地智能體和云端 API 最大的區(qū)別不在模型智商而在資源是你自己的。你的顯存是固定的你的顯卡是獨(dú)占的模型加載一次要幾十秒這些東西一旦進(jìn)入設(shè)計(jì)整個(gè)架構(gòu)的思路都會(huì)跟調(diào)云端接口完全不一樣。1.1 云端接口和本地推理的真實(shí)差距在哪調(diào)云端接口的時(shí)候我們習(xí)慣了一種很奢侈的用法一個(gè)請(qǐng)求里塞上萬把字的歷史反正按 token 計(jì)費(fèi)貴是貴點(diǎn)但不會(huì)失敗。本地推理完全不是這個(gè)邏輯。上下文長(zhǎng)度是硬約束超了就是超了有的實(shí)現(xiàn)會(huì)靜默截?cái)嗲鞍攵斡械闹苯訄?bào)錯(cuò)最坑的是截?cái)嘀竽Ｐ瓦€能正常輸出只是它忘了你在開頭定的規(guī)則。另一層差距是并發(fā)。云端接口你開 20 個(gè)線程同時(shí)打服務(wù)端自己扛本地單機(jī)單卡模型實(shí)例就是一個(gè)進(jìn)程占著一塊顯存兩個(gè)請(qǐng)求同時(shí)進(jìn)來要么排隊(duì)要么把 KV cache 撐爆。我最早那版腳本就是照著云端習(xí)慣寫的ThreadPoolExecutor(max_workers8)跑第一條正常跑到第三條開始報(bào)顯存不足日志里全是超時(shí)。所以本地智能體的第一條設(shè)計(jì)原則是把資源當(dāng)成一等公民寫進(jìn)架構(gòu)里而不是當(dāng)作部署細(xì)節(jié)丟到最后再調(diào)。維度云端 API 習(xí)慣本地推理現(xiàn)實(shí)上下文盡量塞滿越長(zhǎng)越好按需裁剪寧短勿長(zhǎng)并發(fā)多線程直接打串行或極低并發(fā)靠實(shí)例數(shù)堆延遲相對(duì)穩(wěn)定百毫秒級(jí)首字首字幾百毫秒到數(shù)秒受加載狀態(tài)影響失敗率低偶發(fā)限流顯存、上下文、格式都可能觸發(fā)失敗成本模型按 token 付錢一次性硬件投入 電費(fèi) 你的時(shí)間這張表我建議貼在顯示器邊上。后面所有的設(shè)計(jì)取舍基本都能從這張表推出來。1.2 用參數(shù)規(guī)模反推你的顯存下限很多人問我這卡能跑多大模型這個(gè)問題沒法一句話回答因?yàn)榱炕燃?jí)、上下文長(zhǎng)度、是否多模型常駐三個(gè)變量一動(dòng)答案就變了。我給一個(gè)粗略的估算思路你自己往里代。模型權(quán)重的顯存占用約等于參數(shù)量 × 每參數(shù)字節(jié)數(shù)。FP16 是 2 字節(jié)8bit 量化約 1 字節(jié)4bit 量化約 0.5 到 0.6 字節(jié)實(shí)際略高于理論值因?yàn)橛行硬涣炕Ｋ砸粋€(gè) 7B 模型 4bit 量化權(quán)重占 3.5 到 4GB 左右14B 大約 8GB32B 大約 18 到 20GB。然后是 KV cache這部分經(jīng)常被忽略。它的占用跟上下文長(zhǎng)度、層數(shù)、隱藏維度成正比粗算可以用每 1000 token 占用幾百 MB這個(gè)量級(jí)去估具體數(shù)值隨模型差異很大同一個(gè)模型在 8K 和 32K 上下文下KV cache 能差出好幾 GB。再加上運(yùn)行時(shí)的一些固定開銷大概留 1 到 2GB 余量。舉一個(gè)我實(shí)際配過的例子單卡 24GB目標(biāo)是跑一個(gè) 14B 級(jí)別的規(guī)劃模型加一個(gè) 7B 級(jí)別的執(zhí)行模型同時(shí)常駐。14B 4bit 權(quán)重約 8GB配 8K 上下文KV cache 加開銷算 3GB合計(jì) 11GB7B 4bit 約 4GB配 4K 上下文算 1.5GB合計(jì) 5.5GB。兩者相加 16.5GB卡上還剩 7GB 多看起來寬裕但實(shí)際上系統(tǒng)和其他進(jìn)程還要吃一部分所以我最后把 7B 那一路的上下文壓到了 4K 以內(nèi)把并發(fā)鎖死在 1。這個(gè)配置跑起來很穩(wěn)連續(xù)跑了三千多條任務(wù)沒出過 OOM。1.3 延遲不能只看 token/s新手看模型性能喜歡看每秒多少 token這個(gè)指標(biāo)有用但不完整。真正影響批量任務(wù)總耗時(shí)的是單條任務(wù)的平均端到端耗時(shí)它由三部分組成首 token 延遲、生成耗時(shí)、以及被很多人忽略的模型切換或加載耗時(shí)。首 token 延遲跟你喂進(jìn)去的上下文長(zhǎng)度強(qiáng)相關(guān)。同一個(gè)模型200 token 的 prompt 首字可能 0.3 秒就出來了8000 token 的 prompt 可能要等兩三秒——因?yàn)橐颜麄€(gè)上下文過一遍前向。生成耗時(shí)才是 token/s 說了算的部分。而模型切換如果你的流程里要在規(guī)劃模型和執(zhí)行模型之間來回跳而顯存又不夠兩個(gè)同時(shí)常駐那每次切換都要重新加載一次十幾秒到一分鐘不等批量任務(wù)里這個(gè)開銷會(huì)被放大到無法接受。這就引出了后面章節(jié)的一個(gè)核心決策要么讓所有參與協(xié)作的模型同時(shí)常駐要么把流程改造成分階段批處理讓同一個(gè)模型在一段時(shí)間內(nèi)只干一件事。這兩條路各有代價(jià)但都比一條任務(wù)內(nèi)來回切模型要好得多。提示算顯存的時(shí)候不要按理論最大值去卡留 20% 左右余量。本地推理的顯存占用不是恒定的長(zhǎng) prompt 進(jìn)來會(huì)臨時(shí)沖高卡得太死就會(huì)出現(xiàn)平時(shí)都好好的偶爾崩一次這種最難查的故障。2. 把 LM Studio 變成一臺(tái)模型服務(wù)器圖形界面是用來試模型效果的真正做智能體開發(fā)你得把它當(dāng)服務(wù)用。LM Studio 提供了本地服務(wù)能力會(huì)起一個(gè) HTTP 服務(wù)對(duì)外暴露一套和主流接口格式兼容的端點(diǎn)。這一步做好了后面換模型、換工具、換框架客戶端代碼基本不用動(dòng)。2.1 服務(wù)化之后客戶端只認(rèn)一個(gè) base_url在應(yīng)用里開啟本地服務(wù)默認(rèn)監(jiān)聽在本機(jī)的一個(gè)端口上常見是 1234端點(diǎn)路徑和主流格式一致/v1/chat/completions、/v1/completions、/v1/models、/v1/embeddings。這意味著你可以直接用官方的 OpenAI 風(fēng)格 SDK只把base_url指過來api_key隨便填一個(gè)非空字符串就行。from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:1234/v1, api_keylocal-no-auth, # 本地服務(wù)不校驗(yàn)但字段不能為空 timeout300.0, # 關(guān)鍵本地首字慢默認(rèn)超時(shí)太短 ) resp client.chat.completions.create( modellocal-model-id, # 必須和服務(wù)端加載的模型標(biāo)識(shí)一致 messages[ {role: system, content: 你是一個(gè)只輸出 JSON 的抽取器。}, {role: user, content: 從下面這段文本里抽取公司名和金額。}, ], temperature0.1, )這段代碼里有兩個(gè)地方最容易出錯(cuò)。第一個(gè)是timeout。SDK 默認(rèn)超時(shí)通常是 60 秒或者更短本地模型如果正在首次加載或者 prompt 特別長(zhǎng)很可能超過這個(gè)時(shí)間客戶端直接拋超時(shí)但服務(wù)端其實(shí)還在算。表現(xiàn)就是報(bào)錯(cuò)了但模型后來又把結(jié)果算出來了日志對(duì)不上。我一般直接給到 300 秒寧可等也不誤判。第二個(gè)是model字段的取值。它必須和服務(wù)端當(dāng)前加載的模型標(biāo)識(shí)嚴(yán)格一致寫錯(cuò)一個(gè)字都會(huì)返回 404 或者找不到模型的錯(cuò)誤。穩(wěn)妥的做法是啟動(dòng)時(shí)先打一次/v1/models把返回的列表打印出來確認(rèn)你要用的那個(gè) id 長(zhǎng)什么樣再寫進(jìn)配置。models client.models.list() for m in models.data: print(m.id)這個(gè)習(xí)慣幫我省過好幾次時(shí)間。我有一次排查了半天為什么請(qǐng)求一直失敗最后發(fā)現(xiàn)是模型標(biāo)識(shí)里帶了個(gè)版本后綴我照著別人的示例少寫了一段。2.2 模型加載策略常駐、JIT 與 TTL 的取舍LM Studio 支持按需加載機(jī)制請(qǐng)求進(jìn)來時(shí)如果模型沒加載它會(huì)自動(dòng)去加載用完之后經(jīng)過一段空閑時(shí)間再卸載。這個(gè)機(jī)制對(duì)偶爾換模型試試的場(chǎng)景非常友好但對(duì)批量任務(wù)來說是個(gè)陷阱。原因很簡(jiǎn)單按需加載意味著第一個(gè)請(qǐng)求要等模型加載完這個(gè)時(shí)間可能是十幾秒到一分鐘。如果你的批量腳本里每處理幾十條就要切換一次模型那總耗時(shí)會(huì)被加載開銷吞掉一大半。更麻煩的是如果在加載過程中客戶端超時(shí)重試會(huì)打進(jìn)一堆重復(fù)請(qǐng)求把隊(duì)列堵死。我在實(shí)際項(xiàng)目里的做法是批處理開始前把所有要用的模型手動(dòng)預(yù)加載并且關(guān)掉或拉長(zhǎng)空閑卸載時(shí)間。LM Studio 本身提供命令行工具和界面兩種方式做預(yù)加載也可以用一個(gè)空的試探請(qǐng)求預(yù)熱——發(fā)一條只有一個(gè)字的消息把模型頂起來。def warmup(client, model_id, retries30, interval5): 發(fā)一條極短請(qǐng)求等模型真正就緒 for i in range(retries): try: client.chat.completions.create( modelmodel_id, messages[{role: user, content: hi}], max_tokens1, timeout180.0, ) print(f[warmup] {model_id} ready) return True except Exception as e: print(f[warmup] {model_id} not ready ({i1}/{retries}): {e}) time.sleep(interval) raise RuntimeError(f{model_id} 預(yù)熱失敗)這個(gè)warmup函數(shù)幾乎是我每個(gè)本地智能體腳本的標(biāo)配。它解決的問題是讓加載這件事發(fā)生在你控制的時(shí)刻而不是發(fā)生在批量循環(huán)的中間。什么時(shí)候該讓多個(gè)模型同時(shí)常駐什么時(shí)候該用按需加載我給一個(gè)判斷標(biāo)準(zhǔn)——看切換頻率。如果一批任務(wù)里模型 A 和模型 B 的調(diào)用是交替出現(xiàn)的一條任務(wù)里先 A 后 B那必須同時(shí)常駐否則每條任務(wù)都要吃兩次加載。如果是分段的前 500 條全用 A后 500 條全用 B那按需加載完全夠用還能省顯存。2.3 上下文長(zhǎng)度這個(gè)旋鈕擰錯(cuò)直接 OOM模型加載時(shí)一般可以設(shè)置上下文長(zhǎng)度。這個(gè)值設(shè)小了長(zhǎng)文檔會(huì)被截?cái)嘀悄荏w的工作記憶不夠用設(shè)大了KV cache 線性增長(zhǎng)顯存直接爆。而且有個(gè)隱含的坑有些模型配置文件里聲明的最大上下文很長(zhǎng)但實(shí)際訓(xùn)練時(shí)用的長(zhǎng)度并沒有那么長(zhǎng)你硬設(shè)到最大值模型在后半段的注意力質(zhì)量會(huì)明顯下降表現(xiàn)是前面還記得后面就開始胡編。我的經(jīng)驗(yàn)值是這樣抽取類、分類類任務(wù)2K 到 4K 足夠需要多輪工具調(diào)用的智能體8K 起步整篇長(zhǎng)文檔分析按文檔長(zhǎng)度給到 16K 或 32K但一定要同步確認(rèn)顯存扛得住。設(shè)完之后別忘了在請(qǐng)求層也做一次 token 預(yù)估和裁剪雙保險(xiǎn)。3. 多模型協(xié)調(diào)規(guī)劃者、執(zhí)行者、裁判各管一段單模型智能體最常見的失敗模式是什么活都想讓一個(gè)模型干。它既要理解任務(wù)、又要拆解步驟、又要調(diào)用工具、又要檢查結(jié)果prompt 越寫越長(zhǎng)長(zhǎng)到一定程度之后模型就開始丟指令。多模型協(xié)調(diào)的核心思路不是用更多模型顯得厲害而是把互相沖突的能力要求拆開讓每個(gè)模型只面對(duì)一類問題。3.1 為什么一個(gè)模型干不完所有活拆開有三個(gè)實(shí)打?qū)嵉暮锰?。第一?prompt 變短了。規(guī)劃者的 system prompt 只需要講清楚輸出什么樣的任務(wù)分解結(jié)構(gòu)執(zhí)行者的 prompt 只需要講清楚按給定步驟做這一件事。每個(gè)模型的上下文都很干凈指令遵循度明顯上升。我之前用一個(gè) 7B 模型同時(shí)做規(guī)劃和執(zhí)行光 system prompt 就寫了兩千多字結(jié)果它在第三步之后就忘了輸出格式要求拆成兩個(gè)模型之后兩個(gè) prompt 各三百字穩(wěn)定得多。第二是模型能力可以錯(cuò)配。規(guī)劃這件事對(duì)推理能力要求高對(duì)速度要求低用大一點(diǎn)的模型值得執(zhí)行如果是格式轉(zhuǎn)換、字段抽取這類活小模型完全夠速度快好幾倍。讓 32B 去干 7B 能干的事純屬浪費(fèi)讓小模型去規(guī)劃復(fù)雜流程它拆不明白。第三是失敗隔離。執(zhí)行者某一條輸出格式不對(duì)重試就行不影響整體規(guī)劃。單模型一體化的話格式一崩整條鏈路全廢還得從頭再來。3.2 角色契約用 JSON 把模型之間的對(duì)話固定下來多模型協(xié)調(diào)最容易翻車的地方是模型之間怎么傳話。如果你讓規(guī)劃者輸出一段自由文本再把它塞進(jìn)執(zhí)行者的 prompt那執(zhí)行者每次收到的格式都不一樣穩(wěn)定性完全靠運(yùn)氣。我的做法是給每一對(duì)模型之間定義一個(gè) JSON 契約。規(guī)劃者的輸出必須符合一個(gè) schema執(zhí)行者只接受這個(gè) schema。這樣中間層可以做校驗(yàn)、可以做重試、可以做緩存。PLAN_SCHEMA { type: object, properties: { steps: { type: array, items: { type: object, properties: { id: {type: integer}, action: {type: string, enum: [extract, classify, summarize]}, target_field: {type: string}, instruction: {type: string} }, required: [id, action, instruction] } } }, required: [steps] }把a(bǔ)ction做成枚舉值是個(gè)小技巧可以極大降低下游的分支判斷復(fù)雜度。模型不會(huì)給你發(fā)明一個(gè)analyze_deeply這種沒法處理的動(dòng)作名。請(qǐng)求時(shí)把 schema 傳給服務(wù)端如果當(dāng)前版本支持結(jié)構(gòu)化輸出參數(shù)就用參數(shù)不支持就在 prompt 里貼 schema 并加一句只輸出 JSON不要任何解釋然后在客戶端做一層解析容錯(cuò)。import json, re def parse_json_loose(text: str) - dict: 從模型輸出里盡力摳出 JSON text text.strip() # 去掉常見的 markdown 代碼塊包裹 text re.sub(r^(?:json)?\s*, , text) text re.sub(r\s*$, , text) try: return json.loads(text) except json.JSONDecodeError: pass # 退而求其次截取第一個(gè) { 到最后一個(gè) } start, end text.find({), text.rfind(}) if start ! -1 and end start: return json.loads(text[start:end1]) raise ValueError(f無法解析為 JSON: {text[:200]})這個(gè)函數(shù)看著粗糙但在實(shí)際跑批中救回來的比例相當(dāng)可觀。小模型在 JSON 前后加一句好的以下是結(jié)果是家常便飯硬性json.loads會(huì)直接失敗而寬松解析能把這部分撈回來。3.3 兩段式流水線先批量規(guī)劃再批量執(zhí)行這一節(jié)是我認(rèn)為整篇文章里最值錢的部分。前面說過模型切換的代價(jià)很高那怎么在多模型協(xié)作的前提下避免頻繁切換答案是把按任務(wù)循環(huán)改成按階段循環(huán)。具體來說假設(shè)你要處理 500 條任務(wù)每條都需要先規(guī)劃再執(zhí)行。糟糕的做法是for task in tasks: # 500 次循環(huán) plan planner(task) # 切到規(guī)劃模型 result executor(plan) # 切到執(zhí)行模型好的做法是plans [planner(t) for t in tasks] # 500 次規(guī)劃模型不切換 results [executor(p) for p in plans] # 500 次執(zhí)行模型不切換代碼只差幾行性能差出好幾倍。原因就是模型加載和卸載的次數(shù)從 1000 次變成了 2 次。這個(gè)思路在本地推理場(chǎng)景下幾乎是必須的在云端反而不重要——這也是為什么很多照著云端教程寫的架構(gòu)搬到本地就跑不動(dòng)。這個(gè)改造有個(gè)前提規(guī)劃階段的輸出必須能完整落盤執(zhí)行階段能獨(dú)立讀回來。也就是說你的中間結(jié)果必須可序列化、可持久化。這個(gè)要求順帶把斷點(diǎn)續(xù)跑的問題也解決了一半。流水線形態(tài)模型切換次數(shù)中間結(jié)果可恢復(fù)適用場(chǎng)景按任務(wù)循環(huán)交錯(cuò)調(diào)用約 2N 次難任務(wù)量極小、交互式按階段循環(huán)兩段式2 次易批量任務(wù)首選三階段規(guī)劃/執(zhí)行/校驗(yàn)3 次易質(zhì)量要求高的場(chǎng)景3.4 裁判模型的價(jià)值與成本第三個(gè)角色是校驗(yàn)者也有人叫它裁判模型。它的工作是拿到執(zhí)行者的輸出判斷這條結(jié)果是否合格不合格就退回重做或者標(biāo)記出來。裁判模型能不能省取決于你的容錯(cuò)成本。如果輸出只是給人看的參考稿人還會(huì)再掃一遍那裁判可以省。如果是自動(dòng)進(jìn)入下游流程的一個(gè)格式錯(cuò)誤可能讓整個(gè)管道崩掉那裁判很值。裁判模型選型上有個(gè)反直覺的點(diǎn)不要用和被校驗(yàn)?zāi)Ｐ屯吹哪Ｐ?。同一個(gè)模型對(duì)自己的輸出有天然的偏好它覺得這就是對(duì)的校準(zhǔn)效果很差。用不同家族、不同規(guī)模的模型做交叉校驗(yàn)抓到問題的概率明顯更高。我用一個(gè) 14B 做執(zhí)行、一個(gè) 7B 做裁判抓格式問題很有效但如果兩者互換7B 執(zhí)行、14B 裁判雖然裁判更強(qiáng)但因?yàn)?14B 的判據(jù)更寬容反而漏掉一些小問題。這里面有點(diǎn)玄學(xué)建議用自己的數(shù)據(jù)實(shí)測(cè)。成本上要知道裁判這一步會(huì)讓總調(diào)用次數(shù)增加 50%如果三段式是規(guī)劃、執(zhí)行、裁判各一次。對(duì)于本地推理這個(gè)成本主要是時(shí)間不是錢所以要算清楚你的時(shí)間預(yù)算。我現(xiàn)在的默認(rèn)配置是格式類校驗(yàn)用純代碼做正則、schema 校驗(yàn)語義類校驗(yàn)才用裁判模型能把裁判調(diào)用量壓掉一大半。4. 批量任務(wù)流水線從 CSV 到結(jié)果落盤前面的角色分工解決了誰來干這一節(jié)解決怎么干得快、干得穩(wěn)、斷了能接上。批量任務(wù)的工程量和單次調(diào)用完全不是一個(gè)量級(jí)很多在 demo 里不是問題的問題在 500 條、5000 條的規(guī)模下都會(huì)變成問題。4.1 任務(wù)隊(duì)列與并發(fā)閘門先明確一個(gè)反直覺的結(jié)論本地單實(shí)例場(chǎng)景下并發(fā)數(shù)設(shè) 1 往往比設(shè) 4 更快。原因在于本地模型的推理是計(jì)算密集型的GPU 的算力就那么多兩個(gè)請(qǐng)求同時(shí)進(jìn)來各自分到一半算力總吞吐并不會(huì)提升反而因?yàn)?KV cache 占雙份顯存、調(diào)度開銷增加整體變慢。更糟的是并發(fā)一高上下文一長(zhǎng)顯存占用峰值疊加很容易觸發(fā) OOM然后進(jìn)程被系統(tǒng)殺掉前面跑的全白費(fèi)。那想提速怎么辦兩條路。一是提高單條吞吐減少輸出長(zhǎng)度、縮短 prompt、用更小的模型二是多開服務(wù)實(shí)例綁不同端口每個(gè)實(shí)例加載不同模型或同樣的模型靠實(shí)例數(shù)橫向堆。第二條路要求顯存足夠而且要注意每個(gè)實(shí)例都要獨(dú)立設(shè)上下文長(zhǎng)度別一個(gè)實(shí)例設(shè) 32K 把卡吃光。我的隊(duì)列結(jié)構(gòu)大概是這樣的import queue, threading, json, time from dataclasses import dataclass dataclass class Task: task_id: str payload: dict retry: int 0 def worker(task_q: queue.Queue, done_ids: set, out_fp, lock: threading.Lock): while True: task task_q.get() if task is None: # 毒丸用于優(yōu)雅退出 task_q.task_done() break try: result process_one(task) # 真正的模型調(diào)用 with lock: out_fp.write(json.dumps( {task_id: task.task_id, ok: True, result: result}, ensure_asciiFalse) \n) out_fp.flush() # 關(guān)鍵每寫一條就刷盤 except Exception as e: with lock: out_fp.write(json.dumps( {task_id: task.task_id, ok: False, error: str(e)}, ensure_asciiFalse) \n) out_fp.flush() finally: task_q.task_done()注意flush()那一行。批量任務(wù)最怕的就是跑到一半進(jìn)程掛了緩沖區(qū)里的結(jié)果全丟。每寫一條刷一次盤犧牲一點(diǎn) IO 性能換來的是隨時(shí)可以斷、斷了不丟。4.2 斷點(diǎn)續(xù)跑別讓第 900 條失敗毀掉前面 899 條有了上面那個(gè) JSONL 落盤續(xù)跑就很直接了啟動(dòng)時(shí)把結(jié)果文件讀一遍收集所有task_id構(gòu)造任務(wù)隊(duì)列時(shí)跳過這些 id。def load_done(path): done set() if not os.path.exists(path): return done with open(path, encodingutf-8) as f: for line in f: line line.strip() if not line: continue try: rec json.loads(line) except json.JSONDecodeError: continue # 上次崩潰寫了半行跳過 if rec.get(ok): done.add(rec[task_id]) return done這里有個(gè)細(xì)節(jié)只把ok: True的算作已完成失敗的記錄留著但允許重跑。同時(shí)要處理文件最后一行寫了一半的情況——進(jìn)程被殺的時(shí)候緩沖區(qū)可能寫到一半這一行是壞的 JSON解析失敗直接跳過就行不要因?yàn)橐恍袎臄?shù)據(jù)讓整個(gè)續(xù)跑邏輯崩掉。用 JSONL 而不是一個(gè)大 JSON 數(shù)組也是同樣的道理。大數(shù)組要整體解析中途壞了整個(gè)文件都讀不了JSONL 是逐行獨(dú)立的壞一行不影響其他行。這個(gè)格式在日志類的批量場(chǎng)景里幾乎是標(biāo)準(zhǔn)答案。4.3 錯(cuò)誤分類與重試策略不是所有錯(cuò)誤都值得重試。我的分類方式是這樣錯(cuò)誤類型典型表現(xiàn)處理策略上下文超限400 報(bào)錯(cuò)提示超過最大長(zhǎng)度不重試裁剪輸入后重新入隊(duì)顯存不足500 或連接被重置退避 30 秒后重試最多 2 次模型加載中連接拒絕 / 超時(shí)先 warmup再重試次數(shù)放寬JSON 解析失敗客戶端解析異常提高約束強(qiáng)度后重試最多 3 次內(nèi)容質(zhì)量不合格裁判模型判定換一種 prompt 策略重試最多 1 次重試要帶退避而且每次重試最好稍微改一下參數(shù)比如把 temperature 調(diào)低一點(diǎn)或者把 prompt 里的格式約束加強(qiáng)。同樣的輸入、同樣的參數(shù)、同樣的隨機(jī)種子跑兩次大概率得到同樣的錯(cuò)誤這種重試純屬浪費(fèi)時(shí)間。另外一定要設(shè)一個(gè)全局的重試上限防止某條毒數(shù)據(jù)把整個(gè)隊(duì)列卡死。我的做法是把重試超過 N 次的 task 丟進(jìn)一個(gè)死信隊(duì)列文件主流程繼續(xù)往下跑跑完再統(tǒng)一人工看。4.4 結(jié)果落盤與可追溯批量任務(wù)跑完之后你多半會(huì)遇到這條結(jié)果為什么是這個(gè)的追問。所以每條記錄里除了最終結(jié)果我還會(huì)存三樣?xùn)|西用的哪個(gè)模型、prompt 的哈希、以及原始輸入。record { task_id: task.task_id, ok: True, model: MODEL_ID, prompt_ver: v3, # prompt 版本號(hào)改了就升 input_hash: sha1(task.payload[text]), result: result, elapsed_ms: int(elapsed * 1000), ts: int(time.time()), }prompt_ver這個(gè)字段看著不起眼后面排查問題的時(shí)候價(jià)值極大。你會(huì)發(fā)現(xiàn)有些結(jié)果質(zhì)量下降追溯回去是因?yàn)槟炒胃牧?prompt 但沒記錄導(dǎo)致新老數(shù)據(jù)混在一起沒法比較。有版本號(hào)就能按版本切分統(tǒng)計(jì)。elapsed_ms用來算平均耗時(shí)和 P95幫你判斷要不要換模型或者調(diào)并發(fā)。我一開始沒存這個(gè)后來想優(yōu)化性能的時(shí)候發(fā)現(xiàn)沒法量化只能重新跑一遍白花了兩個(gè)小時(shí)。5. 跑起來才暴露的三個(gè)坑上下文漂移、JSON 抖動(dòng)、顯存不回收前面講的都是設(shè)計(jì)層面的事真跑起來之后問題往往出在你想不到的地方。這一節(jié)我把幾個(gè)印象最深的故障完整復(fù)盤一遍包括我當(dāng)時(shí)是怎么一步步定位的因?yàn)榕挪樗悸繁冉Y(jié)論更有復(fù)用價(jià)值。5.1 第 37 條開始返回空內(nèi)容一次完整的排查鏈路現(xiàn)象一批 200 條的任務(wù)前 36 條都正常從第 37 條開始模型返回的內(nèi)容是空字符串不報(bào)錯(cuò)HTTP 200finish_reason是stop。第一步我先確認(rèn)是不是數(shù)據(jù)問題。把第 37 條的輸入單獨(dú)拿出來脫離批處理再跑一次——正常返回。排除了輸入本身的問題。第二步懷疑是狀態(tài)污染。因?yàn)槲业膱?zhí)行器是個(gè)帶記憶的智能體每條任務(wù)復(fù)用同一個(gè)對(duì)話歷史只在末尾追加新內(nèi)容。第 37 條單獨(dú)跑正常但如果在跑完前 36 條之后再跑它就復(fù)現(xiàn)了。這就鎖定了是歷史累積導(dǎo)致的。第三步打印上下文長(zhǎng)度。果然跑到第 36 條的時(shí)候累計(jì)的 messages 已經(jīng)有 9000 多 token超過了我給模型設(shè)的 8K 上下文。服務(wù)端的處理方式是靜默截?cái)唷炎钋懊娴?system prompt 和最初的對(duì)話全砍了只留最后幾條。模型看到的是幾十條沒有頭沒有尾的對(duì)話記錄它不知道自己在干什么于是輸出空。這個(gè)坑的本質(zhì)是智能體的記憶和上下文窗口是兩回事。記憶可以存在外部文件、數(shù)據(jù)庫(kù)、向量庫(kù)但每次送給模型的只能是窗口內(nèi)那一段。把完整歷史一股腦塞進(jìn)去必然溢出。修法有三層。第一層每條任務(wù)獨(dú)立不復(fù)用歷史。批量任務(wù)里 90% 的場(chǎng)景根本不需要跨條記憶復(fù)用歷史純屬自找麻煩。第二層確實(shí)需要多輪記憶時(shí)做滑動(dòng)窗口加摘要保留最近 K 輪原文更早的用一次模型調(diào)用壓縮成一段摘要。第三層請(qǐng)求前做 token 預(yù)估超了就主動(dòng)裁剪別等服務(wù)端幫你截——它截的位置你控制不了。def trim_messages(messages, max_tokens6000, keep_systemTrue): 粗略按字符數(shù)裁剪中文約 1.5 字/token留足余量 def est(m): return len(m[content]) * 0.7 total sum(est(m) for m in messages) if total max_tokens: return messages system [m for m in messages if m[role] system] if keep_system else [] rest [m for m in messages if m[role] ! system] # 從最舊的開始丟保留最近的 while rest and sum(est(m) for m in system rest) max_tokens: rest.pop(0) return system rest字符數(shù)乘系數(shù)這個(gè)估算很粗糙但足夠用。真要精確可以用對(duì)應(yīng)的 tokenizer 算不過在批量場(chǎng)景里粗略估算加足夠的安全余量性價(jià)比更高。5.2 結(jié)構(gòu)化輸出忽好忽壞第二個(gè)坑更隱蔽。用同一個(gè) prompt、同一個(gè) schema前面一百條輸出都是規(guī)規(guī)矩矩的 JSON從某一條開始模型開始在前面加一句好的以下是抽取結(jié)果后面又加一句希望對(duì)你有幫助。這個(gè)問題的根源是采樣隨機(jī)性。溫度不為零的時(shí)候模型每次選詞都有隨機(jī)性某一次它選了輸出一句客套話這個(gè)分支后面就順著這個(gè)分支走下去了。任務(wù)越多樣、prompt 越寬松觸發(fā)概率越高。我的處理是三層防御。第一層把 temperature 壓到 0.1 以下抽取類任務(wù)甚至可以 0。第二層在 system prompt 里用強(qiáng)約束的措辭不是請(qǐng)輸出 JSON而是只輸出 JSON第一個(gè)字符必須是左花括號(hào)不要輸出任何解釋、前后綴或代碼塊標(biāo)記。第三層客戶端用寬松解析兜底。還有一個(gè)容易被忽略的點(diǎn)max_tokens設(shè)太小也會(huì)導(dǎo)致 JSON 截?cái)?。模型輸出了一個(gè)完整的對(duì)象但正好在}之前被截?cái)嘟馕霰厝皇　＿@個(gè)錯(cuò)誤看起來像模型不會(huì)輸出 JSON實(shí)際上是參數(shù)設(shè)置問題。我在日志里加了一條判斷——如果finish_reason length直接標(biāo)記為輸出被截?cái)嘧咧卦嚥⑻岣?max_tokens而不是走 JSON 修復(fù)邏輯這樣能省下不少無效重試。5.3 并發(fā)一開就掉速這個(gè)我最開始完全沒想明白串行跑 100 條用了 8 分鐘并發(fā) 4 跑同樣的 100 條用了 11 分鐘越并發(fā)越慢。排查下來是兩個(gè)原因疊加。第一GPU 算力被切分每個(gè)請(qǐng)求的速度都下降而總吞吐沒有提升——這是預(yù)期內(nèi)的。第二也是更致命的并發(fā) 4 的時(shí)候顯存占用峰值上去了觸發(fā)了 KV cache 的換入換出甚至有一次直接 OOM 導(dǎo)致服務(wù)重啟重啟之后又要重新加載模型這十幾秒的加載時(shí)間被平攤到整個(gè)批次上把省下來的時(shí)間全吃了。最終的解法是單實(shí)例串行 多實(shí)例并行。開兩個(gè)服務(wù)實(shí)例綁不同端口各加載一個(gè)模型兩個(gè) Python 進(jìn)程分別打不同的端口。這樣既是并行的又不會(huì)在單個(gè)實(shí)例內(nèi)部爭(zhēng)搶資源。代價(jià)是顯存要夠兩個(gè)模型同時(shí)常駐如果顯存不夠那就老老實(shí)實(shí)串行接受這個(gè)速度。方案顯存占用相對(duì)吞吐穩(wěn)定性單實(shí)例并發(fā) 4高峰值疊加差可能更慢低單實(shí)例并發(fā) 1低基準(zhǔn)高雙實(shí)例各并發(fā) 1高雙份權(quán)重約 1.8 倍高雙實(shí)例共享同一模型中需確認(rèn)是否共享權(quán)重取決于實(shí)現(xiàn)中這張表里的數(shù)字是我在自己機(jī)器上實(shí)測(cè)的量級(jí)你的結(jié)果會(huì)不一樣但趨勢(shì)應(yīng)該是類似的本地推理優(yōu)先保證單請(qǐng)求的穩(wěn)定橫向擴(kuò)展靠實(shí)例不靠線程。6. 參數(shù)調(diào)優(yōu)把不確定性壓進(jìn)可接受區(qū)間參數(shù)這事兒官方文檔給的默認(rèn)值是通用場(chǎng)景下的折中不是你這個(gè)場(chǎng)景的最優(yōu)解。批量任務(wù)和聊天對(duì)話對(duì)參數(shù)的要求差別很大前者要的是極致的穩(wěn)定和可復(fù)現(xiàn)后者要的是一定程度的多樣性。6.1 temperature / top_p / repeat_penalty 的組合我的默認(rèn)配置是這樣的參數(shù)抽取/分類任務(wù)摘要/改寫任務(wù)規(guī)劃/推理任務(wù)temperature0.0 - 0.10.3 - 0.50.5 - 0.7top_p0.90.90.95repeat_penalty1.051.051.1max_tokens按字段數(shù)估算 ×2按原文長(zhǎng)度 0.31024溫度調(diào)到 0 的時(shí)候理論上輸出是確定的但實(shí)際跑起來你會(huì)發(fā)現(xiàn)同一個(gè)輸入兩次調(diào)用偶爾還是有細(xì)微差異——這是浮點(diǎn)運(yùn)算和批處理順序帶來的不是參數(shù)沒生效。所以別指望絕對(duì)可復(fù)現(xiàn)能做到95% 一致就已經(jīng)很方便調(diào)試了。repeat_penalty這個(gè)參數(shù)在本地模型上特別容易踩坑。設(shè)得太高比如 1.3模型會(huì)為了避免重復(fù)而刻意換詞導(dǎo)致專有名詞、字段名都被改掉抽取任務(wù)直接崩。設(shè)得太低長(zhǎng)文本生成會(huì)出現(xiàn)車轱轆話。1.05 到 1.1 這個(gè)區(qū)間比較安全抽取類任務(wù)盡量往低走。還有一點(diǎn)同一批次內(nèi)不要把參數(shù)改來改去。我吃過這個(gè)虧中途覺得輸出太死板把溫度從 0.1 調(diào)到 0.4結(jié)果同一批次里前半段和后半段的風(fēng)格差異明顯下游做統(tǒng)計(jì)的時(shí)候沒法合并。參數(shù)要改就整批重跑或者加版本號(hào)區(qū)分。6.2 讓模型少說話的三個(gè)手段批量任務(wù)里輸出長(zhǎng)度直接等于時(shí)間成本。模型多寫一句廢話500 條任務(wù)就多花好幾分鐘。壓輸出長(zhǎng)度有三個(gè)手段效果依次遞減。第一個(gè)是max_tokens。硬限制最直接。但要注意留夠余量設(shè)太小會(huì)截?cái)?JSON反而增加失敗重試。第二個(gè)是 prompt 里的顯式約束。不要只寫簡(jiǎn)潔回答要寫具體的結(jié)構(gòu)要求比如輸出三個(gè)字段每個(gè)字段不超過 20 字不要輸出其他內(nèi)容。具體的數(shù)字比抽象的形容詞有效得多。第三個(gè)是 few-shot 示例。給一兩個(gè)示例讓模型照著格式走。示例的格式必須和你期望的完全一致包括有沒有空格、有沒有標(biāo)點(diǎn)。模型對(duì)示例的模仿能力比對(duì)指令的遵循能力強(qiáng)得多這是小模型最實(shí)用的一招。注意few-shot 示例會(huì)計(jì)入 token占上下文。如果你為了壓輸出而加了三個(gè)長(zhǎng)示例可能反而更慢。我的經(jīng)驗(yàn)是最多兩個(gè)示例每個(gè)控制在 100 字以內(nèi)。6.3 一套可以直接抄的配置把前面所有東西串起來一個(gè)能直接跑的骨架大概長(zhǎng)這樣import json, time, queue, threading, hashlib from openai import OpenAI CFG { base_url: http://127.0.0.1:1234/v1, model_plan: your-planner-model-id, model_exec: your-executor-model-id, temperature_exec: 0.1, top_p: 0.9, repeat_penalty: 1.05, max_tokens_exec: 512, timeout: 300, } client OpenAI(base_urlCFG[base_url], api_keylocal, timeoutCFG[timeout]) def call(model, system, user, max_tokens512, temperature0.1, retries3): last_err None for i in range(retries): try: r client.chat.completions.create( modelmodel, messages[ {role: system, content: system}, {role: user, content: user}, ], temperaturetemperature, top_pCFG[top_p], max_tokensmax_tokens, ) choice r.choices[0] if choice.finish_reason length: max_tokens int(max_tokens * 1.5) # 被截?cái)嗵舷拗卦?continue return choice.message.content except Exception as e: last_err e time.sleep(min(2 ** i * 5, 30)) raise RuntimeError(fcall failed after {retries} retries: {last_err})這段代碼里有幾個(gè)我認(rèn)為必須保留的細(xì)節(jié)finish_reason length的判斷并自動(dòng)抬高上限、指數(shù)退避但封頂 30 秒、以及失敗之后拋出帶上下文的異常而不是靜默返回 None。靜默失敗是批量任務(wù)里最難查的問題寧可讓程序崩出來。7. 我把這套東西跑順之后的一些體會(huì)這套流水線我在幾個(gè)不同的數(shù)據(jù)批上跑過規(guī)模從幾百條到幾千條機(jī)器從單卡 16G 到單卡 24G。最大的體會(huì)是本地智能體的瓶頸基本不在模型能力上而在工程約束上。一個(gè) 7B 模型在結(jié)構(gòu)清晰的單項(xiàng)任務(wù)上表現(xiàn)可能比一個(gè) 32B 模型在混亂 prompt 下更可靠——因?yàn)榍罢哂肋h(yuǎn)不會(huì)超時(shí)、不會(huì) OOM、不會(huì)因?yàn)樯舷挛囊绯龆蝗皇洝Ａ硪粋€(gè)體會(huì)是關(guān)于值不值得。本地跑批的時(shí)間成本是實(shí)打?qū)嵉囊粭l任務(wù)快則兩秒慢則三十秒500 條就是幾小時(shí)的等待。所以我現(xiàn)在會(huì)先花十分鐘做一個(gè)判斷這個(gè)任務(wù)的失敗代價(jià)高不高如果輸出要直接進(jìn)下游系統(tǒng)本地跑 三重校驗(yàn)就值得如果只是給人做參考人工掃一眼的成本比搭管道還低那不如手動(dòng)來幾條。最后分享一個(gè)我覺得挺有用的小習(xí)慣給每個(gè)批次的運(yùn)行日志打一個(gè)批次號(hào)并記錄當(dāng)時(shí)的模型配置、prompt 版本、參數(shù)快照。一個(gè) JSON 文件就行幾十行。等到兩周后你發(fā)現(xiàn)某批結(jié)果有問題想復(fù)現(xiàn)的時(shí)候沒有這個(gè)快照你就得靠回憶去猜當(dāng)時(shí)用了什么配置。我因?yàn)檫@個(gè)習(xí)慣至少省過兩次通宵重跑。