“把数据库迁到 GPU，就像移民到火星。”

在 WAIC 2026 的现场，星环科技创始人、CEO 孙元浩口中的这场“火星移民”，正随着其面向 AI Agents 的 GPU 原生认知数据库预览版的发布，成为可落地的现实。AI 时代，星环科技要重写整个数据库。

然而，当被问及底层技术究竟如何实现“重写”时，孙元浩却笑着卖了个关子：“这个我们就不告诉别人了。”

这段发生在 WAIC 2026 星环科技展区上的现场采访，之所以让人印象深刻，部分原因在于这位技术掌门人对自家产品战略的绝对笃信，部分原因在于同样身为一名科幻迷的他，有趣的思考方式——关于速度，关于火星，关于 AI Infra 领域的一种理想主义。

“快”的含义变了

星环科技创业初期，曾提出要打造世界上最快的大数据处理引擎。

“星环”这一公司名字，来自科幻小说《三体》中的“星环号”，人类第一艘实现光速飞行的飞船，也寄托着公司对极致速度的追求。

当时，数据库对性能的需求主要来自数据规模的增长。企业数据从几个 GB 增长到数百 TB、数 PB，甚至更大的规模，单台服务器无法完成处理，只能依靠分布式计算，将数据和任务拆分到更多机器上执行。

在那个阶段，“快”意味着能够在可以接受的时间内处理更大的数据量。

AI Agents 出现后，数据库对速度的要求发生了变化。单次处理的数据量未必很大，但调用次数变得极其密集。

过去，人类用户查询一张报表，等待几秒钟可能并不会严重影响体验。但在 Agent 的执行链路中，一次查询延迟会传递到下一步推理，下一步推理又可能触发新的查询。任何一个环节的等待，都会在循环中不断累积。

因此，AI 时代数据库追求的“快”，不再只是在大数据量上完成批量处理，也包括在大量小规模、连续、并发的数据调用中维持足够低的延迟。

“以前的 AI 是一次一问一答，是 One Shot。现在变成了一个 Loop。”孙元浩认为，Agent 会不停地推理、行动、调用数据库、观察结果，发现不对以后再修改、再重来。这样的使用方式，对数据库带来的影响非常巨大。

在孙元浩看来，今天数据库正在经历的变化，根源并不只是数据规模再次增长，而是数据的使用者发生了改变。过去数据库的用户是人，未来的数据库就是给 AI 用的。

这也是星环科技在 WAIC 2026 期间发布 GPU 原生认知数据库预览版背后的核心判断：当数据基础设施开始直接面向 AI Agent，数据库需要从计算架构到能力体系重新设计。

Agent 想要什么

仿照凯文·凯利的科技观和他的经典著作《科技想要什么》，我们不妨也思考一下 Agent 想要什么。

把 Agent 对数据库的需求拆开看，其实是三层递进的结构：

第一层是速度。数百个 Agent 高频并发，传统数据库的并行计算能力很快触顶。单颗 CPU 通常有 100 到 200 个通用计算核心，约 400GB/s 级内存带宽。这个配置在过去二十年里足够应付绝大多数数据库工作负载，毕竟人类发起的查询，频率和并发量都有上限。

如前文所述，当数百个 Agent 同时发起数据扫描、复杂聚合和向量检索，CPU 的并行资源会被迅速占满。核心不够用，排队就开始了；带宽不够用，数据传输就堵住了。结果就是，Agent 等数据的时间，比推理的时间还长。

速度只是 AI Agent 对数据库提出的第一层要求。

当 AI 从一次问答走向持续执行，数据库还需要解决另外两个问题：上下文和记忆。

第二层是上下文。企业数据天然分散，关系型数据在数据库里，文档知识在文档系统里，语义信息在向量库里，关联关系在图数据库里。Agent 要做出准确判断，需要这些信息被统一组织、协同检索。靠系统拼接能做到，但代价是架构复杂度飙升。

第三层是记忆。Agent 不是用完即弃的。它需要记住用户偏好、任务进度、历史结论，在跨会话场景中延续理解。这要求数据库具备长期记忆能力，而不只是存储和查询。

速度、上下文、记忆，三层需求叠加在一起，传统以 CPU 为中心的数据库架已经很难招架。AI Agent 的大脑在 GPU 上高速运行，但它需要的数据、知识和业务上下文，仍要等待 CPU 侧的数据库完成查询、分析和整理。模型越来越快，数据供给却没有同步加速，GPU 算力因此不断陷入等待。

