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