EVIE-8B 对比 EVIE-Preview-4.5B：32 倍更宽向量带来 1.39 分提升

在腾讯发布 EVIE-Preview-4.5B 并称其为 ViDoRe 排行榜上最准确的视觉文档检索器三周后，腾讯又发布了 EVIE-8B，并悄悄挪动了自家 128 维模型所依存的评分标准。EVIE-8B 是 8.41B 的旗舰教师模型，采用 4096 维的逐 token 嵌入；EVIE-Preview-4.5B 则是 4.54B 的紧凑型检索器，其核心卖点一直是 128 维就足以击败体积四倍于自己的模型。在 EVIE-8B 模型卡内的刷新版排行榜上，EVIE-Preview-4.5B 如今在其自家产品系列中仅列第三——排在新的 EVIE-8B 之后，也排在腾讯同一天早上发布的蒸馏模型 EVIE-4.5B 之后。如果你正在考虑用这两个已命名模型中的哪一个来索引文档语料库，腾讯模型卡上的数据表明，8B 在 ViDoRe V3 上高约 1.39 分，在 ViDoRe V2 上高 3.36 分——但要达到这一水平，每个向量的索引空间成本要高出 32 倍。本文探讨的是这种取舍是否值得，并且首先坦承：两份评分表都是腾讯自己的，均未经独立复现。

简短版本

• 如果检索精度是瓶颈，且你的语料库足够小，原始索引大小无关紧要——你的规模以数千页计，而非数百万页——并且你想要腾讯发布的最佳开源检索器，那么选择 EVIE-8B。

• 如果索引成本、每页延迟或 GPU 预算是实际约束，请选择 EVIE-Preview-4.5B——它的 128D 向量正是其存在的全部理由；它在 ViDoRe V1 上与 8B 的精度差距很小，在 V3 上差距中等。

• 在提交前，请同时对照 EVIE-4.5B 重新检查两者：腾讯发布了一个同日推出的学生模型，具备运行时截断向量和 token 压缩，在效率前沿上使两者都相形见绌；任何忽略它的对比都已然过时。

• 此处所有数字均视为厂商自报。EVIE-8B 尚未被腾讯以外的任何人运行过；EVIE-Preview-4.5B 的数据来自腾讯自己的复现脚本。

它们实际不同的地方

• 参数 — EVIE-8B：8.41B。EVIE-Preview-4.5B：4.54B。

主干网络 — Qwen3.5-9B（全双向注意力）对比 Qwen3.5-4B（交错式 GatedDeltaNet 线性注意力与全注意力）。

• Embedding — 4096维逐词元多向量对比原生128维逐词元多向量，两者均使用MaxSim后期交互进行评分。

• ViDoRe V1（10个任务，nDCG@5）— 92.18 对比 91.73。

• ViDoRe V2（4个任务，nDCG@5）— 74.23 对比 70.87。这是最大的相对差距。

• ViDoRe V3（48 个任务，nDCG@10）— 66.75 对比 65.36。

• 那些标题数字背后的视觉令牌预算——EVIE-8B 评估为每页 1,024 个令牌，而 EVIE-Preview-4.5B 的主打档次为每页 1,792 个令牌（在其 768 令牌的训练档次下，预览版取得了 64.56 的成绩）。

• 每100万页的原始BF16索引 — EVIE-8B未发布，而预览版在每页768个token时为179.2 GiB，在每页1,792个token时为420.5 GiB。

• 许可与发布 — Apache-2.0，于 2026-09-04 静默发布，对比 Apache-2.0，于 2026-08-17 静默发布。

上方的记分板重申了同样的描述。阅读时请留意两点提醒：EVIE-8B 列和 EVIE-Preview-4.5B 列来自腾讯的两份不同模型卡；而 8B 的 V3 头条数字是在低于预览版头条数字的每页视觉令牌预算下测得的。

两张腾讯卡，在互相交谈

对这场对决最诚实的定位是：这是一场家庭内部的争论，而不是一场独立的较量。EVIE-Preview-4.5B 自己的模型卡（8 月 17 日发布）声称“在 ViDoRe V3 上排名第一”，成绩为 65.36 nDCG@10，比 webAI-ColVec1.1-8b 高出 0.04。EVIE-8B 的模型卡（9 月 4 日发布）把同一个 65.36 重新列为该页面上的第三好成绩，低于 EVIE-8B 的 66.75 和 EVIE-4.5B 的 66.02，并显示 8B 在 ViDoRe V3 的全部八个公开领域上都击败了 preview 版本。两份成绩单都由腾讯自家的评测框架产出，而这两款模型在已有文献中都还没有任何独立的评测记录。所以，你正在读到的这场对比，就是腾讯对“腾讯击败腾讯”的自我叙述——内部自洽，很可能是刻意设计成这样，并且从未得到任何利益无关方的验证。

上面的tencent/EVIE-8B卡片是挑战者的公开界面：一个具有4096维嵌入的8.41B旗舰教师模型，以及家族页面顶部更新的ViDoRe表格。

上方 tencent/EVIE-Preview-4.5B 的模型卡属于当前在位者：一个 4.54B 检索器，其原生 128D 向量和已发表的索引成本计算仍是其标志性特征。

