A method and system for dynamic resource requirement characterization of a task life cycle

Abstract

The application discloses a kind of dynamic resource demand characterization method and system of task life cycle, belong to artificial intelligence computing resource management technical field, when task starts, deployment monitoring agent, through GPU instruction sudden increase inflection point dynamically divides task life cycle, and synchronously monitors CPU instruction flow;Collect task semantic features, CPU / GPU hardware index and interactive time delay data, extract key features after space-time alignment and calculate collaborative efficiency index;Based on historical task library, construct cross-stage resource demand coupling matrix, quantize adjacent stage CPU / GPU resource transmission coefficient;Build double-flow prediction model, predict resource demand in conjunction with coupling matrix, generate three-dimensional demand matrix;Demand matrix is encoded into dynamic vector and introduced stage transition resource change intensity enhancement vector, finally output enhancement vector sequence triggers CPU / GPU collaborative scheduling.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence computing resource management technology, specifically a method and system for representing dynamic resource requirements throughout the task lifecycle. Background Technology

[0002] With the rapid development of artificial intelligence (AI), machine learning (ML), and deep learning (DL) technologies, the demands of various computing tasks on computing resources are becoming increasingly complex. Especially in the application of AI computing platforms, computing tasks often encompass multiple stages, including data processing, model training, and inference. Each stage has different resource requirements. Traditional computing resource scheduling methods mainly rely on static configuration, that is, allocating resources based on the type and size of the task. This cannot accurately capture the dynamic changes of the task at different lifecycle stages, resulting in low resource utilization efficiency and potentially leading to resource waste or system bottlenecks.

[0003] Current resource scheduling systems are typically based on the initial configuration of a task, failing to adequately consider changes in resource requirements during task execution, particularly the uneven and time-dependent demands on CPUs and GPUs in computational tasks. For example, the training phase of a deep learning model may initially require only a small amount of computing resources, but as training progresses, especially during the training process, the demand for GPU resources increases dramatically, potentially experiencing multiple computational peaks and fluctuations. In such cases, static resource allocation methods cannot flexibly cope with these changes, resulting in low resource utilization of the computing platform when handling complex tasks, and may even affect task completion time and efficiency. Summary of the Invention

[0004] The purpose of this invention is to provide a method and system for representing dynamic resource requirements throughout a task's lifecycle, in order to solve the problems mentioned in the background art.

[0005] To address the aforementioned technical problems, this invention provides the following technical solution: a method for representing dynamic resource requirements throughout a task's lifecycle, characterized in that: the method includes:

[0006] Step S1: Deploy a monitoring agent when the task starts, dynamically divide the task lifecycle stages by capturing the sudden inflection point of GPU computing instructions in real time, and synchronously monitor the CPU instruction flow;

[0007] Step S2: Collect task semantic features, CPU microarchitecture metrics, GPU hardware metrics, and interaction latency between CPU and GPU; perform spatiotemporal alignment on the collected data, extract key features of CPU / GPU respectively, and calculate collaborative efficiency metrics.

[0008] Step S3: Analyze the resource consumption transfer patterns of the same type of task at each stage based on the historical task database, calculate the CPU-GPU resource transmission coefficient during stage transition, and construct a cross-stage resource demand coupling matrix;

[0009] Step S4: Construct a dual-stream prediction model, using the coupling matrix as prior knowledge input to the prediction network. The CPU stream uses a temporal convolutional network to predict the CPU demand curve within a preset time period in the future; the GPU stream combines historical memory usage data and resource transmission coefficients to predict GPU resource inflection points.

[0010] Step S5: Integrate the dual-flow prediction results, calculate the synergistic correlation degree and stage influence weight through the coupling matrix, and generate a three-dimensional demand matrix;

[0011] Step S6: Encode the three-dimensional demand matrix into a dynamic vector sequence; based on the intensity of resource demand changes during the transition of the coupling matrix quantization stage, concatenate the quantization result as a new feature dimension into the dynamic vector, and finally output an enhanced vector sequence to trigger the real-time scheduler to perform collaborative scheduling of CPU / GPU resources.

[0012] Step S1 includes:

[0013] Step S1-1: The monitoring agent accesses the GPU instruction register through the PCIe bus interface to collect the instantaneous frequency of GPU computing instructions in real time, and at the same time collects the number of cycles of the CPU instruction stream through the CPU performance counter.

[0014] Step S1-2: In the initial stage after task startup, continuously collect the instantaneous frequency of GPU computing instructions at a preset sampling interval, calculate the average value of the frequency values ​​of N consecutive sampling points, and denot it as F. avg Based on this mean, a surge threshold α for GPU instructions is set, where α is F. avg A fixed multiple: α = k × F avg , where k is an empirical coefficient preset according to the task type; the GPU instruction frequency collected in real time, denoted as F(t), is continuously detected, where F(t) represents the GPU instruction frequency at time t;

[0015] Set jump point determination conditions:

[0016] First, the real-time GPU instruction frequency F(t) ≥ α is collected over n or more consecutive sampling periods. Second, the frequency growth rate ΔF over these n periods is calculated: ΔF = (F(t) - F(tn)) / F(tn), where F(tn) represents the instantaneous frequency of GPU computation instructions collected at n sampling periods before the current detection time t. If the growth rate exceeds 50%, the starting time of this interval is determined as the transition point.

[0017] Steps S1-3: Using the transition point as the time node and combining it with the GPU instruction frequency, the lifecycle is divided into four stages:

[0018] When F(t) < 0.1α, and it is within the time period from task start to the first transition point, it is determined to be the initialization phase;

[0019] When 0.1α <= F(t) < α, and it is in the period after the first transition point and the frequency has not stably exceeded the threshold, and the frequency growth rate exceeds the preset value for multiple consecutive cycles, it is determined to be in the climbing phase.

[0020] When F(t)>=α and the frequency fluctuation amplitude within A consecutive sampling periods is ≤ε, it is determined to be in a steady state; where A is the preset stable observation window length and ε is the preset fluctuation threshold coefficient, both of which are dynamically adjusted based on historical data according to the task type.

[0021] When F(t) < 0.1α, and the frequency first falls below 0.1α after the end of the steady-state phase and begins a continuous downward trend until the end of the task, it is determined to be the convergence phase.

[0022] Step S2 includes:

[0023] Step S2-1: Based on the stage boundaries defined in Step S1, synchronously collect task semantic features, CPU microarchitecture metrics, GPU hardware metrics, and the interaction latency between the CPU and GPU.

[0024] Task semantic features include task type, algorithm name, input data size, and preset parameters;

[0025] CPU microarchitecture metrics include core utilization, L3 cache hit rate, thread scheduling latency, and memory bandwidth utilization.

[0026] GPU hardware metrics include processor utilization, memory usage, memory read / write bandwidth, PCIe data transfer rate, and kernel function execution time.

[0027] The interaction latency between the CPU and GPU includes data transmission latency and synchronization waiting latency;

[0028] Step S2-2: Using the timestamp of GPU instruction acquisition in step S1 as a benchmark, use linear interpolation to supplement the missing time point data of CPU indicators; classify and store the acquired discrete indicators according to "stage-device-indicator";

