Power prediction methods, systems, devices, and media

Abstract

The application provides a power prediction method, system, device and medium, and relates to the technical field of power prediction, and comprises the following steps: generating a context record corresponding to a power prediction model file according to an environment in which the power prediction model file is to be deployed, a training data set used and a hyperparameter dictionary thereof; creating a target container image corresponding to the power prediction model file based on the context record, and deploying the target container image to a target container node that meets a resource quota requirement corresponding to the context record to obtain a Pod instance carrying a power prediction microservice; if a power prediction request is received, sending the power prediction request to the Pod instance to obtain a power prediction result fed back by the Pod instance for the power prediction request. The application can realize consistent deployment and stable operation of the power prediction microservice, thereby improving the accuracy of power prediction.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of power prediction, in particular to a power prediction method, system, device and medium. BACKGROUND

[0002] In the field of power prediction, the Python library version, CUDA (Compute Unified Device Architecture) driver, base operating system image and runtime configuration file relied on by the power prediction model are usually manually specified by the developer in the local environment and fixed in the container image. Due to the high dependence of the deployment process from development to production on the running environment, the same power prediction microservice is extremely prone to inaccurate power prediction when deployed in different clusters. SUMMARY

[0003] Therefore, the purpose of the present application is to provide a power prediction method, system, device and medium, which can realize consistent deployment and stable operation of the power prediction microservice, thereby improving the accuracy of power prediction.

[0004] In a first aspect, the present application provides a power prediction method, comprising: generating a context record corresponding to the power prediction model file according to the environment in which the power prediction model file to be deployed is located, the training data set used and the hyperparameter dictionary thereof; creating a target container image corresponding to the power prediction model file based on the context record, and deploying the target container image to a target container node that meets the resource quota requirement corresponding to the context record, to obtain a Pod instance carrying a power prediction microservice; if a power prediction request is received, sending the power prediction request to the Pod instance to obtain a power prediction result fed back by the Pod instance for the power prediction request.

[0005] In an embodiment, generating a context record corresponding to the power prediction model file according to the environment in which the power prediction model file to be deployed is located, the training data set used and the hyperparameter dictionary thereof comprises: calling an environment perception probe to collect code version information, dependency environment information and running environment information of the environment in which the power prediction model file is located as an environment fingerprint; calling a double-layer data fingerprint generator to generate a file-level fingerprint and a content-level fingerprint based on the training data set used by the power prediction model file, and splicing the file-level fingerprint and the content-level fingerprint into a data set fingerprint; extracting the hyperparameter dictionary of the power prediction model file, and converting the hyperparameter dictionary into a structured hyperparameter after the hyperparameter dictionary is verified by parameter range and type constraints; Based on the environment fingerprint and dataset fingerprint, a semantic version number is generated according to preset rules. The semantic version number includes a major version number, a minor version number, and a patch number. The major version number is used to indicate whether the runtime environment information in the environment fingerprint has changed, the minor version number is used to indicate whether the dataset fingerprint has changed, and the patch number is used to indicate whether the code version information in the environment fingerprint has changed. Digitally sign the identifier, environment fingerprint, dataset fingerprint, structured hyperparameters, and semantic version number corresponding to the power prediction model file to obtain the context record associated with the power prediction model file; Register the power prediction model file and its associated context record to the model registry center.

[0006] In one implementation, creating a target container image corresponding to the power prediction model file based on context records includes: Determine the base container image that matches the environment fingerprint from the pre-built container image library; Generate image configuration files based on structured hyperparameters; Write the dataset fingerprint into the label field of the base container image; Based on the base container image, image configuration file, and tag fields, construct the target container image corresponding to the power prediction model file.

[0007] In one implementation, the target container image is deployed to a target container node that meets the resource quota requirements corresponding to the context record, resulting in a Pod instance that supports the power prediction microservice, including: Map the dataset fingerprint to resource quota requirements; Construct the deployment configuration object corresponding to the power prediction model file, and configure the resource limit field in the deployment configuration object based on resource quota requirements; Scan the real-time resource status of container nodes in the container cluster and filter target container nodes by combining the resource limit field in the deployment configuration object.

[0008] In one implementation, the method further includes: Identify the monitoring objects corresponding to the power prediction model and attach the monitoring objects to the deployment configuration objects; Monitor the scaling metrics corresponding to the target container node by monitoring the target container node; Based on the scaling metrics and preset thresholds, the deployment configuration object is updated, and the target container node is scaled up or down based on the updated deployment configuration object.

[0009] In one implementation, a power prediction request is sent to a Pod instance to obtain a power prediction result from the Pod instance in response to the power prediction request, including: The communication transmission protocol is determined based on the real-time operating data carried in the power prediction request and the target semantic version number. When the power prediction request passes multi-level authentication, a standardized short-term token corresponding to the power prediction request is generated based on the real-time running data and the target semantic version number. The standardized short-term token is written with at least the target semantic version number and the target dataset fingerprint corresponding to the real-time running data. Based on the target semantic version number and target dataset fingerprint written with standardized short-term tokens, determine the Pod instance to be invoked for the power prediction request; According to the communication transmission protocol, the power prediction request is sent to the Pod instance to be invoked.

[0010] In one implementation, the method further includes: Collect performance metrics corresponding to Pod instances; Bind performance metrics to the target semantic version number and the target dataset fingerprint; Based on performance metrics and their associated target semantic version number and target dataset fingerprint, bimodal anomaly detection is performed on Pod instances. Bimodal anomaly detection includes performance degradation detection and data drift detection. If a Pod instance fails the bimodal anomaly detection, the environmental fingerprint, dataset fingerprint, and structured hyperparameters corresponding to the power prediction model file are reused to train the power prediction model and obtain a new Pod instance.

