A dynamic data access method based on MCP driving

Abstract

The application provides a dynamic data access method based on MCP driving. In the method, a first CMU receives a context data access request sent by a target MC when the target MC acquires a target processing request, and in response to the context data access request, acquires static context data and dynamic context data corresponding to the target processing request, and then sends the static context data and the dynamic context data corresponding to the target processing request to the target MC, so that only the static and dynamic context data required by the target processing request is acquired in the data access stage, and then repeated encoding and analysis of full context objects are avoided, and the calculation efficiency of the data access process is improved.

Description

Technical Field

[0001] This application relates to data processing technology, and more particularly to a dynamic data access method based on MCP driving. Background Technology

[0002] In dynamic collaborative processing scenarios of artificial intelligence models, multiple model components (MCs) need to communicate through the Model Context Protocol (MCP) to share the context data required for processing tasks.

[0003] In existing technologies, MCP-driven data transmission typically relies on serialization and deserialization mechanisms, which encode the memory structure of the context object into transmittable byte data (such as JSON, Protobuf, or MessagePack), transmit it through a network or message channel, and then parse it back into the original object structure at the receiving end.

[0004] However, when the context data structure is complex, involves multiple nesting or inter-object references, and is updated frequently, performing recursive traversal and field-by-field encoding on the complete context object in each transmission, and then reconstructing the entire object structure at the receiving end, will result in significant CPU and memory consumption. Summary of the Invention

[0005] This application provides a dynamic data access method based on MCP driving, which can obtain only the static and dynamic context data required by the target processing request during the data access phase, thereby improving the computational efficiency of the data access process.

[0006] In a first aspect, this application provides a dynamic data access method based on MCP (Model Context Protocol), applied to a dynamic data access system including multiple Model Components (MCs) and multiple Context Management Units (CMUs). The MCs and CMUs communicate via the Model Context Protocol (MCP), and the multiple CMUs are used to store static and dynamic context data required by the MCs when processing tasks. The method includes:

[0007] The first CMU receives a context data access request sent by the target MC when it obtains a target processing request. The plurality of CMUs includes the first CMU, and the plurality of MCs includes the target MC.

[0008] The first CMU responds to the context data access request and obtains the static context data and dynamic context data corresponding to the target processing request;

[0009] The first CMU sends the static context data and dynamic context data corresponding to the target processing request to the target MC.

[0010] Optionally, a portion of the CMU may be used to store static context data required for MC processing tasks, or a portion of the CMU may be used to store dynamic context data required for MC processing tasks, or a portion of the CMU may be used to store both static and dynamic context data required for MC processing tasks.

[0011] Optionally, the static context data includes one or more of the model configuration parameter data and access policy data used in the processing process corresponding to the target processing request; the dynamic context data includes one or more of the session state information, intermediate results of model inference, and runtime environment parameters.

[0012] Optionally, obtaining the static context data and dynamic context data corresponding to the target processing request includes:

[0013] The static and dynamic context data corresponding to the target processing request are obtained using incremental binary serialization.

[0014] Optionally, the plurality of CMUs further includes a second CMU, wherein the deployment locations of the first CMU and the second CMU are different; correspondingly, the first CMU responds to the context data access request and obtains the static context data and dynamic context data corresponding to the target processing request, including:

[0015] The first CMU acquires the dynamic context data corresponding to the stored target processing request;

[0016] If the first CMU does not store the static context data corresponding to the target processing request, the first CMU sends the static context data access request corresponding to the target processing request to the second CMU according to the access address of the second CMU;

[0017] The first CMU receives the static context data corresponding to the target processing request sent by the second CMU in response to the static context data access request.

[0018] Optionally, the dynamic data access system further includes a context routing control unit (CRC); correspondingly, before the first CMU responds to the context data access request and obtains the static context data and dynamic context data corresponding to the target processing request, it further includes:

[0019] The first CMU receives a first notification message sent by the CRC when it determines that the first CMU stores the dynamic context data corresponding to the target processing request but does not store the static context data. The first notification message carries the access address of the second CMU.

[0020] The first CMU sends a static context data access request to the second CMU based on the access address, and calls the binary serialization decoder to receive the static context data in a zero-copy manner.

[0021] Optionally, the first CMU sends static context data and dynamic context data corresponding to the target processing request to the target MC, including:

[0022] The first CMU sends the static context data and dynamic context data corresponding to the target processing request to the target MC through a zero-copy transmission mechanism.

[0023] Secondly, this application provides a dynamic data access system, including: multiple model components (MCs) and multiple context management units (CMUs), wherein the MCs and the CMUs communicate through a model context protocol (MCP), and the multiple CMUs are used to store static context data and dynamic context data required by the MCs when processing tasks;

