2026年春季，大模型行業(yè)的高燒似乎正在退去，取而代之的是一種近乎冷酷的理性。近日，《財(cái)經(jīng)》報(bào)道指出，全球企業(yè)級(jí) AI 應(yīng)用中，約50%的Token正在被浪費(fèi)。

浪費(fèi)的原因很具體，AI應(yīng)用從“對(duì)話”轉(zhuǎn)向“執(zhí)行”，這些計(jì)算資源流向了較貴的大型旗艦?zāi)Ｐ?，Agent在復(fù)雜多輪任務(wù)中，歷史文件、對(duì)話會(huì)不斷累積，大量無(wú)用、冗余、過(guò)期的信息會(huì)不斷產(chǎn)生并且重復(fù)計(jì)算，Token消耗因此指數(shù)級(jí)增長(zhǎng)。也就是說(shuō)，企業(yè)和開(kāi)發(fā)者在用最貴的車(chē)跑最短的路。

OpenRouter的流量數(shù)據(jù)反映了這個(gè)轉(zhuǎn)變：過(guò)去一個(gè)季度，旗艦級(jí)模型的調(diào)用占比在下降，100B–300B區(qū)間的模型調(diào)用量則明顯上升。以近日上線的100B 模型Elephant為例，單日流量暴漲500%，沖上熱榜榜首，成為OpenClaw等 Agent 最受歡迎的選型。開(kāi)發(fā)者開(kāi)始按任務(wù)類型分配模型，而不是一律用最頂配。這是工程理性回歸的信號(hào)，不是對(duì)旗艦?zāi)Ｐ偷姆穸ā?/p>

為什么現(xiàn)在才開(kāi)始算這筆賬

幾年前，"選最強(qiáng)的模型"是最省心的工程決策。旗艦?zāi)Ｐ蛶缀踉谒腥蝿?wù)上都更好，成本問(wèn)題還沒(méi)到逼人重新設(shè)計(jì)架構(gòu)的程度。

現(xiàn)在情況變了，Agent需要“執(zhí)行”大量工作。一個(gè)客服Agent處理一張工單，可能需要調(diào)用模型十幾次：理解意圖、查詢知識(shí)庫(kù)、判斷優(yōu)先級(jí)、生成回復(fù)、核查格式。如果同時(shí)有幾千張工單在處理，每天的調(diào)用量輕松進(jìn)入百萬(wàn)級(jí)別。在這種頻率下，每次調(diào)用多付的溢價(jià)開(kāi)始在賬單上顯現(xiàn)。

今年3月，一位名為shelvenzhou的開(kāi)發(fā)者在Github進(jìn)行了一項(xiàng)基準(zhǔn)測(cè)試，引發(fā)了廣泛討論。他記錄自己的OpenClaw日常工作（包括代碼、郵件、PDF、圖片、搜索等）Token消耗情況——第一輪對(duì)話Token成本0.0050美元；第五輪對(duì)話Token成本0.0665美元，是第一輪的13.3倍；第10輪的Token成本達(dá)到了0.13美元，是第一輪的26倍。

根據(jù)報(bào)道，《財(cái)經(jīng)》統(tǒng)計(jì)了GitHub上有關(guān)“Token Waste”相關(guān)Issues的數(shù)量。這一討論至少有5200個(gè)，僅2026年一季度就誕生了4150個(gè)。越來(lái)越多的開(kāi)發(fā)者在實(shí)際業(yè)務(wù)中正面臨控制Token浪費(fèi)的問(wèn)題。

目前大多數(shù)Agent的工程實(shí)現(xiàn)還相當(dāng)粗糙。面對(duì)Agent的多步任務(wù)，Token消耗以接近線性的速度增長(zhǎng)，而其中大量?jī)?nèi)容對(duì)當(dāng)前步驟毫無(wú)意義。這類問(wèn)題催生了一個(gè)新的工程概念——Agent Harness，它不是模型本身，而是包裹在模型外部、負(fù)責(zé)管理上下文、編排工具調(diào)用、控制執(zhí)行生命周期的“韁繩”和“馬具”。

Token 效率因此形成了兩條并行的壓力線，一條來(lái)自 Agent 框架側(cè)，Harness 的出現(xiàn)就是典型代表；另一條來(lái)自模型側(cè)，推動(dòng)廠商用更精簡(jiǎn)的參數(shù)完成同等質(zhì)量的推理。

模型，向?qū)嵱弥髁x靠攏

在這場(chǎng)范式轉(zhuǎn)移中，一批深耕“token效率”的模型成為了舞臺(tái)中央的主角。它們不比拼參數(shù)規(guī)模，而是在單位Token成本下，比拼推理速度、指令遵循度以及長(zhǎng)上下文的穩(wěn)定性。

根據(jù)OpenRouter 的 LLM Leaderboard在4月16日的數(shù)據(jù)，模型格局呈現(xiàn)出明顯的“大模型控榜，小模型控場(chǎng)”的分化態(tài)勢(shì)。

