模型抢头条的这八天，NVIDIA 悄悄换了 RAG 的地基

八天之内四个前沿模型发布，这个礼拜的 AI 圈热闹得像跨年。Kimi K3 冲榜，GPT-5.6 全家桶落地，榜单截图在各个群里飞来飞去，刷到后面人都有点麻了。

然后，在这堆头条的缝隙里，NVIDIA 发了一个几乎没人转发的东西。

一个 embedding 系列，叫 Nemotron 3 Embed。没有发布会，没有炫酷 demo，连一张能发朋友圈的对话截图都贡献不了，毕竟这玩意压根不会聊天。但如果你在公司搭过 RAG，或者正打算搭，我跟你说，这个发布跟你的关系，可能比上面那四个头条加起来都大。

很多朋友可能不知道 embedding 是干嘛的，一句话，它把一段文字压成一串数字向量，语义相近的文字，向量之间的距离就近。RAG（检索增强生成，先从你的知识库里查出相关资料，再把资料喂给大模型去回答）这条流水线里，负责「查资料」这一步的就是它。

NVIDIA 在发布里有句话我觉得说得挺准，embedding 模型决定了你的 agent 到底能「看见」哪些段落。

你想想看，生成模型再聪明，检索层把料喂错了，它也只能一本正经地基于错料胡说。线上 RAG 答得蠢，八成的锅在检索，不在生成。我干的活儿就是给大模型搭让它真正能干活的那层工程，这种车见得太多了，排查问题的人盯着 prompt 改了一下午，最后发现是召回的十条里八条不相关。地基歪了，楼上怎么装修都白搭。

而地基这一层，确实很久没有大新闻了。聊天模型每个月都在换代，embedding 圈子安静得多，很多团队的检索模型还是一两年前选型时定下的那个，一直没人碰，也没什么动力碰。

这次 NVIDIA 一口气开源了三个 checkpoint，算是把这潭水搅动了一下。

配置分三档。Nemotron-3-Embed-8B-BF16 是精度优先的大杯，Nemotron-3-Embed-1B-BF16 是同款设计的小杯，还有一个 Nemotron-3-Embed-1B-NVFP4，是给自家 Blackwell 显卡优化的 4-bit 版本。三个都支持 32768 token 的输入长度，在 34 种语言上做了评测，协议用的 OpenMDW 1.1，商用友好的宽松开源协议。

比较有意思的一个细节，基座不是 NVIDIA 自己的，是 Mistral 的。8B 建在 Ministral-3-8B 上，两个 1B 建在 Ministral-3-3B 上。老黄家卖铲子卖得风生水起，做模型倒是很务实，谁的基座好用就用谁的。

成绩单也硬。8B 版本在 RTEB 上综合排名第一，78.46 的平均 NDCG@10（衡量检索前十条结果排得准不准的指标，越高越好）。RTEB 全称 Retrieval Embedding Benchmark，是专门考察检索能力的榜，设计上就留了一部分不公开的任务集，防的就是公开榜被刷烂那一套。在这种榜上拿第一，含金量比普通刷分高一截。

更让我在意的其实是小杯。新的 1B 比上一代 1B 基线高出 10.4 个点，61.98 到 72.38。

好家伙，同一个体量，一代之间十个点。要知道 embedding 这种基础组件，平时半个点半个点地抠都算有进展，十个点基本就是换代级别的差距了。

这 10.4 个点是怎么来的，管线还挺讲究。1B 不是单独训了个小模型，是从一个 3B 的母版一路「压」出来的。先用神经架构搜索做剪枝（把网络里贡献不大的部分砍掉，搜索空间覆盖隐藏层宽度、注意力头数、深度这些），3B 剪到 2B，再让这个 2B 拜 8B 当老师做蒸馏（让小模型去逼近大模型的输出），然后同样的流程再来一轮，压到 1.14B。剪一刀，学一轮，再剪一刀，再学一轮。

这套组合拳打下来，小模型保住了大模型八九成的功力，有点子牛逼。

