Data management method, storage controller, storage device, medium, and product

Abstract

Embodiments of the present application relate to a data management method, a storage controller, a storage device, a storage medium and a computer program product. The method comprises: when a preset condition is met, migrating at least part of cold data stored in a first storage area to a second storage area; when target data is written, dynamically selecting, according to a usage scenario type of the target data, whether to allocate the target data to the first storage area or the second storage area; maintaining a metadata mapping table to record a storage area and a physical address where each target data is currently located, and redirecting a read request of the target data according to the metadata mapping table. Embodiments of the present application actively migrate cold data, release high-performance storage space, avoid hot data from being mistakenly evicted, dynamically allocate storage media according to usage scenarios, improve resource utilization efficiency, metadata mapping and read redirection ensure data location transparency and migration consistency, effectively reduce inference delay, improve hot data hit rate and system throughput.

Description

Technical Field

[0001] This application relates to the field of storage technology, and in particular to a data management method, storage controller, storage device, storage medium, and computer program product. Background Technology

[0002] Existing flash memory devices can simultaneously divide a single-level memory cell (SLC) region and a three-level memory cell (MLC) region on the same chip, and manage them independently at the namespace level. The SLC region features high read / write bandwidth, low latency, and long erase / write lifespan, while the MLC region offers high capacity per unit area and low cost, but its bandwidth and latency are inferior to the SLC region. The host initiates read / write commands to different namespaces via the NVMe protocol.

[0003] In large language model inference scenarios, two types of core data are involved. The first type is model parameter weights, including attention layer weights and feedforward network layer weights, which are only loaded and used in calculations when a route is hit. The second type is key-value cache, which is a key-value tensor cached during inference to avoid repeatedly calculating the attention of historical tokens. Its size grows linearly with the dialogue length.

[0004] Existing data management solutions divide flash memory into fixed fast namespaces and shared namespaces during device manufacturing or initial configuration, with the partition ratio statically determined. When an application writes data, it selects the specified namespace based on the data priority tags marked in the configuration file. High-priority data is written to the fast namespace, and low-priority data is written to the shared namespace. When a namespace is full, an insufficient space error code is returned to the host, and the upper-layer application decides whether to delete the old data. Once data is written, it remains fixed in that namespace and does not migrate, nor does it reselect the medium after changes in hot / cold attributes.

[0005] For AI inference scenarios, the existing solution described above uniformly marks all expert weights as high priority and writes them into the fast namespace, uniformly marks all key-value caches as medium priority and writes them into the fast namespace, and then overflows into the shared namespace after the fast namespace is full. It does not distinguish whether the key-value cache is shared data or non-shared session private data. This will cause the fast namespace to run out of space due to carrying too much cold data, hot data to be evicted, and non-shared key-value cache to occupy the high-speed media bandwidth that should be used to serve shared prefix cache data, resulting in increased inference latency. Summary of the Invention

[0006] To address the aforementioned issues, embodiments of this application provide a data management method, a storage controller, a storage device, a storage medium, and a computer program product.

[0007] According to a first aspect of the embodiments of this application, a data management method is provided, applied to a storage controller, the storage controller being used to manage a storage device including a first storage area and a second storage area, wherein the unit capacity cost of the first storage area is higher than that of the second storage area and its read / write performance is better than that of the second storage area, the method comprising: When preset conditions are met, at least a portion of the cold data stored in the first storage area will be migrated to the second storage area; When writing target data, the target data is dynamically allocated to the first storage area or the second storage area according to the usage scenario type of the target data; Maintain a metadata mapping table to record the current storage area and physical address of each target data, and redirect read requests for the target data according to the metadata mapping table.

[0008] In one implementation, the preset conditions include one or more of the following: The available space in the first storage area is lower than a preset threshold. The coldness score of the data to be migrated is higher than the preset coldness score threshold; The number of times the data to be migrated is accessed within a preset time window is less than a preset access threshold. Received a migration notification from the AI ​​inference engine.

[0009] In one implementation, the target data includes expert weights in the large language model inference process, and the migration of at least a portion of the cold data stored in the first storage area to the second storage area includes: In the first storage area, one or more cold expert weights are selected in ascending order of access frequency. The cold expert weights are the expert weights whose access frequency is less than a preset access frequency threshold within a preset time window. The one or more cold expert weights are migrated to the second storage area, wherein the amount of data occupied by the one or more cold expert weights is determined based on the difference between the available space in the first storage area and the preset threshold.

[0010] In one implementation, the use case type includes shared and non-shared scenarios, and the dynamic selection of allocating the target data to the first storage area or the second storage area includes: If the target data belongs to a non-shared scenario, the target data will be directly allocated to the second storage area; If the target data belongs to a shared scenario, then query the available space of the first storage area; if the available space of the first storage area is sufficient, then allocate the target data to the first storage area; if the available space of the first storage area is insufficient, then downgrade the target data to the second storage area.

[0011] In one implementation, the shared scenario is a multi-session shared key-value cache prefix scenario, and the non-shared scenario includes any one of the following: historical dialogue recovery scenario, user session branch scenario, non-reusable portion scenario in a temporary long context window scenario, and any key-value cache segment scenario that is used only in a single session and is not reused.

[0012] In one implementation, the dynamic selection of allocating the target data to the first storage region or the second storage region includes: When multiple hot data from shared scenarios compete for space in the first storage area, the first storage area is allocated in descending order of the number of reuse sessions corresponding to the key-value cache prefix of each hot data. The more reuse sessions, the higher the priority. The hot data is target data whose access count within a preset time window is higher than a preset access count threshold. Once the available space in the first storage area is restored, the hot data of the shared scenario that has been downgraded and allocated to the second storage area will be upgraded and allocated to the first storage area.

[0013] In one embodiment, before migrating at least a portion of the cold data stored in the first storage area to the second storage area, the method further includes: Obtain the available space remaining in the second storage area; When the available space in the second storage area is insufficient to accommodate the data to be migrated, a rollback strategy is triggered. The rollback strategy includes: removing existing cold data from the second storage area according to the least recently used strategy in order to free up space for the data to be migrated.

[0014] In one implementation, the metadata mapping table includes one or more of the following information: Data type; The identifier of the physical storage area where the data is currently located; The physical address of the data within the current storage area; Data access counter and most recently accessed timestamp; Data migration status marker.

