25美分復(fù)刻o1推理：窮人的并行搜索方案

第一次用OpenAI o1時，我拋給它一個刁鉆問題："設(shè)計一個多區(qū)域、強一致的隊列，要能扛住整個AWS區(qū)域掛掉。"

它停頓了十秒。然后給出一個精妙、謹慎、自我修正的答案。我服了。

然后看了眼價格。還有速率限制。還有我完全看不到它為什么否決某些路徑的黑箱。

這時候一個念頭冒出來——不是什么突破，而是一個老舊、無聊、美好的云架構(gòu)模式：Map-Reduce。

AI實驗室不會告訴你的秘密：推理就是搜索，而搜索天生愛并行。

你不需要o1。你需要50個廉價大模型并行跑，一個裁判，再加AWS Step Functions。

單模型的困境

單個LLM是個聰明的猜測者，但只有一槍機會。問它難題，它立刻開始吐token。第20個token stumble一下，整個答案就歪進溝里。

o1的解法是"先想后說"——模擬多條內(nèi)部思維鏈。

但訣竅在于：你不需要特殊模型來干這個。可以暴力推理——讓50個廉價模型的副本各試一種思路，再雇一個昂貴的裁判挑出最好的想法，縫合起來。

這不是魔法。這是分布式計算。

我叫它Scatter-Gather Reasoning（分散-收集推理）。

架構(gòu)全在Serverless

整套東西搭在AWS無服務(wù)器上。沒有Kubernetes，沒有常駐GPU。

用戶問題進來，Step Functions的Distributed Map同時啟動50個Lambda。每個Lambda調(diào)Claude 3 Haiku（極便宜、極快），temperature設(shè)0.9。

高溫意味著同樣提示詞產(chǎn)出 wildly different 的答案。一個Haiku可能提議Postgres隊列，另一個推SQS+DynamoDB，第三個可能幻覺出一個完全錯誤但有趣的方案。

沒關(guān)系。我們要的就是多樣性。

50個響應(yīng)在2-4秒內(nèi)落進S3桶。

工人跑完后，Step Functions觸發(fā)單個Judge Lambda。它讀取全部50個答案，拼成一個巨型提示詞，發(fā)給Claude Sonnet 3.5（聰明得多，但更慢更貴），temperature壓到0.1。

裁判的系統(tǒng)提示詞極其簡潔：

"審閱這50個方案。明顯錯的扔掉。從幸存者里提取最強想法。然后合成一個單一、正確、生產(chǎn)就緒的答案。注明哪個工人貢獻了哪個想法。"

Sonnet返回最終答案。用戶看到的是一個深思熟慮、推理嚴密的回應(yīng)——完全不知道背后有50個小模型壯烈犧牲。

成本拆解

按us-east-1 Bedrock現(xiàn)價算賬。單次硬查詢假設(shè)：

Haiku蜂群：（500輸入+1000輸出）×50 = 每個工人$0.00025 → 總計$0.068

Sonnet裁判：輸入50,500 token → $0.15；輸出2,000 token → $0.03

合計：約25美分。15秒內(nèi)跑完。

作為對照，o1-preview按輸入長度不同，單次查詢成本在$0.60到$6.00之間。而且你還看不見它怎么想的。

這方案不是什么

不是o1替代品。o1在數(shù)學(xué)證明和代碼生成上仍然更強，它的內(nèi)部思維鏈針對特定推理任務(wù)做了優(yōu)化。

但對我們這些需要解釋性、需要控制成本、需要知道答案從哪來的人來說，Scatter-Gather是個務(wù)實的中間地帶。

你可以看到50個工人各自想了什么。可以調(diào)溫度、調(diào)數(shù)量、換模型。可以把裁判換成Gemini 1.5 Pro，或者本地Llama 3 70B。

這是可審計的推理。開源的o1。

關(guān)鍵設(shè)計決策

為什么用Haiku當(dāng)工人？夠快夠便宜，幻覺率其實對發(fā)散搜索有利——我們要的是想法多樣性，不是每個都對。

為什么50個？邊際收益遞減。測試顯示30個能抓到80%的好想法，50個到90%，再往上性價比崩掉。

為什么S3做中間存儲？Step Functions狀態(tài)機有256KB限制，50個完整響應(yīng)塞不進去。S3便宜到忽略不計，而且方便調(diào)試時翻日志。

為什么讓裁判引用工人編號？這是可解釋性的核心。用戶追問"為什么選DynamoDB全局表而不是Aurora Global"，你能指認是Worker_17提出的，并回溯它的原始推理。

實際跑起來的坑

第一個版本用SQS做工人結(jié)果收集，踩了坑：SQS消息可見性超時和Lambda超時打架，導(dǎo)致部分結(jié)果重復(fù)處理。換成S3+Step Functions原生等待模式，可靠性提升一個數(shù)量級。

Haiku的temperature 0.9在部分查詢上太瘋，會生成語法破碎的JSON。加了輸出格式強制：每個工人必須用指定JSON schema返回，否則自動重試一次。裁判收到格式錯誤的直接丟棄。

Sonnet裁判的輸入token膨脹很快。50個工人各回1000 token，加上提示詞框架，輕松破5萬。早期用Claude 3 Opus當(dāng)裁判，輸入成本直接飆到$0.75，性價比崩塌。Sonnet 3.5是甜點。

什么時候別用這套

實時聊天場景不行，15秒延遲用戶受不了。需要確定性輸出的合規(guī)場景也不行，概率性搜索本質(zhì)不可復(fù)現(xiàn)。還有極度簡單的查詢——讓50個工人搶答"2+2"，純粹浪費錢。

最適合的是：復(fù)雜架構(gòu)設(shè)計、故障排查根因分析、需要多視角權(quán)衡的策略決策。也就是o1宣傳冊上寫的那些場景，只是你愿意用可解釋性和成本換可控性。

下一步可以玩什么

工人分層：10個Haiku做快速發(fā)散，10個Sonnet做深度推演，30個Haiku做邊界情況探索。成本漲一點，覆蓋度漲很多。

遞歸Scatter-Gather：裁判的合成答案如果置信度不夠，自動觸發(fā)第二輪，針對薄弱環(huán)節(jié)再派50個工人深挖。

模型異構(gòu)：混用Claude、GPT-4o-mini、Gemini Flash當(dāng)工人，利用不同訓(xùn)練數(shù)據(jù)的盲區(qū)互補。

但這些優(yōu)化都有個前提：先跑通基礎(chǔ)版。25美分一次，值得試試。

代碼和CloudFormation模板我放在GitHub了。不是產(chǎn)品，是藍圖。按你的需求改，按你的預(yù)算調(diào)。

云廠商花了二十年教我們：規(guī)模上去，單價下來。AI推理正在走同樣的路。o1是保時捷，Scatter-Gather是改裝思域——慢兩秒，但你知道引擎蓋下面每一顆螺絲在哪。