先別急著 Scale。這句話聽起來很反直覺尤其是在“AI”已經(jīng)被默認和“規(guī)?；苯壴谝黄鸬慕裉?。很多人拿到一個新模型、跑通一條生成流程后的第一反應(yīng)就是立刻把它放大從 20 條擴到 2000 條從單機調(diào)到多機從一個人用變成全團隊用。但我在實際項目里看到的往往是另一個版本的故事批量任務(wù)上線不到半天輸出質(zhì)量忽高忽低錯誤日志堆滿了磁盤成本數(shù)字開始讓人肉疼最后只能緊急拉停。問題不全在模型也不全在并發(fā)。問題在于很多團隊把“單次跑通”誤當成了“可以規(guī)模化”。在傳統(tǒng)軟件開發(fā)里功能能跑通距離上線往往只差性能優(yōu)化和部署流程。但在 AI 時代這條路徑被徹底改寫了。因為 AI 的輸出不是確定性的你每一次調(diào)用得到的結(jié)果都可能不一樣如果你在沒有設(shè)計好反饋、日志、重試和人工校驗邊界的情況下直接擴容那么 scale 放大的不只是成功案例還會放大失敗率、幻覺、壞數(shù)據(jù)和沒人處理的異常。所以我的主判斷很明確AI 時代擴容的第一順序不是加機器而是先把“可控性”擴起來。這也是這篇文章想講清楚的事。1. AI 先改變的不是吞吐量而是“擴容的瓶頸”1.1 傳統(tǒng)擴容解決的是“資源夠不夠”新擴容要解決的是“結(jié)果穩(wěn)不穩(wěn)”過去我們談?wù)?Scale通常是在談?wù)撏掏铝坑脩粽埱笞兌嗔藬?shù)據(jù)庫連接不夠了接口響應(yīng)變慢了那就加服務(wù)器、加緩存、加消息隊列。這套思路的底層假設(shè)是只要給足資源系統(tǒng)行為就能保持穩(wěn)定。AI 應(yīng)用的第一批規(guī)模化場景很容易讓人沿用舊思路。接口慢了可能是模型服務(wù)并發(fā)不夠任務(wù)多了可能是腳本跑得不夠快存儲滿了可能是數(shù)據(jù)同步不到位。這些判斷沒有錯但只覆蓋了問題的一半。另一半是每次調(diào)用模型拿到的輸出并不穩(wěn)定。同一段 prompt同一個輸入可能這輪輸出是對的下一輪就漏掉一個關(guān)鍵條件更麻煩的是模型在某些情況下會一本正經(jīng)地生成不存在的引用、錯誤的參數(shù)、甚至完全偏移主題的內(nèi)容。也就是說AI 系統(tǒng)的核心不確定性不在服務(wù)器而在輸出本身。這帶來的變化是擴容的瓶頸從“資源飽和度”轉(zhuǎn)移到了“結(jié)果可信度”。你可以用 1000 臺機器把吞吐量撐上去但沒法用機器直接解決 5% 的壞輸出對下游系統(tǒng)造成的污染。1.2 真正的 scale 分為四層很多人只看到了第一層我通常會把 AI 系統(tǒng)的擴容拆成四個層面流量規(guī)模單位時間內(nèi)能處理多少請求。數(shù)據(jù)規(guī)模知識庫、語料、文檔集有多大索引能不能跟上。任務(wù)規(guī)模批量任務(wù)能跑多長、能支撐多少種輸入變化。反饋規(guī)模輸出結(jié)果有人看、有人審、有人修正、能回流進下一輪改進。傳統(tǒng)思路關(guān)注前兩層尤其是第一層。但 AI 項目真正容易崩的地方在第三層和第四層。流量規(guī)模上去之后如果任務(wù)輸入仍然五花八門腳本和提示詞很快就撐不住。數(shù)據(jù)規(guī)模上去之后如果你沒有建立對應(yīng)的上下文管理策略模型很容易在長文檔里丟掉最關(guān)鍵的約束。任務(wù)規(guī)模上去之后如果失敗重試和人工審核跟不上壞數(shù)據(jù)就會直接進入你可能還要用來做訓(xùn)練的成果集。所以我給團隊的建議通常是先別急著把請求量拉到最高先確認你的任務(wù)能不能扛住輸入變化你的結(jié)果有沒有人在看。這個順序一旦反了后面所有優(yōu)化都在給錯誤加速。1.3 為什么“單條成功”會帶來安全感這里還有一種心理因素讓人更容易做出“先擴容”的沖動決定。當你手動跑到第 5 條、第 10 條時輸出看起來都不錯你會產(chǎn)生一個很強的直覺這個流程已經(jīng)成熟了。然后你把并發(fā)調(diào)到 8 或者 16腳本開始批量跑。你能看到的只是進度條在往前走直到過了很久你翻結(jié)果目錄時才發(fā)現(xiàn)有一半輸出是重復(fù)的還有一部分壓根沒有按照 prompt 里的硬性要求輸出。原因很簡單手動驗證時你的注意力在隱性地兜底。輸入是你一條條選的調(diào)用的順序是你控制的異常出現(xiàn)時你會下意識判斷并跳過。批量腳本沒有這個能力它只會把所有輸入一視同仁地交給模型然后把你沒有預(yù)料到的所有異常原樣寫進結(jié)果里。因此真正的 Scale 準備不是從 10 到 1000 直接跳而是先把“無人工干預(yù)時系統(tǒng)也能穩(wěn)定處理常見異?！边@件事做好。注意批量調(diào)用之前先用 20 到 50 條有代表性的樣本跑一遍不要只跑順手的輸入。這一步會幫你過濾掉大多數(shù)“跑通假象”。2. 先擴展工作流再擴展規(guī)模提示詞、上下文和樣本基線2.1 提示詞不應(yīng)該硬編碼在腳本里很多人寫 AI 批處理腳本時會直接把 prompt 寫成字符串塞在代碼里。這在單次實驗里沒什么問題但你要 Scale 的時候它就是第一個坑。原因是提示詞一定會隨著任務(wù)變而你不會記得哪一版 prompt 對應(yīng)哪一輪輸出。如果哪天結(jié)果變差你根本說不清楚是模型更新了、輸入數(shù)據(jù)變了還是提示詞被誰動過。我比較推薦的做法是把提示詞模板獨立成文件用版本號管理起來。腳本只負責(zé)加載模板、填充變量、調(diào)用模型、記錄結(jié)果。這樣你至少能做到每次調(diào)用都能回溯到當時用的提示詞版本。下面是一個示意結(jié)構(gòu)關(guān)鍵不是代碼本身而是分層方式# prompts/generate_draft.txt 你是一名技術(shù)編輯。 根據(jù)下面的要點寫一段 300 字左右的博客草稿。 要求 - 語言自然不要廣告腔 - 開頭要有具體場景 - 結(jié)尾要給一句實操建議。 【本期要點】 {{input}} 【參考材料】 {{context}}# process.py示意結(jié)構(gòu) import json import time from pathlib import Path prompt_template Path(prompts/generate_draft.txt).read_text(encodingutf-8) def call_model(system_prompt: str, user_prompt: str, model: str) - str: # 這里對接你自己的模型服務(wù) # 上線前先確認上下文窗口、超時時間和錯誤返回格式 return def run_one(sample: dict) - dict: prompt prompt_template.replace({{input}}, sample[input]) prompt prompt.replace({{context}}, sample.get(context, )) started time.time() output call_model( system_prompt你是一個嚴謹?shù)募夹g(shù)編輯, user_promptprompt, modelsample.get(model, default), ) return { sample_id: sample[id], prompt: prompt, output: output, duration_ms: int((time.time() - started) * 1000), created_at: time.time(), }注意這只是一個結(jié)構(gòu)示例不能直接跑。它的意義在于提醒你把“指令”“樣例輸入”“參考材料”分開管理。后面排查“為什么這條輸出偏題”時你會節(jié)省大量時間。2.2 上下文要拆成三部分而不是一股腦全塞進去做 AI 工程時間久了你會慢慢形成一個共識上下文管理往往比提示詞措辭更影響結(jié)果。我習(xí)慣把上下文拆成三層固定指令模型必須遵守的角色和規(guī)則比如輸出格式、字數(shù)、語氣。動態(tài)輸入當次任務(wù)真正要處理的數(shù)據(jù)比如一段待總結(jié)的文檔。參考材料可選的背景知識比如企業(yè)知識庫片段、相關(guān)歷史結(jié)果。這三層不應(yīng)該混在同一個字符串里。原因是它們出問題的概率完全不同。固定指令如果被輸入內(nèi)容“污染”模型可能忽略規(guī)則輸入內(nèi)容過長可能把前面指令擠出上下文窗口參考材料如果太雜模型會失去焦點。在擴容之前我建議你先把這三層寫清楚最好在代碼里用不同的變量管理。每輪調(diào)用結(jié)束以后把最終拼好的 prompt 也存進日志。這樣出現(xiàn)壞結(jié)果時你能立刻看出是規(guī)則被覆蓋還是輸入本身有問題還是參考材料給錯了。2.3 建立你的“10 條樣本基線”我想給每個準備 Scale 的團隊推薦一個很輕量的做法先建立一個基線表不需要很重只需要 10 到 20 條代表性輸入。選擇樣本時不要只挑簡單的。至少包含這幾類正常輸入。超短輸入比如只有一句話。超長輸入比如接近上下文上限的文本。含特殊符號或代碼片段的輸入。之前模型最容易出錯的輸入。然后逐條小批量執(zhí)行記錄輸出質(zhì)量?？梢允侨斯ご蛉齻€檔位通過、勉強通過、不通過。這組數(shù)據(jù)就是你的基線。之后每當你調(diào)整提示詞、切換模型、改上下文策略、甚至升級依賴版本時都用同一批樣本重跑一遍。如果通過率明顯下降說明你的改動帶來了回歸。這比“感覺變好了”“效果差不多”這種判斷可靠得多。這里有一句我經(jīng)常對同事說的話基線不是用來證明系統(tǒng)有多好而是用來防止你在擴容之后才發(fā)現(xiàn)系統(tǒng)變差了。2.4 小批量試點是通往批量任務(wù)的唯一路徑當你有了基線下一步不是直接上并發(fā)而是先跑一個小批量比如 200 條。小批量批次的意義在于你能完整地看一遍“輸入-調(diào)用-輸出-存儲”的閉環(huán)。你會看到某些輸入觸發(fā)了超時某些輸出沒有按 JSON 返回某些文件路徑有中英文混用問題某些文本編碼導(dǎo)致腳本中斷。這些問題在 10 條樣本里未必暴露但在 200 條里基本都會出現(xiàn)。等這個小批量跑完你再決定是不是要增加到幾千條節(jié)奏就穩(wěn)了。不要第一輪就把并發(fā)拉到 16。先以 1 并發(fā)跑 50 條確認沒有底層配置問題再以 4 并發(fā)跑 200 條觀察耗時和失敗率最后才考慮更高的并發(fā)。3. 從原型到生產(chǎn)差的不是模型而是日志、權(quán)限、異常和邊界3.1 日志是 Scale 的地基做不好一切無從談起在沒有日志的情況下討論擴容基本等于閉著眼睛開車。尤其是 AI 調(diào)用你不僅要記錄“調(diào)用了什么模型”還要記錄和業(yè)務(wù)強相關(guān)的字段。我在工程里至少會記錄這些內(nèi)容請求 ID 和業(yè)務(wù) ID。提示詞模板版本。最終拼出來的完整 prompt或至少它的哈希值。模型的返回原文。耗時、token 消耗。當時使用的模型和參數(shù)。是否觸發(fā)重試、重試次數(shù)、最終是否成功。這個日志表不用一開始設(shè)計得很龐大。最簡單的方案是每行結(jié)果存成 JSON寫進一個按日期切分的結(jié)果目錄。之后不管是排查壞樣本、統(tǒng)計成本還是復(fù)盤質(zhì)量都有據(jù)可查。很多團隊在原型階段忽略日志等到生產(chǎn)環(huán)境出問題再去補費時費力。更麻煩的是缺失的日志無法事后補回來。# 記錄一條結(jié)果到文件示意結(jié)構(gòu) import json from pathlib import Path def save_result(result: dict, out_dir: Path) - None: out_dir.mkdir(parentsTrue, exist_okTrue) path out_dir / f{result[sample_id]}.json with open(path, w, encodingutf-8) as f: json.dump(result, f, ensure_asciiFalse, indent2)3.2 異常重試要有但不能盲目重試AI 調(diào)用過程中網(wǎng)絡(luò)超時、模型服務(wù)限流、返回格式異常都很常見。沒有重試策略任務(wù)容易中斷重試太激進又可能把限流打得更嚴重甚至造成成本浪費。一個相對穩(wěn)妥的做法是第一次失敗后等待 1 秒再重試。第二次失敗后等待 5 秒再重試。連續(xù)三次失敗后寫入失敗隊列不再自動重試。失敗隊列觸發(fā)告警由人工查看到底是什么原因。這里的關(guān)鍵判斷是不要默認“重試一定能成功”。如果一條輸入反復(fù)失敗它是值得人工分析的壞樣本。如果你不區(qū)分失敗類型就無限重試最后只會得到一堆重復(fù)調(diào)用記錄以及一張高得嚇人的賬單。3.3 權(quán)限、密鑰和成本邊界要提前設(shè)計還有一個經(jīng)常被忽略的點是權(quán)限。原型階段你可能會圖省事把 API Key 直接寫在腳本里甚至放在前端請求里。這在個人電腦上問題不大但一旦變成多人使用的服務(wù)就是嚴重風(fēng)險。進入生產(chǎn)前至少要確認API Key 存放在服務(wù)端環(huán)境變量或密鑰管理服務(wù)中。前端和后端之間的調(diào)用經(jīng)過受控接口而不是直接暴露模型服務(wù)地址。不同角色使用不同的訪問權(quán)限比如普通用戶不能改提示詞模板。設(shè)置單日調(diào)用上限和預(yù)算告警避免腳本 bug 導(dǎo)致成本失控。成本這塊我多強調(diào)一句AI 調(diào)用成本不是只算 token 費用還要算失敗重試的成本、人工審核的成本、以及壞結(jié)果流入下游后返工的成本。很多人只盯著模型單價最后發(fā)現(xiàn)真正花費時間的是清理壞數(shù)據(jù)。3.4 批量任務(wù)異常排查鏈路當你真的遇到批量任務(wù)異常時建議按下面這個順序排查而不是直接懷疑模型不好用。先看現(xiàn)象是請求失敗、卡住不動、輸出為空、還是輸出格式不對再看輸入這一批輸入是從哪里來的文件編碼對不對字段是否完整有沒有異常字符導(dǎo)致 prompt 拼接出錯再看配置模型版本、提示詞版本、輸出目錄、權(quán)限、依賴庫版本最近有沒有變化再看參數(shù)并發(fā)數(shù)、超時時間、重試次數(shù)、上下文窗口是否和當前任務(wù)匹配最后看模型服務(wù)上游是否限流服務(wù)是否健康最近模型是否有更新或調(diào)整。這個順序可以有效避免一個常見誤區(qū)一上來就改提示詞。很多問題其實出在數(shù)據(jù)清洗和腳本健壯性上跟模型本身關(guān)系不大。4. 當應(yīng)用從單人變成多人、多系統(tǒng)真正要擴展的是反饋回路4.1 不要讓“提示詞大師”成為單點瓶頸在個人使用階段一個人可以靠記憶管理所有提示詞和參數(shù)。但 Scale 到團隊協(xié)作時這就會變成災(zāi)難。團隊里如果有一個人最懂提示詞所有人都在等他把規(guī)則調(diào)好。一旦他請假業(yè)務(wù)就卡住一旦他換了一版提示詞其他人根本不知道影響范圍。這不是團隊能力問題而是流程沒有可追溯性。我建議團隊至少做到三點提示詞模板入庫有版本號。所有參數(shù)調(diào)整通過配置管理而不是散落在聊天記錄里。每周復(fù)盤一批壞樣本明確下一次迭代要改進的規(guī)則。這三點沒有一項很復(fù)雜但它們決定了 AI 應(yīng)用能不能脫離個人英雄主義變成團隊能持續(xù)迭代的能力。4.2 從直連腳本到接口化、隊列化當接入方從一個腳本變成多個系統(tǒng)比如內(nèi)容平臺、運營后臺、產(chǎn)品接口你至少要開始考慮接口化。接口化不是把腳本包一層 HTTP API 就完事而是要處理請求格式統(tǒng)一。鑒權(quán)和配額。結(jié)果異步獲取或回調(diào)。失敗任務(wù)的重新發(fā)送。調(diào)用方能看到任務(wù)狀態(tài)而不是只能等結(jié)果。一個常見的中間方案是引入任務(wù)隊列把所有調(diào)用轉(zhuǎn)成異步任務(wù)。這樣即使某個時刻調(diào)用量很大也不會把模型服務(wù)直接打掛。# 偽代碼任務(wù)隊列的基本思路 # submit_task(prompt_id, payload) # worker 進程接收任務(wù) - 加載模板 - 調(diào)用模型 - 保存結(jié)果 - 寫日志 # 連續(xù)失敗超過 3 次 - 寫入 dead_letter 隊列 - 觸發(fā)告警如果你的團隊已經(jīng)在用 Spring AI 這類集成框架接口化通常會省不少事。但框架不能替你決定日志結(jié)構(gòu)、權(quán)限邊界和人工審核流程。這些屬于系統(tǒng)設(shè)計不是框架職責(zé)。4.3 存儲和數(shù)據(jù)同步也要遵循“先小范圍驗證”說到數(shù)據(jù)規(guī)模這里有一個很容易踩的坑還沒想清楚目錄結(jié)構(gòu)就把整個歷史數(shù)據(jù)集復(fù)制到目標環(huán)境。我在一些數(shù)據(jù)量級比較大的項目里見過這樣的問題團隊為了準備訓(xùn)練語料一次性同步了幾千個文檔結(jié)果發(fā)現(xiàn)文件命名沖突、權(quán)限不一致、部分文件損壞最后只能清空重來。如果你想在 TrueNAS Scale 這類 NAS 平臺上配置數(shù)據(jù)同步方法可以很細但原則只有一個先配對兩臺機器同步一個小數(shù)據(jù)集確認文件名、權(quán)限、修改策略都符合預(yù)期再放到定時任務(wù)里同步全量。這跟在 AI 批量任務(wù)里先跑 200 條再跑全量是同一個道理。不要被“全量同步”四個字迷惑。全量意味著你正在把一個小錯誤放大成一次大規(guī)模返工。4.4 人工審核不是抽樣而是一條顯性流程很多團隊在 Scale 之前總覺得自己的人工審核方案沒問題。等到量起來后才發(fā)現(xiàn)所謂審核就是“抽空看看結(jié)果”一旦任務(wù)堆上來根本看不過來。正確做法是在流程設(shè)計階段就把人工審核占位。你可以按輸出類型和風(fēng)險等級分類高風(fēng)險內(nèi)容必須人工審核后才能發(fā)布。中風(fēng)險內(nèi)容機器預(yù)審合格后再人工抽檢。低風(fēng)險內(nèi)容系統(tǒng)自動處理定期復(fù)盤壞樣本。關(guān)鍵不是“有沒有人看”而是“誰能決定要不要看”。這個判斷如果做不好要么審核過度拖慢效率要么審核不足放大風(fēng)險。5. 擴容前先回答五個問題一個可復(fù)用的判斷清單5.1 你能否說清當前失敗率如果我問你最近 1000 次調(diào)用里有多少次輸出不合格你能立刻答出來嗎如果答案是“沒人統(tǒng)計過”那就說明現(xiàn)在不適合擴容。失敗率是 AI 系統(tǒng)最重要的健康指標。它可以是自動評估也可以是人抽檢后的統(tǒng)計但必須有一個數(shù)字。沒有失敗率的擴容是在賭運氣。5.2 失敗之后誰能看到、誰能重試批量任務(wù)跑完之后如果有 30 條壞結(jié)果它們會被記錄到哪里誰會收到通知重試失敗后下一步動作是什么沒有這個流程壞結(jié)果只會在系統(tǒng)里安靜地躺著直到某一天有人發(fā)現(xiàn)成果集里有大量低質(zhì)量內(nèi)容。5.3 成本增長是線性的還是非線性變陡調(diào)用量翻倍成本也翻倍這是線性增長還好估算。但如果你用了重試機制、加了更長上下文、或者每次失敗都要人工處理成本可能遠遠超過任務(wù)量增速。擴容之前建議先算一筆賬跑 1000 條需要多少錢其中模型費用多少、超時重試費用多少、人工審核時間多少。如果這筆賬算不出來就不要急著擴量。5.4 人工校驗的邊界寫清楚了嗎不是所有任務(wù)都需要人工審核但你必須清楚哪些任務(wù)不需要。判斷標準可以是業(yè)務(wù)風(fēng)險、內(nèi)容合規(guī)、下游用途、數(shù)據(jù)敏感度等。如果這個邊界沒寫清楚那你所謂的審核流程就是看心情。這種不確定性在規(guī)模化之后會成為比模型失敗率更麻煩的管理問題。5.5 這只是擴充一次任務(wù)還是要讓它每天穩(wěn)定運行這是最后一個問題也是最關(guān)鍵的判斷。一次性跑一批任務(wù)是項目每天穩(wěn)定運行是產(chǎn)品。兩者的工程要求完全不同。如果只是臨時跑一批你只需保證腳本能跑完、結(jié)果能保存。但如果是每天運行你還需要考慮調(diào)度、監(jiān)控、告警、數(shù)據(jù)備份、輸出人工審核、模型版本升級策略。我見過不少團隊把一次性任務(wù)腳本直接丟到生產(chǎn)計劃任務(wù)里結(jié)果一個周末沒人盯著積累了幾千條重復(fù)輸出。5.6 一張簡單的判斷表判斷項適合擴容的跡象先別擴容的跡象失敗率低于 1%錯誤種類集中高于 5%每條輸出錯誤類型都不一樣反饋回路有結(jié)果庫壞樣本每周復(fù)盤結(jié)果散落在各人電腦和聊天記錄里成本有預(yù)算監(jiān)控單條成本波動小沒有人知道這個月消耗了多少 token人工審核明確哪些輸出必須人審?fù)耆蕾嚹Ｐ洼敵鰶]有審核環(huán)節(jié)流程復(fù)用提示詞、參數(shù)、數(shù)據(jù)版本可回溯還在靠某個人記憶里的參數(shù)和規(guī)則啟動方式先小批量驗證再逐步放量一批直接拉滿全量這五問不是形式主義它們對應(yīng)的是 Scale 前必須補齊的五塊拼圖質(zhì)量基線、反饋機制、成本模型、人工邊界和可運維性。任何一個缺位擴容都不是加速而是放大故障。如果你這周只做一件事我建議做一次基線測試挑 10 條有代表性的輸入跑一遍把輸出、耗時、錯誤、備注記下來。然后帶著這份基線去和同事討論“是不是真的可以 Scale”。你會發(fā)現(xiàn)真正值得擴展的不是并發(fā)數(shù)而是你對這套系統(tǒng)運行規(guī)律的理解。先把可控性擴起來這才是 AI 時代 scale 的正確起點。