戰(zhàn)：API調(diào)用、并發(fā)限速與質(zhì)量管控)
1. 先想清楚再動(dòng)手DALL·E 與 Gemini 的生圖定位差異1.1 兩者的接口形態(tài)與生成風(fēng)格差異做批量生圖之前最容易被忽略的一件事就是DALL·E 和 Gemini 根本不是同一類東西。雖然它們都叫“文生圖模型”但接口形態(tài)、返回方式、適用場(chǎng)景差別很大。DALL·E 走的是 OpenAI 的 Images API核心就是images.generate這一組接口。你傳入提示詞、指定尺寸和數(shù)量它同步返回一張或一組圖片的 URL 或者 base64 數(shù)據(jù)。生成質(zhì)量穩(wěn)定、語(yǔ)義理解細(xì)膩尤其擅長(zhǎng)把長(zhǎng)句子里的多個(gè)約束條件拆解到畫(huà)面里。比如“一只穿紅色雨衣的柴犬站在東京街頭身后是霓虹燈招牌雨滴清晰可見(jiàn)”這種多層描述DALL·E 基本都能還原到位。它的短板也很明顯單次請(qǐng)求最多生成 10 張SDK 頻率限制嚴(yán)格量一大就得考慮排隊(duì)和退避。Gemini 這邊則更像是多模態(tài)大模型的“附帶技能”。你調(diào)用的是 Gemini API 里的generateContent接口把提示詞放進(jìn)contents里同時(shí)指定responseModalities: [Image]模型會(huì)返回生成圖像的內(nèi)聯(lián) base64 數(shù)據(jù)。它的優(yōu)勢(shì)在于如果你本來(lái)就在用 Gemini 做文本生成、圖片理解、甚至視頻理解再順手接入生圖能力整個(gè)架構(gòu)可以共用一套鑒權(quán)和調(diào)用鏈路不用為生圖單獨(dú)維護(hù)一套 SDK。Gemini 的圖在寫(xiě)實(shí)風(fēng)格和光影質(zhì)感上有自己的特色某些場(chǎng)景下甚至比 DALL·E 更細(xì)膩但在復(fù)雜指令的還原度上沒(méi)有 DALL·E 那么“較真”。我自己的感受是如果項(xiàng)目核心就是“把一段描述變成高質(zhì)量圖片”選 DALL·E 更省心如果項(xiàng)目本身是多模態(tài)應(yīng)用比如圖文問(wèn)答、內(nèi)容審核、配圖生成一體化的內(nèi)部工具那用 Gemini 可以把系統(tǒng)復(fù)雜度壓得更低。1.2 選型矩陣什么時(shí)候用 DALL·E什么時(shí)候用 Gemini先給一個(gè)可以直接抄作業(yè)的判斷表場(chǎng)景推薦選擇理由電商商品圖、營(yíng)銷海報(bào)對(duì)畫(huà)面還原度要求極高DALL·E復(fù)雜的商品描述還原更準(zhǔn)出圖穩(wěn)定大量不同風(fēng)格插畫(huà)、虛擬形象Gemini光影質(zhì)感好批次之間風(fēng)格一致性比較容易控制多模態(tài)應(yīng)用中的配圖模塊Gemini與文本生成共用一套 API鏈路簡(jiǎn)單高并發(fā)、大批量日均千張以上DALL·E 排隊(duì)機(jī)制官方限速雖有但退避機(jī)制成熟文檔齊全成本敏感的小團(tuán)隊(duì)Gemini 免費(fèi)額度 低檔位免費(fèi)額度初期夠用試錯(cuò)成本低需要嚴(yán)格按固定比例出圖如 1:1 頭像、9:16 封面兩者均可需實(shí)測(cè)不同尺寸支持能力不同實(shí)測(cè)為準(zhǔn)選擇的關(guān)鍵不是“哪個(gè)模型更強(qiáng)”而是“你的工程鏈路到底愿不愿意為某個(gè)模型做專門適配”。DALL·E 的優(yōu)勢(shì)是生態(tài)成熟Python SDK 里就能完成幾乎所有事Gemini 的優(yōu)勢(shì)是統(tǒng)一如果你已有的項(xiàng)目里 Google 系服務(wù)占了很大比重硬塞一套 OpenAI SDK 反而顯得臃腫。另外一個(gè)很實(shí)際的考量賬號(hào)和網(wǎng)絡(luò)的可得性。這一點(diǎn)我不想展開(kāi)說(shuō)太多但提醒大家在實(shí)際部署前先確認(rèn)好當(dāng)前網(wǎng)絡(luò)環(huán)境下哪個(gè)服務(wù)能夠穩(wěn)定訪問(wèn)、鑒權(quán)暢通。這直接決定了后續(xù)調(diào)試的效率。我見(jiàn)過(guò)不少團(tuán)隊(duì)在架構(gòu)上選了很理想的方案結(jié)果每次跑批處理都要先折騰十分鐘環(huán)境最終被迫換方案。2. 環(huán)境準(zhǔn)備與第一張圖把步驟落實(shí)到能跑通2.1 API 密鑰管理與環(huán)境變量無(wú)論選哪個(gè)模型第一步都是密鑰管理。別把密鑰寫(xiě)死在代碼里哪怕項(xiàng)目不公開(kāi)也盡量不要因?yàn)槟阌肋h(yuǎn)不知道代碼什么時(shí)候會(huì)被分享出去。正確做法是放到環(huán)境變量或者項(xiàng)目根目錄的.env文件里并且保證.env不進(jìn) git。# .env OPENAI_API_KEYsk-xxxxxxxxxxxxxxxx GOOGLE_API_KEYAIzaxxxxxxxxxxxxxxxxPython 端用python-dotenv加載import os from dotenv import load_dotenv load_dotenv() openai_key os.getenv(OPENAI_API_KEY) google_key os.getenv(GOOGLE_API_KEY) if not openai_key and not google_key: raise RuntimeError(至少配置一個(gè) API Key)這里有個(gè)經(jīng)驗(yàn)之談兩個(gè)密鑰都配上代碼里做多后端支持。原因不是“兩個(gè)模型都要用”而是開(kāi)發(fā)階段某個(gè)服務(wù)萬(wàn)一出現(xiàn)臨時(shí)不可用你可以一鍵切到另一個(gè)不至于整個(gè)進(jìn)度卡死。后面要講的完整流水線本身就應(yīng)該設(shè)計(jì)成“生成后端可配置”而不是硬編碼死一個(gè)模型。2.2 單張生成的最小可運(yùn)行代碼DALL·E 的最小可運(yùn)行代碼是這么寫(xiě)的import os from openai import OpenAI client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) resp client.images.generate( modeldall-e-3, prompt一只穿紅色雨衣的柴犬站在東京街頭霓虹燈倒映在濕潤(rùn)的路面上寫(xiě)實(shí)攝影風(fēng)格, size1024x1024, qualityhd, n1, ) image_url resp.data[0].url print(image_url)Gemini 這邊略有不同import os import google.generativeai as genai genai.configure(api_keyos.getenv(GOOGLE_API_KEY)) model genai.GenerativeModel(gemini-2.0-flash-exp) resp model.generate_content( 一只穿紅色雨衣的柴犬站在東京街頭霓虹燈倒映在濕潤(rùn)的路面上寫(xiě)實(shí)攝影風(fēng)格, generation_config{response_modalities: [Image]}, ) # 返回的是內(nèi)聯(lián) base64 image_data resp.candidates[0].content.parts[0].inline_data.data with open(sample.png, wb) as f: f.write(image_data)注意 Gemini 的輸出是 base64需要自己寫(xiě)文件DALL·E 默認(rèn)返回 URL你也可以設(shè)置response_formatb64_json讓它直接返回 base64避免 URL 過(guò)期問(wèn)題。兩條鏈路拿到手之后建議先把這兩份代碼跑通再考慮批量化?；A(chǔ)不牢的批處理腳本后面出bug你都分不清是模型問(wèn)題還是代碼問(wèn)題。2.3 參數(shù)詳解size、quality、n 與 response_format批量場(chǎng)景下參數(shù)選擇決定了你的單位成本和質(zhì)量值得花點(diǎn)時(shí)間理解。size參數(shù)直接影響計(jì)費(fèi)。DALL·E 3 的 1024x1024、1024x1792、1792x1024 三個(gè)檔位價(jià)格不同寬幅圖相對(duì)貴一些。Gemini 這邊也有尺寸限制不同模型對(duì)輸出分辨率有上限。我的建議是按最終用途選尺寸不要一律選最大。如果只是做內(nèi)容配圖web端展示1024x1024 足夠了如果是做印刷物料或視頻封面再看是否需要上高分版本。quality參數(shù)是 DALL·E 特有的。標(biāo)準(zhǔn)檔生成速度快、成本低高清檔細(xì)節(jié)更好但也更慢。實(shí)戰(zhàn)里我發(fā)現(xiàn)如果是批量生成后還要人為篩選建議先用標(biāo)準(zhǔn)檔跑全量篩出值得精修的圖再用高清檔重生成。這樣能用最低成本覆蓋最大樣本量。當(dāng)然這個(gè)策略不適用于“必須一步到位”的生產(chǎn)場(chǎng)景。n參數(shù)在 DALL·E 3 里最多10張Gemini 沒(méi)有 n 參數(shù)但你可以通過(guò)并發(fā)多個(gè)請(qǐng)求來(lái)達(dá)到類似效果。說(shuō)實(shí)話我一般不用n1的批量模式因?yàn)樗趩未握?qǐng)求里一次性消耗多個(gè)配額一旦某張圖出問(wèn)題整個(gè)請(qǐng)求就要重來(lái)。相比之下用并發(fā)控制一個(gè)個(gè)生成單張失敗只需要重試那一張錯(cuò)誤隔離性更好。response_format建議直接設(shè)成b64_json。URL 看起來(lái)方便但拿去做流水線必須下載等于多一次 HTTP 往返還可能出現(xiàn) URL 過(guò)期。base64 直接入庫(kù)或?qū)懕P一步到位。當(dāng)然要注意 base64 比二進(jìn)制膨脹約 33%傳參和寫(xiě)文件時(shí)稍微注意一下內(nèi)存占用就行。兩個(gè)模型都跑通、參數(shù)都理清楚之后你的“單張”能力就緒了。這時(shí)候再回頭看批量需求思路會(huì)清晰很多批量不是把單張代碼包個(gè) for 循環(huán)那么簡(jiǎn)單它還涉及限速、錯(cuò)誤處理、斷點(diǎn)續(xù)跑這些工程問(wèn)題。3. 批量化路上真正難啃的骨頭限速、并發(fā)與重試3.1 速率限制的真實(shí)形態(tài)與應(yīng)對(duì)策略很多人第一次跑批量腳本都栽在同一個(gè)地方前 20 張生成得好好的第 21 張突然報(bào) 429。原因很簡(jiǎn)單你觸發(fā)了服務(wù)端的速率限制。這里的限制通常有兩個(gè)維度每分鐘請(qǐng)求數(shù)RPM和每分鐘圖片數(shù)IPM。DALL·E 的 RPM 限制在不同賬號(hào)等級(jí)下差異很大免費(fèi)檔和付費(fèi)檔差距可以到數(shù)倍。你可以在服務(wù)端文檔里查到具體數(shù)值但更好的做法是代碼里不寫(xiě)死限速參數(shù)而是做成可配置項(xiàng)。這樣賬號(hào)升級(jí)或者換服務(wù)商時(shí)不用改代碼邏輯。# config.py RATE_LIMIT { rpm: 60, # 每分鐘最多請(qǐng)求數(shù) ipm: 120, # 每分鐘最多生成圖片數(shù) max_retries: 6, base_delay: 2.0, }有一個(gè)非常容易踩的坑RPM 限制看著夠用但 IPM 先爆了。比如你每分鐘發(fā) 60 個(gè)請(qǐng)求每個(gè)請(qǐng)求生成 3 張圖圖片數(shù)就是 180直接超了 IPM 限制。所以批量腳本里要同時(shí)跟蹤兩個(gè)維度的消耗。我自己比較推薦的是令牌桶思路維護(hù)一個(gè)計(jì)數(shù)器每次請(qǐng)求前根據(jù)已用請(qǐng)求數(shù)和已用圖片數(shù)做雙重判斷超了任意一個(gè)就等待當(dāng)前周期結(jié)束。實(shí)現(xiàn)不復(fù)雜但能把 429 的出現(xiàn)概率大幅降低。3.2 線程池與信號(hào)量實(shí)現(xiàn)可調(diào)控的并發(fā)Python 里做并發(fā)最高效的方式是用concurrent.futures.ThreadPoolExecutor然后通過(guò)信號(hào)量控制最大并發(fā)數(shù)。import threading import time from concurrent.futures import ThreadPoolExecutor, as_completed semaphore threading.Semaphore(5) # 同一時(shí)刻最多 5 個(gè)請(qǐng)求在飛 def generate_one(task): with semaphore: # 調(diào)用 DALL·E 或 Gemini 的單張生成函數(shù) result generate_image(task[prompt], task[output_path]) return task, result with ThreadPoolExecutor(max_workers10) as executor: futures [executor.submit(generate_one, task) for task in tasks] for future in as_completed(futures): task, result future.result() print(f完成: {task[output_path]})這里有兩個(gè)細(xì)節(jié)值得注意。第一max_workers和信號(hào)量的大小是兩個(gè)概念max_workers決定線程池里最多多少線程信號(hào)量在函數(shù)內(nèi)部再做一層閘門。你可以開(kāi) 20 個(gè)線程同時(shí)只放行 5 個(gè)真實(shí)請(qǐng)求其余的排隊(duì)等待。這樣即使任務(wù)里混入了一些耗時(shí)操作比如圖片后處理也不會(huì)擠占 API 請(qǐng)求的配額。第二不要只靠線程池控制并發(fā)因?yàn)榫€程池只限制線程數(shù)不感知 API 配額。兩個(gè)腳本實(shí)例同時(shí)跑的時(shí)候線程池的限流形同虛設(shè)。把限速參數(shù)做成全局配置必要時(shí)用 Redis 或文件鎖做跨進(jìn)程限流。單機(jī)小批量可以忽略但如果你計(jì)劃定時(shí)任務(wù)多進(jìn)程跑遲早會(huì)遇到這個(gè)問(wèn)題。3.3 退避重試與可觀測(cè)性設(shè)計(jì)429 和 5xx 的錯(cuò)誤處理是批量腳本的核心。不處理重試的批量腳本本質(zhì)上是一次性賭運(yùn)氣。推薦指數(shù)退避策略第一次重試等 2 秒第二次等 4 秒第三次等 8 秒加上隨機(jī)抖動(dòng)防止所有任務(wù)同時(shí)重試導(dǎo)致又撞在一起。import random import time def generate_with_retry(task, max_retries6, base_delay2.0): for attempt in range(max_retries): try: return generate_image(task) except RateLimitError as e: delay base_delay * (2 ** attempt) random.uniform(0, 1) print(f請(qǐng)求被限流{delay:.1f}s 后重試 ({attempt1}/{max_retries})) time.sleep(delay) except APIStatusError as e: if e.status_code 500: delay base_delay * (2 ** attempt) random.uniform(0, 1) print(f服務(wù)端錯(cuò)誤 {e.status_code}{delay:.1f}s 后重試) time.sleep(delay) else: raise # 4xx 錯(cuò)誤一般不重試直接拋出去人工處理 raise RuntimeError(f任務(wù)重試 {max_retries} 次仍然失敗: {task[prompt][:50]})除了重試可觀測(cè)性同樣重要。批量任務(wù)跑起來(lái)后你需要知道跑了多少成功多少失敗多少失敗的原因分布是什么當(dāng)前處于什么階段我習(xí)慣在每個(gè)任務(wù)的處理函數(shù)里記錄狀態(tài)到 SQLite 或 JSONL 文件格式大概是{task_id: t001, prompt: xxx, status: success, cost: 0.04, duration: 3.2, error: null}跑完一批之后直接按狀態(tài)聚合成功率一目了然。這樣做的成本很低但能幫你省下大量的排障時(shí)間。批量任務(wù)最怕的不是失敗而是失敗了不知道、不知道失敗了多少、不知道失敗的原因。4. 提示詞工程讓批量生成的風(fēng)格保持穩(wěn)定4.1 模板化提示詞與變量注入批量生成和單張生成最大的區(qū)別在于你需要讓幾十上百?gòu)垐D片保持統(tǒng)一的風(fēng)格基線而不是每張圖自由發(fā)揮。做法就是模板化提示詞。假設(shè)你要做一套 30 張的“城市夜景插畫(huà)”系列提示詞模板大概是這樣的PROMPT_TEMPLATE ( 一幅城市夜景插畫(huà)主題是{city}的{landmark} 畫(huà)面以深藍(lán)色和金色為主色調(diào)筆觸細(xì)膩 氛圍寧?kù)o且?guī)в幸稽c(diǎn)科幻感適合作為豎版手機(jī)壁紙尺寸 9:16。 ) cities [ {city: 上海, landmark: 外灘建筑群}, {city: 東京, landmark: 澀谷十字路口}, {city: 巴黎, landmark: 埃菲爾鐵塔}, # ... 更多 ]每個(gè)城市只替換{city}和{landmark}兩個(gè)變量其余所有描述詞固定不變。這樣一來(lái)不同圖片之間天然具備了風(fēng)格一致性你后續(xù)篩選也只需要關(guān)注主題差異不用費(fèi)勁比對(duì)風(fēng)格漂移。模板化還有一個(gè)隱藏的好處方便批量修改。如果客戶看完前 5 張說(shuō)“色調(diào)太深了要明亮一點(diǎn)”你只需要改模板里關(guān)于色調(diào)的描述然后重新生成全量耗時(shí)和成本都可控。這才是批量的工程化價(jià)值。4.2 負(fù)面提示詞與風(fēng)格錨點(diǎn)DALL·E 沒(méi)有專門的負(fù)面提示詞參數(shù)但 Gemini 的部分接口支持system_instruction那里可以做風(fēng)格約束。更通用的做法是把“不要什么”直接寫(xiě)進(jìn)提示詞里。我自己常用的表述方式“不要文字、不要水印、不要邊框”“不要歪斜的建筑透視”“不要過(guò)度銳化”“保持自然光影不要 HDR 效果”寫(xiě)提示詞時(shí)建議把“風(fēng)格錨點(diǎn)”放在開(kāi)頭把“負(fù)面約束”放在中段把“技術(shù)參數(shù)”尺寸、構(gòu)圖、光線放在末尾。順序?qū)ι山Y(jié)果有影響模型通常更關(guān)注靠前的描述。說(shuō)到風(fēng)格錨點(diǎn)我強(qiáng)烈推薦給批量任務(wù)建一個(gè)“風(fēng)格詞匯表”風(fēng)格方向推薦錨點(diǎn)詞匯寫(xiě)實(shí)攝影85mm 鏡頭、f/1.8 光圈、自然膚色、淺景深賽博朋克霓虹燈、雨夜、全息投影、高對(duì)比、冷色調(diào)青色與洋紅國(guó)風(fēng)插畫(huà)水墨質(zhì)感、留白、淡彩、輪廓線柔和卡通 3D皮克斯風(fēng)格渲染、柔軟材質(zhì)、圓潤(rùn)造型、柔和全局光照極簡(jiǎn)海報(bào)大量留白、單一主色、幾何構(gòu)圖、無(wú)襯線字體的感覺(jué)一旦確定風(fēng)格所有提示詞統(tǒng)一掛上錨點(diǎn)詞匯不要每次憑感覺(jué)增刪。4.3 批量場(chǎng)景下的提示詞版本管理這個(gè)細(xì)節(jié)很多人會(huì)忽略但實(shí)際上是批量項(xiàng)目中最大的隱性成本之一提示詞改動(dòng)了批量結(jié)果的一致性立刻被打破。你昨天用模板 A 跑出 100 張今天覺(jué)得某個(gè)形容詞不夠好隨手改成模板 B 又跑了 100 張這兩批圖混在一起就會(huì)出現(xiàn)明顯的風(fēng)格斷層。解決思路其實(shí)很簡(jiǎn)單給提示詞模板加上版本號(hào)PROMPT_TEMPLATES { v1: ( 一幅城市夜景插畫(huà)主題是{city}的{landmark} 畫(huà)面以深藍(lán)色和金色為主色調(diào)... ), v2: ( 一幅城市夜景插畫(huà)主題是{city}的{landmark} 畫(huà)面以深藍(lán)色和金色為主色調(diào)增加了月光反射效果... ), }然后在任務(wù)清單里記錄用的模板版本{task_id: t001, prompt_version: v2, prompt: ...}以后你看到任何一張圖都能追溯到它是由哪個(gè)版本的提示詞生成的。如果某個(gè)版本的結(jié)果整批被棄用你也知道應(yīng)該重建哪些任務(wù)。這本質(zhì)上就是數(shù)據(jù)管理思維圖像生成項(xiàng)目跑到后期瓶頸往往不在“模型能力”而在“管理和追溯能力”。5. 從腳本到流水線任務(wù)隊(duì)列、斷點(diǎn)續(xù)跑與產(chǎn)物管理5.1 任務(wù)清單與狀態(tài)管理批量腳本跑一次容易但真實(shí)生產(chǎn)里你會(huì)遇到無(wú)數(shù)需要斷點(diǎn)續(xù)跑的場(chǎng)景跑到一半 API 掛了、磁盤滿了、提示詞需要調(diào)整、某幾張圖超時(shí)。如果腳本設(shè)計(jì)成“從頭跑”前面的產(chǎn)出全廢時(shí)間和成本雙重浪費(fèi)。正確的做法是引入任務(wù)狀態(tài)機(jī)。每個(gè)任務(wù)有四個(gè)狀態(tài)待處理、處理中、成功、失敗。狀態(tài)記錄在 JSONL 或 SQLite 里腳本每次啟動(dòng)時(shí)讀取狀態(tài)文件跳過(guò)已成功的任務(wù)只處理待處理和失敗的任務(wù)。import json from pathlib import Path STATE_FILE Path(tasks_state.json) def load_state(): if STATE_FILE.exists(): with open(STATE_FILE, r, encodingutf-8) as f: return {t[task_id]: t for t in map(json.loads, f)} return {} def save_result(task, status, errorNone): with open(STATE_FILE, a, encodingutf-8) as f: f.write(json.dumps({**task, status: status, error: error}, ensure_asciiFalse) \n)實(shí)際可以做得更輕不需要每次成功都寫(xiě)文件可以攢 5~10 條批量 flush 一次減少磁盤 IO。但狀態(tài)文件一定要有否則重跑全量任務(wù)的時(shí)間損失不是線性增長(zhǎng)而是結(jié)合限速的指數(shù)級(jí)增長(zhǎng)。5.2 結(jié)果落盤與文件命名規(guī)范產(chǎn)物管理是另一個(gè)容易被忽視的點(diǎn)。批量生成的圖片如果沒(méi)有規(guī)范的命名幾天后你打開(kāi)文件夾看到的是一堆 hash 文件名完全對(duì)不上任務(wù)。我建議的文件命名規(guī)則{series_name}/{task_id}_{version}_{style_tag}_{timestamp}.png例如city_night_series/t001_v2_shanghai_bund_20250114.png這個(gè)命名包含了系列名、任務(wù) ID、提示詞版本、主題標(biāo)識(shí)和時(shí)間戳。配合狀態(tài)文件里的完整提示詞你可以在任何時(shí)候從圖片反推生成信息。另外圖片本身建議同時(shí)保留原始 base64 和 final PNG 兩個(gè)版本。base64 可以存到狀態(tài)文件里做備份溯源PNG 用于實(shí)際展示和使用。兩個(gè)都留一份不大但恢復(fù)成本完全不同。5.3 失敗任務(wù)的恢復(fù)與重新生成失敗任務(wù)怎么處理我的策略是先嘗試自動(dòng)重試重試耗盡后把任務(wù)標(biāo)記為失敗跑完一批后統(tǒng)一人工檢查失敗原因。常見(jiàn)的失敗原因失敗錯(cuò)誤常見(jiàn)原因處理方式429 限流并發(fā)過(guò)大或配額不足增加退避時(shí)間或降低并發(fā)重試400 無(wú)效請(qǐng)求提示詞包含敏感詞或非法字符修改提示詞后人工重跑執(zhí)行超時(shí)網(wǎng)絡(luò)波動(dòng)或服務(wù)端異常單獨(dú)挑出重試圖片內(nèi)容被拒觸發(fā)內(nèi)容審核修改提示詞重新生成密鑰配額耗盡本月用量超限換密鑰或等額度恢復(fù)這里要特別提醒內(nèi)容審核攔截是批量項(xiàng)目里最容易被低估的失敗因素。某些提示詞單看沒(méi)問(wèn)題但批量跑幾天后就會(huì)撞上審核系統(tǒng)的高敏感模式。這時(shí)候別硬懟換個(gè)措辭就能解決。比如“穿著性感”改成“穿著時(shí)尚”“身材曲線”改成“姿態(tài)優(yōu)雅”表述安全也能讓生成更穩(wěn)定?；謴?fù)操作建議寫(xiě)成獨(dú)立函數(shù)def recover_failed_tasks(state_file): failed_tasks [] for record in load_state(): if record[status] failed: failed_tasks.append(record) # 重新跑失敗的 run_batch(failed_tasks)這樣你隨時(shí)可以在不觸碰成功任務(wù)的前提下只補(bǔ)跑失敗的那幾條。對(duì)于批量流水線這種“精確懲戒粒度”很重要。整批重跑是最后的選項(xiàng)而不是默認(rèn)選項(xiàng)。6. 實(shí)測(cè)數(shù)據(jù)與踩坑總結(jié)6.1 一次批量生產(chǎn)的實(shí)測(cè)數(shù)據(jù)拿一個(gè)實(shí)際模擬項(xiàng)目舉例生成 120 張不同城市夜景插畫(huà)DALL·E 31024x1024 標(biāo)準(zhǔn)質(zhì)量并發(fā) 5單價(jià)約 0.04 美元一張。實(shí)測(cè)數(shù)據(jù)大概是這樣的指標(biāo)數(shù)值總耗時(shí)約 34 分鐘成功116 張失敗4 張失敗原因3 張觸發(fā)內(nèi)容審核1 張超時(shí)總費(fèi)用約 4.8 美元平均單張耗時(shí)約 17 秒429 觸發(fā)次數(shù)2 次均已自動(dòng)恢復(fù)失敗率 3.3%在可接受范圍內(nèi)。但如果失敗率超過(guò) 10%說(shuō)明提示詞模板或參數(shù)配置有問(wèn)題不建議直接加并發(fā)硬跑先停下來(lái)分析失敗模式。盲目增加重試次數(shù)和并發(fā)數(shù)只會(huì)讓成本更快消耗。另外我注意到一個(gè)規(guī)律內(nèi)容審核失敗往往集中在某些特定主題上。比如涉及“夜景人像”的任務(wù)失敗率遠(yuǎn)高于“純建筑夜景”。如果項(xiàng)目允許盡量在模板里避開(kāi)高危主題組合。6.2 我踩過(guò)的幾個(gè)坑和解決方案第一個(gè)坑直接使用默認(rèn) network 超時(shí)。OpenAI SDK 的默認(rèn)超時(shí)配置在很多網(wǎng)絡(luò)環(huán)境下不夠用批量任務(wù)里單張請(qǐng)求耗時(shí)超過(guò) 30 秒并不罕見(jiàn)。建議手動(dòng)設(shè)置 timeout否則會(huì)出現(xiàn)客戶端超時(shí)但服務(wù)端還在處理的狀況任務(wù)被標(biāo)記失敗但實(shí)際已經(jīng)生成重試會(huì)造成重復(fù)扣費(fèi)。from openai import OpenAI client OpenAI( api_keyos.getenv(OPENAI_API_KEY), timeout60.0, # 給足時(shí)間不要用默認(rèn)值 )第二個(gè)坑把 URL 下載和生成混在同一個(gè)事務(wù)里。用 URL 模式時(shí)生成成功并不代表下載成功。穩(wěn)妥的做法是生成時(shí)直接用b64_json把下載環(huán)節(jié)徹底省掉。第三個(gè)坑任務(wù)清單里的提示詞沒(méi)有做長(zhǎng)度校驗(yàn)。某些模型對(duì)提示詞長(zhǎng)度有限制超長(zhǎng)提示詞會(huì)在中間被截?cái)鄬?dǎo)致生成結(jié)果偏離預(yù)期。批量腳本里統(tǒng)一加一個(gè)截?cái)嗷蝾A(yù)檢邏輯長(zhǎng)度超限直接報(bào)錯(cuò)避免稀里糊涂跑幾百?gòu)垙U圖。第四個(gè)坑也是最容易忽略的本地磁盤空間。1000 張 1024x1024 的 PNG 大約占用 1.5~2GB如果還保留 JSONL 狀態(tài)文件內(nèi)存和磁盤都要提前規(guī)劃。跑之前檢查一次磁盤剩余空間不費(fèi)什么事但能避免跑到一半磁盤寫(xiě)滿的尷尬。6.3 成本優(yōu)化與質(zhì)量抽檢建議最后說(shuō)說(shuō)成本和質(zhì)量管理。批量場(chǎng)景下成本控制和質(zhì)量保障是兩條線成本控制方面最有效的策略是“先小批量驗(yàn)證再全量鋪開(kāi)”。先拿 5~10 條典型任務(wù)跑一遍人工看結(jié)果質(zhì)量確認(rèn)提示詞沒(méi)問(wèn)題后再放全量。這個(gè)策略下哪怕是全量失敗浪費(fèi)的也只有 10 張圖的錢。另外可以監(jiān)控每次運(yùn)行的總費(fèi)用設(shè)置一個(gè)月度預(yù)算閾值腳本跑之前先判斷預(yù)算是否足夠。質(zhì)量抽檢方面我建議每一批任務(wù)產(chǎn)出后至少隨機(jī)抽 10% 的圖片做人工檢查。檢查維度包括是否與提示詞匹配、風(fēng)格是否一致、有沒(méi)有明顯畸變或瑕疵。抽檢結(jié)果如果合格率低于 80%不要繼續(xù)跑下一批先回頭調(diào)提示詞。關(guān)于成本還有一個(gè)容易被忽略的點(diǎn)模型版本升級(jí)后的價(jià)格差異。同一家服務(wù)商的不同模型版本可能有不同價(jià)格代碼里硬編碼的版本號(hào)會(huì)在不知情的情況下悄悄增加成本。建議在配置中心統(tǒng)一管理模型版本每次升級(jí)先跑小批量對(duì)比效果和成本。至于 DALL·E 和 Gemini 的日常分工我的實(shí)測(cè)體會(huì)是DALL·E 更適合“描述復(fù)雜、需要精確還原”的任務(wù)Gemini 更適合“風(fēng)格感強(qiáng)、需要氛圍渲染”的插畫(huà)類任務(wù)。如果一個(gè)項(xiàng)目?jī)烧叨忌婕敖ㄗh分成兩條流水線分支各跑各的而不是在同一個(gè)循環(huán)里無(wú)縫切換。理由很簡(jiǎn)單兩者的限速、錯(cuò)誤類型、出圖風(fēng)格差異都不同混在一個(gè)循環(huán)里會(huì)讓問(wèn)題定位變得非常困難。最后想補(bǔ)充一點(diǎn)私人體會(huì)批量生圖這類項(xiàng)目技術(shù)層面其實(shí)沒(méi)有什么神秘的API 調(diào)用、并發(fā)、重試都是常規(guī)工程手段。真正拉開(kāi)差距的是對(duì)任務(wù)的管理方式——你有沒(méi)有能力在 500 張圖里快速定位到那一張異常圖能不能在三天后準(zhǔn)確復(fù)現(xiàn)某批圖的生成條件這些數(shù)據(jù)管理和工程化的細(xì)節(jié)往往比模型本身的選型更決定項(xiàng)目成敗。我自己在跑過(guò)幾個(gè)批量項(xiàng)目后的經(jīng)驗(yàn)是把前面說(shuō)的任務(wù)狀態(tài)機(jī)、提示詞版本、產(chǎn)物命名規(guī)范都搭好之后生成圖片本身的代碼幾乎不用改項(xiàng)目推進(jìn)的速度主要取決于你篩圖、改詞、復(fù)跑的反饋循環(huán)夠不夠快。這套基礎(chǔ)設(shè)施值得在你第一次跑批量前就搭好否則越到后面越難補(bǔ)。 DALL·E與Gemini批量生圖實(shí)戰(zhàn)：API調(diào)用、并發(fā)限速與質(zhì)量管控
1. 先想清楚再動(dòng)手DALL·E 與 Gemini 的生圖定位差異1.1 兩者的接口形態(tài)與生成風(fēng)格差異做批量生圖之前最容易被忽略的一件事就是DALL·E 和 Gemini 根本不是同一類東西。雖然它們都叫“文生圖模型”但接口形態(tài)、返回方式、適用場(chǎng)景差別很大。DALL·E 走的是 OpenAI 的 Images API核心就是images.generate這一組接口。你傳入提示詞、指定尺寸和數(shù)量它同步返回一張或一組圖片的 URL 或者 base64 數(shù)據(jù)。生成質(zhì)量穩(wěn)定、語(yǔ)義理解細(xì)膩尤其擅長(zhǎng)把長(zhǎng)句子里的多個(gè)約束條件拆解到畫(huà)面里。比如“一只穿紅色雨衣的柴犬站在東京街頭身后是霓虹燈招牌雨滴清晰可見(jiàn)”這種多層描述DALL·E 基本都能還原到位。它的短板也很明顯單次請(qǐng)求最多生成 10 張SDK 頻率限制嚴(yán)格量一大就得考慮排隊(duì)和退避。Gemini 這邊則更像是多模態(tài)大模型的“附帶技能”。你調(diào)用的是 Gemini API 里的generateContent接口把提示詞放進(jìn)contents里同時(shí)指定responseModalities: [Image]模型會(huì)返回生成圖像的內(nèi)聯(lián) base64 數(shù)據(jù)。它的優(yōu)勢(shì)在于如果你本來(lái)就在用 Gemini 做文本生成、圖片理解、甚至視頻理解再順手接入生圖能力整個(gè)架構(gòu)可以共用一套鑒權(quán)和調(diào)用鏈路不用為生圖單獨(dú)維護(hù)一套 SDK。Gemini 的圖在寫(xiě)實(shí)風(fēng)格和光影質(zhì)感上有自己的特色某些場(chǎng)景下甚至比 DALL·E 更細(xì)膩但在復(fù)雜指令的還原度上沒(méi)有 DALL·E 那么“較真”。我自己的感受是如果項(xiàng)目核心就是“把一段描述變成高質(zhì)量圖片”選 DALL·E 更省心如果項(xiàng)目本身是多模態(tài)應(yīng)用比如圖文問(wèn)答、內(nèi)容審核、配圖生成一體化的內(nèi)部工具那用 Gemini 可以把系統(tǒng)復(fù)雜度壓得更低。1.2 選型矩陣什么時(shí)候用 DALL·E什么時(shí)候用 Gemini先給一個(gè)可以直接抄作業(yè)的判斷表場(chǎng)景推薦選擇理由電商商品圖、營(yíng)銷海報(bào)對(duì)畫(huà)面還原度要求極高DALL·E復(fù)雜的商品描述還原更準(zhǔn)出圖穩(wěn)定大量不同風(fēng)格插畫(huà)、虛擬形象Gemini光影質(zhì)感好批次之間風(fēng)格一致性比較容易控制多模態(tài)應(yīng)用中的配圖模塊Gemini與文本生成共用一套 API鏈路簡(jiǎn)單高并發(fā)、大批量日均千張以上DALL·E 排隊(duì)機(jī)制官方限速雖有但退避機(jī)制成熟文檔齊全成本敏感的小團(tuán)隊(duì)Gemini 免費(fèi)額度 低檔位免費(fèi)額度初期夠用試錯(cuò)成本低需要嚴(yán)格按固定比例出圖如 1:1 頭像、9:16 封面兩者均可需實(shí)測(cè)不同尺寸支持能力不同實(shí)測(cè)為準(zhǔn)選擇的關(guān)鍵不是“哪個(gè)模型更強(qiáng)”而是“你的工程鏈路到底愿不愿意為某個(gè)模型做專門適配”。DALL·E 的優(yōu)勢(shì)是生態(tài)成熟Python SDK 里就能完成幾乎所有事Gemini 的優(yōu)勢(shì)是統(tǒng)一如果你已有的項(xiàng)目里 Google 系服務(wù)占了很大比重硬塞一套 OpenAI SDK 反而顯得臃腫。另外一個(gè)很實(shí)際的考量賬號(hào)和網(wǎng)絡(luò)的可得性。這一點(diǎn)我不想展開(kāi)說(shuō)太多但提醒大家在實(shí)際部署前先確認(rèn)好當(dāng)前網(wǎng)絡(luò)環(huán)境下哪個(gè)服務(wù)能夠穩(wěn)定訪問(wèn)、鑒權(quán)暢通。這直接決定了后續(xù)調(diào)試的效率。我見(jiàn)過(guò)不少團(tuán)隊(duì)在架構(gòu)上選了很理想的方案結(jié)果每次跑批處理都要先折騰十分鐘環(huán)境最終被迫換方案。2. 環(huán)境準(zhǔn)備與第一張圖把步驟落實(shí)到能跑通2.1 API 密鑰管理與環(huán)境變量無(wú)論選哪個(gè)模型第一步都是密鑰管理。別把密鑰寫(xiě)死在代碼里哪怕項(xiàng)目不公開(kāi)也盡量不要因?yàn)槟阌肋h(yuǎn)不知道代碼什么時(shí)候會(huì)被分享出去。正確做法是放到環(huán)境變量或者項(xiàng)目根目錄的.env文件里并且保證.env不進(jìn) git。# .env OPENAI_API_KEYsk-xxxxxxxxxxxxxxxx GOOGLE_API_KEYAIzaxxxxxxxxxxxxxxxxPython 端用python-dotenv加載import os from dotenv import load_dotenv load_dotenv() openai_key os.getenv(OPENAI_API_KEY) google_key os.getenv(GOOGLE_API_KEY) if not openai_key and not google_key: raise RuntimeError(至少配置一個(gè) API Key)這里有個(gè)經(jīng)驗(yàn)之談兩個(gè)密鑰都配上代碼里做多后端支持。原因不是“兩個(gè)模型都要用”而是開(kāi)發(fā)階段某個(gè)服務(wù)萬(wàn)一出現(xiàn)臨時(shí)不可用你可以一鍵切到另一個(gè)不至于整個(gè)進(jìn)度卡死。后面要講的完整流水線本身就應(yīng)該設(shè)計(jì)成“生成后端可配置”而不是硬編碼死一個(gè)模型。2.2 單張生成的最小可運(yùn)行代碼DALL·E 的最小可運(yùn)行代碼是這么寫(xiě)的import os from openai import OpenAI client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) resp client.images.generate( modeldall-e-3, prompt一只穿紅色雨衣的柴犬站在東京街頭霓虹燈倒映在濕潤(rùn)的路面上寫(xiě)實(shí)攝影風(fēng)格, size1024x1024, qualityhd, n1, ) image_url resp.data[0].url print(image_url)Gemini 這邊略有不同import os import google.generativeai as genai genai.configure(api_keyos.getenv(GOOGLE_API_KEY)) model genai.GenerativeModel(gemini-2.0-flash-exp) resp model.generate_content( 一只穿紅色雨衣的柴犬站在東京街頭霓虹燈倒映在濕潤(rùn)的路面上寫(xiě)實(shí)攝影風(fēng)格, generation_config{response_modalities: [Image]}, ) # 返回的是內(nèi)聯(lián) base64 image_data resp.candidates[0].content.parts[0].inline_data.data with open(sample.png, wb) as f: f.write(image_data)注意 Gemini 的輸出是 base64需要自己寫(xiě)文件DALL·E 默認(rèn)返回 URL你也可以設(shè)置response_formatb64_json讓它直接返回 base64避免 URL 過(guò)期問(wèn)題。兩條鏈路拿到手之后建議先把這兩份代碼跑通再考慮批量化?；A(chǔ)不牢的批處理腳本后面出bug你都分不清是模型問(wèn)題還是代碼問(wèn)題。2.3 參數(shù)詳解size、quality、n 與 response_format批量場(chǎng)景下參數(shù)選擇決定了你的單位成本和質(zhì)量值得花點(diǎn)時(shí)間理解。size參數(shù)直接影響計(jì)費(fèi)。DALL·E 3 的 1024x1024、1024x1792、1792x1024 三個(gè)檔位價(jià)格不同寬幅圖相對(duì)貴一些。Gemini 這邊也有尺寸限制不同模型對(duì)輸出分辨率有上限。我的建議是按最終用途選尺寸不要一律選最大。如果只是做內(nèi)容配圖web端展示1024x1024 足夠了如果是做印刷物料或視頻封面再看是否需要上高分版本。quality參數(shù)是 DALL·E 特有的。標(biāo)準(zhǔn)檔生成速度快、成本低高清檔細(xì)節(jié)更好但也更慢。實(shí)戰(zhàn)里我發(fā)現(xiàn)如果是批量生成后還要人為篩選建議先用標(biāo)準(zhǔn)檔跑全量篩出值得精修的圖再用高清檔重生成。這樣能用最低成本覆蓋最大樣本量。當(dāng)然這個(gè)策略不適用于“必須一步到位”的生產(chǎn)場(chǎng)景。n參數(shù)在 DALL·E 3 里最多10張Gemini 沒(méi)有 n 參數(shù)但你可以通過(guò)并發(fā)多個(gè)請(qǐng)求來(lái)達(dá)到類似效果。說(shuō)實(shí)話我一般不用n1的批量模式因?yàn)樗趩未握?qǐng)求里一次性消耗多個(gè)配額一旦某張圖出問(wèn)題整個(gè)請(qǐng)求就要重來(lái)。相比之下用并發(fā)控制一個(gè)個(gè)生成單張失敗只需要重試那一張錯(cuò)誤隔離性更好。response_format建議直接設(shè)成b64_json。URL 看起來(lái)方便但拿去做流水線必須下載等于多一次 HTTP 往返還可能出現(xiàn) URL 過(guò)期。base64 直接入庫(kù)或?qū)懕P一步到位。當(dāng)然要注意 base64 比二進(jìn)制膨脹約 33%傳參和寫(xiě)文件時(shí)稍微注意一下內(nèi)存占用就行。兩個(gè)模型都跑通、參數(shù)都理清楚之后你的“單張”能力就緒了。這時(shí)候再回頭看批量需求思路會(huì)清晰很多批量不是把單張代碼包個(gè) for 循環(huán)那么簡(jiǎn)單它還涉及限速、錯(cuò)誤處理、斷點(diǎn)續(xù)跑這些工程問(wèn)題。3. 批量化路上真正難啃的骨頭限速、并發(fā)與重試3.1 速率限制的真實(shí)形態(tài)與應(yīng)對(duì)策略很多人第一次跑批量腳本都栽在同一個(gè)地方前 20 張生成得好好的第 21 張突然報(bào) 429。原因很簡(jiǎn)單你觸發(fā)了服務(wù)端的速率限制。這里的限制通常有兩個(gè)維度每分鐘請(qǐng)求數(shù)RPM和每分鐘圖片數(shù)IPM。DALL·E 的 RPM 限制在不同賬號(hào)等級(jí)下差異很大免費(fèi)檔和付費(fèi)檔差距可以到數(shù)倍。你可以在服務(wù)端文檔里查到具體數(shù)值但更好的做法是代碼里不寫(xiě)死限速參數(shù)而是做成可配置項(xiàng)。這樣賬號(hào)升級(jí)或者換服務(wù)商時(shí)不用改代碼邏輯。# config.py RATE_LIMIT { rpm: 60, # 每分鐘最多請(qǐng)求數(shù) ipm: 120, # 每分鐘最多生成圖片數(shù) max_retries: 6, base_delay: 2.0, }有一個(gè)非常容易踩的坑RPM 限制看著夠用但 IPM 先爆了。比如你每分鐘發(fā) 60 個(gè)請(qǐng)求每個(gè)請(qǐng)求生成 3 張圖圖片數(shù)就是 180直接超了 IPM 限制。所以批量腳本里要同時(shí)跟蹤兩個(gè)維度的消耗。我自己比較推薦的是令牌桶思路維護(hù)一個(gè)計(jì)數(shù)器每次請(qǐng)求前根據(jù)已用請(qǐng)求數(shù)和已用圖片數(shù)做雙重判斷超了任意一個(gè)就等待當(dāng)前周期結(jié)束。實(shí)現(xiàn)不復(fù)雜但能把 429 的出現(xiàn)概率大幅降低。3.2 線程池與信號(hào)量實(shí)現(xiàn)可調(diào)控的并發(fā)Python 里做并發(fā)最高效的方式是用concurrent.futures.ThreadPoolExecutor然后通過(guò)信號(hào)量控制最大并發(fā)數(shù)。import threading import time from concurrent.futures import ThreadPoolExecutor, as_completed semaphore threading.Semaphore(5) # 同一時(shí)刻最多 5 個(gè)請(qǐng)求在飛 def generate_one(task): with semaphore: # 調(diào)用 DALL·E 或 Gemini 的單張生成函數(shù) result generate_image(task[prompt], task[output_path]) return task, result with ThreadPoolExecutor(max_workers10) as executor: futures [executor.submit(generate_one, task) for task in tasks] for future in as_completed(futures): task, result future.result() print(f完成: {task[output_path]})這里有兩個(gè)細(xì)節(jié)值得注意。第一max_workers和信號(hào)量的大小是兩個(gè)概念max_workers決定線程池里最多多少線程信號(hào)量在函數(shù)內(nèi)部再做一層閘門。你可以開(kāi) 20 個(gè)線程同時(shí)只放行 5 個(gè)真實(shí)請(qǐng)求其余的排隊(duì)等待。這樣即使任務(wù)里混入了一些耗時(shí)操作比如圖片后處理也不會(huì)擠占 API 請(qǐng)求的配額。第二不要只靠線程池控制并發(fā)因?yàn)榫€程池只限制線程數(shù)不感知 API 配額。兩個(gè)腳本實(shí)例同時(shí)跑的時(shí)候線程池的限流形同虛設(shè)。把限速參數(shù)做成全局配置必要時(shí)用 Redis 或文件鎖做跨進(jìn)程限流。單機(jī)小批量可以忽略但如果你計(jì)劃定時(shí)任務(wù)多進(jìn)程跑遲早會(huì)遇到這個(gè)問(wèn)題。3.3 退避重試與可觀測(cè)性設(shè)計(jì)429 和 5xx 的錯(cuò)誤處理是批量腳本的核心。不處理重試的批量腳本本質(zhì)上是一次性賭運(yùn)氣。推薦指數(shù)退避策略第一次重試等 2 秒第二次等 4 秒第三次等 8 秒加上隨機(jī)抖動(dòng)防止所有任務(wù)同時(shí)重試導(dǎo)致又撞在一起。import random import time def generate_with_retry(task, max_retries6, base_delay2.0): for attempt in range(max_retries): try: return generate_image(task) except RateLimitError as e: delay base_delay * (2 ** attempt) random.uniform(0, 1) print(f請(qǐng)求被限流{delay:.1f}s 后重試 ({attempt1}/{max_retries})) time.sleep(delay) except APIStatusError as e: if e.status_code 500: delay base_delay * (2 ** attempt) random.uniform(0, 1) print(f服務(wù)端錯(cuò)誤 {e.status_code}{delay:.1f}s 后重試) time.sleep(delay) else: raise # 4xx 錯(cuò)誤一般不重試直接拋出去人工處理 raise RuntimeError(f任務(wù)重試 {max_retries} 次仍然失敗: {task[prompt][:50]})除了重試可觀測(cè)性同樣重要。批量任務(wù)跑起來(lái)后你需要知道跑了多少成功多少失敗多少失敗的原因分布是什么當(dāng)前處于什么階段我習(xí)慣在每個(gè)任務(wù)的處理函數(shù)里記錄狀態(tài)到 SQLite 或 JSONL 文件格式大概是{task_id: t001, prompt: xxx, status: success, cost: 0.04, duration: 3.2, error: null}跑完一批之后直接按狀態(tài)聚合成功率一目了然。這樣做的成本很低但能幫你省下大量的排障時(shí)間。批量任務(wù)最怕的不是失敗而是失敗了不知道、不知道失敗了多少、不知道失敗的原因。4. 提示詞工程讓批量生成的風(fēng)格保持穩(wěn)定4.1 模板化提示詞與變量注入批量生成和單張生成最大的區(qū)別在于你需要讓幾十上百?gòu)垐D片保持統(tǒng)一的風(fēng)格基線而不是每張圖自由發(fā)揮。做法就是模板化提示詞。假設(shè)你要做一套 30 張的“城市夜景插畫(huà)”系列提示詞模板大概是這樣的PROMPT_TEMPLATE ( 一幅城市夜景插畫(huà)主題是{city}的{landmark} 畫(huà)面以深藍(lán)色和金色為主色調(diào)筆觸細(xì)膩 氛圍寧?kù)o且?guī)в幸稽c(diǎn)科幻感適合作為豎版手機(jī)壁紙尺寸 9:16。 ) cities [ {city: 上海, landmark: 外灘建筑群}, {city: 東京, landmark: 澀谷十字路口}, {city: 巴黎, landmark: 埃菲爾鐵塔}, # ... 更多 ]每個(gè)城市只替換{city}和{landmark}兩個(gè)變量其余所有描述詞固定不變。這樣一來(lái)不同圖片之間天然具備了風(fēng)格一致性你后續(xù)篩選也只需要關(guān)注主題差異不用費(fèi)勁比對(duì)風(fēng)格漂移。模板化還有一個(gè)隱藏的好處方便批量修改。如果客戶看完前 5 張說(shuō)“色調(diào)太深了要明亮一點(diǎn)”你只需要改模板里關(guān)于色調(diào)的描述然后重新生成全量耗時(shí)和成本都可控。這才是批量的工程化價(jià)值。4.2 負(fù)面提示詞與風(fēng)格錨點(diǎn)DALL·E 沒(méi)有專門的負(fù)面提示詞參數(shù)但 Gemini 的部分接口支持system_instruction那里可以做風(fēng)格約束。更通用的做法是把“不要什么”直接寫(xiě)進(jìn)提示詞里。我自己常用的表述方式“不要文字、不要水印、不要邊框”“不要歪斜的建筑透視”“不要過(guò)度銳化”“保持自然光影不要 HDR 效果”寫(xiě)提示詞時(shí)建議把“風(fēng)格錨點(diǎn)”放在開(kāi)頭把“負(fù)面約束”放在中段把“技術(shù)參數(shù)”尺寸、構(gòu)圖、光線放在末尾。順序?qū)ι山Y(jié)果有影響模型通常更關(guān)注靠前的描述。說(shuō)到風(fēng)格錨點(diǎn)我強(qiáng)烈推薦給批量任務(wù)建一個(gè)“風(fēng)格詞匯表”風(fēng)格方向推薦錨點(diǎn)詞匯寫(xiě)實(shí)攝影85mm 鏡頭、f/1.8 光圈、自然膚色、淺景深賽博朋克霓虹燈、雨夜、全息投影、高對(duì)比、冷色調(diào)青色與洋紅國(guó)風(fēng)插畫(huà)水墨質(zhì)感、留白、淡彩、輪廓線柔和卡通 3D皮克斯風(fēng)格渲染、柔軟材質(zhì)、圓潤(rùn)造型、柔和全局光照極簡(jiǎn)海報(bào)大量留白、單一主色、幾何構(gòu)圖、無(wú)襯線字體的感覺(jué)一旦確定風(fēng)格所有提示詞統(tǒng)一掛上錨點(diǎn)詞匯不要每次憑感覺(jué)增刪。4.3 批量場(chǎng)景下的提示詞版本管理這個(gè)細(xì)節(jié)很多人會(huì)忽略但實(shí)際上是批量項(xiàng)目中最大的隱性成本之一提示詞改動(dòng)了批量結(jié)果的一致性立刻被打破。你昨天用模板 A 跑出 100 張今天覺(jué)得某個(gè)形容詞不夠好隨手改成模板 B 又跑了 100 張這兩批圖混在一起就會(huì)出現(xiàn)明顯的風(fēng)格斷層。解決思路其實(shí)很簡(jiǎn)單給提示詞模板加上版本號(hào)PROMPT_TEMPLATES { v1: ( 一幅城市夜景插畫(huà)主題是{city}的{landmark} 畫(huà)面以深藍(lán)色和金色為主色調(diào)... ), v2: ( 一幅城市夜景插畫(huà)主題是{city}的{landmark} 畫(huà)面以深藍(lán)色和金色為主色調(diào)增加了月光反射效果... ), }然后在任務(wù)清單里記錄用的模板版本{task_id: t001, prompt_version: v2, prompt: ...}以后你看到任何一張圖都能追溯到它是由哪個(gè)版本的提示詞生成的。如果某個(gè)版本的結(jié)果整批被棄用你也知道應(yīng)該重建哪些任務(wù)。這本質(zhì)上就是數(shù)據(jù)管理思維圖像生成項(xiàng)目跑到后期瓶頸往往不在“模型能力”而在“管理和追溯能力”。5. 從腳本到流水線任務(wù)隊(duì)列、斷點(diǎn)續(xù)跑與產(chǎn)物管理5.1 任務(wù)清單與狀態(tài)管理批量腳本跑一次容易但真實(shí)生產(chǎn)里你會(huì)遇到無(wú)數(shù)需要斷點(diǎn)續(xù)跑的場(chǎng)景跑到一半 API 掛了、磁盤滿了、提示詞需要調(diào)整、某幾張圖超時(shí)。如果腳本設(shè)計(jì)成“從頭跑”前面的產(chǎn)出全廢時(shí)間和成本雙重浪費(fèi)。正確的做法是引入任務(wù)狀態(tài)機(jī)。每個(gè)任務(wù)有四個(gè)狀態(tài)待處理、處理中、成功、失敗。狀態(tài)記錄在 JSONL 或 SQLite 里腳本每次啟動(dòng)時(shí)讀取狀態(tài)文件跳過(guò)已成功的任務(wù)只處理待處理和失敗的任務(wù)。import json from pathlib import Path STATE_FILE Path(tasks_state.json) def load_state(): if STATE_FILE.exists(): with open(STATE_FILE, r, encodingutf-8) as f: return {t[task_id]: t for t in map(json.loads, f)} return {} def save_result(task, status, errorNone): with open(STATE_FILE, a, encodingutf-8) as f: f.write(json.dumps({**task, status: status, error: error}, ensure_asciiFalse) \n)實(shí)際可以做得更輕不需要每次成功都寫(xiě)文件可以攢 5~10 條批量 flush 一次減少磁盤 IO。但狀態(tài)文件一定要有否則重跑全量任務(wù)的時(shí)間損失不是線性增長(zhǎng)而是結(jié)合限速的指數(shù)級(jí)增長(zhǎng)。5.2 結(jié)果落盤與文件命名規(guī)范產(chǎn)物管理是另一個(gè)容易被忽視的點(diǎn)。批量生成的圖片如果沒(méi)有規(guī)范的命名幾天后你打開(kāi)文件夾看到的是一堆 hash 文件名完全對(duì)不上任務(wù)。我建議的文件命名規(guī)則{series_name}/{task_id}_{version}_{style_tag}_{timestamp}.png例如city_night_series/t001_v2_shanghai_bund_20250114.png這個(gè)命名包含了系列名、任務(wù) ID、提示詞版本、主題標(biāo)識(shí)和時(shí)間戳。配合狀態(tài)文件里的完整提示詞你可以在任何時(shí)候從圖片反推生成信息。另外圖片本身建議同時(shí)保留原始 base64 和 final PNG 兩個(gè)版本。base64 可以存到狀態(tài)文件里做備份溯源PNG 用于實(shí)際展示和使用。兩個(gè)都留一份不大但恢復(fù)成本完全不同。5.3 失敗任務(wù)的恢復(fù)與重新生成失敗任務(wù)怎么處理我的策略是先嘗試自動(dòng)重試重試耗盡后把任務(wù)標(biāo)記為失敗跑完一批后統(tǒng)一人工檢查失敗原因。常見(jiàn)的失敗原因失敗錯(cuò)誤常見(jiàn)原因處理方式429 限流并發(fā)過(guò)大或配額不足增加退避時(shí)間或降低并發(fā)重試400 無(wú)效請(qǐng)求提示詞包含敏感詞或非法字符修改提示詞后人工重跑執(zhí)行超時(shí)網(wǎng)絡(luò)波動(dòng)或服務(wù)端異常單獨(dú)挑出重試圖片內(nèi)容被拒觸發(fā)內(nèi)容審核修改提示詞重新生成密鑰配額耗盡本月用量超限換密鑰或等額度恢復(fù)這里要特別提醒內(nèi)容審核攔截是批量項(xiàng)目里最容易被低估的失敗因素。某些提示詞單看沒(méi)問(wèn)題但批量跑幾天后就會(huì)撞上審核系統(tǒng)的高敏感模式。這時(shí)候別硬懟換個(gè)措辭就能解決。比如“穿著性感”改成“穿著時(shí)尚”“身材曲線”改成“姿態(tài)優(yōu)雅”表述安全也能讓生成更穩(wěn)定?；謴?fù)操作建議寫(xiě)成獨(dú)立函數(shù)def recover_failed_tasks(state_file): failed_tasks [] for record in load_state(): if record[status] failed: failed_tasks.append(record) # 重新跑失敗的 run_batch(failed_tasks)這樣你隨時(shí)可以在不觸碰成功任務(wù)的前提下只補(bǔ)跑失敗的那幾條。對(duì)于批量流水線這種“精確懲戒粒度”很重要。整批重跑是最后的選項(xiàng)而不是默認(rèn)選項(xiàng)。6. 實(shí)測(cè)數(shù)據(jù)與踩坑總結(jié)6.1 一次批量生產(chǎn)的實(shí)測(cè)數(shù)據(jù)拿一個(gè)實(shí)際模擬項(xiàng)目舉例生成 120 張不同城市夜景插畫(huà)DALL·E 31024x1024 標(biāo)準(zhǔn)質(zhì)量并發(fā) 5單價(jià)約 0.04 美元一張。實(shí)測(cè)數(shù)據(jù)大概是這樣的指標(biāo)數(shù)值總耗時(shí)約 34 分鐘成功116 張失敗4 張失敗原因3 張觸發(fā)內(nèi)容審核1 張超時(shí)總費(fèi)用約 4.8 美元平均單張耗時(shí)約 17 秒429 觸發(fā)次數(shù)2 次均已自動(dòng)恢復(fù)失敗率 3.3%在可接受范圍內(nèi)。但如果失敗率超過(guò) 10%說(shuō)明提示詞模板或參數(shù)配置有問(wèn)題不建議直接加并發(fā)硬跑先停下來(lái)分析失敗模式。盲目增加重試次數(shù)和并發(fā)數(shù)只會(huì)讓成本更快消耗。另外我注意到一個(gè)規(guī)律內(nèi)容審核失敗往往集中在某些特定主題上。比如涉及“夜景人像”的任務(wù)失敗率遠(yuǎn)高于“純建筑夜景”。如果項(xiàng)目允許盡量在模板里避開(kāi)高危主題組合。6.2 我踩過(guò)的幾個(gè)坑和解決方案第一個(gè)坑直接使用默認(rèn) network 超時(shí)。OpenAI SDK 的默認(rèn)超時(shí)配置在很多網(wǎng)絡(luò)環(huán)境下不夠用批量任務(wù)里單張請(qǐng)求耗時(shí)超過(guò) 30 秒并不罕見(jiàn)。建議手動(dòng)設(shè)置 timeout否則會(huì)出現(xiàn)客戶端超時(shí)但服務(wù)端還在處理的狀況任務(wù)被標(biāo)記失敗但實(shí)際已經(jīng)生成重試會(huì)造成重復(fù)扣費(fèi)。from openai import OpenAI client OpenAI( api_keyos.getenv(OPENAI_API_KEY), timeout60.0, # 給足時(shí)間不要用默認(rèn)值 )第二個(gè)坑把 URL 下載和生成混在同一個(gè)事務(wù)里。用 URL 模式時(shí)生成成功并不代表下載成功。穩(wěn)妥的做法是生成時(shí)直接用b64_json把下載環(huán)節(jié)徹底省掉。第三個(gè)坑任務(wù)清單里的提示詞沒(méi)有做長(zhǎng)度校驗(yàn)。某些模型對(duì)提示詞長(zhǎng)度有限制超長(zhǎng)提示詞會(huì)在中間被截?cái)鄬?dǎo)致生成結(jié)果偏離預(yù)期。批量腳本里統(tǒng)一加一個(gè)截?cái)嗷蝾A(yù)檢邏輯長(zhǎng)度超限直接報(bào)錯(cuò)避免稀里糊涂跑幾百?gòu)垙U圖。第四個(gè)坑也是最容易忽略的本地磁盤空間。1000 張 1024x1024 的 PNG 大約占用 1.5~2GB如果還保留 JSONL 狀態(tài)文件內(nèi)存和磁盤都要提前規(guī)劃。跑之前檢查一次磁盤剩余空間不費(fèi)什么事但能避免跑到一半磁盤寫(xiě)滿的尷尬。6.3 成本優(yōu)化與質(zhì)量抽檢建議最后說(shuō)說(shuō)成本和質(zhì)量管理。批量場(chǎng)景下成本控制和質(zhì)量保障是兩條線成本控制方面最有效的策略是“先小批量驗(yàn)證再全量鋪開(kāi)”。先拿 5~10 條典型任務(wù)跑一遍人工看結(jié)果質(zhì)量確認(rèn)提示詞沒(méi)問(wèn)題后再放全量。這個(gè)策略下哪怕是全量失敗浪費(fèi)的也只有 10 張圖的錢。另外可以監(jiān)控每次運(yùn)行的總費(fèi)用設(shè)置一個(gè)月度預(yù)算閾值腳本跑之前先判斷預(yù)算是否足夠。質(zhì)量抽檢方面我建議每一批任務(wù)產(chǎn)出后至少隨機(jī)抽 10% 的圖片做人工檢查。檢查維度包括是否與提示詞匹配、風(fēng)格是否一致、有沒(méi)有明顯畸變或瑕疵。抽檢結(jié)果如果合格率低于 80%不要繼續(xù)跑下一批先回頭調(diào)提示詞。關(guān)于成本還有一個(gè)容易被忽略的點(diǎn)模型版本升級(jí)后的價(jià)格差異。同一家服務(wù)商的不同模型版本可能有不同價(jià)格代碼里硬編碼的版本號(hào)會(huì)在不知情的情況下悄悄增加成本。建議在配置中心統(tǒng)一管理模型版本每次升級(jí)先跑小批量對(duì)比效果和成本。至于 DALL·E 和 Gemini 的日常分工我的實(shí)測(cè)體會(huì)是DALL·E 更適合“描述復(fù)雜、需要精確還原”的任務(wù)Gemini 更適合“風(fēng)格感強(qiáng)、需要氛圍渲染”的插畫(huà)類任務(wù)。如果一個(gè)項(xiàng)目?jī)烧叨忌婕敖ㄗh分成兩條流水線分支各跑各的而不是在同一個(gè)循環(huán)里無(wú)縫切換。理由很簡(jiǎn)單兩者的限速、錯(cuò)誤類型、出圖風(fēng)格差異都不同混在一個(gè)循環(huán)里會(huì)讓問(wèn)題定位變得非常困難。最后想補(bǔ)充一點(diǎn)私人體會(huì)批量生圖這類項(xiàng)目技術(shù)層面其實(shí)沒(méi)有什么神秘的API 調(diào)用、并發(fā)、重試都是常規(guī)工程手段。真正拉開(kāi)差距的是對(duì)任務(wù)的管理方式——你有沒(méi)有能力在 500 張圖里快速定位到那一張異常圖能不能在三天后準(zhǔn)確復(fù)現(xiàn)某批圖的生成條件這些數(shù)據(jù)管理和工程化的細(xì)節(jié)往往比模型本身的選型更決定項(xiàng)目成敗。我自己在跑過(guò)幾個(gè)批量項(xiàng)目后的經(jīng)驗(yàn)是把前面說(shuō)的任務(wù)狀態(tài)機(jī)、提示詞版本、產(chǎn)物命名規(guī)范都搭好之后生成圖片本身的代碼幾乎不用改項(xiàng)目推進(jìn)的速度主要取決于你篩圖、改詞、復(fù)跑的反饋循環(huán)夠不夠快。這套基礎(chǔ)設(shè)施值得在你第一次跑批量前就搭好否則越到后面越難補(bǔ)。