[0029] Step S2-3: Extract key features from the aligned data, including:

[0030] Key CPU characteristics: peak core utilization, trough cache hit rate, and average thread scheduling latency within a given period;

[0031] Key GPU characteristics: peak memory usage, average stream processor utilization, memory read / write bandwidth fluctuation, and kernel function execution time distribution within a given period.

[0032] Step S2-4: Based on the interaction data between the CPU and GPU, calculate quantitative indicators reflecting the efficiency of their collaborative work, including:

[0033] Data transfer efficiency: Transfer efficiency = 1 - (PCIe transfer time / GPU computation time);

[0034] Resource idle rate: Idle rate = (CPU waiting time for GPU + GPU waiting time for CPU) / Total duration of the stage;

[0035] Pipeline matching degree: Matching degree = CPU data preprocessing time / GPU computation time.

[0036] Step S3 includes:

[0037] Step S3-1: Based on the semantic features of the task collected in step S2, calculate the cosine similarity of the semantic feature vectors from the historical task database and select tasks with a matching degree ≥ 80%; for each selected historical task, extract the key features and quantitative indicators of each stage according to the four stages divided in step S1 and step S2; clean the extracted historical data, remove outliers, and supplement missing data.

[0038] Step S3-2: The resource transmission coefficient is used to quantify the impact of resource consumption in the previous stage on resource demand in the next stage. The four stages of the task life cycle are connected in sequence. Only the transmission coefficient between adjacent stages is calculated, that is, the following three sets of coefficients need to be calculated: initialization → ramp-up, ramp-up → steady state, and steady state → convergence.

[0039] CPU resource transfer coefficient K cpu : This represents the impact of CPU resource consumption in stage s on the CPU resource demand in stage s+1; the calculation formula is: K cpu =cov(C s C s+1 ) / var(C s ); where C s For the total CPU requirement of stage s in the historical task, C s+1 Let be the total CPU demand for stage s+1; cov be the covariance, measuring the degree of synchronous change between the two; var be the variance, measuring the fluctuation of stage s itself; K cpu The larger the value, the more significant the impact of CPU consumption in stage s on CPU demand in stage s+1. A positive coefficient indicates that an increase in CPU consumption in the previous stage leads to an increase in CPU demand in the next stage; a negative coefficient indicates that an increase in resource consumption in the previous stage leads to a decrease in resource demand in the next stage.

[0040] GPU resource conduction coefficient K gpu : This represents the degree to which the GPU resource consumption in the previous stage s affects the GPU resource demand in the next stage s+1; the calculation logic is the same as that for CPU, and the formula is: K gpu =cov(G s G s+1 ) / var(G s ); where: G s Gs+1 represents the total GPU resource requirement of stage s in the historical task; Gs+1 represents the total GPU resource requirement of stage s+1 in the same historical task; cov(G s G s+1 ) represents G s With G s+1 The covariance measures the degree of synchronous change in GPU resource requirements between two phases; var(G s ) represents G s The variance measures the fluctuation range of GPU resource requirements in stage s.

[0041] Step S3-3: Construct a cross-stage resource demand coupling matrix with a dimension of 4×4×2×2, representing source stage × target stage × source device × target device. The source device and target device correspond to CPU and GPU, respectively. Therefore, the matrix elements cover four types of transmission relationships: CPU→CPU, CPU→GPU, GPU→CPU, and GPU→CPU. Only adjacent stages are filled with corresponding coefficients, and non-adjacent stages and elements in the same stage are set to 0. The matrix is ​​normalized to map the coefficients to the interval [-1,1], thus forming the cross-stage resource demand coupling matrix.

[0042] Step S4 includes:

[0043] Step S4-1: The CPU flow is predicted using a temporal convolutional network. The historical CPU indicator sequence extracted in step S2 is input into the temporal convolutional network according to the time window. Multi-scale temporal dependencies are captured through a multi-layer causal convolutional structure. Each convolutional layer is followed by a BatchNorm layer and a ReLU activation function. Residual connections are introduced, and the input is directly added to the output of the convolutional layer. A Dropout layer is added before the fully connected layer, and the dropout rate is set to 0.2. Finally, the CPU demand sequence for the next 30 time steps is output, which includes the predicted values ​​of various CPU feature indicators.

[0044] Step S4-2: The GPU stream combines historical memory usage data and the resource transmission coefficient calculated in step S3 to predict inflection points. First, the first derivative of the historical memory usage sequence is calculated to identify suspicious points where the absolute value of the derivative exceeds a threshold. Features of W time steps before and after each suspicious point are extracted to construct a feature vector. The feature vector is input into a 3-layer fully connected network with 64, 32, and 1 neurons in each layer. The output layer uses the Sigmoid activation function to output the probability value that the suspicious point is a true inflection point. The probability values ​​are filtered by a threshold η to generate a sequence containing timestamps and inflection point types.

[0045] Step S5 includes:

