端侧小型 Embedding 模型深度对比研究

深度研究RAG端侧 AI2026-07

夫检索增强（RAG）之成败，半在检索，半在生成。而检索之魂，全在 embedding 模型——它将"字面不同、语义相通"之句，投于同一向量空间。然云端 API 虽便，却有三患：隐私外泄、按量计费、网络依赖。故端侧（on-device）small embedding 模型，遂成隐私优先、离线可用、零边际成本之利器。

本文广搜 2025–2026 之公开基准与实测，择其"小巧可端侧部署"者，逐一秤其体积、维度、上下文、多语能力与许可，终以决策之树、按场景荐之。

1. 何为"适合端侧"：四道门槛

"小巧"二字，非只看参数量。端侧落地，须过四关——犹如一人欲负笈远行，不只问体重，亦须问口粮、行囊、脚力。

• 其一，模型体积（磁盘/下载）。决定能不能进浏览器缓存、能不能塞进手机存储。百兆以下者，可一次性下载缓存，此后秒级响应；逾五百兆者，须斟酌设备余量。
• 其二，向量维度（dimension）。决定向量库之存储与检索开销。维度高则表达力丰，然每存储一条向量、每算一次余弦，皆更费。384 维与 1024 维，百万元素之差以 GB 计。
• 其三，上下文长度（context）。长文若超窗，则"截尾而忘本"——后段尽失。512 token 仅容约 400 词，长文档须切碎；8192 乃至 32K 者，可整篇投之。
• 其四，硬件与量化。是否须 GPU？CPU 能否扛？经量化（int8/int4）后，体积可缩数倍而精度微损。此即端侧之"变废为宝"术。

📌 术语小释：MTEB（Massive Text Embedding Benchmark）乃衡量 embedding 之权威统考，含检索、聚类、分类、句对、重排、STS 等五十余科；MMTEB / C-MTEB 则其多语/中文卷。分数愈高愈佳，然不同榜单口径略有出入，宜横向比、勿孤立看。

2. 模型版图总览：一表览尽

下表汇十五款"可端侧"之代表，数据综合自 MTEB 官方榜、各模型卡及 Ollama/Milvus 实测（截至 2026-07）。

标注说明：MRL = Matryoshka 表征学习，可无损截断维度（如 768→256→128）以省存储；(RAM量化) 指经 int8 量化后内存占用；"—" 表示该项于所引基准未见公开数字，非谓其弱。

3. 极轻量档（< 100MB，可塞进浏览器/树莓派）

此档之模型，体量不及一张高清图，却已能撑起基础语义检索。恰如"小舟亦可渡河"——不求远航，但求即时。

3.1 all-MiniLM-L6-v2：端侧之"默认公民"

• 22.7M 参数、384 维、46MB，久为 Sentence-Transformers 之默认。
• 胜在无处不兼容：Ollama、transformers.js、ONNX 皆有现成权重；树莓派、CI 流水线、老笔记本皆能跑。
• 弱在精度：MTEB ~56，长文上下文仅 256 token（约 200 词）。宜作原型与兜底，不宜作生产主力。

3.2 gte-small：同体量之"性能标杆"

• ~70MB、384 维、512 上下文，MTEB 61.36——比 all-MiniLM 高约 5 分，体量仅增三分之一。
• 实测被 SemanticFinder 社区推为默认替代，性价比极佳。英文检索强，中文弱。

3.3 bge-small 双子：en-v1.5 与 zh-v1.5

• bge-small-en-v1.5（134MB、384 维）：MTEB 62.11，为 384 维档之英任务顶流。
• bge-small-zh-v1.5（118M、512 维）：C-MTEB 57.82，专为中文优化，词汇表 21128 覆盖 99.8% 常见中文字。单句 0.87ms、吞吐 1150 句/秒（T4 GPU）。
• 二者皆 MIT 许可，商用无忧。中文场景直取 zh 版。

3.4 multilingual-e5-small：多语之"小钢炮"

• 140MB、384 维、512 上下文，MTEB 英 59.93 / 中 55.38，支持 100+ 语言。
• 虽每语训练数据不及英文，却已显著胜过旧版多语模型 distiluse-base-multilingual。低价位多语需求之首选。

3.5 Snowflake Arctic Embed xs / s：尺寸优先极致

• xs（22M、46MB）检索 ~50；s（33M、67MB）检索 51.98——后者已逼近 bge-small-en 之 51.68。
• 出自 Snowflake 多阶段检索优化管线，专为"最严苛延迟/成本预算"而生。若连 70MB 都嫌多，此二者是底线。

3.6 jina-embeddings-v2-small-en：小身量、长上下文

• 33M 参数、512 维、8192 上下文——以小模型而拥长文之能，赖其 ALiBi 双向注意力可外推。
• 英文单体，Apache-2.0。整本技术手册、法律条文可整段投之而不截尾，此其独到之处。

