120萬億。

這是豆包大模型現(xiàn)在的日均Token消耗量，在全球范圍僅次于OpenAI和谷歌。三個月前，這個數(shù)字還是63萬億，過個春節(jié)翻了一倍，如果時間線放到兩年前，增速是一千倍。

也無怪乎沒人再討論AI泡沫，在Token消耗量那條急速上昂的曲線面前，對大模型需求的一切質(zhì)疑都顯得不合時宜，2026年是產(chǎn)業(yè)的“Token共識之年”，對于火山引擎來說，即是好消息，也是壞消息。

好消息在于，大模型產(chǎn)業(yè)的走向證明了火山引擎戰(zhàn)略的正確性。過去兩到三年，在所有關于MaaS和Token的產(chǎn)業(yè)敘事中，火山引擎始終是最激進的一個，這被解讀為后來者面向先行者的挑戰(zhàn)機會，盡管其他頭部云廠商或多或少提及MaaS的商業(yè)模式，但是大船掉頭的思維和戰(zhàn)略慣性，導致這些廠商并沒有徹底轉(zhuǎn)向新的Token邏輯。

當AI Agent運行規(guī)模與任務復雜度同步提高，以OpenClaw為代表的各類“龍蝦”智能體產(chǎn)品，極大推升了Token消耗的天花板，加之視頻、音頻等模型的調(diào)用，相較文字對話的Token消耗也有指數(shù)級的增長，因此所有廠商都加大了MaaS商業(yè)模式的投入。

壞消息在于，火山引擎要直面比以往更激烈的競爭，當所有廠商都達成共識，被行業(yè)詬病的Token商業(yè)粘性差、毛利低的問題，也就暴露在直白的商業(yè)競爭之下，甚至可能掀起新一輪的行業(yè)價格戰(zhàn)。

火山引擎的策略是什么？

120萬億Token，花在哪了？

火山引擎總裁譚待指出，Token使用量是衡量AI發(fā)展速度的核心指標，近期豆包大模型使用量高速增長，核心驅(qū)動因素是AI視頻創(chuàng)作的爆發(fā)與AI智能體的加速普及。

第一個是視頻創(chuàng)作的爆發(fā)。Seedance 2.0、Seedream 5.0 lite等多模態(tài)模型的推出，讓視頻創(chuàng)作相關的Token消耗大幅增長。這不再是某個特定行業(yè)的需求，而是跨行業(yè)的普適應用，所有行業(yè)都有營銷、傳播的需求，視頻內(nèi)容是最好的載體。

在本次大會上，火山引擎宣布Seedance 2.0 API 面向企業(yè)用戶開放公測。據(jù)介紹，火山引擎為 Seedance 2.0 建立了行業(yè)領先的版權與肖像安全保障，覆蓋視頻生成涉及的各種模態(tài)和創(chuàng)作前后全流程，對侵權、深度偽造等行為進行檢測和防御，有效保護版權方和創(chuàng)作者的權益。

第二個是龍蝦類智能體的普及。這個在一個月內(nèi)迅速走紅的AI產(chǎn)品，正在改變企業(yè)AI的使用方式。

譚待表示，現(xiàn)在很難把龍蝦帶來的Token消耗歸到某個特定行業(yè)或場景。一年前大家還會按行業(yè)劃分AI的應用，現(xiàn)在龍蝦的普及，讓每個員工都能使用，有人用它做招聘，有人用它做市場分析，有人用它處理周報，所以無法單一定義其應用場景。

“這也印證了我們的邏輯，AI的發(fā)展既要自上而下，也要自下而上，自下而上就是讓員工都能使用AI，ArkClaw這類產(chǎn)品就非常適合；自上而下則是像HiAgent這類產(chǎn)品，二者結(jié)合能讓企業(yè)的AI創(chuàng)新和轉(zhuǎn)型速度大幅提升?！彼a充道。

由此也引出企業(yè)使用AI的兩種方式，譚待認為，企業(yè)AI未來會有敏態(tài)和穩(wěn)態(tài)兩種形態(tài)，敏態(tài)以員工為導向，支持廣泛嘗試，比如通過ArkClaw產(chǎn)品，員工能探索招聘等問題的解法，這就是敏態(tài)。

當嘗試出有效方法后，可通過HiAgent產(chǎn)品將方法固化，轉(zhuǎn)為穩(wěn)態(tài)業(yè)務。穩(wěn)態(tài)業(yè)務能關注穩(wěn)定性、準確率和成本問題，還能優(yōu)化路徑、選擇不同尺寸和能力的模型，從而降低成本。

“企業(yè)真正關注的是端到端完成事情的整體成本，而非單Token成本，若單Token成本低，但用較差的模型需要消耗10倍甚至20倍Token還做不出結(jié)果，只會造成浪費?！弊T待說。

Token會不會漲價？

摩根士丹利在3月份研報中指出，云計算一直是價格通縮的行業(yè)，規(guī)模越大，成本越低，價格就越向下。但是，AI時代正在打破這一范式，一個前所未有的提價周期正在醞釀，中國AI云定價將開啟20年來首次上調(diào)周期。

其同時也指出，不同于全球市場云廠商已開啟漲價周期，中國市場具備兩個獨有制約因素，一是不同廠商對于市場份額的優(yōu)先級不同，相應定價策略可能壓制行業(yè)整體提價空間；