1.39分的问题

ViDoRe V3 上的原始差距很小——EVIE-8B 的 66.75 与 EVIE-Preview-4.5B 的 65.36 之间仅差 1.39 个 nDCG@10 分——但这还附带一个对部署至关重要的 token 预算前提。EVIE-8B 的评估协议将每页文档限制为 1,024 个视觉 token；而预览模型需要每页 1,792 个 token 才能取得其标榜的 65.36 分，在自身 768 token 的训练预算下则只拿到 64.56 分。从这些数字来看，8B 不仅在相近预算下更准确——它在更小的预算下也更准确，而这正是每页延迟所希望看到的方向。更大的相对优势体现在 ViDoRe V2 上：EVIE-8B 报告得分为 74.23，而预览模型为 70.87，在包含更难合成文档任务的该榜单上提升了 3.36 分。ViDoRe V1 是最古老、也最饱和的榜单，几乎没有什么变化：92.18 对 91.73。这种模式——在大家都已接近天花板的任务上增长平缓，在更新更难的任务上表现决定性优势——是真实能力提升而非榜单噪音的特征，但它仍然是腾讯自己对这一能力的测量结果。

指数才是真正的对手

准确性只是这个决定的一半，因为这两个模型对于你要存储什么做出了截然不同的承诺。EVIE-Preview-4.5B 存在的理由是其原生的 128 维 token 向量：模型卡公布了精确的索引计算（在其训练预算下，每百万页对应 179.2 GiB 原始 BF16 索引，按外推层级计算则为 420.5 GiB），并指出更窄的向量会按比例直接削减存储量和 MaxSim 评分计算量。EVIE-8B 的 token 向量是 4096 维——单个向量宽度是前者的 32 倍——而 EVIE-8B 的模型卡却完全没有公布任何索引大小的数据。这种省略本身就是信息：在每页 token 数相同的情况下，原始 BF16 EVIE-8B 索引的规模约为预览版的 32 倍，这使得百万页规模的语料库在量化之前就达到数 TB 量级，也让这款旗舰模型只能面向几十万页的规模，而不是那种可以随意大规模托管的东西。旗舰模型的宽度换来的是检索保真度，换不来可部署性。

腾讯于当天发布的第三个选项

任何诚实的对比都不会止步于标题中的这两个模型，因为包含 EVIE-8B 的那次发布同样也带来了 EVIE-4.5B——一个从 8B 教师模型蒸馏出来的 4.61B 学生模型，使用单一的 2048 维投影，可在运行时截断为 64、128、256、512、1024 或 2048 维；此外还有一道腾讯称之为 HAC 的免训练 token 压缩流程，把页面视觉 token 聚类压缩到 32–64 个向量，且据模型卡，索引占用为每百万页 3.81 GiB。在腾讯自己的评测表中，EVIE-4.5B 在 ViDoRe V3 上得分 66.02——仅落后 8B 教师模型 0.73，领先 EVIE-Preview-4.5B 0.66——这恰好回答了这场对决所提出的那个两难问题。如果你想要的是“没有 8B 索引负担、却有 8B 大部分精度”的模型，腾讯已经把它发布出来了，而它既不是本页标题点名的两个模型中的任何一个。EVIE-Preview-4.5B 的立足之处虽然狭窄，但真实存在：对任何在 8 月部署它的人来说，它已经是正式上线运行的那个检查点；而且它固定的 128D 配置比那种需要你在运行时自行选择维度的 matryoshka 式模型更容易把握。

你应该用哪个进行索引

将模型与真正起作用的约束条件匹配：

• 在 EVIE-8B 处建立索引，如果您正在构建准确性参考点——无论是基准测试、数十万页规模的高价值法律或科学语料库，还是检索遗漏代价高昂且存储成本低廉的系统。您支付的是该模型家族曲线顶端的性能，而该家族希望您日后扩展的是 4.5B 学生模型。

• 如果你已经用 EVIE-Preview-4.5B 建过索引，并且测得的质量可以接受，那就继续用它——重新索引的成本是实打实的，而你去追的 V3 增益只是某个厂商卡上的 1.39 分，而这个分数还没有任何人独立证实过。

• 如果你要在一个有意义的规模上从零开始，那么在这两者之前先评估 EVIE-4.5B。Prefix-MRL 截断和 HAC 压缩直接针对上述存储运算，腾讯自己的数据表明它已接近教师模型的水平。

这三个方案都没有在任何平台（包括OrcaRouter）上提供托管API，因此检索阶段无论怎么选都得自托管。其后的阶段则不必如此。像OrcaRouter在200多个模型上运行的那类路由器，可以把读取你检索到的页面并撰写答案的模型统一放在单一API后面，跨提供商自动故障转移，并将提供商列表价格以0%加价原样传递——当给它供数的检索器只是一个三天前发布的检查点、其说法尚未得到核实时，这正是你需要的架构。用适合你存储的检索器构建索引，并让流水线其余部分保持可替换，直到腾讯之外有人确认这些评分卡中哪一张才是真的。