[0046] Step S5-1: Spatiotemporally align the demand curve of the CPU stream output and the inflection point sequence of the GPU stream output from Step S4. Using the GPU inflection point timestamp as a reference, resample the CPU demand curve to the same time granularity using linear interpolation to generate an aligned binary sequence {(CPU t GPU t} T t=1 Where T represents the total time step, CPU t Represents the CPU resource vector at time t, GPU t This represents the GPU state vector at the corresponding time point;

[0047] Step S5-2: Based on the coupling matrix constructed in step S3, calculate the co-correlation degree C at each time step. t and stage influence weight W t The formula for calculating the degree of synergy is:

[0048] C t =∑ 4 s=1 ∑ d1,d2∈{CPU,GPU} M[s,c,d1,d2]·Similarity(d1,CPU t ,d2,GPU t );

[0049] Where M[s,c,d1,d2] are the elements of the coupling matrix constructed in step S3, representing the transmission coefficient of "source device d1 → target device d2" in the current stage c from the historical stage s; the Similarity function quantifies the matching degree between the current resource state and the historical stage, and calculates the cosine similarity between the current resource state vector and the feature vector of the historical stage.

[0050] Stage Influence Weight W t This represents the percentage of influence of each historical stage on the current time t, obtained by normalizing the corresponding row vectors of the coupling matrix using the Softmax function;

[0051] Step S5-3: Using the collaborative correlation degree and stage influence weight as coefficients, perform weighted aggregation on the spatiotemporally aligned resource sequence to generate a three-dimensional demand matrix D∈R. T×2×F Where T is the time step, 2 corresponds to the two device dimensions of CPU and GPU, and F is the resource feature dimension; the matrix element calculation formula is: D[t,d,f]=C t ·(W t Couple (CPU) t [f],GPU t [f]); where D[t,d,f] represents the element values ​​of time t, device d, and feature f in the matrix; Couple is the cross-device feature fusion function, which performs nonlinear weighted fusion based on the coupling matrix.

[0052] Step S6 includes:

[0053] Step S6-1: Encode the three-dimensional demand matrix D into a dynamic vector sequence V={v1,v2,...,vt} through a fully connected network, where vt represents the encoded vector at time step t; each vector in the sequence belongs to R. K K is the encoding dimension, which contains the resource demand characteristics within a preset time period in the future; sinusoidal positional encoding is introduced in the encoding process to preserve the temporal dependency of resource demand;

[0054] Step S6-2: Calculate the stage-transmitted urgency E based on the coupling matrix. t Quantify the urgency of changes in resource demand during the transition from the current stage to the next stage:

[0055] E t =∑ d1,d2∈{0,1} M[c,ns,d1,d2] / ∑ 4 s=1 ∑ d1,d2 M[c,s,d1,d2]; where ns represents the next stage; d1,d2∈{0,1}: 0 corresponds to CPU, 1 corresponds to GPU; preset threshold θ E , when E t >θ E This indicates that resource demand is about to change significantly due to a stage transition;

[0056] Step S6-3: Transfer the urgency level E of the stage. t As a newly added identifier, it is concatenated to the dynamic vector to form the enhanced vector vt'=[vt;E t ], and generate scheduling trigger signals through a threshold classifier: when E in multiple consecutive time steps t Continue to rise and exceed θ E When a critical inflection point is detected in the GPU inflection point sequence, a scaling instruction is output.

[0057] A dynamic resource demand characterization system for a task lifecycle includes a stage division module, a multi-source data acquisition module, a resource transmission analysis module, a dual-stream resource prediction module, a demand fusion module, and a dynamic scheduling module.

[0058] The phase segmentation module deploys a monitoring agent when the task starts, dynamically dividing the task lifecycle into phases by capturing the sudden inflection point of GPU computing instructions in real time, and simultaneously monitoring the CPU instruction flow.

[0059] The multi-source data acquisition module collects task semantic features, CPU microarchitecture metrics, GPU hardware metrics, and interaction latency between the CPU and GPU; it performs spatiotemporal alignment on the collected data, extracts key features of the CPU / GPU respectively, and calculates collaborative efficiency metrics.

[0060] The resource transmission analysis module analyzes the resource consumption transfer patterns of similar tasks at different stages based on the historical task database, calculates the CPU-GPU resource transmission coefficient during stage transitions, and constructs a cross-stage resource demand coupling matrix.

[0061] The dual-stream resource prediction module constructs a dual-stream prediction model, using the coupling matrix as prior knowledge input to the prediction network. The CPU stream uses a temporal convolutional network to predict the CPU demand curve within a preset time period in the future; the GPU stream combines historical memory usage data and resource conduction coefficients to predict GPU resource inflection points.

[0062] The demand fusion module integrates the dual-stream forecast results and calculates the synergistic correlation degree and stage influence weight through the coupling matrix to generate a three-dimensional demand matrix;

[0063] The dynamic scheduling module encodes the three-dimensional demand matrix into a dynamic vector sequence. Based on the intensity of resource demand changes during the transition of the coupling matrix quantization stage, the quantization result is used as a new feature dimension and concatenated into the dynamic vector. Finally, the enhanced vector sequence is output to trigger the real-time scheduler to perform collaborative scheduling of CPU / GPU resources.

[0064] Compared with the prior art, the beneficial effects achieved by the present invention are:

[0065] This invention dynamically divides the task lifecycle into four stages by capturing the inflection point of GPU instruction surges in real time, replacing the traditional static stage division method, and more accurately adapting to the dynamic changes in resource requirements during task execution. At the same time, it constructs a cross-stage resource requirement coupling matrix based on a historical task library, quantifies the CPU / GPU resource transmission coefficient between adjacent stages, reveals the resource dependency pattern between stages, provides key prior knowledge for subsequent resource prediction, and significantly improves the accuracy of resource requirement prediction.

[0066] This invention constructs a dual-stream prediction model and combines it with a cross-stage resource coupling matrix to quantify the mutual influence and stage transition rules between CPU / GPU resources, thereby achieving dynamic resource demand representation. At the same time, it introduces a stage transmission urgency mechanism to quantify the urgency of resource changes during stage transitions, triggering real-time resource scheduling and achieving efficient collaboration between CPU / GPU resources. This not only improves the stability of task execution but also optimizes the real-time response capability of resource allocation. Attached Figure Description

[0067] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0068] Figure 1 This is a flowchart illustrating a method for representing dynamic resource requirements throughout a task's lifecycle. Detailed Implementation

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

[0070] Please see Figure 1 This invention provides a technical solution: a method for representing dynamic resource requirements throughout a task's lifecycle, comprising:

[0071] Step S1: Deploy a monitoring agent when the task starts, dynamically divide the task lifecycle stages by capturing the sudden inflection point of GPU computing instructions in real time, and synchronously monitor the CPU instruction flow;

[0072] Step S2: Collect task semantic features, CPU microarchitecture metrics, GPU hardware metrics, and interaction latency between CPU and GPU; perform spatiotemporal alignment on the collected data, extract key features of CPU / GPU respectively, and calculate collaborative efficiency metrics.

[0073] Step S3: Analyze the resource consumption transfer patterns of the same type of task at each stage based on the historical task database, calculate the CPU-GPU resource transmission coefficient during stage transition, and construct a cross-stage resource demand coupling matrix;

[0074] Step S4: Construct a dual-stream prediction model, using the coupling matrix as prior knowledge input to the prediction network. The CPU stream uses a temporal convolutional network to predict the CPU demand curve within a preset time period in the future; the GPU stream combines historical memory usage data and resource transmission coefficients to predict GPU resource inflection points.

[0075] Step S5: Integrate the dual-flow prediction results, calculate the synergistic correlation degree and stage influence weight through the coupling matrix, and generate a three-dimensional demand matrix;

[0076] Step S6: Encode the three-dimensional demand matrix into a dynamic vector sequence; based on the intensity of resource demand changes during the transition of the coupling matrix quantization stage, concatenate the quantization result as a new feature dimension into the dynamic vector, and finally output an enhanced vector sequence to trigger the real-time scheduler to perform collaborative scheduling of CPU / GPU resources.

[0077] Step S1 includes:

[0078] Step S1-1: The monitoring agent accesses the GPU instruction register through the PCIe bus interface to collect the instantaneous frequency of GPU computing instructions in real time, and at the same time collects the number of cycles of the CPU instruction stream through the CPU performance counter.

[0079] Step S1-2: In the initial stage after task startup, continuously collect the instantaneous frequency of GPU computing instructions at a preset sampling interval, calculate the average value of the frequency values ​​of N consecutive sampling points, and denot it as F. avg Based on this mean, a surge threshold α for GPU instructions is set, where α is F. avg A fixed multiple: α = k × F avg , where k is an empirical coefficient preset according to the task type; the GPU instruction frequency collected in real time, denoted as F(t), is continuously detected, where F(t) represents the GPU instruction frequency at time t;

[0080] Set jump point determination conditions:

[0081] First, the real-time GPU instruction frequency F(t) ≥ T is collected over n or more consecutive sampling periods. Second, the frequency growth rate ΔF over these n periods is calculated: ΔF = (F(t) - F(tn)) / F(tn), where F(tn) represents the instantaneous frequency of GPU computation instructions collected at n sampling periods before the current detection time t. If the growth rate exceeds 50%, the starting time of this interval is determined as the transition point.

