1. 先把體量賬算清楚端側(cè)設(shè)備的容量天花板在哪1.1 參數(shù)量、精度和文件大小的換算關(guān)系標(biāo)題里問(wèn)“端側(cè)本地模型放得下嗎”這問(wèn)題沒(méi)法用一句“能”或者“不能”回答因?yàn)椤澳Ｐ鸵?guī)模”和“能不能放下”之間隔著好幾層換算。很多人看到“XX億參數(shù)”就緊張其實(shí)先要搞懂一個(gè)最小單元一個(gè)參數(shù)在內(nèi)存里占多少個(gè)字節(jié)。同一個(gè)模型用不同精度存儲(chǔ)大小差得很遠(yuǎn)。FP32單精度浮點(diǎn)每個(gè)參數(shù)占 4 字節(jié)FP16半精度浮點(diǎn)每個(gè)參數(shù)占 2 字節(jié)INT88比特整數(shù)每個(gè)參數(shù)占 1 字節(jié)常見(jiàn)的 4bit 量化每個(gè)參數(shù)約 0.5 字節(jié)所以一個(gè) 10 億參數(shù)1B的模型原始 FP32 權(quán)重是 4GB轉(zhuǎn)成 FP16 是 2GB量化到 INT8 是 1GB再激進(jìn)一點(diǎn)壓到 4bit 只剩約 500MB。這個(gè)換算關(guān)系是整個(gè)話題的地基后面所有討論都建立在它上面。很多人只盯“文件大小”但真正決定能不能跑起來(lái)的是“運(yùn)行時(shí)峰值內(nèi)存”。權(quán)重文件能塞進(jìn)存儲(chǔ)不代表推理時(shí)能塞進(jìn)內(nèi)存。手機(jī) App 拿到一個(gè) 1GB 的模型文件加載時(shí)權(quán)重、激活值、KV Cache自回歸模型里的緩存、中間特征圖是同時(shí)在內(nèi)存里的實(shí)際占用往往是文件大小的 1.5 到 2 倍。1.2 端側(cè)設(shè)備的“三堵墻”存儲(chǔ)墻、內(nèi)存墻、算力墻判斷一個(gè)模型能不能本地跑要同時(shí)看三堵墻。第一堵墻是存儲(chǔ)。普通手機(jī)現(xiàn)在 128GB 起步空間看起來(lái)不缺但系統(tǒng)、照片、App 把空間瓜分完之后留給單個(gè)應(yīng)用離線模型包的往往只有幾個(gè) GB。嵌入式設(shè)備更緊張很多工業(yè)邊緣盒子存儲(chǔ)就是 8GB 或 16GB還要分一部分給日志和系統(tǒng)能放模型的區(qū)域非常有限。第二堵墻是內(nèi)存。這是最常被低估的。手機(jī)內(nèi)存看著有 12GB、16GB但操作系統(tǒng)、當(dāng)前 App、后臺(tái)進(jìn)程都在搶。一個(gè) App 能穩(wěn)定申請(qǐng)到的內(nèi)存很多時(shí)候只有 2GB 到 4GB。模型推理是內(nèi)存密集型操作峰值一沖上去輕則掉幀重則直接被系統(tǒng)殺掉。第三堵墻是算力。端側(cè) NPU/DSP 現(xiàn)在跑 CNN 這類結(jié)構(gòu)很擅長(zhǎng)但 Transformer 里的注意力矩陣、Softmax、Gelu 這類算子在不同芯片上的表現(xiàn)方差非常大。有些 NPU 對(duì)動(dòng)態(tài)形狀支持很差詞表檢索、beam search 這類操作可能根本加速不了。算力不夠模型就算裝得下推理速度也會(huì)讓人無(wú)法接受。1.3 端側(cè)模型常見(jiàn)的量級(jí)區(qū)間結(jié)合我實(shí)際做過(guò)和見(jiàn)過(guò)的設(shè)備大致有這么幾個(gè)舒適區(qū)模型量級(jí)FP16 大小INT8 大小4bit 量化后端側(cè)可行性100M0.1B200MB100MB50MB非常輕松任何設(shè)備都能跑300M0.3B600MB300MB150MB主流手機(jī)無(wú)壓力嵌入式需評(píng)估1B2GB1GB500MB手機(jī)上的上限區(qū)需配合優(yōu)化3B6GB3GB1.5GB高端機(jī)勉強(qiáng)普通設(shè)備吃力7B14GB7GB3.5GB基本告別普通端側(cè)除非特殊硬件所以“端側(cè)能不能放下”不是一個(gè)絕對(duì)概念。200M 級(jí)別的模型幾乎放哪都能跑1B 級(jí)別開始要精打細(xì)算再往上就屬于硬件專項(xiàng)定制范疇。有了這張尺子我們?cè)倩仡^量“萬(wàn)物識(shí)物”和“多語(yǔ)言翻譯”這兩個(gè)具體需求。2. “萬(wàn)物識(shí)物”的本質(zhì)為什么模型規(guī)模會(huì)失控2.1 從固定 1000 類到開放詞表任務(wù)定義改變了模型結(jié)構(gòu)傳統(tǒng)圖像分類模型比如大家熟悉的 ResNet、MobileNet 那套思路邏輯很簡(jiǎn)單圖片輸入網(wǎng)絡(luò)提取特征最后接一個(gè)全連接分類頭輸出神經(jīng)元個(gè)數(shù)等于類別數(shù)。你訓(xùn)練一個(gè) 1000 類模型分類頭就是 1000 個(gè)神經(jīng)元想識(shí)別 1 萬(wàn)類就把分類頭改成 1 萬(wàn)維。模型主體不動(dòng)動(dòng)的只是一個(gè)線性層。但“萬(wàn)物識(shí)物”的訴求完全不是這樣?，F(xiàn)實(shí)里的物體遠(yuǎn)遠(yuǎn)超出固定列表今天加一個(gè)品類、明天加一個(gè)品牌分類頭方案永遠(yuǎn)追不上。于是業(yè)界走向了開放詞表Open Vocabulary路線代表性的做法就是類 CLIP 的對(duì)比學(xué)習(xí)架構(gòu)一個(gè)圖像編碼器一個(gè)文本編碼器把圖片和文字映射到同一個(gè)向量空間通過(guò)計(jì)算圖像特征和文本特征之間的相似度來(lái)判斷“圖片里是什么”。這個(gè)架構(gòu)帶來(lái)的第一個(gè)變化是模型不再是一個(gè)網(wǎng)絡(luò)而是兩個(gè)網(wǎng)絡(luò)。圖像編碼器負(fù)責(zé)把像素變成向量文本編碼器負(fù)責(zé)把候選標(biāo)簽變成向量。兩個(gè)網(wǎng)絡(luò)的參數(shù)量加在一起規(guī)模立刻比單純分類模型大了一圈。2.2 類CLIP架構(gòu)的端側(cè)版本視覺(jué)和文本兩條鏈路各占多少很多人以為 CLIP 類模型“只有”幾百兆這個(gè)印象來(lái)自那些被裁剪過(guò)、只做推理用的版本。實(shí)際上完整訓(xùn)練態(tài)模型的體量視覺(jué)編碼器加文本編碼器動(dòng)輒 1B 以上。不過(guò)剛才那張尺子告訴我們端側(cè)更關(guān)心的是“能不能壓縮后運(yùn)行”所以我們要拆開看兩條鏈路的壓縮空間。視覺(jué)編碼器通常是 CNN 或 ViTCNN 類結(jié)構(gòu)對(duì)端側(cè)非常友好卷積算子在各家 NPU 上都有深度優(yōu)化壓縮到 INT8 甚至 4bit 后精度損失相對(duì)可控。文本編碼器是 Transformer算子和顯式/隱式的注意力機(jī)制相關(guān)端側(cè)支持度取決于芯片但 300M 到 600M 的文本編碼器壓到 150MB 左右并不夸張。更隱蔽的開銷在“萬(wàn)物”這個(gè)詞本身。你真正部署的時(shí)候不能把整本詞典都當(dāng)作候選標(biāo)簽一次丟進(jìn)去算相似度。假設(shè)一次識(shí)別要比較 100 個(gè)候選類別的文本特征那至少要把 100 個(gè)文本向量全部加載到內(nèi)存如果候選詞表有 10 萬(wàn)個(gè)詞把全部文本特征算一遍時(shí)間和內(nèi)存都會(huì)失控。所以實(shí)際工程里要做候選挖掘Candidate Mining先用一個(gè)輕量模型粗篩再對(duì)候選子集精細(xì)比較。2.3 “萬(wàn)物”還需要詞表兜底候選標(biāo)簽本身也要占內(nèi)存這里還要補(bǔ)一個(gè)很多人忽略的點(diǎn)文本編碼器不是吃進(jìn)去一個(gè)詞而是吃進(jìn)去一段經(jīng)過(guò) tokenizer 切分的 token 序列。多語(yǔ)言場(chǎng)景下詞表里每種語(yǔ)言都要有對(duì)應(yīng)的子詞單元標(biāo)簽文本越長(zhǎng)編碼器計(jì)算量越大。我遇到過(guò)最頭疼的情況是“萬(wàn)物”清單里放了大量長(zhǎng)尾名詞比如一條商品的完整標(biāo)題“2024 新款戶外防水登山鞋男防滑耐磨徒步鞋”tokenizer 切完可能是一長(zhǎng)串 token。識(shí)別時(shí)每一幀都要把這一長(zhǎng)串文本編碼一遍計(jì)算量不是線性的是隱性地暴漲。所以“萬(wàn)物識(shí)物”放在端側(cè)真正決定成敗的不是那個(gè)視覺(jué)編碼器而是文本編碼器和詞表帶來(lái)的附加內(nèi)存與延遲。如果把視覺(jué)端壓到 200M文本端卻因?yàn)樵~表膨脹到 300M總賬依然不好看。3. 多語(yǔ)言翻譯的真正瓶頸詞表膨脹比模型深度更麻煩3.1 BPE和子詞為什么多語(yǔ)言詞表按“語(yǔ)言數(shù)”放大多語(yǔ)言翻譯模型和單語(yǔ)翻譯模型的差異和“模型深度”關(guān)系不大最核心的差異在詞表Vocabulary。單語(yǔ)詞表通常 3 萬(wàn)到 5 萬(wàn)個(gè)子詞就夠用了。多語(yǔ)言場(chǎng)景下每種語(yǔ)言都有自己獨(dú)特的字符體系中文的漢字、日文的假名、韓文的諺文、阿拉伯文的連寫字母、各種拉丁字母變體……這些字符無(wú)法直接共享詞表只能跟著語(yǔ)言數(shù)量往上膨脹?，F(xiàn)在的做法主流是 BPE / SentencePiece 這類子詞切分算法好處是把常見(jiàn)詞拆成更小片段讓不同語(yǔ)言之間可以共享一部分子詞。比如“telephone”和“téléphone”可以共享一部分 token。但跨語(yǔ)系的共享非常有限中文漢字和英文子詞之間幾乎無(wú)法共享所以詞表膨脹是硬約束。一個(gè)典型的多語(yǔ)言詞表規(guī)模覆蓋歐洲十余種語(yǔ)言時(shí)詞表大約 100k 到 150k覆蓋亞歐非數(shù)十種語(yǔ)言時(shí)詞表往往沖到 250k 到 500k。這里每個(gè) token 不是一個(gè)簡(jiǎn)單的整型它還對(duì)應(yīng)一個(gè)向量。3.2 詞表與隱藏維度決定的 Embedding 權(quán)重賬Embedding 矩陣的體量很好算詞表大小 × 隱藏維度 × 參數(shù)精度假設(shè)詞表 300k、隱藏維度 1024、用 FP16300000 × 1024 × 2B 614MB這只是一個(gè) Embedding 矩陣。Transformer 模型通常輸入和輸出層各有一次 Embedding 操作很多實(shí)現(xiàn)是共享權(quán)重的也就是輸入層和輸出層用同一個(gè)矩陣這時(shí)還好如果不共享上面這個(gè) 614MB 就要乘以 2變成 1.2GB。更麻煩的是Embedding 矩陣在推理時(shí)不像普通權(quán)重層那樣可以連續(xù)計(jì)算它涉及查表操作內(nèi)存訪問(wèn)模式對(duì)端側(cè)緩存很不友好。翻譯模型解碼的時(shí)候每一步都要在輸出層做一次“詞表規(guī)模 × 隱藏維度”的矩陣乘法。詞表越大這一步越慢。還有一個(gè)小細(xì)節(jié)多語(yǔ)言模型通常還要給每種語(yǔ)言加一個(gè)語(yǔ)言 ID 嵌入Language Embedding雖然體量不大但同樣會(huì)占用維度空間。所以在多語(yǔ)言模型里幾百兆的參數(shù)可能不是核心網(wǎng)絡(luò)而是詞表嵌入矩陣。3.3 多語(yǔ)言翻譯模型的整體體量實(shí)測(cè)區(qū)間結(jié)合開源社區(qū)做過(guò)的一系列多語(yǔ)言翻譯模型大致落在這些區(qū)間模型配置詞表規(guī)模總參數(shù)量FP16 文件INT8 文件小型6層d_model 51260k200M-300M400-600MB200-300MB中型12層d_model 768150k800M-1.2B1.6-2.4GB0.8-1.2GB大型24層d_model 1024300k3B-5B6-10GB3-5GB結(jié)論很明確用中等規(guī)模的量化版本多語(yǔ)言翻譯模型是可以放進(jìn)端側(cè)的尤其是詞表控制在 150k 以內(nèi)、參數(shù)量在 1B 左右、量化到 INT8 或 4bit 時(shí)總占用能壓到 1GB 上下。對(duì)一部主流手機(jī)這是可行的對(duì) 8GB 存儲(chǔ)的嵌入式盒子就要斟酌了。4. 端側(cè)放不下時(shí)的實(shí)戰(zhàn)壓縮手段量化、蒸餾、分片的取舍4.1 量化從FP16到4bit的真實(shí)收益與精度回退既然原始模型放不下第一個(gè)想到的就是量化。量化不是新鮮概念但很多人把“量化”當(dāng)成一鍵壓縮忽略了精度回退問(wèn)題的分布不均。對(duì)翻譯模型來(lái)說(shuō)量化掉的經(jīng)驗(yàn)是Embedding 層對(duì)量化非常敏感因?yàn)樵~向量直接決定語(yǔ)義空間的位置從 FP16 強(qiáng)行砍到 4bit近義詞之間的距離會(huì)發(fā)生漂移翻譯出來(lái)的詞經(jīng)?！安钜豢跉狻?。而 Transformer 里的注意力層和前饋層對(duì)量化相對(duì)寬容。實(shí)操上建議混合精度Embedding 層保留 INT8 甚至 FP16計(jì)算密集的線性層用 4bit注意力矩陣用 8bit。這樣既保住了語(yǔ)義質(zhì)量又把整體占用壓下來(lái)。每次量化之后都要在真實(shí)數(shù)據(jù)上跑一遍雙語(yǔ) BLEU 或者 chrF 指標(biāo)不要只看困惑度。4.2 蒸餾與結(jié)構(gòu)化裁剪讓端側(cè)模型“本來(lái)就不大”量化是在“已訓(xùn)練好的大模型”上做減法蒸餾則是從源頭上訓(xùn)練一個(gè)小的。做法是用一個(gè)千億或者幾十億參數(shù)的大模型當(dāng)老師讓幾百 M 的小模型去擬合老師模型的輸出分布。蒸餾出來(lái)的小模型在指定語(yǔ)言對(duì)上的效果往往比直接拿小模型在數(shù)據(jù)上硬訓(xùn)要好很多。我特別推薦在多語(yǔ)言場(chǎng)景里做“分組蒸餾”不是讓一個(gè)小模型同時(shí)學(xué) 100 種語(yǔ)言而是按語(yǔ)系分組蒸餾出一組小模型每個(gè)小組負(fù)責(zé)若干種相近語(yǔ)言。翻譯時(shí)先判斷語(yǔ)言類型再路由到對(duì)應(yīng)的小模型。這樣每個(gè)模型詞表更小精度更高加載和切換也靈活。結(jié)構(gòu)化裁剪剪枝在端側(cè)的實(shí)際收益沒(méi)有想象中大。Transformer 里過(guò)度剪枝容易導(dǎo)致整體性能崩塌而且剪枝后的稀疏矩陣在很多 NPU 上不能直接用還要再轉(zhuǎn)回稠密折騰一圈還不如直接蒸餾一個(gè)小模型來(lái)得干凈。4.3 模型分片與詞表動(dòng)態(tài)加載運(yùn)行時(shí)再摳內(nèi)存如果模型總量還是超了可以考慮“并不全部加載進(jìn)內(nèi)存”的思路。翻譯模型里最常見(jiàn)的做法是“分片加載”把模型拆成 Embedding 層、若干 Transformer 層、輸出層幾個(gè)部分按需從存儲(chǔ)映射進(jìn)內(nèi)存。端側(cè)跑在第一個(gè) token 之前只加載前幾層解碼到中途再加載后面的層。配合操作系統(tǒng)的內(nèi)存映射mmap機(jī)制可以讓系統(tǒng)按頁(yè)讀取權(quán)重而不是一次性把整個(gè)文件讀進(jìn)來(lái)。對(duì)詞表特別大的模型可以做“詞表裁剪快照”模型包里放一個(gè)完整詞表用于離線檢索但推理時(shí)只加載當(dāng)前語(yǔ)言對(duì)相關(guān)的那部分 token 向量。比如一個(gè) 300k 詞表的模型如果用戶只切換中英、中日翻譯只把中文和英文相關(guān)的 60k token 的子詞向量加載進(jìn)來(lái)Embedding 內(nèi)存直接少一大塊。4.4 分層卸載不是丟人方案端側(cè)云端的混合架構(gòu)純端側(cè)方案一旦要覆蓋幾十種語(yǔ)言和“萬(wàn)物識(shí)別”成本會(huì)非常難看。我見(jiàn)過(guò)不少團(tuán)隊(duì)最后選擇了混合架構(gòu)端側(cè)放一個(gè)輕量級(jí)模型應(yīng)對(duì)離線需求和常見(jiàn)場(chǎng)景云端放完整大模型兜底。聯(lián)網(wǎng)時(shí)自動(dòng)走云端斷網(wǎng)時(shí)降級(jí)到端側(cè)模型。很多人覺(jué)得“端側(cè)云端”是妥協(xié)不“純粹”。但在實(shí)際產(chǎn)品里用戶在乎的是“能不能離線用”“快不快”“準(zhǔn)不準(zhǔn)”而不是“模型是否真的全部裝在本地”。一個(gè)合理的降級(jí)鏈路往往比“死磕端側(cè)”更能照顧體驗(yàn)。關(guān)鍵是降級(jí)策略要做到用戶無(wú)感端側(cè)模型負(fù)責(zé)大概率常見(jiàn)的識(shí)別和翻譯當(dāng)置信度低或遇到陌生語(yǔ)言對(duì)時(shí)自動(dòng)切換到云端。這個(gè)置信度閾值需要反復(fù)調(diào)調(diào)太高則離線模式頻繁失敗調(diào)太低則云端流量和延遲白白增加。5. 務(wù)實(shí)決策框架什么必須放端側(cè)什么應(yīng)該留在云端5.1 判定標(biāo)準(zhǔn)延遲、隱私、帶寬、離線到底哪些能力要放端側(cè)哪些可以交給云端我習(xí)慣用四個(gè)維度打分。延遲敏感度實(shí)時(shí)翻譯、實(shí)時(shí)識(shí)別用戶等不起一次 800ms 的網(wǎng)絡(luò)往返這類優(yōu)先放端側(cè)。隱私敏感度醫(yī)療影像、身份證件、聊天內(nèi)容等數(shù)據(jù)不出設(shè)備是硬需求必須本地處理。帶寬成本視頻流、大批量圖片識(shí)別在弱網(wǎng)環(huán)境下傳不動(dòng)端側(cè)可以先兜底。離線可用性明確要求飛行模式、野外環(huán)境也能用的場(chǎng)景比如巡檢、戶外導(dǎo)航端側(cè)是唯一選擇。四項(xiàng)里只要中了兩項(xiàng)就應(yīng)該考慮端側(cè)方案。如果一項(xiàng)都不占那上云端是更經(jīng)濟(jì)的選擇沒(méi)必要把模型塞進(jìn)設(shè)備折磨自己。5.2 參考架構(gòu)一個(gè)雙級(jí)緩存系統(tǒng)我自己比較偏好的參考架構(gòu)是“雙級(jí)緩存”第一級(jí)端側(cè)常駐一個(gè)覆蓋高頻需求的輕量模型比如 200M 的識(shí)別模型加一個(gè) 500M 左右、覆蓋頭部十幾種語(yǔ)言的翻譯模型。系統(tǒng)啟動(dòng)時(shí)就加載保證基礎(chǔ)功能離線可用。第二級(jí)按需下載的語(yǔ)言包或品類包。用戶第一次使用某種冷門語(yǔ)言或識(shí)別某個(gè)垂直品類時(shí)提示下載一個(gè)幾十 MB 的增量模塊。下載后替換或補(bǔ)充到第一級(jí)模型旁邊。這個(gè)方案的好處是不是一開始就讓用戶下載一個(gè) 3GB 的“全家桶”而是讓用戶只為他需要的部分付費(fèi)存儲(chǔ)和流量。增量模塊之間通過(guò)版本號(hào)管理服務(wù)端可以隨時(shí)發(fā)布新的語(yǔ)言包而不需要用戶升級(jí)整個(gè) App。5.3 低資源場(chǎng)景下的降級(jí)方案詞典、檢索、模板翻譯如果連 500M 的小模型都不想放或者設(shè)備太陳舊還有一條更輕的路線用檢索式方案代替生成式模型。物體識(shí)別可以退化為“特征向量 本地檢索庫(kù)”每張圖像抽一個(gè)向量提前給每個(gè)候選類別抽好向量部署時(shí)只放一個(gè)“類別向量庫(kù)”幾十 MB 搞定。翻譯可以退化為“短語(yǔ)詞典 模板匹配”離線詞典命中高頻短語(yǔ)模板負(fù)責(zé)句子結(jié)構(gòu)替換。這種方案效果當(dāng)然不如大模型但作為應(yīng)急降級(jí)、特定垂直領(lǐng)域比如工業(yè)設(shè)備銘牌識(shí)別、餐廳菜單翻譯完全夠用。這里我特別想強(qiáng)調(diào)一個(gè)工程心態(tài)端側(cè)方案不是“替代”云端方案而是“分層兜底”。很多時(shí)候低資源方案解決的是“有和沒(méi)有”的問(wèn)題不是“好和更好”的問(wèn)題。5.4 給三類團(tuán)隊(duì)的選型建議團(tuán)隊(duì)資源不同策略完全不同。個(gè)人開發(fā)者別輕易碰多語(yǔ)言全家桶。選一個(gè) 300M 以下的單一語(yǔ)言翻譯模型加一個(gè)輕量識(shí)別模型只支持中英等兩三個(gè)核心語(yǔ)言對(duì)先把閉環(huán)跑通。中小團(tuán)隊(duì)采用“按需下載 雙級(jí)緩存”架構(gòu)主推 5 到 10 種高頻語(yǔ)言冷門語(yǔ)言走云端 API云端失敗再提示離線不可用。大團(tuán)隊(duì)有硬件和算法資源可以考慮自研蒸餾管線針對(duì)自家設(shè)備做混合精度量化把模型壓到極限后常駐端側(cè)。6. 我踩過(guò)的坑和給你的實(shí)操建議6.1 詞表統(tǒng)一設(shè)計(jì)能一石二鳥我參與過(guò)的項(xiàng)目里有一個(gè)關(guān)鍵決策把“萬(wàn)物識(shí)物”的文本編碼器詞表和多語(yǔ)言翻譯的詞表統(tǒng)一起來(lái)。好處很明顯同一個(gè) tokenizer、同一套子詞視覺(jué)語(yǔ)言和翻譯模型共享 Embedding 矩陣整體包體直接小一截。但代價(jià)是詞表設(shè)計(jì)階段很痛苦。視覺(jué)標(biāo)簽用詞偏名詞翻譯用詞偏句式表達(dá)兩者對(duì)子詞切分的偏好不完全一致。你需要在大規(guī)模語(yǔ)料上做好詞頻統(tǒng)計(jì)平衡視覺(jué)和翻譯兩個(gè)域的子詞覆蓋。一旦定下來(lái)后續(xù)再做任何語(yǔ)言擴(kuò)展都要小心翼翼因?yàn)楦脑~表等于改模型輸入空間。6.2 多語(yǔ)言質(zhì)量退化加語(yǔ)言要雨露均沾多語(yǔ)言模型的經(jīng)典坑是語(yǔ)言越加越多每種語(yǔ)言的質(zhì)量都在掉尤其是資源稀缺的小語(yǔ)種會(huì)被高資源語(yǔ)言“擠占”。原因不難理解模型總?cè)萘坑邢拊~表、層參數(shù)要分給更多語(yǔ)言。我的建議是加語(yǔ)言不能“只加詞表、不訓(xùn)練”要把新語(yǔ)言的語(yǔ)料和已有語(yǔ)言的語(yǔ)料按比例混合重新做一輪全語(yǔ)言微調(diào)。每次加語(yǔ)言之后都要在已有的主要語(yǔ)言上重新跑一遍回歸測(cè)試。否則容易出現(xiàn)“新增中文翻譯很好但英文翻譯突然變差”的尷尬情況。6.3 別只看文件大小要看峰值內(nèi)存和首Token延遲模型放進(jìn)設(shè)備之后判斷能不能用不要只看安裝包大小。要實(shí)測(cè)兩件事峰值內(nèi)存用內(nèi)存分析工具跑一段連續(xù)翻譯任務(wù)看加載模型 推理時(shí)的峰值 RSSResident Set Size。如果超過(guò) App 可用內(nèi)存上限的一半大概率會(huì)在低內(nèi)存設(shè)備上被殺。首 Token 延遲多語(yǔ)言翻譯是自回歸生成用戶從輸入文字到屏幕上出現(xiàn)第一個(gè)譯文 token 的等待時(shí)間直接影響體驗(yàn)。這個(gè)數(shù)字受算力、量化方案、詞表大小影響很大實(shí)測(cè)比理論估算可靠。我自己吃過(guò)虧一個(gè) INT8 模型文件挺小但在某款 NPU 上因?yàn)榍度氩楸砗头戳炕阕硬恢С钟布铀偈?token 延遲沖到 1.5 秒只能重做算子融合。6.4 熱更新設(shè)計(jì)詞表不能隨便加模型版本要兼容端側(cè)模型很方便做熱更新但詞表版本不兼容是個(gè)暗坑。云端如果發(fā)布了新詞表舊模型不認(rèn)識(shí)新 token新模型不認(rèn)識(shí)舊緩存結(jié)果就是翻譯質(zhì)量暴跌或者直接索引越界。建議在模型包里帶上 tokenizer 的版本號(hào)服務(wù)端下發(fā)增量包時(shí)校驗(yàn)詞表版本一致性。模型文件命名務(wù)必帶 hash不要用“model_v2_final_really”這種詭異命名發(fā)布流程會(huì)亂到你懷疑人生。多語(yǔ)言翻譯和萬(wàn)物識(shí)別同時(shí)上端側(cè)沒(méi)有銀彈但也不是天方夜譚。核心策略就一句話能剪的剪、能量化的量化、能拆的拆、能降級(jí)的降級(jí)把用戶最常用的那部分留在本地把長(zhǎng)尾需求交給云端。端側(cè)模型這個(gè)方向上我會(huì)持續(xù)跟下去下次再分享更多實(shí)測(cè)數(shù)據(jù)和踩坑記錄。