阿里雲重新定義 AI 時代數據庫

作者 | 柴旭晨 编辑 | 张晓玲 面对如今科技圈言必称 “AINative” 的热潮，阿里云资深副总裁、数据库产品事业部负责人李飞飞却显得颇为冷静，甚至主动给这股热潮 “降了降温”。 阿里云数据库产品技术架构部负责人王远在 1 月 20 日向华尔街见闻直言，现在很多厂商喊出的 “AI 原生” 口号其实有些 “大跃进” 了。相比于急着贴上 “原生” 的标签，阿里云 PolarDB 选择了一个更务实的目标——先做到 “AI Ready（AI 就绪）”。 为了让大家听懂什么是 “AI 就绪”，李飞飞用了一个直观的 “4+1” 公式。 想象一下，以前的数据库像是一个整齐划一的档案柜，只存文字和表格。但 AI 时代的数据五花八门，有图片、有视频、有日志。所以，“AI 就绪” 的第一步就是让数据库变成一个 “大湖”，既能存表格，也能存这些杂乱的数据，这叫做 “Lakebase（湖库一体）”。紧接着，数据库得学会像图书管理员一样，通过统一的元数据管理，把这些海量且碎片化的信息梳理清楚。 更有趣的改变在于让数据库 “长出脑子”。 李飞飞解释说，大模型虽然聪明，但它学到的都是过去的数据。如果你问它 “今天 PolarDB 大会来了多少人”，它肯定答不上来，因为它不知道此时此刻正在发生的事。这就是数据库的价值所在——它掌握着最新的 “热数据”。通过在数据库里直接运行 AI 模型（模型算子化），让大模型能实时读取最新的热数据，这样 AI 就不会 “产生幻觉”，能回答当下的问题。 至于那个 “+1”，指的就是要跟上硬件涨价的步伐。最近内存价格疯涨，阿里云通过技术手段把硬件资源 “池化”，就像共享单车一样，让大家共享昂贵的内存和算力，从而把成本打下来。 既然现在只是 “就绪”，那什么样的数据库才配叫 “AI 原生” 呢？李飞飞给出一个非常犀利的判断标准，他把这比作运动员的体格检查。 他说，这就好比一个人自称是国家级运动员，光看外表不行，得测体脂率。如果体脂率还在 20% 以上那就别吹牛了；只有降到 5% 以下，才具备世界级运动员的身体素质。 对应到数据库上，李飞飞认为真正的 “AI 原生” 必须达到两个硬指标：第一，你的数据库用户里，至少有一半不是人类，而是 AIAgent（智能体）；第二，数据库输出的内容里，有一半不是传统的表格数据，而是 AI 能读懂的 Token（语义单位）。只要没达到这两个标准，现在喊 “AI 原生” 大多是在讲故事。 虽然李飞飞在概念定义上很克制，但在实际应用上，企业们的动作却很快。 以造车新势力理想汽车为例，他们就没有把 PolarDB 仅仅当成一个存数据的仓库，而是把它变成了一个智能处理中心。理想汽车利用 PolarDB 的一站式能力，不仅完成了数据的清洗和打标，还在数据库内部直接进行特征提取和推理。 这意味着，从车辆产生的数据到最终的智能决策，数据不需要搬来搬去，在数据库内部就完成了 “化学反应”。这种用法，正是李飞飞口中 “AI 就绪” 的最佳样本。 除了技术，王远还特别提到了一笔经济账。在 AI 时代，不仅算力贵，连存数据的内存都在涨价，未来可能还要翻好几倍。这时候，云数据库的优势就体现出来了。 如果不使用云技术，企业自己买服务器，成本会越来越高。而 PolarDB 通过 “Serverless（无服务器化）” 技术，可以做到极致的弹性——没任务的时候甚至可以不占用计算节点，来了任务秒级启动。这种 “用多少付多少” 的模式，是在硬件涨价周期里帮企业省钱的关键。 可以说，阿里云这次传递的信号很明确：在通往未来的路上少玩概念多练内功。毕竟，只有当 AI 智能体真正接管了数据库的读写，那个传说中的 “AI 原生时代” 才算真正到来。 以下是与阿里云资深副总裁兼数据库产品事业部负责人李飞飞、阿里云数据库产品事业部产品管理与技术架构部负责人王远的对话实录： 问：从云原生数据库到 AI 就绪的怎样理解 “AI 就绪”？ 李飞飞：从原生到 AI 就绪，我和王远分享里面再三讲到这个点我认为 “4+1” 4 个点加 1 个底座。一是存储层走向 lakebase，数据库原来面向结构化的数据存储和湖的面向 semanticshortcut，甚至 answershortcutdata 的存储结合起来，是第一个 lakebase。这在 AI 时代，AIready 非常重要，因为 AI 时代，能处理的数据类型极大丰富了，因为我可以做 embedding，可以做特征提取，多模态检索，这是必要的第一步，走向 AIready，所以是 lakebase。 第二是源数据的统一管理，AI 时代的特点是数据源特别多，有日志、有交易产生的数据，甚至图片、文本、音视频，并且每一类数据类型、数据量特别大，同一类型的数据量和数据源特别多，所以元数据的统一关系变得很重要。以前的元数据几百 G、1T、2T，元数据可能就几兆，现在元数据就上 T，所以元数据的统一管理这里面变成很关键的抓手了，而且元数据要实时更新，我们把以前做的 ZEroETL 技术在是数据面的是 dataplan 技术，集成到元数据的管理上。数据源发生变化，matterdata 信息发生变化，我们可以实时同步到元数据管理这层，总结来讲是 matterformetters（音），元数据的统一管理。这是第二个关键能力。 第三个关键能力是多模态的检索和处理，从结构化走向半结构化、非结构化融合，结合 embedding 能力，向量、全文检索等多模态，这是第三。 第四个里面有两个小点：模型算子化 +AgentAI 的支持，这两个是有机在一起的。要在数据库里面做模型推理服务，在一年多前我们提出模型算子化，很多人不是很理解为什么干这个事儿？现在看非常自然，因为模型会吞噬所有数据，冷数据、温的数据全部会被模型吞噬掉，冷数据意义不大了，是模型参数的一部分。甚至温数据今天通过 lora 微调技术，也可以做到半实时地更新到模型里。 唯一目前看，不能被模型实时吞噬掉的数据就是热数据。因为模型今天不具备实时增删改查的能力，热数据一定是持久的、长期的有非常大的价值，那模型如果没有热数据的加持，会产生幻觉，对事实不能理解。 热数据和模型在线推理的时候产生化学反应，这是为什么我们在数据库里做模型算子化。未来一定是 token 的世界，未来在接下来一年 token 可能涨 100 倍甚至 1000 倍，全世界的 token 量。这些 token 怎么被消耗？对大多数企业和个人，直接 totoken，不知道怎么用的。像人一样，直接给他铁、铜、金不知道怎么用，但是你给他金项链、金手镯，他知道怎么用。所以一定要场景化使用 token，模型算子化和热数据的结合就这个价值。 场景化还有一个逻辑，模型算子化了，热数据实时转成 token，怎么场景化使用？要有各种各样的 Agent，面向 AgentAI，开发 Agent、部署 Agent、verticaAgent 跑在数据库上，这也是非常重要的能力。这是第四个方向，模型算子化 +AgentAI 的支持，这是数据库走向 AIready 的四个关键要素，lakebase、元数据统一技术、多模态检索和处理、模型算子化及 AgentAI 的支持。 “+1” 是什么呢？一定要跟上硬件的发展步伐，所有的系统，数据库、database、只不过硬件随着时间不断变化。我们小时候一台 386、486，当时内存 64K、32K，今天内存我们 PolarDB 结合，公共云上现在已经开通正式对外商业化服务，单实力可以做到 100 多 T 内存池化，可以挂载 CPU+GPU 推理节点的 GPU，访问同一个内存池，底下存储池化，所以硬件的优化，包括像 serialold 的内存池化、PD 分离、KVcache 这些结合硬件的能力。KVcache 一定要结合硬件做，单从软件层面做 KVcache 没有意义，一定要结合硬件特点，GPU 机头里的 DRAM，CPU 机头的 DRAM，远端的 DRAM，HBM，这些怎样池化掉，还有和 SSD 这层。 所以结合硬件特点的持续迭代，内存强，刚才讲数据库最早发展的时候，关键挑战就是内存强，到今天内存强这个 “幽灵” 又回来了。刚才演讲说，内存在过去几个月涨了 30%—40%，接下来我们认为内存可能还要涨 2 到 3 倍。结合硬件的创新突破，这是 “4+1”，AIready 要干这么几件事情。 问：各位谈到数据库使用成本进一步降低，在降成本过程中，架构优化主要做了哪些内容？ 王远：关于成本，为什么有这么大的性价比和成本优势，总结起来三个点：一是资源的池化，二是多租共享，三是弹性伸缩。首先时至今日，从云计算时代到 AI 时代，有一个逻辑是没有变，只有规模化到一定程度，才能够有一定的成本优势或者成本红利，才能把这些东西释放给用户，让他享受到。所以 PolarDB 首先拥有云上最大规模的数据库用户，这是我们很高的护城河，所以决定了我们可以做这件事儿。 二是多租共享。技术层面，可以分存储层做了什么，内存做了什么，算力做了什么，存储层这边，刚才像李飞飞说了有冷、热、温三层数据，如果所有数据都是热数据，那成本肯定是居高不下的。而对于一个企业和组织来讲，大部分数据有一定的温属性、冷属性，需要的时候再翻出来，这时候 PolarDB 需要把自己进入更多的高性价比的存储介质，然后能对企业当中的数据做分类存储，但分类存储不是把管理负担转嫁给用户，需要数据库内部做智能化的冷热分层，智能化的数据调度、跨界流转和迁移，这是 PolarDB 存储层做的第一件事，降成本。 内存层，刚才说了 CXL 是我们大力推的技术，CXL 直观地感受是有一个超大规模的远端内存池，带来的效果是远端内存池可以复用的，多租共享复用的，它除了能够做内存高消耗的查询分析加速以外，也可以做到租户之间的共享。如果能够把内存利用率提高进而带动 CPU 的利用率提高这部分成本也是非常可观的，结合目前内存在疯狂的涨价趋势，未来会有更大的红利，通过这种技术手段，释放给用户。 因为 PolarDB 选择了一体化的架构，我们会把 TP、AP，加 IP 一体化处理，它带来技术上我们可以做的事情就是异构算力的混合调度。我可以把 GPU 和 CPU 的算力可以混合调度起来，比如我们在 PolarDB 内部做的，可以把 spark 框架和 ray 框架混部，这样 CPU 和 GPU 可以综合利用，同时 CPU 处理的东西，比如打标操作、ETL 操作用 CPU 处理完，可以根据 CPU 吞吐决定拉起多少 GPU，处理下一步的 embedding 操作，这些方面在提效同时，也会带来很可观的降本操作。 产品形态上，我们也做了设计，我们主推的 serverless，就是极致弹性的产品形态。未来我们认为 Agent 是数据库的主力用户，有一个调研报告说，新建的数据库可能有 80-90% 都是 Agent 自主创建的，那 Agent 是 7×24 小时的运行程序，它所带来的工作负载是完全不一样的，它有可能是高查询、高并发或者大查询的，也可能它一段时间内就是不工作的。这时候弹性的能力，极端情况下可以零计算节点，只有数据存储，没有算力，但一旦有算力来，可以秒级拉起对应计算节点，处理 Agent 或者用户提交的任务，通过产品形态，我们也能够保证在场竞争中有相应的价格优势。 我们通过一系列的技术手段，加产品形态设计，保证产品在市场上的价格竞争力。 李飞飞：随着存储成本上涨，是周期性的事情，我们回头看历史，过一段时间存储上涨，厂商提升产量，价格下来，但这次周期我个人认为非常长，因为它是时代的变革。 所以短期可能三到五年，存储的价格 DRAM 也好，整个 HBM 上涨，我个人认为，过去这么多年我们沉淀的云原生技术和产品能力，会越来越有价值。之前有些客户自建搞服务器，反正服务器不值钱，成本很低，这个时代一去不复返了，不做内存池化、不做存储池化，不做 serverless，不做弹性调度，成本会越来越高。这是我对未来的判断。 问：为了打造 AI 原生数据库，阿里内部不同产品能力打通上做了哪些努力？现在各家数据库厂商都在打造智能化数据库底座，PolarDB 给开发者带来的差异化体验是什么？ 李飞飞：阿里云所有产品最早和百炼打通的，一年多前我们在 political 开发者大会上，我们调模型跟百炼打通，还是有一些质疑的声音，你们为什么干这个事。现在回头看，绝对是轻舟已过万重山，是绝对应该干的事情。 可以给大家讲，PolarDB 以及整个瑶池数据库的 token 量增长，在过去短短几个月的增长超过 100 倍。就是通过瑶池数据库的产品，PolarDB 灵洞、RDS、ADB 调百炼也好，调模型算子化的服务也好，调 pai，我们 token 消耗量增加了 100 倍，短短几个月内，爆发式的增长。 二集成了哪些产品？百炼、pai，pai 提供了定制化的模型推理服务能力和微调能力。 三我们自己做了模型算子化的服务，这样我们在 SLA 弹性瞬间爆发上，自己也可以做 overflow 提供模型推理的能力，这是模型算子化。而且所有这些通过 SQL 语句或 API。接下来我们重点做的事情，当然我们已经具备了这个能力，但不完美，除了 SQLAPI，开放的 SDK，我们接下来要支持自然语言。自然语言用大模型自然语言方式来无缝调用所有这些，从 TP 到 HP、IP 全部打通。这是我们目前的情况。 这是和 AI 直接相关的，AI 和存储团队、计算团队，阿里的存储计算都是深度集成的。回应您刚才的问题，AI 方向对接了哪些产品。 王远：刚才分享的时候有一个观点，未来数据库用户不仅仅是现在的开发者，还有更多的普通用户，未来我们也认为他是数据库的直接用户，因为大模型能力让我们的数据库未来真的很大概率具备直接服务普通用户的能力，基于这个假设，开发者的体验，首先传统数据类开发者我们做了哪些体验化的提升？到今天为止，PolarDB 选择的就是一体化的路，在 AI 时代一体化的路，就是选择了 lakebase 的技术路径。它从传统的云原生关系型的数据库处理结构化数据，到现在对非结构化数据、半结构化数据，所有多模态数据的全力处理能力的支持。 具体到面向开发者提供的能力，最基础的向量。向量能力一定会提供给开发者的，对 AI 时代来讲，向量一定是最通用的一类数据表征，我们认为 AI 时代如果数据库不支持向量，基本上不能说这是 AI 时代的数据库，除了向量还不够，因为向量只是其中一种表征，对于一个企业或组织应用来讲，多模态的数据管理是关键，特别是一些企业的经验和知识。 比如持续施工的数据、graph 数据、全文数据，大量业务标签都是全文数据，这些东西都要提供一体化的多模管理能力。再往上我们需要对于开发者更好地体验来讲就是数据库和应用走得越来越近，这个基础上，提供一些一体化 rag 能力。还有 circle 里引入模型算子，能够让我们开发者至少在 circle 里方便集成大模型能力，不管大模型部署在数据库内部还是以 MaaS 方式提供的远程调用服务，都能够给开发者提供一体化的透明的服务方式。这是我们定义面向开发者的体验能力升级。 面向普通用户，我们认为未来更大的增长空间是在这，或者说数据库要能够出圈，比如超出数据圈，进入 AI 圈，或者跟 AI 走得近的时候，下一步的体验更关键。比如自然语言交互和多模态交互，这个能力是我们现在 PolarDB 已经给用户提供了，未来这个可能会是主流，我们认为未来一定基于命令行的交互，基于工具的交互会存在，会存在于 Agent 和数据库之间的交互，通过命令行和脚本交互，而用户和数据库的交互一定是通过自然语言、多模态更直觉的交互方式提升我们的用户体现。 第二我们希望数据库对数据的管理更贴近人的思维方式。具体表达是什么呢？除了我在管理数据，管理 schema（音）的时候，我们需要对知识、对记忆做管理，包括我的知识怎么组织，我的记忆，工作记忆、事实性的记忆，经验性的记忆，怎么管理流转，这些东西我们希望 PolarDB 能够提供对应的记忆管理能力或知识管理能力。 第三对于智能体开发应用的支持。未来我们希望 PolarDB 作为 datacentric 的 AIinfrastructure，我们对 PolarDB 是抱有厚望的。 问：AIready 阶段，从 2022 年到 2025 年，四年的时间，刚才分享了四大能力，包括模型算子、多模态处理能力，我们到了 2026 年年初阶段，具备了四大能力以后，真正完成了 AIready 阶段了吗？ 李飞飞：今天开发者大会讲的能力是 AIready 的 connected data base，今天有些数据库厂商已经喊出 AInative，我们还是实事求是，不想那么喊，因为 AI 赛道本身还在快速演进，一天一个样。中国卷 14 个小时睡觉，美国人白天开始接着卷，全球接力卷，而且两边还不是完全接力，overlap，我们干 14 小时，人家也干 14 小时，我们还没睡觉的时候人家已经起来干活了，我们准备睡觉的时候，他们接着干。 AI 赛道，现在喊 AInative 过早，因为 AI 本身还在快速变革，这是为什么我们坚定喊 AIready，不要喊 AInative，现在喊 AInative 我觉得是大跃进，谁喊 AI native data base 谁就是大跃进。因为 AI 本身在快速变革，就是 AIready，回应什么时候是 AInative 呢？以及 AInative 数据库长什么样子呢？我们可以畅想未来，没有问题，对未来有判断。我不认为现在任何人做到了所谓的 AInative，喊这个都是讲故事，而我们讲 AIready 是实时，一步一个脚印做到了。 第二 AInative 未来长什么样？两句话：（1）未来的世界一定是海量 Agent 使用数据库的世界。（2）未来世界一定是 tokendominant 的事件。从这两个标准衡量，数据库是不是 AInative 了，比如这个数据库上两个关键标准，比如你衡量一个运动员是不是国家级的运动员，我也可以说我是国家级运动员，但你不信。关键指标体脂率，如果体脂率在 20-25%，你说是国家级运动员扯了，起码在 5% 以下了，世界级运动员，或者至少 7% 以下。你的基本运动素养要达到一定标准。 海量 Agent 使用数据库，二是海量的 token。如果一个数据库进入 AInative 时代衡量标准是它有多少实力是 Agent 在使用，数据库至少一半的实力是 Agent 在使用，这是第一个标准。第二它的 output，今天数据库的 output 很多时候是表格，一行行。它的 output，bytes 来衡量，因为行和 token 没法对比，没关系我们 cover 到 bytes，它的 outputbytes 的一半是 token，做到这两个就是 AInative，还没到的，拿照妖镜照一下。 要做到哪些事情做到 AI native data base 呢？ 以终为始，倒推，我要干到这两件事，我需要干哪些东西？这是逻辑性地思考问题的框架，我要让我实力的一半是 Agent，突出 bytes 一半是 token，我数据库要做什么？就要坚定的刚才讲的方向上持续迭代和演进，比如模型算子化、无缝集成模型调用能力，Agent，甚至不光是单 Agent，多 Agent 编排、调用，marketAgent 协同，数据库里怎么支持，而且超级强的多租能力。SaaS 场景是多 Agent 的雏形，未来多 Agent 一定比今天的 SaaS 还 SaaS。所以多租隔离会变成刚性需求。 然后多版本迭代，AI 推理的无缝集成，还有 rag 知识库，这是我们刚才讲的，rag 就是多模态检索，实时知识的更新 embedding，这是未来 AInative 的关键特点。还有无缝自然语言查询，甚至不是查询，而是自然语言定义问题，从问题直接到查询，到 action。 为什么我讲 action？淘宝电商讲，订单系统下单，最终都是数据库，所以数据库是天然 action 发生的地方，只不过 action 以前是通过 API 的方式兑换它，以后 AInative 很有可能是 Agent 直接给数据库下指令。数据库就是 action 发生的地方。 千问 APP 打通了阿里所有的生态，但万变不离其宗，通过千问自然语言订奶茶或者淘宝上下单，找这样的衣服，它给你生成照片，你说要这样的衣服淘宝里面下单，最终 action 发生在数据库里面的，AInativedatabase 一定是 action 发生的地方。 问：阿里系还有千问大模型以及现在很多原生 Agent 应用前段时间千问 APP 算是国内最早可以进行在阿里系进行跨应用调用，PolarDB 跟他们有没有进行探索性的合作，有没有一些实践性的经验？ 李飞飞：有很多。刚才主论坛分享里面我们也请了百炼 PD 做分享，我们是深入协同。 王远：现在这个时代，数据是燃料，数据库是引擎，我们要更好给大模型输动力，集团肯定是我们很好的试验田。千问前段时间和阿里整个打通，阿里云内部是百炼不说最大的调用者，也是阿里云内部最大调用者之一了，我们每天 token 消耗从年初到现在已经翻了几百倍，就是我们自己的消耗。 大家有没有关注数据库领域下半年除了大模型以外，还有一个比较火的概念，起源于一个开源项目 superbase，它的理念是后端即服务。设计理念是以数据库为核心，把企业级应用所需要的后台服务，长在数据库上。这个理念虽然很直接，但能想通的人非常了不起。 问：未来 Agent 可能存在很多跨应用调用情况，上面是不是也要做很多智能体信任协议？ 王远：是的，像多人协同，MartinAgent 系统，atoa 这套体系要支持的，Agent 之间访问肯定也需要互相健全的，刚才 PolarDB 在集成 backendservice 以后，并向支撑 Astrategicapplication（音）这个方向做的时候，包括 atoa，MCP 这套东西，都需要纳管进来的。我刚才说的未来可能数据库的终端用户不太会使用命令行，但我说得未来比较长，短期内肯定还是需要的。长期演进我个人认为，Agent 是访问数据库的主力的话，那 MCP、atoa 甚至各种程序、脚本东西，都应该是 Agent 自己写、自己生成、自己调用，人就是给数据库提问题。 问：现在阿里云的 PolarDB 还是 AIready，不属于 AI 原生，目前是谁在用？而一些客户担心所谓的 AI 原生有顾虑带来更高成本。 李飞飞：今天有理想、度小满等，当然不是每个客户实践都用了 AIready 的产品能力，但理想绝对用了，我刚才分享也讲了，它构建一站式的数据平台，从数据打标清洗做 embedding 特征提取，再到和交易数据打通、热数据打通，做在线推理，这些能力它全用了，本质上 lackbase+ 多模检索 + 模型算子化和调用百炼，这几个能力都用了。 另外我们有最佳实践的书，后面也给了电子版的码，大家可以扫一下，就是 PolarDBAI 实践全景加速企业大模型应用落地，里面有十几个到二十个案例，都是头部企业客户，有各行各业。第一个问题举了理想的例子，而最佳实践 PolarDB 的 AI 能力，现在有哪些客户在用，怎么用？已经有超级无敌多的案例。这本书是总结，大家可以看一下。待会儿二维码大家扫一下。 AIready 到 AInative 这些都是概念，今天我们不要做概念支撑，未来世界一定是 AInative 的世界，什么时候走到那个世界？我不知道，但它一定是加速实现的，但今天这个节点，我不认为我们可以 clam（音）到 AInative。因为 AI 本身都在发生巨变，怎么定义什么叫 AInative 呢？这是我刚才讲的逻辑。但我们每个人都在向 AInative 狂奔，包括 PolarDB 自己。这是刚才讲的核心逻辑。 问：如果是传统的组合，比如我用的搜索引擎 + 传统数据库或者说传统数据库 + 向量数据库 + 内存数据库的组合，我迁到 Agentic 架构下需要做什么改变，能得到什么收益？ 王远：面向 AI oriented data infra 要不要推倒重建及本质是一个问题，你问我，不用。本身大家拥抱 AI，特别是企业拥抱 AI，应该采用平滑迁移演进的思想，但只是速度相比于传统时代要加速，而不是被动地等着平滑升级，只是平滑升级的过程一定是加快的。 如果全盘推翻重建，不能说错，但有一点过于激进和冒险的选择。所以 PolarDB 也是基于这个前提设计自己，怎样支持用户从传统的 IDC 或传统的架构，升级成云原生架构，进一步升级成 AIready 的数据平台，其实 PolarDB 有一整套的设计，具体说起来，可以说到三个点： 1.本身 PolarDB 是云原生关系型数据库，这是基础。引申到 AI 时代，PolarDB 是我们热数据的入口，所以 PolarDB 也一直会兼容 PG 和 MySQL，和这两个生态完整的兼容应用，让应用迁过来不用改，我们还会提供积分一体的方案，平滑迁移的方案。这是要保证客户在用 PolarDB 做 datainfra 或 AIinfra 升级的时候，现有应用不中断，更平稳。因为要保证客户业务正常运行，再做能力的升级，这是最直接最能够让人接受的方式，所以第一步 PolarDB 一定会做好热数据的入口这关，一定支持好所有 TP 在线类的业务，并提供完整的平滑升级解决方案。 2.PolarDB 自身关联 lakebase 架构，因为热数据进来以后，会成功激活企业内部的温数据和冷数据，所以 PolarDB 提供了温数据、冷数据平滑入湖的方案，目前如果用传统的架构，比如 ES、MySQL、PG 搞得在线库，这些数据肯定都是割裂的，业务上一条数据发生变化，它在你的对象存储、文件系统里，对应的文件不可能发生变化的，所以 PolarDB 的 lakebase 架构，把所有的冷温数据能够做到一体化的集成纳管，并能够做到 matedata 之间的一致性和联动。 就是说我增加一个业务标签，或者增加一条修改记录，对应到文件系统或对象存储系统上的 rodata（音）会对应的 updata，这样能够真正做到多模数据的实时性、一致性的一体化更新。数据的一致性、正确性和实时性保证了之后，这是业务创新的基础，这是第二层，做到冷、热、温三层数据在保证一致性、正确性和实时性基础上的联动。 3.我们会提供一系列的让客户易于创新的支撑，包括我说的托管 ray 框架，为客户处理数据，更快托管 superbase 框架，能够开发它的企业级应用更快，跟 MaaS 集成、defend 集成、coder 集成全部都在做。你能想象的，任何开发方式的选择，PolarDB 都可以做很好地支持，因为选择 webcoding 的企业有，但还有一部分企业为了保证业务流程平滑，会选择 workflow 的方式，只不过 workflow 的过程中，每一个节点会引入 Agent，保证效率更高，所以 PolarDB 作为数据平台，需要支持各种各样的 AI 转型应用，这方面我们会充分和生态兼容对接。 大概这三层：热数据的入口、多模数据的管理和联动，然后 AI 生态的兼容支持。这是我们给 PolarDB 提供的转型升级方案的三个关键点。 问：过去几年我们看到 AI 浪潮来临以后，针对中小企业的价格普惠，曲线一直向下，尤其是阿里的公有云部分。另一方面又看到硬件一直在涨价。模型算子化和您说的 AIready 对过去的曲线有什么变化？另外对阿里云过去的收入模式或商业模式，有什么优化提升的部分？ 李飞飞：我们作为云计算本质上，包括 AI 平台化的公司，云计算和 AI 平台化的公司，本质上是规模化的生意，生意的角度是规模。规模越大越能释放规模成本下降的逻辑，边际成本越低，越能给终端客户释放红利，有越高的价值。 过去几年我们持续做普惠的面向中小客户的普惠降价，本质是通过核心两点： 1.技术创新，我们不断做池化、多租、弹性，比单租的使用效率高，所以能释放价格红利，这是最核心的点。 2.规模，规模越大，越容易做弹性的调度。规模小怎么调？没什么好调的。规模越大，腾挪空间越大，越能削峰填谷、弹性调度，释放出规模效应。 第一个点和第二个点有双轮驱动的效果，所以我们能持续释放红利，让大多数的企业客户能吃到红利，这是价格曲线的逻辑。 另外现在面对新一波内存存储周期性涨价，这波周期会相当长，以前存储价格跌到地板价了，存储厂商不愿意生产，它有产能，限制产能，所以价格上涨，价格一上涨总有一个人忍不住跳出来生产，因为产能足够的，价格马上就打下来了。这一轮逻辑是产能根本不够，不是他们故意踩刹车，需求爆发式增长，开足马力，开足所有产能也满足不了市场需求，所以这波存储周期涨价是相当长期的，底层逻辑是这个。 存储涨价带来整个链条上的价格上涨，通算服务器，智算，GPU 今天大概率也会涨价，GPU 里也有 HBM、DRAM，底层一样的。这波涨价是持续长周期的，但历史角度看，最终它也有周期，当 AI 变成非常成熟的产业的时候，变革没有像今天这么快，每天发生变化的时候，就会回到周期性的周期，这是食物发展的客观规律，而当下这波周期会相对比较长。我的判断。 怎么帮客户创造价值呢？这个时代云计算厂商、AI 平台厂商能发挥更大的价值，能够创造更大的客户价值，比你自购资源、自己管理资源，越是在成本高的时候越能发挥更大价值，因为你有规模效应，任何单体客户很难有这么大的，像云计算和 AI 厂商这么大的规模协同效应，边际成本下降的逻辑。所以越是 bombcost 上涨的时候，平台化的规模，运营的效率提升越有价值。