[0011] In a second aspect, the present invention also provides a power prediction system, comprising: The model registration module is used to generate context records corresponding to the power prediction model file based on the environment in which the power prediction model file to be deployed is located, the training dataset used, and its hyperparameter dictionary. The instance deployment module is used to create the target container image corresponding to the power prediction model file based on the context record, and deploy the target container image to the target container node that meets the resource quota requirements corresponding to the context record, so as to obtain the Pod instance that carries the power prediction microservice; The request-response module is used to send a power prediction request to the Pod instance if a power prediction request is received, so that the Pod instance can respond with a power prediction result in response to the power prediction request.

[0012] Thirdly, the present invention also provides an electronic device including a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement any of the methods provided in the first aspect.

[0013] Fourthly, the present invention also provides a computer-readable storage medium storing computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement any of the methods provided in the first aspect.

[0014] This invention provides a power prediction method, system, device, and medium. First, a context record corresponding to the power prediction model file is generated based on the environment of the power prediction model file to be deployed, the training dataset used, and its hyperparameter dictionary. Then, a target container image corresponding to the power prediction model file is created based on the context record, and the target container image is deployed to a target container node that meets the resource quota requirements corresponding to the context record, resulting in a Pod instance carrying the power prediction microservice. If a power prediction request is received, it is sent to the Pod instance to obtain a power prediction result from the Pod instance. This method uses the context record generated based on the environment of the power prediction model file, the training dataset used, and its hyperparameter dictionary as the input for deployment, driving the construction of the target container image and the generation of resource quota requirements. Based on this, target container nodes that meet the requirements are selected. Image construction no longer relies on manual specification but automatically selects the base image, generates runtime configuration, and injects data identifiers strictly according to the context record. The entire process eliminates the uncertainty caused by local environment differences, achieving consistent deployment and stable operation of the power prediction microservice, thereby improving the accuracy of power prediction.

[0015] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained through the structures particularly pointed out in the description and the drawings.

[0016] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0017] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0018] Figure 1 A schematic flowchart of a power prediction method provided in an embodiment of the present invention; Figure 2A system architecture diagram for implementing the power prediction method is provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a power prediction system provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, 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.

[0020] Currently, existing power prediction systems are typically built on monolithic or traditional modular architectures, with model development, deployment, and operation and maintenance being fragmented, forming technological silos. During the development phase, algorithm models heavily rely on the local environments of developers, lacking unified standardized interfaces and version management mechanisms, making model assets difficult to reuse and collaborate on. During the deployment phase, the heterogeneity of model dependencies, runtime environments, and configuration files easily leads to "environment inconsistency" issues, causing frequent inaccuracies in the model from development to production. At the system level, resource scheduling mostly adopts static configuration strategies, unable to elastically scale according to the prediction task load, making it difficult to handle high-concurrency requests or traffic fluctuations. Furthermore, data management is weak; multi-source heterogeneous data (such as meteorological and SCADA data) lacks unified metadata governance and data lineage tracing capabilities, resulting in inconsistent data quality and difficulties in tracing the root cause of problems, ultimately restricting the overall reliability, maintainability, and scalability of the system.

[0021] Based on this, the present invention provides a power prediction method, system, device and medium that can achieve consistent deployment and stable operation of power prediction microservices, thereby improving the accuracy of power prediction.

[0022] To facilitate understanding of this embodiment, a power prediction method disclosed in this invention will first be described in detail, see [link to relevant documentation]. Figure 1 The diagram shows a power prediction method, which mainly includes the following steps S102 to S106: Step S102: Generate the context record corresponding to the power prediction model file based on the environment of the power prediction model file to be deployed, the training dataset used, and its hyperparameter dictionary.

[0023] The power prediction model file refers to an executable or loadable file that encapsulates the power prediction algorithm, parameter configuration, and necessary metadata. The power prediction algorithm can be a neural network model, a machine learning model, or a numerical computation model, etc. Context records are used to characterize the runtime environment, training dataset, and hyperparameter dictionary upon which the power prediction model depends.

[0024] In one implementation, based on the environment of the power prediction model file to be deployed, the training dataset used, and its hyperparameter dictionary, the environment fingerprint, dataset fingerprint, and structured hyperparameters corresponding to the power prediction model are determined respectively. Based on the above data, a semantic version number corresponding to the power prediction model is generated to characterize whether the runtime environment information in the environment fingerprint has changed, whether the dataset fingerprint has changed, and whether the code version information in the environment fingerprint has changed. Finally, the environment fingerprint, dataset fingerprint, structured hyperparameters, and semantic version number are combined to generate a context record.

[0025] Step S104: Create the target container image corresponding to the power prediction model file based on the context record, and deploy the target container image to the target container node that meets the resource quota requirements corresponding to the context record to obtain the Pod instance that carries the power prediction microservice.

[0026] The resource quota requirement is determined based on the dataset fingerprint in the context record and is used to configure the resource limit field in the deployment configuration object required to filter target container nodes.

[0027] In one implementation, a target container image corresponding to the power prediction model file is constructed based on the environmental fingerprint, dataset fingerprint, and structured hyperparameters; the dataset fingerprint is mapped to resource quota requirements, and the resource limit field in the deployment configuration object is configured based on the resource quota requirements; the real-time resource status of container nodes in the container cluster is scanned, and the target container nodes are filtered in combination with the resource limit field in the deployment configuration object.

[0028] Step S106: If a power prediction request is received, the power prediction request is sent to the Pod instance to obtain the power prediction result from the Pod instance in response to the power prediction request.

[0029] In one example, a successfully deployed Pod instance provides a RESTful or gRPC interface to the outside world through an API gateway. The API gateway handles core gateway functions such as request routing, load balancing, authentication, and traffic metering. If a power prediction request is received, the API gateway sends the power prediction request to the Pod instance to obtain the power prediction result from the Pod instance.