[0024] The first CMU receives a context data access request sent by the target MC when it obtains a target processing request. The plurality of CMUs includes the first CMU, and the plurality of MCs includes the target MC.

[0025] The first CMU responds to the context data access request and obtains the static context data and dynamic context data corresponding to the target processing request;

[0026] The first CMU sends the static context data and dynamic context data corresponding to the target processing request to the target MC.

[0027] Thirdly, this application provides an electronic device, comprising:

[0028] Processor; and,

[0029] Memory for storing the executable instructions of the processor;

[0030] The processor is configured to perform any of the possible methods described in the first aspect by executing the executable instructions.

[0031] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement any of the possible methods described in the first aspect.

[0032] In the dynamic data access method based on MCP driving provided in this application, the first CMU receives the context data access request sent by the target MC when it obtains the target processing request, and responds to the context data access request to obtain the static context data and dynamic context data corresponding to the target processing request. Then, it sends the static context data and dynamic context data corresponding to the target processing request to the target MC. This enables the acquisition of only the static and dynamic context data required by the target processing request during the data access phase, thereby avoiding repeated encoding and parsing of the full context object and improving the computational efficiency of the data access process. Attached Figure Description

[0033] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0034] Figure 1 This is a flowchart illustrating a dynamic data access method based on MCP driver according to an example embodiment of this application;

[0035] Figure 2 This is a flowchart illustrating a dynamic data access method based on MCP driver according to another example embodiment of this application;

[0036] Figure 3 This is a schematic diagram of the structure of a dynamic data access system according to an example embodiment of this application;

[0037] Figure 4 This is a schematic diagram of the structure of an electronic device according to an example embodiment of this application.

[0038] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0039] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0040] Figure 1 This is a flowchart illustrating a dynamic data access method based on MCP driver according to an example embodiment of this application. Figure 1 As shown, the method provided in this embodiment includes:

[0041] S110, the first CMU receives the context data access request sent by the target MC when it obtains the target processing request.

[0042] In this embodiment, the method is applied to a dynamic data access system comprising multiple Model Components (MCs) and multiple Context Management Units (CMUs). The MCs and CMUs communicate via the Model Context Protocol (MCP). Multiple CMUs are used to store static and dynamic context data required by the MCs when processing tasks. Specifically, some CMUs may be used to store static context data required by the MCs when processing tasks, some may be used to store dynamic context data required by the MCs when processing tasks, or some may be used to store both static and dynamic context data required by the MCs when processing tasks.

[0043] When the target MC receives a target processing request, in order to execute the processing task, the target MC constructs a context data access request message according to the MCP communication rules and sends it to the first CMU through the MCP communication channel. This context data access request includes at least the following:

[0044] A request identifier (Request ID) is used to uniquely identify the target request for processing.

[0045] Target MC identification information;

[0046] Request data type description (e.g., need to obtain static context data, dynamic context data, or both);

[0047] Optional version number information or context data area index information, used to indicate data version or partition range.

[0048] Then, after receiving the access request message, the first CMU first parses its content and determines the target processing request identifier, and then enters the data retrieval process accordingly.

[0049] S120, the first CMU responds to the context data access request and obtains the static context data and dynamic context data corresponding to the target processing request.

[0050] In this step, the first CMU maintains a local context data storage module, which can store both static and dynamic context data, or store only one type of data.

[0051] Upon receiving an access request, the first CMU first retrieves the context data object corresponding to the request identifier from the local storage module. This static context data retrieval includes, but is not limited to: model configuration parameter data (e.g., network structure configuration, inference parameters) and access policy data (e.g., security policies, access control rules). Furthermore, the first CMU can match relevant object entries in the static data storage area based on the request information and read the corresponding data. The dynamic context data retrieval includes, but is not limited to: session state information (e.g., user session ID, context window content), intermediate model inference results (e.g., cached incomplete inference steps), and runtime environment parameters (e.g., CPU / GPU resource utilization, network latency parameters). The first CMU can match and read relevant object entries in the dynamic data storage area based on the request information.

[0052] In addition, during the data retrieval process, if the locally stored data is the latest version, the first CMU reads it directly; if there are differences in data versions, an incremental binary serializer can be called to encode the changed parts to improve transmission efficiency.

[0053] In one specific implementation, incremental binary serialization can be used to obtain the static and dynamic context data corresponding to the target processing request. The incremental binary serialization method includes:

[0054] Monitor the version number and change history of context data objects;

[0055] Based on the change log, only the parts that have changed since the last transmission are binary encoded;

[0056] In binary encoding, a combination of fixed-length and variable-length fields is used to reduce parsing overhead.

