用8年时间将向量数据库做到极致后，我们为何又推出了Vector Lakebase ？
Zilliz 在2019 年正式开源Milvus，成为全球第一家向量数据库企业时，行业对向量搜索的认知，还是给图片、文本、商品、文档算一个 embedding，然后查语义相似，只要能跑起来，就万事大吉。
但我们一直相信，这些产品行为、用户内容、企业知识库、实验数据、历史对话、Agent 记忆，始终是一个企业最宝贵的数据资产。只要一种数据会被持续写入、长期保存、反复查询，并且会影响线上体验，它就应该需要独立的存储、索引、调度、隔离、容灾恢复和成本模型。
也是因此，向量数据的管理，不该只是一个功能，作为一种会影响未来企业发展质量的新的数据形态，它需要一个专门的产品，将它的性能、体验、门槛，做到极致。
而过去8年多时间里，我们也一直在深耕这件事。产品结构上，我们从单机走向分布式，从本地走上云端。能力上，我们优化了很多细节：量化，索引结构，缓存，预取，冷热分层。
通过将数据加载到本地缓存，向量检索的速度，已经可以做到百亿数据毫秒级检索，Milvus与Zilliz Cloud成为了向量数据库极致性能的代名词。
但现实商业世界中，永远存在成本、性能、体验的不可能三角。在传统向量检索架构里，只要数据要保持随时可查询，背后就需要计算与内存资源持续在线。 但极致的在线检索性能，真的是所有场景下的必需吗？
现如今，冷数据的占比正越来越高。有时候，一次 A/B 实验结束后，相关 embedding 可能很少再被访问。一个 SaaS 产品里，大量用户不会每天登录。企业知识库中，很多文档几个月都不会有被检索需求。自动驾驶的数据训练，一批数据，我们往往每个月只需要使用一到两次。
在这些场景，一个集合也许一个月只被查询几次，运行时间不超过5小时，用户也并不需要为此投入向量数据库级别的资源建设，让高性能资源一个月时间里有715小时都被浪费。相应的，成本也就成了这一场景下的优先考量要素。
而解决这一问题，也是我们选择在近期推出Vector Lakebase 产品的初心所在。
传统向量数据库，是如何保持高性能在线检索的？
传统向量数据库的架构，本质上是为高频使用的在线服务优化的。而低延迟的向量搜索，需要索引尽量靠近计算，以CPU内存、本地磁盘存储之类的形式存在。
以 HNSW 为例，它是用内存和计算，换取更低查询延迟的典型代表。在HNSW，查询并不是顺序读取一个文件里的所有向量，而是从图中的入口节点开始，沿着更接近查询向量的邻居逐步跳转。在这个过程中，系统不断计算查询向量与候选节点的距离，并更新候选集，一次查询通常需要跳转、计算数百个节点。
如果上百步的读取，每一步都跨网络去S3为代表的对象存储读取，S3本身几十毫秒的远程 I/O 会被重复放大，最终让查询延迟远远超过在线服务可接受的范围。
也是因此，一个典型的向量数据库架构是这样的：S3 只负责保存完整数据，但真正服务在线查询的，通常是 QueryNode 本地的内存、磁盘和缓存。一个 collection 想要随时响应查询，就需要提前把 segment 和索引从S3加载到 QueryNode。
在此模式下， 1 亿条 768 维 float32 向量，其原始向量大约 286 GB。如果使用 HNSW，M=48 的图结构还会带来约 55 GB 的邻居链接，使得整体数据和索引接近 340 GB。
然后传统 QueryNode 模型，通常会把这些数据拆到3台在线的128G的机器上，以24,000 美金的年费，保证其高性能的实时在线检索效率。
100M × 768 维 float32
原始向量 + HNSW 图结构
总量约 340 GB
QueryNode 1：128 GB RAM + NVMe，加载约 113 GB segment
QueryNode 2：128 GB RAM + NVMe，加载约 113 GB segment
QueryNode 3：128 GB RAM + NVMe，加载约 113 GB segment
S3 保存完整 340 GB 数据，作为 source of truth。
QueryNode 把 segment 和索引加载到本地，并提供查询服务。
但问题是，对于我们开头提到的那种一个月只加载一次的数据，其实并不需要如此高性能的配置。
那有没有可能，把向量数据放在 S3 ，让查询与计算能自动按需启动、按需加载、按需释放？每个月用多久、用多少，就按照实际使用的资源计费？同时还能保证过滤搜索、语义检索、权限设计，以及在工作负载高峰期的检索效率。
答案是可以，这正是 Vector Lakebase 要解决的问题。
实现Vector Lakebase按需搜索，为什么这么难？
过去的向量搜索，为了保证在线响应效率，必须把数据可查询、 计算资源常驻绑定在一起，
而Vector Lakebase 要做的，就是把这两件事解耦：让数据可以常驻在对象存储；计算服务按需启动与释放。
对于热数据，系统仍然可以always-on serving。索引常驻本地，查询路径最短，目标是低延迟、高 QPS 和稳定 P99。
对于冷数据，系统可以使用 on-demand search。让数据和索引持久存在对象存储里。查询发生时，再启动计算资源，加载必要的索引元数据和相关数据块，完成搜索后释放资源。
但要达到这个效果，需要克服冷启动速度、单次查询总量可控、 I/O 放大以及控制平面成本等至少四大问题。
第一关：如何解决海量原始索引的冷启动效率
如果按传统方式处理冷数据查询，那么340 GB HNSW 索引，光是从S3拉起到本地，所需的冷启动时间就会直接超过 4 分钟。用户发起一次搜索需要等几分钟，产品体验约等于零。
所以 Lakebase 要解决的第一个问题，是如何让冷数据尽快进入可搜索状态。为此，我们做了三大针对性优化。
优化一：用 1+3-bit matryoshka quantization 缩小冷启动索引
Lakebase 的第一步，就是把需要加载的索引压缩到足够小的可用状态。
这里我们使用的是基于 RabitQ（Gao & Long, 2024）构建的 1+3-bit 套娃式量化。
第一步，我们会在1bit量化压缩过的数据上进行初步检索（该模式下，数据加载量仅为HNSW的三十分之一）。此外，由于RabitQ 会提供 1-bit 距离误差边界，让系统可以更安全地剪枝候选结果，这一轮搜索的recall 可以达到 85% 到 90%。
在1bit数据进行计算时，3bit量化的数据也在这个过程中被加载好，然后对 1-bit 阶段留下的候选结果，做1+3 bit精度的重新评分，最终实现95%的召回。
两层之间，1bit负责过滤，3bit负责优化。
优化二：降低量化误差，避免压缩牺牲 recall
量化解决了加载速度问题，但也带来另一个风险：量化误差可能影响召回质量。
因此，Lakebase 在量化质量上做了两点优化。
第一是 per-vector optimal scaling。
系统不会让所有向量共享同一个全局缩放因子，而是为每个向量单独选择更合适的 scaling，使每个向量的量化误差最小化。
第二是基于维度方差的非均匀 bit allocation。
不同维度承载的信息量并不相同。方差更高、区分度更强的维度，会获得更多 bit；信息量较低的维度，则使用更少 bit。
这两项优化，可以在不增加索引体积的前提下，尽量降低量化误差，让压缩后的索引仍然保持较高 recall。
优化三：用 GPU 和 AVX-512 避免量化本身成为瓶颈
量化还会带来一个工程问题，量化计算本身也很耗费资源。为此，Lakebase 在索引构建和查询执行路径上都做了硬件优化。
索引构建阶段使用 GPU 加速，降低上亿规模向量量化和索引生成的时间成本。
查询阶段则使用AVX-512/ARM SVE优化距离计算，提高 CPU 上的计算吞吐。
到这里，Lakebase 已经解决了冷启动中关于数据压缩的第一个大问题。但这还不够，如果每次查询仍然要扫描 1 亿条向量，计算成本还是太高。
第二关：如何避免冷数据的全量扫描
按需计算的成本以及用户体验取决于两件事：启动多快，以及多久能释放。
尽管有1-bit 索引压缩启动时间，但对 1 亿条向量做计算，整体的资源消耗时间仍然不容小觑。
所以 Lakebase 还需要减少每次查询真正访问的数据量。
为了解决这个问题，我们使用了 IVF clustering 和全局索引剪枝。
查询开始前，系统会把向量聚成多个 bucket。查询进来后，会先找到最相关的 centroid，再只搜索对应 bucket。在上文所举的例子里，通过这个方法，每次查询大约只需要扫描 3% 的数据。
100M 条向量 → IVF clustering
bucket 数量 N 会随着数据量增长
查询 q → 找到最近的 centroid → 只搜索对应 bucket
只扫描约 3% 的数据
S3 I/O 只拉取约 3% 的数据
计算只在约 3% 的数据上执行
当然，IVF 不是新东西。但我们的实现有两个不同点。
第一是规模。
大多数 IVF 实现在十亿级向量规模下会失效，因为构建索引需要一次性把所有数据加载进内存。我们构建了分布式索引构建能力，把 clustering 工作分片到多个节点上，让 IVF 可以扩展到任意规模，甚至数十亿向量。
第二是和 Lakebase 的交互方式。
查询时，只有相关 bucket 会直接从 S3 拉取，QueryNode 内存里只保留约 3% 的数据。一个只加载了 3% 数据集的节点，可以在查询完成后几乎立刻被回收。
结合前文中的 1-bit 量化，实际的数据加载与运算，会大幅压缩：340 GB → 13 GB（量化）→ 每次查询约 400 MB（IVF 剪枝）。
冷启动阶段，只用 5–10 秒加载 cluster centroid 和 1-bit 索引元数据，后续每次查询只需要获取相关 bucket的400MB数据，效率大大提升。
第三关：原始数据读取带来的S3 I/O问题
向量搜索本身返回的是 ID。但业务真正需要的往往是存在S3中的完整结果：原始文本、metadata、scalar fields，甚至原始向量。每次原始结果读取，都需要一次S3 point read。
但如果S3中原始文本的存储格式不适合 point read，I/O 问题就会被严重放大。
很多产品在S3中的文件存储格式默认为Parquet。标准 Parquet 常用 64 MB row group，而一条向量记录可能只有 3 KB。这就导致我们只需要读取3KB的原始数据，采用Parquet格式的时候，却需要下载整个64 MB的 row group，实际 I/O浪费接近 20,000 倍。
因此，我们推出了Storage V2 ：将宽列和窄列分开，分别存储向量和标量字段，并把 row group 缩到 1 MB，从而减少 64 倍 的I/O 放大。
但问题是Parquet本身还有一个天然矛盾。块级压缩依赖于较大的 row group。row group 一旦变小，压缩率就会下降，文件体积也会随之变大。换句话说，在 Parquet 里，小 row group 和高压缩率很难同时成立。
所以 Lakebase 引入了 Vortex。
Vortex 由 Spiral 开发，并托管在 Linux Foundation。它不强制使用固定 row group，layout 可以自由配置。它还支持通过 Delta → RLE → BitPacking 的嵌套编码，在不解压的情况下，对压缩数据直接做 point query。同时，它还能基于 BtrBlocks 算法自动选择编码方式，在压缩率、编码速度和解码速度之间做平衡。
| 指标 | Parquet | Lance | Vortex |
|---|---|---|---|
| Point read throughput（reads/s） | 162 | 464 | 620 |
| 每次读取的 S3 字节数（MB） | 9.44 | 0.006 | 0.07 |
| 每行 S3 GET 次数 | ~2 | ~5 | ~2 |
| Full scan throughput（MB/s） | 638 | 730 | 1,548 |
| Write throughput（MB/s） | 216 | 247 | 244 |
以上是一个对比的结果展示，在3M 行，128 维向量，S3，256 个并发 reader，每次读取 10 行 batch的情况下：
Parquet 格式每次读取需要下载 9.44 MB 的数据——即整个 row group。
Lance 通过以 512 byte 的粒度读取数据，将读取量降低到 0.006 MB，但代价是 IOPS 下降：每行大约需要 5 次 S3 GET 请求，而其他格式只需约 2 次。
Vortex 格式的读取量仅为 0.07 MB，每行大约需要 2 次 GET 请求——比 Parquet 格式减少了 135 倍的数据量，而且没有 IOPS 下降。Full-scan throughput 也比 Parquet 高 2.4 倍，写入性能相当。
至此，第三个障碍解决了。
第四关：多租户情况下，控制平面成本如何降低
前三个问题都在查询链路上。还有一个问题更隐蔽：控制平面。
即使所有 QueryNode 都空闲，在传统向量数据库模式下，每个 Milvus 实例仍然要保持 Coordinator 和 etcd 运行。QueryNode 可以缩到零，但这两个组件不行。它们是有状态组件，必须常驻。
相应的，当租户数量达到百万级时，控制平面的开销，甚至会超过 QueryNode 成本。
Lakebase通过对控制平面的优化，将相关的成本开销从 O(N) 降低成了O(1)。
传统 Milvus 的控制平面成本是 O(N)：
┌──────────────────────────────────────────────────────────────┐
│ Shared infrastructure │
│ Kafka / Pulsar (shared) Index Pool (shared) │
└──────────────────────────────────────────────────────────────┘
| | |
Tenant A Tenant B Tenant C
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ Coordinator │ │ Coordinator │ │ Coordinator │
│ etcd │ │ etcd │ │ etcd │
├──────────────────┤ ├──────────────────┤ ├──────────────────┤
│ QueryNode │ │ QueryNode │ │ QueryNode │
│ (dedicated) │ │ (dedicated) │ │ (dedicated) │
└────────┬─────────┘ └────────┬─────────┘ └────────┬─────────┘
└─────────────────────┼─────────────────────┘
↓
┌──────┐
│ S3 │
└──────┘
Lakebase 的控制平面成本是 O(1)：
┌───────────────────────────────────────────────────────────────┐
│ Shared control plane (per-region) │
│ │
│ ┌──────────────────┐ ┌──────────┐ ┌───────────────────┐ │
│ │ Shared │ │ Catalog │ │ WAL Service │ │
│ │ Coordinator │ │ ≠ etcd │ │ → S3, ≠ Kafka │ │
│ │ │ │ │ │ │ │
│ └──────────────────┘ └──────────┘ └───────────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ Index Service (GPU Build Pool) │ │
│ └───────────────────────────────────────────────────────┘ │
└─────────────────────────────┬─────────────────────────────────┘
┌────────────────────┼─────────────────────┐
Tenant A NS Tenant B NS Tenant C NS
┌────────────┐ ┌────────────┐ ┌───────────┐
│ QueryNode │ │ (idle) │ │ QueryNode │
│ QueryNode │ │ scale = 0 │ └────┬──────┘
└──────┬─────┘ └────────────┘ │
└─────────────────────┬─────────────────────┘
↓
┌──────┐
│ S3 │
└──────┘
Lakebase 中，我们淘汰了原有的按租户分配资源的模式，用Shared Coordinator 替代了 per-tenant coordinator。并用Catalog 取代了每个实例单独部署的 etcd，然后移除了 2 GB 的存储上限。
WAL Service 可直接写入 S3，无需本地磁盘。实测吞吐量达到 750 MB/s，是 Kafka 的 5.8 倍，用于取代 Kafka/Pulsar。
Index Service 则变成了一个跨租户共享的 GPU 构建池，取代了原先每个实例单独分配 GPU 的模式。
“Scale to zero” 不再只是“QueryNode 可以释放”。它开始意味着：整个实例在空闲时几乎没有成本。
┌──────────────────────────────────────────────────────────────┐
│ Multi-tenant × Lakebase On-demand Search │
│ │
│ S3 storage layer compute (on demand) │
│ ┌──────────────┐ │
│ │Tenant A data │ ◄──── query ──── QueryNode A (active) │
│ ├──────────────┤ │
│ │Tenant B data │ (idle, no QueryNode) │
│ ├──────────────┤ │
│ │Tenant C data │ (idle, no QueryNode) │
│ ├──────────────┤ │
│ │Tenant N data │ ◄──── query ──── QueryNode N (active) │
│ └──────────────┘ │
│ │
│ 1M tenants, 1% active → 99% of data has zero compute cost │
└──────────────────────────────────────────────────────────────┘
传统模式中，多租户意味着通过不同 collection 或 partition 在一个集群中共享tenant。但这种集群存在硬性限制：etcd 的 2 GB 元数据限制、coordinator 的吞吐量以及固定的QueryNode 容量。
而在Vector Lakebase，Catalog 用可扩展的 metadata store 替代 etcd，Shared Coordinator 可以在没有 per-tenant 开销的情况下支持更多 tenant，S3 提供存储弹性，最终实现单机群服务多租户，而且只有正在接收查询的租户会消耗计算资源。其他租户只为存储付费。
选择Vector Lakebase意味着什么？
回到一开始的问题，1 亿条向量，768 维 float32，每天 10 次查询，每次 1 分钟，每月活跃约 5 小时的情况下，用户到底需要多大成本？
答案取决于计算资源是否必须持续在线。
| 指标 | Self-hosted Milvus | Zilliz Cloud Tiered Storage Model | Vector Lakebase On-demand Search |
|---|---|---|---|
| 计算资源 | 持续在线 | 持续在线 | 按需启动 |
| 空闲计算成本 | 按整月资源计费 | 按整月资源计费 | 0 |
| 冷启动模式 | 初次加载后保持 warm | 初次加载后保持 warm | 每次会话开始约 5–10 秒 |
| 适合场景 | 高频在线检索 | 托管式冷热分层服务 | 低频语义查询、分析型搜索、批处理任务 |
| 成本逻辑 | 为常驻集群付费 | 为托管服务和持续计算能力付费 | 为实际计算运行时间付费 |
在自托管 Milvus 中，主要成本来自常驻计算资源。即使查询频率很低，集群也需要持续在线，以保证数据处于可查询状态。按 3 台 r6g.4xlarge on-demand 实例估算，仅 EC2 成本约为 2,073 美元/月，还不包括 Kafka 等依赖组件。
Zilliz Cloud Tiered Storage Model 降低了运维复杂度，并通过分层存储降低冷数据的存储成本。但从计算模型看，它仍然是持续在线的服务模式。其冷启动成本通常是一次性的：数据加载完成后，后续查询可以保持较低延迟。对高频或稳定访问的场景来说，这种模式非常合适；但对每月只活跃数小时的工作负载来说，计算资源的基础成本其实并不必要。
Vector Lakebase On-demand Search，可以让数据可以长期保存在对象存储中，计算资源只在查询会话开始时启动，并在任务结束后释放。
相应的，在这个例子中，Vector Lakebase 模式下，用户只需为每月约 5 小时的计算以及实际的S3存储成本付费。每年只需要 240 美元，不使用的99% 的时间里没有计算成本。
而随着语义数据可以被自由加载释放，团队也不再需要用同一种计算形态处理所有工作负载。热数据可以使用持续在线的 serving compute；低频语义查询可以使用 on-demand search；数据发现、聚类、清洗和批处理任务可以使用 batch compute。
当然，Vector Lakebase也不是万能的。为了保证会话之间计算成本为零，节点会在查询结束后缩容到零，每次新的请求发起时会有约 5–10 秒冷启动。
所以，这三种模式没有完全的优劣之分，取决于你的数据是否需要长期占据计算资源。
开始使用 Zilliz Vector Lakebase
Zilliz Vector Lakebase Public Preview 现已开放。 如果你正在构建 AI 搜索、智能体记忆、企业知识库、多模态检索、数据湖语义分析或大规模批量分析工作流，现在就可以开始体验新一代面向 AI 工作负载的语义数据平台。
尝鲜链接：https://zilliz.com.cn
附Zilliz Vector Lakebase 能力一览
当前阶段的Zilliz Vector Lakebase ，主要做了五方面的能力建设：
- 服务能力升级：推出分层服务方案，为极致性能、容量优化和低成本分层存储等不同场景提供对应选择。
- 按需搜索能力升级：推出按需搜索（On-Demand Search），让大规模低频检索、数据探索和离线分析不再需要长期维持闲置计算资源。
- 数据湖搜索能力升级：支持外部数据湖搜索（External Data Lake Search），可直接在已有数据湖上增加高性能索引和大规模搜索能力。
- 检索能力升级：在同一系统内支持向量搜索、全文搜索、JSON 查询、地理空间搜索、多向量搜索、多路径检索和重排序。
- 湖原生存储能力升级：同构统一的lake-Native Storage，基于 Vortex 开放格式，为在线服务和离线分析提供统一、高效、低成本的数据底座。与 Lance 和 Parquet 相比，它能提供更快、更便宜的随机读取，以及按列格式的灵活性和更广泛的数据建模能力。
James Luan