二是中國缺乏類似OpenAI這樣對算力需求極度旺盛的獨立基礎模型提供商，使得供應端成本壓力向下游定價的傳導效率相對弱于美國市場。

談及漲價話題，譚待的回應很直接，首先漲價只是部分廠商的行為，也有廠商在降價。更重要的是，Token的價值不同，價格自然也不同。“下一代模型能力更強，單Token成本理論上會更貴，但單Token產(chǎn)生的經(jīng)濟價值也會更高?！?/p>

此外他還表示，一些場景下Token價格高，關鍵不在Token本身貴，而在無效Token消耗太多。“目前龍蝦使用的Tokens，有一大半都是無謂的探索。通過優(yōu)化skill配合、壓縮等方法，能減少這類無謂的投入消耗，成本也會大幅降低?！?/p>

圖片來自AI生成

三年前沒人用模型，大家只能講模型參數(shù)；之后開始講用量，因為模型能力還有限，能做的案例也比較簡單，當時企業(yè)也在探索如何通過模型賺錢。

現(xiàn)在的趨勢是，不少企業(yè)已經(jīng)找到了用模型創(chuàng)造更大經(jīng)濟價值的方法，比如用Seedance 2.0能以低成本、高效率制作內(nèi)容，在廣告營銷、內(nèi)容制作上獲得更多收入。一旦這個商業(yè)邏輯跑通，企業(yè)對模型的要求就會轉(zhuǎn)向價值導向，關注模型能否創(chuàng)造更大價值、解決實際問題，這能推動行業(yè)建立正循環(huán)，也是企業(yè)現(xiàn)在最核心的關注點。

近期國內(nèi)阿里云、百度云等廠商先后宣布AI相關算力產(chǎn)品漲價公告，火山引擎等廠商則保持價格不變，反映出不同廠商的策略以及資源儲備不同。

譚待指出，豆包每一代模型的定價都經(jīng)過精心設計，定價后基本保持不變，若結(jié)合模型的智力水平看，單Token的價格實際在下降，因為軟硬件層面的優(yōu)化一直在推進，而模型的智力上限卻在持續(xù)提升，看Token價格，不能拋開模型能力，否則沒有任何意義。

賽博養(yǎng)蝦三要素

龍蝦火了之后，一個問題困擾著很多企業(yè)客戶：推出龍蝦后，原有工作該如何開展？

譚待提出的敏態(tài)和穩(wěn)態(tài)思路，為這個問題提供了解決方案。但要讓龍蝦真正在企業(yè)落地，還需要三個關鍵要素：模型、安全和Skills。

“模型是核心，決定了智能體能力的上限和下限?！弊T待說，豆包2.0針對Agent場景做了很多優(yōu)化，尤其是在VLM能力上，在視覺理解、計算機視覺、機器人視覺方面表現(xiàn)很好。

安全是第二個要素，也是用戶關注的核心。隨著OpenClaw使用量的提升，有很多問題，比如沙箱與權限失控、提示詞注入、Skills插件投毒等安全問題不斷出現(xiàn)，實際上Openclaw有一套安全設計的機制，完全可以通過更好的產(chǎn)品化設計，和現(xiàn)有安全方案的結(jié)合，盡可能的完善龍蝦的安全機制。

火山引擎ArkClaw針對Agent權限管理和Skills全流程安全防護做了全面升級，也正式通過了信通院有關“龍蝦”類產(chǎn)品的可信能力認和安全防護產(chǎn)品有效認證，是國內(nèi)首家、也是目前唯一一家同時斬獲這兩項認證的廠商。

第三個要素是Skills的開放，決定智能體執(zhí)行能力邊界的要素，正在成為各家競爭的焦點。譚待表示，大家使用OpenClaw，核心看中的是其全球開放的生態(tài)。

本次大會上，火山引擎宣布和OpenClaw共建“ClawHub中國鏡像站”，而非做私有的生態(tài)。通過中國官方鏡像網(wǎng)站，開發(fā)者可以提供更友好的使用體驗，不用擔心高頻訪問源站即時性和穩(wěn)定性問題。

談及龍蝦這條路線是否是AGI過程中的真正轉(zhuǎn)折點，還是可能在半年甚至一年后被更先進的方式取代，譚待給出了一個類比：

”電腦是偉大的發(fā)明，但軟盤在電腦發(fā)展史上的地位，很難定義是轉(zhuǎn)折點還是階段性產(chǎn)物。OpenClaw的相關技術對行業(yè)產(chǎn)生了巨大影響，但未來到了AGI時代，再回看它的定位，是像軟盤一樣的階段性產(chǎn)物，還是有更高的地位，現(xiàn)在很難判斷?！?/p>

一年前，譚待曾用馬拉松作比喻，AI行業(yè)大概跑了500米，現(xiàn)在，他判斷這個距離變成了一公里。

“判斷行業(yè)階段可以用終局來倒推，目前OpenAI、Anthropic等企業(yè)的收入是已知的，全球行業(yè)收入大概是這些企業(yè)收入的三倍，結(jié)合對未來收入的想象空間，就能判斷行業(yè)的發(fā)展進度?！?strong>（本文作者 | 張帥，編輯 | 楊林）