[0057] It is worth noting that in the process of monitoring context data objects, in order to maintain the consistency of context data across nodes within the system, existing technologies typically rely on periodic polling to detect changes in object state or on full data comparison to determine updates. However, this approach has two significant drawbacks: first, in high-frequency data update scenarios, the polling or comparison process consumes a large amount of CPU and memory resources and has high latency; second, due to the lack of a precise change location mechanism, the system struggles to obtain real-time information on the update content and timing of specific fields, easily leading to inaccurate context version management and thus affecting the efficiency of task synchronization and collaboration under the MCP protocol.

[0058] Therefore, in the dynamic data access process driven by MCP, how to achieve accurate real-time monitoring of writing or modifying fields of context data objects, and accurately record field change events and corresponding version numbers without significantly increasing system resource overhead, so as to improve the real-time performance and accuracy of context data version management and ensure data consistency and synchronization efficiency between multiple MCs and multiple CMUs, has become a technical problem that needs to be further solved.

[0059] To address this, the specific implementation of monitoring the version number and change records of the aforementioned context data object can be configured to capture change events in real time using an event-driven mechanism when a field of the context data object is written to or modified, and record the change events to a change event queue. Specifically, the event-driven mechanism intercepts field updates based on object property delegation or operator overloading, and synchronously updates the version number of the context data object.

[0060] The above steps employ an event-driven mechanism to capture change events in real time when write or modification operations occur on fields of the context data object, and record these events in a change event queue. This event-driven mechanism intercepts field update operations based on object property delegation or operator overloading, and synchronously updates the version number of the context data object. This ensures that change events are captured and recorded as field updates occur, avoiding the delays of periodic polling and enabling instant updates for context version management. Furthermore, it eliminates the need for full data comparison; only the fields triggering changes are recorded and their version numbers modified, significantly reducing CPU computation and memory usage.

[0061] Furthermore, in the steps described above, change events of the context data object need to be recorded in the event queue so that the encoder can read, encode, and transmit the events. However, if a single buffer queue is used to simultaneously implement encoder reading and change event writing, lock contention can easily occur in high-frequency data update scenarios. That is, the encoder reading process and the event writing process compete for queue access control. Lock contention not only leads to event recording delays and reduced encoding efficiency, but may also cause queue blocking, resulting in delayed writing or loss of some change events. This affects the real-time performance and integrity of the context version, and reduces the data synchronization performance of the entire MCP system under multi-model component collaboration.

[0062] To address this, the change event queue can be configured as a double-buffered structure, specifically including a first buffer queue for encoder reading and a second buffer queue for receiving and recording change events. The first and second buffer queues are switched at the end of the detection cycle to avoid lock contention between the encoder reading process and the change event writing process.

[0063] In the above steps, by designing the change event queue as a double-buffered structure, including a first buffer queue for encoder reading and a second buffer queue for receiving and recording change events, and then performing a buffer switch at the end of the detection cycle, it is possible to realize that read and write operations are performed on two independent buffer queues respectively, thereby avoiding competition for the same queue resources under high concurrency by physically isolating access paths.

[0064] Furthermore, when the encoder performs read operations on the first buffer queue, it will not be blocked by the write process, enabling it to continuously read and encode all events, thereby reducing encoding latency. Write operations, on the other hand, are performed only on the second buffer queue, ensuring that all captured change events are recorded to the available queue without delay, and that the writing of new events is not affected even if the read process is time-consuming.

[0065] Finally, at the end of the detection cycle, the system performs a buffer switch to ensure that there is no data loss during the role switching process between the read queue and the write queue, thus achieving continuous real-time version recording and encoding.

[0066] Furthermore, it's worth noting that when performing context data transmission, the encoder typically needs to perform full binary encoding of the entire context data object corresponding to the target processing request, even if some data areas remain unchanged. This full encoding method, especially when the context data structure is complex and includes multiple independent information areas such as session state, inference intermediate results, and runtime environment parameters, wastes serialization computation resources and frequently triggers cache invalidation in high-update-frequency scenarios, leading to a decrease in encoding performance.

[0067] Although the amount of encoding can be reduced through difference detection, in scenarios where multiple data types and different update characteristics coexist, the lack of fine-grained cache management and independent version tracking mechanisms for different context data regions makes it difficult to locate the update region in a timely and accurate manner and quickly generate the corresponding encoding results, thus limiting the context transmission efficiency of MCP in high-concurrency and high-update-frequency scenarios.

[0068] In response, before binary encoding can be performed only on the parts that have changed since the last transmission based on the change record, the context data object corresponding to the target processing request can be divided into multiple independent context data areas according to the data type and update characteristics. The context data areas include one or more of the following: session state area, inference intermediate result area, and runtime environment parameter area.

