同一台16GB MacBook Air，密集嵌入跑到重启，SPLADE显存不到1.5GB
先看显存占用
SPLADE 是稀疏检索模型，思路接近 BM25，但会用上语义信息。作者把它塞进自己的本地文档搜索流程，替掉了原来的密集嵌入模型 Qwen3-Embedding-0.6B。差别最直观的地方是体积：SPLADE 推理时占用不到 1.5GB 显存，MacBook Air 这种小型系统就能跑。
同一台机器上的对照
测试机是一台 M5 MacBook Air，16GB 内存。同一个任务里，密集嵌入模型几乎没法用，机器很快因为高温重启。换成 SPLADE 之后，全程没有出现内存不足的错误或警告。速度没慢下来，效果反而更好：查询速度相近，SPLADE 表现超过 Qwen3-Embedding-0.6B，内存占用少得多。
评估数据集是作者自己搭的，几百条查询。语料是他 Mac 上的全部文档，韩文为主，掺少量英文。
用的是 KURE-sparse-nano
作者用的不是原始 SPLADE，而是 KURE-sparse-nano，这个模型在英文和韩文上都表现不错。整套实现已经开源：模型的推理优化、代码，还有 LanceDB 索引和用 Rust 写的倒排索引。倒排索引是为了让搜索更快。想复现的人不用从零搭起。
混合方案反而更差
有个不太符合直觉的结果：SPLADE 加密集嵌入的混合检索，效果比单用 SPLADE 还差。想省事的人反而好选了，不用同时维护两套检索。
评论区的基准与疑问
有人贴出 BEIR-13 上的分数：KURE-Sparse-nano 53.2，低于 SlideOn 的 58.7、KURE-Sparse-base 的 58.6 和 linkup-sparseup-embed-v1 的 58.1。有人补了一句，SlideOn 可能更好，因为它更小，不过稀疏性也得算进去。
评论区还留着几个没回音的问题：能不能拿来搜照片和音频，而不只是文本文档；有没有和 Gemma Embed 2 比过；能不能在别的语言上训练。作者自己给的适用场景是低资源的本地环境——想要一套快、便宜的本地 RAG 系统，值得试一试。一位评论者说自己在做本地学术检索代理，这个模型正好合用。
作者的评估语料只覆盖韩文和英文，其他语言什么表现，得自己搭起来测。
关键事实
- SPLADE 是一种稀疏检索模型，类似 BM25 但利用语义信息。
- 作者用 SPLADE 模型替换了密集嵌入模型 Qwen3-Embedding-0.6B。
- 作者构建了一个包含几百条查询的评估数据集，语料库是 Mac 上的文档，主要是韩文和部分英文。
- 在作者的实验中，SPLADE 在查询速度相近的情况下，性能超过了 Qwen3-0.6B 密集嵌入模型，且内存占用少得多。
- SPLADE 模型推理时占用不到 1.5GB 显存，因此可以在 MacBook Air 这类小型系统上运行。
- 作者在 M5 MacBook Air 16GB 上测试，密集嵌入模型几乎无法使用，导致 MacBook 因高温重启；而 SPLADE 模型全程无内存不足错误或警告。
- SPLADE 与密集嵌入的混合检索效果实际上比单独使用 SPLADE 更差。
- 作者推荐在低资源本地环境中尝试 SPLADE 模型来运行快速且经济的本地 RAG 系统。