AI 博客

OpenAI、Cohere、Voyage 与 Qwen3:那个换不起的模型

换掉 LLM,改的是一段提示词。换掉嵌入模型,要重嵌整个语料、重建索引,并让你手上所有检索数字全部作废——两个模型产出的向量彼此不可比,因此不存在渐进迁移。这让它成为 RAG 栈里唯一一个在锁定状态下做出的选择,而真正定案的数字是每条向量占多少字节、以及模型的生命周期由谁掌控,不是排行榜名次。

作者 智能体 AI 维基 27 分钟读完

换掉 LLM,改的是一段提示词。换掉嵌入模型,要重嵌整个语料、重建索引,并让你量过的每一个检索数字统统作废——两个模型产出的向量身处不同的空间,彼此无从比较,因此既没有渐进迁移,也没有哪个 A/B 试验能比迁移本身更便宜。这是检索栈里唯一一个在锁定状态下做出的选择,正因如此,定案的数字是每条向量占多少字节、以及模型的生命周期由谁掌控。排行榜名次,是桌上最没用的那个输入。

先看全貌

四个模型,覆盖 2026 年真正可选的四种姿态:人人手上已有密钥的既定选项、多模态的那个、专门盯着存储账单的那个,以及那个你可以放进自己硬盘、从此不会弄丢的。

模型获取方式默认向量标价
OpenAI text-embedding-3-large 第一方 API;Azure 3072 维,float32 —— 12 KiB $0.13 / 百万 token
Cohere Embed v4 Cohere API、Bedrock、Azure AI Foundry、SageMaker 1536 维,float32 —— 6 KiB 文本 $0.12 / 百万 token;图像 $0.47 / 百万图像 token
voyage-3.5 Voyage API;也可经 AWS Marketplace 与 Azure 2048 维,可选 int8 —— 2 KiB $0.06 / 百万 token
Qwen3-Embedding-8B 开放权重,Apache-2.0 最高 4096 维,float32 —— 16 KiB 你的 GPU,你的电费
Where each embedding model leans hardest A four-by-five grid comparing maximum input length, output dimensions, sub-float output types, non-text input and lifecycle control across OpenAI text-embedding-3-large, Cohere Embed v4, voyage-3.5 and Qwen3-Embedding-8B. Cohere leads on input length and images, voyage on compressed output, Qwen3 on lifecycle control, and OpenAI leads on nothing except ubiquity. Five axes, four models Max input per request Output dimensions Sub-float output Non-text input Lifecycle control OpenAI text-embedding-3-large ~8k tokens 3072 default, shortenable float only Text only Vendor's clock Cohere Embed v4 128k tokens 256 to 1536 int8, uint8, binary Images, inline with text Vendor's clock Voyage AI voyage-3.5 32k tokens 256 to 2048, Matryoshka int8, uint8, binary Text only Vendor's clock Qwen Qwen3-Embedding-8B 32k tokens up to 4096 Whatever you write yourself Text only Apache-2.0, frozen on disk Clear advantage on this axis Adequate Constraint you will feel
没有谁在每一根轴上都领先,而这些轴对你的承重也并不相同。

其中两格值得读两遍。Cohere 的 128k 输入与 OpenAI 的约 8k 不在一个数量级上,它改变了"一个块"被允许长成什么样。Qwen3-Embedding-8B 在 Qwen 于 2025 年 6 月发布时以 70.58 分位居 MTEB 多语言榜首——它也是这里唯一一个你可以把权重钉住、镜像下来,到 2031 年仍原封不动运行的模型。

只做一次的那个选择

What changing an embedding model actually touches The source corpus feeds two parallel embedding passes. The old model's index keeps serving live query traffic while the new model's index is built and shadowed, so both indexes are resident at once. Downstream, chunk size, top-k, reranker thresholds and every retrieval eval baseline have to be re-established against the new vector space before traffic can cut over. Source corpus every chunk, read again Embed pass model A, already paid Index A serving every query Embed pass model B, full corpus Index B shadow, unproven Query traffic unaware, unpaused Re-established against the new vector space before cutover, none of it transferable: chunk size · top-k · reranker threshold · hybrid weights · every retrieval eval baseline
两套索引同时驻留,而向量空间下游的一切都无法沿用。

两个模型,两个空间,中间没有桥

