金磊 發(fā)自 凹非寺
量子位 | 公眾號 QbitAI

神秘模型Elephant的面紗，終于被揭開了。

事情是這樣的。

前一陣子OpenRouters在自家官方上提到了一個神秘模型Elephant Alpha，并且給到的評價是這樣的：

僅100B大小，在同規(guī)模模型里是SOTA，還巨省Token。

話題一出，立即引來不少網(wǎng)友們的圍觀，他們紛紛開始猜測這又是哪家的模型。

不過非常微妙的一點是，這次網(wǎng)友們猜測的對象，統(tǒng)一地指向了中國大模型：

是MiniMax、Kimi、DeepSeek，還是什么新黑馬？

量子位獨家獲悉了答案，只能說網(wǎng)友們猜對了一半——

確實是來自中國的模型；但玩家并未在他們給的選項里。

因為這頭「大象」，出自螞蟻Inclusion AI 團隊之手。

很反差的一點是，「大象」不大，自帶的只是100B大小、256K上下文窗口、32K輸出的敏捷屬性。

并且在整體體驗下來之后，很直觀的感受，就是它有點國產(chǎn)版Grok 4 Fast的味道，天生干活圣體。

來，咱們這就展開一波深度實測~

干活圣體，很省Token

針對「大象」的實測，我們是在OpenRouters上的網(wǎng)頁端來展開。

并且會取日常工作較高頻的工作內(nèi)容來進行測試，只為證明一件事：「大象」干活，到底行不行。

實測1：修Bug沒有多余廢話

對于程序員群里來說，AI寫代碼已經(jīng)不是什么新鮮事了。

但現(xiàn)在比較頭疼的，就是怕AI唰唰唰地寫了幾百行代碼，一跑全報錯，再讓它改，它又給你唰唰唰地重新生成幾百行……

不僅效率低，還很費Token。

為此，我們在這個實測環(huán)節(jié)中給「大象」先安排了一個接地氣的任務(wù)：

用HTML和原生JS寫一個帶表單校驗的活動報名頁，要求包含姓名、手機號、郵箱，并且手機號必須符合中國大陸格式。

△原速度展示

可以看到，「大象」在思考片刻后，以極快的速度將代碼給生成了出來。

把整段代碼保存為.html文件后，也是可以成功運行。

但這并不是重點，重點在于「大象」是否做到修復(fù)。

于是乎，我們接下來給剛才生成好的代碼來一波投毒的操作：

把JS邏輯里定義提交按鈕的變量 const submitBtn = document.getElementById(‘submitBtn’) 直接刪掉。

如此投毒之后，控制臺必定會爆出 Uncaught ReferenceError: submitBtn is not defined 的錯誤。

然后我們把這份代碼再喂給「大象」，并簡單地附上一句：

運行報錯了，找不到變量。

不同于其它大模型，「大象」特別精準地找到了問題所在，然后用極簡的方式給出了解法。

也正因為這種沒有多余廢話的回答，直接省去了Token的無用消耗。

實測2：雜亂文檔，會抓重點

代碼生成和修復(fù)還只能說是程序員工作圈子里的任務(wù)，但像會議內(nèi)容整理，幾乎是所有職場人都需要經(jīng)歷的事兒。

在這項測試中，我們特意準備了一份大約3000字的會議紀要，里面充滿了口語化的表述，毫無意義的重復(fù)強調(diào)、部門之間關(guān)于排期的互相扯皮，甚至還有中途某人跑題聊起中午吃什么的外賣討論：

然后我們把文件丟給「大象」并附上一句Prompt：

忽略所有寒暄和跑題內(nèi)容。請基于這3000字，嚴格按照以下JSON 格式（包含：結(jié)論摘要、待辦清單及責(zé)任人、一封用于抄送全員的跟進郵件草稿）輸出結(jié)果。

「大象」給出的整理結(jié)果可以說是一目了然。

在剔除了無用信息之后，嚴格按照Prompt要求的那樣，把會議內(nèi)容給呈現(xiàn)了出來。

或許單看「大象」的結(jié)果不夠明顯，我們?yōu)榇颂匾饽昧薌emini-2.5-Flash-Lite做了下對比：

正所謂沒有對比就沒有傷害。

Gemini-2.5-Flash-Lite雖然也是實現(xiàn)了Prompt里的結(jié)構(gòu)，但很明顯一點就是，太長，也就意味著更多Token的消耗。

所以「大象」在會議整理任務(wù)上，Win Again。

實測3：Agent任務(wù)，也是夠快

最后的實測，我們來上一道硬菜——大火的Agent。

我們用「大象」來模擬一個輕量級的Agent Loop：

讀取一份包含四個月度數(shù)據(jù)的CSV銷售報表 → 計算季度同比（需要調(diào)用數(shù)學(xué)邏輯） → 寫一段簡練的分析結(jié)論 → 自檢數(shù)字是否準確。

從內(nèi)容上來看，「大象」先是對數(shù)據(jù)做了快速分析和推理，并給出了初步結(jié)論；而后又完成了自檢的工作，最終輸出最終結(jié)論。