[0030] The power prediction method provided in this invention uses context records generated based on the environment of the power prediction model file, the training dataset used, and its hyperparameter dictionary as input for deployment. This drives the construction of the target container image and the generation of resource quota requirements, and selects target container nodes that meet the requirements accordingly. This eliminates the need for manual specification in image construction. Instead, it automatically selects the base image, generates runtime configuration, and injects data identifiers based strictly on the context records. The entire process eliminates the uncertainty caused by local environment differences, achieves consistent deployment and stable operation of the power prediction microservice, and thus improves the accuracy of power prediction.

[0031] For ease of understanding, embodiments of the present invention provide a system for performing this power prediction method, see [link to documentation]. Figure 2 The diagram shows a system architecture for implementing this power prediction method. The system consists of six core modules, which work closely together through standardized interfaces and event-driven mechanisms to achieve integrated closed-loop management of model development, deployment, operation and governance. These modules include: a microservice architecture layer, a standardized model development layer, a model repository and version management layer, a containerized deployment and resource scheduling layer, a data platform layer, and a monitoring and lifecycle management layer.

[0032] (i) Microservice architecture layer: Built on Spring Cloud, all business services are provided to the outside world through the API (Application Programming Interface Gateway). The gateway integrates identity authentication, dynamic rate limiting, circuit breaking and degradation and intelligent routing capabilities to ensure high availability and security controllability of the system.

[0033] (II) Standardized Model Development Layer: The Model SDK (Model Software Development Kit) is provided, featuring a built-in "development environment snapshot and interface contract generation mechanism." During model training script execution, the SDK automatically captures environment fingerprints, dataset fingerprints, and structured hyperparameters. This information is forcibly embedded into the extended fields of ONNX (Open Neural Network Exchange) / PMML (Predictive Model Markup Language) files during model export as indivisible metadata, ensuring that each export carries a complete reproducibility context and resolving the disconnect between the model and training environment from the source. Simultaneously, the ModelSDK defines a unified model interface specification based on PMML and ONNX, and encapsulates common capabilities such as data preprocessing, feature engineering, and model inference into reusable components, effectively decoupling algorithm development from engineering implementation.

[0034] (III) Model Repository and Version Management System: During model registration, the version decision engine and reproduction contract signing process are executed: based on the environment fingerprint, dataset fingerprint, structured hyperparameters and code version, a semantic version number is automatically generated according to preset rules; after the above elements are normalized and summarized, the HSM (Hardware Security Module) generates an RSA-PSS (Rivest–Shamir–Adleman Probabilistic Signature Scheme) signature; the model registration record and file are strongly consistently written through ACID (Atomicity, Consistency, Isolation, Durability) transaction and object storage dual-write mechanism, and a verifiable reproduction certificate is returned.

[0035] Therefore, the model version is no longer manually labeled, but a trusted unit with programmable verifiability and asset traceability.

[0036] (iv) Containerized Deployment and Resource Scheduling Layer: Implementing a dual mechanism of compliance injection during image building and adaptive resource scheduling during the image building and deployment phases. Image building: Automatically extract the Python / CUDA version from the model context and dynamically match the base image; write the environment fingerprint, dataset fingerprint, and structured hyperparameters into the image tag and configuration file to form auditable metadata, complete operator compatibility verification and security scanning, and generate trusted credentials by HSM signature after passing the verification. Resource scheduling: Based on the time series length, number of wind turbines, and other features contained in the dataset fingerprint, CPU (Central Processing Unit) / memory / GPU (Graphics Processing Unit) quotas are dynamically allocated; the HPA (Horizontal Pod Autoscaler) strategy introduces a data drift index as a forced scaling-down trigger condition on the basis of traditional CPU utilization and QPS (Queries Per Second) metrics; the scheduler prioritizes nodes in the same rack and with the same GPU model to reduce cross-rack communication latency.

[0037] This layer enables a verifiable, traceable, and adaptive deterministic delivery process.

[0038] (v) Data middle platform layer: Unified access to multi-source heterogeneous data such as meteorological data and wind turbine SCADA (Supervisory Control and Data Acquisition) data, and relying on metadata management system and data lineage analysis tools to realize centralized governance, quality monitoring and real-time alarm of data assets.

[0039] (vi) Monitoring and lifecycle management layer: Beyond basic indicator collection and visualization, construct a closed loop of dual-modal anomaly detection, root cause analysis, and autonomous decision-making: Simultaneously monitor performance degradation and data drift; after alarm is triggered, automatically compare the data fingerprints of the current and historical versions to accurately identify data source changes or model capability degradation; the decision engine automatically executes corresponding handling strategies based on the root cause type: roll back to the model version that matches the historical data fingerprint, restart the instance, or start automatic retraining.

[0040] Based on the above system, this invention provides a specific implementation of a power prediction method, achieving an end-to-end automated closed loop from model development to operation and maintenance, including: Step 1: Model Development and Standardized Packaging. Algorithm engineers develop power prediction models based on the Model SDK, outputting power prediction model files that conform to the PMML or ONNX standards, achieving unified interfaces, standardized structures, and interoperable formats.

[0041] Step 2, model registration and context association, includes: Step 2.1: Call the environment awareness probe to collect the code version information, dependency environment information, and runtime environment information of the environment in which the power prediction model file is located, as an environment fingerprint.

[0042] In one example, the environment-aware probe module is invoked to automatically perform the following operations: read the code version information of the current Git repository; run the "pip freeze" tool to calculate the hash value of the Python dependency list as dependency environment information; obtain runtime environment information such as Python version, GPU device UUID, and operating system kernel version; and combine the three types of information in a structured way to form an environment fingerprint.

[0043] Step 2.2: Call the two-layer data fingerprint generator to generate file-level fingerprints and content-level fingerprints based on the training dataset used by the power prediction model file, and concatenate the file-level fingerprints and content-level fingerprints to form the dataset fingerprint.

[0044] In one example, a two-layer data fingerprint generator is invoked to perform dual computations on the training dataset: the SHA-256 algorithm is applied to the original data file (such as CSV / Parquet) to generate a file-level fingerprint; the actual sample content after decompression / loading (including the sequence of fields such as timestamps, power values, and wind speed) is digested by row or block to generate a content-level fingerprint; the two are then concatenated with a fixed delimiter to form the dataset fingerprint.