[0082] Steps S1-3: Using the transition point as the time node and combining it with the GPU instruction frequency, the lifecycle is divided into four stages:

[0083] When F(t) < 0.1α and it is within the time period from task start to the first transition point, it is determined to be the initialization phase; during this phase, GPU computation instructions are sparse, and the task is mainly CPU-driven preprocessing work.

[0084] When 0.1α <= F(t) < α, and it is in the period after the first transition point and the frequency has not stably exceeded the threshold, and the frequency growth rate exceeds the preset value for several consecutive cycles, it is determined to be the climbing phase. In this phase, GPU computing tasks are gradually started, resource demand transitions from CPU to GPU, and the instruction frequency continues to increase with the increase in computing intensity.

[0085] When F(t)>=α and the frequency fluctuation amplitude within A consecutive sampling periods is ≤ε, it is determined to be in a steady state. Here, A is the preset stable observation window length and ε is the preset fluctuation threshold coefficient. Both are dynamically adjusted based on historical data according to the task type. In this stage, the GPU enters a high-intensity computing state, the resource requirements of the CPU and GPU remain stable and coordinated, the computing efficiency remains at a high level, and the resource consumption characteristics do not fluctuate significantly.

[0086] When F(t) < 0.1α, and the frequency first drops below 0.1α after the steady-state phase ends and begins a continuous downward trend until the task ends, it is determined to be the convergence phase. During this phase, GPU computing tasks gradually terminate, the instruction frequency decreases, the resource focus shifts back to the CPU, and subsequent processing work becomes the main task.

[0087] Example 1: Taking an image recognition task as an example, the monitoring agent calls NVMLAPI through the PCIe bus interface to collect the instantaneous frequency of GPU computing instructions in real time; at the same time, based on the CPU performance counter library, it collects the number of cycles of the CPU instruction stream at a period of 1ms.

[0088] After the task starts, in the initial stage, the GPU instruction frequency is continuously collected at a sampling interval of 10ms. The average value of the frequency values ​​of 100 consecutive sampling points is calculated, and F=500MHz is obtained. If k=2 is set, the burst threshold α=2×500=1000MHz.

[0089] In real-time detection, if F(t) ≥ 1000MHz (10-14ms) for 5 consecutive sampling periods, and the frequency growth rate ΔF = (F(14ms) - F(9ms)) / F(9ms) = 60% > 50% for these 5 periods, then the 10ms is determined to be the transition point.

[0090] Initialization phase: From task start to the first transition point (10ms) (0-9ms), the GPU instruction frequency F(t) < 0.1×1000=100MHz. The task is mainly CPU-driven image preprocessing, such as data decoding and normalization.

[0091] Climbing phase: After the first jump point (10-50ms), 0.1α (100MHz) ≤ F(t) < α (1000MHz), and the frequency increases by more than 10% for several consecutive cycles (F(t) increases from 100MHz to 800MHz within 10-20ms), the GPU gradually starts computing, and the resource demand transitions from CPU to GPU;

[0092] Steady-state phase: F(t)≥1000MHz, and the frequency fluctuation amplitude within 20 consecutive sampling periods (50-70ms) is ≤5%, the GPU enters high-intensity computing (such as model inference), and the CPU and GPU work together to stabilize;

[0093] Convergence Phase: After the steady-state phase ends (70ms later), F(t) < 100MHz and continues to decrease. The GPU task terminates, and the focus of resources shifts back to the CPU for post-processing, such as result integration and output.

[0094] Step S2 includes:

[0095] Step S2-1: Based on the stage boundaries defined in Step S1, synchronously collect task semantic features, CPU microarchitecture metrics, GPU hardware metrics, and the interaction latency between the CPU and GPU.

[0096] Task semantic features include task type, algorithm name, input data size, and preset parameters;

[0097] CPU microarchitecture metrics include core utilization (the load percentage of each CPU core), L3 cache hit rate (the ratio of cache hits to total accesses), thread scheduling latency (the average waiting time for a thread from ready to execution), and memory bandwidth utilization (the ratio of actual memory read / write speed to theoretical peak speed).

[0098] GPU hardware metrics include processor utilization, video memory utilization (the ratio of used video memory to total video memory), video memory read / write bandwidth (the amount of video memory data transferred per second), PCIe data transfer rate (the data transfer speed between the CPU and the GPU), and kernel function execution time (the time from start to finish for each GPU kernel function).

[0099] Interaction latency data between the CPU and GPU includes data transmission latency (the time it takes for the CPU to send data to the GPU or vice versa) and synchronization wait latency (the idle time for the CPU to wait for the GPU to complete calculations or for the GPU to wait for data from the CPU).

[0100] Step S2-2: Using the timestamps of GPU instruction acquisition in Step S1 as a benchmark, linear interpolation is used to supplement the missing time points of CPU metrics. The formula is:

[0101] The CPU index value at time t after alignment is calculated as: previous sampling point value + (next sampling point value - previous sampling point value) × (t - previous sampling time) / (next sampling time - previous sampling time). The collected discrete indices are classified and stored according to "stage-device-index".

[0102] Step S2-3: Extract key features from the aligned data, including:

[0103] Key CPU characteristics include: peak core utilization (the maximum CPU core utilization in that phase), trough cache hit rate (the minimum cache hit rate in that phase), and average thread scheduling latency (the average level of scheduling latency in that phase), which are used to characterize the CPU's performance characteristics in different phases.

[0104] Key GPU features include: peak memory usage, average stream processor utilization, memory read / write bandwidth fluctuation (standard deviation of bandwidth within the stage), and kernel function execution time distribution (e.g., 90th percentile value, reflecting the execution time of most kernel functions), which are used to characterize the resource load characteristics of the GPU at different stages.

[0105] Step S2-4: Based on the interaction data between the CPU and GPU, calculate quantitative indicators reflecting the efficiency of their collaborative work, including:

[0106] Data transfer efficiency: Transfer efficiency = 1 - (PCIe transfer time / GPU computation time);

[0107] (The closer the value is to 1, the less the data transmission hinders the computation, and the better the collaboration.)

[0108] Resource idle rate: Idle rate = (CPU waiting time for GPU + GPU waiting time for CPU) / Total duration of the phase; (The lower the value, the less idle resources the CPU and GPU have, and the more efficient their collaboration).

[0109] Pipeline matching degree: Matching degree = CPU data preprocessing time / GPU computation time;

[0110] (The closer the value is to 1, the better the pace of CPU preprocessing and GPU computation is matched, avoiding long waiting times for one side.)

[0111] Step S3 includes:

[0112] Step S3-1: Based on the semantic features of the tasks collected in Step S2, calculate the cosine similarity of the semantic feature vectors from the historical task database and select tasks with a matching degree ≥ 80%; for each selected historical task, extract the key features and quantitative indicators of each stage according to the four stages divided in Step S1; clean the extracted historical data, remove outliers (such as sudden increases / decreases in resource consumption due to hardware failure, identified by the Z-score method: |data value - mean| > 3 times the standard deviation is considered an anomaly), and supplement missing data (for a small number of missing stage resource values, use the median of the same stage of the same type of task to fill in);

