八個字就能說明白MoE是骨架推理是腦子多模態(tài)是五官。這不是什么嚴謹?shù)慕炭茣x而是我做了這么多年模型應(yīng)用之后覺得最不容易把人繞暈的類比。但問題恰恰出在——大多數(shù)人對這三個詞的認知是割裂的甚至把它們當成互斥的選項來討論。這個是MoE架構(gòu)所以它不是多模態(tài)那個模型會推理所以它一定不是稀疏架構(gòu)這種話我在不少技術(shù)群里見過每次看到都想嘆氣。今天這篇就把這事徹底捋清楚大模型的分類不是一個維度而是至少三個互相獨立的坐標系。搞懂這個你再去選型、讀論文、看各種模型榜單思路會清晰非常多。1. 三個概念各自回答一個不同的問題1.1 亂象的根源分類維度不同卻放在同一個天平上先做一個最簡單的思想實驗。你去問一個路人蘋果和橘子哪個更好吃他可能會猶豫。但你去問蘋果和水果刀哪個更好用他一定覺得你瘋了——因為一個能吃、一個能用根本不在同一個類比維度上?，F(xiàn)在很多人討論大模型干的就是這種蘋果對比水果刀的事情。MoE、推理模型、多模態(tài)這三個詞經(jīng)常出現(xiàn)在同一個投票帖、同一個選型表格、同一個評測榜單里好像它們是并列選項。但稍微想一下就知道MoE回答的是模型的內(nèi)部結(jié)構(gòu)長什么樣、參數(shù)怎么組織、算力怎么分配推理模型回答的是模型在回答問題之前要不要多想一會兒、能不能處理復(fù)雜邏輯任務(wù)多模態(tài)回答的是模型能吃進去什么類型的輸入、能吐出什么類型的輸出。一個是結(jié)構(gòu)問題一個是能力問題一個是接口問題。你說它們怎么并列之所以會有這種混亂是因為過去幾年模型的演進節(jié)奏太快。兩年前市面上絕大多數(shù)模型都是稠密結(jié)構(gòu)的通用文本模型一個詞就能概括全部特征到了現(xiàn)在DeepSeek V3是MoE但通用、DeepSeek R1是MoE且會推理、Qwen2.5-VL可能是稠密結(jié)構(gòu)但是多模態(tài)、Kimi k1.5又可能是多模態(tài)加推理的混合體。每個模型身上同時背著多個標簽如果底層分類邏輯不清楚看什么都像一鍋粥。1.2 一個簡單的分析框架從三個正交軸去看模型我在實際做技術(shù)選型和方案設(shè)計的時候習(xí)慣用三個獨立的軸去拆解任何一個大模型。這個方法沒有任何學(xué)術(shù)門檻就是一個工程判斷工具分類軸核心問題典型取值關(guān)注對象結(jié)構(gòu)軸模型內(nèi)部是全員激活還是部分專家激活稠密Dense、稀疏MoE顯存占用、推理吞吐、部署成本能力軸模型是否具備深度推理能力通用模型、推理模型復(fù)雜任務(wù)的準確率、思維鏈長度、錯誤修正能力模態(tài)軸模型支持哪些輸入輸出類型純文本、視覺語言、全模態(tài)業(yè)務(wù)場景的數(shù)據(jù)形態(tài)、接口設(shè)計這三個軸是正交的。意思是說你在任何一個軸上取了一個值都不影響你在其他軸上取值。一個模型可以同時是MoE結(jié)構(gòu) 推理能力 純文本輸入也可以同時是稠密結(jié)構(gòu) 普通能力 多模態(tài)輸入。這些組合都是真實存在的不是理論上硬湊的。這樣一拆你會發(fā)現(xiàn)以前很多糾結(jié)的問題變得特別簡單。比如我想部署一個本地多模態(tài)模型但顯存只有16G該選哪個本質(zhì)上是在「模態(tài)軸」上選多模態(tài)在「結(jié)構(gòu)軸」上盡量選參數(shù)量小的稠密模型或者小MoE模型兩個軸各查各的答案自然就出來了。接下來我按照結(jié)構(gòu)軸 → 能力軸 → 模態(tài)軸的順序把每個維度單獨講透最后再放到一起看真實世界里的組合案例。2. MoE模型內(nèi)部結(jié)構(gòu)的稀疏化改造2.1 稠密模型與稀疏模型的分界線先回到最基礎(chǔ)的概念。傳統(tǒng)的Transformer模型無論是GPT-3、Llama 2還是早期的ChatGLM它們的核心特點是前饋網(wǎng)絡(luò)FFN這一層里的所有參數(shù)在處理每個token時都會被激活。這種結(jié)構(gòu)叫稠密模型Dense Model。打個比方就像一家公司無論來的是什么需求所有員工都得參與處理一遍。稠密模型的優(yōu)點是想都不用想的——訓(xùn)練穩(wěn)定、推理邏輯簡單、生態(tài)工具成熟。但缺點也明擺著參數(shù)量一上去推理成本跟著爆炸。70B的稠密模型光權(quán)重就占140GB左右的顯存FP16精度每次前向傳播都要把全部參數(shù)過一遍。這就是為什么很長一段時間里開源社區(qū)能做7B、13B但能做70B以上的個人或小團隊屈指可數(shù)。MoEMixture of Experts混合專家把這個問題換了個解法。它的思路是我不需要所有參數(shù)同時參與計算我只需要讓一部分專家去處理特定的token。還是那家公司的類比MoE相當于把公司拆成了多個專業(yè)小組來了一個需求門控路由器Router先看一眼然后只把需求派給兩三個對口的專家組其他專家照常休息。什么是專家在MoE模型里一般就是把Transformer的FFN層復(fù)制若干份每一份就是一個專家前饋網(wǎng)絡(luò)。原來的一個FFN層變成了一組FFN層每個token只激活其中少數(shù)幾個。這樣做的直接效果是總參數(shù)量可以做得非常大但每次推理的實際計算量FLOPs只和激活的專家數(shù)量相關(guān)。2.2 路由機制、專家分工與負載均衡MoE聽起來簡單但讓它在工程上真正work有無數(shù)細節(jié)。最關(guān)鍵的是路由Routing機制。路由器的本質(zhì)是一個輕量級的線性層輸入是token的隱層表示輸出是每個專家的得分。在訓(xùn)練和推理的時候我們需要從這個得分分布里選出Top-K個專家通常K取1到4之間。但這個選擇是離散的沒法直接做梯度回傳所以主流做法是在訓(xùn)練時用軟路由所有專家都參與梯度計算來指導(dǎo)硬路由推理時只激活Top-K個的逐步逼近。然后是負載均衡。這絕對是MoE訓(xùn)練里最頭疼的問題之一。因為路由器完全自主學(xué)的話很快會發(fā)現(xiàn)某些專家特別強、用途廣于是大量token都往那幾個專家身上堆其他專家變成擺設(shè)。這就好比公司里兩三個骨干累到死其他人天天閑著——整體效率反而下降。業(yè)界應(yīng)對手段主要有幾個負載均衡損失在訓(xùn)練目標函數(shù)里加入一項懲罰讓路由器給每個專家的分配概率盡量均勻?qū)＜胰萘肯拗平o每個專家設(shè)定一個最大token處理上限超出部分走殘差連接跳過路由噪聲訓(xùn)練時給路由得分加一點高斯噪聲增加探索性讓模型不至于過早陷入少數(shù)專家壟斷的局面。還有一個在工程里容易被忽略的點共享專家Shared Expert的設(shè)計。像DeepSeek V3的MoE結(jié)構(gòu)里除了被路由的細粒度專家之外還加了一個始終被激活的共享專家負責(zé)吸收通用知識。這個設(shè)計明顯緩解了一個問題——如果沒有共享專家通用知識和專用知識都要靠路由去分配路由壓力大且容易導(dǎo)致專家職責(zé)重疊。你實際部署的時候不需要關(guān)心這些但理解它有助于你判斷一個MoE模型的參數(shù)量、激活量這些指標到底意味著什么。2.3 主流MoE模型與幾點選型心得現(xiàn)在開源生態(tài)里的MoE模型已經(jīng)不少了我列幾個有代表性的模型總參數(shù)量激活參數(shù)量專家數(shù)量說明Mixtral 8x7B46.7B12.9B8Top-2開源MoE的先行者DeepSeek V3671B37B256細粒度1共享Top-8當前開源MoE的性價比標桿Qwen3 MoE系列多檔位約1/4總參量各版本不同中文生態(tài)友好Grok系列數(shù)百B級約1/5總參量多專家閉源但公開了部分信息從使用者的角度MoE帶來的實際影響非常直接顯存占用看總參數(shù)因為所有專家權(quán)重都要加載到內(nèi)存里即使推理時只激活一部分。用FP16精度的DeepSeek V3權(quán)重也要1.3TB左右不是單卡能玩的必須上多機多卡或量化。推理速度看激活參數(shù)因為實際計算的FLOPs由激活參數(shù)決定。這就是為什么MoE模型總參數(shù)量很大但推理吞吐不一定比同級別稠密模型差的原因。量化MoE要小心專家之間有負載不均衡問題量化誤差在某些專家上可能被放大最好用針對MoE設(shè)計的量化方案而不是直接套稠密模型的量化腳本。3. 推理模型從快答到慢想的范式轉(zhuǎn)變3.1 推理模型到底改變了什么如果說MoE是在模型骨架上做文章那么推理模型就是在使用范式上做文章。這兩者完全不沖突但經(jīng)常被放在一起比較——這是我看到的最常見的誤區(qū)之一。普通的大模型不管它是稠密還是MoE是怎么回答問題的你輸入一個問題模型看一眼然后立刻按照已經(jīng)學(xué)到的概率分布一個token一個token地把答案生成出來。這個過程中模型在第一直覺上做反應(yīng)生成的內(nèi)容是相當快的。對于給我寫一封請假郵件總結(jié)這段文字這類任務(wù)這種快很合理答案質(zhì)量也確實夠用。但碰到復(fù)雜問題呢比如數(shù)學(xué)競賽題、邏輯推理題、多步規(guī)劃的編程題第一直覺往往不夠用。人怎么解決復(fù)雜問題會先打個草稿列幾個思路發(fā)現(xiàn)路徑不對再折返最后正式作答。推理模型要做的就是把打草稿這件事也交給模型做。最核心的機制是推理時擴展Inference-Time Scaling。傳統(tǒng)的模型訓(xùn)練完成后你在推理時的計算量是固定的——生成多少token就是多少計算。而推理模型會在正式回答前內(nèi)部先生成一段很長的思維鏈Chain of Thought模型在這條思維鏈里嘗試多種解法、發(fā)現(xiàn)錯誤、自我修正最后才給出最終答案。代價是什么肉眼可見的是變慢。你問一個普通模型問題幾秒鐘出結(jié)果問推理模型可能十幾秒甚至幾分鐘。用戶感知的慢其實是模型在內(nèi)部悄悄做了大量額外推理。所以我也經(jīng)常跟團隊說不要把推理模型當默認選擇——只有任務(wù)復(fù)雜度配得上那段思維鏈的時候才值得為之付出延遲。3.2 推理能力是怎么訓(xùn)練出來的推理模型不是改一下推理階段的參數(shù)就能得到的它的關(guān)鍵在于訓(xùn)練方法的變革。目前業(yè)界主流路線可以分三個階段看第一個階段是冷啟動的SFT。為了讓模型產(chǎn)生高質(zhì)量的思維鏈先用人工標注或者用強模型蒸餾出的長思維鏈數(shù)據(jù)做監(jiān)督微調(diào)。這個階段解決的是模型會不會輸出思維鏈的問題。第二個階段是大規(guī)模強化學(xué)習(xí)。這是推理模型和普通模型最根本的分水嶺。普通模型微調(diào)終點通常是交叉熵損失盡可能低推理模型則在SFT之后繼續(xù)做強化學(xué)習(xí)獎勵信號不是一句接得好不好而是規(guī)則可驗證的結(jié)果——比如數(shù)學(xué)題答案是否數(shù)值正確、代碼能否通過測試用例。模型在強化學(xué)習(xí)中不斷試錯逐漸學(xué)會在復(fù)雜問題上花更多時間思考學(xué)會了自我糾錯。第三個階段是推理時策略的優(yōu)化。一些更新的模型開始引入以思考長度換取精度的動態(tài)機制模型可以根據(jù)問題難度自己決定要多長思維鏈。這就是慢思考的由來。了解這些之后你再看這個模型是不是推理模型就有了判斷依據(jù)推理模型一般都有專門的長思維鏈訓(xùn)練階段而且往往在數(shù)學(xué)、代碼等規(guī)則可驗證的任務(wù)上特別強。這不是隨便在普通模型上加個Lets think step by step提示詞能模擬的——提示詞只能喚起模型在預(yù)訓(xùn)練階段見過的一些推理樣例質(zhì)量和穩(wěn)定性都不如專門訓(xùn)練出來的推理模型。3.3 市面上常見的推理模型與辨別指南現(xiàn)在你能接觸到的推理模型已經(jīng)挺多了。OpenAI的o1、o3系列是最早帶火這個概念的產(chǎn)品開源社區(qū)里DeepSeek R1絕對是一個里程碑它證明了用強化學(xué)習(xí)讓開源模型獲得強推理能力是可行的之后QwQ、Kimi k1.5、GLM-Z1、以及各種基于R1蒸餾出來的小參數(shù)推理模型也層出不窮。如何辨別一個模型屬不屬于推理模型我的經(jīng)驗是看三個信號官方文檔或模型卡的訓(xùn)練說明。明確提到長思維鏈、強化學(xué)習(xí)、推理時擴展這些字眼的基本就是API的支持參數(shù)。推理模型一般都有控制思考長度的字段或者response中會額外返回reasoning_content這樣的字段普通模型沒有任務(wù)表現(xiàn)特征。在數(shù)學(xué)競賽、復(fù)雜代碼題上表現(xiàn)明顯好于同規(guī)模普通模型但簡單任務(wù)上速度反而偏慢。這里要特別提醒一下因DeepSeek R1走紅之后市面上出現(xiàn)了一堆蒸餾出來的推理模型。正規(guī)蒸餾當然是有效的——比如用R1生成大量思維鏈數(shù)據(jù)去微調(diào)一個小模型小模型確實能繼承一部分推理能力。但有些所謂的推理模型就是在普通模型之上套了個提示詞模板讓它假裝慢思考實際并沒有專門訓(xùn)練過。怎么區(qū)分看它生成的思維鏈是不是真的在自我糾錯還是只是在重復(fù)已知信息。前者會有這里可能有問題我重新檢查一下這樣的內(nèi)部對話后者一眼就能看出來是流水賬。4. 多模態(tài)輸入與輸出接口的擴展4.1 多模態(tài)的模態(tài)到底指什么第三個維度離普通用戶最近也最容易造成概念混亂。很多非技術(shù)背景的人一聽到多模態(tài)就以為是一個更高級的大模型——很多廠商也確實這么宣傳好像多模態(tài)是模型的某種超能力標簽。但從工程角度看多模態(tài)就是一件非常樸素的事情模型能處理的信號類型更多了。純文本模型能讀能寫的只有token。你給它一張圖片它看到的只是一串二進制字節(jié)無法理解圖片里的內(nèi)容。多模態(tài)模型做的事情本質(zhì)上是在輸入端加感官、在輸出端加表達方式。具體拆開看視覺-語言模型VLM能讀文字加圖片比如GPT-4V、Qwen-VL系列、Llama 3.2 Vision、InternVL音頻輸入模型能聽錄音、識別語音意圖比如Qwen-Audio、Gemini系列視頻理解模型能讀懂視頻幀序列的內(nèi)容這在當前多模態(tài)領(lǐng)域是推進最快的方向之一生成類多模態(tài)不僅讀多種模態(tài)還能輸出圖像、音頻、視頻比如Sora、可靈、Veo系列。注意多模態(tài)是一個接口范圍的描述不是模型能力的評價。一個支持圖片輸入的模型在純文本推理能力上未必比同規(guī)模的純文本模型強甚至因為視覺編碼器占用了參數(shù)空間文本能力可能被削弱。這也是為什么很多實際項目里寧可分別用一個純文本模型做復(fù)雜邏輯處理 一個視覺模型做OCR提取也不硬上一個多模態(tài)模型因為分工更明確、效果更可控。4.2 多模態(tài)模型的兩種主流技術(shù)路線理解多模態(tài)最重要的是理解它跟文本模型的關(guān)系。目前主流技術(shù)路線可以分成兩大類。拼接式Modular / Adapter-based。這種做法以LLaVA為代表保留一個完整的文本大模型作為大腦在前端接一個視覺編碼器比如CLIP的ViT把圖片編碼成視覺token再通過一個投影層Projector把視覺token映射到文本模型的語義空間里。圖片進來之后視覺token和文本token被拼接到一起文本模型照常做自回歸生成。這種路線的核心是讓模型學(xué)會看圖——訓(xùn)練時凍結(jié)文本模型的大部分參數(shù)只訓(xùn)練投影層和視覺編碼器通過大量圖文對數(shù)據(jù)把兩者的語義空間對齊。優(yōu)點是工程上簡單視覺部分和語言部分可以獨立迭代優(yōu)化實驗成本低。缺點是視覺信息經(jīng)過投影層的壓縮之后可能有損失模型對圖片細節(jié)的感知能力不如對文字的敏感度高。原生式Native / Unified。這種路線更激進它從一開始就不分文本engine和視覺engine而是把所有模態(tài)統(tǒng)一成一種token表示放進同一個Transformer里訓(xùn)練。Gemini系列的底層思路、以及各種以統(tǒng)一分詞器為核心的模型走的就是這條路線。優(yōu)點是模態(tài)間融合得更自然模型可以在視覺和文本交叉的任務(wù)上做更靈活的推理缺點是訓(xùn)練數(shù)據(jù)要求極高、工程復(fù)雜度大不是一般團隊能做到的。如果你只是調(diào)用API或者部署開源模型不需要關(guān)心內(nèi)部到底走哪條路。但如果你要做微調(diào)或者二次開發(fā)就必須搞清楚你的模型屬于哪一種因為微調(diào)策略完全不同拼接式模型微調(diào)時通常還是要凍結(jié)視覺編碼器只動投影層和語言層的LoRA原生式模型則可以嘗試在多模態(tài)數(shù)據(jù)上統(tǒng)一做LoRA。4.3 多模態(tài)與MoE、推理模型的關(guān)系我見過的最大誤區(qū)就是有人把多模態(tài)和MoE當成對立選項其實它們根本不是一個維度。多模態(tài)描述的是輸入輸出的接口范圍MoE描述的是模型的內(nèi)部結(jié)構(gòu)。一個多模態(tài)模型完全可以是MoE架構(gòu)——事實上目前很多主流產(chǎn)品就是比如Gemini 1.5 Pro采用了MoE架構(gòu)同時支持圖片、音頻、視頻輸入Qwen2.5-Omni也把多模態(tài)編碼器和MoE結(jié)構(gòu)結(jié)合在了一起。同樣多模態(tài)和推理模型也不沖突。新一代的推理模型已經(jīng)在往多模態(tài)方向擴展——比如能看圖解題的推理模型輸入一張幾何題圖片輸出一步一步的推導(dǎo)過程。這種模型同時占據(jù)了能力軸的推理位置和模態(tài)軸的多模態(tài)位置。別被市場上的標簽宣傳帶偏多模態(tài)不是模型等級的象征它只是一個能力維度的標記。5. 正交坐標系下的真實產(chǎn)品拆解5.1 用三維框架看幾個實際模型理論講了這么多現(xiàn)在放到真實世界的模型身上驗證一下。我用三個維度給幾個代表性模型打標簽?zāi)愀惺芤幌逻@種拆解方式有多清晰模型結(jié)構(gòu)軸能力軸模態(tài)軸Llama 3.1 8B稠密通用純文本Mixtral 8x7BMoE通用純文本Qwen2.5-VL 7B稠密通用視覺語言DeepSeek V3MoE通用純文本DeepSeek R1MoE推理純文本GPT-4o官方未公開推測含MoE通用全模態(tài)o1 / o3系列官方未公開推理純文本視覺輸入Gemini 2.0系列混合含MoE通用推理混合全模態(tài)Kimi k1.5官方未公開推理視覺語言推理這張表一下子就能說明問題每個模型其實是三維空間里的一個點標簽跟標簽之間是組合關(guān)系不是互斥關(guān)系。比如你在用DeepSeek R1你說它是MoE模型沒錯說它是個推理模型也對說它是個文本模型還是對——只是這三個判斷分別回答的是三個不同的問題。5.2 為什么同一款產(chǎn)品在不同榜單里定位完全不同理解了三維拆解你就能看穿很多宣傳話術(shù)和榜單排名的障眼法了。有些榜單測的是通用對話能力上榜的自然是結(jié)構(gòu)軸能力軸綜合評分高的通用模型有些榜單測的是數(shù)學(xué)推理那推理模型肯定名列前茅有些榜單測的是視覺理解那純文本模型再強也上不了榜。不是模型變強或變?nèi)趿耸前駟卧谀貌煌某咦恿俊＿@就好比拿奔跑速度和游泳速度兩個指標去給運動員排名博爾特可能兩者都出色但你不能因為一個游泳健將沒進百米決賽就否定他。做選型的時候先搞清楚自己業(yè)務(wù)的核心瓶頸到底在哪個維度再去找對應(yīng)的尺子。5.3 三維拆解法在項目選型里的實際用法我在技術(shù)方案里經(jīng)常用一套非常樸素的選型流程分享出來供你參考。假設(shè)我要給一個實際業(yè)務(wù)選模型我會按下面順序走先確定模態(tài)軸。我的業(yè)務(wù)數(shù)據(jù)是什么形態(tài)是純文本、圖文混合、還是涉及音視頻這一步直接篩掉一大批不合適的模型縮小候選范圍。再確定能力軸。我的任務(wù)需要快答還是慢想如果90%的請求是簡單問答、信息抽取、格式整理通用模型就夠了硬上推理模型只會白白增加延遲和成本。如果任務(wù)涉及復(fù)雜數(shù)學(xué)運算、多步代碼生成、嚴謹邏輯推導(dǎo)再考慮推理模型。最后看結(jié)構(gòu)軸。這一步更多是部署層面的考量——我的GPU資源夠不夠需要的吞吐量多大如果是個人開發(fā)者、單卡16G顯存就別惦記數(shù)百B參數(shù)的大MoE了老老實實選個7B左右的稠密模型或者小規(guī)模的MoE量化版如果是企業(yè)級多卡集群則可以考慮大MoE用總參數(shù)換效果、用稀疏激活保吞吐。在剩余候選中做效果實測。這一步不能省榜單數(shù)據(jù)只能幫你初篩真實業(yè)務(wù)里的數(shù)據(jù)分布跟公開評測集往往差距很大。6. 常見誤區(qū)自查清單6.1 六個高頻誤區(qū)你現(xiàn)在中了幾個誤區(qū)一MoE不如稠密模型。有些人覺得MoE是偷懶的做法用一堆小專家湊數(shù)。實際訓(xùn)練得當?shù)腗oE效果是能超過同激活參數(shù)量的稠密模型的因為總參數(shù)量大了知識容量上限更高。誤區(qū)二推理模型就是更聰明的模型。推理模型在復(fù)雜任務(wù)上確實表現(xiàn)更強但在簡單任務(wù)上它可能因為想太多而答錯且延遲高、成本高。我實際測試過讓推理模型做11等于幾它有時候會因為過度懷疑自己而給出一個莫名其妙的答案。誤區(qū)三多模態(tài)模型的文本能力一定更強。完全相反很多多模態(tài)模型因為要在視覺數(shù)據(jù)上分配訓(xùn)練預(yù)算純文本能力反而不如同參數(shù)量的純文本模型。想用多模態(tài)模型做大段文本的深度分析很可能失望。誤區(qū)四本地部署大模型一定要選MoE。MoE省的是推理計算量不省顯存。你本地一臺16G顯存的機器跑7B稠密模型很舒服跑一個總參數(shù)量46B的Mixtral 8x7B就算量化到4bit也夠嗆。誤區(qū)五只要API支持傳圖片就是多模態(tài)模型。嚴格說很多文本模型是通過外部OCR工具把圖片轉(zhuǎn)成文字再處理的你傳圖片它也能看懂一些內(nèi)容但這不叫多模態(tài)。真正的多模態(tài)是圖片以視覺token形式進模型而不是圖片先被外部工具轉(zhuǎn)成文本。誤區(qū)六推理模型會逐漸取代通用模型。至少在成本和延遲大幅下降之前不會。實際業(yè)務(wù)里絕大多數(shù)請求都是低難度任務(wù)通用模型的性價比遠高于推理模型。未來的方向大概率是系統(tǒng)層面做路由——簡單問題走通用模型復(fù)雜問題走推理模型而不是單一模型通吃。6.2 拿一個新模型時我建議你先問自己五個問題你新拿到一個模型或者看到一篇新的模型發(fā)布公告不要急著跑benchmark。以下五個問題問完你對它的認知就已經(jīng)超過80%的圍觀群眾了它的總參數(shù)量和激活參數(shù)量分別是多少判斷結(jié)構(gòu)軸稠密還是MoE、規(guī)模多大它是否有專門的思維鏈/強化學(xué)習(xí)訓(xùn)練階段判斷能力軸通用還是推理它原生支持哪些輸入和輸出類型判斷模態(tài)軸純文本、視覺、音頻、視頻官方文檔里部署時的顯存推薦是多少倒推模型的真實部署成本它是從頭訓(xùn)練的還是從某個基座微調(diào)/蒸餾來的判斷創(chuàng)新含量蒸餾模型和基座模型差距很大6.3 一個我自己的踩坑經(jīng)歷最后講一個真實踩過的坑。之前接了一個項目客戶要求模型能讀合同截圖并給出風(fēng)險提示。我當時圖省事直接選了一個很火的全模態(tài)模型因為它宣傳圖片視頻音頻全能我心想既然圖片能讀那合同掃描件肯定沒問題。結(jié)果一到現(xiàn)場就翻車了。合同圖片里大量密集的小字號條款文字普通多模態(tài)模型的視覺編碼器根本認不全經(jīng)常漏字、錯字給出的風(fēng)險提示自然也不可靠。后來我換了個思路先用專門的OCR模型把合同圖片轉(zhuǎn)成結(jié)構(gòu)化文本再用一個純文本的通用模型做條款分析。效果立竿見影錯誤率直接降了一個數(shù)量級。這個案例完美說明了三維拆解法的重要性。我當時只盯著模態(tài)軸看覺得支持圖片輸入就夠了卻忽略了一個事實多模態(tài)支持的是看圖不等于識文。復(fù)雜場景里單模態(tài)的專業(yè)工具往往比多模態(tài)的通才更可靠。這也是我現(xiàn)在給所有團隊的建議選型的時候不要被全能兩個字沖昏頭腦先搞清楚三個軸各自的需求再把每個軸用最合適的方案填上最后組合起來。模型選型不是選一個最貴的而是選一個最匹配的。