[0045] Step 2.3: Extract the hyperparameter dictionary from the power prediction model file. After the hyperparameter dictionary passes the parameter range and type constraint verification, convert the hyperparameter dictionary into structured hyperparameters.

[0046] In one example, a hyperparameter dictionary is extracted from the training script, validated against a predefined JSON schema (such as parameter range and type constraints specific to the power prediction field), and serialized into JSON-LD format after successful validation to form structured hyperparameters.

[0047] Step 2.4: Based on the environment fingerprint and the dataset fingerprint, generate a semantic version number according to preset rules. The semantic version number includes a major version number, a minor version number, and a patch number. The major version number is used to indicate whether the runtime environment information in the environment fingerprint has changed, the minor version number is used to indicate whether the dataset fingerprint has changed, and the patch number is used to indicate whether the code version information in the environment fingerprint has changed.

[0048] In one example, environmental fingerprints, dataset fingerprints, structured hyperparameters, and code version are input into a multi-dimensional version decision engine, which compares the changes according to preset rules: If the dataset fingerprint is inconsistent with the historical registration record, the minor version number is incremented; If the Python version or GPU UUID in the environment fingerprint changes, the major version number is incremented. If only the code version changes and the environment fingerprint, dataset fingerprint, and structured hyperparameters remain unchanged, then the patch number is incremented. The final generated semantic version number is in the format `vM.m.p+YYYYMMDD-HASH`.

[0049] Step 2.5: Digitally sign the identifier, environment fingerprint, dataset fingerprint, structured hyperparameters, and semantic version number corresponding to the power prediction model file to obtain the context record associated with the power prediction model file.

[0050] In one example, the storage URI, environmental fingerprint, dataset fingerprint, structured hyperparameters, semantic version number, and code version of the power prediction model file are concatenated into a normalized string in ASCII lexicographical order. The HSM hardware security module is then called to sign the normalized string using the RSA-PSS signature algorithm and a private key, generating an immutable digital signature, which serves as the context record.

[0051] Step 2.6: Register the power prediction model file and its associated context record to the model registry center.

[0052] In one example, the registration interface provided by the Model Registry writes the context record to its relational database (such as PostgreSQL) using ACID transactions; simultaneously, the power prediction model file is uploaded to object storage (such as MinIO), and a URI association is established; upon successful registration, a reproduction certificate is returned, completing the formal registration of the model file and its context record in the model registry. The reproduction certificate contains a unique registration ID, a model file download link, an HSM public key URL, and a Base64 encoded context digest.

[0053] Step 3, Continuous Integration and Secure Image Building. In this embodiment of the invention, the power prediction model file enters the CI / CD pipeline, automatically builds a Docker image, completes dependency installation, environment configuration and security scanning, and pushes the trusted image to a private image repository. Specifically: Step 3.1: Determine the base container image matching the environment fingerprint from the pre-built container image library. Step 3.2: Generate the image configuration file based on structured hyperparameters. Step 3.3: Write the dataset fingerprint into the tag field of the base container image. Step 3.4: Based on the base container image, image configuration file, and tag field, construct the target container image corresponding to the power prediction model file.

[0054] In one example, based on the selected base container image, image configuration file, and tag fields, a pre-built multi-stage Dockerfile template for power prediction is invoked to execute the image build command. During the build process, dependency installation, environment configuration, and security scanning are performed.

[0055] Dependency installation refers to: accurately pulling the dependency versions that are completely consistent with the training environment based on the Python dependency list recorded in the environment fingerprint; executing "pipinstall-rrequirements.txt" in the "build-stage" of the Docker multi-stage build to ensure that the package names, version numbers, installation sources and compilation options are completely consistent with those during the development period, achieving bit-level reproduction of the Python runtime environment and eliminating the problem of environment inconsistency from the root.

[0056] Environment configuration refers to: matching and selecting the official base image of the corresponding CUDA version and Python runtime from the pre-configured image library based on the "python--version" and "nvidia-cuda-version" fields in the environment fingerprint; serializing the inference parameters defined in the structured hyperparameters into standard JSON format and writing them to the ` / etc / model / config.json` path within the image as the default runtime configuration when the service starts; simultaneously writing key information such as dataset fingerprint, model registration ID, and semantic version number into the image metadata in the form of tags to support subsequent scheduling identification, monitoring correlation, and audit tracing; and calling the ONNXRuntime toolset to perform forward inference verification on the model file under the target GPU environment to detect whether there are abnormal outputs such as numerical overflow, NaN, or Inf in FP16 / INT8 mode, ensuring the stable execution of the operator chain in the deployment environment.

[0057] Security scanning includes: (1) OS layer vulnerability scanning: detecting operating system component vulnerabilities in the base image (such as known CVEs for OpenSSL). (2) Python dependency tree scanning: checking whether there are blacklisted packages in the piplist (such as requests<2.31.0 which is disabled due to security risks). (3) Static code analysis: scanning the model inference code for high-risk patterns (such as hard-coded keys, insecure deserialization of pickle.load()). (4) Generating secure and trusted credentials: after all scans are passed, a security credential containing SBOM (Software Material Inventory), CVE remediation suggestions, and signature timestamp is generated and signed by HSM. When pushing the image, it is uploaded to Harbor's Notary service, and the image is marked as trusted=true.

[0058] Step 4, Intelligent Scheduling and Elastic Deployment. In this embodiment of the invention, the container cluster (such as Kubernetes) pulls images from the image repository according to resource policies (such as CPU / GPU quotas), deploys model service instances, and configures HPA policies to achieve dynamic instance scaling based on request volume. Specifically, this includes: Step 4.1: Map the dataset fingerprint to resource quota requirements.