嵌入是某一个模型在训练中自行发明的空间里的一个坐标。把模型 A 的向量与模型 B 的向量做余弦相似度,不是信号弱,而是范畴错误——就像拿纬度去比华氏温度。你学不到一个便宜的投影来修好它,没有让两个模型同时服务同一索引的双写期,也没有办法只迁移语料的百分之十然后测一测。变更的单位是整个语料。

相比之下,栈里其他每一个部件都退化得优雅得多。生成模型可以挂在路由后面、在线上流量里评估。重排序器坐在检索之上,随时可以关掉。向量数据库可以双写,再按集合逐个切换。只有嵌入模型的迁移是原子的,而它的回滚只有一句话:你有没有把旧索引留着。

账单不是问题所在

人们把这场迁移当成一笔 API 费用来估价,而那是小的一半:

# 20M chunks at ~400 tokens each
tokens = 20_000_000 * 400          # 8.0e9

# The embed pass, at list price
openai_3_large = tokens / 1e6 * 0.13   # $1,040
voyage_3_5     = tokens / 1e6 * 0.06   # $  480

# The part that is not the bill:
#   both indexes resident until cutover  ->  2x vector storage
#   every retrieval baseline             ->  re-measured from zero
#   top-k, reranker cut-off, hybrid mix  ->  re-tuned per index
#   rollback                             ->  only if you kept index A

一千美元不算什么。真正的价格是:一个工程师花六周重新调 top-k 与重排序阈值,重新标注黄金集——因为旧的相关性判断是对着另一批邻居做出来的——再去为一个让部分查询变差的改动辩护。团队回避重嵌,不是因为它以美元计昂贵,而是因为它以信心计昂贵。

于是这个选择只朝一个方向复利

既然迁移这么别扭,理性的做法就是挑那个你不会长出其约束的模型,而不是本季度领先 1.5 分的那个。日后会咬人的约束是输入长度(你会想要更大的块)、输出宽度(你会想要更小的占用)、模态(总会来一份扫描件)与生命周期(模型总会被弃用)。而质量排名——每一篇对比文章都拿它开头的那个——恰恰是最能自行消化的约束:两分的检索差距会在你修好分块之后自动收窄,它永远不会变成一次迁移。

四个模型,各自到底是干什么用的

OpenAI text-embedding-3-large——不再是前沿的那个默认项

它出现在每一份教程、每一个框架的默认配置里,而且你的团队本来就有它的密钥。它同时也是这场对比中最宽的向量:3072 维 float32,输入上限约 8k token,只收文本,只出浮点,每 token $0.13 也是最贵的。Matryoshka 训练意味着你可以只要 1024 维或 256 维,按比例削掉存储而质量损失有限——但多数团队从没这么做过,因为默认值能用,而向量库那笔开销没人认领。

当检索只是配套功能而非产品本身、语料小到存储只是零头、而且"谁都不必去做评测"的价值高过那点差距时,选它。这是真实且常见的处境。只是要让它成为一个决定,而不是一个默认。

Cohere Embed v4——把一整条流水线删掉的那个

Embed v4 在同一个请求里接收文本与图像、可交错排列,输入窗口 128k token,输出维度可在 256 到 1536 之间配置,并支持 int8uint8binary 输出类型。文本每百万 token $0.12;图像单独计费,每百万图像 token $0.47。

选它的理由不是某个基准上的差值,而是一张幻灯片、一张图表、一份扫描发票或一帧截图可以按它本来的样子被嵌入,而不必先推过一条 OCR 加版面重建的流水线——那条流水线你之后要自己拥有、监控,并在解析器升级时整批重跑。如果你的语料确实是视觉性的,Embed v4 从你的架构里移走了一整个子系统——而少一个子系统,任何时候都胜过两个百分点的 nDCG。如果你的语料是纯文本,那你就是在为一项永远不会调用的能力付出 voyage-3.5 两倍的价钱。

voyage-3.5——那个读得懂存储账单的

voyage-3.5 通过 Matryoshka 学习支持 2048、1024、512 与 256 维,输出可选 float、int8uint8binaryubinary,输入窗口 32k,标价每百万 token $0.06,是这里最低的。Voyage 自己给出的推荐组合——2048 维 int8——相对 3072 维 float,把向量数据库成本降低 83%,且检索质量更高。这个说法里成本的那一半不是基准,是除法:2048 字节比 12,288 字节,正是 83.3%,你拿计算器就能验。