[0015] In one implementation, redirecting the read request for the target data according to the metadata mapping table includes: When a read request for the target data is received, the metadata mapping table is queried to determine the current storage area where the requested target data is located, and a read command is sent to the corresponding storage area. If the migration status of the target data corresponding to the metadata mapping table is marked as "migration in progress", then wait for the migration to complete or read from the old physical address to ensure data consistency.

[0016] In one implementation, the first storage area is a fast namespace and the second storage area is a shared namespace; or, the first storage area is a fast partition and the second storage area is a shared partition. The fast namespace or the fast partition operates in a single-level storage unit mode, while the shared namespace or the shared partition operates in a three-level storage unit mode, a four-level storage unit mode, or a media mode with a unit capacity higher than that of a single-level storage unit.

[0017] In one implementation, the target data includes at least one of model parameter data or key-value cache data during the AI ​​inference process, wherein the model parameter data includes expert weights in a hybrid expert model, and the key-value cache data includes attention tensors cached during the inference process of a large language model.

[0018] According to a second aspect of the embodiments of this application, a storage controller is provided, comprising: A memory on which computer programs are stored; A processor for executing the computer program in the memory to implement the steps of the method of any one of the first aspects.

[0019] According to a third aspect of the embodiments of this application, a storage device is provided, comprising: The first storage region has the best read / write performance and the best unit capacity cost; The second storage area has a second read / write performance that is lower than the first read / write performance and a unit capacity cost that is lower than the first unit capacity cost. A storage controller is configured to perform the method as described in any one of the first aspects to dynamically manage and migrate data between the first storage area and the second storage area.

[0020] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the method described in any one of the first aspects.

[0021] According to a fifth aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described in any one of the first aspects.

[0022] The embodiments of this application achieve the following beneficial effects: when preset conditions are met, at least a portion of the cold data stored in the first storage area is migrated to the second storage area; when writing target data, the target data is dynamically allocated to the first or second storage area according to the usage scenario type of the target data; a metadata mapping table is maintained to record the current storage area and physical address of each target data, and read requests for the target data are redirected according to the metadata mapping table. The embodiments of this application release high-performance storage space by actively migrating cold data, preventing hot data from being erroneously evicted; dynamically allocate storage media according to usage scenarios, ensuring that highly reused data receives high-speed resources and low-reuse data is stored in the capacity area, improving resource utilization efficiency; metadata mapping and read redirection ensure data location transparency and migration consistency, effectively reducing inference latency and improving hot data hit rate and system throughput.

[0023] Other features and advantages of this application will be described in detail in the following detailed description section. Attached Figure Description

[0024] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart of a data management method provided in an embodiment of this application.

[0025] Figure 2 This is a flowchart of a data management method provided in an embodiment of this application.

[0026] Figure 3 This is a flowchart of a data management method provided in an embodiment of this application.

[0027] Figure 4 This is a flowchart of a data management method provided in an embodiment of this application.

[0028] Figure 5 This is a flowchart of a data management method provided in an embodiment of this application.

[0029] Figure 6 This is a flowchart of a data management method provided in an embodiment of this application.

[0030] Figure 7 This is a block diagram of a storage device provided in one embodiment of this application.

[0031] Figure 8 This is a block diagram of a storage controller provided in one embodiment of this application. Detailed Implementation

[0032] The specific embodiments of this application will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit this application.

[0033] It should be understood that the term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description.

[0034] It should be noted that the concepts of "first" and "second" mentioned in this application are only used to distinguish different devices, modules, or units, and are not used to limit the order of functions performed by these devices, modules, or units or their interdependencies. The modifications of "one" and "multiple" mentioned in this application are illustrative rather than restrictive, and those skilled in the art should understand that, unless explicitly stated in the context, they should be understood as "one or more". In the description of this application, unless otherwise stated, "multiple" means two or more, and other quantifiers are similar; "at least one item", "one item or multiple items", or similar expressions refer to any combination of these items, including any combination of single or multiple items.

[0035] Although operations or steps are described in a specific order in the accompanying drawings in the embodiments of this application, this should not be construed as requiring these operations or steps to be performed in the specific order or serial order shown, or requiring all of the shown operations or steps to be performed to obtain the desired result. In the embodiments of this application, these operations or steps may be performed serially; they may be performed in parallel; or a portion of these operations or steps may be performed.

[0036] The names of the messages or information exchanged between multiple devices in the embodiments of this application are for illustrative purposes only and are not intended to limit the scope of these messages or information. It is understood that before using the technical solutions disclosed in the embodiments of this application, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this application in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained. The application will now be described in conjunction with specific embodiments.

[0037] Figure 1 This is a flowchart illustrating a data management method provided in an embodiment of this application. Figure 1As shown in the figure, this application provides a data management method applied to a storage controller. The storage controller manages a storage device comprising a first storage area and a second storage area. The first storage area has a higher unit capacity cost than the second storage area and better read / write performance. The method may include the following steps: In step S10, when a preset condition is met, at least a portion of the cold data stored in the first storage area is migrated to the second storage area.

[0038] In step S20, when writing target data, the target data is dynamically allocated to the first storage area or the second storage area according to the usage scenario type of the target data.

[0039] In step S30, a metadata mapping table is maintained to record the current storage area and physical address of each target data, and read requests for the target data are redirected according to the metadata mapping table.

[0040] For example, the data management method in the storage device provided in the embodiments of this application can be described as the following core steps that are executed in parallel or alternately.

[0041] First, the available space in the first storage area and the access frequency of the data stored therein can be continuously monitored. When a preset migration trigger condition is detected, such as the available space in the first storage area being lower than a preset threshold, or the access frequency of some data therein being lower than a set threshold, the cold data migration operation can be initiated.

[0042] Specifically, data objects that meet the definition of cold data can be identified from the first storage area, such as data that are accessed very infrequently within a preset time window. These data can be migrated from the first storage area, which has better read / write performance but higher unit cost, to the second storage area, which has lower unit cost but relatively inferior read / write performance, thereby freeing up valuable space in the first storage area.

[0043] At the same time, whenever new target data needs to be written, the system does not adopt a static allocation strategy, but dynamically evaluates the usage scenario type carried by the target data itself. Different usage scenarios have different requirements for access latency, reuse frequency and storage persistence. Based on this scenario classification information, the system can intelligently decide whether to allocate the target data to the first storage area or the second storage area, so that high-speed storage resources can be given priority to those scenarios with the most urgent performance requirements.