[0059] In one implementation, the dataset fingerprint in the model context is parsed to extract its implicit computational load characteristics, including time series length, number of turbines, and feature dimension. These dimensions are then mapped to resource quota baselines: an increase in time series length corresponds to an increase in CPU requests, an increase in the number of turbines corresponds to an increase in GPU memory requests, and an increase in feature dimension corresponds to an increase in memory requests. All resource request values ​​are expressed in native Kubernetes units (such as "cpu", "nvidia.com / gpu", "memory"), and unit-based quota requirements conforming to the specification are generated.

[0060] Step 4.2: Construct the deployment configuration object corresponding to the power prediction model file, and configure the resource limit field in the deployment configuration object based on resource quota requirements. The deployment configuration object is also known as the Deployment resource object.

[0061] In one example, a Deployment resource object for the target model service is constructed based on a pre-built Deployment template for power prediction. The resource quota requirement is injected into the resource limit field of the Deployment resource object. At the same time, environment variables (such as “MODEL_REGISTRY_ID”, “DATA_FINGERPRINT_DIGEST”), security context (non-root, read-only root file system) and ready probe ( / health endpoint) are injected.

[0062] Step 4.3: Scan the real-time resource status of container nodes in the container cluster and filter target container nodes by combining the resource limit field in the deployment configuration object.

[0063] In one implementation, the Kubernetes API is called to obtain the real-time resource status of all nodes in the cluster, and the GPU device topology information is used for filtering, retaining only container nodes that meet the resource limit field and are located in the same rack.

[0064] Step 4.4: Determine the monitoring object corresponding to the power prediction model and attach the monitoring object to the deployment configuration object. The monitoring object is also the HPA resource object.

[0065] In one example, based on the model type (such as LSTM, XGBoost, or physical numerical model) and application scenario, the corresponding policy template is matched from the pre-built HPA policy rule base to generate an HPA resource object. The "spec.scaleTargetRef" field in the HPA resource object is then pointed to the Deployment resource object to complete the mounting. The HPA object is configured with three types of metric sources: CPU utilization, custom metric QPS, and data drift index.

[0066] Step 4.5: Monitor the scaling metrics corresponding to the target container node through the monitoring object. The scaling metrics are CPU utilization, custom metric QPS, and data drift index.

[0067] Step 4.6: Based on the scaling up / down metrics and preset metric thresholds, update the deployment configuration object, and then perform scaling up or scaling down actions on the target container node based on the updated deployment configuration object.

[0068] In one example, the HPA resource object periodically collects aggregate metrics for all Pods under the target Deployment, calculating the current total QPS and average QPS per Pod (i.e., total QPS divided by the current number of replicas). Based on a preset target throughput threshold per Pod, the theoretical expected number of replicas is calculated using a rounding-up rule: "Expected number of replicas = ceil(current total QPS / target QPS per Pod)". This value is further combined with multi-dimensional metrics such as CPU utilization and data drift index for joint constraint judgment. When high load metrics (such as QPS and CPU) continuously exceed limits, a scaling-up strategy is triggered; when low load metrics (such as QPS and CPU) continuously remain in the redundant range, a scaling-down strategy is triggered; when the data drift index exceeds the preset safety threshold, a forced scaling-down to zero replicas is immediately executed, and abnormal events are reported simultaneously to prevent the service exposure of potential failure models.

[0069] Scaling up and down is achieved by updating the `spec.replicas` field of the target Deployment; the Kubernetes control plane automatically creates or terminates the corresponding number of Pods accordingly; newly started Pods still follow the original resource quota requirements during the scheduling phase, reusing the CPU / GPU / memory specifications and GPU topology-aware scheduling strategies generated based on the model context, ensuring that service instances remain consistent in performance, stability and resource adaptability after scaling up and down.

[0070] Step 5: Service Deployment and Unified Traffic Management. In this embodiment of the invention, successfully deployed services provide RESTful or gRPC interfaces to the outside world through an API gateway. The gateway is responsible for request routing, load balancing, authentication, and traffic metering. Specifically, this includes: Step 5.1: Determine the communication transmission protocol based on the real-time operating data and target semantic version number carried in the power prediction request.

[0071] In one example, the API gateway parses the real-time operational data (such as request timestamp, wind turbine ID list, and meteorological element fields) and the target semantic version number carried in the power prediction request. Combined with the model context record associated with the version number, it determines the inference interface type. For example, if the model file format is ONNX and the client declares support for HTTP / 2 or QUIC (Quick UDP Internet Connections), then it negotiates to use gRPC over HTTP / 2; otherwise, it defaults to using the RESTful (Representational State Transfer) style HTTP / 1.1 interface.

[0072] Step 5.2: If the power prediction request passes multi-level authentication, generate a standardized short-term token corresponding to the power prediction request based on the real-time running data and the target semantic version number. The standardized short-term token is written with at least the target semantic version number and the target dataset fingerprint corresponding to the real-time running data.

[0073] In one implementation, after the power prediction request passes three-level authentication (i.e., TLS certificate verification, scheduling master station permission verification, and anti-replay time window verification), the API gateway generates a standardized short-term token (JWT, JSONWebToken). The payload of this token contains at least two key claims: "model_version" (target semantic version number) and "data_fingerprint" (target dataset fingerprint). The token's validity period is uniformly configured by the system (e.g., 5 minutes), and the signing key is uniformly managed by the scheduling CA (Certificate Authority).

[0074] Step 5.3: Based on the target semantic version number and target dataset fingerprint written with the standardized short-term token, determine the Pod instance to be invoked for the power prediction request.

[0075] In one implementation, the API gateway parses the `model_version` and `data_fingerprint` fields in the standardized short-term token, queries the Service Registry for a list of ready model service Pod instances, and filters them based on the following criteria: the Deployment resource object to which the target Pod belongs contains a tag in its metadata with the key `model-version` and the value being the corresponding semantic version number, and a tag with the key `data-fingerprint-digest` and the value being the fingerprint of the target dataset that matches the current request; further, affinity matching is performed based on the region identifier and GPU model tag, prioritizing Pod instances of the same region and GPU model as target routing nodes.