NVFP4 版本则是把压缩延续到了部署侧。4-bit 量化（把权重从 16 位浮点压到 4 位，显存占用大幅缩水，精度有损）之后又做了一轮量化感知蒸馏找补精度，最后只比 BF16 母版低 0.38 个点，保留率 99.5%，官方说在 Blackwell 上吞吐最高能翻倍。模型卡里还写了个挺实用的特性，2048 维的向量可以直接从头部截到 1024 或者 512 维，重新归一化就能用，存储紧张的时候这就是个现成的降档开关。

到这里都是官方发布的明面信息，各家科技媒体都会写。接下来聊点通稿里不会展开的，我看完材料之后替你算的三笔账。坦率讲，这三笔账才决定你该不该动心。

第一笔，推理账。

8B，对聊天模型来说是小个子，对 embedding 模型来说是巨无霸。过去大家生产上常用的 bge-large 这类模型，体量在 0.3B 上下，8B 是它的二十多倍。而 embedding 模型的工作方式是，用户每发一条 query，都得实时过一遍模型算向量，这是查询链路上绕不开的一跳。官方给 8B 列的测试硬件是 A100 80GB 和 H100 80GB，什么概念，你的检索入口从此要一张大卡常驻伺候。延迟和电费，都是每天在走表的。

第二笔，存储账。

8B 吐的是 4096 维向量，比 OpenAI 的 text-embedding-3-large 还宽一千维。向量库的内存是按维度线性走的，一笔粗账，1000 万个文本块，4096 维，fp32 存储就是 164GB，同样的库换 1024 维只要 41GB。知识库到亿级文本块的团队，光向量存储的差价就够买好几张卡了。精度涨的那几个点，很大一部分是拿这些真金白银换的。

第三笔，重嵌账。

这笔最容易被忽略。换 embedding 模型不是改个配置就完事的，新模型和旧模型吐的向量完全不兼容，整个知识库的每一段文本都得重新算一遍向量，全量重建索引。库大一点，这就是以天计的 GPU 时长，外加切换期间新旧索引并行的双份存储。更妙的是，官方自己在用例里推荐了成本分层玩法，高频简单 query 走 1B，难 query 路由到 8B，听着很美，但 1B 是 2048 维、8B 是 4096 维，两套向量互不相认，你得维护两套索引。账单请自行乘二。

顺手再补一刀 NVFP4 的适用面。它不支持 sentence-transformers 直接加载，得走 vLLM 起服务，那个翻倍吞吐是在 Blackwell 架构上测出来的。你手里那张 3090，跟这个版本基本没有缘分。

还有个提醒，78.46 是在 RTEB 的 16 个公开任务、4096 序列长度下测的。榜单不知道你的领域数据长什么样，法律条文、医疗记录、内部工单，都可能跟榜单分布差得远。倒是有一点对程序员挺友好，它的训练数据里明确塞了 SWE-bench、text2sql 这类语料，自然语言查代码这个场景算是分布内任务，代码检索的老大难问题，这次是被正经照顾到了。

那么，到底要不要动。我自己的感受是，分三种情况。

新起的 RAG 项目，Nemotron 3 Embed 直接进候选短名单，不用犹豫。尤其三类场景，多语言知识库（检索是跨语言的，官方举的例子是德语 query 能召回日语工单的解决记录）、代码检索、agent 长期记忆（32768 的输入长度够把一整段对话摘要直接压进向量，不用切得稀碎）。

存量系统跑得好好的，别为榜单上两个点把全库重嵌一遍。重嵌账和双索引账摆在那里，这钱花下去用户大概率毫无感知。

真想升级的，我的建议是盯 1B-BF16 这个甜点位。比上一代高 10 个点是实打实的代差，2048 维的存储压力只有 8B 的一半，还能用 sentence-transformers 直接加载，encode_query 和 encode_document 两个方法连前缀都帮你自动加好了。说实话我也不确定它在你的领域上还能不能保住榜单优势，动手前拿自己的真实 query 集跑一轮召回对比，比看任何榜单都靠谱。

头条这种东西，注定是聊天模型的。embedding 不会说话，不出圈，永远上不了热搜。

但船就是这样，岸上的人看的是帆，吃水线下面的船壳才决定它沉不沉。地基换代的日子，值得从头条的缝隙里捞出来，记上一笔。