[0069] Then, independent difference cache units are maintained for multiple context data regions. Each difference cache unit includes a region version number field and a region hash check value field, which are used to quickly detect the region update status by the difference in region version number or hash check value when each context data region is updated.

[0070] Finally, when an update is detected in any context data region, binary encoding is performed only on the fields in the difference cache unit corresponding to the updated region, while the difference cache units of other unupdated context data regions remain unchanged.

[0071] Specifically, for context data regions whose update frequency exceeds a preset frequency, binary encoding template data corresponding to the region is pre-generated and stored so that when the region is updated, the binary encoding template data can be called to directly generate the target binary encoding result, thereby reducing the performance degradation of binary serialization caused by serialization cache failure in high update frequency scenarios.

[0072] By dividing the context data object corresponding to the target processing request into multiple independent context data regions (including one or more of the session state region, inference intermediate result region, and runtime environment parameter region) according to data type and update characteristics, and maintaining an independent difference cache unit for each region, the specific region in the context data object that has been updated can be quickly determined based on the difference in region version number or hash check value, avoiding redundant encoding operations on the unupdated region.

[0073] Furthermore, upon detecting an update event, only the difference cache unit field corresponding to the changed region is binary encoded, while the difference cache units for other regions remain unchanged, effectively reducing encoding time and CPU usage. In addition, for context data regions with update frequencies exceeding a preset value, binary encoding template data can be pre-generated and stored, allowing the target encoding result to be directly generated when an update event occurs, avoiding performance degradation caused by repeatedly constructing the encoding structure and frequent cache invalidation.

[0074] It is also worth noting that in the specific implementation methods described above, when using incremental binary serialization to obtain the static and dynamic context data corresponding to the target processing, the context data is usually composed of both static and dynamic context data, which contains a large number of objects with mutual references and nested structures.

[0075] Existing binary serialization methods lack a systematic global analysis of object reference relationships. The serialization process often employs full traversal encoding, meaning that even if only some child objects change, the parent object and all referenced objects will be fully encoded, increasing the amount of serialized data and processing time. Furthermore, circular references are common in complex reference structures. Without detection and skipping mechanisms, recursive traversal may fall into an infinite loop, causing system blocking or crashes. Simultaneously, repeatedly referenced objects may be encoded multiple times within the same serialization cycle, leading to encoding redundancy and inaccurate deserialization recovery.

[0076] To address this, a reference relationship analysis can be performed on the object structures of static and dynamic context data to construct a corresponding object reference graph. Each node in the graph corresponds to a context data object, and its globally unique identifier, parent object information, and reference count are recorded. Then, during incremental binary serialization, a depth-first traversal of the object reference graph is used for change detection. When a change is detected in a child object of a node, the corresponding change marker is propagated to its parent node and up-level nodes to ensure that nested parent nodes are correctly identified as the changed object.

[0077] During traversal, circular references are detected, and recursive processing of already visited nodes is skipped to prevent infinite recursion during serialization. When performing binary encoding, if the globally unique identifier of a context data object node has already been encoded within the current serialization cycle, the object content is not re-encoded. Instead, a reference marker carrying the globally unique identifier is generated to restore shared reference relationships during deserialization. When the object reference structure changes, the object reference graph is regenerated, and the incremental binary serialization index table is updated synchronously to ensure consistency with the latest object structure.

[0078] This approach analyzes the reference relationships of objects in both static and dynamic context data before incremental binary serialization, constructing an object reference graph to uniformly manage metadata such as the globally unique identifier, parent object references, and reference counts for each context data object. Furthermore, a depth-first traversal of the object reference graph is used for change detection. When a child object changes, the change marker is propagated to its parent and up-level nodes, ensuring that all nested parent object changes are accurately captured, thus achieving precise incremental encoding.

[0079] Furthermore, detecting circular references during traversal and skipping recursive processing when encountering already visited nodes can prevent serialization blocking or system exceptions caused by infinite recursion, thereby improving the stability of the serialization process. Then, within the same serialization cycle, for already encoded context data objects, a reference tag is generated carrying its globally unique identifier, thereby avoiding redundant encoding, reducing the amount of encoded data, and ensuring the consistency of the reference structure during deserialization recovery.

[0080] S130, the first CMU sends the static context data and dynamic context data corresponding to the target processing request to the target MC.

[0081] After successfully acquiring the static and dynamic context data corresponding to the target processing request, the first CMU encapsulates this data into a context data response message conforming to the MCP protocol and sends it to the target MC through the appropriate transmission mechanism. Specifically, the static and dynamic context data can be binary encoded according to the field structure specified by the MCP protocol. A data version number, data type marker, and verification information are appended to the encoded data for correct parsing and version matching by the target MC at the receiving end. Then, data transmission is performed through the MCP channel. If the sending and receiving ends are located on the same computing node, a shared memory mapping method can be directly used; if they are located on different computing nodes, a network transmission protocol supporting DMA is used to directly write the encoded data into the receiving end buffer, avoiding redundant memory copying.

