開場白
這期熱度最高的不是大塊頭模型，而是一顆僅 322M 的決策分類器convaiinnovations/laya，官方 card 自己拿它對比 26 到 28B 等級的對手，宣稱準確率更高、速度快 7.8 倍，等一下告訴你這份自報數據該怎麼看。同集還有衝上 120 萬次下載、掛了 37 個量化版本的 OCR 模型baidu/Unlimited-OCR，以及能把文字、圖片、音訊塞進同一向量空間的 google/embeddinggemma-2。
本期精選
1. google/embeddinggemma-2：一顆模型通吃文字、圖片、音訊的 RAG 前菜
- 這是什麼：google/embeddinggemma-2 是 Google 出的多模態 embedding 模型，總參數 740M（文字主幹 270M＋視覺編碼器 170M＋音訊編碼器 300M），授權 Apache-2.0。官方 model card 標示文字（含程式碼）、圖片、影片、音訊都會被映射到同一個 768 維向量空間，不是分開訓練幾顆 embedding 模型。
- 能用在哪些場景：
- 後端工程師想自架公司內部文件搜尋，把 Confluence、Notion 匯出的技術文件、會議記錄切塊後灌進 pgvector 或 Qdrant。官方 card 標示支援 100+ 語言、上下文 8192 tokens，中英混雜的內部文件可以共用同一套索引，不必為中文另外換一顆 embedding。
- 做知識庫的小團隊想用一句話同時搜到簡報截圖和會議錄音，card 寫的是文字、圖片、影片、音訊都映射到同一個 768 維向量空間，不用再維護三套各自獨立的 embedding 服務。
- 向量資料庫帳單或硬體吃緊的情況，card 說支援 Matryoshka（MRL）截斷到 512、256、128 維，截到 256 維品質損失很小，向量儲存成本最多能省到六分之一；另外也能只載入需要的模態（純文字 270M、文字加圖片 440M），適合塞進 side-car 容器或筆電。
- 跑得動嗎：官方沒有給具體 VRAM 數字，但 model card 強調它「designed to run on consumer hardware such as mobile devices and laptops」。要注意官方明確警告推論要用 bfloat16 或 float32，用 float16 會出現 NaN 或 embedding 品質劣化；頁面目前沒有列出 GGUF 之類的量化版本。
- 本期聲量：HF 熱度 1005，144.3k 次下載、2.4k 個讚，是本期聲量最高的一顆；同家族另外有 2 個量化／重打包版本。
- 跟同類比：要先講清楚，card 自報的 MTEB multilingual 61.36、MTEB code 78.68（官方說程式碼任務比前代進步約 14%），以及跨模態的 MIEB 64.64（圖）、MMEB 50.67（影片）、MSEB 69.54（音訊），都只跟「前代 EmbeddingGemma」比較，沒有對照 bge-m3 或 multilingual-e5 這類第三方模型。它的差異點與其說是分數，更像是一顆模型吃四種模態，而且小到能放進筆電。
- 怎麼取得：README 給的最短路徑是用 sentence-transformers，
SentenceTransformer("google/embeddinggemma-2")再model.encode(sentences)；也可以走 transformers 的AutoProcessor加AutoModel.from_pretrained(..., device_map="auto")。 - 連結：https://huggingface.co/google/embeddinggemma-2
2. baidu/Unlimited-OCR：發票合約別再上傳雲端，MIT 授權還自帶 37 個量化版本
- 這是什麼：baidu/Unlimited-OCR 是百度推出的 OCR 模型，3B 參數、BF16，授權 MIT。README 直接提供
model.infer()處理單張圖片、model.infer_multi()處理多頁文件與 PDF。 - 能用在哪些場景：
- 接外包或做 SaaS 後台的工程師要處理發票、報價單、多頁 PDF 合約，但這些檔案有個資與保密顧慮不能丟雲端，整份文件可以留在自己機器上用
model.infer_multi()解析。 - 想把紙本資料數位化進個人知識庫的人，掃描講義、翻拍白板、書本頁面轉成可搜尋的文字後丟進 Obsidian 或 Notion；官方頁面標示有 37 個量化版本可以搭 Ollama、LM Studio、Jan，不必自己處理 CUDA 環境。
- 原本按頁數付費給雲端 OCR API 的團隊想換成自架，model card 提供 vLLM 的 Docker image（CUDA 13.0 與 12.9 兩種版本）與 SGLang 的啟動方式，可以在內網拉起一個常駐服務替換掉外部計費端點。
- 接外包或做 SaaS 後台的工程師要處理發票、報價單、多頁 PDF 合約，但這些檔案有個資與保密顧慮不能丟雲端，整份文件可以留在自己機器上用
- 跑得動嗎：官方標示需要 NVIDIA GPU，實測環境寫的是
torch==2.10.0、torchvision==0.25.0、transformers==4.57.1，但具體 VRAM 門檻官方沒有標示。模型本身 3B、BF16，另外頁面列出 37 個量化版本可以配 llama.cpp、LM Studio、Jan、Ollama，等於把硬體門檻又往下拉了一截。 - 本期聲量：HF 熱度 320，1.2M 次下載、4.7k 個讚。
- 跟同類比：card 自報的是 llamaindex/ParseBench 成績，mean 46.17、Text Content 86.81，但 Text Formatting 只有 0.97，這個數字官方自己就不高，代表純文字抽取和版面格式還原顯然是兩回事，要排版結構的場景得自己驗。PaddleOCR 與 DeepSeek-OCR 只出現在 card 的致謝名單裡，官方沒有給這兩者的正面對照數據；另外這張 card 完全沒標示支援語言，繁體中文與手寫辨識的表現沒辦法從官方文件推斷。
- 怎麼取得：README 的 transformers 路徑是
AutoModel.from_pretrained("baidu/Unlimited-OCR")並要加trust_remote_code=True，再呼叫model.infer()或model.infer_multi()；要起服務的話官方也給了 vLLM Docker image 或 SGLang 的 Python server 兩種方式。 - 連結：https://huggingface.co/baidu/Unlimited-OCR
3. convaiinnovations/laya：沒 GPU 也能跑的工單分流器，自曝比對手快 7.8 倍
- 這是什麼：convaiinnovations/laya 是一套不生成文字、只回傳機率的語意分類／路由模型，授權 Apache-2.0，有兩個版本，英文版 421M（ModernBERT-large 主幹）與多語版 322M（mmBERT-base 主幹）。
- 能用在哪些場景：
- 自己維運客服或工單系統的工程師要做自動分流，model card 舉的例子是 billing 與 technical support 的 routing、urgency scoring、churn risk，把這顆模型掛在 API 前面判斷工單類別與急迫度，不必每張工單都叫一次大模型。
- 在 LLM 前面做守門或路由，先判斷這個請求該不該送大模型、該送哪一顆；card 強調回傳的是「calibrated probabilities」而且完全不生成文字，所以沒有幻覺問題,也不用寫 JSON parsing 的防呆。
- 手上只有一台沒 GPU 的 VPS，但想要語意分類能力，官方說明提到支援 CPU fallback，並附了
laya-serveHTTP server 與 LangChain 整合，可以直接在既有 Python 服務旁邊起一個分類端點。
- 跑得動嗎：官方沒有給最低硬體門檻，但 model card 的參數與實測表可以引述：英文版 421M（下載約 808MB）、多語版 322M（約 647MB）；benchmark 表標示在 Tesla T4 上單一問題跑 32.8 到 39.5 毫秒，並寫明支援 CPU fallback，另外可選 ONNX Runtime 與 TileLang 的 GPU fast path。
- 本期聲量：HF 熱度 189，48.9k 次下載、5.6k 個讚。
- 跟同類比：laya 自己的 card 點名對手 Jev，自報 typed-decisions 準確率 0.766（fine-tuned 版）對 Jev 的 0.727，速度 32.8 毫秒對 236 到 276 毫秒（官方說法是快 7.8 倍），校準度 ECE 0.081 對 Jev 的 0.246，這些都是 laya 單方面自報，不是第三方評測。官方頁面也點出，Cloudflare/clef 的 card 寫測試環境是單張 H200，vllm-sr/d3 的 benchmark 跑在 AMD Instinct MI325X，autotrust/JEV-27B-VL 更直接標示全 256K 上下文需要 80GB 以上顯示記憶體；對照之下 laya 只要幾百 MB，官方說能退回 CPU。另外 card 自己也揭露限制，雖然號稱支援 100+ 語言，但實測是 51 種語言裡有 45 種才達到優於隨機 3 倍的可用標準。
- 怎麼取得：README 的最短範例是
from laya import Router、router = Router()、router.predict(state, questions)；官方也標示可以直接走 Hugging Face transformers、用laya-serve起 HTTP server，或透過 LangChain 整合。 - 連結：https://huggingface.co/convaiinnovations/laya
結尾段落
這期三顆模型剛好對上三種不同的地端焦慮：embeddinggemma-2 解決的是多模態 RAG 要不要分開養幾套服務的問題，Unlimited-OCR 解決的是文件不能上雲的問題，laya 解決的是守門分類不想一直燒大模型 token 的問題。如果只能先選一個動手，laya 的體積與 CPU fallback 應該是門檻最低的起點，但記得它的對比數據都是官方自報，上線前自己拿真實資料再驗一輪比較安心。下集再見。
留言