质量的那一半是厂商在自家评测上给出的数字,就该按厂商数字来看待。但要紧的是这种不对称:只要质量的说法能做到并不更差,仅凭存储的算术,就足以为任何大到有一笔向量库开销的语料定下这道题。

Qwen3-Embedding-8B——那个你可以冻住的

Apache-2.0 权重,最高 4096 维,32k 输入窗口,100 多种语言,并在 Qwen 于 2025 年 6 月发布时以 70.58 分登上 MTEB 多语言榜首。它同时也是 80 亿个你从此要自己服务的参数:取满宽度时每条向量 16 KiB,跑在你为一个天然呈突发形态的嵌入负载所准备的硬件上——服务时清闲,重建索引时打满。

你不是为了榜单名次而选它。你选它是为了 API 一侧永远给不了的那一条性质:这个模型不会在你脚下被弃用。存在自家存储上的一份检查点,才是唯一真正扣得住的版本锁;而对于一份你打算保留十年的语料,这与"每百万 token 多少钱"根本不是同一类论证。同一家族里 0.6B 与 4B 的成员之所以存在,正是为了让这种姿态不必配上一份 8B 的服务预算。

横向对照

存储是那根会复利的轴

Bytes stored per vector at each model's default output Horizontal bars comparing storage per vector: Qwen3-Embedding-8B at 4096 float32 dimensions needs 16,384 bytes, OpenAI text-embedding-3-large at 3072 float32 needs 12,288 bytes, Cohere Embed v4 at 1536 float32 needs 6,144 bytes, and voyage-3.5 requested as int8 at 2048 dimensions needs 2,048 bytes — an eight-fold spread before any quality argument is made. Bytes per vector, at each model's default output 4 KiB 8 KiB 12 KiB 16 KiB Qwen3-Embedding-8B 4096 dims, float32 16,384 B OpenAI text-embedding-3-large 3072 dims, float32 12,288 B Cohere Embed v4 1536 dims, float32 6,144 B voyage-3.5 2048 dims, int8 2,048 B Same corpus, same index, same query path — eight times the storage from top row to bottom
从最上一行到最下一行,存储差了八倍——而这还没开始争论质量。

嵌入这一遍只收一次费;向量却要永远存下去,而在托管型向量数据库上,价格是"驻留字节数"与"被搜索字节数"的函数。按四家的默认设置,同一份两千万块的语料在取满宽度的 Qwen3 下是 328 GB 原始向量,OpenAI 下 246 GB,Cohere 下 123 GB,voyage-3.5 取 int8 时 41 GB。这个差额压根不会出现在模型的账单上——它出现在另一家厂商的账单上,而这正是它能在如此多的模型对比里一声不响活下来的原因。

四家里有三家在这里给了你一根杠杆,而且几乎不费力就能拉动:Matryoshka 训练让缩短的向量优雅退化而非断崖式崩坏,量化感知训练则让 int8 输出在质量上近乎白送。存储花得最多的团队,几乎总是那些从没传过 dimensionsembedding_types 参数的,而不是那些挑错了模型的。

质量差距小于你的分块差距

在任何一个公开检索基准上,这四个模型都会彼此相差几分之内,而排序会随基准、领域与语言而重排。与此同时,一个朴素的 512 token 定长分块器与一个尊重文档结构的分块器之间的差距,通常大于这里最好与最差模型之间的差距——而"有没有重排序器"的差距还要更大。如果你还没调过分块,那这场模型对比测的是你的分块器。

这也是 MTEB 名次不适合当首要输入的原因:它是一份如今模型在训练时已经知道其存在的排行榜,任务不是你的任务,而聚合方式又恰好盖住了你在意的那个领域。用它挑出三个候选;再用你自己语料里的 200 条查询、你自己的相关性判断在三者之间定夺——那是两天的活,也是唯一能迁移的测量。

多模态是一次穿着基准外衣的架构变更

这里只有 Cohere 收图像。这读起来像矩阵里的一行,实际却是流水线上的一个岔口。纯文本那条路需要一个解析阶段——OCR、版面重建、表格抽取、图注生成——它有自己的失败模式、自己的厂商、自己的账单和自己的升级跑步机,而且它悄悄决定了你的检索天花板,因为解析器丢掉的信息,下游没有任何环节能找回来。直接嵌入页面与其说让这个问题消失,不如说把它挪进了一个你不必运维的模型内部。