3.7 mxbai-embed-xsmall-v1：浏览器之宠

• 23M、384 维，mixedbread 出品，专为 transformers.js 调优，WebGPU 下毫秒级。
• 若欲"前端零后端"之语义搜索，此与 bge-small-en-v1.5(量化) 并列为浏览器首选。

4. 轻量·多语档（100MB–400MB，端侧主力）

体量稍增，能力跃迁。此档多为"个人 RAG、小团队知识库"之甜点区。

4.1 nomic-embed-text-v1.5：Ollama 下载量之王

• 137M、768 维（MRL 可降至 64–768）、8192 上下文、274MB。
• 笔记本 CPU 即可跑，不沾 GPU；512 维时胜 OpenAI ada-002 而内存仅其三分之一，256 维时性能近 all-MiniLM 而内存仅十二分之一。
• MTEB 总体 62.39。绝大多数个人/小团队 RAG，此即起点。短板：跨语桥接弱。

4.2 bge-m3：多语·多功能之集大成

• 568M、1024 维、8192 上下文、1.2GB、MIT。
• "M3" 即多语（100+）、多粒度、多功能——一次推理同时产出稠密向量、稀疏向量（类 BM25 词匹配）、ColBERT 式多向量。
• 若框架支持混合检索（Qdrant、Milvus 皆然），稠密+稀疏双信号远胜单一。中文 C-MTEB 64.8 居前。唯英文检索略逊于同体量专英模型。

4.3 EmbeddingGemma-308M：Google 之"端侧亲儿子"

• 308M、768 维（MRL→128）、2K 上下文、量化后 RAM < 200MB、EdgeTPU 上 < 22ms。
• 基于 Gemma 3，跨 100+ 语训练；集成 TFLite / LiteRT / MLX / ONNX / transformers.js，移动端 RAG 之天作之合。
• MMTEB v2 61.15，于 5 亿参数以下多语模型居首。与 Gemma 3n 搭配可成"端侧检索+生成"全链路。
• ⚠️ 许可为 Gemma 条款（responsible commercial use），商用前须细读条款，异于 Apache-2.0 之宽松。

4.4 gte-multilingual-base 与 granite-278m：多语备选

• gte-multilingual-base（280–305M，768 维，8192 上下文）MMTEB 58.24，多语均衡。
• granite-embedding-278m-multilingual（278M，768 维，512 上下文）MMTEB 53.74，IBM 出品，多语覆盖广而精度稍逊。

4.5 nomic-embed-text-v2-moe：多语 MoE 新秀

• ~305M、768 维、8192 上下文、610MB，混合专家架构，训练于 16 亿文本对，支持 ~100 语。
• 同尺寸多语 SOTA 级；若须多语而又不忍 bge-m3 之 1.2GB，可与此、EmbeddingGemma 三方比对己方数据。

5. 准生产档（400MB–1.2GB，端侧高能）

虽逾五百兆，然以 LLM 之标尺衡量仍是"侏儒"，却已具生产级检索力。

5.1 mxbai-embed-large-v1：英文检索之"小模型之王"

• 335M、1024 维、512 上下文、670MB、Apache-2.0。
• 英文检索 MTEB 64.68，于 500M 以下参数模型中居首。文档若英文、自含短节（FAQ、API 文档、商品描述），此即 nomic 之上位替代。
• 软肋：512 token 上限，长文（论文、法条）须切碎，恐碎其语境。

5.2 Qwen3-Embedding-0.6B：2025 之"规则改写者"

• 0.6B、1024 维（MRL 32–1024）、32K 上下文、Apache-2.0、100+ 语（含编程语言）。
• MTEB 英 v2 70.7、多语 64.64、中文 71.02——以六亿参数，越诸多倍其身之旧模型。
• 维度可自定义、支持指令感知（instruction-aware，特定任务提 1–5% 相关性）。GGUF(q8_0/f16) 可经 llama.cpp 跑，Q4 约 400MB。
• 8B 版以 70.58 登 MMTEB 多语榜首（2025-06），然 16GB+ 显存，端侧仅限高配。
• ⚠️ 较新，社区测试与框架自动适配（尤其指令格式）尚不如老模型周全；且较 nomic 重约 4 倍，与 7B 对话模型争显存时须权衡。

6. 中文与多语场景专项

步子哥既用中文，此节单列，以免"洋模型"之误用。

实测一例：中文长文档（年报/白皮书）检索，Qwen3-0.6B 之 NDCG@10 达 0.782，胜 bge-m3(0.715) 与 nomic-v1.5(0.689)；跨语技术文档中英匹配，Qwen3 达 0.826，显式平行语料对比学习之功也。

7. 端侧部署技术栈：量化、ONNX、GGUF、浏览器

模型选定，尚须"落地之术"。同一模型，部署得当可快数倍、小数倍。