[0044] Furthermore, since data may be distributed across different physical storage areas due to migration or dynamic allocation, a metadata mapping table can be maintained. This table, indexed by logical identifiers, accurately records the current storage area identifier and physical address of each target data. When an upper-layer application initiates a read request, the system does not assume where the data is located. Instead, it first queries this metadata mapping table and, based on the redirection information recorded in the table, directs the read request to the correct storage area and retrieves the data.

[0045] This application embodiment uses a cold data migration mechanism triggered by preset conditions to actively move data with low access frequency out of the high-performance storage area, effectively avoiding the long-term retention of cold data and crowding out the high-speed cache space required by hot data, thereby reducing the risk of hot data being wrongly evicted due to insufficient space and improving the overall cache hit rate.

[0046] On the other hand, dynamic allocation based on usage scenario type during data writing ensures that the selection of storage media matches the actual data access pattern. For example, data in scenarios with high reusability and latency sensitivity can be preferentially allocated to high-performance areas, while data in one-off or low-reusability scenarios can be directly allocated to capacity areas, thereby achieving a balance between performance and cost of storage resources.

[0047] Meanwhile, the maintenance of the metadata mapping table and the read redirection mechanism shield the upper-layer software from the dynamic changes in the physical location of the underlying data, ensuring that the data can still be accessed correctly and efficiently after migration or allocation strategy adjustments, thus guaranteeing the transparency of the system and data consistency.

[0048] Optionally, the preset conditions may include one or more of the following: the available space in the first storage area is lower than a preset threshold; the coldness score of the data to be migrated is higher than a preset coldness score threshold; the number of accesses to the data to be migrated within a preset time window is lower than a preset access number threshold; and a migration prompt is received from the AI ​​inference engine.

[0049] For example, the embodiments of this application specify the preset conditions for triggering cold data migration. In actual operation, data migration operations can be flexibly initiated based on the actual occupancy of storage resources, changes in data access patterns (hot and cold), and even intelligent judgment by upper-layer applications.

[0050] Specifically, one or more independent trigger conditions can be configured, which can complement or be used in combination. The first condition focuses on storage space usage: when the available space in the first storage area drops below a pre-set safety threshold, it indicates that the space resources in the high-performance storage area are becoming strained. At this time, it can trigger the migration of some cold data to the second storage area to free up space and prevent the writing of new hot data from being affected by space exhaustion.

[0051] The second and third conditions are based on the data's own access characteristics. A "coldness score" can be maintained for each data object, which comprehensively reflects information from multiple dimensions such as access frequency, recent access time, and access interval. When the coldness score of a piece of data to be migrated is higher than a preset coldness score threshold, or when the number of accesses to that data within a preset time window is lower than a preset access frequency threshold, it indicates that the data's access activity has significantly decreased, meeting the definition of cold data, and it can be identified as an object to be migrated.

[0052] The fourth condition introduces migration prompts from the AI ​​inference engine. In the application scenarios such as large language model inference targeted by this application embodiment, the AI ​​inference engine itself has the deepest understanding of data access patterns. The inference engine can proactively predict that certain data may no longer be frequently accessed in the future based on information such as model structure, request load and session state, and thus issue migration prompts to the storage system to guide the system to adjust the data layout in advance.

[0053] This application's embodiments enhance the flexibility and adaptability of data migration strategies. It enables not only passive, reactive migration based on the underlying storage space status, but also proactive cold / hot data identification migration based on real-time data access characteristics. Furthermore, it can accept intelligent scheduling instructions from the upper-layer AI inference engine to achieve collaborative data layout optimization. This multi-condition triggering mechanism ensures that migration operations are executed at the most appropriate time, avoiding excessive system resource consumption due to overly frequent migrations, and preventing high-performance storage area space shortages or performance degradation due to untimely migrations. This maintains high storage resource utilization under different load modes.

[0054] Figure 2 This is a flowchart illustrating a data management method provided in an embodiment of this application. Figure 2 As shown, the target data includes expert weights in the large language model inference process. The step of migrating at least a portion of the cold data stored in the first storage area to the second storage area may include the following steps: In step S101, in the first storage area, one or more cold expert weights are selected in ascending order of access frequency. The cold expert weights are the expert weights whose access frequency within a preset time window is less than a preset access frequency threshold.

[0055] In step S102, the one or more cold expert weights are migrated to the second storage area, wherein the amount of data occupied by the one or more cold expert weights is determined based on the difference between the available space in the first storage area and the preset threshold.

[0056] For example, this application provides a refined cold data migration implementation method for expert weight data in a hybrid expert model architecture during large language model inference. In a hybrid expert model, the model contains multiple expert networks, and each expert weight is only calculated during the inference process when the routing module determines that it has been hit. Therefore, the actual access frequency of a large number of expert weights varies significantly at any given time. The migration process is as follows: First, all expert weight data stored in the first storage area can be statistically analyzed and sorted according to their access frequency within a preset time window. Based on this, expert weights with access frequencies below a preset access threshold can be marked as "cold expert weights." Then, one or more of these cold expert weights can be selected as the objects for this migration, arranged in ascending order of access frequency.

[0057] The amount of data to be migrated is not a fixed value, but is dynamically calculated based on the difference between the available space in the first storage area and a preset threshold. For example, if the preset threshold is 15% of the total capacity of the first storage area, and the current available space is only 8%, then the data volume corresponding to the 7% difference is the target space size to be migrated and released. Based on this, a list of cold expert weights arranged in ascending order of frequency can be selected sequentially, starting with the coldest expert, until the total data volume of the selected expert weights meets or exceeds the target release amount. Finally, these selected cold expert weights are migrated from the first storage area to the second storage area.

[0058] This application embodiment achieves precise and automated migration of cold expert weights through the above-described implementation methods. Compared to blindly migrating a fixed amount of data or simply migrating all cold data at once, this solution has significant advantages. First, selecting data in ascending order of access frequency ensures that each migration operation prioritizes the least frequently accessed expert weights, thereby maximizing space release benefits with minimal migration costs. Second, the amount of data to be migrated is dynamically determined based on the available space gap, avoiding situations where insufficient migration leads to rapid space depletion and frequent migration triggers, while excessive migration avoids unnecessary IO overhead and over-occupancy of the second storage area. This precise migration control allows the available space in the first storage area to be stably maintained near a preset threshold, providing reliable space guarantees for subsequent hot expert weights or high-priority data. Furthermore, because the migration operation is controlled within necessary limits, the lifespan of the storage medium is extended.