在前20名的榜單中，傳統(tǒng)意義上的大尺寸旗艦?zāi)Ｐ停ㄈ鏑laude Opus 4.6、DeepSeek V3.2等），主要分布在榜單頭部和中上部，依然掌握著復(fù)雜任務(wù)的話語(yǔ)權(quán)；而主打輕量化、高性價(jià)比的小尺寸模型（如Gemini 3 Flash、Grok 4.1 Fast、GPT-5.4 Nano等），且多集中在第 8 名至第 20 名的區(qū)間，形成了不可忽視的“腰部力量”。

可以明顯看到，小尺寸模型的漲幅驚人。根據(jù)4月16日數(shù)據(jù)，排名第17位的 GPT-5.4 Nano以48%的驚人漲幅領(lǐng)跑增長(zhǎng)榜，100B模型Elephant單日漲幅 38%。

從App使用情況來(lái)看，OpenClaw、Hermes Agent、Kilo Code、CLaude Code 等成為這些小尺寸模型的“最大流量貢獻(xiàn)”，開(kāi)發(fā)者正在將小尺寸模型作為高頻、低延遲任務(wù)的首選。

在業(yè)界看來(lái)，100B-300B已然成為一個(gè)實(shí)用主義區(qū)間。GPT-5.4-Mini是目前這條路線的典型代表之一，以更低延遲和更低成本大幅縮小與旗艦?zāi)Ｐ偷男阅懿罹唷?/p>

OpenAI 此前著重強(qiáng)調(diào)了新模型在多模型分層系統(tǒng)中的位置：以其自研編程助手Codex為例，GPT-5.4負(fù)責(zé)規(guī)劃、協(xié)調(diào)與最終判斷，而GPT-5.4 mini子智能體則并行處理代碼庫(kù)檢索、大文件審閱及輔助文檔處理等粒度更細(xì)的子任務(wù)。

OpenAI表示，隨著小型模型速度更快、功能更強(qiáng)大，開(kāi)發(fā)者無(wú)需使用單一模型處理所有任務(wù)，而是可以構(gòu)建系統(tǒng)，由大型模型負(fù)責(zé)決策，小型模型則快速大規(guī)模地執(zhí)行任務(wù)。這種分層調(diào)用的模式開(kāi)始變得實(shí)用而非將就。

Elephant Alpha是另一個(gè)值得關(guān)注的案例，該模型于4月13日深夜上線 Openrouter。同為100B參數(shù)，Elephant定位為“智能效率”優(yōu)先，在保持256K 上下文窗口的同時(shí)，重點(diǎn)優(yōu)化Token使用效率，適合代碼補(bǔ)全、快速文檔處理和輕量Agent交互等場(chǎng)景。由于來(lái)源匿名，其具體技術(shù)細(xì)節(jié)尚不透明，但在開(kāi)發(fā)者社區(qū)已有相當(dāng)?shù)膶?shí)測(cè)關(guān)注。

效率不是降級(jí)，是分工

旗艦?zāi)Ｐ筒粫?huì)消失。在需要跨領(lǐng)域深度推理、多步驟規(guī)劃、復(fù)雜代碼生成的任務(wù)上，它們?nèi)匀皇潜匾?。沒(méi)有人認(rèn)真地認(rèn)為100B模型可以在所有場(chǎng)景下替代旗艦版。

但在日常的業(yè)務(wù)執(zhí)行層——那些占據(jù)大多數(shù)調(diào)用量的任務(wù)——用旗艦?zāi)Ｐ褪窃跒椴恍枰哪芰Ω顿M(fèi)。把這部分流量遷移到效率更高的模型上，毫無(wú)疑問(wèn)是更具性價(jià)比的決策。

這種分工在軟件工程里有先例。CPU發(fā)展從追求單核主頻轉(zhuǎn)向多核協(xié)作，不是因?yàn)閱魏瞬恢匾且驗(yàn)樵趯?shí)際工作負(fù)載下，多核架構(gòu)的整體吞吐遠(yuǎn)超單純堆主頻。數(shù)據(jù)庫(kù)領(lǐng)域也有類似的演變：OLTP和OLAP長(zhǎng)期共存，不同的查詢特征對(duì)應(yīng)不同的存儲(chǔ)和計(jì)算架構(gòu)。

模型選型的邏輯正在經(jīng)歷類似的成熟。Token效率正在成為工程師評(píng)估模型的核心維度之一——不是因?yàn)楸阋?，而是因?yàn)樵诟哳l調(diào)用的場(chǎng)景下，它直接關(guān)系到產(chǎn)品的商業(yè)可行性。那些在單位成本下能提供足夠推理質(zhì)量的模型，正在成為 Agentic應(yīng)用的默認(rèn)底座。

一條路線日漸清晰：規(guī)模繼續(xù)重要，但效率開(kāi)始定價(jià)......

*以上內(nèi)容不構(gòu)成投資建議，不代表刊登平臺(tái)之觀點(diǎn)，市場(chǎng)有風(fēng)險(xiǎn)，投資需謹(jǐn)慎，請(qǐng)獨(dú)立判斷和決策。