[0113] Step S3-2: The resource transmission coefficient is used to quantify the impact of resource consumption in the previous stage on resource demand in the next stage. The four stages of the task life cycle are connected in sequence. Only the transmission coefficient between adjacent stages is calculated, that is, the following three sets of coefficients need to be calculated: initialization → ramp-up, ramp-up → steady state, and steady state → convergence.

[0114] CPU resource transfer coefficient K cpu : This represents the impact of CPU resource consumption in stage s on the CPU resource demand in stage s+1; the calculation formula is: K cpu =cov(C s C s+1 ) / var(C s ); where C s For the total CPU requirement of stage s in the historical task, C s+1 Let be the total CPU demand for stage s+1; cov be the covariance, measuring the degree of synchronous change between the two; var be the variance, measuring the fluctuation of stage s itself; K cpu The larger the value, the more significant the impact of CPU consumption in stage s on CPU demand in stage s+1. A positive coefficient indicates that an increase in CPU consumption in the previous stage leads to an increase in CPU demand in the next stage; a negative coefficient indicates that an increase in resource consumption in the previous stage leads to a decrease in resource demand in the next stage.

[0115] GPU resource conduction coefficient K gpu : This represents the degree to which the GPU resource consumption in the previous stage s affects the GPU resource demand in the next stage s+1; the calculation logic is the same as that for CPU, and the formula is: K gpu =cov(G s G s+1 ) / var(G s );

[0116] Among them: G s Gs+1 represents the total GPU resource requirement of stage s in the historical task; Gs+1 represents the total GPU resource requirement of stage s+1 in the same historical task; cov(G s G s+1) represents G s With G s+1 The covariance measures the degree of synchronous change in GPU resource requirements between two phases; var(G s ) represents G s The variance measures the fluctuation range of GPU resource requirements in stage s.

[0117] Step S3-3: Construct a cross-stage resource demand coupling matrix with a dimension of 4×4×2×2, representing source stage × target stage × source device × target device. The source device and target device correspond to CPU and GPU, respectively. Therefore, the matrix elements cover four types of transmission relationships: CPU→CPU, CPU→GPU, GPU→CPU, and GPU→CPU. Only adjacent stages are filled with corresponding coefficients, and non-adjacent stages and elements in the same stage are set to 0. The matrix is ​​normalized to map the coefficients to the interval [-1,1], thus forming the cross-stage resource demand coupling matrix.

[0118] Example 2: Taking an image recognition task as an example, the task type is image classification, the algorithm is ResNet-50, the input data size is 1000 images, and the preset parameters are batch size=32.

[0119] Tasks with semantic similarity ≥ 80% are selected from the historical task library, such as other image classification tasks, with VGG / ResNet algorithms and similar input sizes. For the 50 selected historical tasks, according to the four stages of step S1 (initialization, ramp-up, steady state, convergence), the total CPU requirement (average CPU utilization × time in the initialization stage) and the total GPU requirement (GPU memory usage × time in the steady state stage) are extracted for each stage, and outliers are cleaned.

[0120] Calculate the resource transmission coefficient between adjacent stages:

[0121] Initialization → Climbing Phase: CPU Resource Transmission Coefficient K cpu =cov(initialization phase CPU demand, ramp-up phase CPU demand) / var(initialization phase CPU demand)=0.8 (positive correlation; the more thorough the initialization CPU preprocessing, the higher the ramp-up phase CPU demand).

[0122] Climbing → Steady-state phase: GPU resource transfer coefficient K gpu =cov(GPU demand during the ramp-up phase, GPU demand during the steady-state phase) / var(GPU demand during the ramp-up phase)=1.2 (positive correlation; the increase in GPU computing intensity during the ramp-up phase will significantly increase the GPU demand during the steady-state phase).

[0123] Construct a 4×4×2×2 coupling matrix:

[0124] The matrix dimensions are: source stage (4) × target stage (4) × source device (2) × target device (2), where:

[0125] Source phase / target phase: initialization, ramp-up, steady state, convergence (index 0~3);

[0126] Source device / target device: CPU (index 0), GPU (index 1);

[0127] The matrix elements represent the resource transfer coefficients from "source stage - source device" to "target stage - target device"; for example:

[0128] The element [0→1,0→0] represents "the impact of CPU resource consumption during the initialization phase on CPU demand during the ramp-up phase";

[0129] The element [1→2, 1→1] represents "the impact of GPU resource consumption during the ramp-up phase on GPU demand during the steady-state phase";

[0130] Based on the calculated coefficients of three adjacent stages, fill in some elements of the matrix:

[0131] Taking the initialization → ascent phase (source phase 0 → target phase 1) as an example:

[0132] CPU→CPU:K cpu =0.8 (Initial CPU preprocessing impacts increased CPU demand).

[0133] CPU→GPU: K gpu =0.7 (The more thorough the initial CPU preprocessing, the higher the GPU demand during the ramp-up phase, such as improving data loading efficiency and reducing GPU waiting time).

[0134] GPU→CPU: K cpu =0.1 (GPU demand has a relatively weak impact on CPU demand during the initialization phase).

[0135] GPU → GPU: K gpu =0.2 (Initial GPU demand has a small impact on increasing GPU demand).

[0136] Step S4 includes:

[0137] Step S4-1: The CPU stream is predicted using a temporal convolutional network. The historical CPU metric sequence extracted in step S2 is input into the temporal convolutional network according to the time window. Multi-scale temporal dependencies are captured through a multi-layer causal convolutional structure. Each convolutional layer is followed by a BatchNorm layer and a ReLU activation function. Residual connections are introduced, and the input is directly added to the output of the convolutional layer. A Dropout layer is added before the fully connected layer, and the dropout rate is set. Finally, the CPU demand sequence for the next 30 time steps is output, which includes the predicted values ​​of various CPU feature metrics.

[0138] Step S4-2: The GPU stream combines historical memory usage data and the resource transmission coefficient calculated in step S3 to predict inflection points. First, the first derivative of the historical memory usage sequence is calculated to identify suspicious points where the absolute value of the derivative exceeds a threshold. Features of W time steps before and after each suspicious point are extracted to construct a feature vector. The feature vector is input into a 3-layer fully connected network with 64, 32, and 1 neurons in each layer. The output layer uses the Sigmoid activation function to output the probability value that the suspicious point is a true inflection point. The probability values ​​are filtered by a threshold η to generate a sequence containing timestamps and inflection point types.

[0139] Example 3

[0140] CPU stream prediction results:

[0141] Input data: a historical sequence of CPU metrics (core utilization, L3 cache hit rate, thread scheduling latency), divided into 20ms time windows;

[0142] Network structure: 3 layers of causal convolutions (kernel size = 5, dilation factor = 1, 2, 4), each layer followed by BatchNorm + ReLU; residual connections adjust the dimension through 1×1 convolutions; dropout layer dropout rate = 0.3;