[0059] Figure 3 This is a flowchart illustrating a data management method provided in an embodiment of this application. The usage scenario types include shared scenarios and non-shared scenarios, such as... Figure 3 As shown, the dynamic selection of allocating the target data to the first storage area or the second storage area may include the following steps: In step S201a, if the target data belongs to a non-shared scenario, the target data is directly allocated to the second storage area.

[0060] In step S202a, if the target data belongs to a shared scenario, the available space of the first storage area is queried; if the available space of the first storage area is sufficient, the target data is allocated to the first storage area; if the available space of the first storage area is insufficient, the target data is downgraded and allocated to the second storage area.

[0061] For example, this application further refines the decision logic for dynamically selecting storage areas based on different usage scenario types during data writing. First, it can identify whether the target data's usage scenario belongs to a shared or non-shared scenario. This identification can be based on the scenario tag attached to the write request by the upper-layer application, or it can be determined automatically by the storage system based on information such as the data's logical address range and session identifier. When the target data is determined to belong to a non-shared scenario, it means that the data is used only by a single user, a single session, or a single request, and the probability of it being reused by other users or requests in the future is extremely low; its access frequency and performance sensitivity are usually low. Therefore, such data can be directly allocated to a second storage area with lower unit capacity cost, without occupying the high-speed storage resources of the first storage area.

[0062] Conversely, when the target data is determined to belong to a shared scenario, it means that the data can be reused by multiple users, multiple sessions, or multiple requests, such as conversation prefix data shared by multiple sessions. This type of data has a high access frequency and is sensitive to read latency, so it can be prioritized for allocation to the first storage area. However, before actual allocation, it is necessary to query the available space of the first storage area to assess whether it has the capacity to accommodate the data. If the query results show that the available space of the first storage area is sufficient, for example, higher than the preset allocation threshold, then the target data is allocated to the first storage area to obtain the best performance service. If the available space is insufficient, it indicates that the high-performance storage area is currently under resource pressure, and the target data in this shared scenario can be downgraded and allocated to the second storage area. Although the performance is slightly inferior to the first storage area, it can ensure the successful execution of write operations, and upgrades can be considered later when space becomes available.

[0063] This application embodiment achieves a reasonable allocation of storage resources between shared and non-shared data through the aforementioned dynamic selection mechanism. For non-shared data, it is directly written to the second storage area, avoiding the consumption of valuable high-speed storage bandwidth and capacity by low-reusability data. This allows the resources of the first storage area to be concentrated on serving shared data that truly requires high performance, thereby improving the overall resource utilization efficiency.

[0064] For shared data, prioritizing allocation to the first storage area ensures effective protection against access latency issues for highly reusable data. This is especially crucial in multi-session concurrent scenarios, where fast reading of the shared prefix significantly improves the first token latency and overall inference throughput for all relevant sessions. Furthermore, even when space is limited in the first storage area, shared data can be degraded to the second storage area instead of immediately returning a write failure. This demonstrates the system's fault tolerance and high availability, guaranteeing business continuity and preventing request interruptions due to temporary space fluctuations.

[0065] Optionally, the shared scenario can be a multi-session shared key-value cache prefix scenario, and the non-shared scenario can include any one of the following: historical dialogue recovery scenario, user session branch scenario, non-reusable part scenario in a temporary long context window scenario, and any key-value cache segment scenario that is used only in a single session and is not reused.

[0066] For example, embodiments of this application provide clear definitions and examples of shared and non-shared scenarios in conjunction with specific application scenarios of large language model inference. During operation, the system needs to classify the written key-value cache data according to these scenario definitions.

[0067] The shared scenario specifically refers to a scenario where multiple sessions share a key-value cache prefix. In the practical application of large language models, multiple user sessions may share the same dialogue prefix, such as key-value caches corresponding to system prompts, role settings, or common background knowledge. This data is repeatedly used by multiple sessions, and each time it is hit, redundant calculations can be avoided, thus saving a lot of computing power. Its access frequency is extremely high, and it belongs to hot data that requires priority in performance protection.

[0068] Non-shared scenarios encompass various key-value cache types that serve only a single session. The historical conversation recovery scenario refers to when a user reloads a previously saved session, requiring the reading of the key-value cache corresponding to that session's history. This data may not be accessed again in the short term after recovery. The user session branching scenario refers to a user branching out from a certain conversation node; the key-value cache in this branch belongs only to that branch session and is not reused in other branches. The non-reusable portion within a temporary long context window refers to key-value cache segments that, although present in the current context window, only serve the current request and have a long window duration, meaning most of the data will not be reused in the future. More generally, any key-value cache segment used only in a single session and not reused falls under the non-shared scenario.

[0069] This application's embodiments, by clearly defining the aforementioned scenario classifications, can guide the storage system to make more accurate allocation decisions. This scenario-based classification, compared to simply treating all key-value caches as homogeneous data, better reflects the actual access patterns of AI inference loads. For multi-session shared key-value cache prefixes, they can be preferentially allocated to the first storage area to maximize their reuse benefits and reduce the average inference latency across all shared sessions. For key-value caches in various non-shared scenarios, they can be directly allocated to the second storage area to avoid these one-off or low-reuse-rate data consuming high-speed storage resources, reducing unnecessary write amplification and media wear. This refined scenario differentiation aligns storage strategies with data usage semantics, thereby maximizing performance gains within limited high-speed storage capacity.

[0070] Figure 4 This is a flowchart illustrating a data management method provided in an embodiment of this application. Figure 4 As shown, the dynamic selection of allocating the target data to the first storage area or the second storage area may include the following steps: In step S201b, when multiple hot data from shared scenarios compete for space in the first storage area, the first storage area is allocated in descending order of the number of reuse sessions corresponding to the key-value cache prefix of each hot data. The more reuse sessions, the higher the priority. The hot data is target data whose access count within a preset time window is higher than a preset access count threshold.

[0071] In step S202b, after the available space in the first storage area is restored, the hot data of the shared scenario that has been downgraded to the second storage area is upgraded and allocated to the first storage area.