7.1 量化：以精度换体积

• int8 动态量化（ONNX/torch）：体积约减 75%，精度损 1–3%，CPU 推理提速 1.4–2.1 倍。树莓派 4B 上 BGE 类由 2.1→4.7 QPS；Jetson Nano 由 8.3→15.6 QPS。
• int4 静态量化：内存再减半（8× 压缩），损 1–3%，须校准数据，宜 NPU/DSP 与极端边缘（手机、RPi）。
• 经验律：1B 参数 int8 约需 1GB、int4 约 0.5GB；故这些 <1B 之模型，端侧内存皆可控。

7.2 ONNX Runtime：跨端推理之枢纽

• 后端可选 CPUExecutionProvider / CUDA / TensorRT / NNAPI（安卓 NPU）/ CoreML（iOS ANE）。
• 导出：python -m transformers.onnx --model=. --feature=sentence_embeddings onnx/，再 quantize_dynamic 转 int8。
• 30 行 Flask 即可替代重型服务框架，树莓派、Intel NUC 无独显设备皆宜。

7.3 GGUF + llama.cpp：0.6B 级之轻装奔行

• Qwen3-Embedding-0.6B 已有 GGUF（q8_0 / f16），llama-embedding -m model.gguf -p "..." --pooling last 一行可跑，亦可启 llama-server --embedding 供 API。

7.4 transformers.js v4：浏览器即推理引擎

• 底层 ONNX Runtime，WebGPU（v4 以 C++ 重写，BERT 类提速约 4×）或 WASM 回退；支持 fp32/fp16/q8/q4。
• 首次下载自动缓存，此后离线秒级。BGE-small 浏览器内热身后单查询约 6ms；mxbai-embed-xsmall-v1、bge-small-en-v1.5(量化) 为前端语义搜索宠儿。
• 兼容 Chrome/Edge 113+、Firefox(WASM)、Safari 18+；iOS Safari 26+ 已开 WebGPU。

7.5 移动与嵌入式

• 安卓：onnxruntime-mobile + NNAPI 调 NPU；iOS：ONNX→CoreML 或 CoreML EP（computeUnits = .all）。
• 树莓派/ARM Linux：pip install onnxruntime（ARM64 wheel），int8 下单文本 ~50ms、内存 ~200MB，堪用。
• MCU/裸机：须 TinyML 与 int8 乃至更低比特，且将重任务上移边缘网关。

8. 按场景推荐：决策之树

需端侧 embedding？
├─ 设备极受限（浏览器缓存/树莓派/CI）？
│   ├─ 英文为主 → gte-small(70MB) 或 all-MiniLM(46MB)
│   ├─ 中文为主 → bge-small-zh-v1.5(139MB)
│   └─ 多语低价 → multilingual-e5-small(140MB)
│
├─ 个人/小团队 RAG（笔记本 CPU）？
│   ├─ 英文 → nomic-embed-text-v1.5(274MB)【默认起点】
│   └─ 中文/多语 → Qwen3-Embedding-0.6B(GGUF,~400MB) 或 bge-m3(1.2GB)
│
├─ 移动端/离线隐私优先？
│   └─ EmbeddingGemma-308M(<200MB RAM, EdgeTPU<22ms)
│
├─ 英文检索精度至上（短自含文档）？
│   └─ mxbai-embed-large-v1(670MB, MTEB 64.68)
│
└─ 中文长文档/跨语/代码检索？
    └─ Qwen3-Embedding-0.6B(32K上下文, C-MTEB 71.02)【当前综合最优选】

一句话心法：检索差，则 70B 对话模型亦产出劣答；检索佳，则 7B 亦可胜出。端侧之役，当先投资于"搜得准"，非"答得巧"。

9. 结论与趋势

• 小模型已非"将就"。Qwen3-0.6B 以六亿参数越诸多旧日巨模；EmbeddingGemma 以三亿参数于端侧多语居首。参数量之迷信，当休矣。
• 三技定乾坤：MRL（维度可截断）、长上下文（8K–32K）、量化（int8/int4）——三者令"小体积、大能力、低时延"得兼。
• 多功能成趋势：bge-m3 之稠密+稀疏+多向量混合检索，正成 RAG 新常态；框架不支援者，宜早迁。
• 端侧生态成熟：transformers.js v4（WebGPU）、ONNX 全端、GGUF/llama.cpp、TFLite/LiteRT/MLX，部署路径四通八达，隐私优先之应用可期。
• 选型铁律：先定场景（语、文长、精度、设备），再秤体积与维度，末论基准分数。分数高而上下文短者，长文必截尾；体积小而无多语者，跨语必失灵。

夫 embedding 者，RAG 之舟也。舟小则轻、舟固则稳。善渡者，不惟求大，惟求宜其水。步子哥据此四档十五模，当可择一舟，泛于端侧之沧海矣。