Amid the current tech frenzy where everyone talks about "AI Native," Li Feifei, Senior Vice President of Alibaba Cloud and Head of the Database Product Business Unit, remains notably calm, even actively trying to "cool down" the hype. Wang Yuan, Head of Database Product Technology Architecture at Alibaba Cloud, stated candidly on January 20th that many vendors' chants of "AI Native" are somewhat of a "Great Leap Forward." Rather than rushing to stick on a "Native" label, Alibaba Cloud's PolarDB has chosen a more pragmatic goal—to first achieve "AI Ready." To help everyone understand what "AI Ready" means, Li Feifei used an intuitive "4+1" formula. Imagine that databases of the past were like neat, uniform filing cabinets, storing only text and tables. But data in the AI era is diverse, including images, videos, and logs. Therefore, the first step of "AI Ready" is to turn the database into a "big lake," capable of storing both tables and this messy, unstructured data—this is called "Lakebase." Next, the database must learn to act like a librarian, using unified metadata management to organize these massive and fragmented pieces of information. A more interesting change involves giving the database a "brain." Li Feifei explained that while large models are intelligent, they have only learned from past data. If you ask one, "How many people attended the PolarDB conference today?" it certainly wouldn't know the answer because it isn't aware of events happening right now. This is where the database's value lies—it holds the latest "hot data." By running AI models directly within the database (model operatorization), large models can read the most recent hot data in real-time, preventing AI from "hallucinating" and enabling it to answer current questions. As for the "+1," it refers to keeping pace with rising hardware costs. With memory prices soaring recently, Alibaba Cloud uses technical means to "pool" hardware resources, much like shared bicycles, allowing everyone to share expensive memory and computing power, thereby driving down costs. Since the current state is merely "Ready," what kind of database truly deserves to be called "AI Native"? Li Feifei offers a very sharp criterion, comparing it to an athlete's physical examination. He said it's like someone claiming to be a national-level athlete; you can't just judge by appearance, you need to measure their body fat percentage. If it's still above 20%, they shouldn't boast; only when it drops below 5% do they possess the physical conditioning of a world-class athlete. Applying this to databases, Li Feifei believes that true "AI Native" must meet two hard metrics: First, at least half of your database users should not be human, but AI Agents. Second, at least half of the database's output should not be traditional tabular data, but Tokens (semantic units) that AI can understand. Unless these two standards are met, most claims of being "AI Native" today are just storytelling. Although Li Feifei is restrained in defining concepts, enterprises are moving quickly in practical applications. Taking the new car manufacturer Li Auto as an example, they do not treat PolarDB merely as a data storage warehouse but have turned it into an intelligent processing center. Utilizing PolarDB's all-in-one capability, Li Auto not only completes data cleaning and labeling but also performs feature extraction and inference directly within the database. This means that from the data generated by vehicles to the final intelligent decision-making, data does not need to be moved around; the "chemical reaction" happens entirely within the database. This usage pattern is the perfect example of what Li Feifei calls "AI Ready." Beyond technology, Wang Yuan specifically mentioned the economic aspect. In the AI era, not only is computing power expensive, but even the memory used for storing data is seeing price hikes, potentially increasing several times over in the future. Here, the advantage of cloud databases becomes evident. If cloud technology is not used, and enterprises buy their own servers, costs will keep rising. Through "Serverless" technology, PolarDB achieves ultimate elasticity—it can even occupy zero compute nodes when there are no tasks, and start up in seconds when a task arrives. This "pay-as-you-use" model is key to helping enterprises save money during a cycle of rising hardware costs. It's clear that the signal Alibaba Cloud is sending is this: on the path to the future, focus less on buzzwords and more on honing internal capabilities. After all, only when AI Agents truly take over the reading and writing of databases will the legendary "AI Native era" truly arrive. The following is a transcript of dialogues with Li Feifei, Senior Vice President of Alibaba Cloud and Head of the Database Product Business Unit, and Wang Yuan, Head of Product Management and Technology Architecture for the Database Product Business Unit at Alibaba Cloud: Question: How should we understand "AI Ready" in the transition from cloud-native databases? Li Feifei: From native to AI Ready, Wang Yuan and I have repeatedly emphasized this point. I believe in the "4+1" concept: four points plus one foundation. First, the storage layer moves towards lakebase, integrating the database's original structured data storage with the lake's storage for semantic data, even answer data. This is the first aspect, lakebase. In the AI era, being AI Ready is crucial because the types of data that can be processed are vastly enriched, as we can perform embedding, feature extraction, and multimodal retrieval. This is the necessary first step towards AI Ready, hence lakebase. Second is unified metadata management. A characteristic of the AI era is the multitude of data sources—logs, transaction data, even images, text, audio, and video—with each data type having enormous volume and numerous sources. Thus, unified metadata management becomes very important. Previously, metadata might have been a few megabytes for hundreds of gigabytes or terabytes of data; now metadata itself can reach terabytes. So unified, real-time metadata management becomes a critical focus. We've integrated our previous Zero-ETL technology, specifically data plane technology, into metadata management. When data sources change, metadata information changes, and we can synchronize it in real-time to the metadata management layer. In summary, it's about unified metadata management. This is the second key capability. The third key capability is multimodal retrieval and processing, moving from structured to semi-structured and unstructured integration, combined with embedding capabilities, vector search, full-text search, and other multimodal abilities. This is the third point. The fourth point contains two sub-points: model operatorization + support for Agent AI; these two are organically linked. Providing model inference services within the database—we proposed model operatorization over a year ago, and many didn't understand why. Now it seems very natural because models will consume all data; cold data, warm data, all will be consumed by models. Cold data becomes less significant, becoming part of the model parameters. Even warm data can now be semi-realtime updated into models via LoRA fine-tuning techniques. The only data that currently cannot be consumed in real-time by models is hot data. Because models today don't possess real-time CRUD (Create, Read, Update, Delete) capabilities, hot data remains persistently valuable. Without the support of hot data, models can hallucinate and fail to comprehend facts. The chemical reaction between hot data and online model inference is why we implement model operatorization within the database. The future is undoubtedly a world of tokens; in the coming year, the global volume of tokens might increase 100 or even 1000 times. How will these tokens be consumed? For most enterprises and individuals, directly dealing with tokens is impractical—they wouldn't know how to use them. It's like giving someone iron, copper, or gold; they wouldn't know what to do, but give them a gold necklace or bracelet, and they understand. So tokens must be used contextually. The combination of model operatorization and hot data provides this value. Another aspect of contextualization: once models are operatorized and hot data is converted to tokens in real-time, how are they used contextually? This requires various Agents. Supporting Agent AI—developing, deploying, and running Agents on the database—is also a crucial capability. This is the fourth direction: model operatorization + support for Agent AI. These are the four key elements for a database to become AI Ready: lakebase, unified metadata technology, multimodal retrieval and processing, and model operatorization with Agent AI support. What is the "+1"? It is imperative to keep up with hardware development. All systems, databases, are merely hardware that changes over time. When we were young, a 386 or 486 computer had 64K or 32K of memory. Today, PolarDB, integrated and commercially available on the public cloud, can achieve a single instance with over 100TB of pooled memory, attaching CPU+GPU inference nodes with GPUs that access the same memory pool, with underlying storage also pooled. Hardware optimization, including technologies like serial memory pooling, compute-storage disaggregation, and KV cache combined with hardware capabilities, is essential. KV cache must be implemented in conjunction with hardware; doing it purely in software is meaningless. It must leverage hardware characteristics—DRAM in GPU nodes, DRAM in CPU nodes, remote DRAM, HBM—and how to pool these, along with the SSD layer. Therefore, continuous iteration that combines hardware characteristics is vital. Memory constraints, which were a key challenge in the early development of databases, have returned as a "ghost." As mentioned in the speech, memory prices have risen 30-40% in the past few months, and we believe they may increase another 2 to 3 times. Innovation breakthroughs that combine hardware advancements constitute the "+1" in the "4+1" framework for achieving AI Ready. Question: You mentioned further reducing database usage costs. What architectural optimizations have been primarily made in this cost reduction process? Wang Yuan: Regarding cost, the significant cost-performance advantage can be summarized in three points: first, resource pooling; second, multi-tenancy sharing; third, elastic scaling. Firstly, from the cloud computing era to the AI era, one logic remains unchanged: only at a certain scale can cost advantages or dividends be achieved and passed on to users. PolarDB boasts the largest user base of databases on the cloud, which is our strong moat, enabling us to do this. Second is multi-tenancy sharing. Technically, we can look at what's done at the storage layer, the memory layer, and the compute layer. At the storage layer, as Li Feifei mentioned, there are cold, warm, and hot data tiers. If all data were hot, costs would undoubtedly remain high. For an enterprise or organization, most data has some warm or cold attributes, only needing retrieval when required. PolarDB needs to incorporate more cost-effective storage media and perform intelligent cold-hot tiering, intelligent data scheduling, cross-tier flow, and migration internally within the database, without burdening the user with management. This is the first thing PolarDB does at the storage layer to reduce costs. At the memory layer, as mentioned, CXL is a technology we strongly promote. The intuitive feeling of CXL is having an ultra-large-scale remote memory pool, which allows for reuse and multi-tenant sharing. Besides accelerating memory-intensive query analysis, it also enables sharing among tenants. Improving memory utilization, which in turn boosts CPU utilization, leads to significant cost savings. Combined with the current sharp rise in memory prices, greater future dividends can be released to users through such technical means. Because PolarDB adopts an integrated architecture, handling TP, AP, and IP together, we can achieve hybrid scheduling of heterogeneous computing power. We can mix and schedule GPU and CPU resources. For example, within PolarDB, we can co-locate Spark and Ray frameworks, allowing comprehensive use of both CPU and GPU. CPU handles tasks like labeling and ETL operations, and based on CPU throughput, we can scale up GPUs for subsequent embedding operations. This not only improves efficiency but also brings considerable cost reduction. In terms of product form, we've also designed our flagship Serverless offering for extreme elasticity. We believe Agents will be the primary users of databases in the future. One research report suggests 80-90% of new databases might be autonomously created by Agents. Agents are 7x24 running programs, generating completely different workloads—they could involve high queries, high concurrency, or large queries, or be idle for periods. Elasticity is key here; in extreme cases, there can be zero compute nodes, only data storage, but compute nodes can start in seconds when needed to handle tasks submitted by Agents or users. Through this product form, we ensure a corresponding price advantage in the market. Through a series of technical means and product design, we guarantee the product's price competitiveness in the market. Li Feifei: The rise in storage costs is cyclical. Looking back historically, storage prices rise, manufacturers increase production, and then prices fall. But I believe this cycle will be very long because it's an era of transformation. So, in the short term, perhaps three to five years, prices for DRAM and HBM will rise. I believe the cloud-native technologies and product capabilities we've accumulated over the years will become increasingly valuable. Previously, some clients built their own servers because servers were cheap; that era is gone. Without memory pooling, storage pooling, Serverless, and elastic scheduling, costs will keep rising. That's my judgment for the future. Question: What efforts has Alibaba made internally to integrate different product capabilities for building an AI-native database? With various database vendors building intelligent database foundations, what differentiated experience does PolarDB offer developers? Li Feifei: Alibaba Cloud's products were the earliest to integrate with Bailian. Over a year ago, at our developer conference, when we discussed model tuning integration with Bailian, there were some doubts about why we were doing this. Looking back now, it was absolutely the right thing to do, like a light boat passing through ten thousand mountains. I can tell you that the token volume for PolarDB and the entire Yaochi database family has grown over 100 times in just the past few months. Through Yaochi database products—PolarDB Lingdong, RDS, ADB—whether tuning Bailian, using model operatorization services, or using PAI, our token consumption has increased 100-fold, an explosive growth in a short period. Secondly, which products are integrated? Bailian and PAI. PAI provides customized model inference services and fine-tuning capabilities. Third, we developed our own model operatorization service, allowing us to handle SLA, elasticity, and instant bursts, and even provide overflow model inference capability ourselves. This is model operatorization. All these are accessible via SQL statements or APIs. Our next focus, though we already have the capability but it's not perfect, is to support natural language beyond SQL/API and open SDKs. We aim to enable seamless invocation of all these capabilities—from TP to HP to IP—using natural language through large models. This is our current status. This relates directly to AI. The AI, storage, and computing teams at Alibaba are deeply integrated. That addresses your question about which AI-related products we've connected with. Wang Yuan: I shared a viewpoint earlier: future database users will not only be current developers but also more ordinary users. We believe they will become direct users because large model capabilities make it highly probable that databases will eventually serve ordinary users directly. Based on this assumption, regarding developer experience: What improvements have we made for traditional database developers? To date, PolarDB has chosen an integrated path for the AI era, which is the lakebase technical path. It extends from traditional cloud-native relational database handling of structured data to full support for processing unstructured data, semi-structured data, and all multimodal data. Specifically, in terms of capabilities provided to developers, the most fundamental is vector support. Vector capabilities must be provided; for the AI era, vectors are arguably the most universal form of data representation. We believe if a database doesn't support vectors in the AI era, it can hardly be called an AI-era database. But vectors alone are not enough, as they are just one representation. For an enterprise or organization's applications, multimodal data management is key, especially for corporate experience and knowledge. For example, time-series data, graph data, full-text data—many business tags are full-text data—all these require integrated multimodal management capabilities. Further up, to provide a better experience for developers, the database and applications are moving closer. On this basis, we provide integrated RAG capabilities. Also, introducing model operators into SQL allows developers to conveniently integrate large model capabilities within SQL, whether the models are deployed inside the database or called remotely as MaaS. This offers developers a unified, transparent service approach. This is how we define the upgraded experience for developers. For ordinary users, we believe the greater growth potential lies here, or for databases to break out of the data circle into the AI circle. The next key experience is natural language interaction and multimodal interaction. PolarDB already provides this capability to users, and it may become mainstream. We believe command-line and tool-based interactions will persist, but for interactions between Agents and databases. However, interaction between users and databases will increasingly be through more intuitive natural language and multimodal methods, enhancing user experience. Second, we want database data management to align more closely with human thinking. What does that mean concretely? Beyond managing data and schemas, we need to manage knowledge and memory—how knowledge is organized, working memory, factual memory, experiential memory, and how these are managed and flow. We hope PolarDB can provide corresponding memory management or knowledge management capabilities. Third is support for Agent application development. In the future, we have high hopes for PolarDB as a data-centric AI infrastructure. Question: The AI Ready phase spans from 2022 to 2025, four years. You mentioned four major capabilities, including model operatorization and multimodal processing. By the beginning of 2026, having these four capabilities, will we have truly completed the AI Ready stage? Li Feifei: The capabilities discussed at today's developer conference are for an AI Ready *connected database*. Some database vendors are already shouting "AI Native," but we prefer to be realistic and not jump the gun because the AI field itself is evolving rapidly, changing daily. In China, people work intensely, maybe sleeping 14 hours? Americans start working during their day, creating a global relay race, and it's not entirely sequential—there's overlap. We work 14 hours, they work 14 hours; sometimes they start before we've even slept. The AI赛道 is moving too fast to declare "AI Native" now. That's why we firmly advocate "AI Ready," not "AI Native." Claiming "AI Native database" now is, I think, a Great Leap Forward. Because AI itself is changing rapidly, "AI Ready" is the appropriate term. As for when it becomes "AI Native" and what that looks like, we can envision the future. I don't think anyone has truly achieved so-called "AI Native" yet; those claims are storytelling. We focus on "AI Ready," achieving it step by step. Secondly, what will AI Native look like? Two statements: (1) The future world will be one where massive numbers of Agents use databases. (2) The future world will be token-dominant. Use these two standards to measure if a database is AI Native. It's like measuring if an athlete is national-level; I could claim it, but you wouldn't believe it without key metrics like body fat percentage. If it's 20-25%, claiming national level is nonsense; it needs to be below 5% for world-class, or at least below 7%. Basic athletic素养 must meet a standard. Massive Agent usage of the database is the first standard. Second, massive token output. If a database enters the AI Native era, the measure is: what portion of its instances are used by Agents? At least half of its instances should be used by Agents—that's the first standard. Second, its output: today, database output is often tables, rows. Its output, measured in bytes—since rows and tokens aren't directly comparable, we can use bytes—should have half of its output bytes as tokens. Achieving these two means it's AI Native. Those not meeting them should be examined critically. What needs to be done to achieve an AI Native database? Start with the end goal and work backward. To achieve these two things, what is needed? This is a logical framework. To have half my instances used by Agents and half my output bytes as tokens, what must the database do? It must steadfastly iterate and evolve in the directions mentioned: model operatorization, seamless integration of model calling capabilities, support for Agents—not just single Agents but multi-Agent orchestration, invocation, market Agent coordination—how to support these in the database, plus super-strong multi-tenancy. SaaS scenarios are the precursor to multi-Agent; future multi-Agent will be even more SaaS-like than today's SaaS. So multi-tenant isolation will become a rigid requirement. Then, multi-version iteration, seamless integration of AI inference, and RAG knowledge bases—which relates to multimodal retrieval and real-time knowledge update embedding—are key characteristics of future AI Native. Also, seamless natural language querying, or even beyond querying—natural language problem definition, going directly from problem to query to action. Why action? Take Taobao's e-commerce order system; ultimately, everything lands in the database. The database is the natural place where actions occur, though previously actions were triggered via APIs. In the AI Native future, it's likely Agents will give direct instructions to the database. The database will be the place where actions happen. Qwen APP has integrated all of Alibaba's ecosystem, but the essence remains: through Qwen's natural language, ordering milk tea or placing an order on Taobao, finding clothes based on a generated photo—the final action happens in the database. An AI Native database must be the place where actions occur. Question: Alibaba also has the Qwen large model and many native Agent applications. Qwen APP was among the earliest in China to enable cross-application calls within the Alibaba ecosystem. Has PolarDB conducted exploratory cooperation with them? Any practical experience? Li Feifei: There's a lot. In the main forum分享, we also invited Bailian PD to share; our collaboration is deep. Wang Yuan: In this era, data is the fuel, and the database is the engine. We need to provide better power for large models. The Group is certainly a great testing ground for us. Qwen's recent integration across Alibaba; within Alibaba Cloud, Bailian is one of the biggest, if not the biggest, internal consumers. Our daily token consumption has increased hundreds of times since the beginning of the year—that's our own usage. Have you noticed in the database field, besides large models, another hot concept emerged recently, originating from an open-source project called Superbase? Its理念 is Backend-as-a-Service. The design philosophy is to center around the database, building enterprise-level application backend services on top of it. This concept is straightforward but requires significant insight to fully grasp. Question: With future Agents likely involving many cross-application calls, will there also be a need for many Agent trust protocols on top? Wang Yuan: Yes, like multi-agent协同, multi-agent systems, the A-to-A (Agent-to-Agent) framework needs support. Agent interactions will certainly require mutual authentication. As PolarDB integrates backend services and moves towards supporting strategic applications, including A-to-A, MCP (Model Context Protocol), these need to be incorporated. I mentioned earlier that future end-users might not use command lines, but that's a longer-term view; short-term, it's still needed. In the long-term evolution, if Agents are the main users accessing databases, then MCP, A-to-A, and various programs/scripts should be written, generated, and called by Agents themselves. Humans will simply pose questions to the database. Question: Currently, Alibaba Cloud's PolarDB is AI Ready, not AI Native. Who is using it currently? And some customers are concerned that所谓的 AI Native might bring higher costs. Li Feifei: Current users include Li Auto, Du Xiaoman, etc. Of course, not every customer uses all the AI Ready product capabilities, but Li Auto definitely does, as I mentioned. They built a one-stop data platform, using data labeling, cleaning, embedding, feature extraction, integration with transaction data and hot data, and online inference—essentially using lakebase, multimodal retrieval, model operatorization, and calling Bailian. These capabilities are all used. Furthermore, we have a best practices book; an electronic version QR code was provided later. It's called "PolarDB AI Practice: Panoramic Acceleration of Enterprise Large Model Application Landing," containing over a dozen to twenty case studies from leading enterprise clients across various industries. The first question used Li Auto as an example, but the best practices show PolarDB's AI capabilities are already used by many clients. The book summarizes this; everyone can scan the QR code later. Concepts like AI Ready to AI Native are just that—concepts. Today, we shouldn't focus on conceptual claims. The future world will be AI Native, but when we reach it is uncertain, though it's accelerating. At this point, I don't think we can claim to be AI Native because AI itself is undergoing tremendous change—how can we define AI Native? That's the logic I explained. But everyone, including PolarDB itself, is racing towards AI Native. That's the core logic. Question: For traditional setups, like using a search engine + traditional database, or traditional DB + vector DB + in-memory DB combination, what changes are needed to migrate to an Agentic architecture, and what benefits can be gained? Wang Yuan: The question of whether to rebuild from scratch for an AI-oriented data infrastructure is fundamental. My answer is: no. Embracing AI, especially for enterprises, should involve a philosophy of smooth migration and evolution, but the speed compared to traditional times must accelerate, not passively wait for gradual upgrades—though the process should still be smooth, just faster. Completely rebuilding from scratch isn't necessarily wrong, but it's a rather radical and risky choice. PolarDB is designed based on this premise: how to support users upgrading from traditional IDC or architectures to cloud-native, and further to an AI Ready data platform. PolarDB has a整套 design, which can be summarized in three points: 1. PolarDB itself is a cloud-native relational database—that's the foundation. Extending to the AI era, PolarDB is our entry point for hot data. Therefore, PolarDB will always maintain compatibility with PG and MySQL, ensuring full生态 compatibility so applications can migrate without changes. We also provide integrated migration solutions for平滑迁移. This ensures that when customers use PolarDB for data infrastructure or AI infrastructure upgrades, existing applications are not disrupted, ensuring smoother transitions. Prioritizing customer business continuity during capability upgrades is the most direct and acceptable approach. So第一步, PolarDB must solidly serve as the hot data entry point, reliably supporting all TP online services, and providing complete平滑升级 solutions. 2. PolarDB自身 adopts the lakebase architecture. Once hot data enters, it can activate the enterprise's warm and cold data. PolarDB provides solutions for smoothly ingesting warm and cold data into the lake. With traditional architectures (e.g., ES, MySQL, PG for online databases), data is often siloed. If a business data record changes, the corresponding file in your object storage or file system won't automatically update. PolarDB's lakebase architecture integrates and manages all cold/warm data unifiedly, ensuring metadata consistency and联动. Adding a business tag or modifying a record triggers corresponding updates in the file system or object storage (e.g., Parquet files), enabling real-time, consistent, unified updates of multimodal data. Ensuring data consistency, correctness, and real-time availability is the foundation for business innovation. This is the second layer: achieving联动 between cold, warm, and hot data based on consistency, correctness, and real-time performance. 3. We provide a series of supports to facilitate customer innovation, including managed Ray frameworks for faster data processing, managed Superbase frameworks for quicker enterprise application development, and integrations with MaaS, Defeng, Coder, etc. We are working on all conceivable development method choices. Some enterprises choose web coding, others prefer workflow approaches for smoother business process transitions, potentially introducing Agents at each workflow node for higher efficiency. As a data platform, PolarDB needs to support various AI transformation applications, and we will fully ensure compatibility and integration with the ecosystem. These are roughly the three layers: hot data entry point, multimodal data management and linkage, and AI ecosystem compatibility support. These are the three key points of PolarDB's transformation and upgrade offering. Question: In recent years, with the AI wave, the price普惠 curve for SMEs, especially on Alibaba's public cloud, has trended downward. On the other hand, hardware prices keep rising. How do model operatorization and AI Ready affect this historical curve? Also, how do they optimize or enhance Alibaba Cloud's past revenue models or business models? Li Feifei: As a cloud computing and AI platform company, our business is fundamentally about scale. Larger scale allows us to realize economies of scale, lower marginal costs, and pass on dividends to end customers, creating higher value. Over the past few years, we've consistently pursued普惠 price reductions for SMEs, primarily through two core aspects: 1. Technological innovation: We continuously implement pooling, multi-tenancy, and elasticity, achieving higher utilization efficiency than single-tenant setups, thus releasing price红利. This is the most crucial point. 2. Scale: Larger scale facilitates elastic scheduling. With small scale, there's little room for adjustment. Larger scale provides more flexibility for load balancing and elastic scheduling, releasing scale effects. These two points create a virtuous cycle, enabling us to continuously release dividends, allowing most enterprise customers to benefit. That's the logic behind the price curve. Now, facing a new cycle of memory/storage price increases, this cycle will be quite long. Previously, storage prices fell to rock bottom, manufacturers were reluctant to produce, they had capacity but restricted it, causing prices to rise. Eventually, someone would jump in to produce, and prices would drop. This time, the logic is different: capacity is genuinely insufficient, not artificially constrained. Demand is exploding, and even at full产能, it can't meet market demand. Therefore, this storage price increase cycle will be relatively long-term; that's the underlying logic. Rising storage costs drive up prices across the chain—general-purpose servers, AI compute, GPUs will likely also涨价, as GPUs contain HBM and DRAM, sharing the same underlying components. This涨价 cycle is long-lasting.但从历史角度看, eventually cycles normalize. When AI becomes a mature industry without daily rapid changes, it will return to cyclical patterns—that's the objective law of development. But currently, this cycle will be relatively long. That's my judgment. How do we create value for customers? In this era, cloud computing providers and AI platform companies can deliver greater value and create more customer value compared to self-purchasing and managing resources. The higher the costs, the greater the value of scale effects. Individual customers can hardly match the scale协同 effects and marginal cost reduction logic of large cloud/AI providers. Therefore, when underlying costs rise, the efficiency gains from platform-scale operations become increasingly valuable.