[0072] For example, this application provides a priority arbitration and dynamic upgrade mechanism for situations where multiple shared hot data compete for the first storage area space.

[0073] In actual operation, multiple shared key-value cache prefixes may compete for limited space in the first storage area. For example, within a certain time period, multiple different session prefixes may be frequently accessed by multiple sessions, and the capacity of the first storage area may not be sufficient to accommodate all this hot data. In this case, priority can be ranked according to the number of reused sessions for the key-value cache prefixes corresponding to each hot data.

[0074] The number of reused sessions refers to the number of valid sessions currently using the key-value cache prefix. A higher value indicates a higher frequency of concurrent access to the data, resulting in greater performance gains from storing it in the first storage area. Hot data requesting allocation to the first storage area can be sorted in descending order of reused session count, prioritizing allocation to hot data with a higher reused session count until all space is allocated. Hot data that fails to secure allocation in the first storage area is then downgraded to the second storage area as described above.

[0075] At the same time, the available space in the first storage area can be continuously monitored. When the available space recovers and exceeds the preset recovery threshold due to cold data migration, data eviction, or other reasons, an upgrade operation can be triggered to re-allocate the shared scenario hot data that was previously downgraded to the second storage area due to insufficient space to the first storage area.

[0076] This application's embodiments introduce the aforementioned competition arbitration and upgrade mechanism, making the space allocation of the first storage area more dynamic and refined. In competitive scenarios, allocation in descending order of reuse session count ensures that limited high-speed storage resources are always prioritized for data that currently generates the greatest reuse benefits, achieving optimal resource utilization. This dynamic priority strategy based on real-time reuse levels is more scientific and efficient than static priority labels or simple first-come, first-served methods. Simultaneously, the upgrade mechanism ensures that data allocation is not a one-time static decision but can be continuously optimized based on changes in storage space status. When space pressure eases, previously degraded hot data can automatically recover to the high-performance storage area without manual intervention, ensuring the system can quickly recover to the optimal data layout state after load fluctuations, thus maintaining stable service quality across different time periods.

[0077] Figure 5 This is a flowchart illustrating a data management method provided in an embodiment of this application. Figure 5 As shown, before migrating at least a portion of the cold data stored in the first storage area to the second storage area, the method may further include the following steps: In step S05, the available space balance of the second storage area is obtained.

[0078] In step S06, when the available space in the second storage area is insufficient to accommodate the data to be migrated, a rollback strategy is triggered. The rollback strategy includes: removing existing cold data from the second storage area according to the least recently used strategy in order to free up space for the data to be migrated.

[0079] For example, this application embodiment adds a pre-verification and exception handling mechanism for the target storage area capacity in the cold data migration process to ensure that the migration operation can be completed smoothly under various circumstances.

[0080] Before formally migrating cold data from the first storage area to the second storage area, the current available space in the second storage area can be obtained first. This acquisition action occurs before the data transfer phase of the migration operation and is considered a pre-condition check.

[0081] Subsequently, based on the total amount of data to be migrated, it can be determined whether the available space in the second storage area is sufficient to accommodate this data. If the available space in the second storage area is sufficient, the migration operation can proceed as normal, directly writing the cold data to the free physical address in the second storage area. However, if the available space in the second storage area is insufficient to accommodate the data to be migrated, it indicates that the capacity-type storage area itself, as the migration target, is also facing a space shortage.

[0082] At this point, the system does not halt the migration or return an error; instead, it triggers a pre-defined rollback strategy. The core operation of this rollback strategy is to evict data already stored in the second storage area according to a Least Recently Used (LRU) policy. The LRU policy prioritizes evicting data that has been accessed the least recently or has the longest remaining access time; this data can be considered "cold data" in the second storage area. By evictting this existing cold data, sufficient new space can be freed up in the second storage area to accommodate the data to be migrated from the first storage area.

[0083] This application significantly enhances the robustness and self-consistency of the data migration mechanism by introducing the aforementioned pre-verification and rollback strategies. In storage devices, both the first and second storage areas may face space pressure. If only the remaining space in the source first storage area is considered during migration while ignoring the space status of the target second storage area, migration may fail, thus blocking the entire space release process. This solution ensures the integrity of the cold data migration link by proactively checking and intelligently handling insufficient space in the second storage area before migration. Eliminating colder data in the second storage area using a least recently used strategy essentially further classifies cold data, ensuring that the least frequently used data is prioritized for elimination. This ensures that relatively more frequently used data is always retained within the limited capacity of the storage space, achieving a data gradient from the first to the second storage area and a tiered system of hot and cold data.

[0084] Optionally, the metadata mapping table may include one or more of the following information: data type; identifier of the physical storage area where the data is currently located; physical address within the storage area where the data is currently located; data access counter and recent access timestamp; data migration status flag.

[0085] For example, this application embodiment defines in detail the specific information fields contained in the metadata mapping table. As the core data structure of the entire dynamic data management and migration mechanism, the completeness of the metadata mapping table design directly affects the correct execution of various system functions.

[0086] During operation, this mapping table maintains a set of key metadata information for each managed data object. The data type field records the category of the data object, such as whether it is an expert weight, a shared key-value cache prefix, or a non-shared key-value cache. This information helps the system quickly understand the nature of the data in subsequent migration or allocation decisions.

[0087] The identifier field of the physical storage area where the data is currently located records whether the data is actually stored in the first storage area or the second storage area, which is the basis for read request redirection. The physical address field of the data's current storage area further refines the specific offset of the data in the corresponding storage area, used for actual read and write command addressing. The data access counter and recent access timestamp fields are used to track the access frequency of the data. Each time data is read or written, the counter and timestamp can be updated. These statistics are the quantitative basis for determining the data's hot / cold status and making migration decisions. The data migration status flag field is used to indicate whether the data is currently in the process of migration, and can include status values ​​such as idle, migrating, and completed. This flag is crucial for ensuring data consistency during the migration process. Read requests can use this flag to decide whether to read directly from the current location or wait for the migration to complete.

[0088] This application embodiment provides a comprehensive and accurate state view for data management by maintaining a metadata mapping table containing the aforementioned rich information items. Data type and access statistics provide data support for intelligent data layout decisions, enabling the system to determine hot and cold storage patterns and plan migrations based on real historical access patterns. Physical storage area identifiers and physical address information provide an addressing basis for transparent data access and dynamic relocation, allowing upper-layer applications to always access data through logical identifiers without being aware of underlying physical storage changes. Migration status markers provide crucial guarantees for data consistency, ensuring the correct processing of concurrent read requests during migration and avoiding the reading of incomplete or erroneous data. This comprehensive mapping table design is the core hub that enables the aforementioned dynamic allocation, migration triggering, and read redirection mechanisms to work together effectively.