[0143] Output: CPU demand curves for the next 30 time steps (600ms), including predicted peak core utilization (average 85%) and predicted trough cache hit rate (average 72%).

[0144] GPU flow inflection point prediction results:

[0145] Input data: Historical memory usage sequence (sampling interval 5ms), combined with the resource transfer coefficient K calculated in step S3. gpu (Relationship between rising and steady-state GPU demand);

[0146] Feature extraction: Calculate the first derivative of the video memory sequence and identify suspicious points where the absolute value of the derivative is greater than a threshold (θ=80MB / ms); extract features (video memory value, derivative value, K) from 15 time steps before and after each suspicious point. gpu (PCIe transfer rate);

[0147] Model structure: 3-layer fully connected network (128→64→1), output layer Sigmoid activation, threshold η=0.85 to filter inflection point probability values;

[0148] Output: A sequence containing timestamps and inflection point type ("climbing → steady state"): The memory usage derivative was detected to suddenly drop from +90MB / ms to -50MB / ms at 120ms, which was determined to be an inflection point of "steady state → convergence";

[0149] Step S5 includes:

[0150] Step S5-1: Spatiotemporally align the demand curve of the CPU stream output and the inflection point sequence of the GPU stream output from Step S4. Using the GPU inflection point timestamp as a reference, resample the CPU demand curve to the same time granularity using linear interpolation to generate an aligned binary sequence {(CPU t GPU t} T t=1 Where T represents the total time step, CPU t Represents the CPU resource vector at time t, GPU t This represents the GPU state vector at the corresponding time point;

[0151] Step S5-2: Based on the coupling matrix constructed in step S3, calculate the co-correlation degree C at each time step. t and stage influence weight W t The formula for calculating the degree of synergy is:

[0152] C t =∑ 4 s=1 ∑ d1,d2∈{CPU,GPU} M[s,c,d1,d2]·Similarity(d1,CPU t ,d2,GPU t );

[0153] Where M[s,c,d1,d2] are the elements of the coupling matrix constructed in step S3, representing the transmission coefficient of "source device d1 → target device d2" in the current stage c from the historical stage s; the Similarity function quantifies the matching degree between the current resource state and the historical stage, and calculates the cosine similarity between the current resource state vector and the feature vector of the historical stage.

[0154] Stage Influence Weight W t This represents the percentage of influence of each historical stage on the current time t, obtained by normalizing the corresponding row vectors of the coupling matrix using the Softmax function;

[0155] Step S5-3: Using the collaborative correlation degree and stage influence weight as coefficients, perform weighted aggregation on the spatiotemporally aligned resource sequence to generate a three-dimensional demand matrix D∈R. T×2×F Where T is the time step, 2 corresponds to the two device dimensions of CPU and GPU, and F is the resource feature dimension; the matrix element calculation formula is: D[t,d,f]=C t ·(W t Couple (CPU) t [f],GPU t [f]); where D[t,d,f] represents the element values ​​of time t, device d, and feature f in the matrix; Couple is the cross-device feature fusion function, which performs nonlinear weighted fusion based on the coupling matrix.

[0156] Example 4: Using the GPU inflection point timestamp as a reference, the CPU demand curve is resampled to a 5ms time granularity through linear interpolation, generating an aligned binary sequence {(CPU t GPU t} T t=1 (T=120 time steps);

[0157] Collaborative correlation degree C t Based on the coupling matrix M, the current stage is the steady-state stage (c=2). The sum of the transmission coefficients from the historical stage s=1 (climbing stage) to the steady-state stage is calculated as: M[1,2,1,1]=1.05).

[0158] Stage Influence Weight W t By normalizing the row vectors of the coupling matrix using Softmax, the influence weight during the ascent phase is 0.7, and the self-influence weight during the steady-state phase is 0.3.

[0159] Generating matrix D∈R 120×2×4 Where D[t, GPU, peak memory usage] = Ct·(Wt·Couple(CPUt[thread scheduling latency], GPUt[memory read / write bandwidth])), the Couple function implements cross-device feature weighting through the coupling matrix;

[0160] Step S6 includes:

[0161] Step S6-1: Encode the three-dimensional demand matrix D into a dynamic vector sequence V={v1,v2,...,vt} through a fully connected network, where vt represents the encoded vector at time step t; each vector in the sequence belongs to R. K K is the encoding dimension, which contains the resource demand characteristics within a preset time period in the future; sinusoidal positional encoding is introduced in the encoding process to preserve the temporal dependency of resource demand;

[0162] Step S6-2: Calculate the stage-transmitted urgency E based on the coupling matrix. t Quantify the urgency of changes in resource demand during the transition from the current stage to the next stage:

[0163] E t =∑ d1,d2∈{0,1} M[c,ns,d1,d2] / ∑ 4 s=1 ∑ d1,d2 M[c,s,d1,d2]; where ns represents the next stage; d1,d2∈{0,1}: 0 corresponds to CPU, 1 corresponds to GPU; preset threshold θ E , when E t >θ E This indicates that resource demand is about to change significantly due to a stage transition;

[0164] Step S6-3: Transfer the urgency level E of the stage. t As a newly added identifier, it is concatenated to the dynamic vector to form the enhanced vector vt'=[vt;E t ], and generate scheduling trigger signals through a threshold classifier: when E in multiple consecutive time steps t Continue to rise and exceed θ E When a critical inflection point is detected in the GPU inflection point sequence, a scaling instruction is output.

[0165] Example 4: The three-dimensional matrix D is encoded into a dynamic vector sequence V={v1,v2,...,v120} through a fully connected network (2 layers, number of neurons 256→128); sinusoidal positional encoding is introduced to preserve temporal dependencies;

[0166] Calculate E t The current stage is the steady state stage, and the next stage is the convergence stage.

[0167] Numeric: M[2,3,1,1]=-0.5 (the coefficient of influence of GPU memory usage in steady state on GPU demand in convergence phase);

[0168] Denominator: M[2,0,1,1]+M[2,1,1,1]+M[2,2,1,1]+M[2,3,1,1]=0.5;

[0169] E t =-0.5 / 0.5=-1.0 (Due to a decrease in resource demand, E) t (negative value)

[0170] Preset threshold θ E =0.7, when E t <θ E At that time, the resource release mechanism is triggered;

[0171] E t =-1.0 is concatenated to the dynamic vector to form the enhanced vector vt'=[vt;-1.0];

[0172] A threshold classifier is used: a two-layer fully connected network, with the number of neurons decreasing from 64 to 1, sigmoid activation, to generate a scheduling signal.

[0173] The "steady state → convergence" inflection point (120ms) in the GPU inflection point sequence was detected, and E t =-1.0<θE=0.7, output scaling instructions, for example: reduce the parallelism of the GPU kernel function from 16 to 8, and release 50% of the video memory.

[0174] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A method for representing dynamic resource requirements throughout a task's lifecycle, characterized in that: The method includes: Step S1: Deploy a monitoring agent when the task starts, dynamically divide the task lifecycle stages by capturing the sudden inflection point of GPU computing instructions in real time, and synchronously monitor the CPU instruction flow; Step S1 includes: Step S1-1: The monitoring agent accesses the GPU instruction register through the PCIe bus interface to collect the instantaneous frequency of GPU computing instructions in real time, and at the same time collects the number of cycles of the CPU instruction stream through the CPU performance counter. Step S1-2: In the initial stage after task startup, continuously collect the instantaneous frequency of GPU computing instructions at a preset sampling interval, calculate the average value of the frequency values ​​of N consecutive sampling points, and denot it as F. avg Based on this mean, a surge threshold α for GPU instructions is set, where α is F. avg A fixed multiple: α = k × F avg , where k is an empirical coefficient preset according to the task type; the GPU instruction frequency collected in real time, denoted as F(t), is continuously detected, where F(t) represents the GPU instruction frequency at time t; Set jump point determination conditions: First, the real-time GPU instruction frequency F(t) ≥ α is collected over n or more consecutive sampling periods. Second, the frequency growth rate ΔF over these n periods is calculated: ΔF = (F(t) - F(tn)) / F(tn), where F(tn) represents the instantaneous frequency of GPU computation instructions collected at n sampling periods before the current detection time t. If the growth rate exceeds 50%, the starting time of this interval is determined as the transition point. Steps S1-3: Using the transition point as the time node and combining it with the GPU instruction frequency, the lifecycle is divided into four stages: When F(t) < 0.1α, and it is within the time period from task start to the first transition point, it is determined to be the initialization phase; When 0.1α <= F(t) < α, and it is in the period after the first transition point and the frequency has not stably exceeded the threshold, and the frequency growth rate exceeds the preset value for multiple consecutive cycles, it is determined to be in the climbing phase. When F(t)>=α and the frequency fluctuation amplitude within A consecutive sampling periods is ≤ε, it is determined to be in a steady state; where A is the preset stable observation window length and ε is the preset fluctuation threshold coefficient, both of which are dynamically adjusted based on historical data according to the task type. When F(t) < 0.1α, and the frequency first falls below 0.1α after the end of the steady-state phase and begins a continuous downward trend until the end of the task, it is determined to be the convergence phase; Step S2: Collect task semantic features, CPU microarchitecture metrics, GPU hardware metrics, and interaction latency between the CPU and GPU; perform spatiotemporal alignment on the collected data, extract key features of each CPU / GPU, and calculate collaborative efficiency metrics; the collaborative efficiency metrics include: Data transfer efficiency: Transfer efficiency = 1 - (PCIe transfer time / GPU computation time); Resource idle rate: Idle rate = (CPU waiting time for GPU + GPU waiting time for CPU) / Total duration of the stage; Pipeline matching degree: Matching degree = CPU data preprocessing time / GPU computation time; Step S3: Analyze the resource consumption transfer patterns of the same type of task at each stage based on the historical task database, calculate the CPU-GPU resource transmission coefficient during stage transition, and construct a cross-stage resource demand coupling matrix; Among them, the CPU resource transmission coefficient K cpu : This represents the impact of CPU resource consumption in stage s on the CPU resource demand in stage s+1; the calculation formula is: K cpu =cov(C s C s+1 ) / var(C s ); where C s For the total CPU requirement of stage s in the historical task, C s+1 Let be the total CPU demand for stage s+1; cov be the covariance, measuring the degree of synchronous change between the two; var be the variance, measuring the fluctuation of stage s itself; K cpu The larger the value, the more significant the impact of CPU consumption in stage s on CPU demand in stage s+1. A positive coefficient indicates that an increase in CPU consumption in the previous stage leads to an increase in CPU demand in the next stage; a negative coefficient indicates that an increase in resource consumption in the previous stage leads to a decrease in resource demand in the next stage. GPU resource conduction coefficient K gpu : This represents the degree to which the GPU resource consumption in the previous stage s affects the GPU resource demand in the next stage s+1; the calculation logic is the same as that for CPU, and the formula is: K gpu =cov(G s G s+1 ) / var(G s ); where: G s Gs+1 represents the total GPU resource requirement of stage s in the historical task; Gs+1 represents the total GPU resource requirement of stage s+1 in the same historical task; cov(G s G s+1 ) represents G s With G s+1 The covariance measures the degree of synchronous change in GPU resource requirements between two phases; var(G s ) represents G s The variance measures the fluctuation range of GPU resource requirements in stage s. The cross-stage resource demand coupling matrix is ​​constructed with a dimension of 4×4×2×2, representing source stage × target stage × source device × target device. The source device and target device correspond to CPU and GPU, respectively. Therefore, the matrix elements cover four types of transmission relationships: CPU→CPU, CPU→GPU, GPU→CPU, and GPU→GPU. The corresponding coefficients are filled only in adjacent stages, and the elements in non-adjacent stages and the same stage are set to 0. The matrix is ​​normalized to map the coefficients to the interval [-1,1], thus forming the cross-stage resource demand coupling matrix. Step S4: Construct a dual-stream prediction model, using the coupling matrix as prior knowledge input to the prediction network. The CPU stream uses a temporal convolutional network to predict the CPU demand curve within a preset time period in the future; the GPU stream combines historical memory usage data and resource transmission coefficients to predict GPU resource inflection points. Step S5: Integrate the dual-flow prediction results, calculate the synergistic correlation degree and stage influence weight through the coupling matrix, and generate a three-dimensional demand matrix; Step S5 includes: Step S5-1: Spatiotemporally align the demand curve of the CPU stream output and the inflection point sequence of the GPU stream output from Step S4. Using the GPU inflection point timestamp as a reference, resample the CPU demand curve to the same time granularity using linear interpolation to generate an aligned binary sequence {(CPU t GPU t } T t=1 Where T represents the total time step, CPU t Represents the CPU resource vector at time t, GPU t This represents the GPU state vector at the corresponding time point; Step S5-2: Based on the coupling matrix constructed in step S3, calculate the co-correlation degree C at each time step. t and stage influence weight W t The formula for calculating the degree of synergy is: C t =∑ 4 s=1 ∑ d1,d2∈{CPU,GPU} M[s,c,d1,d2]·Similarity(d1,CPU t ,d2,GPU t ); Where M[s,c,d1,d2] are the elements of the coupling matrix constructed in step S3, representing the transmission coefficient of "source device d1 → target device d2" in the current stage c from the historical stage s; the Similarity function quantifies the matching degree between the current resource state and the historical stage, and calculates the cosine similarity between the current resource state vector and the feature vector of the historical stage. Stage Influence Weight W t This represents the percentage of influence of each historical stage on the current time t, obtained by normalizing the corresponding row vectors of the coupling matrix using the Softmax function; Step S5-3: Using the collaborative correlation degree and stage influence weight as coefficients, perform weighted aggregation on the spatiotemporally aligned resource sequence to generate a three-dimensional demand matrix D∈R. T×2×F Where T is the time step, 2 corresponds to the two device dimensions of CPU and GPU, and F is the resource feature dimension; the formula for calculating the elements of the three-dimensional demand matrix is: D[t,d,f]=C t ·(W t Couple (CPU) t [f],GPU t [f]); where D[t,d,f] represents the element values ​​of time t, device d, and feature f in the matrix; C t For collaborative correlation, W t The stage influence weights are defined by the coupling matrix; Couple is a cross-device feature fusion function that performs non-linear weighted fusion based on the coupling matrix. Step S6: Encode the three-dimensional demand matrix into a dynamic vector sequence; based on the intensity of resource demand change during the transition of the coupling matrix quantization stage, the quantization result is used as a new feature dimension and concatenated into the dynamic vector, and finally the enhanced vector sequence is output to trigger the real-time scheduler to perform collaborative scheduling of CPU / GPU resources; Step S6 includes: Step S6-1: Encode the three-dimensional demand matrix D into a dynamic vector sequence V={v1,v2,...,vt} through a fully connected network, where vt represents the encoded vector at time step t; each vector in the sequence belongs to R. K K is the encoding dimension, which contains the resource demand characteristics within a preset time period in the future; sinusoidal positional encoding is introduced in the encoding process to preserve the temporal dependency of resource demand; Step S6-2: Calculate the stage-transmitted urgency E based on the coupling matrix. t Quantify the urgency of changes in resource demand during the transition from the current stage to the next stage: E t =∑ d1,d2∈{0,1} M[c,ns,d1,d2] / ∑ 4 s=1 ∑ d1,d2 M[c,s,d1,d2]; where ns represents the next stage; d1,d2∈{0,1}: 0 corresponds to CPU, 1 corresponds to GPU; preset threshold θ E , when E t >θ E This indicates that resource demand is about to change significantly due to a stage transition; Step S6-3: Transfer the urgency level E of the stage. t As a newly added identifier, it is concatenated to the dynamic vector to form the enhanced vector vt'=[vt;E t ], and generate scheduling trigger signals through a threshold classifier: when E in multiple consecutive time steps t Continue to rise and exceed θ E When a critical inflection point is detected in the GPU inflection point sequence, a scaling instruction is output.

2. The method for representing dynamic resource requirements in a task lifecycle according to claim 1, characterized in that: Step S2 includes: Step S2-1: Based on the stage boundaries defined in Step S1, synchronously collect task semantic features, CPU microarchitecture metrics, GPU hardware metrics, and the interaction latency between the CPU and GPU. The task semantic features include task type, algorithm name, input data size, and preset parameters; The CPU microarchitecture metrics include core utilization, L3 cache hit rate, thread scheduling latency, and memory bandwidth utilization. The GPU hardware metrics include processor utilization, video memory usage, video memory read / write bandwidth, PCIe data transfer rate, and kernel function execution time. The interaction latency between the CPU and GPU includes data transmission latency and synchronization waiting latency; Step S2-2: Using the timestamp of GPU instruction acquisition in step S1 as a benchmark, use linear interpolation to supplement the missing time point data of CPU indicators; classify and store the acquired discrete indicators according to "stage-device-indicator"; Step S2-3: Extract key features from the aligned data, including: Key CPU characteristics: peak core utilization, trough cache hit rate, and average thread scheduling latency within a given period; Key GPU characteristics: peak memory usage within a period, average stream processor utilization, memory read / write bandwidth fluctuation, and kernel function execution time distribution.

3. The method for representing dynamic resource requirements in a task lifecycle according to claim 1, characterized in that: Step S3 includes: Step S3-1: Based on the semantic features of the task collected in step S2, calculate the cosine similarity of the semantic feature vectors from the historical task database and select tasks with a matching degree ≥ 80%; for each selected historical task, extract the key features and quantitative indicators of each stage according to the four stages divided in step S1 and step S2; clean the extracted historical data, remove outliers, and supplement missing data. Step S3-2: The resource transmission coefficient is used to quantify the impact of resource consumption in the previous stage on resource demand in the next stage. The four stages of the task life cycle are connected in sequence. Only the transmission coefficient between adjacent stages is calculated, that is, the following three sets of coefficients need to be calculated: initialization → ramp-up, ramp-up → steady state, and steady state → convergence.

4. The method for representing dynamic resource requirements in a task lifecycle according to claim 1, characterized in that: Step S4 includes: Step S4-1: The CPU stream is predicted using a temporal convolutional network. The historical CPU metric sequence extracted in step S2 is input into the temporal convolutional network according to the time window. Multi-scale temporal dependencies are captured through a multi-layer causal convolutional structure. Each convolutional layer is followed by a BatchNorm layer and a ReLU activation function. Residual connections are introduced, and the input is directly added to the output of the convolutional layer. A Dropout layer is added before the fully connected layer, and the dropout rate is set. Finally, the CPU demand sequence for the next 30 time steps is output, which includes the predicted values ​​of various CPU feature metrics. Step S4-2: The GPU stream combines historical memory usage data and the resource transmission coefficient calculated in step S3 to predict inflection points. First, the first derivative of the historical memory usage sequence is calculated to identify suspicious points where the absolute value of the derivative exceeds a threshold. Features of W time steps before and after each suspicious point are extracted to construct a feature vector. The feature vector is input into a 3-layer fully connected network with 64, 32, and 1 neurons in each layer. The output layer uses the Sigmoid activation function to output the probability value that the suspicious point is a true inflection point. The probability values ​​are filtered by a threshold η to generate a sequence containing timestamps and inflection point types.

5. A dynamic resource requirement representation system for a task lifecycle, applied to the dynamic resource requirement representation method for a task lifecycle as described in any one of claims 1-4, characterized in that: The system includes a phase division module, a multi-source data acquisition module, a resource transmission analysis module, a dual-stream resource prediction module, a demand fusion module, and a dynamic scheduling module. The phase division module deploys a monitoring agent when the task starts, dynamically dividing the task lifecycle phases by capturing the sudden inflection point of GPU computing instructions in real time, and synchronously monitoring the CPU instruction flow. The multi-source data acquisition module collects task semantic features, CPU microarchitecture metrics, GPU hardware metrics, and interaction latency between the CPU and GPU; it performs spatiotemporal alignment on the collected data, extracts key features of the CPU / GPU respectively, and calculates collaborative efficiency metrics. The resource transmission analysis module analyzes the resource consumption transfer patterns of the same type of task at each stage based on the historical task database, calculates the CPU-GPU resource transmission coefficient at the stage transition, and constructs a cross-stage resource demand coupling matrix. The dual-stream resource prediction module constructs a dual-stream prediction model, using the coupling matrix as prior knowledge input into the prediction network. The CPU stream uses a temporal convolutional network to predict the CPU demand curve within a preset time period in the future; the GPU stream combines historical memory usage data and resource conduction coefficients to predict GPU resource inflection points. The demand fusion module integrates the dual-stream prediction results and calculates the synergistic correlation degree and stage influence weight through the coupling matrix to generate a three-dimensional demand matrix. The dynamic scheduling module encodes the three-dimensional demand matrix into a dynamic vector sequence; based on the intensity of resource demand changes during the transition of the coupling matrix quantization stage, the quantization result is used as a new feature dimension and concatenated into the dynamic vector, and finally the enhanced vector sequence is output to trigger the real-time scheduler to perform collaborative scheduling of CPU / GPU resources.

Images