[0082] After receiving the data response message, the target MC performs deserialization according to the decoding process of the MCP protocol, restores the binary context data into a directly usable structured object, and loads it into the processing task context for subsequent task execution.

[0083] In this embodiment, the first CMU receives the context data access request sent by the target MC when it obtains the target processing request, and responds to the context data access request to obtain the static context data and dynamic context data corresponding to the target processing request. Then, it sends the static context data and dynamic context data corresponding to the target processing request to the target MC. This enables the acquisition of only the static and dynamic context data required by the target processing request during the data access phase, thereby avoiding repeated encoding and parsing of the full context object and improving the computational efficiency of the data access process.

[0084] Specifically, in the above embodiment, the CMU only extracts the static and dynamic data corresponding to the target processing request from storage or cache, without accessing other context objects not within the scope of the requirement. Since unaccessed context data is not loaded, traversed, encoded, or transmitted, the system avoids computational operations on irrelevant data during serialization, deserialization, and data structure traversal. Then, the CMU encapsulates the necessary static and dynamic context data and sends it to the target MC. The returned data volume directly matches the current task requirements, and redundant data packets are avoided during network transmission, significantly reducing communication latency and bandwidth usage.

[0085] Figure 2 This is a flowchart illustrating a dynamic data access method based on MCP driving according to another example embodiment of this application. Figure 2 As shown, the dynamic data access method based on MCP driver provided in this embodiment includes:

[0086] S210, the first CMU receives the context data access request sent by the target MC when it obtains the target processing request.

[0087] When the target MC receives a target processing request, in order to execute the processing task, the target MC constructs a context data access request message according to the MCP communication rules and sends it to the first CMU through the MCP communication channel.

[0088] S220, the first CMU receives a first notification message sent by the CRC when it determines that the first CMU stores the dynamic context data corresponding to the target processing request but does not store the static context data.

[0089] In this step, the first CMU receives a first notification message sent by the CRC when it determines that the first CMU stores the dynamic context data corresponding to the target processing request but does not store the static context data. The first notification message carries the access address of the second CMU.

[0090] S230, the first CMU sends a static context data access request to the second CMU based on the access address.

[0091] In this step, the first CMU sends a static context data access request to the second CMU based on the access address, and calls the binary serialization decoder to receive the static context data in a zero-copy manner.

[0092] Regarding S220-S230, the static and dynamic context data of multiple Context Management Units (CMUs) are distributed and stored across different nodes. When a model component (MC) is performing a task, its local CMU may only contain dynamic data, lacking static context data. Traditional cross-node access methods rely on local nodes querying the data themselves, a complex process with high latency. Furthermore, static data transfer typically involves multiple memory copies, increasing CPU overhead and reducing system throughput. Therefore, in S220-S230, a Context Routing Control Unit (CRC) is configured to globally monitor the distribution of context data across all CMUs.

[0093] When the CRC check determines that the first CMU stores dynamic data but lacks static data, it sends a first notification message to the first CMU, carrying the access address of the second CMU where the static data is located. The first CMU then uses the MCP protocol to directly initiate a static data access request to the second CMU based on this address, and calls a binary serializer decoder to receive the data in a zero-copy manner, avoiding unnecessary intermediate copying.

[0094] S240, the first CMU obtains the dynamic context data corresponding to the stored target processing request.

[0095] In this step, the first CMU obtains the dynamic context data corresponding to the stored target processing request.

[0096] If the first CMU does not store the static context data corresponding to the target processing request, the first CMU sends the static context data access request corresponding to the target processing request to the second CMU according to the access address of the second CMU.

[0097] S250, the first CMU receives the static context data corresponding to the target processing request sent by the second CMU in response to the static context data access request.

[0098] In this step, the first CMU receives the static context data corresponding to the target processing request sent by the second CMU in response to the static context data access request, and recovers the data using incremental binary deserialization.

[0099] For S240-S250 above, in an MCP-driven dynamic data access system, task execution requires both static and dynamic context data, which are often distributed across different Context Management Units (CMUs). Therefore, in S240-S250, the first CMU prioritizes accessing local data; if any data is missing, the second CMU is then accessed to retrieve the missing portion. This forms a dual-optimized path that minimizes cross-node transmission and data parsing, thereby reducing latency and resource consumption in MCP-driven high-concurrency data access scenarios.

[0100] S260, the first CMU sends the static context data and dynamic context data corresponding to the target processing request to the target MC through a zero-copy transmission mechanism.

