共用維度：升維的新方向

這篇沒有我們的實測。數字都來自論文與模型卡，連結在文末；判斷是我們的，會標明。

先講一個場景

假設你要做一個「公司內部什麼都能搜」的系統。

合約是 PDF，發票是掃描件，會議是錄音，產品照是圖檔。

多模態過去有兩條路：一條是養四個模型——文字嵌入、視覺嵌入、語音轉文字、音訊分類，四套向量空間互不相通，最後再加一層對齊；另一條是把一個模型做得很大，大到能吞下所有模態。

2026 年 10 月，Google 的 EmbeddingGemma 2 示範了第三條：共用語意 backbone，把不同模態的容量隔離在分支裡。純文字跑起來只要 271M；需要視覺再打開視覺分支，需要聲音再打開音訊分支。

它真正值錢的地方不是「一個模型吃四種資料」，而是：升維不必讓整個模型一起變胖。

升維的舊帳單

要理解這條新路，先看舊路的成本。

第一是乘法。 稠密模型的帳單是參數量乘上 token 數。想多一種能力，就得把所有東西一起放大。

第二是梯度打架。 同一組權重要同時滿足「這個像素是貓」和「這個詞是主詞」。兩邊梯度方向不同，互相拉扯。多任務學習裡叫負遷移。

第三是輸入幾何不同。 文字是離散的 token、影像是像素網格、聲音是波形。它們連「什麼是一個單位」都不一樣。

這三個帳單不是要證明多模態不可行，而是說明為什麼舊路走到某個尺寸就開始不划算。新方向的價值，就是換一種付帳方式。

新方向：共用維度，隔離容量

EmbeddingGemma 2 的做法是：拆在入口，合在語意。

圖片/影片/聲音 ──[各自的編碼器]──> soft token ──[同一個 24 層 transformer]──> 向量
                   ↑ 分開                              ↑ 共用

模態編碼器各自處理低階特徵（像素、波形），輸出變成「soft token」——連續向量，跟文字 token 一樣可以排進序列，但不需要對應任何一個字。高階語意則全部交給同一個 transformer。

參數這樣分：主幹（文字也走這裡）271M、視覺編碼器 167M、音訊編碼器 305M。

注意那個 305M：音訊編碼器比整個文字主幹還大。

這正是新方向的關鍵。容量掛在分支上，於是它可以被關掉：

在 Pixel 11 Pro 上、Q4_C 量化下，峰值記憶體（含 runtime 編譯開銷）：純文字 191 MB、文字加影像 447 MB、全模態 567 MB。

而且文字品質沒有犧牲。它的 271M 文字路徑，多語 MTEB 平均 61.36；前一代 308M 是 61.15。參數更少、還多扛三種模態，文字沒有掉。

這就是這條路最有希望的地方：升維可以是「選擇性打開」，不是「整體膨脹」。

兩種拆法，兩張帳單

同樣是「共用主幹、隔離容量」，可以拆在不同地方。目前兩種主流答案：

MoE：拆在模型中間

同一層裡放很多專家，每個 token 只走其中幾個，由 router 決定。

它換到的是：容量與「每 token 計算量」脫鉤。 參數可以很多，但每個 token 只碰一小塊。

代價是訓練變難：router 崩塌、專家負載不均、梯度稀疏。MoE 用訓練的難度，換推論的成本。

EmbeddingGemma 2：拆在入口

異質的模態交給設計好的編碼器，同質的語意交給共用主幹。

它換到的是：容量與「常駐記憶體」脫鉤。 你不需要為了偶爾用一次影片檢索，讓整個模型常駐。

兩者解的不是同一道題，也不互斥。一個在計算上省，一個在記憶體上省。

早融合與晚融合：在哪一層開始對齊

如果你聽過 CLIP，會覺得「這不就是多模態嗎」。

差別在合併點。

晚融合（CLIP、SigLIP）：兩個完整編碼器各自跑完，最後用對比損失對齊。兩塔之間沒有資訊交換。

早融合（EmbeddingGemma 2）：編碼完就變成 soft token，塞進同一個 transformer，所有模態在上面混在一起。

晚融合的好處是兩個塔可以各自很強；代價是學不到跨模態的交互——圖片裡的文字、影片的原聲、簡報裡圖表跟標題的關係。

早融合的代價是所有模態要擠進同一個狹窄通道。它的模型維度只有 512，總共 24 層。（這是我們的解讀：刻意選窄。）

它的賭注是：語意空間夠窄，才逼得出真正的共同表示。

三個支持這條路的證據

論文做了消融實驗，其中三個對「共用主幹」這個方向特別有說服力。

拿掉文字專屬的機制，全部變好

Gemma 的 per-layer embeddings 原本多一個查找表，作用是把 token 資訊注入中間層。EmbeddingGemma 2 把查找表拿掉，只保留投影。

整體從 55.07 變成 55.46；影像 54.57 → 54.67、影片 47.13 → 47.82、視覺文件 61.76 → 62.37。這些消融是訓練過程中的中間配方，不等於最終模型（最終 MMEB-v2 整體是 59.01）。

拿掉反而全部變好，連純文字也是。論文給的理由是：查找表對非文字模態「沒有直接訊號」，還額外佔記憶體。