但更重要的還是速度：只思考了10秒鐘、輸出2秒鐘。

由此可見，這個只有100B大小的「大象」，是真的做到了快、準、省。

而這一點，同樣體現(xiàn)在權(quán)威榜單的評測中。

作為開發(fā)者圈層公認的模型測謊儀，AI BENCHY不看廠商宣傳跑分，只聚焦指令遵循、響應(yīng)速度、Token效率三大實戰(zhàn)指標。

從AI BENCHY給出的結(jié)果來看，「大象」輸出Token維持在了2500左右，說明每一分錢的API算力，都用在了刀刃上。

平均響應(yīng)時間方面，「大象」平均時延被壓制在了1秒左右，而其它選手則均是10-30秒的水平。

并且在最重要的輸出質(zhì)量上，它的一致性分數(shù)達到了9.6分（滿分10分）！

因此，不論是從實測的體驗，亦或是權(quán)威榜單的評測來看，「大象」已然是可以勝任日常絕大多數(shù)的工作了。

但也有不擅長的事

正所謂人無完人、模無完模。

「大象」畢竟走的是一條快、準、省的路線，所以它定然是在某些領(lǐng)域里有所妥協(xié)。

在我們的實測中，也發(fā)現(xiàn)了「大象」一些不太擅長的工作。

例如復(fù)雜長鏈規(guī)劃，就是其中之一：

幫我主導(dǎo)一個出海東南亞市場的戰(zhàn)略項目。請從市場調(diào)研開始，接著做競品分析，然后給出渠道策略建議，最后幫我排一個半年的執(zhí)行甘特圖。

對于這個任務(wù)，「大象」直言無法執(zhí)行。

因為它沒有數(shù)據(jù)采集工具、沒有分析工具、沒有策略生成工具，也沒有項目管理工具。

所以對于這類任務(wù)，我們不妨用大模型規(guī)劃 + 「大象」執(zhí)行的方式來操作。

再如，對于非常非常新的知識，「大象」也可能會心有余而力不足。

以及要求生成React 18新特性或剛更新的SDK代碼時，「大象」可能會基于舊知識產(chǎn)生API幻覺。

所以如果你有這方面的需求，可以在Prompt中注入最新文檔來解決。

最后，Prompt過于模糊，也會影響輸出的質(zhì)量。

例如跟「大象」說：

幫我寫個好看的網(wǎng)頁。

因此，在用「大象」的時候，我們還需切記，Prompt一定要細致、要有足夠的約束力。

Agent 時代，“快、好、省”的小模型同樣重要

其實，在這個時間節(jié)點發(fā)布這樣一款主打智效比的模型，本身就是一種信號。

過去幾年時間里，AI圈似乎都在比拼誰的模型更大、誰的訓(xùn)練成本更貴、誰在榜單上刷的分更高。

但行業(yè)走到今天，做加法的人太多了，需要有人站出來做減法。

因為Token浪費，已然成了行業(yè)高度重視的關(guān)鍵內(nèi)容之一。

《財經(jīng)》報道，全球企業(yè)級AI應(yīng)用中，約有50%的Token正在被浪費。AI應(yīng)用從對話轉(zhuǎn)向執(zhí)行后，Agent在復(fù)雜多輪任務(wù)中會不斷累積歷史文件、對話記錄，大量冗余信息導(dǎo)致Token消耗指數(shù)級增長。

每一塊錢都要花出響動，這是工程落地的鐵律。而踐行這條路線的，遠不止百靈。

就在前不久，OpenAI連續(xù)發(fā)布了GPT-5.4 mini和GPT-5.4 nano兩款小型模型，專為高頻且對延遲敏感的任務(wù)設(shè)計。它們在保持了GPT-5系列優(yōu)秀推理基因的前提下，實現(xiàn)了極高的吞吐量、極低的延遲和極具競爭力的性價比。

谷歌則通過開源小模型Gemma 4，以低成本、高推理力打入低端AI市場。Gemma 4的參數(shù)規(guī)模僅為同智力水平大模型的約二十分之一，過去需要花費上千萬GPU成本才能跑動的模型，現(xiàn)在大概一張高階顯卡就能跑得動，成本差距將近十倍。

尤其是對于預(yù)算有限、算力資源匱乏、追求極致投入產(chǎn)出比的中小企業(yè)而言，無需為冗余Token支付高額算力成本，無需采購昂貴硬件部署大模型，輕量化的「大象」就能無縫承接代碼開發(fā)、文檔處理、數(shù)據(jù)復(fù)盤、輕量Agent執(zhí)行等高頻剛需工作。

在動輒消耗幾十萬Token的長文本辦公場景中，響應(yīng)壓制在1秒內(nèi)、少說廢話的高效模型，正在成為AI從玩具跨越到生產(chǎn)力工具的堅實底座。

快、準、省，這三個看似接地氣的字眼，正在成為AI高效上崗的標準。