孙元浩用了一个形象的比喻：AI 是大脑，数据库是它的四肢。大脑思考得越来越快，但行动和取数据的速度太慢，整个系统还是快不起来。

认知何以涌现

面对 Agent 这个新物种的需要，数据库需要从数据管理系统进化为认知基础设施。星环科技 GPU 原生认知数据库的四个能力维度，试图完成这场进化。

• GPU 原生加速：同一块算力底座，干完所有事

SQL 极速分析、向量检索、图分析、语义检索、机器学习，这些操作过去分散在不同系统里，现在跑在同一块 GPU 算力底座上。这意味着 Agent 不需要在多个系统之间跳转，所有数据操作都在同一个计算体系内完成。

• 一体化融合：消灭"系统拼接"的复杂性

当前企业 AI 数据基础设施的一个普遍痛点：系统太多。

关系型数据用一套数据库，向量检索用另一套，图分析又换一套，全文搜索还得再部署一个。每套系统都有自己的运维体系、数据格式和接入方式。把这些系统拼在一起喂给 Agent，单单是数据搬迁和对齐就能耗掉大量精力。

星环科技的方案是统一承载：关系型、向量、图、全文、文档，多模型能力全部纳入同一底座。数据分析、知识检索、上下文供给和记忆管理，不再需要多套系统拼接。

开发者不用再当"系统胶水工"，可以把精力放在 Agent 本身的业务逻辑上。

• 记忆能力：让 Agent"越用越懂业务"

AI Agent 的一个核心痛点是"健忘"。每次对话、每个任务都从零开始，之前的交互经验、用户偏好、任务进度全部丢失。这导致 Agent 的回答永远停留在"初次见面"的水平，没法越用越聪明。

星环科技的做法是基于自研分布式文件系统，内建长期记忆、会话记忆与上下文管理。支持多类型记忆持续沉淀，通过 GPU 加速实现低延迟检索与精准召回。记忆准确率达到 90%以上；在 BEAM 500K 和 LongMemEval-S 基准测试中，均超过主流开源记忆系统。

• 自然语言数据分析：让业务人员直接用数据

这一能力的价值在于降低了使用门槛。业务人员不需要学 SQL，开发者也不需要手动拼装多系统的查询逻辑，直接用自然语言就能调用底层数据能力。对于 Agent 应用开发来说，这意味着数据、知识和记忆可以更便捷地接入 Agent 的工作流。

数据库要成为 GPU 的原住民

过去多年，行业内已经出现过多种 GPU 加速数据库方案。这类方案通常保留原有 CPU 数据库架构，只把部分计算任务交给 GPU。任务在 CPU 上开始执行，运行到特定环节后将数据搬运到 GPU，计算完成后再传回 CPU。

在高频调用中，CPU 内存与 GPU 显存之间的数据传输，本身就会带来额外延迟。更重要的是，只加速某一个环节，无法消除整个处理链路中的其他瓶颈。

孙元浩将 CPU 与 GPU 的性能差异比作步行和乘坐飞机。

“如果一段路步行，一段路坐飞机，最后一段再步行，肯定比不上从起点直接坐飞机到终点。”

在他看来，GPU 加速数据库和 GPU 原生数据库的核心区别就在这里。

GPU 加速是在原有 CPU 架构中加入 GPU，GPU 原生则要求数据库的核心数据处理链路从起点到终点都围绕 GPU 运行。从任务执行、数据结构到并发控制、资源调度和内存管理，都要重新适配 GPU 的硬件特性。“它是 GPU 的原住民，根本不住在 CPU 上，所以我们把它叫作 GPU 原生。”

难度不啻于“移民火星”

相比 CPU，GPU 拥有万级并行计算单元和数 TB/s 级高带宽显存，当然更适合同时处理大量 Agent 发起的高并行数据负载。基于 GPU 原生架构，数据库计算与 Agent 推理可以在同一 GPU 计算体系内共享显存数据，分析和检索结果直接进入后续推理，避免 CPU 与 GPU 之间的往返搬运。

但问题在于，数据库并不会因为接入一张 GPU，就自动获得数量级的性能提升。

GPU 本身最初面向图形渲染设计，后来逐渐成为 AI 训练和推理的核心硬件，却没有一套天然为数据库准备的成熟软件栈。

这意味着整个数据库需要从头重写，原来为少量 CPU 核心设计的并发控制、任务分配、调度机制，全部要推倒重来。

这种推倒重来，是 GPU 原生数据库与传统数据库外挂 GPU 加速模块之间最本质的差异，也是本文开篇，孙元浩提出的移民火星之喻的由来。