我們的解讀是：共同空間不是靠加東西達成的，是靠拿掉東西。 任何讓某一模態「繞過」共同空間的機制，都會拉低整體。

視覺編碼器不能凍結

可訓練的整體 52.27、影像 50.10、影片 43.26；凍結後掉到 48.18、44.35、39.24，差 4.1 分。

很多多模態模型會凍結模態編碼器，省成本又保留原本能力。這篇的結果是：編碼器要被訓練去適應共同空間。

對這條路來說這是好消息也是提醒——共用主幹不是免費的，它要求每個分支往同一個地方收斂，而收斂是可以被訓練出來的。

音訊編碼器是凍結的，而音訊剛好只打平

論文寫得很清楚：音訊編碼器跟 Gemma 4 E2B/E4B 完全相同，訓練期間凍結。

而音訊是它跟對手最接近的一項：MAEB 的 Mean(Task) 49.87，Jina Omni Nano 50.14，差 0.27 分。Mean(Type) 則是 48.65 對 55.31，沒有打平。對照之下，影像 57.28 對 55.43、影片 50.67 對 35.87，都是明顯領先。

作者自己也留了一句：「透過進一步訓練音訊編碼器，可能也會有類似的增益。」

這是我們的推測，不是論文的結論：把音訊解凍，這一項可能拉開。但他們沒做，所以只能說「有這個可能」——這正是這條路還沒走完的地方。

怎麼用：選型不是排名

選型要看的是「你的場景需要什麼」，不是「誰第一名」。

幾個值得一起看的數字：

（— 代表論文該欄沒有分數；論文用 ∗ 標「不支援」、– 標「沒有分數」，兩者不是同一件事。數字皆來自論文 Table 6。）

三件事值得注意。

第一，跟前代比，文字幾乎沒變，但多出了三種模態。 真正的差別不是分數，是「多出來的功能沒有把原本的能力吃掉」。

第二，純文字它輸給專門模型。 Jina 多語贏 4.2 分、英文贏 2.7 分；Qwen3 贏 3.0 分。而且 744M 是「全部載入」的數字，純文字實際只跑 271M。論文附錄也給了答案：268M 的 harrier-oss-v1-270m 多語 66.5、212M 的 jina-embed-v5-text-nano 65.5，都比它高。這兩個是純文字專家模型。

但這不是缺點，是分工。你要一份能升維的 checkpoint，跟你要一個最強的文字模型，是兩個不同的需求。

第三，多模態它領先很多。 影片 50.67，Jina 30.73、InterestFM 35.87，差距 15 到 20 分。影像 57.28 對 55.43，贏得不誇張但穩定。

聲音方面：同一個模型，原生音訊 69.54，先轉文字（ASR）只有 57.59——差約 12 分。聲音裡的非語言資訊，轉文字就沒了。（前代的 ASR 是 50.95；拿它跟這代的 69.54 比會得到 18.6 分，但那是跨世代比較，不是模態差距。）

還沒走完的地方

一條新路值不值得押注，要看它還缺什麼。這裡有四件事。

純文字不是最強。 論文說的 Pareto frontier 是「品質與參數量」的效率前沿（贏過兩到十二倍大的模型），不是每個單項都第一。

視覺文件還有空間。 在 280 token 預算下 VisDoc 67.84，Jina Omni Nano 71.34。掃描件、表格、排版複雜的文件靠細粒度視覺細節，而論文也說提高 token 預算對 VisDoc 還有增益——這比較像「還沒調到最好」，不是天花板。

量化對聲音傷害最大。 bfloat16 換到 int4，文字幾乎無感（61.36 → 60.84），聲音掉 5.6 分（69.54 → 63.92）。不過論文註明 float 與量化跑的是不同評測 harness，這個降幅含 harness 差異，不能全算在量化頭上。

同一個 token 預算，對三種任務方向不同。 影像是每幀 280、影片是每幀 140 訓練出來的；把推論預算從 280 提到 560：視覺文件大幅改善（63.38 → 67.62）、影像飽和、影片反而變差（48.51 → 46.52）。論文說原因是過長的序列稀釋了注意力與 mean-pooled 表示。

所以部署時，這個旋鈕要按任務分開調——這不是缺陷，是這條路給你的控制權。

結論：升維的新方向

回到那個場景。你不再需要在「四個模型」與「一個大模型」之間二選一。

共用維度，容量隔離在分支：同一個語意空間，需要什麼模態就打開什麼分支。

兩種拆法，各換一張帳單：

MoE 拆在模型中間。同質的專家，用學出來的 router 決定誰上班。換到「容量 vs 每 token 計算」的脫鉤。

EmbeddingGemma 2 拆在入口。異質的模態，用設計好的編碼器決定誰處理。換到「容量 vs 常駐記憶體」的脫鉤。

一個共同的教訓：拆不是為了變大，是為了讓某些東西可以被關掉。

而它最反直覺、也最值得記住的一課是——共同空間是拿掉專屬機制換來的，不是加更多模組換來的。

我們沒有實測這顆模型的部署難度、工具鏈支援或實際延遲，所以這篇不建議你直接遷移。要做的話，先量三件事：你的文字主幹到底多大、分支能不能關、跨模態查詢佔比多少。原始資料：論文 arXiv 2610.37364、Gemma 文件。MoE 的相關工作見 arXiv 2610.37386（channel selection，不是 MoE 綜述）。