如果你最近在搭 AI 工具、調(diào)試提示詞或者被領(lǐng)導(dǎo)點(diǎn)名研究大模型那你大概率已經(jīng)見過這幾個(gè)詞Token、上下文窗口、Temperature、MoE。說實(shí)話我剛帶項(xiàng)目那會(huì)兒這四個(gè)詞也讓我繞了不少彎子以為 Token 就是字?jǐn)?shù)結(jié)果第一次對(duì)賬賬單比心理預(yù)期高了一截以為上下文窗口越大越省心結(jié)果塞了一堆聊天記錄進(jìn)去模型該忘的還是忘Temperature 更邪門同一個(gè)問題0.3 和 1.2 能給出兩個(gè)物種的回答。至于 MoE第一次聽人介紹總參數(shù) 47B、激活參數(shù) 13B的時(shí)候我差點(diǎn)以為對(duì)方在說繞口令。這篇就把這四個(gè)概念一次講透。我盡量不堆論文術(shù)語用做產(chǎn)品、調(diào)接口、部署模型時(shí)真正會(huì)用到的視角來講把背后的原理、估算方式、踩坑點(diǎn)都攤開。它適合正在用 API 做應(yīng)用、準(zhǔn)備私有化部署、或者想從會(huì)調(diào)用跨到懂原理的朋友。不管你是只想把接口調(diào)好還是要自己部署模型這四個(gè)概念都會(huì)直接影響你的效果、成本和穩(wěn)定性。1. 先建立整體認(rèn)知大模型到底是個(gè)什么機(jī)器1.1 大模型不是查資料是猜下一個(gè)詞很多人以為大模型像個(gè)超級(jí)搜索引擎問它問題它就去數(shù)據(jù)庫里把答案檢索出來。實(shí)際完全不是這樣。大模型本質(zhì)上是一個(gè)條件概率預(yù)測(cè)器給它一段文本它預(yù)測(cè)接下來最可能出現(xiàn)的 token 是什么預(yù)測(cè)完一個(gè)把這個(gè) token 接到原文后面再預(yù)測(cè)下一個(gè)。整個(gè)對(duì)話過程其實(shí)就是模型在源源不斷地接龍。這個(gè)機(jī)制解釋了很多奇怪現(xiàn)象。比如它為什么能寫代碼因?yàn)橛?xùn)練數(shù)據(jù)里有海量代碼模型學(xué)會(huì)了看到 if 后面一般接什么它為什么偶爾會(huì)一本正經(jīng)地胡說八道因?yàn)樗举|(zhì)上是在說這個(gè)位置最像真的答案是這句而不是在數(shù)據(jù)庫里驗(yàn)證過。我經(jīng)常跟同事開玩笑大模型不是一個(gè)記憶力超群的好學(xué)生而是一個(gè)看過無數(shù)范文、特別擅長(zhǎng)續(xù)寫的老手。理解這一點(diǎn)至關(guān)重要。因?yàn)楹竺嫠懈拍睢舷挛拇翱?、Temperature、MoE——都是在回答同一個(gè)問題的不同側(cè)面這個(gè)接龍機(jī)器用什么原料、能看多遠(yuǎn)、有多大膽、內(nèi)部怎么分工。1.2 把四個(gè)概念放進(jìn)一條流水線里看我給團(tuán)隊(duì)做培訓(xùn)的時(shí)候喜歡把這四個(gè)概念串成一條流水線Token 是原料。大模型不直接讀字它把文本切成 token 再處理所以 token 的數(shù)量直接決定成本和長(zhǎng)度。上下文窗口是工作臺(tái)。工作臺(tái)就那么大一次能攤開的原料有限。你塞進(jìn)來的東西越多它當(dāng)下能看到的內(nèi)容越多但臺(tái)面會(huì)被占滿。Temperature 是操作員的性格。同樣一堆原料保守的操作員永遠(yuǎn)只選最有把握的做法激進(jìn)的操作員時(shí)不時(shí)會(huì)嘗試點(diǎn)新花樣。MoE 是車間架構(gòu)。有的工廠是一個(gè)全能班組干所有活有的工廠是前臺(tái)把單子分給各個(gè)專業(yè)班組MoE 就是后者的自動(dòng)化版本。這四條線不是孤立的。比如你把上下文窗口頂滿又調(diào)高了 Temperature模型很可能因?yàn)榭吹枚?、想法多而開始跑題你讓 MoE 模型的某個(gè)專家長(zhǎng)期空閑微調(diào)后模型反而可能變傻。后面每一節(jié)我都會(huì)穿插這種關(guān)聯(lián)幫大家建立整體感而不是背幾個(gè)孤立定義。2. Token大模型的字?jǐn)?shù)統(tǒng)計(jì)到底怎么算2.1 為什么大模型不按漢字計(jì)數(shù)如果你在文檔里看到本模型上下文長(zhǎng)度 8K這里的 8K 指的是 token 數(shù)不是字?jǐn)?shù)。分詞器Tokenizer會(huì)把自然語言切分成模型認(rèn)識(shí)的最小單位。英文里一個(gè)常見單詞通常是一個(gè) token比如 hello 是一個(gè) token中文里因?yàn)樾畔⒚芏雀咭粋€(gè)漢字常用 1 到 1.5 個(gè) token生僻字還可能有特殊拆分。我剛開始也很不解中文一個(gè)字明明表意完整為什么要拆因?yàn)榇竽Ｐ偷脑~表不是按人類字典設(shè)計(jì)的而是通過 BPE字節(jié)對(duì)編碼這類算法從訓(xùn)練語料里統(tǒng)計(jì)出來的高頻片段。代碼里的常見關(guān)鍵字、英文常見詞綴、中文里的常用字和詞都會(huì)成為獨(dú)立的 token。所以同樣內(nèi)容中英文表達(dá)的 token 數(shù)往往不一樣同一句話換一個(gè)模型的分詞器token 數(shù)也可能有偏差。這里給一個(gè)粗略估算標(biāo)準(zhǔn)雖然不是官方精確值但足夠支撐日常評(píng)估不同模型的分詞器有差異但偏差不會(huì)太夸張中文文本1 個(gè)漢字約等于 1 至 2 個(gè) token常用字你、的、是通常是 1 個(gè) token。英文文本1 個(gè)單詞約等于 1 至 1.3 個(gè) token。代碼文本常見關(guān)鍵字會(huì)合并token 效率通常比自然語言高1 行簡(jiǎn)單代碼約 3 至 6 個(gè) token。比如一段 1000 字的中文產(chǎn)品介紹按 1.5 估算就是 1500 token 左右。如果模型按輸入 token 計(jì)費(fèi)那成本心里就有數(shù)了。提示做需求評(píng)估時(shí)用中文按 1.5 token/字、英文按 1.2 token/詞估算基本不會(huì)出大錯(cuò)。真要精確還是得用對(duì)應(yīng)模型的分詞器把文本跑一遍。2.2 Token 數(shù)量決定賬單輸入輸出都要算錢大模型計(jì)費(fèi)、限流、上下文限制全都圍繞 token 展開。一次 API 調(diào)用花的錢大致是費(fèi)用 輸入 token 數(shù) × 輸入單價(jià) 輸出 token 數(shù) × 輸出單價(jià)這里有兩件事必須注意。第一很多產(chǎn)品輸入和輸出 token 的價(jià)格不一樣通常是輸出更貴因?yàn)樯墒且粋€(gè) token 一個(gè) token 地推理比并行處理輸入要更耗算力。第二多輪對(duì)話時(shí)每一次新請(qǐng)求都會(huì)把之前的聊天記錄全部拼進(jìn)輸入里重新計(jì)算不會(huì)因?yàn)樯洗嗡氵^就便宜。所以對(duì)話輪次越多你其實(shí)在反復(fù)為那些舊消息付費(fèi)。我?guī)团笥炎鲞^一次調(diào)用量估算一個(gè)客服機(jī)器人平均每輪請(qǐng)求消耗 1200 個(gè)輸入 token、300 個(gè)輸出 token一天 1 萬次調(diào)用那么一天輸入消耗就是 1200 萬 token、輸出消耗是 300 萬 token。按常見的輸入百萬 token 幾十元、輸出百萬 token 上百元的價(jià)位一天幾百到上千元很正常。很多團(tuán)隊(duì)看到賬單才反應(yīng)過來省 token 就是省錢而且是最直接的成本優(yōu)化手段。2.3 壓縮 Token 的幾個(gè)立竿見影的手段我在項(xiàng)目里壓 token 的體感非常明顯。最常用的幾條把固定不變的說明放到 system 提示詞里并且盡量寫短。能一句話說清的就不要用兩句話。少樣本示例只保留最典型的 1 至 2 個(gè)。很多人一上來貼 5 個(gè)例子效果沒提升多少token 卻翻倍。多輪對(duì)話做歷史壓縮。當(dāng)聊天記錄快滿時(shí)讓模型先把前面的內(nèi)容總結(jié)成 100 字以內(nèi)的摘要再帶著摘要繼續(xù)聊而不是原樣搬運(yùn)所有消息。批處理任務(wù)把公共字段名、公共背景寫成一段常量在請(qǐng)求時(shí)直接引用避免每次拼重復(fù)文本。我自己做過一個(gè)日志分析工具最初把字段說明和示例貼在 prompt 里每次調(diào)用要 2200 個(gè) token后來抽成公共配置加摘要降到 900 個(gè) token。功能沒降單次成本直接省了六成。在這種基礎(chǔ)細(xì)節(jié)上多摳一摳比單純換個(gè)便宜模型來得更實(shí)在。3. 上下文窗口大模型的工作臺(tái)就那么大3.1 輸入和輸出共用一個(gè)窗口先搞清這件事上下文窗口是指模型單次能看到的最大 token 數(shù)量。很多人誤以為 8K 窗口就是能輸入 8K、再輸出 8K實(shí)際是輸入和輸出加在一起不超過 8K。你 prompt 寫了 7000 token那么模型最多只能生成 1000 token 的回復(fù)。這個(gè)誤解造成的典型事故是輸出截?cái)嗑渥油Ｔ诎肼房雌饋硐衲Ｐ屯蝗簧盗?。窗口?nèi)的信息也不是一視同仁的。實(shí)驗(yàn)和實(shí)戰(zhàn)都有一個(gè)共同觀察模型對(duì)開頭和結(jié)尾的內(nèi)容把握最好對(duì)埋在中間的大段內(nèi)容容易忽略研究者管這叫 lost in the middle。我做長(zhǎng)文檔問答的時(shí)候把關(guān)鍵結(jié)論放在文檔末尾反而經(jīng)常被漏掉放在對(duì)話末尾或者開頭顯著位置準(zhǔn)確率立刻上來了。這塊工作臺(tái)不但有物理限制還有個(gè)注意力偏心的問題。3.2 窗口用完了怎么辦5 個(gè)能立刻落地的方案這個(gè)問題我?guī)缀趺看畏窒矶紩?huì)被問到。我的默認(rèn)處理順序是這樣的換更長(zhǎng)的窗口。現(xiàn)在很多模型宣稱支持 100K、200K 甚至 1M 窗口適合偶爾處理超大文檔。但注意長(zhǎng)窗口不一定便宜也不一定真能記那么牢。做歷史摘要。對(duì)話類場(chǎng)景最推薦超過閾值就觸發(fā)請(qǐng)先總結(jié)前面內(nèi)容把舊消息替換成摘要繼續(xù)對(duì)話既保住重要信息又穩(wěn)定控制 token。上 RAG。把大段資料切塊存入向量庫每次只檢索與本次問題最相關(guān)的幾段塞進(jìn)窗口而不是在每次對(duì)話里硬塞整本書。拆任務(wù)。長(zhǎng)文檔一次性問不了就按章節(jié)分批提問再把各批次結(jié)果匯總給模型做二次分析。明確告訴模型只根據(jù)最近 N 輪回復(fù)并在代碼里裁掉更早的消息。簡(jiǎn)單粗暴但很有效。我一直強(qiáng)調(diào)窗口更像辦公桌而不是倉庫。你要做的是把最常用的東西擺在桌面上其余放回抽屜外置知識(shí)庫而不是不停地?fù)Q更大的桌子。3.3 長(zhǎng)窗口沒有那么神選型前先做壓力測(cè)試有些朋友一看到支持 200K 上下文立刻把整個(gè)項(xiàng)目文檔塞進(jìn)去。實(shí)測(cè)下來往往發(fā)現(xiàn)響應(yīng)變慢、成本升高但關(guān)鍵內(nèi)容還是可能丟。原因是長(zhǎng)文本對(duì)注意力機(jī)制的計(jì)算壓力很大位置編碼也要處理超長(zhǎng)序列很多模型的有效長(zhǎng)度其實(shí)低于宣傳值。我在給項(xiàng)目選型時(shí)做過一次土味壓力測(cè)試把一篇 5 萬字的技術(shù)文檔放在不同位置連續(xù)問 20 個(gè)問題看哪些信息能穩(wěn)定答對(duì)。結(jié)果很說明問題即便用長(zhǎng)窗口模型埋在文檔中間的問題依然容易答錯(cuò)。所以選模型不要只盯著宣傳頁上的最大窗口要看它在你自己數(shù)據(jù)上的實(shí)際表現(xiàn)。至少準(zhǔn)備一套和業(yè)務(wù)相近的測(cè)試集跑一輪再?zèng)Q定。4. Temperature讓模型按部就班還是天馬行空4.1 一個(gè)公式看懂 Temperature 在改什么大模型每生成一個(gè) token都會(huì)給詞表里每個(gè)候選算一個(gè)分?jǐn)?shù)logit然后用 softmax 變成概率分布。Temperature 就是在這個(gè)環(huán)節(jié)介入的先把每個(gè) logit 除以 T再做 softmax。P(token_i) exp(logit_i / T) / Σ exp(logit_j / T)T 等于 1 時(shí)是原樣輸出T 小于 1 會(huì)讓原先的高分候選概率更高、低分候選概率更低模型變得派系分明更保守T 大于 1 則把概率抹平低分候選也有機(jī)會(huì)冒頭輸出就跳躍、更有創(chuàng)造力。舉個(gè)例子。假設(shè)某位置上三個(gè)候選詞的原始概率是 0.8、0.15、0.05。T 調(diào)到 0.2 后第一個(gè)候選接近 1.0幾乎穩(wěn)贏T 調(diào)到 1.2 后第二個(gè)、第三個(gè)候選被選中的概率明顯上升回答就開始飄了。這也是為什么同一個(gè) prompt 在 T0.3 和 T1.3 下結(jié)果像兩個(gè)人寫的。4.2 按任務(wù)類型調(diào) Temperature代碼、對(duì)話、創(chuàng)作各有各的檔位我平時(shí)調(diào)參的出發(fā)點(diǎn)不是找最聰明的值而是這個(gè)任務(wù)允不允許出錯(cuò)。任務(wù)類型推薦 Temperature原因代碼生成、SQL 編寫0 至 0.3代碼錯(cuò)了就是錯(cuò)了需要確定性和可復(fù)現(xiàn)性數(shù)學(xué)、數(shù)據(jù)抽取、JSON 輸出0 至 0.2必須嚴(yán)格從原文提取不能自由發(fā)揮通用對(duì)話、文案草稿0.7 至 0.9保留一點(diǎn)變化又不太容易跑偏頭腦風(fēng)暴、故事創(chuàng)作1.0 至 1.3需要模型跳出常規(guī)適當(dāng)冒一點(diǎn)險(xiǎn)技術(shù)翻譯0.3 以下術(shù)語要穩(wěn)不能每輪譯法不一樣需要提醒的是很多 API 不允許把 Temperature 設(shè)為 0最小值可能是 0.01 或 0.1目的就是防止完全鎖死。另外別只看 Temperature服務(wù)端的采樣實(shí)現(xiàn)、隨機(jī)種子、beam search 都會(huì)影響確定性。做自動(dòng)化測(cè)試時(shí)最好把 max_tokens、Top-p 一起固定才能比較出參數(shù)變化帶來的真實(shí)差異。4.3 和 Top-p、Top-k 搭配別同時(shí)開兩個(gè)腦洞閥門除了 Temperature你還會(huì)在 API 文檔里看到 Top-p 和 Top-k。Top-k 是只從前 k 個(gè)最高分候選里選Top-p 是不斷往候選池里加 token直到累計(jì)概率超過 p。它們和 Temperature 是同一件事的三種旋鈕都是控制候選池和池內(nèi)的傾向性。我的建議是先固定 Top-p 在 0.9 左右保留大部分高概率候選、裁掉長(zhǎng)尾再單獨(dú)調(diào) Temperature。盡量不要一邊把 Temperature 調(diào)高一邊把 Top-p 也放寬到 0.98 以上兩個(gè)腦洞閥門同時(shí)打開輸出會(huì)很快滑向胡言亂語。反過來如果你要絕對(duì)穩(wěn)定就把 Temperature 調(diào)到最低Top-p 收緊到 0.8甚至可以固定隨機(jī)種子。5. MoE大模型界的專家會(huì)診模式5.1 什么是 MoE把大網(wǎng)絡(luò)拆成一群專家MoE 的全稱是 Mixture of Experts混合專家。它的核心思想是把模型內(nèi)部的一部分結(jié)構(gòu)通常是 FFN 層復(fù)制成多個(gè)專家子網(wǎng)絡(luò)再添一個(gè)路由器。輸入的一個(gè) token 不用經(jīng)過所有專家的手而是由路由器判斷這個(gè)問題更像哪類然后只激活 top 2 或者 top k 個(gè)專家。打個(gè)比方一個(gè)全能型公司每個(gè)部門都能處理所有客戶需求這是傳統(tǒng)的 Dense稠密模型MoE 則是前臺(tái)根據(jù)需求把單子分給對(duì)應(yīng)部門——法務(wù)問題找法務(wù)、技術(shù)問題找技術(shù)沒必要讓所有部門都參與進(jìn)來。訓(xùn)練的時(shí)候這些專家會(huì)自動(dòng)分化有的擅長(zhǎng)代碼有的擅長(zhǎng)數(shù)學(xué)有的擅長(zhǎng)中文表達(dá)。目前很多大模型都用了 MoE 架構(gòu)。你在開源社區(qū)里看到總參數(shù)量巨大但跑起來速度卻不像那么大的模型大概率就是 MoE。這也是為什么 MoE 越來越受關(guān)注在有限的算力預(yù)算里它可以塞進(jìn)更大的知識(shí)容量。5.2 總參數(shù) vs 激活參數(shù)MoE 到底省了什么MoE 最核心的兩個(gè)指標(biāo)是總參數(shù)和激活參數(shù)。總參數(shù)是權(quán)重文件占用的量激活參數(shù)是處理一個(gè) token 時(shí)真正參與計(jì)算的量。以開源社區(qū)常用的 Mixtral 8x7B 為例它由 8 個(gè) 7B 級(jí)別的專家組成加上共享部分總參數(shù)約 47B但因?yàn)槊總€(gè) token 只激活其中 2 個(gè)專家激活參數(shù)只有約 13B。這意味著推理時(shí)的計(jì)算量接近一個(gè) 13B 的密集模型但表達(dá)能力理論上能摸到比 13B 高不少的天花板。模型類型總參數(shù)激活參數(shù)推理算力顯存占用FP16Dense 13B13B13B全部計(jì)算約 26GBMoE 8x7B約47B約13B接近13B約94GB這張表能解釋一個(gè)常見誤解MoE 推理速度快但不代表它省顯存。所有專家的權(quán)重都得加載到內(nèi)存或顯存里只是每個(gè) token 不用全部算一遍。很多人第一次部署 MoE看到47B就以為和運(yùn)行一個(gè) 47B 的 Dense 模型一樣難。其實(shí)難點(diǎn)主要在于權(quán)重大、顯存占用高而不是計(jì)算量本身。想單卡跑起來通常要做量化比如 GGUF 的 Q4/Q8或者用多卡分流。5.3 部署和微調(diào) MoE三個(gè)容易踩的坑如果你不滿足于調(diào)用 API而是想本地私有化部署 MoE 模型有幾個(gè)坑我得提前幫你標(biāo)出來。第一推理框架要選對(duì)。用原版 Transformers 直接跑 MoE速度會(huì)很難看因?yàn)橥掏聝?yōu)化不到位。建議優(yōu)先用 vLLM、SGLang、TGI 這類對(duì) MoE 做過優(yōu)化的框架它們?cè)陲@存調(diào)度、專家并行上都有專門處理。第二顯存估算要按總參數(shù)算不能只看激活參數(shù)。量化的精度選擇需要權(quán)衡一般 Q4 量化在效果和資源占用之間最容易平衡。第三微調(diào)時(shí)留意專家失衡。如果你只用某一類垂直數(shù)據(jù)做微調(diào)路由器可能把所有 token 都分給同幾個(gè)專家其他專家長(zhǎng)期閑下來最后模型整體能力反而會(huì)下降。訓(xùn)練時(shí)最好開啟負(fù)載均衡損失或者保證微調(diào)數(shù)據(jù)的覆蓋面。MoE 不是一個(gè)開箱即用更強(qiáng)的銀彈。它適合預(yù)算有限、想把大模型能力塞進(jìn)已有推理服務(wù)的場(chǎng)景如果只是個(gè)人實(shí)驗(yàn)先跑 Dense 小模型把流程打通再切 MoE 會(huì)更穩(wěn)妥。6. 項(xiàng)目實(shí)戰(zhàn)中的排錯(cuò)速查與經(jīng)驗(yàn)沉淀6.1 高頻問題與對(duì)應(yīng)解法速查表把大家問得最多的問題和我的處理思路整理一下現(xiàn)象常見原因處理方法回答到一半突然斷了輸出 token 上限設(shè)得太小調(diào)大 max_tokens或壓縮 prompt 給輸出騰空間同樣問題每次答案差很多Temperature 偏高降到 0.2 以下必要時(shí)固定隨機(jī)種子多輪對(duì)話聊著聊著失憶上下文窗口被舊消息占滿開啟歷史摘要滾動(dòng)或換更長(zhǎng)窗口模型生成明顯跑題、放飛Temperature 和 Top-p 同時(shí)過高收斂參數(shù)T 降到 0.7 以內(nèi)Top-p 收到 0.9本地部署 MoE 后爆顯存按激活參數(shù)估算了顯存按總參數(shù)算權(quán)重占用改用量化或多卡賬單比預(yù)期高很多多輪歷史 token 反復(fù)計(jì)費(fèi)加日志統(tǒng)計(jì)每次調(diào)用的 token 數(shù)限制對(duì)話長(zhǎng)度6.2 三條最想帶走的實(shí)戰(zhàn)心得第一上線前先做小規(guī)模壓測(cè)。不要只測(cè)試能不能答對(duì)要測(cè)答對(duì)的時(shí)候花了多少 token、用了多長(zhǎng)窗口、隨機(jī)性有多大。把這三個(gè)值固化進(jìn)代碼里再調(diào)參否則你根本不知道效果變好是運(yùn)氣還是調(diào)參調(diào)出來的。第二給 prompt 和維護(hù)文檔加版本意識(shí)。我習(xí)慣在系統(tǒng)提示詞最前面寫一行注釋記錄這是第幾版、token 預(yù)算多少、上次修改的原因。等團(tuán)隊(duì)協(xié)作時(shí)這習(xí)慣會(huì)救命。第三新模型發(fā)布后別急著換。每次換模型都要重新驗(yàn)證上下文窗口的實(shí)際有效長(zhǎng)度、默認(rèn)參數(shù)、計(jì)費(fèi)模式。這三個(gè)東西變一個(gè)線上效果都可能變樣。這套心得是我在多個(gè)項(xiàng)目里反復(fù)踩坑換來的。技術(shù)文檔不會(huì)告訴你到底該怎么選只會(huì)給你一串參數(shù)范圍。我現(xiàn)在的習(xí)慣是遇到新模型先花半天把這四項(xiàng)都測(cè)一遍——token 估個(gè)價(jià)、窗口做壓力測(cè)試、Temperature 跑幾個(gè)溫度檔、MoE 的話再測(cè)一下顯存和吞吐然后才敢往線上放。這四個(gè)概念看著是基礎(chǔ)但基礎(chǔ)不打牢后期優(yōu)化寸步難行。