今年的GTC上，作为英伟达的老朋友，Milvus（Zilliz）又露脸了！美西时间晚上11点18分，依旧是黄仁勋，依旧是那件标志性的黑色皮衣。例行感谢之后，他没有发布新显卡，也没有聊最近火热芯片架构，而是在简短的回忆了Cuda20周年的前世今生后，放出了两张幻灯片。第一张，密密麻麻列满了Apache Spark、Presto、DuckDB、Polars等几十个数据引擎的Logo。这是过去三十年结构化数据处理的完整版图。SQL、Spark、Pandas、Velox、Snowflake、Databricks、Amazon EMR、Google BigQuery……这些名字串联起来的，是一整代数据工程师的职业生涯。第二张幻灯片，画风突变。Milvus（OSSEngines 板块）、Zilliz Cloud（ Enterprise Databases ）、IBM、MongoDB等Logo排列其上。幻灯片上的标题，也吸引了不少人的注意力——"Unstructured Data is the Context of AI."（非结构化数据，是AI的上下文。）而用好非结构化数据，这张图中被连接了最多节点的产品，向量数据库Milvus，必不可少。那么，为什么非结构化数据的处理，会如此重要、Milvus（Zilliz）为何又能在英伟达的非结构化数据处理版图中占据如此重要的地位？01
为什么是Milvus？
事实上，这已经不是 Zilliz 第一次在 GTC 被点名。而要理解Zilliz与英伟达的合作，首先需从英伟达还没成为大模型收租人，Zilliz也尚未成为如今的核心AI infra的时候说起。。早在Zilliz创业伊始，我们就把深度支持GPU写进了公司历代产品研发的最高准则，也是在2019年的GTC China期间，我们正式向公众推出了Milvus的初代形态。到2023年， 双方合作进一步深化，这一年GTC大会的主题演讲舞台上，一身皮衣的黄仁勋正式官宣：“NVIDIA正在将RAFT加速库引入Meta开源的FAISS、Milvus以及Redis。”也正是这一次教科书式的CEO带货，以及同期OpenAI 的官方背书，让Milvus与Zilliz正式从开源世界，被推向台前，短短一年时间，全球数千家组织开始将Milvus纳入自己的技术栈。在此后的一年里，和 NVIDIA 的工程师加速合作,并在2024年的GTC大会上，正式发布了Milvus2.4版本。这是全球首个GPU加速向量数据库，在业界首次采用了英伟达 GPU 的高效并行处理能力和 RAPIDS cuVS 库中新推出的 CAGRA（ CUDA-Accelerated Graph Index for Vector Retrieval ）技术，提供基于 GPU 的向量索引和搜索加速能力。基准测试显示，新版 GPU 加速 Milvus 能提供高达 50 倍（相比HNSW）的向量搜索性能提升。在这个过程中，Milvus 也成为了最早、最深度集成 cuVS 的开源项目。到了2025年，合作进一步深化，我们在Milvus 2.6.版本针对英伟达GPU索引 CAGRA 推出了灵活部署选项，借此实现了非结构化数据查询的Hybrid GPU-CPU架构。既借助CAGRA强大的GPU图构建能力保障索引质量，又复用HNSW成熟的CPU检索能力降低部署成本，完美实现两者优势互补。02
非结构化数据处理，难在哪里？
全世界90%的数据是非结构化的。PDF、文档、图片、视频、音频、传感器信号、代码、日志——这些占据了我们硬盘空间的东西，长期处于“存而不用”的状态。企业花了几十年时间收集、存储这些数据，然后就没有然后了。因为你没法索引它，没法查询它，没法搜索它。过去， 传统数据库的核心能力是精确匹配——找出字段等于某个值的记录。但面对一张图片、一段视频、一份PDF，结构化数据的B+树、用倒排索引，面对检索一段文字的意思，一段视频的内容时，几乎束手无策。但随着Embedding技术的成熟，我们可以把一段文字、一张图片映射为一个高维向量空间中的点。而语义相近的内容，向量在空间中的分布也会更为相近。在此基础上，相似性搜索，取代了精确匹配，成为检索非结构化数据的新范式。但这只是问题的前半段。AI 打开了这扇门，但门后面还藏着一个更为庞大的问题：规模化成本。一家中型企业可能有几百万份历史合同、几千万张产品图、数十年的客服对话记录。如果把它们全部向量化、简单索引、实时检索，一个 1536 维的 float32 向量占 6KB，一亿条就是 600GB，在没有任何工程优化的情况下，几乎天方夜谭。因此，作为全球首个向量数据库产品，Milvus出现了。通过存储、索引这些embedding，Milvus让非结构化数据的高质量、低成本、高效率检索成为了可能。首先是整个数据检索的pipeline搭建上，我们推出了Data in, Data out，让整个非结构化数据的存储与检索流程变得极简。过去，把一份PDF变成可以搜索的向量需要开发者自己拼装一条“流水线”：
每个环节都是额外的代码、额外的依赖、额外的出错点。工程团队一半以上的时间不是花在搜索上，而是花在如何让数据进入搜索系统上。而借助Milvus 2.6的Data-in, Data-out：原始内容（文本、图片、音频等）可以直接写入，embedding在数据库内部完成，不需要外部预处理。针对检索效率问题，索引层面，我们支持 HNSW、DiskANN、IVF 等多种索引类型，针对不同数据规模和延迟要求自动匹配最优策略。此外，在 Zilliz Cloud 上，自研的 Cardinal 引擎在此基础上再提供 10 倍于开源 Milvus 的查询性能，且通过 AutoIndex 自动调优，无需手动配置召回率与速度的平衡点。成本上，Milvus还引入了 Int8 向量压缩（用 8 位整数存储 dense 向量，内存占用大幅降低）和 RabitQ 1-bit 量化（在保持相近检索质量的前提下，内存成本压缩到原来的一半）。运维上，Milvus也推出了新的 WoodpeckerWAL直接去掉了对Kafka和 Pulsar 的依赖，运维复杂度和基础设施成本同步下降。03
解决存储成本困境，先从系统做起
演讲的后半段，聊到Hopper与Vera Rubin的时候，黄仁勋再一次强调了存储的重要性。在他看来，“对智能体最核心的能力是思考，而思考的核心是大语言模型。随着大语言模型的规模不断扩大，生成Token的速度也会持续加快，思考也随之变得更高效。但模型同时需要访问内存，会对KV缓存、cuDF结构化数据、cuVS非结构化数据带来极大压力，也会严重冲击存储系统。”这是英伟达近些年来不断优化Vera Rubin系统的核心原因。但在我们看来，存储的优化是一个系统工程，不只需要硬件的进步，也需要系统与软件思维的共同进化。举个简单的例子，在一个拥有 800 个租户的平台上，通常来说，过去 24 小时内被访问的租户仅占 15%，而剩余 85% 的租户数据几乎不会被访问，如果所有数据在存储资源的分配上一视同仁，带来的，就是无穷无尽的资源浪费。针对过去全量加载模式的痛点，Milvus 2.6引入了分层存储（Tiered Storage），将数据加载逻辑从全量预加载转变为按需加载，实现性能与成本的精准平衡。冷数据按需加载：释放本地资源空间，存储在S3之类的低成本介质智能预测：基于LRU算法动态调整冷热数据边界，自动降级不常用数据块如此一来，只要把数据放在正确的位置，就能带来系统成本70%以上的优化。04
AI 时代，向量数据库+语义检索就够了吗？
关于结构化与非结构化数据在AI时代的分野与未来，黄仁勋提到了一个观点“在AI时代，我们需要让AI来使用结构化数据，并对其实现极致加速。过去，加速结构化数据处理是为了让企业更高效地运转。而未来，AI将以远超人类的速度使用这些数据结构，AI智能体也将大量调用结构化数据库。”直白翻译一下，未来的数据管理与使用，结构化数据与非结构化数据是缺一不可的。但相当长一段时间里，同时高效使用结构化数据与非结构化数据，企业往往需要同时维护Milvus、Redis、ES在内多套基础设施，大大增加了infra层面的运维难度。Zilliz 作为最早开始处理非结构化数据的向量数据库厂商，也是最早需要直面这个融合问题的团队之一。我们的解决方案是，Milvus、Zilliz cloud一套系统，同时解决AI native企业对向量、标量、关键词、地理、时空、JSON 字段检索的全部需求。Hybrid search，解决关键词查询问题：产品 ID、合同编号、法律术语，这类字段不能靠语义近似，差一个字就是错。Milvus 2.5 通过 Sparse-BM25 将全文关键词检索原生内化，与向量语义搜索在同一次查询中并行执行。不再需要独立维护 Elasticsearch 集群，实测查询速度快 30 倍以上。AI Agent 调用数据层，从两扇门变成一扇门。Metadata filtering，向量搜索+过滤筛选，让查询更有边界。真实的业务查询，通常会被一些条件约束，比如"找某款最相近的平替"背后通常隐含着"价格 < 500"或"品类 = 电子"。Milvus 支持在向量搜索时直接对整数、字符串、JSON 字段做精确过滤，把 SQL 逻辑嵌入相似性检索，条件过滤和语义召回在单次查询内同时完成。JSON字段 + 动态 Schema，让数据存储更灵活：现实中的数据 schema 并不总是提前确定的。Milvus 的 JSON 字段支持在同一条记录里混存强类型结构化字段和动态属性，写入时不需要预定义全部字段，读取时仍然可以对已知字段做精确过滤。这是结构化程度可调的安全阀，让系统在灵活性和查询确定性之间不必二选一。Geospatial：地理空间数据与语义向量，同库同查询：地理范围是一类特殊的确定性约束。外卖平台推荐餐厅，需要同时判断用户位置、餐厅配送范围和用户口味偏好——前两者是精确的空间关系，最后一个是语义向量。以前这需要地理数据库和推荐系统各查一次，业务层拼接。Milvus 2.6 引入 Geometry 字段和 RTREE 索引，支持 st_within、st_dwithin 等空间算子，先用空间过滤收窄候选集，再在候选集上跑向量搜索，一次完成。自动驾驶场景同理：轨迹、障碍物区域和场景语义，三类数据同库，毫秒级联合查询。Temporal：时序数据与向量检索的两层结合：AI 的判断是时效敏感的。金融风控场景下，"找与这笔可疑交易语义最相近的历史记录"和"找最近 30 天内最相近的记录"，结果可能完全不同。Milvus 2.6 的 TIMESTAMPTZ 字段支持时区感知和时间区间算术，时间条件可以直接写进 search() 的过滤表达式，与向量查询合并执行，不需要拆成两次查询再求交集。在此之上，Milvus 的 Time Travel 能力让用户可以直接对任意历史时刻的数据库状态做向量检索——不依赖快照副本，运维成本大幅降低。不过，必须承认，上述这些能力更新，更多服务于那些以语义检索为核心、从一开始就围绕 AI 原生架构搭建系统的企业。对于另一类企业——已经沉淀了海量结构化与非结构化数据资产、同时拥有成熟数据基础设施的大型组织来说，问题往往没有这么简单。对于大型企业，真正的瓶颈不在于搜索有多快，而在于整个 AI 系统能不能持续变好。这背后藏着三个交织的基础设施问题：
第一，数据孤岛。 原始文件在对象存储，Embedding 向量在向量数据库，结构化元数据在关系型数据库——三套系统、三种生命周期。一个简单的 AI 功能背后，是一整张数据同步的蜘蛛网。
第二，迭代成本。 Embedding 模型换代，就意味着几十亿条历史向量要全量重新生成、重新入库、重新建索引。这是一个需要单独立项、持续数月的工程项目。
第三，改进闭环断裂。 在线搜索服务和离线数据治理的分离，让两边的数据永远对不上。离线产生的优化信号——去重结果、质量评分、聚类标签——难以回灌到在线服务，AI 系统的改进飞轮转不起来。
这三个问题叠加在一起，让不少企业陷入了一种困境：向量数据库买了，RAG 系统搭了，但随着数据量增长和业务复杂化，维护成本以非线性的速度上升，而 AI 的质量却在缓慢地天花板化。
他们真正需要的，不是再多一套系统，而是一种新的基础设施范式——既能让数据不在不同系统之间反复搬运，又能让 AI 系统在生产中持续自我改进。
在前 AI 时代，Databricks 给出的答案是 Lakehouse。它将原本分散的数据湖和数据仓库能力重新组织起来，让企业可以在统一的数据底座上同时完成实时处理和离线分析，而不必维护割裂的多套系统。
在 AI 时代，面对以非结构化数据为核心的新工作负载，Zilliz 给出的答案是 AI Lakebase一一这也是即将随 Milvus 3.0和 Zilliz Cloud 重磅推出的核心升级方向。
如果细看黄仁勋在 GTC 上展示的数据基础设施图，会发现一个很有意思的变化：在结构化数据时代，Spark 这样的数据湖计算框架是整个数据流转的核心节点；而在非结构化数据时代，Milvus 这样的向量数据库，正在成为新的数据汇聚中心。它不再只是一个"存向量、做检索"的工具，而是在越来越多 AI 应用中承担了连接原始数据、Embedding、索引和检索服务的关键角色。
那么，一个自然的问题就出现了：如果把企业已有的数据湖基础设施，与 Milvus 这样的向量检索能力做深度融合，能不能同时解决前面提到的那些问题，并进一步开启一种全新的工作范式？
AI Lakebase 的核心架构由三层构成：
统一存储层——数据的持久化底座。包括 Zilliz 原生的 Collection（查询优化的向量存储格式）和 Volume（对接企业已有数据湖的开放格式——Iceberg、Lance、Paimon 以及原始文件）。无论数据以何种形式存在，都不需要搬家，也不需要重建。
在线服务集群（Serving Cluster）——面向生产的实时向量检索。采用 Cardinal 引擎，追求毫秒级低延迟，支持性能优先、容量优先、冷热分层等多种集群配置。冷热分层模式下，热数据常驻本地保障高频查询的低延迟需求，冷数据按需从对象存储加载，基于 LRU 算法动态调整冷热边界——仅此一项就能带来 70% 以上的存储成本优化。
按需计算集群（On-demand Cluster）——面向 AI 迭代的弹性计算。支持批量处理（ETL、去重、聚类、重新 embedding）、交互式探索（数据质量分析、失败样本调查、数据集策展）和定时评估任务。任务完成后自动释放，按需付费。
三层共享同一份数据，而不是维护多套副本。这种架构借鉴了 Lakehouse 已经被验证过的存算分离原则，但针对向量检索和 AI 工作负载做了重新设计。核心原则只有一个：数据不搬家。企业带来计算，而不是搬运数据。
但 AI Lakebase 的价值不止于架构的简化。更本质的变化在于，它让 AI 系统第一次拥有了内建的持续改进闭环——我们称之为 AI CS/CD（Continuous Serving / Continuous Discovery）。
┌──────────────────────────────────────┐
│ Continuous AI Data Loop │
│ │
│ CS: Serving ──► Data ──► Lake │
│ ▲ │ │
│ │ ▼ │
│ Improvement ◄── CD: Discovery │
│ │
└──────────────────────────────────────┘
Continuous Serving（CS）：在线服务集群持续对外提供 AI 能力——每一次查询、每一次交互、每一次生成，既是产品输出，也是数据信号。
Continuous Discovery（CD）：按需计算集群持续从积累的数据中提炼洞察——覆盖度分析、质量评估、聚类发现、失败模式识别——并将改进信号回灌到服务端。Discovery 驱动的改进手段不止一种：模型微调、prompt 优化、检索策略调整、知识库策展、Agent 框架迭代，都可以从同一套数据基础设施中获得输入。
因为在线服务和离线分析共享同一份数据，Discovery 产出的去重结果、聚类标签、质量评分，一旦写回，就可以立即被 Serving 消费。Embedding 模型升级也不再是一次漫长而昂贵的工程项目——按需集群弹性地处理增量重建，不影响在线服务。
过去需要维护五套系统的人力，最终可以被压缩成对一张表、一套底座的管理。
这就是 Zilliz Cloud 的双重价值主张——Scale Fast, Iterate Fast：
Scale Fast：全球多区域、多云覆盖，支持千亿级实体的稳定生产运行——不是基准测试数字，而是持续、稳定的生产能力。
Iterate Fast：CS/CD 工作流原生运行在 Lakebase 之上，让 AI 系统在规模化的同时持续自我改进。
规模而不迭代，是一个庞大但停滞的系统；迭代而不规模，是一个精致的原型。两者结合，才是生产级 AI 的目标状态。
而这个从 database 到 lakebase的过程，有点像当年从数据仓库走向 Lakehouse，不再局限于某个单点功能的改进，而是彻底重塑一种新的架构范式。
过程中，向量数据库并没有消失。相反，它仍然存在，只是角色发生了变化——它不再是终点，而成为 Lakebase 中负责在线服务的一层。就像关系型数据库在 Lakehouse 时代依然承担着 OLTP 的职责，向量数据库在 Lakebase 时代依然是实时检索的核心引擎——但它的上下文变了，它不再孤立运行，而是被嵌入一个更完整的数据闭环之中。
黄仁勋在今年 GTC 的舞台上说，非结构化数据是 AI 的 context。这句话反过来理解，其实就是：AI 应用的质量上限，最终取决于非结构化数据基础设施的成熟度。
而今天，这套基础设施仍然远未准备好。AI Lakebase 想要填补的，正是这个空缺：让非结构化数据第一次拥有一个真正统一、可持续演进的数据底座——不仅让 AI 系统跑起来，更让它在生产中越跑越好。
尾声
最后，黄仁勋在本次GTC大会上的最后一段话，与大家共勉:"AI的价值，不在于技术本身，而在于技术的落地、在于技术对社会的改变。只有开放的生态，才能让AI的创新活力充分释放，才能让AI真正走进每一个行业、每一个角落，才能让数万亿美元的AI基建时代，真正成为惠及全人类的时代。"对于Milvus而言，作为一个坚持开源、开放的向量数据库平台，我们也同样期待更多人能加入这个开源生态，共建一个更繁荣的非结构化数据处理未来。Al Lakebase 将作为 Milvus3.0和Zilliz Cloud的重大升级正式推出。如果您对这一方向感兴趣，欢迎联系我们抢先体验
如果您恰好也在展会现场，欢迎前往Kiosk#5的AWS展位，我们线下见！