[0101] In this step, the first CMU sends the static and dynamic context data corresponding to the target processing request to the target MC through a zero-copy transmission mechanism. The zero-copy transmission mechanism includes:

[0102] On the same computing node, a shared memory mapping method is used to transfer binary context data buffers between the sending and receiving ends;

[0103] Between different computing nodes, a transfer protocol that supports direct memory access (DMA) is used to transfer the binary serialized context data directly from the sender's buffer to the receiver's buffer without performing an intermediate user-space copy.

[0104] It's worth noting that in MCP-driven dynamic data access systems, static and dynamic context data are typically transferred and shared between different computing nodes via a binary context data buffer. This buffer is frequently shared and referenced when multiple model components access it simultaneously. However, the buffer's lifecycle control relies on simple reference counting or manual release, which can easily lead to premature data release due to asynchronous access, resulting in null pointer exceptions, data corruption, and other problems at the accessing end. This situation is even more severe in zero-copy transfer or shared memory mapping scenarios, because the lack of real-time coordination between memory release and the user directly impacts system stability and data consistency.

[0105] In one possible implementation, the metadata structure in the binary context data buffer can be configured to include a reference count field, a lifecycle status field, and a last access timestamp field. The reference count field records the number of users currently holding the binary context data buffer. The binary context data buffer is released when the value of the reference count field becomes zero and the lifecycle status field is in a release pending state. The last access timestamp field is used to perform delayed release processing before the binary context data buffer is released to prevent asynchronous access conflicts between the sender and receiver.

[0106] With the aforementioned metadata structure, buffer release and retention can be automatically controlled based on precise reference counting status and lifecycle identifiers. Furthermore, by using the last access timestamp in conjunction with a delayed release strategy, data conflicts and premature release issues caused by asynchronous access are effectively avoided. In addition, in MCP-driven dynamic data access scenarios, the stability of zero-copy data transfer can be significantly improved, enabling the system to maintain data consistency and optimized memory resource utilization even under high concurrency and high-frequency context data updates, thereby effectively resolving buffer premature release and access conflict issues.

[0107] Furthermore, in MCP-driven dynamic data access systems, the binary context data buffer is frequently accessed and referenced by multiple model components and context management units in a multi-threaded or multi-process environment. If a simple reference counting mechanism is used to determine when to release the buffer, contention for updating the reference count can easily occur under high concurrency conditions, leading to incorrect count values.

[0108] Meanwhile, if the buffer is released immediately when the reference count drops to zero, potential subsequent access needs will be ignored, causing data to be destroyed prematurely. This can lead to problems such as null pointer access, memory access anomalies, and performance fluctuations. Especially in context management scenarios that require zero copying and shared buffers, such premature release or unsafe updates can seriously affect the stability and throughput performance of the system.

[0109] To address this, atomic operations can be used to increment or decrement the reference count field, ensuring the atomicity and memory visibility of reference count updates in a multi-threaded concurrent environment. Specifically, when the reference count field becomes zero, the binary context data buffer is not immediately released; instead, the lifecycle state field is set to a pending release state, and the last access timestamp is recorded.

[0110] Then, while in the waiting-to-release state, a delayed release timer is started. When a new access operation is detected within the preset delay time, the reference count field is incremented again according to the atomic operation, and the lifecycle state field is restored to the active state. If the reference count field is still zero and no new access operation is detected when the delay time expires, the lifecycle state field is updated to the released state, and the memory release operation of the binary context data buffer is performed.

[0111] By employing processor-level atomic operations during reference counting updates, the atomicity of count changes and memory visibility in a multi-threaded environment are ensured, effectively avoiding counting errors caused by concurrent contention. When the count value reaches zero, the buffer is not immediately released; instead, its lifecycle state is switched to "waiting to be released," and the last access timestamp is recorded, allowing the system to retain the buffer for a preset delay. When a new access request is detected during the delay, the reference count is quickly restored through atomic operations, and the lifecycle state is switched to "active," ensuring the reusability and access continuity of the buffer. If the delay times out and there are no new accesses, the memory resources are safely released. This approach, while ensuring data consistency and thread safety, reduces the overhead of frequent allocation and release, improves stability and computational efficiency during high-concurrency dynamic data access, and thus solves the problems of unsafe reference counting updates and premature buffer release.

[0112] Figure 3 This is a schematic diagram illustrating the structure of a dynamic data access system according to an example embodiment of this application. For example... Figure 3 As shown, the dynamic data access system 300 provided in this embodiment includes:

[0113] The system includes multiple model components (MC310) and multiple context management units (CMU320). The MCs and CMUs communicate via a model context protocol (MCP330). The multiple CMUs320 are used to store static and dynamic context data required by the MCs when processing tasks.