换来的性能与性价比

GPU 原生数据库最直观的价值体现在性能上。

据星环科技公布的测试结果，在 TPC-DS SF1000 和 TPC-H SF1000 基准测试中，分别完成全部 99 个和 22 个查询，测试通过率达到 100%。相较 CPU 数据库 1TB TPC-DS 基准测试性能提升 70 倍，相较 CPU 数据库 1TB TPC-H 基准测试性能提升 28 倍。

值得注意的是，这并不是一套只负责加速查询的 GPU 计算引擎，而是一套具备完整数据增、删、改、查能力的数据库系统。换言之，它既能够承接业务数据的持续写入和更新，也能够直接在不断变化的数据上完成大规模扫描、复杂关联与聚合分析，从而避免将数据额外搬入独立的 GPU 分析系统。

对于数据分析类 Agent，这些恰好是最频繁出现的操作。

不过，GPU 的采购成本通常高于 CPU。企业是否愿意为 GPU 数据库买单，不能只看性能，还要计算完成同等任务需要投入多少资源、花费多少时间。

“如果 GPU 只比 CPU 快 1.5 倍，它就没有经济性。”孙元浩说，“但如果能快几十倍，经济性就会出现，因为 GPU 的价格并不是 CPU 的几十倍。”

星环科技披露，在 TPC-DS 1TB 特定负载测试中，和 Databricks 相比，GPU 原生数据库表现出的性能超 66 倍，性价比超 14 倍。

当然，基准测试中的数量级性能，并不自动等同于所有生产场景都能获得同等提升。企业还需要综合评估数据类型、查询模式、迁移成本、稳定性、兼容性和运维能力。

真正具有说服力的验证，仍然来自具体业务现场。

面对信贷经营和风险分析场景的 4.8 亿条明细数据，星环科技使用 GPU 原生认知数据库完成多维分析和持续追问，在特定场景下实现了 449 倍性能提升。信贷业务分析需要贯通客户、授信、用信、还款及风险变化等全链路信息，并支持持续追问与多维钻取。传统架构下，这种跨链路、多维度的实时分析几乎不可能实现。

当复杂分析从数小时缩短到分钟甚至更短，业务人员可以围绕结果继续追问：哪些区域的风险正在上升？哪些客户群体出现了异常？风险变化与授信策略、还款行为之间有什么联系？

数据库性能提升后，分析变成了连续发生的交互过程。企业也有机会更早发现风险变化，在问题扩大之前采取行动。

一个新的十年的开端

GPU 原生认知数据库并不是一次孤立的软件升级，它背后还对应着整个计算机基础设施的变化。

过去二十多年，企业数据中心提升计算能力的主要方式是 Scale Out，也就是增加服务器数量，通过高速网络将更多 CPU 节点连接起来。分布式数据库和大数据平台正是在这一阶段快速发展。

当单核 CPU 性能遇到瓶颈后，行业通过多核、分布式和横向扩展继续提高整体处理能力。

AI 时代，基础设施开始重新重视 Scale Up。

大模型训练和推理需要多张 GPU 高速互联。模型参数、上下文和 KV Cache 不断增长，对显存容量、内存带宽、存储和网络提出了更高要求。单纯增加彼此松散连接的 CPU 服务器，很难满足 AI 对低延迟和高带宽的需求。

企业需要先将多张 GPU 通过高速互联组成更强的单体计算系统，再在此基础上继续进行横向扩展。

这并不意味着分布式架构会消失。面对更大的数据和模型，Scale Out 仍然必要，只是单个计算节点本身需要具备更强的性能和更高的带宽。

孙元浩将这条软件的技术演进路线总结为两条持续存在的驱动力：一条来自上层用户需求，一条就来自于底层硬件变化。

随着大模型参数越来越大，KV Cache 不断膨胀，内存墙（Memory Wall）成为全产业的瓶颈，围绕 GPU，HBM、DRAM、高速存储、网络通信和散热系统都在重新设计。

软件层同样需要改变，操作系统、数据库和数据处理框架都要适配新的硬件中心。

重要的是，在他看来，这不只是数据库的事，而是整个计算机架构变革的开端。而在未来的 10 年当中，企业的 AI Infra 会彻底发生变化。

但无论计算架构如何演进，数据库作为数据组织、管理与可信供给的核心系统，其基础地位不会改变。正如黄仁勋所强调的，数据库仍将是 AI 的 “Ground Truth”——为模型提供可验证、可追溯、可持续更新的事实基础。