[0076] Step 5.4: In accordance with the communication transmission protocol, send the power prediction request to the Pod instance to be invoked, so as to obtain the power prediction result from the Pod instance in response to the power prediction request.

[0077] Step 6, Real-time Monitoring and Self-Aware Operation and Maintenance. In this embodiment of the invention, the monitoring system continuously collects service metrics and judges the model status through preset thresholds and intelligent rules. When performance degradation or data drift is detected, it automatically triggers model updates, instance restarts, or version rollbacks, forming a self-healing operation and maintenance closed loop. Specifically, this includes: Step 6.1: Collect the performance metrics corresponding to the Pod instance.

[0078] In one example, the monitoring system (Prometheus) continuously collects core performance metrics from the metric endpoints exposed by the target Pod instance via scheduled fetching: Predictive performance metrics include: P99 latency and RMSE (Root Mean Square Error). Data drift categories include: input feature distribution drift score (calculated based on KS test) and Shannon entropy (characterizing prediction uncertainty) of model output prediction results. Resources and stability metrics include: HTTP error rate and requests per second (QPS).

[0079] Step 6.2: Bind the performance metrics to the target semantic version number and the target dataset fingerprint.

[0080] In one example, when collecting each metric, the monitoring system automatically attaches two key labels to it: "model_registry_id (target semantic version number)" and "data_fingerprint_digest (target dataset fingerprint)" to ensure that all metrics can be accurately traced back to a specific model version and its original training data context.

[0081] Step 6.3: Based on the performance metrics and their associated target semantic version number and target dataset fingerprint, perform bimodal anomaly detection on the Pod instance. Bimodal anomaly detection includes performance degradation detection and data drift detection.

[0082] In one example, the system executes two independent anomaly detection logics in parallel: Performance degradation detection: When the RMSE continuously exceeds a preset multiple threshold of its corresponding operating condition baseline value, and the P99 delay synchronization continuously exceeds another preset multiple threshold of its baseline value, and the continuous over-limit duration is not less than 10 monitoring and acquisition cycles (the default cycle is 5 seconds, i.e., the total duration is ≥50 seconds), a performance degradation alarm is triggered; among them, the baseline value comes from a multi-dimensional baseline library pre-set in the power prediction field, which is finely defined according to dimensions such as wind turbine type, season, and operating period.

[0083] Data drift detection: When the input feature distribution shifts significantly (based on the p-value of the KS test being lower than the preset significance threshold), and the Shannon entropy value of the model output prediction result is consistently higher than its historical P95 quantile threshold, a data drift alarm is triggered; both conditions must be met simultaneously for an alarm to be triggered, to avoid false triggering due to instantaneous fluctuations of a single indicator.

[0084] All alarm events are generated in a structured manner, including alarm type, precise trigger timestamp, relative deviation of each exceeding indicator (such as RMSE deviation from baseline percentage), associated target semantic version number, target dataset fingerprint and other context fields, to ensure traceability, associativity and ability to drive subsequent autonomous decision-making.

[0085] Step 6.4: If the Pod instance fails the bimodal anomaly detection, reuse the environmental fingerprint, dataset fingerprint, and structured hyperparameters corresponding to the power prediction model file to perform training actions on the power prediction model to obtain a new Pod instance.

[0086] In one instance, when the monitoring system detects a performance degradation alert, and the root cause analysis module confirms that the current dataset fingerprint matches the baseline fingerprint and excludes runtime interference factors such as GPU resource contention and CUDA driver anomalies, it determines that the model's generalization ability has declined. At this point, the autonomous decision engine initiates the retraining process. The decision engine submits a standardized retraining task to the ModelSDK training pipeline and enforces the reuse of three immutable contexts: environment fingerprint, dataset fingerprint, and structured hyperparameters. After training, the new model automatically enters the model registry center, where the version decision engine generates a new semantic version number based on semantic rules and fully reuses the fully automated process from steps 1 to 5, achieving closed-loop self-repair of model capabilities and seamless service evolution.

[0087] Furthermore, based on the alarm type and root cause analysis results, the autonomous decision engine automatically selects one of three preset autonomous actions to execute, with the following decision logic: Data drift alert: When the fingerprint of the target dataset is inconsistent with the fingerprint of the baseline dataset, it is determined that the data source has changed, triggering the model version rollback operation. That is, it locates and activates the registered model version that matches the fingerprint of the baseline dataset in the past, and deploys its corresponding service instance to the production environment to achieve rapid recovery of the data-model matching relationship. Performance degradation alert (latency-driven): When the target dataset fingerprint is consistent with the baseline dataset fingerprint, and the increase in P99 latency is significantly higher than the increase in RMSE (i.e., latency anomaly is the main cause), it is determined to be an abnormal runtime environment (such as GPU memory contention, abnormal CUDA driver status, or node resource overload), triggering the Pod instance restart action, that is, performing graceful termination and reconstruction on the current abnormal Pod, reusing the original Deployment configuration and image, and realizing runtime resource reset; Performance degradation alert (error-driven): When the fingerprint of the target dataset is consistent with the fingerprint of the baseline dataset, and the increase in RMSE is significantly higher than the increase in P99 latency (i.e., the main cause is the degradation of prediction accuracy), it is determined that the generalization ability of the model itself has decreased, triggering the model retraining action. That is, based on the three invariant contexts of environment fingerprint, dataset fingerprint and structured hyperparameters, an automated retraining process is started to generate a new version of the model and complete the end-to-end delivery.