[0089] Figure 6 This is a flowchart illustrating a data management method provided in an embodiment of this application. Figure 6 As shown, redirecting the read request for the target data based on the metadata mapping table may include the following steps: In step S301, when a read request for the target data is received, the metadata mapping table is queried to determine the storage area where the requested target data is currently located, and a read command is sent to the corresponding storage area.

[0090] In step S302, if the migration status of the target data corresponding to the metadata mapping table is marked as "migration in progress", then wait for the migration to complete or read from the old physical address to ensure data consistency.

[0091] For example, the embodiments of this application specifically illustrate the implementation process of read path redirection and the handling method to ensure data consistency during migration.

[0092] When an upper-layer application (such as an AI inference engine) initiates a read request for specific target data, the read request carries the data's logical identifier. Upon receiving the read request, the storage system first uses this logical identifier as an index to query the metadata mapping table. Through this table lookup, the system can obtain the identifier of the physical storage area where the target data is currently located, as well as its specific physical address within that storage area. Based on this information, the correct read command can be constructed and sent to the corresponding storage area (either the first or second storage area), thereby completing the data read and returning it to the upper-layer application.

[0093] In addition to the conventional redirection process described above, this application embodiment also specifically considers read consistency guarantees during data migration. When the system queries the metadata mapping table, besides obtaining location information, it can also check the migration status flag corresponding to the data. If the migration status flag indicates that the data is currently in a migration state, it means that the data is being copied from the source storage area to the target storage area, but has not yet been completed. At this time, two strategies can be adopted to ensure that the read data is consistent and complete.

[0094] The first strategy is to wait for the migration to complete, that is, to pause the current read request and wait for the migration operation to finish before reading the data from the new physical address updated in the metadata mapping table. The second strategy is to read from the old physical address, that is, during the migration process, the data still retains a complete copy at the old address in the source storage area, which can bypass the migration process and directly read the data from the old address and return it.

[0095] This application embodiment achieves completely transparent data access to upper-layer applications through the aforementioned read redirection mechanism. Regardless of how the physical storage location of data changes due to cold / hot migration, dynamic allocation, or upgrade / downgrade operations, upper-layer applications always access it through a unified logical address, without needing to be aware of any changes at the underlying level, greatly simplifying application layer design and maintenance. Simultaneously, through migration status marking and strategies of waiting for or reading from the old address, this solution strictly guarantees read consistency during data migration, avoiding data corruption or inconsistent intermediate states caused by concurrent conflicts between migration and read operations, thus ensuring system reliability and data integrity.

[0096] Optionally, the first storage area can be a fast namespace and the second storage area can be a shared namespace; or, the first storage area can be a fast partition and the second storage area can be a shared partition. The fast namespace or the fast partition can operate in a single-level storage unit mode, while the shared namespace or the shared partition can operate in a three-level storage unit mode, a four-level storage unit mode, or a media mode with a unit capacity higher than that of a single-level storage unit.

[0097] For example, the embodiments of this application provide a detailed description of the specific implementation forms of the first storage area and the second storage area and their underlying media types, and provide a variety of optional alternatives.

[0098] In one specific implementation, the first storage region and the second storage region can be implemented based on the namespace mechanism in the NVMe protocol. A fast namespace serves as the first storage region, and a shared namespace serves as the second storage region. Both are partitioned on the same flash memory chip but have independently configured media access policies.

[0099] In another equivalent implementation, if the storage controller uses partitions or logical units rather than namespaces as the management granularity, the first storage area can also be implemented as a fast partition, and the second storage area can be implemented as a shared partition, with the same functionality and management logic as the namespace-based implementation.

[0100] In terms of media type, fast namespaces or fast partitions can operate in a single-level storage unit mode. In this mode, each storage unit stores 1 bit of data, which features fast read and write speeds, low latency, and long erase and write lifespan, making it suitable for handling hot data with high performance requirements.

[0101] Shared namespaces or shared partitions can operate in either a three-tier or four-tier storage unit mode, or with any media mode whose unit capacity is higher than that of a single-tier storage unit. Three-tier storage units store 3 bits of data per unit, while four-tier storage units store 4 bits of data per unit. Their unit capacity cost is significantly lower than that of a single-tier storage unit, but their read / write performance and lifespan are relatively lower. They are suitable for handling cold data or high-volume data that is not performance-sensitive.

[0102] This application's embodiments, through the configuration of the aforementioned region structure and media type, can simultaneously achieve the dual advantages of high performance and low cost within the same storage device. Fast namespaces or partitions operate in a single-level storage unit mode, providing low-latency, high-throughput access channels for hot and high-priority data, ensuring critical performance indicators for inference tasks. Shared namespaces or partitions operate in three-tier, four-tier, or other high-density storage modes, providing large-capacity, low-cost storage space for cold and degraded data, effectively controlling overall storage costs. Using namespaces as the partitioning granularity conforms to the standard NVMe protocol specification, offering good compatibility and scalability; using partitions as the granularity provides greater implementation flexibility, suitable for different types of storage controller architectures.

[0103] Optionally, the target data may include at least one of model parameter data or key-value cache data during the AI ​​inference process. The model parameter data may include expert weights in a hybrid expert model, and the key-value cache data may include attention tensors cached during the inference process of a large language model.

[0104] For example, the embodiments of this application clarify the specific types of the managed target data in an AI inference scenario. During operation, the storage system can perform the aforementioned management operations such as dynamic allocation, cold / hot migration, and read redirection for the two most critical types of data in the AI ​​inference load—model parameter data and key-value cache data.

[0105] For model parameter data, especially in hybrid expert model architectures, the model contains a large number of expert weights. These expert weights are not all activated during inference; instead, a routing mechanism dynamically selects some experts to participate in the calculation. Therefore, the access frequency of different expert weights varies significantly over time. This application's embodiments can manage these expert weights as target data, dynamically migrating them between different storage areas based on their actual access frequency.