[0114] The first CMU receives a context data access request sent by the target MC when it obtains a target processing request. The plurality of CMUs includes the first CMU, and the plurality of MCs includes the target MC.

[0115] The first CMU responds to the context data access request and obtains the static context data and dynamic context data corresponding to the target processing request;

[0116] The first CMU sends the static context data and dynamic context data corresponding to the target processing request to the target MC.

[0117] Optionally, a portion of the CMU may be used to store static context data required for MC processing tasks, or a portion of the CMU may be used to store dynamic context data required for MC processing tasks, or a portion of the CMU may be used to store both static and dynamic context data required for MC processing tasks.

[0118] Optionally, the static context data includes one or more of the model configuration parameter data and access policy data used in the processing process corresponding to the target processing request; the dynamic context data includes one or more of the session state information, intermediate results of model inference, and runtime environment parameters.

[0119] Optionally, obtaining the static context data and dynamic context data corresponding to the target processing request includes:

[0120] The static and dynamic context data corresponding to the target processing request are obtained using incremental binary serialization.

[0121] Optionally, the plurality of CMUs further includes a second CMU, wherein the deployment locations of the first CMU and the second CMU are different; correspondingly, the first CMU responds to the context data access request and obtains the static context data and dynamic context data corresponding to the target processing request, including:

[0122] The first CMU acquires the dynamic context data corresponding to the stored target processing request;

[0123] If the first CMU does not store the static context data corresponding to the target processing request, the first CMU sends the static context data access request corresponding to the target processing request to the second CMU according to the access address of the second CMU;

[0124] The first CMU receives the static context data corresponding to the target processing request sent by the second CMU in response to the static context data access request.

[0125] Optionally, the dynamic data access system further includes a context routing control unit (CRC); correspondingly, before the first CMU responds to the context data access request and obtains the static context data and dynamic context data corresponding to the target processing request, it further includes:

[0126] The first CMU receives a first notification message sent by the CRC when it determines that the first CMU stores the dynamic context data corresponding to the target processing request but does not store the static context data. The first notification message carries the access address of the second CMU.

[0127] The first CMU sends a static context data access request to the second CMU based on the access address, and calls the binary serialization decoder to receive the static context data in a zero-copy manner.

[0128] Optionally, the first CMU sends static context data and dynamic context data corresponding to the target processing request to the target MC, including:

[0129] The first CMU sends the static context data and dynamic context data corresponding to the target processing request to the target MC through a zero-copy transmission mechanism.

[0130] Figure 4 This is a schematic diagram of the structure of an electronic device according to an example embodiment of this application. For example... Figure 4 As shown, the electronic device 400 provided in this embodiment includes: a processor 401 and a memory 402; wherein:

[0131] Memory 402 is used to store computer programs, and the memory may also be flash memory.

[0132] Processor 401 is used to execute the execution instructions stored in the memory to implement the various steps in the above method. For details, please refer to the relevant descriptions in the preceding method embodiments.

[0133] Alternatively, the memory 402 can be either standalone or integrated with the processor 401.

[0134] When the memory 402 is a device independent of the processor 401, the electronic device 400 may further include:

[0135] Bus 403 is used to connect the memory 402 and the processor 401.

[0136] This embodiment also provides a readable storage medium storing a computer program, which, when executed by at least one processor of an electronic device, enables the electronic device to perform the methods provided in the various embodiments described above.

[0137] This embodiment also provides a program product including a computer program stored in a readable storage medium. At least one processor of an electronic device can read the computer program from the readable storage medium, and the at least one processor executes the computer program to cause the electronic device to perform the methods provided in the various embodiments described above.

[0138] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0139] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A dynamic data access method based on MCP driver, characterized in that, A dynamic data access system is applied to a system comprising multiple model components (MCs) and multiple context management units (CMUs), wherein the MCs and the CMUs communicate via a model context protocol (MCP), and the multiple CMUs are used to store static and dynamic context data required by the MCs when processing tasks. The method includes: The first CMU receives a context data access request sent by the target MC when it obtains a target processing request. The plurality of CMUs includes the first CMU, and the plurality of MCs includes the target MC. The first CMU responds to the context data access request by obtaining the static context data and dynamic context data corresponding to the target processing request; including: The static and dynamic context data corresponding to the target processing request are obtained using incremental binary serialization. The object structures of the static context data and the dynamic context data are analyzed for reference relationships, and a corresponding object reference relationship graph is constructed. Each node in the object reference relationship graph corresponds to a context data object, and the globally unique identifier, reference parent object information, and reference count of the context data object are recorded. During the incremental binary serialization process, a depth-first traversal of the object reference graph is used for change detection. When a change is detected in a child object of a node, the corresponding change mark is propagated to its parent node and upper-level nodes to ensure that the parent node of the nested reference can be correctly identified as the changed object. During the traversal, circular references are detected, and the recursive processing of a node that has already been visited is skipped to prevent the serialization process from entering infinite recursion. When performing binary encoding, if the globally unique identifier of the context data object node has already been encoded in the current serialization cycle, the content of the object will not be encoded again. Instead, a reference tag will be generated and the globally unique identifier will be carried to restore the shared reference relationship during deserialization. When the object reference structure changes, the object reference relationship graph is regenerated, and the incremental binary serialization index table is updated synchronously to keep the index table consistent with the latest object structure. The first CMU sends the static context data and dynamic context data corresponding to the target processing request to the target MC.

2. The dynamic data access method based on MCP driver according to claim 1, characterized in that, A portion of the CMU is used to store static context data required for MC processing tasks, or a portion of the CMU is used to store dynamic context data required for the MC processing tasks, or a portion of the CMU is used to store both static and dynamic context data required for the MC processing tasks.

3. The dynamic data access method based on MCP driver according to claim 1, characterized in that, The static context data includes one or more of the model configuration parameter data and access policy data used in the processing process corresponding to the target processing request; the dynamic context data includes one or more of the session state information, intermediate results of model inference, and runtime environment parameters.

4. The dynamic data access method based on MCP driver according to claim 1, characterized in that, The plurality of CMUs also includes a second CMU, wherein the deployment locations of the first CMU and the second CMU are different; Correspondingly, the first CMU responds to the context data access request and obtains the static context data and dynamic context data corresponding to the target processing request, including: The first CMU acquires the dynamic context data corresponding to the stored target processing request; If the first CMU does not store the static context data corresponding to the target processing request, the first CMU sends the static context data access request corresponding to the target processing request to the second CMU according to the access address of the second CMU; The first CMU receives the static context data corresponding to the target processing request sent by the second CMU in response to the static context data access request.

5. The dynamic data access method based on MCP driver according to claim 4, characterized in that, The dynamic data access system further includes a context routing control unit (CRC); correspondingly, before the first CRC responds to the context data access request and obtains the static context data and dynamic context data corresponding to the target processing request, the system further includes: The first CMU receives a first notification message sent by the CRC when it determines that the first CMU stores the dynamic context data corresponding to the target processing request but does not store the static context data. The first notification message carries the access address of the second CMU. The first CMU sends a static context data access request to the second CMU based on the access address, and calls the binary serialization decoder to receive the static context data in a zero-copy manner.

6. The dynamic data access method based on MCP driver according to claim 5, characterized in that, The first CMU sends static context data and dynamic context data corresponding to the target processing request to the target MC, including: The first CMU sends the static context data and dynamic context data corresponding to the target processing request to the target MC through a zero-copy transmission mechanism.

7. A dynamic data access system, characterized in that, include: The system includes multiple model components (MCs) and multiple context management units (CMUs). The MCs and CMUs communicate via the Model Context Protocol (MCP). The multiple CMUs are used to store static and dynamic context data required by the MCs when processing tasks. The first CMU receives a context data access request sent by the target MC when it obtains a target processing request. The plurality of CMUs includes the first CMU, and the plurality of MCs includes the target MC. The first CMU responds to the context data access request by obtaining the static context data and dynamic context data corresponding to the target processing request; including: The static and dynamic context data corresponding to the target processing request are obtained using incremental binary serialization. The object structures of the static context data and the dynamic context data are analyzed for reference relationships, and a corresponding object reference relationship graph is constructed. Each node in the object reference relationship graph corresponds to a context data object, and the globally unique identifier, reference parent object information, and reference count of the context data object are recorded. During the incremental binary serialization process, a depth-first traversal of the object reference graph is used for change detection. When a change is detected in a child object of a node, the corresponding change mark is propagated to its parent node and upper-level nodes to ensure that the parent node of the nested reference can be correctly identified as the changed object. During the traversal, circular references are detected, and the recursive processing of a node that has already been visited is skipped to prevent the serialization process from entering infinite recursion. When performing binary encoding, if the globally unique identifier of the context data object node has already been encoded in the current serialization cycle, the content of the object will not be encoded again. Instead, a reference tag will be generated and the globally unique identifier will be carried to restore the shared reference relationship during deserialization. When the object reference structure changes, the object reference relationship graph is regenerated, and the incremental binary serialization index table is updated synchronously to keep the index table consistent with the latest object structure. The first CMU sends the static context data and dynamic context data corresponding to the target processing request to the target MC.

8. An electronic device, characterized in that, include: processor; as well as, Memory for storing the executable instructions of the processor; The processor is configured to execute the method of any one of claims 1 to 6 by executing the executable instructions.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 6.

Images