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