[0106] Key-value cache data is a crucial data structure cached during the inference process of large language models to accelerate decoding and avoid redundant calculations of attention tensors of historical tokens. The amount of key-value cache data grows rapidly with the increase of sequence length and concurrent sessions, placing high demands on storage capacity and bandwidth. Embodiments of this application can allocate key-value cache data, especially key-value caches that distinguish between shared prefixes and non-shared parts, to differentiated storage areas according to the aforementioned scenario classification strategy.

[0107] This application's embodiments effectively address the unique storage challenges of AI inference scenarios by specifically applying the aforementioned data management method to model parameters and key-value cache data. For expert weights in hybrid expert models, the dynamic migration mechanism ensures that frequently hit expert weights reside in high-performance storage areas, while cold expert weights are migrated to capacity-type storage areas, thereby maximizing the hit rate of expert weights within limited high-speed storage capacity.

[0108] For key-value cache data, differentiated allocation strategies based on shared and non-shared scenarios ensure optimal performance for key-value cache prefixes shared across multiple sessions, while preventing non-shared key-value caches from consuming valuable high-speed storage resources. This customized data management tailored to the characteristics of AI inference workloads directly brings advantages such as reduced inference latency, increased throughput, and optimized storage costs.

[0109] Figure 7 This is a block diagram of a storage device provided in one embodiment of this application. For example... Figure 7 As shown, this application embodiment provides a storage device that may include: The first storage region has the best read / write performance and the best unit capacity cost; The second storage area has a second read / write performance that is lower than the first read / write performance and a unit capacity cost that is lower than the first unit capacity cost. A storage controller is configured to perform the method as described in any of the above embodiments to dynamically manage and migrate data between the first storage area and the second storage area.

[0110] For example, this application also protects a storage device whose structure and functional configuration completely correspond to the foregoing method embodiments. This storage device includes at least two storage regions with different characteristics at either the physical or logical level.

[0111] The first storage area offers higher read / write performance, but its cost per unit capacity is also higher, making it suitable for storing frequently accessed data and data requiring high performance. The second storage area offers relatively lower read / write performance, but its cost per unit capacity is lower than the first storage area, making it suitable for storing cold data and large volumes of data. These two storage areas can coexist in the same storage device, such as different namespaces or partitions on the same flash memory chip, or they can be physically independent storage devices.

[0112] The device also includes a storage controller, which can be a firmware layer management module built into the storage device or a driver or management process running on the host. The controller is configured to execute the data management method described in any of the foregoing embodiments, and its functions can be divided into several collaborative sub-modules, such as space availability monitoring, media type decision-making, and data migration execution. The controller is responsible for continuously monitoring the space usage status of the two storage areas and dynamically managing and migrating data between the first and second storage areas based on preset conditions and real-time load.

[0113] This application embodiment provides a complete storage solution capable of autonomously executing intelligent data layout through the aforementioned system configuration. This storage device does not require manual configuration of data storage locations by upper-layer applications, nor does it rely on external scripts or tools for periodic data transfer. The intelligent management logic integrated within the controller enables the storage device to perceive changes in storage space availability and the evolution of data access patterns in real time, and automatically adjust the distribution of data between high- and low-performance storage areas accordingly. This autonomy and intelligence allow the system to maintain optimal data placement over long periods without human intervention, maximizing the effectiveness of high-performance storage media under given hardware conditions while fully utilizing low-cost storage media to meet capacity requirements, thereby achieving a dynamic balance between performance, cost, and power consumption.

[0114] Optionally, the storage device can be a storage device in an edge-side large model inference device, which may include general-purpose flash memory or solid-state drives. The edge-side large model inference device may include any one of an AI mobile phone, an AI computer, or an in-vehicle inference unit.

[0115] For example, the embodiments of this application further define a typical application scenario of the above-mentioned storage device, namely, an edge-side large model inference device.

[0116] In edge devices, large language models and their inference services run directly on local hardware rather than relying on cloud servers, which places special requirements on the device's storage subsystem. Edge devices, such as AI phones, AI computers, or in-vehicle inference units, are typically sensitive to cost and power consumption, and their storage capacity is limited compared to cloud servers, while simultaneously needing to meet users' demands for low latency and high privacy and security. In these devices, storage devices can be implemented as mainstream storage components such as general-purpose flash memory or solid-state drives. Due to the limitations of physical space and cost budgets in edge devices, it is impossible to configure high-performance, high-cost, large-capacity, high-speed storage media without restriction; therefore, adopting a hybrid media storage architecture becomes an inevitable choice. By implementing the aforementioned data management method in the storage device described in the embodiments of this application, edge devices can significantly improve the performance of large model inference with limited hardware resources.

[0117] This application embodiment, by applying the aforementioned storage device to an edge-side large-model inference device, fully leverages the advantages of hybrid media in resource-constrained edge environments. For AI smartphones or AI computers, users experiencing large language model applications can enjoy faster response times and smoother multi-turn dialogue interactions. Especially in scenarios involving multiple session switching or long text processing, intelligent key-value caching management and expert weight scheduling can significantly reduce first-token latency. For in-vehicle inference units, in scenarios with high real-time requirements such as voice assistants and navigation interactions in smart cockpits, the performance assurance of storage devices directly impacts user experience and driving safety.

[0118] The storage device provided in this application embodiment enables edge devices to efficiently carry large model inference loads without increasing hardware costs, thus promoting the edge deployment and popularization of AI technology.

[0119] Figure 8 This is a block diagram of a storage controller provided in one embodiment of this application. Figure 8 As shown, the storage controller 800 may include a processor 801 and a memory 802. The storage controller 800 may also include one or more of a multimedia component 803, an input / output (I / O) interface 804, and a communication component 805.

[0120] The processor 801 controls the overall operation of the storage controller 800 to complete all or part of the steps in the data management method described above. The memory 802 stores various types of data to support the operation of the storage controller 800. This data may include, for example, instructions for any application or method operating on the storage controller 800, and application-related data such as contact data, sent and received messages, pictures, audio, video, etc. The memory 802 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The multimedia component 803 may include a screen and audio components. The screen may be, for example, a touchscreen, and the audio component is used for outputting and / or inputting audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in memory 802 or transmitted via communication component 805. The audio component also includes at least one speaker for outputting audio signals. I / O interface 804 provides an interface between processor 801 and other interface modules, such as a keyboard, mouse, buttons, etc. These buttons may be virtual or physical buttons. Communication component 805 is used for wired or wireless communication between the storage controller 800 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, 4G, NB-IoT, eMTC, or other 5G technologies, or combinations thereof, is not limited here. Therefore, the corresponding communication component 805 may include: a Wi-Fi module, a Bluetooth module, an NFC module, etc.