[0088] In summary, the method provided by this invention has at least the following characteristics: First, at the basic operational layer, containerization technology completely solves the environment consistency problem, ensuring end-to-end consistency of the model from development to production. Second, at the R&D and operations layer, standardized model interfaces and a one-click deployment mechanism enable agile model delivery, significantly shortening the model deployment cycle. Third, at the resource scheduling layer, based on the elastic scaling capability of real-time load, resource utilization is optimized and system stability is improved. Furthermore, at the data support layer, by introducing unified metadata management and data lineage analysis, data governance capabilities are fundamentally strengthened, ensuring data credibility and traceability. Finally, at the management closed-loop layer, full lifecycle management of the model is achieved from development, deployment, operational monitoring to retirement archiving, ensuring that the model can continuously, stably, and efficiently serve the business.

[0089] Based on the foregoing embodiments, this invention provides a power prediction system, see [link to previous embodiment]. Figure 3 The diagram shows a power prediction system, which mainly includes the following components: The model registration module 302 is used to generate a context record corresponding to the power prediction model file based on the environment of the power prediction model file to be deployed, the training dataset used, and its hyperparameter dictionary. The instance deployment module 304 is used to create a target container image corresponding to the power prediction model file based on the context record, and deploy the target container image to the target container node that meets the resource quota requirements corresponding to the context record, so as to obtain a Pod instance that carries the power prediction microservice. The request response module 306 is used to send the power prediction request to the Pod instance if a power prediction request is received, so as to obtain the power prediction result from the Pod instance in response to the power prediction request.

[0090] The power prediction system provided in this invention uses context records generated based on the environment of the power prediction model file, the training dataset used, and its hyperparameter dictionary as input for deployment. This drives the construction of target container images and the generation of resource quota requirements, and selects target container nodes that meet the requirements accordingly. This eliminates the need for manual specification in image construction. Instead, it automatically selects the base image, generates runtime configuration, and injects data identifiers based strictly on the context records. The entire process eliminates the uncertainty caused by local environment differences, achieves consistent deployment and stable operation of the power prediction microservice, and thus improves the accuracy of power prediction.

[0091] In one implementation, the model registration module 302 is specifically used for: The environment awareness probe is invoked to collect code version information, dependency environment information, and runtime environment information of the environment in which the power prediction model file is located, as an environment fingerprint. The two-layer data fingerprint generator is invoked to generate file-level fingerprints and content-level fingerprints based on the training dataset used by the power prediction model file. The file-level fingerprints and content-level fingerprints are then concatenated to form the dataset fingerprint. Extract the hyperparameter dictionary from the power prediction model file. After the hyperparameter dictionary passes the parameter range and type constraint verification, convert the hyperparameter dictionary into structured hyperparameters. Based on the environment fingerprint and dataset fingerprint, a semantic version number is generated according to preset rules. The semantic version number includes a major version number, a minor version number, and a patch number. The major version number is used to indicate whether the runtime environment information in the environment fingerprint has changed, the minor version number is used to indicate whether the dataset fingerprint has changed, and the patch number is used to indicate whether the code version information in the environment fingerprint has changed. Digitally sign the identifier, environment fingerprint, dataset fingerprint, structured hyperparameters, and semantic version number corresponding to the power prediction model file to obtain the context record associated with the power prediction model file; Register the power prediction model file and its associated context record to the model registry center.

[0092] In one implementation, the instance deployment module 304 is specifically used for: Determine the base container image that matches the environment fingerprint from the pre-built container image library; Generate image configuration files based on structured hyperparameters; Write the dataset fingerprint into the label field of the base container image; Based on the base container image, image configuration file, and tag fields, construct the target container image corresponding to the power prediction model file.

[0093] In one implementation, the instance deployment module 304 is specifically used for: Map the dataset fingerprint to resource quota requirements; Construct the deployment configuration object corresponding to the power prediction model file, and configure the resource limit field in the deployment configuration object based on resource quota requirements; Scan the real-time resource status of container nodes in the container cluster and filter target container nodes by combining the resource limit field in the deployment configuration object.

[0094] In one implementation, the instance deployment module 304 is specifically used for: Identify the monitoring objects corresponding to the power prediction model and attach the monitoring objects to the deployment configuration objects; Monitor the scaling metrics corresponding to the target container node by monitoring the target container node; Based on the scaling metrics and preset thresholds, the deployment configuration object is updated, and the target container node is scaled up or down based on the updated deployment configuration object.

[0095] In one implementation, the request-response module 306 is specifically used for: The communication transmission protocol is determined based on the real-time operating data carried in the power prediction request and the target semantic version number. When the power prediction request passes multi-level authentication, a standardized short-term token corresponding to the power prediction request is generated based on the real-time running data and the target semantic version number. The standardized short-term token is written with at least the target semantic version number and the target dataset fingerprint corresponding to the real-time running data. Based on the target semantic version number and target dataset fingerprint written with standardized short-term tokens, determine the Pod instance to be invoked for the power prediction request; According to the communication transmission protocol, the power prediction request is sent to the Pod instance to be invoked.

[0096] In one implementation, a monitoring module is also included, for: Collect performance metrics corresponding to Pod instances; Bind performance metrics to the target semantic version number and the target dataset fingerprint; Based on performance metrics and their associated target semantic version number and target dataset fingerprint, bimodal anomaly detection is performed on Pod instances. Bimodal anomaly detection includes performance degradation detection and data drift detection. If a Pod instance fails the bimodal anomaly detection, the environmental fingerprint, dataset fingerprint, and structured hyperparameters corresponding to the power prediction model file are reused to train the power prediction model and obtain a new Pod instance.

[0097] The system provided in this embodiment of the invention has the same implementation principle and technical effects as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0098] This invention provides an electronic device, specifically, the electronic device includes a processor and a memory; the memory stores a computer program, which, when run by the processor, executes the method described in any of the above embodiments.

[0099] Figure 4The present invention provides a schematic diagram of the structure of an electronic device 100, which includes a processor 40, a memory 41, a bus 42 and a communication interface 43. The processor 40, the communication interface 43 and the memory 41 are connected through the bus 42. The processor 40 is used to execute executable modules, such as computer programs, stored in the memory 41.

