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