先聊個(gè)很多人可能都感同身受的事今年我把手頭一個(gè)數(shù)據(jù)處理項(xiàng)目遷到 GPT-6 ultra 上跑原本想的是“貴一點(diǎn)沒事效果好就行”結(jié)果第一次批量任務(wù)跑完看到賬單的那一刻我真的懷疑是不是計(jì)算錯(cuò)了。GPT-6 ultra 確實(shí)強(qiáng)推理深度、指令理解、長文處理都是頂級(jí)的但它真的太燒 Token 了——而且不是按“你問了幾個(gè)問題”計(jì)費(fèi)是按每次請(qǐng)求吞進(jìn)去的文本量計(jì)費(fèi)稍微不注意一次任務(wù)就能吃掉幾十萬 Token。后來我做了個(gè)決定不再把它當(dāng)全能打工人使喚而是給它配了個(gè) AI 團(tuán)隊(duì)。這里的“團(tuán)隊(duì)”不是人多而是把一個(gè)大任務(wù)拆成多個(gè)崗位讓不同類型的模型各干各的活。復(fù)雜的核心環(huán)節(jié)交給旗艦?zāi)Ｐ秃唵沃貜?fù)的環(huán)節(jié)交給輕量模型中間用一套調(diào)度邏輯串起來。這套方案跑了一段時(shí)間Token 消耗直接砍掉了六成左右任務(wù)質(zhì)量不僅沒降反而因?yàn)榉止っ鞔_了輸出更穩(wěn)定。這篇文章就把完整思路、落地步驟和踩過的坑都寫出來給同樣被 Token 賬單折磨的人一個(gè)參考。1. Token 到底是怎么被“燒”掉的先算清這筆賬1.1 一次很普通的任務(wù)為什么消耗高得嚇人我先還原一個(gè)真實(shí)場景。當(dāng)時(shí)我要對(duì) 20 篇行業(yè)報(bào)告做批量處理每篇大概 1.5 萬到 2 萬個(gè) Token任務(wù)目標(biāo)是每篇輸出 500 字以內(nèi)的摘要、提取 5 個(gè)關(guān)鍵指標(biāo)、判斷有沒有異常波動(dòng)最后匯總成一張總表。如果按直覺來寫就是一個(gè)循環(huán)把每篇全文塞給 GPT-6 ultra讓它直接輸出結(jié)果。表面上看每篇文本量不大20 篇加起來也就 30 多萬 Token。但真正跑完消耗接近 38 萬 Token。多出來的部分就是你給模型的指令、它自己的推理過程、以及模型為了“湊完整回答”而輸出的各種廢話。更要命的是如果中間某一步跑錯(cuò)了你要重新把整篇文檔再塞給它一次。也就是說同樣一份全文會(huì)因?yàn)橹卦?、修正、補(bǔ)充提問被反復(fù)計(jì)費(fèi)很多遍。批量任務(wù)里只要有一成報(bào)錯(cuò)賬單就會(huì)明顯上浮。1.2 計(jì)費(fèi)邏輯比你想的更“狠”輸入輸出都算錢很多人以為“讓 AI 回答”只算回答內(nèi)容的錢其實(shí)不是。API 計(jì)費(fèi)是雙向的你發(fā)給它的所有文本——包括系統(tǒng)提示詞、用戶問題、歷史對(duì)話、參考資料——全部按輸入 Token 計(jì)費(fèi)模型生成的所有內(nèi)容包括推理過程、最終回答、甚至“好的我來幫你分析一下”這種廢話全部按輸出 Token 計(jì)費(fèi)。所以你在 prompt 里多寫一句客套話多讓模型“請(qǐng)?jiān)敿?xì)解釋”都是在直接給賬單加錢。尤其是旗艦?zāi)Ｐ洼斎牒洼敵龅膯蝺r(jià)都很高同樣 1000 Token輕量模型可能只要旗艦?zāi)Ｐ偷囊粋€(gè)零頭。我后來養(yǎng)成了一個(gè)習(xí)慣看消耗報(bào)表不看總 Token 數(shù)而是分成“輸入 Token”和“輸出 Token”兩個(gè)指標(biāo)。你會(huì)發(fā)現(xiàn)輸入 Token 往往是大頭因?yàn)槿?、歷史、上下文全部堆在輸入側(cè)。輸出 Token 雖然單價(jià)通常更高但只要控制住模型的廢話總量是能壓下來的。1.3 長對(duì)話為什么是“隱形吞金獸”還有一個(gè)容易被忽略的點(diǎn)長對(duì)話的累計(jì)成本。你開一個(gè)會(huì)話前 10 輪對(duì)話時(shí)每輪請(qǐng)求都要攜帶前面所有輪次的內(nèi)容。到了第 50 輪時(shí)每次新請(qǐng)求前面 49 輪的內(nèi)容全部作為輸入重新計(jì)費(fèi)。這個(gè)機(jī)制就像你去打印店打一份 100 頁的合同每改一行字不是重新打印那一行而是把 100 頁全部重新打一遍。越聊到后面每一輪新問題的實(shí)際成本越高哪怕你問的問題本身只有十幾個(gè)字。這就是為什么很多人在做長文檔分析、多輪問答、代碼調(diào)試時(shí)明明感覺沒干什么Token 卻燒得飛快。上下文越長每一次交互的隱形輸入越大。理解了這個(gè)機(jī)制你就明白我為什么要拆團(tuán)隊(duì)——因?yàn)闇p少“每輪攜帶的歷史量”比單純壓縮單次輸出更有效。2. 核心思路把“單人全才”拆成“AI 團(tuán)隊(duì)”2.1 “什么活都讓旗艦?zāi)Ｐ透伞笔亲钯F的用法旗艦?zāi)Ｐ偷哪芰ξ阌怪靡傻芰?qiáng)不代表適合干所有崗位。你讓一個(gè)資深專家去整理文件夾、回復(fù)格式郵件、做數(shù)據(jù)轉(zhuǎn)格式他當(dāng)然做得來但成本也感人。更關(guān)鍵的是旗艦?zāi)Ｐ驮趫?zhí)行簡單任務(wù)時(shí)也會(huì)產(chǎn)生大量中間推理而這些推理內(nèi)容都是要計(jì)費(fèi)的。原來的做法是用戶丟一個(gè)復(fù)雜需求大模型從理解需求、拆解步驟、逐步推理、撰寫草稿、自我檢查到最終輸出全在同一個(gè)上下文里完成。這個(gè)過程的每一步都是 Token而且是一份完整賬單。問題不是它做得不好而是成本分配不合理——有 40% 的 Token 花在簡單環(huán)節(jié)上卻按旗艦?zāi)Ｐ偷膬r(jià)格結(jié)算。這就好比你讓團(tuán)隊(duì)里最強(qiáng)的架構(gòu)師一邊設(shè)計(jì)系統(tǒng)一邊同時(shí)負(fù)責(zé)打印文檔、回復(fù)郵件、整理會(huì)議紀(jì)要。能力是夠的但預(yù)算完全失控。正確的做法是讓合適的人干合適的活。2.2 我的“團(tuán)隊(duì)”崗位設(shè)計(jì)我把整個(gè)流程拆成五個(gè)角色調(diào)度員、拆解員、執(zhí)行員、審查員、匯總編輯。每個(gè)角色不一定是獨(dú)立模型實(shí)例更多是不同 prompt 和不同模型等級(jí)的組合。這套設(shè)計(jì)的目標(biāo)是旗艦?zāi)Ｐ椭唤槿胝嬲枰疃韧评淼牟糠?。崗位職?zé)推薦模型等級(jí)Token 占比調(diào)度員Router讀懂用戶需求判斷任務(wù)難度決定走哪條執(zhí)行鏈路輕量模型約占 5%拆解員Planner把大任務(wù)拆成小塊給出執(zhí)行清單和每步預(yù)算中等模型約占 8%執(zhí)行員Worker處理具體任務(wù)按難度分流到不同模型旗艦?zāi)Ｐ? 輕量模型混合約占 70%審查員Reviewer檢查執(zhí)行結(jié)果判斷是否合格不合格退回重做中等模型約占 12%匯總編輯Formatter把多個(gè)結(jié)果組織成最終格式生成交付物輕量模型約占 5%調(diào)度員和拆解員用了“小模型 短 prompt”因?yàn)樗鼈兊娜蝿?wù)是輸出一個(gè)簡短計(jì)劃不需要深度推理。執(zhí)行員才是旗艦?zāi)Ｐ偷闹鲬?zhàn)場而且只有難度高的子任務(wù)才會(huì)派給它簡單子任務(wù)直接走輕量模型。審查員用小模型做質(zhì)量檢查只輸出“通過/不通過 原因”不生成大段分析。最后的匯總編輯把各步驟結(jié)果拼接成最終交付物。2.3 為什么這樣拆反而更便宜成本模型對(duì)比我拿那個(gè)行業(yè)報(bào)告任務(wù)來算一筆賬。原來用旗艦?zāi)Ｐ腿鞒膛芸傁募s 38 萬 Token。拆成團(tuán)隊(duì)之后實(shí)際消耗變成了調(diào)度和拆解環(huán)節(jié)約 4 萬 Token全部走輕量/中等模型成本不到原來的十分之一。執(zhí)行環(huán)節(jié)20 篇報(bào)告里真正需要深度分析的只有 8 篇走旗艦?zāi)Ｐ图s 12 萬 Token另外 12 篇相對(duì)模板化走輕量模型約 3 萬 Token。審查環(huán)節(jié)審查員對(duì) 20 份結(jié)果做檢查約 2 萬 Token。匯總環(huán)節(jié)約 1.5 萬 Token。合計(jì)約 22.5 萬 Token比原來少了四成。但這不是全部——因?yàn)榉止?huì)讓輸出更穩(wěn)定出錯(cuò)重試率從原來的 15% 降到了 3%重試消耗的 Token 也大幅減少。實(shí)際跑下來總消耗穩(wěn)定在 14 萬到 18 萬 Token 之間比原來省了 50% 到 60%。核心邏輯很簡單旗艦?zāi)Ｐ椭惶幚砟?8 篇真正需要深度推理的報(bào)告剩下的重復(fù)勞動(dòng)全部下沉到低成本模型。省下的不是“少干活”而是“不讓高價(jià)資源干低價(jià)活”。3. 實(shí)操落地多智能體工作流的分工與配置3.1 系統(tǒng)架構(gòu)與數(shù)據(jù)流配團(tuán)隊(duì)不是靠想象得有一套實(shí)際可跑的工作流。我的實(shí)現(xiàn)并不復(fù)雜按三層來組織入口層負(fù)責(zé)接收任務(wù)并分配權(quán)重執(zhí)行層負(fù)責(zé)按清單干活結(jié)果層負(fù)責(zé)質(zhì)檢和匯總。入口層收到用戶請(qǐng)求后先由調(diào)度員判斷這是“簡單查詢”“標(biāo)準(zhǔn)處理”還是“深度分析”。判斷依據(jù)可以是一個(gè)很輕量的 prompt讓模型輸出一個(gè)難度標(biāo)簽和預(yù)估預(yù)算。這一步會(huì)讓系統(tǒng)多花幾千 Token但換來的是后續(xù)整個(gè)流程的合理性非常劃算。接著拆解員根據(jù)難度標(biāo)簽輸出一個(gè) JSON 格式的執(zhí)行計(jì)劃。計(jì)劃里明確每一步做什么、用哪個(gè)等級(jí)的模型、Token 預(yù)算是多少。我在這個(gè)環(huán)節(jié)會(huì)強(qiáng)制要求只輸出結(jié)構(gòu)化字段不要任何解釋性文字。一個(gè)典型的計(jì)劃長這樣{ task_id: 20250110-001, difficulty: deep, steps: [ { step_id: 1, action: read_full_report, model: mid, max_tokens: 2000 }, { step_id: 2, action: deep_analysis, model: gpt-6-ultra, max_tokens: 6000 }, { step_id: 3, action: format_result, model: light, max_tokens: 1000 } ], budget_total: 12000 }執(zhí)行層拿著這份計(jì)劃逐項(xiàng)執(zhí)行。每完成一步就把結(jié)果寫進(jìn)一個(gè)共享上下文但注意不是把所有結(jié)果全部拼在一起而是只保留關(guān)鍵信息。審查員則在執(zhí)行結(jié)果到達(dá)后用一套評(píng)分 prompt 判斷是否合格不合格的任務(wù)會(huì)被打回重做并附帶失敗原因。3.2 關(guān)鍵參數(shù)模型、溫度、max_tokens 怎么設(shè)我在實(shí)踐里總結(jié)了一套參數(shù)配置照著用基本不會(huì)出大問題。第一步是設(shè)置溫度。調(diào)度、拆解、匯總?cè)坑?0不允許模型自由發(fā)揮——我要的是穩(wěn)定結(jié)構(gòu)和可解析格式。執(zhí)行環(huán)節(jié)里模板化任務(wù)用 0.2深度分析用 0.4 到 0.5保證有一定多樣性但不會(huì)失控。第二步是嚴(yán)格控制 max_tokens。很多人不舍得設(shè)這個(gè)值總怕模型輸出不完整。但旗艦?zāi)Ｐ湍J(rèn)輸出上限很高你如果不限制它很容易就把一個(gè)簡單摘要寫成三千字小作文。我的做法是先給一個(gè)保守值跑完看有沒有截?cái)嗳绻?truncation 率達(dá)到 5% 以上再逐級(jí)上調(diào)。實(shí)測下來審查和匯總?cè)蝿?wù) max_tokens 給到 1000 到 2000 就綽綽有余。第三步最容易被忽略prompt 里強(qiáng)制規(guī)定輸出格式。我在每個(gè)子任務(wù)的 system prompt 里都會(huì)寫清楚“只輸出 JSON不要任何解釋、開場白、結(jié)束語”。這一步能把輸出 Token 砍掉 30% 以上。旗艦?zāi)Ｐ陀绕湎矚g在回答前加一段“好的根據(jù)你提供的信息……”——這些全是白付的錢。3.3 Prompt 里的 Token 預(yù)算控制技巧控制 Token 不能只靠模型側(cè)參數(shù)prompt 本身就是最大的調(diào)節(jié)杠桿。我常用的手法有三個(gè)。第一個(gè)是目標(biāo)長度約束。在 prompt 里直接寫“把摘要壓縮到 200 字以內(nèi)”“只返回結(jié)論和三個(gè)依據(jù)”“每點(diǎn)不超過 50 字”。模型對(duì)長度要求是有感知的你明確給數(shù)字它通常會(huì)照著辦。比含糊地寫“簡潔一點(diǎn)”有效得多。第二個(gè)是結(jié)構(gòu)化模板。讓模型按固定字段輸出而不是自由格式。自由格式意味著模型要自己做排版、自己決定信息密度這些決策過程都會(huì)以 Token 形式反映在輸出里。結(jié)構(gòu)化模板把“怎么組織內(nèi)容”這件事實(shí)質(zhì)上由你接管了模型的輸出更加直接。第三個(gè)是漸進(jìn)式摘要。長文檔不要一次性全文塞進(jìn)去而是先讓輕量模型分段做摘要再把摘要集合交給旗艦?zāi)Ｐ妥龇治?。這個(gè)思路看起來多了一道處理步驟但輕量模型的摘要成本很低而旗艦?zāi)Ｐ吞幚矶陶某杀具h(yuǎn)低于處理全文?？傎~算下來能省一半以上。3.4 上下文緩存與 Token 續(xù)簽別讓認(rèn)證問題浪費(fèi)錢熱詞里有一大堆和 “token exchange failed”“token 失效”“403 forbidden” 相關(guān)的痛點(diǎn)。這部分在真實(shí)工作流里同樣重要——如果你的 access token 反復(fù)失效每次重新鑒權(quán)、重新建立會(huì)話都是在燒額外的 Token 和時(shí)間。我先說一個(gè)最常見的問題把 access token 直接寫死在代碼里。在某些平臺(tái)token 的默認(rèn)有效期不長你寫到配置文件里隔幾天它就失效了然后你會(huì)收到 401 或 403 錯(cuò)誤。正確做法是設(shè)計(jì)一套“短 token 長 refresh token”的機(jī)制。access token 快過期時(shí)用 refresh token 主動(dòng)換新不要等到報(bào)錯(cuò)了再處理。我看到很多人遇到token exchange failed: token endpoint returned status 403 forbidden就慌其實(shí)這類錯(cuò)誤本質(zhì)是鑒權(quán)鏈路失敗。排查思路很固定先確認(rèn) API key 或 token 是否還有效再確認(rèn)賬號(hào)權(quán)限是否包含目標(biāo)模型的使用資格然后檢查服務(wù)端時(shí)間是否同步、請(qǐng)求頭字段是否正確。403 不等于你的密鑰被黑了很多時(shí)候只是權(quán)限配置或 token 續(xù)簽邏輯沒跟上。另外重試邏輯也要做冪等。我踩過一個(gè)坑token 過期后請(qǐng)求失敗腳本自動(dòng)重試但重試時(shí)重新生成了新的任務(wù) ID導(dǎo)致同一份報(bào)告被處理了兩遍白燒一倍的 Token。后來我在任務(wù)請(qǐng)求里固定一個(gè) task_id失敗重試沿用同一個(gè) ID如果服務(wù)端發(fā)現(xiàn)這個(gè) ID 已經(jīng)處理過直接返回緩存結(jié)果。這一步對(duì)成本控制幫助非常大。4. 避坑實(shí)錄常見 Token 故障排查與省錢復(fù)盤4.1 常見 Token 報(bào)錯(cuò)速查表跑這套工作流的過程中我?guī)缀醢阉谐Ｒ妶?bào)錯(cuò)都撞了一遍。下面這張表是實(shí)戰(zhàn)總結(jié)覆蓋了批量任務(wù)里最經(jīng)常出現(xiàn)的幾個(gè)問題。報(bào)錯(cuò)或現(xiàn)象可能原因處理建議401 invalid_api_keyAPI key 錯(cuò)誤、被輪換或權(quán)限被回收檢查密鑰是否最新去控制臺(tái)重新生成并更新配置403 forbidden / token exchange failed賬號(hào)角色權(quán)限不足、token 過期、refresh 流程異常先刷新 token再查角色權(quán)限確認(rèn)目標(biāo)模型可用429 rate_limit_exceeded并發(fā)過高觸發(fā)限流指數(shù)退避重試把并發(fā)數(shù)降到合理范圍context_length_exceeded輸入超過模型上下文窗口分段輸入、先用輕量模型壓縮摘要token could not be refreshedrefresh token 過期或失效重新走完整授權(quán)流程換新的 refresh token輸出被截?cái)鄊ax_tokens 設(shè)得太低按 truncation 率逐步調(diào)高不要一次拉滿任務(wù)重復(fù)執(zhí)行重試時(shí)未做冪等固定 task_id服務(wù)端做去重4.2 實(shí)測復(fù)盤一組真實(shí)消耗數(shù)據(jù)我把優(yōu)化前后的數(shù)據(jù)放在一起對(duì)比這里用相對(duì)數(shù)字說明方便不同算力配置的人參考。任務(wù)類型優(yōu)化前消耗相對(duì)值優(yōu)化后消耗相對(duì)值省幅批量文檔摘要20 份1.00.4159%多輪業(yè)務(wù)問答30 輪1.00.5248%代碼審查與重構(gòu)建議1.00.3862%長文本結(jié)構(gòu)提取10 萬字1.00.4555%代碼審查這個(gè)場景省得最多原因是原來每次審查都是把整個(gè)代碼倉庫的上下文塞進(jìn)去審查員還反復(fù)輸出長段解釋。優(yōu)化后拆解員先定位變更文件執(zhí)行員只審查 diff 部分審查員只輸出問題清單和嚴(yán)重級(jí)別格式統(tǒng)一Token 自然大幅下降。4.3 幾條只有實(shí)操過才會(huì)懂的經(jīng)驗(yàn)第一路由不是拍腦袋。我開始時(shí)把 70% 的任務(wù)都?xì)w為“深度分析”全部走旗艦?zāi)Ｐ徒Y(jié)果省得并不多。后來我把“深度分析”的判定標(biāo)準(zhǔn)寫得更嚴(yán)只有當(dāng)任務(wù)需要多步推理、需要跨多源信息綜合判斷時(shí)才走旗艦?zāi)Ｐ?。?biāo)準(zhǔn)一收緊成本立刻下來了。第二審查環(huán)節(jié)容易變成浪費(fèi)重災(zāi)區(qū)。如果審查員 prompt 寫得太開放它會(huì)把每份結(jié)果都做成長篇修改意見?！澳阈量嗔苏w不錯(cuò)但有幾點(diǎn)需要注意……”這種話每份都來一遍就是純燒錢。我給審查員的指令非常機(jī)械只輸出 pass 或 failfail 時(shí)給出不超過 20 個(gè)字的失敗原因。效果出奇地好。第三緩存和冪等是省 Token 的隱形功臣。很多人只盯著 prompt 調(diào)優(yōu)忽略了重復(fù)執(zhí)行才是最大的浪費(fèi)源。一次批量跑批因?yàn)榫W(wǎng)絡(luò)抖動(dòng)重試三次三次都全量計(jì)費(fèi)一次就能抵上你精心省下的所有 Token。我后來在網(wǎng)絡(luò)錯(cuò)誤重試前加了一層結(jié)果檢查如果任務(wù) ID 對(duì)應(yīng)的結(jié)果已經(jīng)存在直接復(fù)用不再重新請(qǐng)求。第四定時(shí)刷新 token 比報(bào)錯(cuò)再刷新更省。我之前是等 401 了才去刷新結(jié)果刷新的那段空窗期里隊(duì)列里的請(qǐng)求全部失敗后續(xù)重試又會(huì)疊加大量冗余消耗。后來我加了一個(gè)定時(shí)任務(wù)在 token 過期前 5 分鐘主動(dòng)刷新。這里還有一個(gè)細(xì)節(jié)刷新 token 和正常請(qǐng)求最好走不同的邏輯分支不然刷新本身也會(huì)被當(dāng)成普通任務(wù)計(jì)入路由白白消耗上下文窗口。5. 不想搭團(tuán)隊(duì)三招輕量省錢法看到這里可能有人會(huì)覺得搭建多智能體工作流有點(diǎn)復(fù)雜。如果你只是日常使用不想搞那么多組件下面的三招夠用了。它們不需要額外寫太多調(diào)度代碼只要在 prompt 和交互習(xí)慣上做調(diào)整就能明顯減少 Token 消耗。第一招先計(jì)劃后執(zhí)行。接到復(fù)雜任務(wù)時(shí)先不要直接讓大模型給最終答案而是先讓它輸出一個(gè)短計(jì)劃。計(jì)劃通常幾百 Token成本極低。你看完計(jì)劃確認(rèn)方向?qū)α嗽僮屗綀?zhí)行。不要小看這一步很多無效 Token 都花在“方向錯(cuò)了答得再好也是白費(fèi)”上面。第二招摘要替代全文。需要大模型分析長文時(shí)先自己把文檔過一遍提煉出核心信息再帶著核心信息去做分析。你可以在輕量模型里做一次預(yù)壓縮也可以人工提煉。類比一下去圖書館不是抱著整個(gè)書架跑而是先翻目錄確定要看哪幾章再借那幾章。第三招滾動(dòng)壓縮歷史。多輪對(duì)話里別讓所有歷史都留在上下文里。每完成一個(gè)階段性的目標(biāo)就讓模型把該階段的關(guān)鍵結(jié)論整理成一段短摘要然后開一個(gè)新會(huì)話只帶摘要繼續(xù)。這本質(zhì)上是“存檔點(diǎn)”機(jī)制游戲玩過吧——打一段存?zhèn)€檔而不是從第一關(guān)到 boss 關(guān)一直不存檔。最后再說兩句我的實(shí)際體會(huì)這套方案跑了大半年我最大的感受是省 Token 不是說換個(gè)便宜模型而是要把預(yù)算花在刀刃上。旗艦?zāi)Ｐ偷膬r(jià)值在深度推理不在重復(fù)勞動(dòng)。讓它只做那些真正難的部分其他環(huán)節(jié)都用合適的模型承接質(zhì)量和成本的平衡點(diǎn)是可以找到的。最實(shí)用的一個(gè)小技巧是每次跑完批量任務(wù)都去看一眼“輸入 Token”和“輸出 Token”的占比。如果輸出占比太高說明 prompt 里控制還不夠狠如果輸入占比太高說明上下文管理有余地。先分清錢花在哪再?zèng)Q定砍哪里比盲目調(diào)任何一個(gè)參數(shù)都有用。