[0100] The memory 41 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 43 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0101] Bus 42 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0102] The memory 41 is used to store programs. After receiving an execution instruction, the processor 40 executes the program. The method executed by the device for defining the flow process disclosed in any of the foregoing embodiments of the present invention can be applied to the processor 40 or implemented by the processor 40.

[0103] Processor 40 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 40 or by instructions in software form. Processor 40 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 41. The processor 40 reads the information in memory 41 and, in conjunction with its hardware, completes the steps of the above method.

[0104] The computer program product of the readable storage medium provided in the embodiments of the present invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the foregoing method embodiments. For specific implementation, please refer to the foregoing method embodiments, which will not be repeated here.

[0105] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0106] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A power prediction method, characterized in that, include: Based on the environment of the power prediction model file to be deployed, the training dataset used, and its hyperparameter dictionary, generate the context record corresponding to the power prediction model file; Based on the context record, create the target container image corresponding to the power prediction model file, and deploy the target container image to the target container node that meets the resource quota requirements corresponding to the context record to obtain the Pod instance that carries the power prediction microservice; If a power prediction request is received, the power prediction request is sent to the Pod instance so that the Pod instance can provide a power prediction result in response to the power prediction request.

2. The power prediction method according to claim 1, characterized in that, Based on the environment of the power prediction model file to be deployed, the training dataset used, and its hyperparameter dictionary, a context record corresponding to the power prediction model file is generated, including: The environment awareness probe is invoked to collect the code version information, dependency environment information, and runtime environment information of the environment in which the power prediction model file is located, as an environment fingerprint. A two-layer data fingerprint generator is invoked to generate a file-level fingerprint and a content-level fingerprint based on the training dataset used by the power prediction model file. The file-level fingerprint and the content-level fingerprint are then concatenated to form a dataset fingerprint. Extract the hyperparameter dictionary from the power prediction model file, and after the hyperparameter dictionary passes the parameter range and type constraint verification, convert the hyperparameter dictionary into structured hyperparameters. Based on the environment fingerprint and the dataset fingerprint, a semantic version number is generated according to a preset rule. The semantic version number includes a major version number, a minor version number, and a patch number. The major version number is used to indicate whether the runtime environment information in the environment fingerprint has changed, the minor version number is used to indicate whether the dataset fingerprint has changed, and the patch number is used to indicate whether the code version information in the environment fingerprint has changed. Digitally sign the identifier, environment fingerprint, dataset fingerprint, structured hyperparameters, and semantic version number corresponding to the power prediction model file to obtain the context record associated with the power prediction model file; The power prediction model file and its associated context record are registered with the model registry center.

3. The power prediction method according to claim 2, characterized in that, Creating the target container image corresponding to the power prediction model file based on the context record includes: The base container image for environment fingerprint matching is determined from a pre-built container image library; Generate an image configuration file based on the structured hyperparameters; Write the dataset fingerprint into the tag field of the base container image; Based on the base container image, the image configuration file, and the tag field, construct the target container image corresponding to the power prediction model file.

4. The power prediction method according to claim 2, characterized in that, Deploying the target container image to a target container node that meets the resource quota requirements corresponding to the context record yields a Pod instance that supports the power prediction microservice, including: Map the dataset fingerprint to resource quota requirements; Construct a deployment configuration object corresponding to the power prediction model file, and configure the resource limit field in the deployment configuration object based on the resource quota requirements; Scan the real-time resource status of container nodes in the container cluster and filter target container nodes by combining the resource limit field in the deployment configuration object.

5. The power prediction method according to claim 4, characterized in that, The method further includes: Identify the monitoring object corresponding to the power prediction model and attach the monitoring object to the deployment configuration object; The monitoring object listens to the scaling indicators corresponding to the target container node. Based on the scaling up / down metrics and preset metric thresholds, the deployment configuration object is updated so that scaling up or scaling down of the target container node is performed based on the updated deployment configuration object.

6. The power prediction method according to claim 2, characterized in that, The power prediction request is sent to the Pod instance to obtain a power prediction result from the Pod instance in response to the power prediction request, including: The communication transmission protocol is determined based on the real-time operating data and target semantic version number carried in the power prediction request. When the power prediction request passes multi-level authentication, a standardized short-term token corresponding to the power prediction request is generated based on the real-time running data and the target semantic version number. The standardized short-term token is written with at least the target semantic version number and the target dataset fingerprint corresponding to the real-time running data. Based on the target semantic version number written in the standardized short-term token and the target dataset fingerprint, the Pod instance to be invoked by the power prediction request is determined; According to the communication transmission protocol, the power prediction request is sent to the Pod instance to which it is to be invoked.

7. The power prediction method according to claim 6, characterized in that, The method further includes: Collect the performance metrics corresponding to the Pod instance; Bind the performance metrics to the target semantic version number and the target dataset fingerprint; Based on the performance metrics and their associated target semantic version number and target dataset fingerprint, the Pod instance is subjected to bimodal anomaly detection, which includes performance degradation detection and data drift detection. If the Pod instance fails the bimodal anomaly detection, the environmental fingerprint, the dataset fingerprint, and the structured hyperparameters corresponding to the power prediction model file are reused to train the power prediction model and obtain a new Pod instance.

8. A power prediction system, characterized in that, include: The model registration module is used to generate a context record corresponding to the power prediction model file based on the environment in which the power prediction model file to be deployed is located, the training dataset used, and its hyperparameter dictionary. The instance deployment module is used to create a target container image corresponding to the power prediction model file based on the context record, and deploy the target container image to the target container node that meets the resource quota requirements corresponding to the context record, so as to obtain a Pod instance that carries the power prediction microservice. The request-response module is used to send a power prediction request to a Pod instance if a power prediction request is received, so that the Pod instance can provide a power prediction result in response to the power prediction request.

9. An electronic device, characterized in that, The method includes a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions that, when invoked and executed by a processor, cause the processor to perform the method according to any one of claims 1 to 7.

Images