[0121] In an exemplary embodiment, the storage controller 800 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the data management method described above.

[0122] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided, which, when executed by a processor, implement the steps of the data management method described above. For example, the computer-readable storage medium may be the memory 802 including the program instructions described above, which may be executed by the processor 801 of the storage controller 800 to complete the data management method described above.

[0123] In another exemplary embodiment, a computer program product is also provided, the computer program product comprising a computer program executable by a programmable device, the computer program having a code portion for performing the data management method described above when executed by the programmable device.

[0124] The preferred embodiments of this application have been described in detail above with reference to the accompanying drawings. However, this application is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this application, various simple modifications can be made to the technical solution of this application, and these simple modifications all fall within the protection scope of this application.

[0125] It should also be noted that the various specific technical features described in the above embodiments can be combined in any suitable manner without contradiction. In order to avoid unnecessary repetition, this application will not describe the various possible combinations separately.

[0126] Furthermore, various different implementations of this application can be combined in any way, as long as they do not violate the spirit of this application, they should also be regarded as the content disclosed in this application.

Claims

1. A data management method, characterized in that, An application to a storage controller for managing a storage device comprising a first storage region and a second storage region, wherein the first storage region has a higher unit capacity cost and better read / write performance than the second storage region, the method comprising: When writing target data, the target data is dynamically allocated to the first storage area or the second storage area according to the usage scenario type of the target data. The usage scenario type includes shared scenario and non-shared scenario. The shared scenario is a multi-session shared key-value cache prefix scenario, and the non-shared scenario is a key-value cache segment scenario that is used only by a single session and is not reused. The dynamic selection of the target data to be allocated to the first storage area or the second storage area includes: if the target data belongs to a non-shared scenario, then the target data is directly allocated to the second storage area; if the target data belongs to a shared scenario, then the available space in the first storage area is queried; if the available space in the first storage area is sufficient, then the target data is allocated to the first storage area; if the available space in the first storage area is insufficient, then the target data is downgraded and allocated to the second storage area. When multiple hot data from shared scenarios compete for space in the first storage area, the first storage area is allocated in descending order of the number of reuse sessions corresponding to the key-value cache prefix of each hot data. The more reuse sessions, the higher the priority. The hot data is target data whose access count within a preset time window exceeds a preset access count threshold. When the available space in the first storage area is restored, the hot data from shared scenarios that have been downgraded to the second storage area are upgraded and allocated to the first storage area. When preset conditions are met, at least a portion of the cold data stored in the first storage area will be migrated to the second storage area; Maintain a metadata mapping table to record the current storage area and physical address of each target data, and redirect read requests for the target data according to the metadata mapping table.

2. The method according to claim 1, characterized in that, The preset conditions include one or more of the following: The available space in the first storage area is lower than a preset threshold. The coldness score of the data to be migrated is higher than the preset coldness score threshold; The number of times the data to be migrated is accessed within a preset time window is less than a preset access threshold. Received a migration notification from the AI ​​inference engine.

3. The method according to claim 2, characterized in that, The target data includes expert weights in the large language model inference process, and the migration of at least a portion of the cold data stored in the first storage area to the second storage area includes: In the first storage area, one or more cold expert weights are selected in ascending order of access frequency. The cold expert weights are the expert weights whose access frequency is less than a preset access frequency threshold within a preset time window. The one or more cold expert weights are migrated to the second storage area, wherein the amount of data occupied by the one or more cold expert weights is determined based on the difference between the available space in the first storage area and the preset threshold.

4. The method according to claim 1, characterized in that, The non-shared scenarios include any one of the following: historical dialogue recovery scenario, user session branch scenario, non-reusable portion of temporary long context window scenario, and any key-value cache segment scenario that is used only in a single session and is not reused.

5. The method according to claim 1, characterized in that, Before migrating at least a portion of the cold data stored in the first storage area to the second storage area, the method further includes: Obtain the available space remaining in the second storage area; When the available space in the second storage area is insufficient to accommodate the data to be migrated, a rollback strategy is triggered. The rollback strategy includes: removing existing cold data from the second storage area according to the least recently used strategy in order to free up space for the data to be migrated.

6. The method according to claim 1, characterized in that, The metadata mapping table includes one or more of the following information: Data type; The identifier of the physical storage area where the data is currently located; The physical address of the data within the current storage area; Data access counter and most recently accessed timestamp; Data migration status marker.

7. The method according to claim 1, characterized in that, The step of redirecting the read request for the target data according to the metadata mapping table includes: When a read request for the target data is received, the metadata mapping table is queried to determine the current storage area where the requested target data is located, and a read command is sent to the corresponding storage area. If the migration status of the target data corresponding to the metadata mapping table is marked as "migration in progress", then wait for the migration to complete or read from the old physical address to ensure data consistency.

8. The method according to any one of claims 1-7, characterized in that, The first storage area is a fast namespace, and the second storage area is a shared namespace; or, the first storage area is a fast partition, and the second storage area is a shared partition. The fast namespace or the fast partition operates in a single-level storage unit mode, while the shared namespace or the shared partition operates in a three-level storage unit mode, a four-level storage unit mode, or a media mode with a unit capacity higher than that of a single-level storage unit.

9. The method according to any one of claims 1-7, characterized in that, The target data includes at least one of model parameter data or key-value cache data during the AI ​​inference process. The model parameter data includes expert weights in a hybrid expert model, and the key-value cache data includes attention tensors cached during the inference process of a large language model.

10. A storage controller, characterized in that, include: A memory on which computer programs are stored; A processor for executing the computer program in the memory to implement the steps of the method according to any one of claims 1-9.

11. A storage device, characterized in that, include: The first storage region has the best read / write performance and the best unit capacity cost; The second storage area has a second read / write performance that is lower than the first read / write performance and a unit capacity cost that is lower than the first unit capacity cost. A storage controller is configured to perform the method as described in any one of claims 1-9 to dynamically manage and migrate data between the first storage region and the second storage region.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the steps of the method described in any one of claims 1-9.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-9.

Images