诚实的附带条件是:它也让故障变得不透明。解析器把表格弄坏了,你还能去看那份解析结果;多模态嵌入漏掉了图表角落里的那个数字,你就没有任何东西可查。当你的文档确实是视觉性的时候走这条路,而不是因为它听起来更现代。

生命周期:那个你熬不过去的弃用

生成模型退役时,你改一个字符串、重跑评测、吸收一些行为漂移。嵌入模型退役时,你要重嵌整个语料——正是本文通篇在讲的那场迁移,只不过按厂商的日程而不是你的日程。这里每一个 API 模型都带着这份敞口;开放权重的那个没有,因为硬盘上的一份检查点没有生命终止日期。这是检索层选择开放权重的最强论据,而它与成本或隐私毫无关系。

如果你留在 API 上——多数团队也该如此——缓解办法是让重嵌所需的原料常备:把块文本与向量存在一起,而不是只留在源系统里;让嵌入作业能从零冷启动跑通;让检索评测集进版本库、并且一个下午就能重跑。手里握着这三样的团队,能在一周内消化一次被迫的迁移。没有的团队,会在弃用窗口期里发现自己重建不出自己的索引。

什么情况选哪个

处境因为
检索只是一项功能,语料不到几百万块OpenAI text-embedding-3-large那点差距回不了本你花在评测上的时间。传个 dimensions=1024,然后继续干别的。
语料是幻灯片、扫描件、截图、图表Cohere Embed v4它删掉解析子系统,而不是优化它;而 128k 输入让一个块可以就是一份文档。
几千万块,且向量库账单已经看得见voyage-3.5,取 int8每 token 单价最低,字节数只有四分之一;存储上的节省远大于 token 上的节省。
数据驻留、物理隔离,或一份要服务十年的语料Qwen3-Embedding-8B唯一没有弃用日期的选项。除非你已量出确需 8B,否则从 0.6B 或 4B 起步。
重度多语言,尤其是非拉丁文字把 Qwen3 与 Cohere 一起列入候选,用你自己的查询定夺多语言排名在不同基准间波动最大,所以这恰恰是公开数字最迁移不过来的情形。
你还没调过分块一个都别选——先修分块否则这场对比测的是你的分块器,而且你反正之后还得再重嵌一次。

常见问题

我能不能一个集合一个集合地渐进迁移嵌入模型?

如果你的语料被切成一批彼此从不联合检索的索引,那你可以一次迁一个索引。但你不能在同一个可检索空间里混用模型:来自不同模型的向量之间的相似度是没有意义的,所以一个迁到一半的索引,在它还没赶上的那一部分上返回的就是噪声。

向量更小是不是一定意味着检索更差?

不是等比例地差。用 Matryoshka 表示学习训练的模型会把最重要的信息集中在靠前的维度上,因此截断带来的是缓和的退化;而量化感知训练又让 int8 输出在质量上近乎白送。请在你自己的查询上测:从 2048 float 到 2048 int8 的损失通常远小于团队的预期,而存储的节省恰好是四倍。

MTEB 名次是不是没用?

它用来排除有用,用来选型会误导。榜单上远远靠后的模型不太可能给你惊喜;而前十名之间的顺序,并不能预测哪一个会在你的语料上胜出。用它挑三个候选,然后花两天从自己的数据里建 200 条带标注的查询——那个测量才经得起生产环境的检验。

API 上的嵌入模型被弃用时,实际会发生什么?

你会拿到一个通知窗口,然后要在它关闭之前把一切重嵌一遍。没有哪种版本锁定帮得上忙,因为旧向量之所以还有效,仅仅因为那个能产出兼容向量的端点还活着。请把块文本与向量存在一起、让嵌入作业能从零冷启动跑通——否则那个窗口会让你发现自己重建不出自己的索引。

为了省钱该不该自建嵌入服务?

很少仅仅为了省钱。按每百万 token $0.06,一份八十亿 token 的语料嵌一遍只要几百美元,连一张 GPU 都买不来。为生命周期控制、数据驻留,或者确实极高的重嵌频率而自建——如果理由只是成本,那么一个 0.6B 模型跑在 CPU 机器上就已经足够便宜,8B 那个根本无关。

延伸阅读

本站相关:

资料来源: