Method and device for realizing token shunting through computing power by intelligent computing cloud platform

Abstract

The application provides a method and device for realizing Token shunting through computing power by an intelligent computing cloud platform, and relates to the technical fields of intelligent computing centers, intelligent computing centers, computing power infrastructure and intelligent computing cloud, and the method comprises the following steps: S1, multiple candidate Token nodes are generated by analyzing multi-source information corresponding to a user request; S2, node attributes of each candidate Token node and edge relationships between the candidate Token nodes are generated to construct a Token value graph; S3, the candidate Token nodes are valued according to the Token value graph and a historical computing power account book, and multiple key Token nodes in the Token value graph are identified; and S4, Token shunting is performed according to the key Token nodes, the Token value graph and the historical computing power account book. The application can retain key Tokens, improve the accuracy and efficiency of Token shunting, avoid computing power waste caused by invalid pre-filling, repeated tool calling, invalid caching and excessive verification, and improve the success rate and security of tasks.

Description

Technical Field

[0001] This invention relates to the fields of intelligent computing centers, smart computing centers, computing power infrastructure, and smart computing cloud technology, specifically to a method and apparatus for achieving token distribution through computing power in an intelligent computing cloud platform. Background Technology

[0002] With the rapid development of artificial intelligence technology, "intelligent computing centers" and "smart computing centers" have emerged.

[0003] An "intelligent computing center" refers to a facility that provides the necessary computing power, data, and algorithms for artificial intelligence applications (such as the development, training, and inference of deep learning models) by utilizing large-scale heterogeneous computing resources, including general-purpose and intelligent computing power. Intelligent computing centers encompass facilities, hardware, and software, and can provide full-stack capabilities from underlying computing power to top-level application enablement.

[0004] "Intelligent computing center" includes, but is not limited to, "intelligent computing center".

[0005] "Intelligent computing center" or artificial intelligence computing center is a type of computing infrastructure that provides computing power services, data services, and algorithm services required for artificial intelligence applications, based on artificial intelligence theory and adopting artificial intelligence computing architecture.

[0006] "Computing power" is the core of "intelligent computing center" and "smart computing center". It is the ability of computer equipment or computing / data center to process parameters. It is the ability of computer hardware and software to work together to execute a certain computing requirement. It is the computing power to achieve the target result output by processing parameter data. It is a new type of productivity that integrates parameter computing power, network carrying capacity and data storage capacity. It mainly provides services to society through computing power infrastructure.

[0007] In existing technologies, runtime scheduling typically uses requests, rounds, task steps, agent calls, context window lengths, or model types as basic units. At the underlying implementation level, large model computation essentially revolves around tokens, and in large model inference systems, tokens are directly related to cost and performance. Existing systems usually track total input tokens, total output tokens, cache hit tokens, or request-level GPU latency. However, these statistics primarily serve billing or performance monitoring and haven't yet incorporated tokens into multi-agent orchestration decisions. This leads to the easy deletion of critical tokens during computation, and writing low-value content into long-term memory increases subsequent retrieval noise. Furthermore, it results in wasted computational power due to invalid pre-filling, duplicate tool calls, invalid caching, and over-validation, ultimately reducing task success rate and security.

[0008] It is evident that since the emergence of intelligent computing centers, how to retain key tokens, avoid writing low-value content into long-term memory, reduce subsequent retrieval noise, improve the accuracy and efficiency of token distribution, avoid wasting computing power caused by invalid pre-filling, duplicate tool calls, invalid caching and over-validation, and improve task success rate and security has always been a difficult problem to be solved in this field. Summary of the Invention

[0009] This invention provides a method and apparatus for token distribution through computing power in an intelligent computing cloud platform, in order to solve the problems in the prior art, such as the easy deletion of key tokens, the increase of subsequent retrieval noise by writing low-value content into long-term memory, the waste of computing power caused by invalid pre-filling, duplicate tool calls, invalid caching and over-verification, and the reduction of task success rate and security.

[0010] To solve the above problems, the present invention is implemented as follows: In a first aspect, the present invention provides a method for a smart computing cloud platform to achieve token distribution through computing power, comprising: Step S1: Based on the multi-source information corresponding to the user request, parse the multi-source information and generate multiple candidate Token nodes; Step S2: Generate the node attributes of each candidate Token node and the edge relationships between candidate Token nodes to construct a Token value graph; Step S3: Based on the Token value map and historical computing power ledger, evaluate the value of candidate Token nodes and identify multiple key Token nodes in the Token value map. The historical computing power ledger includes the evaluation and routing information of Token nodes at historical moments. Step S4: Distribute tokens based on key token nodes, token value graphs, and historical computing power ledgers.

[0011] Secondly, the present invention also provides a device for a smart computing cloud platform to achieve token distribution through computing power, comprising: The node generation module is used to generate multiple candidate token nodes based on the multi-source information corresponding to the user request and to parse the multi-source information. The value graph construction module is used to generate the node attributes of each candidate token node and the edge relationships between candidate token nodes in order to construct the token value graph. The identification module is used to evaluate the value of candidate Token nodes based on the Token value graph and historical computing power ledger, and to identify multiple key Token nodes in the Token value graph. The historical computing power ledger includes the evaluation and routing information of Token nodes at historical moments. The Token distribution module is used to distribute tokens based on key token nodes, the token value graph, and the historical computing power ledger.

[0012] Thirdly, the present invention also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein when the computer program is executed by the processor, it implements the steps in the method for token distribution through computing power of the intelligent computing cloud platform described in the first aspect above.

[0013] Fourthly, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the method for token distribution through computing power in the intelligent computing cloud platform described in the first aspect above.

[0014] Fifthly, the present invention also provides a computer program product, including computer instructions, which, when executed by a processor, implement the steps in the method for token distribution through computing power in the intelligent computing cloud platform described in the first aspect above.

[0015] In this invention, step S1 involves parsing the multi-source information corresponding to the user request to generate multiple candidate Token nodes; step S2 involves generating the node attributes of each candidate Token node and the edge relationships between candidate Token nodes to construct a Token value graph; step S3 involves evaluating the value of the candidate Token nodes based on the Token value graph and historical computing power ledger to identify multiple key Token nodes in the Token value graph; and step S4 involves Token distribution based on the key Token nodes, the Token value graph, and the historical computing power ledger. This invention can retain key Tokens, avoid writing low-value content into long-term memory, reduce subsequent retrieval noise, improve the accuracy and efficiency of Token distribution, avoid wasting computing power caused by invalid pre-filling, duplicate tool calls, invalid caching, and over-validation, and improve task success rate and security. Attached Figure Description

[0016] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the description of the present invention will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart of a method for achieving token distribution through computing power in an intelligent computing cloud platform provided by the present invention; Figure 2 This is a structural diagram of a device for achieving token distribution through computing power in an intelligent computing cloud platform provided by the present invention; Figure 3 This is a structural diagram of an electronic device provided by the present invention. Detailed Implementation

[0018] The technical solutions of this invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0019] The “computing power” mentioned in this invention refers to: the ability of computer equipment or computing / data center to process information; the ability of computer hardware and software to work together to perform a certain computing requirement; the computing power to achieve the target result output by processing information data; and a new type of productivity that integrates information computing power, network carrying capacity, and data storage capacity, mainly providing services to society through computing power infrastructure.

[0020] The "computational power" (CP) described in this invention refers to the ability of a data center server to process data and output results. It is a comprehensive indicator of a data center's computing power, encompassing general computing power, supercomputing power, and intelligent computing power. The commonly used unit of measurement is floating-point operations per second (FLOPS, 1 EFLOPS = 10^18 FLOPS), with higher values ​​indicating stronger overall computing power. It is estimated that 1 EFLOPS is approximately the computing power output of 5 Tianhe-2A supercomputers, 500,000 mainstream server CPUs, or 2 million mainstream laptops. The calculation formula is: CP = CP 通用 +CP 智能 +CP 超级 .

[0021] The "Network Power" (NP) mentioned in this invention refers to the performance of data transmission capability of computing facilities, which includes comprehensive capabilities such as network architecture, network bandwidth, transmission latency, intelligent management and scheduling, and involves network transmission within and between data centers. It is a comprehensive indicator for measuring network transmission scheduling capability.

[0022] The "Storage Power" (SP) described in this invention refers to the comprehensive capabilities of a data center in four aspects: data storage capacity, performance, security and reliability, and green and low-carbon operation. It is a comprehensive indicator for measuring the data storage capacity of a data center, including external storage devices such as storage arrays and internal storage devices within servers. The commonly used unit of measurement for storage capacity is exabytes (EB, 1EB = 2^60 bytes), while the commonly used unit of measurement for performance is the number of read / write operations per second (IOPS / TB). Disaster recovery ratio is an important indicator of security and reliability.

[0023] The "computing infrastructure" mentioned in this invention refers to a new type of information infrastructure that integrates information computing power, network carrying capacity, and data storage capacity, enabling centralized computing, storage, transmission, and application of information.

[0024] The "new information infrastructure" mentioned in this invention refers to network infrastructure such as 5G networks, fiber optic broadband networks, backbone networks, international communication networks, and satellite internet; computing infrastructure such as data centers, general computing centers, intelligent computing centers, and supercomputing centers; and new technology facilities such as artificial intelligence, blockchain, and quantum computing.

[0025] The “computing power” mentioned in this invention includes: general computing power, intelligent computing power, and supercomputing power.

[0026] The "general computing power" mentioned in this invention refers to the computing power provided by servers based on CPU (Central Processing Unit) chips, which is used to support basic general computing such as cloud computing and edge computing.

[0027] The "intelligent computing power" mentioned in this invention refers to: a computing platform deployed on a large scale based on dedicated chips such as GPU (Graphics Processing Unit), FPGA (Field Programmable Gate Array), and ASIC (Application Specific Integrated Circuit) for various artificial intelligence innovative applications, such as natural language processing and machine vision.

[0028] The “supercomputing power” mentioned in this invention refers to the computing power provided by high-performance computing clusters such as supercomputers. It utilizes the centralized computing resources of multiple computer systems working in parallel and uses a dedicated operating system to handle extremely complex or data-intensive problems. It is mainly used for computing in cutting-edge scientific fields, such as planetary simulation, drug molecule design, and gene analysis.

[0029] The "intelligent computing center" described in this invention refers to a facility that utilizes large-scale heterogeneous computing resources, including general-purpose computing power (CPU) and intelligent computing power (GPU, FPGA, ASIC, etc.), to primarily provide the necessary computing power, data, and algorithms for artificial intelligence applications (such as the development, training, and inference of deep learning models). The intelligent computing center encompasses facilities, hardware, and software, and can provide full-stack capabilities from underlying computing power to top-level application enablement.

[0030] The "intelligent computing cloud platform" mentioned in this invention, abbreviated as "intelligent computing cloud", refers to a cloud computing platform that integrates hardware and software resources based on an intelligent computing center.

[0031] The "intelligent computing center" mentioned in this invention includes, but is not limited to, "smart computing center".

[0032] The "intelligent computing center" mentioned in this invention, also known as an artificial intelligence computing center, is a type of computing infrastructure that provides computing power services, data services, and algorithm services required for artificial intelligence applications, based on artificial intelligence theory and adopting an artificial intelligence computing architecture.

[0033] The "computing center" mentioned in this invention refers to a facility that is mainly composed of infrastructure such as wind, thermal, hydro, and electricity, and IT hardware and software equipment, and has computing power, carrying capacity, and storage capacity, including general data centers, intelligent computing centers, supercomputing centers, etc.

[0034] The "supercomputing center" mentioned in this invention refers to a supercomputing data center, which is a data center based on supercomputers or large-scale computing clusters. It can provide large-scale computing, storage and network services and is widely used in aerospace, defense, oil exploration, climate modeling and genome sequencing and other application scenarios.

[0035] The “computing resources” mentioned in this invention refer to the technologies and facilities required for the development of the digital society that have the ability to compute, transmit, store and apply information, including but not limited to computing resources such as CPUs and GPUs, network resources such as switches and routers, storage resources such as storage arrays and distributed storage, security resources such as firewalls and intrusion detection systems, and supporting and guaranteeing resources such as wind, fire, water and electricity.

[0036] The "model" mentioned in this invention includes, but is not limited to, "large language model" and "multimodal large model".

[0037] The "large language model" mentioned in this invention refers to a large-scale language model (LLM), which is a language model with a large number of parameters. It is designed to understand and generate human language, and is trained with a large amount of text data. It can perform a wide range of tasks, including text summarization, translation, and sentiment analysis.

[0038] The “Multimodal Large Models” mentioned in this invention refer to models that combine multimodal information such as text, images, videos, and audio for training, including but not limited to multimodal large language models.

[0039] The "computing power routing" described in this invention refers to a core routing technology for the convergence of computing and network technologies. Based on existing IP networks, it incorporates the status of computing resources (such as CPU / GPU load, memory, and computing service type) into routing decisions to achieve the joint optimal selection of network paths and computing nodes.

[0040] The "computing power service" mentioned in this invention refers to a service that provides users with on-demand information computing power, network carrying capacity, and data storage capacity through computing power resources, such as inference service, training service, or fine-tuning service.

[0041] The “computing power cluster” mentioned in this invention refers to a distributed computing system that interconnects a large number of computing nodes (usually including acceleration chips such as CPU / GPU / TPU) through a high-speed network and is scheduled to work together by a unified management system. It aims to provide aggregated computing power far exceeding that of a single node to support large-scale artificial intelligence applications, model training, scientific computing and complex data processing.

[0042] The “computing power network” mentioned in this invention refers to the platform network on which multiple GPUs exchange a large amount of data during the token calculation process (training or inference).

[0043] The “Token” mentioned in this invention refers to the basic unit of measurement when a large language model or multimodal large model processes text, code, image descriptions, document content, or other serialized inputs and outputs.

[0044] It is important to emphasize that different models use different tokenizers. The same text may correspond to different numbers of tokens in different models.

[0045] Please see Figure 1 , Figure 1 This is a flowchart of a method for token distribution through computing power provided by the present invention, as shown below. Figure 1 As shown, the method includes: Step S1: Based on the multi-source information corresponding to the user request, parse the multi-source information and generate multiple candidate Token nodes.

[0046] In this invention, the Token node is not necessarily limited to a single sub-word output by the tokenizer. To balance computational efficiency and engineering feasibility, the Token node can be a single Token, a continuous Token fragment, a structured field, a tool parameter, a JSON field, a line of code, a retrieval paragraph, a memory summary, an error stack fragment, a human feedback fragment, or a risk marker. As long as it can be mapped to the Token range in the model context, it can serve as a node in the graph.

[0047] The token node can be a single token output by the tokenizer, or it can be a token span, sentence, structured field, code block, tool parameter, table cell, image OCR fragment or multimodal object. This invention does not limit this.

[0048] The beneficial technical effects achieved by step S1 are: heterogeneous multi-source information is transformed into Token nodes, which upgrades the Token from a text segmentation unit to a measurable and schedulable computing power asset, providing a refined data foundation for subsequent Token-level differentiated routing.

[0049] Step S2: Generate the node attributes of each candidate Token node and the edge relationships between candidate Token nodes to construct a Token value graph.

[0050] Node attributes include at least one of the following: source type, semantic type, task relevance, risk level, timeliness, confidence level, reuse probability, pre-computational cost, historical contribution, and audit identifier.

[0051] Edge relationships include at least one of the following: reference relationship, inclusion relationship, constraint relationship, causal relationship, conflict relationship, tool dependency relationship, evidence support relationship, risk propagation relationship, reuse relationship, substitution relationship, summary and induction relationship, modification relationship and failure rollback relationship.

[0052] The token value graph can be implemented using directed graphs, undirected graphs, heterogeneous graphs, hypergraphs, factor graphs, dynamic graphs, or time series graphs; edge weights can be generated by rules, models, graph neural networks, statistical co-occurrence, or manual annotation.

[0053] The beneficial technical effects achieved by step S2 are as follows: By assigning multi-dimensional attributes to each Token node and establishing various edge relationships between nodes, the system can accurately identify key Tokens and their dependent chains based on node attributes and topological relationships, providing a structured decision-making basis for subsequent differentiated computing power routing, according to the measurable and associative Token graph structure.

[0054] Step S3: Based on the Token value map and historical computing power ledger, evaluate the value of candidate Token nodes and identify multiple key Token nodes in the Token value map. The historical computing power ledger includes the evaluation and routing information of Token nodes at historical moments.

[0055] In one embodiment, based on the node attributes, topological relationships, edge weights in the Token value graph, and the input-output relationship between each runtime action and the Token set recorded in the historical computing power ledger, the Token value is evaluated, the criticality of each candidate Token node is comprehensively calculated, and the set of critical Token nodes that have a significant impact on the task results, high risk, or high reuse potential is identified through graph centrality analysis and path coverage evaluation.

[0056] Token value assessment can employ a token value evaluator, which can be implemented using methods such as linear weighting, gradient boosting trees, neural networks, graph neural networks, reinforcement learning strategies, contextual bandits, or a hybrid approach combining rules and learning. Contextual bandits are a class of algorithmic frameworks for making sequential decisions under uncertainty; in this application, they are used to dynamically select the optimal path among multiple computing power paths and continuously learn and improve during operation.

[0057] In one embodiment, the token computing power ledger can be implemented using a relational database, graph database, columnar database, time-series database, object storage, or blockchain-style immutable log; to improve data security, the ledger content can be hashed, anonymized, or encrypted according to a privacy policy.

[0058] The beneficial technical effects achieved by step S3 are: it can accurately identify key token nodes worth investing computing power in from a large number of token nodes, retain key tokens, and avoid evenly distributing high-cost inference resources to all tokens, thereby achieving the optimal balance between task quality and resource consumption under a limited computing power budget.

[0059] Step S4: Distribute tokens based on key token nodes, token value graphs, and historical computing power ledgers.

[0060] In one embodiment, based on key Token nodes and their neighborhood subgraphs in the Token value graph, combined with the historical contribution, reuse revenue, and cost records of each Token in the historical computing power ledger, differentiated Token routing is performed on the Token set. High-value, high-risk Tokens are allocated large model, expert model, sandbox, or manual approval resources, high-reusability Tokens are allocated cache resources, and low-value historical Tokens are allocated compression or discard processing, thereby achieving computing power routing.

[0061] Optionally, the Token routing action of the present invention may include model selection, inference depth selection, context window selection, tool permission selection, cache level selection, sandbox level selection, manual approval selection, batch processing priority selection, and tenant resource pool selection.

[0062] In one embodiment, a graph-constrained context assembly mechanism can also be used. Under context budget constraints, high-value constraints and evidence chain integrity are prioritized for preservation, non-critical tokens are subjected to structured compression or elimination, and finally the assembled context is input into the model to perform inference and obtain the execution result of the user request. In this invention, graph-constrained context assembly provides data support for token diversion.

[0063] The beneficial technical effects achieved by step S4 are: avoiding writing low-value content into long-term memory, reducing subsequent retrieval noise, improving the accuracy and efficiency of token distribution, avoiding the waste of computing power caused by invalid pre-filling, duplicate tool calls, invalid caching and over-validation, and improving task success rate and security.

[0064] In one embodiment, step S1 includes: Step S1.1: Obtain multi-source information based on the user request and its associated context.

[0065] In one embodiment, information such as user requests, system prompts, historical conversations, long-term memory, search results, tool returns, code execution logs, external API returns, security policies, user profiles, and human feedback are received as multi-source information.

[0066] Step S1.2: Segment the multi-source information to obtain multiple token fragments.

[0067] In one embodiment, multi-source information is segmented into tokens or token fragments.

[0068] For example, perform token segmentation and fragment merging on multi-source information to obtain multiple token fragments.

[0069] Step S1.3: Obtain the alignment relationship between token fragments.

[0070] In one embodiment, alignment is established based on the original text location, data source, session round, agent steps, and tool calls.

[0071] In one embodiment, a mapping alignment relationship is established between token fragments based on the original text location, data source, session round, agent step, and tool call.

[0072] The beneficial technical effects achieved by steps S1.1 to S1.3 are: segmenting multi-source information into tokens or token fragments, and establishing a mapping alignment relationship between the tokens and the original text location, data source, session rounds, agent steps, and tool calls, providing a structured data foundation for token node generation and value graph construction.

[0073] Step S1.4: Based on the alignment relationship, perform structural field parsing and source alignment on the Token fragment to generate multiple candidate Token nodes.

[0074] For example, the token fragments undergo structural field parsing. For natural language text, semantic integrity and positional sequence are preserved; for tool call results, field names, values, data types, and return status codes are parsed; for code execution logs, error stacks, line numbers, and variable values ​​are extracted; for external API returns, parameter key-value pairs, status codes, and timestamps are identified. Furthermore, the token fragments are source-aligned based on alignment relationships.

[0075] The beneficial technical effects achieved by step S1.4 are as follows: by parsing the structure fields and aligning the sources of the token fragments, unstructured multi-source information is transformed into structured token nodes, providing an accurate and traceable data foundation for subsequent value graph construction and computing power routing.

[0076] In one embodiment, step S2 includes steps S2.1, S2.2, and S2.3, which will be described in detail below.

[0077] Step S2.1: Generate node attributes for each candidate Token node.

[0078] In one embodiment, node attributes such as source type, semantic type, task relevance, risk level, timeliness, reuse probability, confidence level, pre-computational cost, and audit identifier are generated for each Token node to ensure the semantic fidelity, location traceability, and structural resolvability of multi-source heterogeneous information in the Token-level modeling process.

[0079] In one embodiment, let the set of Token nodes for a single task be... .

[0080] Each candidate token node The attribute vector can be represented as .

[0081] in, Indicate the source type, such as user input, historical memory, tool results, system commands, external knowledge, sub-Agent output, and human feedback; Represent semantic types, such as task objectives, hard constraints, entities, values, permissions, codes, paths, amounts, times, legal terms, preferences, and error logs; Indicates task relevance; Indicates the risk level; Indicates timeliness; Indicates the probability of reuse; Indicates confidence level; This indicates the estimated or actual computing power cost; Indicates historical contribution; This indicates identification information related to tenants, sessions, data permissions, and auditing.

[0082] In a preferred embodiment, the system categorizes Token nodes as follows: Task Core Token, Constraint Token, Tool Dependency Token, Evidence Token, Inference Intermediate Token, Risk Token, Memory Token, Preference Token, Low-Value Filler Token, Conflict Token, Failure Trajectory Token, and Manual Correction Token. Different Token types correspond to different default strategies. For example, Task Core Tokens are retained in their original form and enter the Planner by default; Risk Tokens are used for risk propagation and permission verification by default; High-Reusability Memory Tokens are used as cache accumulation candidates by default; and Low-Value Filler Tokens are used as compression candidates by default.

[0083] Step S2.2: Obtain the edge relationships, edge weights, and relationship validity periods between candidate Token nodes.

[0084] In one embodiment, the relationship types of edge relationships include at least one or more of the following: reference relationship, containment relationship, constraint relationship, causal relationship, conflict relationship, tool dependency relationship, evidence support relationship, risk propagation relationship, reuse relationship, substitution relationship, summary and induction relationship, manual correction relationship, and failure rollback relationship.

[0085] In a preferred embodiment, the edge weight can be determined by the semantic similarity, structural dependency, location proximity, tool call chain, manual annotation, and historical ledger feedback of the candidate token nodes.

[0086] Optionally, edge weight .in, and For node semantic representation, Indicates the strength of structured dependencies. Indicates the intensity of the location proximity. Indicates the dependency strength of the tool call chain. This indicates the strength of reliance on manual feedback or historical ledger confirmation. For normalization function, , , , , For weighted weights.

[0087] Optionally, the validity period of a Token node's relationship is determined by a combination of the node's own validity, the decay difference between the edge establishment timestamp and the current time, the node's lease expiration status, and the historical reference frequency, so that the Token value graph can dynamically reflect the current validity and credibility of the edge relationship in the time dimension.

[0088] The beneficial technical effects achieved by steps S2.1 to S2.2 are as follows: by assigning multi-dimensional attributes to token nodes and establishing edge relationships with weights and timeliness, unstructured text is transformed into a computable and evolvable graph structure, which helps to accurately measure token value, risk propagation path and reuse potential.

[0089] Step S2.3: Construct a directed weighted token value graph based on the node attributes of each candidate token node, the edge relationships between candidate token nodes, edge weights, and relationship validity periods.

[0090] Optionally, the edge weights are determined based on the strength of the relationships between candidate token nodes. The strength of the relationships is obtained by normalizing at least one of semantic similarity, structured dependency strength, location proximity strength, tool call chain dependency strength, and feedback dependency strength.

[0091] This invention constructs token nodes and their relationships into a directed weighted heterogeneous graph, namely a token value graph. .

[0092] in, This is a set of Token nodes that contains each candidate Token node. Let be the set of edges. This is a set of relation types. For any edge... It can be represented as .

[0093] in, Indicates the relation type, Represents edge weight, Indicates the time limit of a relationship.

[0094] For example, the user input "Please delete test orders from before 2024 in the database" can generate task tokens, action tokens, database object tokens, time condition tokens, and high-risk write operation tokens. The table structure fields returned by the tool, the delete statement output by the SQL generator agent, the write operation risks identified by the risk control module, and manual approval opinions will all establish references, constraints, risk propagation, and manual correction edges with these tokens. In this way, the system not only knows that "this call is risky," but also knows which action token, table name token, and time condition token the risk comes from, and can reuse this risk identification experience in subsequent tasks.

[0095] The beneficial technical effects achieved by step S2.3 are as follows: This step integrates the Token nodes and their multidimensional relationships into a directed weighted heterogeneous graph, enabling semantic, risk, dependency and timeliness information to be co-expressed in a unified graph structure, providing a computable structured decision-making basis for Token-level value propagation, risk tracking and computing power routing.

[0096] In one embodiment, step S3 includes steps S3.1, S3.2, S3.3, and S3.4. These are described in detail below.

[0097] Step S3.1: For each set of first token nodes, obtain the comprehensive value score of the set of first token nodes based on the token value map and historical computing power ledger.

[0098] The first token node set includes at least one candidate token node. In some embodiments, the first token node set includes only one candidate token node, and obtaining a certain indicator of the first token node set means obtaining the indicator of a single candidate token node. In some embodiments, the first token node set includes multiple candidate token nodes, and obtaining a certain indicator of the first token node set can be an indicator of the entire first token node set, or it can be calculated based on the indicator of each candidate token node in the first token node set, such as by performing average, weighted, median, highest, lowest value, or other calculation methods, thereby obtaining the indicator of the first token node set. Optionally, the multiple candidate token nodes included in the first token node set can be multiple random candidate token nodes, or multiple candidate token nodes with correlation or dependency; this application does not impose any restrictions on this.

[0099] In one embodiment, step S3.1 includes steps S3.1.1, S3.1.2, S3.1.3, and S3.1.4, which will be described in detail below.

[0100] Step S3.1.1: Based on the Token value map and historical computing power ledger, obtain the weighted values ​​of the task relevance, historical contribution, reuse probability, timeliness score, reuse probability, confidence and redundancy of the first Token node set to the current task result, and obtain the basic value score.

[0101] The token value scoring mechanism of this application is described below. The token value is not simply determined by text length or frequency of occurrence, but rather by its marginal contribution to the current task outcome, risk impact, reuse benefits, timeliness, and confidence level. The first token node set includes nodes... Let's take an example to illustrate, and set a node. The basic value score is , can be represented as .

[0102] in, Indicates task relevance. Indicates historical contribution. Indicates timeliness, Indicates the reuse probability. Indicates the confidence level. In other implementations, this indicates redundancy. It can also represent compressibility. , , , , , This indicates the weighted weight.

[0103] Step S3.1.2: Obtain the centrality score of the first Token node set in the Token value graph by weighting it according to at least one of the PageRank, betweenness centrality score, task path coverage or key constraint coverage of the first Token node set.

[0104] The centrality of a token node in the token value graph can be evaluated using metrics such as PageRank, betweenness centrality, task path coverage, or key constraint coverage.

[0105] PageRank is a graph centrality metric. The higher a Token node is referenced by many other high-value Token nodes (e.g., by multiple task steps, multiple tool results, or multiple constraints), the higher its PageRank value will be. The system will then identify it as a key Token node and allocate it with a stronger model or higher validation resources.

[0106] Step S3.1.3: Obtain the graph propagation value score of the first Token node set based on the basic value score, edge weight, and centrality score.

[0107] In one embodiment, step S3.1.3 includes steps S3.1.3.1, S3.1.3.2, and S3.1.3.3, which will be described in detail below.

[0108] Step S3.1.3.1: Determine the edge set of the first Token node set.

[0109] Step S3.1.3.2: Sum the product of the basic value score and the edge weight of the Token node associated with the edge set to obtain the sum value.

[0110] Step S3.1.3.3: Weight the summation value, the basic value score and the centrality score of the first Token node set to obtain the graph propagation value score of the first Token node set.

[0111] In one embodiment, graph propagation value also needs to be considered for nodes with strong relationships to high-value nodes.

[0112] node The graph's dissemination value score can be represented as .

[0113] in, Represents a node Central score in the token value graph , Indicates weighted weights, nodes The basic value score is ,node ,node These are two Token nodes connected in the edge set.

[0114] For example, if a token itself seems ordinary, but it connects multiple task constraints or multiple tool dependencies, its graph propagation value will be increased.

[0115] Step S3.1.4: Obtain the risk-converted returns for multiple types of risks, and obtain the comprehensive value score based on the weighted average of the risk-converted returns for multiple types of risks and the sum of the graph propagation value score.

[0116] Multiple types of risk-reduction benefits include the following: the reduction in expected risk loss through verification or approval of the first token node set; the reuse benefits obtained by caching the first token node set; and the benefits of storing the first token node set for multi-agent processes.

[0117] To incorporate risk into value assessment, this invention introduces risk-discounted returns. For high-risk tokens, if investing more computing power in verification can significantly reduce erroneous calls or compliance incidents, then the token has a high security computing power value. Optionally, a comprehensive value score can be defined as follows: .

[0118] in, This indicates the expected risk of loss that can be reduced through verification or approval. This indicates the subsequent reuse benefits that can be obtained through caching or accumulating data. This indicates that retaining the token improves the stability of multi-agent processes. , , This indicates the weighted weight.

[0119] The beneficial technical effects achieved by step S3.1 are as follows: Based on the topological relationship of the Token value graph and the feedback of the historical ledger, the comprehensive score is calculated by integrating the graph propagation value and historical contribution, so that the value assessment has both the globality of the graph structure and the reliability of historical experience, supporting accurate computing power routing decisions.

[0120] Step S3.2: Obtain the risk level, redundancy, centrality score of the first Token node set in the Token value graph, and the proportion of the first Token node set covering the path from the task objective to the tool result, evidence, or final output.

[0121] In one embodiment, the risk level of the first token node set can be obtained based on the node attributes of each candidate token node in the first token node set; and a redundancy assessment can be performed on the first token node set to obtain the redundancy degree.

[0122] For details on obtaining the centrality score, please refer to the relevant content in step S3.1, which will not be repeated here.

[0123] Step S3.3: Obtain the criticality of the first Token node set based on its comprehensive value score, risk level, centrality score, path ratio, and redundancy.

[0124] In one embodiment, step S3.3 includes steps S3.3.1, S3.3.2, and S3.3.3, which will be described in detail below.

[0125] Step S3.3.1: Obtain the weighted values ​​of the comprehensive value score, risk level, centrality score, and path ratio of the first Token node set.

[0126] Step S3.3.2: Obtain the product of the redundancy of the first Token node set and its own weight.

[0127] Step S3.3.3: The difference between the weighted value and the product is used as the key value of the first Token node set.

[0128] The beneficial technical effects achieved by steps S3.2 and S3.3 are as follows: By integrating multi-dimensional indicators such as comprehensive value, risk, centrality, path coverage and redundancy to evaluate criticality, the identification of key tokens combines value, risk and structural importance, and ensures that computing power is accurately allocated to tokens with the highest impact.

[0129] Step S3.4: Identify multiple key Token nodes in the Token value graph based on the keyness of each first Token node set.

[0130] In one embodiment, step S3.4 includes steps S3.4.1 and S3.4.2, which will be described in detail below.

[0131] Step S3.4.1: Obtain the graph expansion radius of the first Token node set based on the node attributes of each Token node in the first Token node set.

[0132] Step S3.4.2: Based on the graph expansion radius, expand the first set of Token nodes with a criticality higher than the preset criticality threshold in the Token value graph to obtain multiple critical Token nodes.

[0133] The following section further describes the identification of key token nodes in this application. After constructing the token value graph, it is necessary to identify key token nodes for which significant computing power should be invested. In one embodiment, a combined score is obtained based on node value (such as comprehensive value score), risk score, graph centrality score, and task path coverage to determine keyness. .in, This indicates the proportion of the path that the node covers from the task objective to the tool's results, evidence, or final output; , , , , For weights.

[0134] Furthermore, the top-K nodes with the highest criticality can be selected, and their neighborhoods can be expanded to form a key token subgraph. The formula can be expressed as follows: The candidate Token nodes in the key Token subgraph are then used as key Token nodes, thus obtaining the key Token node set.

[0135] in, The graph expansion radius is adjusted. For high-risk nodes, the expansion radius can be increased to preserve the source of risk and downstream impact chains. For highly reusable nodes, summary edges and tool template edges can be prioritized for expansion. For conflicting nodes, both conflicting parties and their evidence nodes can be preserved during expansion.

[0136] This mechanism avoids the loss of context caused by traditional summarization strategies that retain isolated high-scoring tokens. For example, in contract review, the statement "the penalty for breach of contract is 1 million yuan" should not only retain the numerical token, but also the breach conditions, applicable parties, contract version, user review questions, and sources of evidence; otherwise, the meaning of the numerical token is incomplete.

[0137] The beneficial technical effects achieved by step S3.4 are: it can accurately identify key token nodes worth investing computing power in from a large number of token nodes, retain key tokens, avoid writing low-value content into long-term memory, reduce subsequent retrieval noise, and improve the accuracy and efficiency of token distribution.

[0138] In one embodiment, step S4 includes steps S4.1, S4.2, S4.3, S4.4, and S4.5, which will be described in detail below.

[0139] Step S4.1: Obtain multiple initial Token computing power routing policies. The Token computing power routing policies are used to indicate at least one of the models, tools, caches and verification resources to be allocated.

[0140] The token computing power routing strategy of this application is described below. The computing power routing in this invention refers to selecting different resource paths for different token sets based on the token value graph and computing power ledger. A typical routing strategy is as follows: Small model routing: Low-risk, low-complexity, and well-structured token sets are processed by small models or rule engines, such as formatting, classification, simple extraction, and low-value summaries.

[0141] Large model routing: High-value token sets that require complex reasoning or cross-evidence integration are handled by stronger models, such as task planning, interpretation of key constraints, complex code modifications, and contract risk analysis.

[0142] Expert Model Routing: Token sets with professional domain semantic types are routed to expert models or expert agents in fields such as law, code, finance, data analysis, and security auditing.

[0143] Tool routing: Factual, time-sensitive, or external state-dependent tokens trigger retrieval, databases, file systems, code interpreters, or business APIs.

[0144] Cache routing: High reusability and low expiration risk. Tokens enter the cache layer, and subsequent requests can directly reuse their key-value pairs, digests, or tool templates.

[0145] Verification routes: High-risk or high-impact tokens trigger verification models, cross-models, rule verification, unit testing, sandbox execution, or manual approval.

[0146] Compressed routing: Low- to medium-value historical tokens enter the compressed agent, which outputs a structured digest and retains backtracking edges.

[0147] Discard routes: Tokens that are low-value, low-risk, low-reusability, irrelevant to the task, or highly redundant will not be included in subsequent contexts.

[0148] In a preferred embodiment, the system maintains multiple computing power pools, including a low-cost small model pool, a high-precision large model pool, a long-context model pool, an expert model pool, a code sandbox pool, a tool execution pool, a key-value cache (KV cache) high-speed memory pool, a KV cache extended storage pool, and a manual approval queue. Token routing results are mapped to scheduling requests to these resource pools. In scenarios with limited computing power, the system prioritizes high-value, high-risk tokens, strongly constrained tokens, and highly reusable tokens, while reducing the inference budget for low-value generative tokens.

[0149] Step S4.2: For each set of second token nodes, determine the candidate token computing power routing strategy corresponding to the set of second token nodes based on the preset action constraints and the initial token computing power routing strategy.

[0150] In this embodiment of the invention, based on the multi-agent orchestration of token value, the Planner Agent first receives the token value graph and the key token set, and then determines the task decomposition method. That is, task decomposition is not simply semantic planning, but value-driven computational planning. The "Planner Agent" of this invention is used to decompose complex user tasks into a sequence of executable subtasks, and allocate appropriate Executor Agents, Tools, or resources to each subtask.

[0151] Let there be a set of optional actions. for:

[0152] in, These are the multiple actions associated with small model routing, large model routing, expert model routing, tool routing, cached routing, compressed routing, verification routing, sandbox routing, manual operation routing, and discarded routing.

[0153] Action constraints include at least one of the following: expected task quality constraints, computing power cost constraints, revenue constraints, latency constraints, GPU memory usage constraints, expected error loss constraints, risk constraints, and allowed tool permission set constraints. In one embodiment, the system selects an action for each Token set, which can be expressed as a constraint optimization problem:

[0154] The system aims to find an optimal computing power routing strategy π that maximizes the expected task benefits generated by all token sets after being allocated the corresponding models, tools, caches, and verification resources, while minimizing computing power costs, latency, GPU / cache usage, and error risks. Indicates: A strategy is applied to the token set S. The resulting task benefits, quality benefits, or overall utility. , , , For weights.

[0155] According to the action constraints, the following must be satisfied:

[0156] Where Q represents the expected task quality, C represents the total computing cost, L represents the total latency, M represents the GPU memory usage, E represents the expected error penalty, and B represents the budget. For time delay constraints, As the upper limit of risk, This is the set of permissions allowed for certain tools.

[0157] In engineering implementation, the above optimizations do not require a globally precise solution. Greedy algorithms, hierarchical routing, reinforcement learning, contextual bandit, hybrid rule-based and learning strategies, or offline-trained policy networks can be employed. The key is that the policy input is not the entire request, but rather the token value graph and token computing power ledger statistics. The policy output is not a single model selection, but rather the configuration of models, tools, caching, compression, and verification for different token sets.

[0158] The beneficial technical effects achieved by steps S4.1 and S4.2 are as follows: By filtering matching computing power routing strategies through preset action constraints, it ensures that each Token set obtains a compliant and feasible computing power routing scheme, providing a safe and effective candidate action space for subsequent optimal strategy selection.

[0159] Step S4.3: Optimize the candidate token computing power routing strategy based on the token value map and historical computing power ledger to obtain the target token computing power routing strategy.

[0160] In one embodiment, step S4.3 includes steps S4.3.1, S4.3.2, and S4.3.3, which will be described in detail below.

[0161] Step S4.3.1: Based on the Token value map and historical computing power ledger, obtain the target computing power return ratio and target risk score of the second Token node set.

[0162] In one embodiment, step S4.3.1 includes steps S4.3.1.1, S4.3.1.2, and S4.3.1.3, which will be described in detail below.

[0163] Step S4.3.1.1: Based on the Token value graph and historical computing power ledger, calculate the unit computing power revenue ratio of each candidate Token node in the second Token node set, and score the graph relationship collaboration of the second Token node set.

[0164] In one embodiment, step S4.3.1.1 includes steps S4.3.1.1.1, S4.3.1.1.2, S4.3.1.1.3, S4.3.1.1.4, and S4.3.1.1.5, which will be described in detail below.

[0165] Step S4.3.1.1.1: Based on the Token value map and historical computing power ledger, calculate the weighted values ​​of the quality improvement score, risk reduction score and reuse revenue of each candidate Token node in the second Token node set under the standard strategy, and obtain the target revenue of each candidate Token node in the second Token node set.

[0166] Step S4.3.1.1.2: Calculate the weighted value of the model computation cost, tool cost, memory cost and latency cost of each candidate Token node in the second Token node set under the standard Token computing power routing strategy, and obtain the target cost of each candidate Token node in the second Token node set.

[0167] Step S4.3.1.1.3: Based on the ratio of target revenue to target cost, obtain the unit computing power revenue ratio of each candidate Token node in the second Token node set.

[0168] Step S4.3.1.1.4: Obtain the graph continuity score of the second Token node set according to the preset graph continuity constraints.

[0169] Step S4.3.1.1.5: Obtain the sum of the target revenue of each candidate Token node in the second Token node set, and divide the sum of this sum and the sum of the graph coherence score by the target cost of the second Token node set to obtain the graph relationship collaboration score.

[0170] The target cost of the second Token node set is the sum of the target costs of each candidate Token node in the second Token node set.

[0171] In one embodiment, the present invention further defines a Token computing power benefit ratio, used to determine whether a particular Token or set of Tokens is worth allocating higher computing power to. Let's assume a Token node... The expected quality improvement when using strategy a is The expected reduction in risk loss is The expected reuse revenue is The corresponding model computation cost, tool cost, graphics memory cost, and latency cost are respectively , , , The unit computing power revenue ratio can then be defined as:

[0172] in, To prevent constants with a denominator of zero, and , For weights.

[0173] Taking the second set of token nodes as the token set S as an example, we can consider the graph relationship coordination within the set:

[0174] in, The graph coherence score represents the set of tokens, such as whether key constraints are fully covered, whether the chain of evidence is closed, and whether the chain of risks is complete. This represents the sum or weighted value of the model computation cost, tooling cost, memory cost, and latency cost for each token node in the token set. This design avoids the system from selecting only scattered high-scoring tokens while ignoring the constraint that tokens must be retained in groups.

[0175] Step S4.3.1.2: Based on the unit computing power revenue ratio of each candidate Token node in the second Token node set and the graph relationship collaborative scoring of the second Token node set, obtain the target computing power revenue ratio.

[0176] In one embodiment, the target computing power revenue ratio is obtained by weighting the unit computing power revenue ratio of each candidate Token node in the second Token node set and the graph relationship collaborative score of the second Token node set.

[0177] In one embodiment, a preset function is calculated based on the unit computing power revenue ratio of each candidate Token node in the second Token node set and the graph relationship collaborative scoring of the second Token node set to obtain the target computing power revenue ratio.

[0178] Step S4.3.1.3: Based on the Token value graph and historical computing power ledger, perform risk propagation calculation on the second Token node set to obtain the target risk score.

[0179] Risk propagation can be achieved through probability propagation, maximum path propagation, graph neural network propagation, rule engine propagation, or security policy matrix.

[0180] In one embodiment, step S4.3.1.3 includes steps S4.3.1.3.1 and S4.3.1.3.2, which will be described in detail below.

[0181] Step S4.3.1.3.1: Determine the edge set and initial risk score of the second Token node set.

[0182] Step S4.3.1.3.2: Calculate the target risk propagation formula based on the initial risk score, the risk propagation coefficient of the Token nodes associated with the edge set, the edge weight, and the candidate risk score of the previous time step, and obtain the target risk score of the second Token node set at the current time step.

[0183] The following describes the token risk scoring and risk propagation mechanism of this application. This invention classifies risk tokens as a type of token requiring special computing power upgrades. Risk types include, but are not limited to: amount tokens, permission tokens, privacy tokens, identity tokens, contract term tokens, medical or financial advice tokens, code execution tokens, file path tokens, database write operation tokens, external API parameter tokens, credential tokens, cross-tenant data tokens, user-defined preference tokens that are explicitly prohibited from being disclosed, and tokens that may trigger security policy conflicts.

[0184] Set up a Token node The initial risk score is (It is a risk classifier used to identify factors including amount, Structured Query Language (SQL), Shell, and identity identifiers), and risk propagates along the edges of the graph. Shell is the command-line interface for users to interact with the operating system kernel.

[0185] In one embodiment, a preferred formula for the propagation of target risk is as follows:

[0186] in, This represents the risk propagation coefficient corresponding to the edge type; This represents the candidate risk score at the previous moment. This represents the target risk score at the current moment.

[0187] For example, tool-dependent edges and parameter-referenced edges have higher propagation coefficients than ordinary semantically similar edges; manually confirmed edges can reduce propagation risk; conflict edges can increase the risk weight that needs to be verified. In one embodiment, if there are many nodes and the risk of collateral propagation under complex chains is required, a risk attenuation coefficient needs to be introduced.

[0188] The beneficial technical effects achieved by step S4.3.1 are: integrating the value graph topology relationship with historical ledger feedback, comprehensively evaluating the computing power return ratio and risk score of the token set, providing a quantitative basis for differentiated routing, and ensuring that high-yield, high-risk tokens receive matching computing power investment.

[0189] Step S4.3.2: Obtain the reuse probability of the second Token node set based on the historical computing power ledger.

[0190] In one embodiment, step S4.3.2 includes steps S4.3.2.1 and S4.3.2.2, which will be described in detail below.

[0191] Step S4.3.2.1: Based on the historical computing power ledger, calculate the weighted values ​​of the historical occurrence frequency, reuse intensity of the same tenant or project, degree of templating, reuse intensity of tool definition or tool result, historical contribution and expiration risk of the second Token node set.

[0192] Step S4.3.2.2: Normalize the weighted value to obtain the reuse probability of the second Token node set.

[0193] This invention expands cache admission from "recent use" or "same prefix" to "whether the token has calculable reuse benefits." The system is a token node. Calculate the reuse probability :

[0194] in, Indicates the frequency of occurrence in history, Indicates the reuse intensity within the same tenant or project. Indicates the degree of templateization. Indicates the reuse strength of tool definitions or tool results. Indicates historical contribution. This indicates a risk of expiration. , , , , , This indicates the weighted weight.

[0195] The beneficial technical effect achieved by step S4.3.2 is that by accurately calculating the reuse probability, highly reused tokens are given priority to obtain cache resources, thereby reducing the computational power consumption of repeated inference.

[0196] Step S4.3.3: Optimize the candidate Token computing power routing strategy based on the target computing power benefit ratio, target risk score and reuse probability to obtain the target Token computing power routing strategy.

[0197] In one embodiment, step S4.3.3 includes steps S4.3.3.1, S4.3.3.2, and S4.3.3.3, which will be described in detail below.

[0198] Step S4.3.3.1: Adjust the computing power to be allocated to the second Token node set according to the target computing power benefit ratio, so as to optimize the candidate Token computing power routing strategy.

[0199] Step S4.3.3.2: In response to the target risk score being greater than the preset risk score threshold, optimize the candidate token computing power routing strategy based on at least one of the following: risk type, risk level, risk propagation scope, and task context.

[0200] When the target risk score of a certain token set exceeds a threshold, the system does not simply reject the task, but selects an appropriate computing power upgrade strategy based on the risk type. For example, for code execution tokens, the system can transfer the Executor Agent's code execution to a container sandbox and enable a read-only file system; for monetary tokens, the system can require cross-verification by multiple models and manual approval; for legal clause tokens, the system can call legal clause retrieval tools and expert models; for database write operation tokens, the system can first generate a dry-run query and require approval; for privacy tokens, the system can perform anonymization, permission verification, and tenant isolation.

[0201] The following section further describes the security computing power upgrade driven by token risk in this application, thereby optimizing the token computing power routing strategy. This invention emphasizes that high-risk tokens should not use the same computing power path as ordinary tokens. In one embodiment, the system can also determine the security computing power upgrade strategy based on the risk type, risk propagation scope, and task context. The upgrade strategy includes, but is not limited to: For tokens related to permissions, amounts, payments, deletions, submissions, signings, and external writes, trigger secondary confirmation, manual approval, or strategy engine approval. For tokens related to code execution, shell commands, file writing, and network access, sandbox execution, permission closure, file system snapshots, and output verification are triggered. Tokens related to legal terms, contractual responsibilities, and compliance requirements trigger professional search tools, expert models, and cross-validation of multiple models. For tokens containing privacy information, identity identifiers, keys, accounts, and customer data, trigger de-identification, tenant permission verification, minimal context exposure, and audit logging; For the external API parameter Token, trigger parameter schema validation, dry-run call, idempotency check, and rollback contingency plan generation.

[0202] Schema is a formal definition of data structure, format, and constraints. In this invention, it is used for format validation of external API parameters and is also an important object for the accumulation of highly reusable tokens into long-term skills. Dry-Run is a pre-execution mechanism that simulates operations but does not actually change the state. In this invention, it is used for pre-checking and approval of database write operations and external API calls, ensuring that high-risk tokens undergo security verification before actually consuming computing power.

[0203] In a preferred embodiment, the security upgrade intensity is jointly determined by the risk score and the value score. The security upgrade intensity can also be understood as the risk level, and can be expressed as: .

[0204] in, This indicates the potential risks associated with downstream tool usage, output conclusions, or external actions that may be affected by this token. This indicates that a certain level of confidence has been established. , , , Indicates the weighted weight. () represents a function that quantizes parameters into levels. Once a high level is reached, the system automatically prohibits low-privilege agents from directly processing the token; it must be approved through a high-level model, sandbox, or manual review.

[0205] Step S4.3.3.3: Determine whether the second Token node set should be cached based on the reuse probability of the second Token node set, so as to optimize the candidate Token computing power routing strategy.

[0206] In one embodiment, cache accumulation can adopt KV cache, prompt prefix cache, semantic cache, long-term memory, retrieval index, skill summary, tool template, code snippet template or tenant-level shared knowledge base.

[0207] Step S4.3.3.3 includes: steps S4.3.3.3.1, S4.3.3.3.2, and S4.3.3.3.3, which will be explained in detail below.

[0208] Step S4.3.3.3.1: Obtain the cache cost by summing the storage cost of the second Token node set with the opportunity cost caused by crowding out other caches.

[0209] Step S4.3.3.3.2: Obtain the expected reuse value by multiplying the reuse probability of the second Token node set by the comprehensive value score.

[0210] Step S4.3.3.3.3: Based on the ratio of expected reuse value to caching cost and its relationship with a preset ratio threshold, determine whether the second Token node set should be cached in order to optimize the candidate Token computing power routing strategy.

[0211] The following section introduces the Token reuse probability-driven caching and skill accumulation of this invention.

[0212] The cache admission rule can be expressed as:

[0213] in, To save costs, The opportunity cost incurred by crowding out other caches. This represents a preset ratio threshold. In this embodiment, if the ratio of a token's expected reuse value to its caching cost is greater than the ratio threshold, it indicates that the ratio is high enough and caching is required; otherwise, it is not cached. The caching admission rule is used to determine whether a token should be cached for the first time.

[0214] For tokens that meet the admission criteria, the system can choose different storage methods: original token prefix caching, KVcache storage, summary memory, skill summary, plugin context, tool template, retrieval index, or tenant-level knowledge fragments. For tokens with high risk but high reusability, the system can use de-identified caching, encrypted caching, tenant-isolated caching, or only caching the structure template without caching sensitive content.

[0215] This mechanism enables intelligent computing cloud platforms to transform highly reusable tokens into auditable computing power assets. For example, code standards, API documentation, tool schemas, review rules, and user preferences for the same project within an enterprise can be accumulated as long-term skills; while one-off tool logs, expired search results, and low-contribution conversations do not repeatedly occupy expensive context.

[0216] In one embodiment, step S4.3.3 further includes steps S4.3.3.4 and S4.3.3.5, which will be described in detail below.

[0217] Step S4.3.3.4: For each set of second token nodes, in response to determining the cached set of second token nodes, obtain the lease value of the set of second token nodes based on the reuse probability, comprehensive value score, memory cost, expiration risk and privacy risk of the set of second token nodes.

[0218] Step S4.3.3.5: Perform lifecycle management on the second Token node set based on the lease value and lease term of the second Token node set.

[0219] The following describes the Token computing power lease and lifecycle management of this application. To avoid highly reused tokens occupying cache and memory indefinitely, this invention introduces a Token computing power lease mechanism. Each cached or stored Token node has a lease term, lease value, lease renewal conditions, and lease revocation conditions. Let the Token node... Lease value for:

[0220] Where t represents time. This indicates the cost of video memory or cache. This indicates a risk of expiration. These three factors indicate privacy risks and are negative indicators for calculating lease value. , , As weight.

[0221] The lease value is used to determine whether a token should be retained after it has been cached. When the value exceeds a threshold, the system renews the cache or memory; when it falls below the threshold, the system performs degradation, compression, desensitization, or deletion. For stable content such as enterprise knowledge and tool schemas, the lease can be longer; for search results, temporary logs, and expired business data, the lease is shorter; for privacy tokens, the lease is strictly constrained by permissions and compliance policies.

[0222] This mechanism transforms cache and long-term memory from simple "long-term existence after writing" black boxes into assets that can be dynamically managed based on changes in computing power returns and risks.

[0223] The beneficial technical effects achieved by step S4.3 are as follows: the candidate routing strategy is jointly optimized by combining the computing power return ratio, risk score and reuse probability to ensure that high-yield and high-risk tokens receive sufficient computing power, and high-reusability tokens are cached first, thereby maximizing the return on computing power input, retaining key tokens, avoiding writing low-value content into long-term memory, reducing subsequent retrieval noise, and improving the accuracy and efficiency of token routing.

[0224] Step S4.4: Perform graph constraint context assembly and compression based on the Token value graph.

[0225] In one embodiment, step S4.4 further includes steps S4.4.1, S4.4.2, S4.4.3, and S4.4.4, which will be described in detail below.

[0226] Step S4.4.1: Obtain the comprehensive value score, graph coherence score, and redundancy of multiple third token node sets, where each third token node set includes at least one key token node.

[0227] Step S4.4.2: Based on the comprehensive value score, graph coherence score, and redundancy of the third Token node set, obtain the model context requirements of the third Token node set.

[0228] Step S4.4.3: Based on the preset model context budget and the model context requirements of each third token node set, determine the target token node set to be put into the context from the third token node set.

[0229] Step S4.4.4: For key token nodes and / or candidate token nodes that are not included in the context, perform compression based on the comprehensive value score and target risk score of the key token nodes and / or candidate token nodes.

[0230] The following describes the graph-constrained context assembly and compression method of this application. In multi-agent tasks, the context window is one of the most expensive resources. This invention treats context assembly as a budget selection problem on a token value graph, rather than simply truncating the most recent round. For a given model context budget... The system selects the set of target Token nodes to be placed into the context as Token set C:

[0231] The following constraints must be met:

[0232] in, For the length of the token, The graph is scored for coherence, with Red representing redundancy. , The weight is used as the basis. For tokens not retained in the original text, the system determines the compression method based on their value and risk: high-value, high-risk tokens are not compressed or only de-identified; medium-value tokens are compressed into structured summaries; low-value tokens are discarded; and highly reusable tokens are separately stored as long-term memory or skill summaries.

[0233] In a preferred embodiment, the compression result is also written back to the Token value graph. A summary summarization edge is established between the original Token node and the summary Token node. The ledger records the input Token, output summary, compression model, cost, and contribution of subsequent tasks for this compression operation. If a subsequent task discovers that the summary causes an error, the system can backtrack along the summary summarization edge to the original Token and reduce the confidence of the compression strategy for similar Token types.

[0234] The beneficial technical effects achieved by step S4.4 are as follows: Based on the Token value graph structure, high-value Tokens are retained first under the context budget constraint, while low-value historical Tokens are compressed or removed. This ensures that key information is not lost while reducing memory usage, improving inference efficiency, avoiding the waste of computing power caused by invalid pre-filling, duplicate tool calls, invalid caching and over-validation, and providing support for subsequent computing power routing.

[0235] Step S4.5: Perform token routing on the second token node set according to the target token computing power routing strategy to obtain the execution result of the user request.

[0236] Tokens are routed according to the target token computing power routing strategy, allocating differentiated computing power resources to the second token node set: high-risk token sets trigger sandbox execution, multi-model cross-validation, or manual approval; highly reusable token sets are entered into the KV Cache, long-term memory, or skill summary storage; low-value token sets are structured compressed or directly removed. The assembled context inputs the model for inference and outputs the final execution result. The resource consumption and token mapping relationship throughout the process are synchronously written to the token computing power ledger.

[0237] The beneficial technical effects achieved by step S4.5 are as follows: By routing the second token node set according to the target token computing power routing strategy, token-level computing power can be accurately allocated, high-impact tokens can obtain sufficient inference resources, and low-value tokens can be compressed or eliminated, thereby improving task quality while reducing computing power costs and latency.

[0238] In one embodiment, the method further includes step S5, updating the historical computing power ledger according to the execution process of token distribution.

[0239] The historical computing power ledger records each runtime action including at least one of the following: a pipeline identifier; the set of token nodes associated with this action; an agent or module identifier; model specifications or tool specifications; the number of input and output tokens; the number of inference layers or inference budget; GPU time, memory usage, batch queue waiting, and network communication overhead; cache saving, reading, hit, and eviction information; tool costs, sandbox costs, or external API costs; intermediate, final, or verification results of this token distribution action; records of errors, rollbacks, timeouts, security events, or manual interventions; and an estimate of the contribution of backfilling after the task is completed.

[0240] The historical computing power ledger, also known as the Token computing power ledger, is a crucial component of this invention. Its purpose is not simply to record the total cost of requests, but rather to record the input-output relationship between each runtime action and the Token set. A record in the ledger can be represented as... .

[0241] in, For serial number identification; This refers to the set of Token nodes involved in this action; For Agent or module identifier; For model specifications or tool specifications; For input / output token count, inference layer count, or inference budget; This includes GPU time, video memory usage, batch queue waiting, and network communication overhead. Save, read, hit, and eviction information for the KV cache or prompt word cache; Costs include tool costs, sandbox costs, or external API costs. This refers to the intermediate result, final result, or verification result of this action; Logs of errors, rollbacks, timeouts, security incidents, or human intervention; Estimate the contribution of backfilling after the task is completed.

[0242] In a preferred embodiment, the ledger establishes a multi-level index based on tenant, session, task, agent, token set, and resource type. At the tenant level, it can calculate the proportion of high-value tokens invested, the waste rate of low-value tokens, the approval rate of high-risk tokens, and the benefit of cache reuse for that tenant. At the agent level, it can calculate the success rate and cost of a particular agent when processing different token types. At the model level, it can calculate the unit benefit of a particular model for different token types. At the cache level, it can calculate the write cost, hit rate, and GPU time saved for a certain type of token.

[0243] Unlike traditional logs, the Token computing power ledger can automatically answer the following questions: Which tokens consumed the most computing power but contributed the least in a failure? Which tool result tokens are frequently reused and worth accumulating as skills? Which risk tokens frequently trigger manual approval and should the default verification be improved? Which historical memory tokens frequently enter the context but never affect the answer and should be compressed? Which user preference tokens continuously improve satisfaction in multiple tasks and should be retained in the long term?

[0244] The beneficial technical effect achieved by step S5 is to synchronously write the input-output relationship between the runtime actions and the Token set in the current execution trajectory into the historical computing power ledger, so that the ledger continuously accumulates Token-level input-output data, providing traceable experience for subsequent value assessment, routing optimization and cost accounting.

[0245] In one embodiment, it also includes: Step S6: Obtain the first output of the m-th sampling or evaluation of each Token node participating in the calculation, the second output after masking or downweighting nodes, and the result quality score.

[0246] Step S7: Based on the first output, the second output, and the result quality score, obtain the contribution of all Token nodes participating in the calculation.

[0247] Step S8: Update the parameters of the Token value evaluator based on the contribution level.

[0248] The following describes the token contribution feedback mechanism in this application. After the task is completed, the system needs to estimate the contribution of different tokens to the final result. Contributions can come from user ratings, manual modifications, tool success rates, unit test results, retrieval evidence matching, rollback counts, model self-evaluation, external evaluators, or business metrics. For token nodes... Contribution obtained from counterfactual attribution It can be approximated as:

[0249] Contribution is used to determine whether the final outcome would be better, worse, or essentially unchanged without the token; this is an approximate counterfactual contribution attribution. Contribution attribution can employ Shapley approximation, shading experiments, output reference chain analysis, tool result usage, manual position modification, unit test pass rates, user ratings, or business metric feedback. Shapley value, a fair allocation method in cooperative game theory, is used to calculate each participant's marginal contribution to the total revenue in a cooperative alliance, thereby achieving a fair distribution of revenue. The token value evaluator is used to assess the value of token nodes.

[0250] in, Score the quality of the results. For the output of the m-th sampling or evaluation, Indicates a hidden or downweighted node. The output is then M, representing the total number of runs. In engineering practice, approximation methods can be used to avoid rerunning the entire task each time. For example, contributions can be attributed based on output reference chains, tool result usage, manual modifications, error rollback paths, and evaluator feedback.

[0251] Subsequently, the system updates the parameters of the Token value evaluator:

[0252] in, For evaluator parameters, This represents the updated evaluator parameters. This represents the evaluator parameters before the update. For loss function, This represents the learning rate. For rule-based implementations, the historical contribution can also be updated using an exponential sliding mechanism as follows:

[0253] This indicates the historical contribution level before the update. This indicates the updated historical contribution level. If a certain type of token is repeatedly proven to have a high contribution, its default value increases; if a certain type of token repeatedly causes errors, rollbacks, or low-quality results, its risk score or verification strength increases; if a certain type of token is cached and not hit for a long time, its reuse probability decreases; if a certain type of compressed digest causes the loss of key constraints, the system increases the priority of preserving the original text of that type of token.

[0254] The beneficial technical effects achieved by steps S6 to S8 are as follows: the value evaluator parameters are updated based on the token contribution, which increases the weight of high-contribution tokens and decreases the weight of low-contribution tokens. The system continuously learns "which tokens are worth investing computing power in", thereby achieving closed-loop optimization and continuous evolution of the scheduling strategy.

[0255] The following describes the ledger-driven multi-tenant computing power governance of this invention. In intelligent computing cloud platforms, different tenants have different budgets, service levels, data isolation requirements, and risk strategies. The Token computing power ledger of this invention can be used for tenant-level computing power governance. The system can generate Token asset reports for each tenant, including high-value Token input, low-value Token consumption, risk Token approval, cache hit revenue, tool call revenue, failure rollback costs, and manual intervention costs. Therefore, the platform can provide tenants with more granular computing power packages, such as "high-risk Token enhanced verification package," "high-reusability knowledge caching package," "code agent sandbox enhanced package," and "long context low-value compression package," etc.

[0256] When resources are scarce, the system can prioritize scheduling based on tenant service level and token value, rather than simply scheduling according to request arrival order or fixed tenant weights. High-value, high-risk tokens receive priority GPU and approval resources; low-value, generative tokens can be delayed or downgraded; cache writes of highly reusable tokens can be pre-warmed during off-peak periods; and long-term memory writes of low-contribution tokens can be rejected. This mechanism balances the company's core business operations in terms of computing power operation, cost accounting, resource elasticity, and service quality assurance.

[0257] In a preferred embodiment, the method of the present invention includes the following steps: receiving user requests and their associated context, including historical dialogues, long-term memory, tool definitions, external knowledge, user preferences, security policies, and tenant budgets; performing token segmentation, fragment merging, structural field parsing, and source alignment on multi-source information to form a set of token nodes; generating semantic type, task relevance, risk score, timeliness, confidence level, reuse probability, pre-computational cost, and audit identifier for each token node; constructing a token value graph based on relationships such as citations, constraints, causality, conflict, tool dependence, risk propagation, reuse, and human feedback; calculating the comprehensive value, risk propagation score, reuse benefit, and unit computing power benefit ratio of the tokens based on node attributes, graph structure, and historical computing power ledger; identifying key token sets and their neighborhood subgraphs, and determining token sets that must be retained in their original form, are compressible, can be discarded, require verification, require tool invocation, require caching, or require human approval.

[0258] The multi-agent computing power routing module selects the Planner, Executor, Tool Agent, Verifier, Security Agent, Memory Agent, and Cache Agent modules, along with their model specifications, context windows, tool permissions, and execution order, based on the key token set. During each Agent call, model inference, tool execution, cache saving, sandbox operation, model verification call, and manual approval, the corresponding token set and resource consumption are written to the token computing power ledger. The graph constraint context assembly module assembles model inputs according to token value and context budget, compressing or discarding low-value historical tokens, desensitizing or isolating risky tokens, and retaining the original text of high-value constraint tokens. After the task is completed, it collects data on result quality, user feedback, manual corrections, tool execution effects, error rollback, cache hits, latency, and cost. Based on result attribution, it updates token contribution, reuse probability, risk score, and value evaluator parameters. High-reusability, high-contribution tokens are stored in long-term memory, skill summaries, tool templates, or KV cache, while low-contribution or expired tokens are downgraded, compressed, or cleaned up.

[0259] Compared with the prior art, the present invention has at least the following beneficial effects: This invention enables the assetization of computing power at the token level. Instead of simply counting the total number of requested tokens, the system establishes value, risk, reuse, and cost fields for each token or token fragment, making tokens schedulable, accountable, and auditable computing power assets.

[0260] This invention can improve the accuracy of multi-agent resource allocation. The Planner Agent no longer simply breaks down the process into tasks, but determines the number of sub-Agents, model levels, context windows, tool permissions, verification strength, and manual approval conditions based on a set of key tokens.

[0261] This invention can reduce the cost of invalid context. The system can identify low-value historical tokens, redundant tool logs, and expired memories, compress or discard them, while retaining high-value constraints and evidence chains, thereby reducing pre-filling costs and memory usage.

[0262] This invention can improve the security of high-risk tasks. The system can locate specific risk tokens and trace the risk propagation path along the token value graph. For high-risk tokens such as permissions, amounts, legal terms, code execution, external API parameters, and privacy data, it can trigger high-precision model, sandbox, multi-model verification, or manual approval.

[0263] This invention can improve caching revenue. The system determines which tokens are worth caching or storing based on reuse probability, historical contribution, and computing power revenue ratio, rather than solely on recent use or identical prefixes, thereby improving the actual revenue of KV cache, Promptcache, long-term memory, and skill digest.

[0264] This invention supports a traceable computing power ledger. Each agent call, model inference, tool execution, cache storage, context compression, and manual feedback is associated with a token set, facilitating post-event auditing, cost attribution, tenant billing, and error review.

[0265] This invention can form a feedback learning closed loop. After a task is completed, the system updates the token value evaluator in reverse based on user feedback, manual corrections, tool execution effects, rollback counts, and result quality, enabling the platform to gradually learn which tokens are worth investing more computing power in.

[0266] This invention is suitable for the deployment of intelligent computing cloud services. The solution is naturally compatible with multiple GPU pools, multiple model pools, multiple tenants, multiple tools, and caching layers, and can use token-level value for computing power scheduling, service level control, cost optimization, and value-added service design.

[0267] In one embodiment, the present invention can implement token value graph computing power routing for enterprise code agents.

[0268] In an enterprise R&D scenario, a user request might be: "Please fix the issue of occasional duplicate refunds occurring during concurrent refunds in the order service, and submit a minimal patch." The system first reads the user request, relevant repository files, error logs, unit test failure information, historical commit records, coding style guidelines, and project preferences. The token segmentation module maps this information to task target tokens, concurrency tokens, refund tokens, duplicate refund tokens, file path tokens, error stack trace tokens, database table name tokens, historical patch tokens, coding style guide tokens, and test command tokens.

[0269] In the token value graph, "duplicate entries" establish evidence and constraint edges with exception stacks in error logs, database table fields, related test cases, and user task objectives; "patch commits" establish risk propagation edges with Git write operations, file paths, and permission tokens; and "concurrent refunds" establish causal edges with locking mechanisms, transaction boundaries, and idempotency tokens. System calculations revealed that error stacks, refund status fields, idempotent keys, transaction commit paths, and test commands are high-value tokens; Git commits, database write operations, and shell commands are high-risk tokens; and code style guidelines and project history patches are highly reusable tokens.

[0270] Based on this, the computing power routing module decides: high-value code tokens are handled by the code expert model; a small model first summarizes a large number of low-value logs; the tool agent retrieves relevant files and test cases; a container sandbox is launched for Shell command tokens; Git commit tokens are not actually committed yet, only patches are generated and await human confirmation; and project code style tokens are written into the tenant-level skill summary. Each file read, code generation, test execution, and patch generation is written to the token computing power ledger. After the task is completed, if the test passes and the patch is accepted by humans, the system will increase the historical contribution of tokens such as "idempotent key check," "concurrent refund test command," and "order service code style"; if some log fragments have never been referenced, their default value will be reduced and they will be compressed earlier in subsequent similar tasks.

[0271] This embodiment illustrates that the present invention does not simply send the entire code task to a large model, but rather treats the code, logs, tool results, risk actions, and historical specifications as token assets to differentiate them, thereby reducing costs and improving security.

[0272] In one embodiment, the present invention can achieve a high-risk token security upgrade for contract review agents.

[0273] In a contract review scenario, a user uploads a cooperation agreement and asks, "Please indicate the payment, default, and data usage terms that are most unfavorable to us." The system maps the contract text, user identity, company policies, historical review comments, and external regulatory search results into token nodes. Tokens related to amount, payment period, penalty rate, liability limitation, data usage scope, cross-border transfer, and automatic renewal are identified as high-value, high-risk tokens.

[0274] In the token value graph, the payment amount token establishes a constraint edge with payment terms, acceptance standards, and invoice terms; the penalty token establishes a causal edge with the default event, disclaimer clauses, and liability cap; and the data usage token establishes a risk propagation edge with the privacy policy, data subject, and cross-border transfer requirements. If the model finds a conflict between Article 8 of the contract, "Data may be used for product optimization," and the company policy, "Customer data shall not be used for training," the system establishes a conflict edge between the corresponding tokens and activates the conflict resolution agent.

[0275] The computational power routing module assigns general interpretative clauses to the medium-level model summary, payment, default, and data usage tokens to the legal expert model and retrieval tool, and key conclusions to the verification model for review. If a certain amount token or liability cap token has a significant impact, the system requires that the original token and clause location be referenced in the output, and that token set be added to the human review queue. After the task is completed, human lawyers modify some conclusions, and the system maps the modified locations back to the token value map, reducing the confidence of misinterpreted tokens and increasing the verification strength of similar clauses in subsequent tasks.

[0276] This embodiment illustrates that the present invention can treat key clauses in contract review as high-risk, high-value tokens, allowing secure computing power and human resources to be concentrated on clauses that truly affect the outcome, rather than applying the highest cost treatment to the entire contract.

[0277] In one embodiment, the present invention can enable the reuse and compression of tool result tokens of data analysis agents.

[0278] In a data analysis scenario, the user requests to "analyze the main reasons for the decline in gross profit margin in each region over the past six months and generate charts." The system integrates database schema, SQL query results, historical analysis templates, user preferences, and visualization specifications. Token nodes include indicator tokens, time range tokens, region tokens, product category tokens, SQL field tokens, query result tokens, outlier tokens, chart preference tokens, and interpretation conclusion tokens.

[0279] The system found that database schemas, indicator definitions, and chart specifications have a high probability of reuse within the same tenant, so they are consolidated into long-term tool templates and Prompt prefixes; specific query results have high timeliness but low long-term reuse value, so they are only cached within the current task; outlier tokens are highly correlated with the final conclusion, so the original text is retained and entered into the large model analysis; a large number of detailed row tokens are aggregated into statistical summaries by small models or rule modules, and do not directly enter the context of the large model.

[0280] In the ledger, the system records the field tokens, filter condition tokens, number of returned rows, tool latency, and final conclusion references involved in each SQL execution. If a SQL query result is referenced multiple times in the final conclusion, the historical contribution of the corresponding metric token and field token is increased; if certain detailed fields are frequently entered into queries but never affect the conclusion, they are not included in the initial context by default.

[0281] This embodiment illustrates that the present invention can process the massive amount of tokens returned by the tool in layers according to value, timeliness and reuse probability, avoiding mechanically piecing together database details into the context of a large model, while preserving a traceable chain of evidence.

[0282] In one embodiment, the present invention can realize a token computing power ledger for a multi-tenant intelligent computing cloud platform.

[0283] In a multi-tenant intelligent computing cloud platform, different enterprise customers simultaneously run code agents, knowledge-based Q&A agents, customer service agents, and compliance agents. The platform maintains a token computing power ledger for each tenant, recording the GPU time, cache space, tool costs, and number of manual approvals consumed by different token types. In one tenant's code agent tasks, highly reusable tokens mainly consist of repository specifications, build commands, and internal API documentation; in another tenant's compliance agent, high-value tokens mainly consist of policy clauses, approval opinions, and legal citations.

[0284] Based on the ledger, the platform discovered that the first tenant's code standardization token had a high reuse rate and significant cache hit benefits, so it provided them with a "project skills persistent caching" strategy. The second tenant's legal terms token was high-risk and frequently triggered manual approval, so it provided them with a "high-risk terms expert verification" strategy. When GPU resources are strained, the system downgrades low-value generative tokens to smaller models or delays their execution, while reserving large models and manual approval resources for high-risk, high-value tokens.

[0285] This embodiment illustrates that the present invention not only serves single tasks, but can also serve as the basis for resource governance and commercial billing of intelligent computing cloud platforms, enabling the platform to explain which token assets each tenant's computing power consumption comes from, and which optimization strategies have brought about cost savings.

[0286] In one embodiment, the present invention can achieve reverse learning of failure trajectory tokens.

[0287] In a complex research task, the agent made an incorrect conclusion by referencing outdated webpage content. After the task was completed, the system received human feedback: "This data is outdated; please refer to the latest announcement." The feedback learning module established a failure rollback edge and a human correction edge using the erroneous conclusion token, the outdated search result token, the search time token, the human correction token, and the final correct data token.

[0288] Subsequently, the system updated the value evaluator: reducing the timeliness and confidence level of expired retrieval tokens, increasing the risk score of data source tokens with dates, and raising the default priority of external retrieval and secondary verification in similar tasks. Later, when users inquire about tasks involving the latest data, the system automatically identifies time-sensitive tokens as high-risk, high-value tokens, invokes the real-time retrieval tool, and requires the data date to be included in the output.

[0289] This embodiment illustrates that the Token computing power ledger of the present invention not only records successful paths but also failure trajectories, enabling the system to learn from errors which Tokens need more verification and which old memories should be downgraded or eliminated.

[0290] In one embodiment, the present invention can achieve graph constraint compression of long context meeting minutes.

[0291] In enterprise meeting minutes scenarios, users require extracting decisions, responsible persons, and deadlines from meeting transcripts containing tens of thousands of tokens. Traditional solutions might directly input long texts into a long context model or summarize them segment by segment before aggregating. With this invention, the system first identifies speaker tokens, decision action tokens, responsible person tokens, date tokens, dispute tokens, veto tokens, and follow-up task tokens, and then establishes constraint edges and conflict edges.

[0292] For ordinary discussion tokens, the system compresses them; for tokens such as "final decision," "responsible to a certain department," "deadline," and "pending legal confirmation," the original text is retained; for contradictory time tokens, a conflict resolution agent is activated; for project and organization name tokens that appear multiple times, they are written into short-term task memory. The final context of the model is no longer a simple summary concatenation, but is assembled from key token subgraphs. The ledger records whether each decision token is referenced in the final minutes and the location of any manual modifications. If a person is found to have been wrongly assigned responsibility, the system finds the original speech token and summary token along the reference edge and lowers the confidence of the relevant summary strategy.

[0293] This embodiment illustrates that the present invention can compress long-context tasks using graph constraints, avoiding the loss of key responsibilities and date constraints in traditional summarization.

[0294] This invention can be used for text agents, as well as code agents, table agents, image understanding agents, multimodal agents, voice agents, robotic process automation agents, and enterprise automation workflows.

[0295] This invention can be deployed in private environments, public cloud environments, hybrid cloud environments, edge inference environments, or multi-cluster intelligent computing cloud platforms.

[0296] The core difference of this invention lies in the unified modeling, graphing, accounting, and routing of the Token as the minimum computing power asset in the operation of multiple agents.

[0297] Existing agent frameworks emphasize agents, tools, memory, and processes, but do not unify the task contribution, risk propagation, reuse benefits, and computing power input and output of tokens into a unified graph and ledger. This application unifies the task contribution, risk propagation, reuse benefits, and input and output of tokens into a token value graph and computing power ledger, realizing token-level computing power asset management and auditable scheduling.

[0298] Existing caching technologies emphasize prefix reuse, key-value block management, or cache eviction, but do not determine which tokens are worth caching based on multi-agent task contributions and risk propagation. This application determines the cache admission and retention form based on token reuse probability, historical contribution, and computing power benefit ratio, enabling cache resources to accurately serve high-reuse, high-contribution tokens, thereby improving cache hit rate and computing power saving effect.

[0299] Existing model routing emphasizes the trade-off between request-level cost and quality, but does not allocate different computing power to different token sets within the same request; this application dynamically allocates large models, small models, expert models or cache paths within the same request based on the unit computing power benefit ratio of different tokens, thereby achieving fine-grained and precise allocation of computing power.

[0300] Existing security measures like Guardrails emphasize overall input / output or tool call verification, but do not establish a propagation path for risk tokens across multiple agents and tools. This application establishes a risk token propagation mechanism along the value graph, accurately locating the source of risk and its downstream impact, triggering differentiated security upgrade strategies, and achieving traceable token-level risk control.

[0301] This invention uses a token value graph and a computing power ledger for multi-agent runtime computing power routing. At the multi-agent runtime level, user requests, historical dialogues, long-term memory, tool call results, sub-agent intermediate trajectories, external knowledge, risk warnings, user preferences, failure rollback records, and manual feedback are uniformly mapped to token nodes or token fragment nodes. Furthermore, a token value graph is constructed that includes reference relationships, constraint relationships, causal relationships, conflict relationships, tool dependency relationships, risk propagation relationships, and reuse relationships. Simultaneously, a token-compute ledger is maintained, recording the computing power input, memory usage, latency, tool cost, final contribution, and error risk for each model call, agent scheduling, tool execution, context compression, KV cache storage, code sandbox operation, model call verification, and manual approval record corresponding to the token set. The multi-agent scheduler no longer invokes models according to fixed procedures or simple request priorities. Instead, it dynamically allocates small models, large models, expert models, tool permissions, cache levels, verification strength, sandbox resources, and manual approval resources based on the token's task contribution, risk level, reuse probability, timeliness, confidence level, and unit computing power benefit ratio. This solution enables token-level computing power assetization, agent runtime auditability, risk token security upgrades, reuse token skill accumulation, and closed-loop optimization of computing power input and output. It is suitable for intelligent computing cloud platforms, large model agent platforms, enterprise-level knowledge assistants, code agents, data analysis agents, compliance review agents, and multi-tenant computing power operation systems.

[0302] This invention implements computing power routing during multi-agent runtime based on Token value graph and computing power ledger, in order to solve the problems in existing multi-agent systems such as Tokens not being managed as assets, lack of fine-grained attribution of computing power investment, difficulty in propagating and tracking risky tokens, difficulty in accumulating highly reusable tokens, coarse resource allocation within the same request, and inability to learn backwards after the task ends.

[0303] Furthermore, this invention addresses the computing power operation scenario of intelligent computing cloud platforms, transforming the value, risk, reuse, and latency impact of tokens into an executable computing power allocation strategy. This strategy prioritizes high-contribution tokens with limited GPU memory, inference instances, tool instances, and verification resources, while transferring low-value or reusable tokens to caching, compression, or low-cost computing power paths.

[0304] This invention unifies user requests, historical memories, tool results, intermediate trajectories, and risk warnings into Token nodes or Token fragment nodes during multi-agent runtime; constructs a Token value graph based on node attributes and edge relationships; records the input and output corresponding to each Agent call, model inference, tool execution, cache storage, context compression, verification, and manual feedback through a Token computing power ledger; dynamically allocates computing power based on the Token's task contribution, risk level, reuse probability, timeliness, confidence level, and unit computing power benefit ratio; triggers large model, expert model, sandbox, multi-model cross-validation, or manual approval for high-risk Tokens; triggers KV cache persistence, skill summary, long-term memory, or tool template accumulation for highly reused Tokens; performs compression or discarding on low-value historical Tokens; allocates larger context windows, stronger models, stronger tool permissions, and higher verification strength to high-impact Tokens; and updates the Token value evaluator in reverse based on user feedback, manual correction, tool results, rollback count, Token cost, and latency performance after task completion.

[0305] Unlike traditional "request routing," "model routing," or "agent process orchestration," the core of this invention is to enable the intelligent computing cloud platform to gradually learn at runtime "which tokens are worth deep inference, which tokens should be compressed, which tokens should invoke tools, which tokens are worth caching, and which tokens may pose security risks." Therefore, this invention not only improves task success rate and security but also reduces the waste of computing power caused by invalid pre-filling, duplicate tool calls, invalid caching, and over-validation.

[0306] This application no longer treats user requests as an indivisible whole, nor does it consider Agent calls as the sole scheduling unit. Instead, it introduces a Token assetization layer during multi-agent runtime. After receiving a user request, the system uniformly parses user input, system prompts, developer instructions, historical dialogues, long-term memory, search documents, tool results, code logs, error stacks, external knowledge, user preferences, security prompts, failure trajectories, and human feedback to form a set of Token nodes. Each Token node contains not only text content and original location, but also source, semantic type, assigned task, timestamp, timeliness, confidence level, risk score, reuse probability, historical contribution, pre-computational cost, actual computational cost, and auditable identifier.

[0307] In the intelligent computing cloud platform, the computing power management layer generates computing power routing labels for each token set based on the node weights output by the token value graph and the historical revenue in the token computing power ledger. These labels include fast channels, economic channels, secure channels, reuse channels, long context channels, and manual approval channels. During multi-agent runtime, the model pool, agent pool, cache layer, and tool pool are scheduled according to these labels, thereby achieving token-level distribution of computing power.

[0308] Subsequently, the system constructs a token value graph. Nodes in the graph represent individual tokens, consecutive token fragments, structured fields, tool parameters, memory summaries, or risk markers, while edges represent relationships such as references, constraints, causality, conflict, inclusion, substitution, tool dependency, risk propagation, reuse, and manual correction. The system calculates the task contribution, risk level, reuse probability, and computing power return ratio of each token node using a value evaluator and a risk propagator, and identifies key token sets.

[0309] The multi-agent scheduler determines computing power routing based on a key token set rather than a fixed process. For high-value and high-risk token sets, the system can upgrade to a stronger model, expert model, sandbox validation, multi-model cross-validation, or manual approval; for high-value but low-risk token sets, the system can allocate a larger context window and a higher inference budget; for low-value historical tokens, the system can compress them into graph-constrained summaries or discard them directly; for highly reusable tokens, the system can retain the original tokens, save them in a KV cache, generate skill summaries, write them into long-term memory, or form tool call templates; for tokens with strong tool dependencies, the system can prioritize calling retrieval, databases, code interpreters, or business APIs; for conflicting tokens, the system can activate a dedicated conflict resolution agent.

[0310] During task execution, every model invocation, agent scheduling, tool execution, context compression, key-value cache saving, sandbox operation, model verification invocation, and human feedback is written to the Token computing power ledger. After the task is completed, the system updates the Token value evaluator in reverse based on result quality, error rollback, human correction, user feedback, tool success rate, latency, cost, and security events. This forms a closed loop of "Token nodeization—value graph construction—computing power routing—ledger recording—result attribution—value feedback".

[0311] The following describes the structural composition of the intelligent computing cloud platform system for token distribution via computing power, as described in this application. In a preferred embodiment, the intelligent computing cloud platform system for token distribution via computing power includes the following modules: Multi-source input access module: used to receive user requests, system prompts, historical dialogues, long-term memory, search results, tool returns, code execution logs, external API returns, security policies, user profiles, and human feedback.

[0312] Token Segmentation and Alignment Module: This module is used to segment the above multi-source information into tokens or token fragments, and establish alignment relationships between the original text location, data source, session round, agent steps, and tool calls.

[0313] Token Node Attribute Generation Module: Used to generate source type, semantic type, task relevance, risk level, timeliness, confidence level, reuse probability, pre-computational cost, historical contribution, and audit identifier for each Token node.

[0314] Token Value Graph Construction Module: Used to establish equilateral relationships between token nodes, including references, constraints, causality, conflicts, tool dependencies, risk propagation, reuse, replacement, induction, and manual correction, forming a dynamically updatable token value graph.

[0315] Token Value Assessment Module: Used to calculate the token's task contribution, risk discounting return, reuse return, and unit computing power return ratio based on node attributes, graph structure, task objectives, context budget, and historical ledger records.

[0316] Token Risk Propagation Module: Used to propagate risk profiles along the token value graph, identifying high-risk token sets and their upstream sources and downstream impact.

[0317] Token Computing Power Ledger Module: Used to record the token set, computing power input, memory usage, latency, tool cost, result quality, and error risk for each Agent call, model inference, tool execution, cache storage, context compression, verification, and manual approval.

[0318] Multi-agent computing power routing module: used to select model specifications, number of agents, context window, tool permissions, caching strategy, sandbox resources and verification strength based on token value and computing power benefit ratio.

[0319] The graph constraint context assembly module is used to assemble candidate tokens into model contexts based on the token value graph, retaining high-value constraints, compressing low-value history, isolating risk information, and maintaining the integrity of the reference chain.

[0320] The Caching and Skill Accumulation module is used to accumulate tokens or token fragments into KV cache, Prompt prefix, long-term memory, skill summary, plugin context, or tool template based on token reuse probability and ledger revenue.

[0321] Feedback Learning Module: Used to update the Token Value Evaluator in reverse order after the task is completed, based on user feedback, manual corrections, tool execution performance, failure rollbacks, and result evaluations.

[0322] Cloud computing power adaptation module: used to map token-level routing results to different GPU pools, CPU tool pools, sandbox clusters, cache layers, storage layers and manual approval queues, and supports multi-tenant isolation and auditing.

[0323] This invention can retain key tokens, avoid writing low-value content into long-term memory, reduce subsequent retrieval noise, improve the accuracy and efficiency of token distribution, avoid wasting computing power caused by invalid pre-filling, duplicate tool calls, invalid caching and over-validation, and improve task success rate and security.

[0324] Please see Figure 2 , Figure 2 This is a structural diagram of a device for token distribution through computing power provided by the present invention, such as... Figure 2 As shown, the device 200 for token distribution through computing power in the intelligent computing cloud platform includes: The node generation module 210 is used to generate multiple candidate Token nodes based on the multi-source information corresponding to the user request and to parse the multi-source information. The value graph construction module 220 is used to generate the node attributes of each candidate Token node and the edge relationships between candidate Token nodes in order to construct the Token value graph. The identification module 230 is used to evaluate the value of candidate Token nodes based on the Token value graph and the historical computing power ledger, and to identify multiple key Token nodes in the Token value graph. The historical computing power ledger includes the evaluation and routing information of Token nodes at historical moments. The Token distribution module 240 is used to distribute tokens based on key token nodes, token value graphs, and historical computing power ledgers.

[0325] In one embodiment, the node generation module 210 is further configured to: Obtain multi-source information based on user requests and their associated context; Multi-source information is segmented to obtain multiple token fragments; Retrieve the alignment relationship between token fragments; Based on the alignment relationship, the token fragments are parsed for structural fields and aligned for source to generate multiple candidate token nodes.

[0326] In one embodiment, the value graph construction module 220 is further configured to: Generate node attributes for each candidate Token node; Obtain the edge relationships, edge weights, and relationship expiration times between candidate token nodes; Based on the node attributes of each candidate token node, the edge relationships between candidate token nodes, edge weights, and relationship validity periods, a directed weighted token value graph is constructed.

[0327] In one embodiment, node attributes include at least one of the following: source type, semantic type, task relevance, risk level, timeliness, confidence level, reuse probability, pre-computational cost, historical contribution, and audit identifier; Edge relationships include at least one of the following: reference relationship, inclusion relationship, constraint relationship, causal relationship, conflict relationship, instrument dependency relationship, evidence support relationship, risk propagation relationship, reuse relationship, substitution relationship, summary and induction relationship, modification relationship and failure rollback relationship; The edge weights are determined based on the strength of the relationships between candidate token nodes. The strength of the relationships is obtained by normalizing at least one of the following: semantic similarity, structured dependency strength, location proximity strength, tool call chain dependency strength, and feedback dependency strength.

[0328] In one embodiment, the identification module 230 is further configured to: For each set of first token nodes, a comprehensive value score is obtained based on the token value map and historical computing power ledger. Obtain the risk level, redundancy, centrality score of the first token node set in the token value graph, and the proportion of the first token node set covering the path from the task objective to the tool results, evidence, or final output; The criticality of the first token node set is obtained based on its comprehensive value score, risk level, centrality score, path ratio, and redundancy. Identify multiple key token nodes in the token value graph based on the criticality of each first token node set; The first set of token nodes includes at least one candidate token node.

[0329] In one embodiment, the identification module 230 is further configured to: Based on the Token value graph and historical computing power ledger, the weighted values ​​of the task relevance, historical contribution, reuse probability, timeliness score, reuse probability, confidence and redundancy of the first Token node set for the current task result are obtained to obtain the basic value score. The centrality score of the first Token node set in the Token value graph is obtained by weighting it according to at least one of the PageRank, betweenness centrality score, task path coverage, or key constraint coverage of the first Token node set. Based on the basic value score, edge weight, and centrality score, obtain the graph propagation value score of the first Token node set; Obtain the risk-converted returns for multiple types of risks, and obtain a comprehensive value score based on the weighted average of the risk-converted returns for multiple types of risks and the sum of the graph propagation value score.

[0330] In one embodiment, multiple types of risk-reduced benefits include the following: the expected risk loss reduced by verifying or approving the first Token node set; the reuse benefit obtained by caching the first Token node set; and the benefit of storing the first Token node set for multi-Agent processes.

[0331] In one embodiment, the identification module 230 is further configured to: Determine the edge set of the first Token node set; Sum the product of the base value score and the edge weight of the Token node associated with the edge set to obtain the sum value; We obtain the graph propagation value score of the first Token node set by weighting the summation value, the basic value score, and the centrality score of the first Token node set.

[0332] In one embodiment, the identification module 230 is further configured to: Obtain the weighted value of the comprehensive value score, risk level, centrality score, and path ratio of the first Token node set; Obtain the product of the redundancy of the first Token node set and its own weight; The difference between the weighted value and the product is used as the key value of the first Token node set.

[0333] In one embodiment, the identification module 230 is further configured to: Based on the node attributes of each Token node in the first Token node set, obtain the graph expansion radius of the first Token node set; Based on the graph expansion radius, in the Token value graph, the first set of Token nodes with a criticality higher than the preset criticality threshold is expanded to obtain multiple critical Token nodes.

[0334] In one embodiment, the Token routing module 240 is further configured to: Obtain multiple initial token computing power routing policies, which are used to indicate at least one of the models, tools, caches, and verification resources to be allocated; For each set of second token nodes, a candidate token computing power routing strategy is determined based on preset action constraints and the initial token computing power routing strategy. The candidate token computing power routing strategy is optimized based on the token value map and historical computing power ledger to obtain the target token computing power routing strategy. Execution graph constraint context assembly and compression based on the token value graph; The second set of token nodes is split according to the target token computing power routing strategy in order to obtain the execution result of the user request.

[0335] In one embodiment, the Token routing module 240 is further configured to: Based on the Token value map and historical computing power ledger, obtain the target computing power return ratio and target risk score of the second Token node set; Obtain the reuse probability of the second Token node set based on the historical computing power ledger; The candidate token computing power routing strategy is optimized based on the target computing power return ratio, target risk score and reuse probability to obtain the target token computing power routing strategy.

[0336] In one embodiment, the Token routing module 240 is further configured to: Based on the Token value graph and historical computing power ledger, calculate the unit computing power revenue ratio of each candidate Token node in the second Token node set, and score the graph relationship collaboration of the second Token node set. The target computing power revenue ratio is obtained based on the unit computing power revenue ratio of each candidate Token node in the second Token node set and the graph relationship collaborative scoring of the second Token node set. Based on the token value graph and historical computing power ledger, risk propagation calculations are performed on the second token node set to obtain the target risk score.

[0337] In one embodiment, the Token routing module 240 is further configured to: Based on the Token value map and historical computing power ledger, the weighted values ​​of the quality improvement score, risk reduction score and reuse revenue of each candidate Token node in the second Token node set under the standard strategy are calculated to obtain the target revenue of each candidate Token node in the second Token node set. Under the standard Token computing power routing strategy, the weighted values ​​of model computing cost, tool cost, memory cost and latency cost of each candidate Token node in the second Token node set are calculated to obtain the target cost of each candidate Token node in the second Token node set. Based on the ratio of target revenue to target cost, obtain the unit computing power revenue ratio of each candidate Token node in the second Token node set; Based on the preset graph continuity constraints, obtain the graph continuity score of the second Token node set; Obtain the sum of the target revenue of each candidate Token node in the second Token node set, and divide this sum and the sum of the graph coherence score by the target cost of the second Token node set to obtain the graph relationship collaboration score. The target cost of the second Token node set is the sum of the target costs of each candidate Token node in the second Token node set.

[0338] In one embodiment, the Token routing module 240 is further configured to: Determine the edge set and initial risk score for the second set of token nodes; Based on the initial risk score, the risk propagation coefficient of the Token nodes associated with the edge set, the edge weight, and the candidate risk score of the previous time step, the target risk propagation formula is calculated to obtain the target risk score of the second Token node set at the current time step.

[0339] In one embodiment, the Token routing module 240 is further configured to: Based on the historical computing power ledger, calculate the weighted values ​​of the historical occurrence frequency of the second token node set, the reuse intensity of the same tenant or the same project, the degree of templated nature, the reuse intensity of tool definition or tool result, historical contribution, and expiration risk. The weighted value is normalized to obtain the reuse probability of the second set of token nodes.

[0340] In one embodiment, the Token routing module 240 is further configured to: Based on the target computing power benefit ratio, adjust the computing power to be allocated to the second Token node set to optimize the candidate Token computing power routing strategy; and / or, In response to a target risk score exceeding a preset risk score threshold, the candidate token computing power routing strategy is optimized based on at least one of the following: risk type, risk level, risk propagation scope, and task context; and / or, Based on the reuse probability of the second Token node set, determine whether the second Token node set should be cached in order to optimize the candidate Token computing power routing strategy.

[0341] In one embodiment, the Token routing module 240 is further configured to: The cache cost is obtained by summing the storage cost of the second Token node set with the opportunity cost caused by crowding out other caches; The expected reuse value is obtained by multiplying the reuse probability of the second Token node set by the comprehensive value score. Based on the ratio of expected reuse value to caching cost and its relationship with a preset ratio threshold, it is determined whether the second Token node set should be cached, so as to optimize the candidate Token computing power routing strategy.

[0342] In one embodiment, the Token routing module 240 is further configured to: For each set of second token nodes, in response to determining the cached set of second token nodes, the lease value of the set of second token nodes is obtained based on the reuse probability, comprehensive value score, memory cost, expiration risk and privacy risk of the set of second token nodes. Lifecycle management is performed on the second token node set based on the lease value and lease term.

[0343] In one embodiment, the Token routing module 240 is further configured to: Obtain the comprehensive value score, graph coherence score, and redundancy of multiple sets of third token nodes, each set of third token nodes including at least one key token node; Based on the comprehensive value score, graph coherence score, and redundancy of the third token node set, obtain the model context requirements of the third token node set. Based on the preset model context budget and the model context requirements of each third token node set, determine the target token node set to be put into the context from the third token node set; For key token nodes and / or candidate token nodes that are not included in the context, compression is performed based on the comprehensive value score and target risk score of the key token nodes and / or candidate token nodes.

[0344] In one embodiment, the update processing module 250 is further configured to: The historical computing power ledger is updated based on the execution process of token distribution; The historical computing power ledger records each runtime action including at least one of the following: a pipeline identifier; the set of token nodes associated with this action; an agent or module identifier; model specifications or tool specifications; the number of input and output tokens; the number of inference layers or inference budget; GPU time, memory usage, batch queue waiting, and network communication overhead; cache saving, reading, hit, and eviction information; tool costs, sandbox costs, or external API costs; intermediate results, final results, or verification results of this action; records of errors, rollbacks, timeouts, security events, or manual interventions; and an estimated contribution to backfilling after the task is completed.

[0345] In one embodiment, the update processing module 250 is further configured to: Obtain the first output of the m-th sampling or evaluation of each Token node participating in the calculation, the second output after masking or downweighting nodes, and the result quality score; Based on the first output, the second output, and the result quality score, obtain the contribution of all Token nodes participating in the calculation; The parameters of the Token value evaluator are updated based on the contribution level. The Token value evaluator is used to evaluate the value of Token nodes.

[0346] This invention can retain key tokens, avoid writing low-value content into long-term memory, reduce subsequent retrieval noise, improve the accuracy and efficiency of token distribution, avoid wasting computing power caused by invalid pre-filling, duplicate tool calls, invalid caching and over-validation, and improve task success rate and security.

[0347] The device for achieving token distribution through computing power in the intelligent computing cloud platform provided by this invention is capable of implementing the various processes of the above-mentioned method for achieving token distribution through computing power in the intelligent computing cloud platform. The technical features are one-to-one and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0348] The device for achieving token distribution through computing power in the intelligent computing cloud platform provided by this invention is capable of implementing the various processes of the above-mentioned method for achieving token distribution through computing power in the intelligent computing cloud platform. The technical features are one-to-one and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0349] It should be noted that the device for token distribution through computing power in the intelligent computing cloud platform of this invention can be a device, or a component, integrated circuit, or chip in an electronic device.

[0350] The present invention also provides an electronic device, see [link to relevant documentation]. Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. The electronic device includes a memory 301, a processor 302, and a program or instructions stored in the memory 301 that run on the memory. When the program or instructions are executed by the processor 302, they can achieve the following: Figure 1 The corresponding intelligent computing cloud platform achieves the same beneficial effect through any step in the method embodiment of token distribution using computing power, and will not be elaborated here.

[0351] The processor 302 can be a CPU, ASIC, FPGA or GPU.

[0352] Those skilled in the art will understand that all or part of the steps of the above-described method embodiment for implementing token distribution through computing power in the intelligent computing cloud platform can be accomplished by hardware related to program instructions, and the program can be stored in a readable medium.

[0353] The present invention also provides a readable storage medium on which a computer program is stored, and which, when executed by a processor, can perform the above-described functions. Figure 1 The corresponding intelligent computing cloud platform achieves any step in the method embodiment of token distribution through computing power, and can achieve the same technical effect. To avoid repetition, it will not be described again here. The storage medium mentioned is such as read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk, etc.

[0354] The present invention also provides a computer program product, including computer instructions that, when executed by a processor, implement the above-described... Figure 1 The corresponding intelligent computing cloud platform implements each process of the token distribution method through computing power, and can achieve the same technical effect. To avoid repetition, it will not be described in detail here.

[0355] The terms "first," "second," etc., used in this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or apparatuses. Additionally, the use of "and / or" in this invention indicates at least one of the connected objects, such as A and / or B and / or C, representing seven possibilities: A alone, B alone, C alone, both A and B present, both B and C present, both A and C present, and A, B, and C present.

[0356] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0357] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or second terminal device, etc.) to execute the methods of the various embodiments of the present invention.

[0358] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of the present invention.

Claims

1. A method for token distribution through computing power in an intelligent computing cloud platform, characterized in that, include: Step S1: Based on the multi-source information corresponding to the user request, parse the multi-source information to generate multiple candidate Token nodes; Step S2: Generate the node attributes of each candidate Token node and the edge relationships between the candidate Token nodes to construct a Token value graph; Step S3: Based on the Token value map and historical computing power ledger, evaluate the value of the candidate Token nodes and identify multiple key Token nodes in the Token value map. The historical computing power ledger includes the evaluation and routing information of Token nodes at historical moments. Step S4: Perform token distribution based on the key token nodes, the token value graph, and the historical computing power ledger; Step S3 includes: Step S3.1: For each set of first token nodes, obtain a comprehensive value score for the set of first token nodes based on the token value map and the historical computing power ledger; Step S3.2: Obtain the risk level, redundancy, centrality score of the first Token node set in the Token value graph, and the proportion of the first Token node set covering the path from the task objective to the tool result, evidence, or final output. Step S3.3: Obtain the criticality of the first Token node set based on the comprehensive value score, risk level, centrality score, path ratio, and redundancy of the first Token node set; Step S3.4: Identify multiple key token nodes in the token value graph based on the keyness of each first token node set; The first Token node set includes at least one of the candidate Token nodes; Step S3.3 includes: Step S3.3.1: Obtain the weighted value of the comprehensive value score, risk level, centrality score and path ratio of the first Token node set; Step S3.3.2: Obtain the product of the redundancy and the weight of the first Token node set; Step S3.3.3: The difference between the weighted value and the product is used as the criticality of the first Token node set; Step S3.4 further includes: Step S3.4.1: Obtain the graph expansion radius of the first Token node set based on the node attributes of each Token node in the first Token node set; Step S3.4.2: Based on the graph expansion radius, expand the first set of Token nodes with a criticality higher than a preset criticality threshold in the Token value graph to obtain multiple critical Token nodes.

2. The method according to claim 1, characterized in that, Step S1 includes: Step S1.1: Obtain the multi-source information based on the user request and its associated context; Step S1.2: Segment the multi-source information to obtain multiple token fragments; Step S1.3: Obtain the alignment relationship between the token fragments; Step S1.4: Based on the alignment relationship, perform structural field parsing and source alignment on the Token fragment to generate multiple candidate Token nodes.

3. The method according to claim 1, characterized in that, Step S2 includes: Step S2.1: Generate node attributes for each candidate Token node; Step S2.2: Obtain the edge relationships, edge weights, and relationship validity periods between the candidate Token nodes; Step S2.3: Construct a directed weighted token value graph based on the node attributes of each candidate token node, the edge relationships between the candidate token nodes, the edge weights, and the relationship validity periods.

4. The method according to claim 3, characterized in that, The node attributes include at least one of the following: source type, semantic type, task relevance, risk level, timeliness, confidence level, reuse probability, pre-computational cost, historical contribution, and audit identifier; The edge relationship includes at least one of the following: reference relationship, inclusion relationship, constraint relationship, causal relationship, conflict relationship, instrument dependency relationship, evidence support relationship, risk propagation relationship, reuse relationship, substitution relationship, summary and induction relationship, modification relationship and failure rollback relationship; The edge weights are determined based on the strength of the relationships between the candidate token nodes. The strength of the relationships is obtained by normalizing at least one of semantic similarity, structured dependency strength, location proximity strength, tool call chain dependency strength, and feedback dependency strength.

5. The method according to any one of claims 1-4, characterized in that, Step S3.1 includes: Step S3.1.1: Based on the Token value map and the historical computing power ledger, obtain the weighted values ​​of the task relevance, historical contribution, timeliness score, reuse probability, confidence and redundancy of the first Token node set to the current task result, and obtain the basic value score; Step S3.1.2: Obtain the centrality score of the first Token node set in the Token value graph by weighting it according to at least one of the PageRank, betweenness centrality score, task path coverage or key constraint coverage of the first Token node set. Step S3.1.3: Obtain the graph propagation value score of the first Token node set based on the basic value score, edge weight and centrality score; Step S3.1.4: Obtain the risk-converted returns of multiple types, and obtain the comprehensive value score based on the weighted value of the risk-converted returns of multiple types and the sum of the graph propagation value scores.

6. The method according to claim 5, characterized in that, The risk-reduction benefits of the various types include the following: the expected risk loss reduced by verifying or approving the first Token node set; the reuse benefits obtained by caching the first Token node set; and the benefits of storing the first Token node set for multi-Agent processes.

7. The method according to claim 6, characterized in that, Step S3.1.3 includes: Step S3.1.3.1: Determine the edge set of the first Token node set; Step S3.1.3.2: Sum the product of the basic value score and the edge weight of the Token node associated with the edge set to obtain the sum value; Step S3.1.3.3: Weight the summation value, the basic value score of the first Token node set, and the centrality score to obtain the graph propagation value score of the first Token node set.

8. The method according to any one of claims 1-4, characterized in that, Step S4 includes: Step S4.1: Obtain multiple initial Token computing power routing strategies. The Token computing power routing strategy is used to indicate at least one of the models, tools, caches and verification resources to be allocated. Step S4.2: For each set of second token nodes, determine the candidate token computing power routing strategy corresponding to the set of second token nodes according to the preset action constraints and the initial token computing power routing strategy. The action constraints include at least one of the following: expected task quality constraints, computing power cost constraints, computing power revenue constraints, latency constraints, video memory usage constraints, expected error loss constraints, risk constraints, and allowed tool permission set constraints. Step S4.3: Optimize the candidate Token computing power routing strategy based on the Token value map and the historical computing power ledger to obtain the target Token computing power routing strategy; Step S4.4: Perform graph constraint context assembly and compression based on the Token value graph; Step S4.5: Perform token routing on the second token node set according to the target token computing power routing strategy to obtain the execution result of the user request.

9. The method according to claim 8, characterized in that, Step S4.3 includes: Step S4.3.1: Based on the Token value map and the historical computing power ledger, obtain the target computing power return ratio and target risk score of the second Token node set; Step S4.3.2: Obtain the reuse probability of the second Token node set based on the historical computing power ledger; Step S4.3.3: Optimize the candidate Token computing power routing strategy based on the target computing power benefit ratio, the target risk score and the reuse probability to obtain the target Token computing power routing strategy.

10. The method according to claim 9, characterized in that, Step S4.3.1 includes: Step S4.3.1.1: Based on the Token value graph and the historical computing power ledger, calculate the unit computing power revenue ratio of each candidate Token node in the second Token node set, and the graph relationship collaborative score of the second Token node set; Step S4.3.1.2: Based on the unit computing power revenue ratio of each candidate Token node in the second Token node set and the graph relationship collaborative scoring of the second Token node set, obtain the target computing power revenue ratio; Step S4.3.1.3: Based on the Token value map and the historical computing power ledger, perform risk propagation calculation on the second Token node set to obtain the target risk score.

11. The method according to claim 10, characterized in that, Step S4.3.1.1 includes: Step S4.3.1.1.1: Based on the Token value map and the historical computing power ledger, calculate the weighted values ​​of the quality improvement score, risk reduction score and reuse revenue of each candidate Token node in the second Token node set under the standard strategy, and obtain the target revenue of each candidate Token node in the second Token node set. Step S4.3.1.1.2: Calculate the weighted value of the model computation cost, tool cost, memory cost and latency cost of each candidate Token node in the second Token node set under the standard Token computing power routing strategy, and obtain the target cost of each candidate Token node in the second Token node set; Step S4.3.1.1.3: Based on the ratio of the target revenue to the target cost, obtain the unit computing power revenue ratio of each candidate Token node in the second Token node set; Step S4.3.1.1.4: Obtain the graph continuity score of the second Token node set according to the preset graph continuity constraints; Step S4.3.1.1.5: Obtain the sum of the target revenue of each candidate Token node in the second Token node set, and divide the sum of the sum and the graph coherence score by the target cost of the second Token node set to obtain the graph relationship collaboration score, wherein the target cost of the second Token node set is the sum of the target costs of each candidate Token node in the second Token node set.

12. The method according to claim 10, characterized in that, Step S4.3.1.3 includes: Step S4.3.1.3.1: Determine the edge set and initial risk score of the second Token node set; Step S4.3.1.3.2: Calculate the target risk propagation formula based on the initial risk score, the risk propagation coefficient of the Token node associated with the edge set, the edge weight, and the candidate risk score of the previous time step, and obtain the target risk score of the second Token node set at the current time step.

13. The method according to claim 9, characterized in that, Step S4.3.2 includes: Step S4.3.2.1: Based on the historical computing power ledger, calculate the weighted values ​​of the historical occurrence frequency, reuse intensity of the same tenant or project, degree of templating, reuse intensity of tool definition or tool result, historical contribution and expiration risk of the second Token node set; Step S4.3.2.2: Normalize the weighted value to obtain the reuse probability of the second Token node set.

14. The method according to claim 9, characterized in that, Step S4.3.3 includes: Step S4.3.3.1: Adjust the computing power to be allocated to the second Token node set according to the target computing power benefit ratio, so as to optimize the candidate Token computing power routing strategy; and / or, Step S4.3.3.2: In response to the target risk score being greater than a preset risk score threshold, optimize the candidate token computing power routing strategy based on at least one of risk type, risk level, risk propagation scope, and task context; and / or, Step S4.3.3.3: Determine whether the second Token node set is cached based on the reuse probability of the second Token node set, so as to optimize the candidate Token computing power routing strategy.

15. The method according to claim 14, characterized in that, Step S4.3.3.3 includes: Step S4.3.3.3.1: Obtain the cache cost based on the sum of the storage cost of the second Token node set and the opportunity cost caused by crowding out other caches; Step S4.3.3.3.2: Obtain the expected reuse value based on the product of the reuse probability and the comprehensive value score of the second Token node set; Step S4.3.3.3.3: Based on the relationship between the ratio of the expected reuse value and the caching cost and the preset ratio threshold, determine whether the second Token node set should be cached, so as to optimize the candidate Token computing power routing strategy.

16. The method according to claim 14, characterized in that, Step S4.3.3.3 is followed by: Step S4.3.3.4: For each set of the second token nodes, in response to determining the cached set of the second token nodes, obtain the lease value of the set of the second token nodes based on the reuse probability, comprehensive value score, memory cost, expiration risk and privacy risk of the set of the second token nodes; Step S4.3.3.5: Perform lifecycle management on the second Token node set according to the lease value and lease term of the second Token node set.

17. The method according to claim 8, characterized in that, Step S4.4 includes: Step S4.4.1: Obtain the comprehensive value score, graph coherence score and redundancy of multiple third token node sets, where each third token node set includes at least one key token node; Step S4.4.2: Based on the comprehensive value score, graph coherence score, and redundancy of the third Token node set, obtain the model context requirements of the third Token node set; Step S4.4.3: Based on the preset model context budget and the model context requirements of each third Token node set, determine the target Token node set to be placed into the context from the third Token node set; Step S4.4.4: For the key token node and / or the candidate token node that are not placed in the context, perform compression based on the comprehensive value score and target risk score of the key token node and / or the candidate token node.

18. The method according to any one of claims 1-4, characterized in that, Step S4 is followed by: Step S5: Update the historical computing power ledger according to the execution process of Token distribution; The historical computing power ledger records at least one of the following actions for each runtime: a pipeline identifier; the set of token nodes associated with this action; an agent or module identifier; model specifications or tool specifications; the number of input and output tokens; the number of inference layers or inference budget; GPU time, memory usage, batch queue waiting, and network communication overhead; cache saving, reading, hit, and eviction information; tool costs, sandbox costs, or external API costs; intermediate results, final results, or verification results of this action; records of errors, rollbacks, timeouts, security events, or manual interventions; and an estimated contribution to backfilling after the task is completed.

19. The method according to any one of claims 1-4, characterized in that, Step S5 is followed by: Step S6: Obtain the first output of the m-th sampling or evaluation of each Token node participating in the calculation, the second output after masking or downweighting nodes, and the result quality score; Step S7: Based on the first output, the second output, and the result quality score, obtain the contribution of all Token nodes participating in the calculation; Step S8: Update the parameters of the Token value evaluator according to the contribution level. The Token value evaluator is used to evaluate the value of Token nodes.

20. A device for intelligent computing cloud platform to achieve token distribution through computing power, characterized in that, include: The node generation module is used to generate multiple candidate Token nodes based on the multi-source information corresponding to the user request and to parse the multi-source information. The value graph construction module is used to generate the node attributes of each candidate Token node and the edge relationships between the candidate Token nodes in order to construct a Token value graph. The identification module is used to evaluate the value of the candidate Token nodes based on the Token value graph and the historical computing power ledger, and to identify multiple key Token nodes in the Token value graph. The historical computing power ledger includes the evaluation and routing information of Token nodes at historical moments. The Token distribution module is used to distribute tokens based on the key token nodes, the token value graph, and the historical computing power ledger. The identification module is further configured to: For each set of first token nodes, a comprehensive value score is obtained based on the token value map and the historical computing power ledger. Obtain the risk level, redundancy, centrality score of the first token node set in the token value graph, and the proportion of the first token node set covering the path from the task objective to the tool result, evidence, or final output. Based on the comprehensive value score, risk level, centrality score, path ratio, and redundancy of the first Token node set, the criticality of the first Token node set is obtained. Identify multiple key token nodes in the token value graph based on the keyness of each of the first token node sets; The first Token node set includes at least one of the candidate Token nodes; The identification module is further configured to: Obtain the weighted value of the comprehensive value score, risk level, centrality score, and path ratio of the first Token node set; Obtain the product of the redundancy of the first Token node set and its own weight; The difference between the weighted value and the product is used as the criticality of the first Token node set; The identification module is further configured to: Based on the node attributes of each Token node in the first Token node set, obtain the graph expansion radius of the first Token node set; Based on the graph expansion radius, in the Token value graph, the first set of Token nodes with a criticality higher than a preset criticality threshold is expanded to obtain multiple critical Token nodes.

21. An electronic device, characterized in that, include: A processor, a memory, and a program stored in the memory and executable on the processor, wherein the program, when executed by the processor, implements the steps of the method for achieving token distribution through computing power in the intelligent computing cloud platform as described in any one of claims 1 to 19.

22. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the method for token distribution through computing power in the intelligent computing cloud platform as described in any one of claims 1 to 19.

23. A computer program product, characterized in that, It includes computer instructions, which, when executed by a processor, implement the steps of the method for achieving token distribution through computing power in the intelligent computing cloud platform as described in any one of claims 1 to 19.

Images