A containerized charging analysis method and system oriented to GPU computing power

Abstract

This invention discloses a containerized billing and analysis method and system for GPU computing power, which realizes full lifecycle management and billing linkage of computing power resources based on container orchestration technology. The method includes: a container resource management layer receiving and parsing computing power requests, scheduling and creating containers and generating unique binding identifiers; monitoring container lifecycle events and pushing them to the computing power metering layer via API; the metering layer establishing a user-container-resource mapping, measuring consumption through a computing power conversion algorithm and generating detailed bills; a multi-dimensional billing rule layer matching user packages, calculating bills and updating remaining credit limits; and upon receiving a reset request, synchronously destroying and rebuilding containers, terminating the billing link, clearing consumption records, and restoring credit limits, completing a software-based synchronous reset. This invention achieves real-time linkage between container status and billing, improves the accuracy of computing power metering, supports multi-dimensional flexible billing, provides efficient computing power reset response, and adapts to the refined management needs of enterprise-level GPU computing power leasing.

Description

Technical Field

[0001] This invention relates to the field of GPU computing power billing technology, specifically to a containerized billing analysis method and system for GPU computing power. Background Technology

[0002] With the rapid development of the artificial intelligence and deep learning industries, the demand for GPU computing power in core businesses such as large language model training, computer vision inference, and multimodal model development is experiencing explosive growth. GPU hardware is characterized by high procurement costs, high technical barriers to operation and maintenance, and rapid iteration and updates. Small and medium-sized enterprises, research institutions, and individual developers find it difficult to bear the cost and operational pressure of building their own GPU computing power clusters. Therefore, GPU computing power leasing services based on containerization technology have become the mainstream computing power supply model in the industry. Relying on K8s (Kubernetes) container orchestration technology, GPU computing power resources can be elastically scheduled, rapidly deployed, and isolated for operation, significantly reducing the barrier to entry for computing power.

[0003] In the GPU computing power leasing service system, computing power metering and billing management are core components, directly determining the service provider's operational efficiency and the effectiveness of users' computing power usage cost control. Currently, most industry-standard billing management technologies for containerized GPU computing power follow the traditional architecture of physical machine and virtual machine computing power billing, failing to adapt to the elastic scaling, short lifecycle, and frequent state changes inherent in containerized computing power. This results in numerous intractable technical shortcomings in practical applications, as detailed below:

[0004] First, the coupling between the computing resource management and billing modules is extremely low, making it impossible to achieve real-time synchronization between billing status and container running status. Existing technologies generally employ a separate architecture for hardware monitoring data collection and backend offline billing. The entire lifecycle management of containers—including creation, scheduling, pausing, and destruction—is independently executed by the Kubernetes container management platform, while billing is handled by a separate financial system. The two only synchronize data through scheduled tasks, without establishing a real-time linkage mechanism based on container events. This architecture is highly susceptible to problems such as "containers have been destroyed but billing has not stopped," "containers have started but billing is delayed," and "containers are paused but billing continues." This not only leads to severely inaccurate billing results but also easily triggers fee disputes between service providers and users, failing to guarantee the fairness and accuracy of billing.

[0005] Second, the billing dimension is too singular, and its adaptability to GPU computing power-specific units of measurement is poor, failing to meet the needs of refined cost control. Existing mainstream billing schemes only support billing based on a single dimension of "number of GPUs + runtime," without setting differentiated billing prices based on the hardware resource specifications (GPU model, number of CPU cores, memory capacity, disk size) applied for by the container. This fails to reflect the computing power value and cost differences of GPU hardware with different performance levels. At the same time, existing solutions lack the ability to adapt to industry-specific standardized units of measurement for GPU computing power, such as DCU / degree and computing power, and cannot convert the hardware resource consumption of containers into a unified standardized unit of measurement for computing power. This makes it impossible to adapt to the refined management needs of users in scenarios such as model training and inference, where costs are calculated based on actual computing power consumption.

[0006] Third, the lack of software-based and automated management of the computing power reset mechanism results in high response latency and is prone to generating unnecessary computing power consumption. In practical applications such as AI model training and parameter tuning, users frequently encounter issues with the ineffective use of computing resources due to program errors or improper parameter settings, urgently requiring computing power reset to terminate invalid billing and restore consumed computing power quotas. In existing technologies, this process relies entirely on manual intervention: users need to submit an operation and maintenance work order, which requires operations and maintenance personnel to manually log into the Kubernetes cluster to destroy abnormal containers, then simultaneously notify finance personnel to modify billing data and restore user computing power quotas, and finally manually rebuild the containers. The entire process can have a response latency of minutes or even hours, which is not only cumbersome and costly to operate, but also continuously generates unnecessary computing power consumption that users do not need to bear, causing cost losses for users and seriously affecting the continuity of user business.

[0007] Fourth, the billing rules are rigid, lacking flexibility and scalability, and unable to adapt to diverse computing power leasing needs. Existing billing systems mostly use hard-coded or fixed configurations for their billing rules. Administrators cannot flexibly adjust these rules through visual configuration; they must modify the underlying code to iterate the rules, resulting in long iteration cycles and high adaptation costs. Current solutions do not support automatic switching between "in-package deduction and over-limit billing," nor do they support combined configurations of multi-dimensional billing factors such as hardware resource specifications, runtime, computing power units, and user type. This makes it difficult to adapt to the differentiated computing power package needs of different groups such as enterprise users, research institutions, and individual developers, and thus fails to meet the diverse operational needs of the computing power leasing market. Summary of the Invention

[0008] To address this, the present invention provides a containerized billing analysis method and system for GPU computing power, which solves the problems of traditional technologies being unable to link the container lifecycle with the billing process, resulting in insufficient metering accuracy, poor billing flexibility, and lack of automated management capabilities.

[0009] To achieve the above objectives, the present invention provides the following technical solution: a containerized billing analysis method for GPU computing power, comprising the following steps:

[0010] S1. The container resource management layer receives the GPU computing power resource application request submitted by the user, parses the hardware resource specifications, computing power requirement type and operating parameters in the GPU computing power resource application request, allocates GPU nodes and creates container instances of corresponding specifications through Pod scheduling policy, and generates uniquely bound container identifiers and user identifiers as associated credentials for computing power metering and billing.

[0011] S2, the container resource management layer captures the status events of the entire lifecycle of the container in real time through the built-in event listener, and pushes the event information to the computing power metering layer in real time through the standardized API interface, so as to realize the triggering linkage between the container status and the computing power metering process.

[0012] S3, the computing power metering layer parses the received event information, establishes the association mapping relationship between users, containers, and requested resource specifications, and completes the metering of corresponding computing power consumption based on the real-time running status of containers and the requested hardware resource specifications, and generates the corresponding computing power consumption details.

[0013] S4. The multi-dimensional billing rule layer receives the computing power consumption details and, through the built-in configurable billing rule engine, matches the type of computing power package that the user has purchased, completes the calculation of the corresponding computing power bill, and synchronously updates the remaining quota of the user's corresponding package.

[0014] S5. When a user-initiated computing power reset request is received, the multi-dimensional billing rule layer synchronously issues container destruction and reconstruction instructions to the container resource management layer, simultaneously terminating the current billing link, clearing the corresponding computing power consumption record, and restoring the user's remaining computing power quota, thus completing the software-based synchronous reset of computing power resources and billing links.

[0015] As a preferred solution for containerized billing analysis of GPU computing power, in step S1, the parameters parsed by the GPU computing power resource application request specifically include hardware resource specifications, computing power demand type, and expected runtime; the hardware resource specifications include the number of CPU cores, GPU model and quantity, memory capacity, and disk size; the computing power demand type includes two categories: model training and deep learning inference.

[0016] In step S1, the generated uniquely bound container identifier is PodID, and the user identifier is UserID.

[0017] As a preferred solution for containerized billing analysis methods for GPU computing power, in step S2, the status events of the entire lifecycle of the container specifically include PodCreated, PodRunning, PodPaused, and PodDeleted events, and the event information includes event type, trigger time, container identifier, and user identifier.

[0018] As a preferred solution for containerized billing and analysis methods for GPU computing power, event information is pushed to the computing power metering layer in real time through a standardized API interface, realizing the linkage between container status and the computing power metering process. Specifically:

[0019] When the PodCreated event is detected, the association mapping between user, container, and resource specification is pre-established.

[0020] The computing power metering and billing process is started when the PodRunning event is detected; the computing power metering and billing process is paused in real time when the PodPaused event is detected.

[0021] Upon detecting the PodDeleted event, the computing power metering and billing process is immediately terminated, and a complete computing power consumption detail statement is generated to achieve complete synchronization between container status and billing status.

[0022] As a preferred solution for containerized billing analysis of GPU computing power, in step S3, computing power consumption is measured through a computing power conversion algorithm. This algorithm converts the hardware resource consumption into DCU / degree standard GPU computing power units based on the hardware resource specifications requested by the container and its actual operating status. The calculation formula is as follows:

[0023]

[0024] In the formula, This represents the total GPU computing power consumed by the container during its corresponding runtime cycle. The preset standard computing power parameters for the corresponding GPU model applied for for the container are fixed baseline values; The number of GPUs requested for the container; The cumulative actual runtime of the container in the PodRunning state; This is a correction factor dynamically calculated based on the real-time GPU utilization during container operation.

[0025] As a preferred solution for containerized billing analysis methods targeting GPU computing power, in step S4, the configurable billing rule engine adopts a plug-in design and presets multi-dimensional billing rules through a visual interface. The rule dimensions specifically include:

[0026] Hardware resource specifications: Differentiated base unit prices for specific GPU models, CPU core counts, memory capacity, and disk size configurations;

[0027] Computing power unit dimension: Configure corresponding unit price conversion factors for DCU and degree, two types of GPU computing power dedicated units;

[0028] Package type dimension: Supports configuration and automatic switching of four billing modes: billing by time, billing by DCU quota, billing by amount quota, and deduction within the package + billing by usage for excess amount.

[0029] As a preferred solution for containerized billing analysis of GPU computing power, step S4 involves calculating the corresponding computing power bill. The specific execution logic is as follows:

[0030] For users within the package: the remaining computing power quota within the corresponding package will be deducted first. When the quota is exhausted, the excess will be switched to the pay-as-you-go billing mode. Any unused quota within the package validity period will be carried over to the next cycle.

[0031] For pay-as-you-go users: the total cost is calculated directly based on the total computing power consumption and the basic unit price of the corresponding hardware resource specifications.

[0032] As a preferred solution for containerized billing analysis methods for GPU computing power, step S5 involves completing the software-based synchronous reset of computing resources and the billing link. The specific execution process is as follows:

[0033] S51. Receive the computing power reset request submitted by the user through the user interaction layer, and parse the user identifier, container identifier and original hardware resource specifications corresponding to the request.

[0034] S52. Send a container destruction command to the container resource management layer, simultaneously terminate the billing link corresponding to the current container, and clear all computing power consumption records generated by the container.

[0035] S53. Restore the remaining computing power quota of the user's corresponding computing power package, and send a container reconstruction instruction to the container resource management layer based on the hardware resource specifications originally applied for by the user.

[0036] S54. The container resource management layer creates a new container instance of the corresponding specification. After the new container starts, it triggers the start of a new computing power metering and billing link, completing the full process reset.

[0037] This invention also provides a containerized billing analysis system for GPU computing power, employing the aforementioned containerized billing analysis method for GPU computing power, including:

[0038] The GPU computing power resource application and container deployment module is used by the container resource management layer to receive GPU computing power resource application requests submitted by users, parse the hardware resource specifications, computing power requirement type and operating parameters in the GPU computing power resource application request, allocate GPU nodes and create container instances of corresponding specifications through Pod scheduling policies, and generate uniquely bound container identifiers and user identifiers as associated credentials for computing power metering and billing.

[0039] The container lifecycle event listening and push module is used to trigger the linkage between container status and computing power metering. The container resource management layer uses a built-in event listener to capture the status events of the container lifecycle in real time and push the event information to the computing power metering layer in real time through a standardized API interface, so as to realize the linkage between container status and computing power metering process.

[0040] The GPU computing power consumption measurement and detail generation module is used by the computing power measurement layer to parse the received event information, establish the association mapping relationship between users, containers, and requested resource specifications, and complete the measurement of corresponding computing power consumption based on the real-time running status of containers and the requested hardware resource specifications, and generate corresponding computing power consumption details.

[0041] The multi-dimensional computing power billing and quota management module is used to receive the computing power consumption details in the multi-dimensional billing rule layer, match the type of computing power package purchased by the user through the built-in configurable billing rule engine, complete the calculation of the corresponding computing power bill, and update the remaining quota of the user's corresponding package in a synchronous manner.

[0042] The software-based synchronous reset module for computing resources and billing links is used to simultaneously issue container destruction and reconstruction instructions to the container resource management layer when a user initiates a computing power reset request. This simultaneously terminates the current billing link, clears the corresponding computing power consumption record, and restores the user's remaining computing power quota, thus completing the software-based synchronous reset of computing resources and billing links.

[0043] As a preferred solution for a containerized billing and analysis system for GPU computing power, the software-based synchronous reset module for computing power resources and billing links includes:

[0044] The reset request receiving submodule is used to receive computing power reset requests submitted by users through the user interaction layer, and parse the user identifier, container identifier and original hardware resource specifications corresponding to the request.

[0045] The container management instruction distribution submodule is used to send container destruction instructions to the container resource management layer, synchronously terminate the billing link corresponding to the current container, and clear all computing power consumption records generated by the container.

[0046] The billing link and data reset submodule is used to restore the remaining computing power quota of the user's corresponding computing power package and send a container reconstruction instruction to the container resource management layer based on the hardware resource specifications originally applied for by the user.

[0047] The reset process control submodule is used by the container resource control layer to create new container instances of the corresponding specifications. After the new container starts, it triggers the start of a new computing power metering and billing link, completing the full process reset.

[0048] The present invention has the following advantages:

[0049] First, this invention abandons the traditional separate architecture of "hardware data collection and offline computing." It uses a built-in event listener to capture container lifecycle events in real time, directly using container creation, running, pause, and destruction events as triggers for the computing power metering and billing process. This achieves synchronized linkage across all states: billing starts when a container starts, stops when a container is paused, and terminates when a container is destroyed. This fundamentally eliminates common industry problems such as "billing not stopping even after container release" and "billing delay after container startup," ensuring the real-time nature, accuracy, and fairness of billing results, and significantly reducing fee disputes between computing power service providers and consumers. Furthermore, it eliminates the need for additional hardware data collection equipment, reducing system deployment costs and operational complexity.

[0050] Secondly, this invention employs a computing power conversion algorithm based on hardware resource specifications, actual runtime, and dynamic resource utilization. This algorithm can uniformly convert the hardware resource consumption of GPUs of different models and specifications into standardized GPU computing power measurement units, overcoming the shortcomings of existing technologies such as single billing dimensions and poor adaptability to heterogeneous computing power. It achieves differentiated measurement of GPUs with different performance levels through a GPU benchmark computing power value, and adapts to the actual working conditions of GPU computing power load fluctuations in model training and inference scenarios through a dynamic resource utilization coefficient. This avoids measurement deviations such as "full measurement even when containers are idle," significantly improving the accuracy of computing power measurement. Simultaneously, it supports differentiated billing configurations for supporting hardware resources such as CPU cores, memory, and disk, comprehensively meeting the core needs of enterprise users for refined computing power cost management.

[0051] Third, this invention achieves full-process software-based atomic control of computing power reset. After a user initiates a computing power reset request, the entire process can be completed automatically without human intervention. This solves the pain points of existing technologies, such as reliance on manual operation and maintenance, high response latency, and easy generation of invalid computing power consumption. It significantly reduces the operation and maintenance manpower costs of computing power service providers and avoids unnecessary computing power cost losses caused by program errors and parameter tuning. At the same time, by reusing the hardware resource specifications originally applied for by the user to rebuild the container, the continuity of the user's AI training and inference business is ensured, perfectly adapting to the actual application scenarios of high-frequency computing power reset in the model development process.

[0052] Fourth, the multi-dimensional billing rule layer of this invention adopts a plug-in design, with a built-in configurable billing rule engine. Administrators can configure multi-dimensional billing factors and unit prices, such as hardware resource specifications, computing power units, and package types, through a visual interface. Iterative adjustments to billing rules can be completed without modifying the underlying system code, solving the shortcomings of existing technologies such as fixed billing rules and high iteration costs. The engine supports four mainstream billing modes: time-based billing, DCU quota billing, quota-based billing, and in-package deduction + over-quota billing. It can automatically switch modes after the package quota is exhausted, flexibly adapting to the differentiated computing power leasing needs of different user groups such as SMEs, research institutions, and individual developers. This significantly shortens the iteration cycle of billing rules, reduces system maintenance costs, and can quickly adapt to the diverse operational needs of the computing power leasing market.

[0053] Fifth, this invention significantly reduces operation and maintenance costs through fully automated management and control, reduces user disputes through a precise metering and billing system, and allows for rapid expansion of diversified computing power service products through a flexible and configurable billing engine, enhancing market competitiveness. For computing power users, the transparent and accurate billing system, flexible package selection, and rapid computing power reset capabilities significantly lower the barrier to entry and overall cost of using GPU computing power, improving user experience. This invention fills the gaps in existing containerized GPU computing power billing technologies and can effectively promote the development of the GPU computing power leasing industry towards standardization, refinement, and universal accessibility. Attached Figure Description

[0054] To more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings in the following description are merely exemplary, and those skilled in the art can derive other embodiments based on the provided drawings without creative effort.

[0055] The structures, proportions, sizes, etc. illustrated in this specification are only for the purpose of assisting those skilled in the art in understanding and reading the content disclosed herein, and are not intended to limit the conditions under which the present invention can be implemented. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportions, or adjustments to the size, without affecting the effects and objectives that the present invention can produce, should still fall within the scope of the technical content disclosed in the present invention.

[0056] Figure 1 This is a schematic diagram of the containerized billing analysis method for GPU computing power provided in an embodiment of the present invention;

[0057] Figure 2This is a schematic diagram of the technical roadmap for the containerized billing analysis method for GPU computing power provided in this embodiment of the invention;

[0058] Figure 3 This is a schematic diagram of a containerized billing and analysis system architecture for GPU computing power provided in an embodiment of the present invention. Detailed Implementation

[0059] The following specific embodiments illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. 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.

[0060] Example 1

[0061] See Figure 1 and Figure 2 Embodiment 1 of the present invention provides a containerized billing analysis method for GPU computing power, comprising the following steps:

[0062] S1. The container resource management layer receives the GPU computing power resource application request submitted by the user, parses the hardware resource specifications, computing power requirement type and operating parameters in the GPU computing power resource application request, allocates GPU nodes through the Pod scheduling policy and creates container instances of the corresponding specifications, and generates uniquely bound container identifiers and user identifiers as associated credentials for computing power metering and billing.

[0063] The container resource management layer serves as the entry point for computing resources, directly connecting to the native orchestration capabilities of the Kubernetes cluster. It forms the foundation for software-based and automated management of computing resources, replacing the traditional manual allocation of GPU resources and deployment of environments. This streamlines the process from resource application to subsequent billing. It analyzes hardware resource specifications, computing demand types, and operating parameters, providing a data foundation for differentiated scheduling, metering, and billing. Each parameter corresponds to a dimension of the billing system, resolving the issues of traditional solutions' single billing dimension and inability to adapt to different hardware and business scenarios.

[0064] Pod scheduling is based on native Kubernetes scheduling strategies, including node affinity, dedicated GPU resources, label matching, and resource quota management. It automatically matches GPU nodes that meet the user's requested specifications, ensuring that the allocated hardware resources perfectly match the user's needs. Simultaneously, containerization achieves resource isolation between multiple users, guaranteeing the security and stability of computing power usage. A uniquely bound container identifier and user identifier are generated, establishing a unique mapping relationship between "user identity - computing power instance - billing account." This ensures that every container state change, computing power consumption metering, and billing calculation is attributed to the corresponding user, fundamentally avoiding billing errors and user account data chaos.

[0065] In this embodiment, the parameters parsed in step S1 of the GPU computing power resource application request specifically include hardware resource specifications, computing power demand type, and expected runtime; the hardware resource specifications include the number of CPU cores, GPU model and quantity, memory capacity, and disk size; the computing power demand type includes two categories: model training and deep learning inference.

[0066] Specifically, the application parameters are broken down into hardware resource specifications, computing power demand type, and expected runtime, fully covering all core factors affecting GPU computing power costs. This provides data support for the implementation of multi-dimensional billing rules and solves the pain points of traditional solutions that only charge by time and have a single dimension.

[0067] Among them, the number of CPU cores, GPU model and quantity, memory capacity, and disk size are the hardware resources for container operation. Different configurations correspond to different hardware procurement costs and computing power value. For example, there are orders of magnitude differences in computing power performance and procurement costs between NVIDIA A100 and RTX 3090. By analyzing this parameter, differentiated pricing for different hardware specifications can be achieved, which fully matches the reasonable billing logic of "high-value resources, high unit price; low-value resources, low unit price".

[0068] Model training typically involves high-load, long-duration dedicated GPU usage, while deep learning inference is mostly low-load, elastically startable and stopable shared GPU usage. Their computing power utilization efficiency and resource consumption characteristics are completely different. By distinguishing between these types, differentiated scheduling strategies and billing prices can be configured, adapting to the refined operational needs of different business scenarios and solving the shortcomings of traditional solutions that cannot adapt to different computing power usage scenarios. The expected runtime parameter is used for two purposes: firstly, for node resource reservation planning during Kubernetes scheduling to avoid cluster resource conflicts; secondly, it serves as a reference for users to estimate computing power costs and select service packages, helping users to manage computing power usage costs in advance and improve the user experience.

[0069] In one possible embodiment, in step S1, the generated uniquely bound container identifier is PodID, and the user identifier is UserID.

[0070] Specifically, PodID is a globally unique identifier for a container instance in a Kubernetes cluster. It is non-repeatable and can pinpoint a unique container instance within the cluster. It fully corresponds to the container's lifecycle from creation to destruction, serving as the core carrier for capturing container events and tracking computing power operation status, ensuring that every container state change can be tracked. UserID is a globally unique identifier for users on the computing power platform. It can be associated with all core billing-related data, including user account information, purchased computing power packages, remaining quota, historical bills, and permission configurations. It is the core identity credential for billing calculation and quota management. Uniquely binding PodID and UserID breaks down the data barriers between the "container resource layer" and the "user billing layer," ensuring that metering, billing, and reset operations triggered by container events correspond to the correct user account. This avoids the problems of inaccurate matching between users and computing power instances and chaotic billing attribution in traditional solutions.

[0071] S2, the container resource management layer, captures the status events of the entire container lifecycle in real time through the built-in event listener, and pushes the event information to the computing power metering layer in real time through the standardized API interface, so as to realize the triggering linkage between container status and computing power metering process.

[0072] Specifically, the built-in event listener uses the native Kubernetes watch mechanism, directly connecting to the Kubernetes API Server to monitor container events within the cluster in real time, rather than the traditional timed polling mode. Event capture latency can be controlled to the millisecond level, ensuring that container state changes are captured in real time. This solves the problem of billing status lag and inconsistency caused by timed data synchronization in traditional solutions. Every state change of a container from creation to destruction generates corresponding native Kubernetes events. By capturing these full lifecycle events, all state nodes of the container's operation can be covered, ensuring that every state change triggers corresponding metering process adjustments, achieving real-time linkage between state changes and metering action adjustments.

[0073] The system employs a standardized RESTful API interface for event information push, featuring high compatibility, high reliability, and low coupling. This achieves layered decoupling between the container resource management layer and the computing power metering layer, allowing both layers to be independently upgraded and iterated. Simultaneously, it ensures structured transmission of event information, avoiding parsing errors caused by inconsistent data formats and guaranteeing the integrity and timeliness of event pushes. This abandons the traditional passive billing model of "hardware data collection - scheduled synchronization - offline accounting," using container events as the active trigger source for the metering process. Container state changes directly drive the start, stop, and pause of the metering process. Architecturally, this achieves deep coupling between the computing power resource management and billing modules, fundamentally solving the problems of separation and asynchronous state between resource management and billing in traditional solutions.

[0074] In one possible embodiment, in step S2, the container's full lifecycle status events specifically include PodCreated, PodRunning, PodPaused, and PodDeleted events, and the event information includes event type, trigger time, container identifier, and user identifier.

[0075] Specifically, the four event categories—PodCreated, PodRunning, PodPaused, and PodDeleted—cover the core state nodes of the entire container lifecycle from creation, running, paused, to destruction, ensuring no omissions or redundancies. Each event corresponds to a key action in the metering and billing process, guaranteeing that all container state changes can be accurately captured and trigger corresponding billing adjustments. For the PodCreated event, the container instance has been created in the Kubernetes cluster but has not yet started running. This event is used to complete data preparation in advance, avoiding billing delays after the container starts. For the PodRunning event, the container has entered a normal running state, and GPU resources are actually being used. This event is the core trigger point for starting metering and billing. For the PodPaused event, the container has been paused, and GPU resources are no longer being used by business applications. This event is the trigger point for pausing metering and billing. For the PodDeleted event, the container has been destroyed, and GPU resources have been completely released back to the cluster. This event is the trigger point for terminating metering and billing. Among them, the event type is used to determine the metering action that needs to be triggered, the trigger time is used to calculate the effective runtime of the container, and the container identifier and user identifier are used to associate the corresponding computing power instance and user account. The four fields completely cover all the core information required to trigger metering and billing, with no redundant fields, ensuring the efficiency of event transmission and parsing.

[0076] Specifically, event information is pushed to the computing power metering layer in real time via a standardized API interface, enabling the linkage between container status and the triggering of the computing power metering process.

[0077] When the PodCreated event is detected, the association mapping between user, container, and resource specification is pre-established.

[0078] The computing power metering and billing process is started when the PodRunning event is detected; the computing power metering and billing process is paused in real time when the PodPaused event is detected.

[0079] Upon detecting the PodDeleted event, the computing power metering and billing process is immediately terminated, and a complete computing power consumption detail statement is generated to achieve complete synchronization between container status and billing status.

[0080] Specifically, during the pre-mapping process of the PodCreated event, in the window period before the container is created but not yet started, the association mapping between the user, the container, and the requested resource specifications is completed in advance. User account information, package information, and container hardware specifications are matched and verified in advance, ensuring that metering and billing can start immediately once the container enters the running state. This completely solves the problem of delayed billing startup after container startup in traditional solutions, guaranteeing billing accuracy. The PodRunning state is the only valid state in which the container actually occupies GPU computing resources. Only in this state has the user actually used GPU computing power. Therefore, using this event as the trigger point for billing startup perfectly aligns with the fairness principle of "billing only for actual use," avoiding the unreasonable problem of incurring charges before the container is created but not running. When the container is paused, GPU computing resources are no longer occupied by business applications and are in an idle state. At this time, the PodPaused event pauses metering and billing in real time, reflecting the actual computing power usage of the user. This solves the problem of continued billing even when the container is paused in traditional solutions, protecting user rights and adapting to the high-frequency usage scenario of temporarily pausing parameter tuning and troubleshooting during model training. Container destruction means that GPU computing resources have been completely released back to the cluster, and users no longer occupy any computing resources. Therefore, the PodDeleted event immediately terminates billing and generates a complete computing power consumption detail, ensuring that the termination of billing and the release of resources are completely synchronized. This fundamentally eliminates the industry pain point of "the container has been destroyed but the billing has not stopped" and achieves complete strong synchronization between the container status and the billing status.

[0081] S3, the computing power metering layer, parses the received event information, establishes the association mapping relationship between users, containers, and requested resource specifications, and completes the metering of corresponding computing power consumption based on the real-time running status of containers and the requested hardware resource specifications, generating corresponding computing power consumption details.

[0082] Specifically, the computing power metering layer serves as an intermediary connecting the container resource management layer and the billing rule layer. Its core function is to convert the container's operational status and hardware resource usage into standardized computing power units, solving the problems of non-standardized quantification of hardware resource usage and the inability to uniformly measure heterogeneous GPU computing power in traditional solutions. By parsing the container and user identifiers in the event information and calling the pre-established association mapping data from step S1, the binding relationship between the user, container, and resource specifications is reconfirmed, ensuring the accuracy of the metering data and avoiding errors in metering attribution. Simultaneously, it provides the basic parameters of hardware specifications for computing power conversion.

[0083] The system uses the real-time running status of containers (actual runtime) and the specifications of the requested hardware resources as the core two-factor metering metrics. Runtime corresponds to the time dimension of computing power usage, while hardware specifications correspond to the scale and performance dimension of computing power usage. The combination of these two dimensions can comprehensively cover the core influencing factors of computing power consumption. Compared with traditional single-duration billing, the metering dimensions are more comprehensive and accurate. The computing power consumption details report fully records data such as user identifier, container identifier, hardware specifications, start and end times of operation, cumulative runtime, and total computing power consumption. It is the sole legal basis for billing and can also provide users with visual queries, achieving full transparency of computing power consumption and solving the problems of opaque computing power consumption and inability for users to verify it in traditional solutions.

[0084] In one possible embodiment, in step S3, the computing power consumption is measured using a computing power conversion algorithm. This algorithm converts the computing power consumption into DCU / degree standard GPU computing power units based on the hardware resource specifications requested by the container and its actual operating status. The calculation formula is as follows:

[0085]

[0086] In the formula, This represents the total GPU computing power consumed by the container during its corresponding runtime cycle. The preset standard computing power parameters for the corresponding GPU model applied for for the container are fixed baseline values; The number of GPUs requested for the container; The cumulative actual runtime of the container in the PodRunning state; This is a correction coefficient dynamically calculated based on the real-time GPU utilization during container operation. The computing power conversion algorithm does not require additional hardware acquisition equipment; it can accurately quantify computing power consumption solely through container application parameters and runtime status data obtained at the software level. Simultaneously, it uniformly converts the resource consumption of different GPU models and specifications into DCU / degree, a standardized unit of measurement for GPU computing power commonly used in the industry. This solves the pain points of traditional solutions, such as the inability to uniformly measure heterogeneous GPU computing power and poor adaptability, achieving standardized benchmarking and accounting of computing power consumption across different hardware platforms.

[0087] S4. The multi-dimensional billing rule layer receives the computing power consumption details and, through the built-in configurable billing rule engine, matches the type of computing power package that the user has purchased, completes the calculation of the corresponding computing power bill, and synchronously updates the remaining quota of the user's corresponding package.

[0088] Specifically, the configurable billing rule engine built into the multi-dimensional billing rule layer decouples billing logic from the underlying system code, solving the pain point of rigid and inflexible billing rules in traditional solutions. The configurable billing rule engine adopts a plug-in design, separating configurable items such as billing rules, unit price, and conversion factors from the underlying calculation logic. Administrators do not need to modify the system code; they can configure and adjust billing rules solely through a visual interface, significantly shortening the iteration cycle of billing rules, reducing system maintenance costs, and enabling rapid adaptation to changes in market demands. Based on the user identifier in the computing power consumption details, the engine automatically retrieves the user's purchased computing power package information, matches the corresponding billing rules, and completes billing calculation. This achieves fully automated execution of the metering data-package rules-billing calculation process without manual intervention, significantly improving calculation efficiency and accuracy. After the bill is calculated, the remaining credit limit in the user's package is deducted in real time to ensure that the user's remaining credit limit data is completely synchronized with the actual computing power consumption. Users can check their remaining credit limit in real time, which realizes full transparency of computing power consumption and credit limit management and avoids disputes over excessive charges caused by users not knowing that their credit limit has been exhausted.

[0089] In one possible embodiment, in step S4, the configurable billing rule engine adopts a plug-in design, and presets multi-dimensional billing rules through a visual interface. The rule dimensions specifically include:

[0090] Hardware resource specifications: Differentiated base unit prices for specific GPU models, CPU core counts, memory capacity, and disk size configurations;

[0091] Computing power unit dimension: Configure corresponding unit price conversion factors for DCU and degree, two types of GPU computing power dedicated units;

[0092] Package type dimension: Supports configuration and automatic switching of four billing modes: billing by time, billing by DCU quota, billing by amount quota, and deduction within the package + billing by usage for excess amount.

[0093] Specifically, the plug-in design encapsulates billing rules of different dimensions into independent plug-in modules. When adding a new billing dimension or adjusting billing rules, only the corresponding plug-in needs to be added or modified, without altering the core engine code. This ensures system stability and provides strong scalability, allowing for the addition of more billing dimensions such as user level, region, and time period to adapt to future operational needs. The hardware resource specification dimension achieves a strong binding between hardware resources and billing unit prices. Different performance hardware corresponds to different base unit prices, perfectly matching hardware procurement costs and computing power value, enabling refined differentiated billing and solving the problem of lacking hardware specification-based differentiated billing capabilities in traditional solutions. The computing power unit dimension achieves flexible adaptation to two mainstream industry computing power units: DCU and degree. By configuring unit price conversion factors, the two units can be freely switched and uniformly calculated, adapting to the metering habits of different user groups. This solves the problem of poor adaptability of traditional solutions to GPU-specific computing power units and can meet the refined metering needs of users of different industries and sizes. The package types cover all mainstream billing models in the current computing power rental market, meeting the differentiated needs of different user groups: time-based billing is suitable for users with temporary and short-term computing power use; DCU / degree-based billing is suitable for enterprise users with long-term and stable computing power use; and in-package deduction + over-limit pay-as-you-go billing is suitable for users with basic computing power needs and occasional peak computing power needs. At the same time, it supports automatic switching of modes without manual intervention, solving the pain points of single billing mode and lack of flexibility in traditional solutions.

[0094] In one possible embodiment, in step S4, the calculation of the corresponding computing power bill is completed, and the specific execution logic is as follows:

[0095] For users within the package: the remaining computing power quota within the corresponding package will be deducted first. When the quota is exhausted, the excess will be switched to the pay-as-you-go billing mode. Any unused quota within the package validity period will be carried over to the next cycle.

[0096] For pay-as-you-go users: the total cost is calculated directly based on the total computing power consumption and the basic unit price of the corresponding hardware resource specifications.

[0097] Specifically, the user billing within the package adopts a design of "prioritizing deduction of the package quota and automatically switching to pay-as-you-go when the quota is exhausted," which perfectly aligns with the typical computing power usage habits of enterprise users. Fixed-quota packages purchased by users typically have lower unit prices, and prioritizing deduction ensures users enjoy the most favorable billing rates; once the quota is exhausted, it automatically switches to pay-as-you-go billing, preventing interruptions to training tasks due to insufficient quota and ensuring business continuity; the automatic carryover of remaining quota protects user rights and avoids the problem of unused quota expiring and becoming invalid, significantly improving the user experience.

[0098] The pay-as-you-go billing system employs a "real-time consumption, real-time billing" design, suitable for individual users or SMEs using computing power temporarily or for short periods. It eliminates the need to purchase packages in advance, calculating costs based on actual computing power consumption. This low-barrier-to-entry, highly flexible system meets the needs of fragmented computing power usage. Through a dual-track billing logic combining in-package and pay-as-you-go billing, it covers the billing needs of a full range of users, from individual developers to large enterprises. The entire process is automated, eliminating the need for manual calculations, significantly reducing platform operating costs and resolving the issue of traditional solutions being unable to adapt to diverse user billing needs.

[0099] S5. When a user-initiated computing power reset request is received, the multi-dimensional billing rule layer synchronously issues container destruction and reconstruction instructions to the container resource management layer, simultaneously terminating the current billing link, clearing the corresponding computing power consumption record, and restoring the user's remaining computing power quota, thus completing the software-based synchronous reset of computing power resources and billing links.

[0100] Specifically, in real-world scenarios of AI model training and parameter tuning, users frequently encounter issues where computing resources are ineffectively occupied due to program bugs or incorrect parameter settings. Traditional solutions require users to submit maintenance work orders, with maintenance personnel manually destroying containers and finance personnel manually modifying billing data. Response delays can reach minutes or even hours, easily generating a large amount of unnecessary and unnecessary costs for users. This step adopts an atomic design that synchronizes the "container management command issuance" with the "billing link and data reset," ensuring complete synchronization between container destruction and billing termination. This avoids additional costs caused by inconsistencies in their execution timing and guarantees complete consistency between resource status and billing status during the reset process. Either the entire process succeeds, or it rolls back to the initial state, avoiding data inconsistency issues.

[0101] The entire reset process is fully automated through software commands, requiring no manual intervention. This solves the problems of high manual maintenance costs, high response latency, and susceptibility to operational errors inherent in traditional solutions, significantly improving reset efficiency and reducing platform maintenance costs. Simultaneously, clearing invalid computing power consumption records and restoring the user's remaining computing power quota completely eliminates invalid computing power costs incurred due to user errors, protecting the user's economic rights and adapting to high-frequency parameter tuning and trial-and-error scenarios in AI R&D. The container is rebuilt based on the user's original hardware resource specifications, eliminating the need for users to resubmit applications and configure parameters. After the reset, users can directly continue using the corresponding computing power resources, ensuring business continuity and avoiding business interruptions caused by the reset operation.

[0102] In this embodiment, step S5 involves completing the software-based synchronous reset of computing resources and billing links. The specific execution process is as follows:

[0103] S51. Receive the computing power reset request submitted by the user through the user interaction layer, and parse the user identifier, container identifier and original hardware resource specifications corresponding to the request.

[0104] S52. Send a container destruction command to the container resource management layer, simultaneously terminate the billing link corresponding to the current container, and clear all computing power consumption records generated by the container.

[0105] S53. Restore the remaining computing power quota of the user's corresponding computing power package, and send a container reconstruction instruction to the container resource management layer based on the hardware resource specifications originally applied for by the user.

[0106] S54. The container resource management layer creates a new container instance of the corresponding specification. After the new container starts, it triggers the start of a new computing power metering and billing link, completing the full process reset.

[0107] Specifically, S51 is the entry point and legality verification step of the reset process. By parsing the user identifier and container identifier, it can locate the container instance that needs to be reset and the corresponding user account, verify the user's operation permissions, and prevent unauthorized operations. It also parses the original hardware resource specifications to provide parameter basis for subsequent container reconstruction, ensuring that the reconstructed container is completely consistent with the original specifications and does not require user reconfiguration. S52 is the core risk control step of the reset process. It adopts a synchronous execution logic of "destroying the container first, then terminating billing, and clearing records". Destroying the container first ensures that GPU resources are released immediately and no new computing power is consumed. Synchronously terminating the billing link and clearing the consumption records can completely eliminate invalid billing data generated by this container operation, ensuring that resource release and billing termination are completely synchronized without any time difference, thus avoiding the generation of additional costs from the root. S53 restores user rights and ensures seamless business continuity. Based on the cleared computing power consumption records, it restores the corresponding computing power quota within the user's package, ensuring that the user's computing power quota is restored to the state before the container ran. Simultaneously, it sends a container reconstruction command based on the original specifications, achieving a seamless "destruction-reconstruction" transition and guaranteeing the continuity of user services. S54 is the closed-loop step of the reset process. After the new container is created and started, a new metering and billing chain is triggered, allowing users to directly continue business operations such as model training. The entire reset process requires only one request from the user, without any additional operations, making it extremely easy to use. Furthermore, the entire process response time can be controlled within 50ms, far lower than the minute-level response time of traditional manual maintenance, significantly improving processing efficiency and avoiding prolonged interruptions to user services.

[0108] The application scenarios of this invention are as follows:

[0109] Model training computing power package billing scenario: An AI company purchased a GPU computing power package with a 30-day validity period and a total capacity of 1000 DCUs for model training. The company submitted a computing power resource application through the system's user interaction layer, specifying the hardware configuration as one NVIDIA A100 GPU card, 16 CPU cores, 128GB of memory, and an expected runtime of 72 hours. Upon receiving the application, the Kubernetes container resource management layer automatically allocated GPU nodes and created container instances according to the application specifications, then pushed a PodRunning event to the computing power metering layer, triggering the computing power metering and billing process. The computing power metering layer calculates the DCU computing power consumption in real time based on the actual container runtime, the NVIDIA A100 GPU computing power baseline, and a dynamic resource utilization coefficient, and simultaneously deducts the company's remaining computing power package quota. After model training is completed, the company triggers container destruction, the system immediately terminates computing power metering and billing, generates a detailed bill for the computing power usage, and the unused remaining quota in the computing power package is automatically carried over to the next usage cycle.

[0110] Emergency Scenario for Computing Power Reset: A research institution, while training an image recognition model, encountered an issue where incorrect model parameter settings resulted in the ineffective use of GPU computing resources. To avoid unnecessary computing power consumption costs, the institution submitted a computing power reset request through the system's user interaction layer. Upon receiving the request, the system responded quickly, completing the entire reset process in just 40ms: First, it issued an instruction to the K8s container resource management layer to destroy the currently ineffective container instance; simultaneously, it terminated the corresponding billing link for the container, cleared the 20 DCU computing power consumption record generated by this ineffective operation, and restored this computing power quota to the research institution's computing power account; finally, it automatically rebuilt the container instance according to the hardware resource specifications initially requested by the institution, started a new computing power metering and billing link, ensuring the continuous operation of the research institution's subsequent model training business and fundamentally avoiding additional costs caused by ineffective computing power occupation.

[0111] Hybrid Billing Model Adapts to Business Scenarios: A small and medium-sized enterprise (SME) configured a hybrid computing power billing package on the platform, consisting of a basic 500-degree computing power quota and pay-as-you-go pricing for excess computing power, tailored to its dual business needs of short-term high-performance model training and long-term low-performance model inference. During the model training phase, the enterprise applies for high-specification GPU computing power resources through the system, with the actual computing power consumption deducted first from the 500-degree basic quota. Once the basic quota is exhausted, the system automatically and seamlessly switches to the pay-as-you-go pricing model, calculating costs according to the pay-as-you-go pricing standard for high-specification GPU resources. During the model inference phase, the enterprise applies for low-specification GPU computing power resources. The system calculates costs based on the characteristics of the deep learning inference business scenario, using a preset preferential unit price. It integrates the quota deductions, excess billing, and preferential billing data from the training phase and inference phase to generate a clear and traceable hybrid billing statement, helping the SME achieve refined management of computing power usage costs.

[0112] It should be noted that the method of this embodiment can also be applied to distributed scenarios, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method in this embodiment, and the multiple devices will interact with each other to complete the containerized billing analysis method for GPU computing power.

[0113] It should be noted that the above description describes some embodiments of this disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0114] Example 2

[0115] See Figure 3 Embodiment 2 of the present invention also provides a containerized billing analysis system for GPU computing power, employing the containerized billing analysis method for GPU computing power described in the above embodiments, including:

[0116] The GPU computing power resource application and container deployment module 100 is used by the container resource management layer to receive GPU computing power resource application requests submitted by users, parse the hardware resource specifications, computing power requirement type and operating parameters in the GPU computing power resource application request, allocate GPU nodes and create container instances of corresponding specifications through Pod scheduling policies, and generate uniquely bound container identifiers and user identifiers as associated credentials for computing power metering and billing.

[0117] The container lifecycle event listening and push module 200 is used to trigger the linkage between container status and computing power metering. The container resource management layer uses the built-in event listener to capture the status events of the container lifecycle in real time, and pushes the event information to the computing power metering layer in real time through the standardized API interface to realize the trigger linkage between container status and computing power metering process.

[0118] The GPU computing power consumption measurement and detail generation module 300 is used by the computing power measurement layer to parse the received event information, establish the association mapping relationship between users, containers, and requested resource specifications, and complete the measurement of corresponding computing power consumption based on the real-time running status of containers and the requested hardware resource specifications, and generate corresponding computing power consumption details.

[0119] The multi-dimensional computing power billing and quota management module 400 is used to receive the computing power consumption details in the multi-dimensional billing rule layer, match the type of computing power package purchased by the user through the built-in configurable billing rule engine, complete the calculation of the corresponding computing power bill, and update the remaining quota of the user's corresponding package in a synchronous manner.

[0120] The software-based synchronous reset module 500 for computing resources and billing links is used to simultaneously issue container destruction and reconstruction instructions to the container resource management layer when a user initiates a computing power reset request. This simultaneously terminates the current billing link, clears the corresponding computing power consumption record, and restores the user's remaining computing power quota, thus completing the software-based synchronous reset of computing resources and billing links.

[0121] In this embodiment, the software-based synchronous reset module 500 for computing resources and billing links includes:

[0122] The reset request receiving submodule 501 is used to receive computing power reset requests submitted by users through the user interaction layer, and parse the user identifier, container identifier and original hardware resource specifications corresponding to the request.

[0123] The container management instruction issuing submodule 502 is used to send a container destruction instruction to the container resource management layer, synchronously terminate the billing link corresponding to the current container, and clear all computing power consumption records generated by the container.

[0124] The billing link and data reset submodule 503 is used to restore the remaining computing power quota of the user's corresponding computing power package and send a container reconstruction instruction to the container resource management layer based on the hardware resource specifications originally applied for by the user.

[0125] The reset process control submodule 504 is used by the container resource control layer to create a new container instance of the corresponding specification. After the new container starts, it triggers the start of a new computing power metering and billing link, completing the full process reset.

[0126] It should be noted that the information interaction and execution process between the modules of the above system are based on the same concept as the method embodiment in Embodiment 1 of this application, and the resulting technical effects are the same as those in the method embodiment of this application. For details, please refer to the description in the method embodiment shown above in this application, and it will not be repeated here.

[0127] Example 3

[0128] Embodiment 3 of the present invention provides a non-transitory computer-readable storage medium storing program code for a containerized billing analysis method for GPU computing power. The program code includes instructions for executing the containerized billing analysis method for GPU computing power of Embodiment 1 or any possible implementation thereof.

[0129] Computer-readable storage media can be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

[0130] Example 4

[0131] Embodiment 4 of the present invention provides an electronic device, including: a memory and a processor;

[0132] The processor and the memory communicate with each other via a bus; the memory stores program instructions that can be executed by the processor, and the processor can execute the containerized billing analysis method for GPU computing power according to Embodiment 1 or any possible implementation thereof by calling the program instructions.

[0133] Specifically, a processor can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, an integrated circuit, etc. When implemented in software, the processor can be a general-purpose processor that reads software code stored in memory. This memory can be integrated into the processor or located outside the processor and exist independently.

[0134] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable system. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0135] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing systems. They can be centralized on a single computing system or distributed across a network of multiple computing systems. Optionally, they can be implemented using program code executable by a computing system, thereby storing them in a storage system for execution by the computing system. In some cases, the steps shown or described can be performed in a different order than those presented herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0136] Although the present invention has been described in detail above with general descriptions and specific embodiments, modifications or improvements can be made to it, which will be obvious to those skilled in the art. Therefore, all such modifications or improvements made without departing from the spirit of the present invention fall within the scope of protection claimed by the present invention.

Claims

1. A containerized billing analytics method for GPU compute power, characterized in that, Includes the following steps: S1. The container resource management layer receives the GPU computing power resource application request submitted by the user, parses the hardware resource specifications, computing power requirement type and operating parameters in the GPU computing power resource application request, allocates GPU nodes and creates container instances of corresponding specifications through Pod scheduling policy, and generates uniquely bound container identifiers and user identifiers as associated credentials for computing power metering and billing. S2, the container resource management layer captures the status events of the entire lifecycle of the container in real time through the built-in event listener, and pushes the event information to the computing power metering layer in real time through the standardized API interface, so as to realize the triggering linkage between the container status and the computing power metering process. S3, the computing power metering layer parses the received event information, establishes the association mapping relationship between users, containers, and requested resource specifications, and completes the metering of corresponding computing power consumption based on the real-time running status of containers and the requested hardware resource specifications, and generates the corresponding computing power consumption details. S4. The multi-dimensional billing rule layer receives the computing power consumption details and, through the built-in configurable billing rule engine, matches the type of computing power package that the user has purchased, completes the calculation of the corresponding computing power bill, and synchronously updates the remaining quota of the user's corresponding package. S5. When a user-initiated computing power reset request is received, the multi-dimensional billing rule layer synchronously issues container destruction and reconstruction instructions to the container resource management layer, simultaneously terminating the current billing link, clearing the corresponding computing power consumption record, and restoring the user's remaining computing power quota, thus completing the software-based synchronous reset of computing power resources and billing links.

2. The GPU-capable containerized billing analytics method of claim 1, wherein, In step S1, the parameters parsed in the GPU computing power resource application request specifically include hardware resource specifications, computing power requirement type, and expected runtime; the hardware resource specifications include the number of CPU cores, GPU model and quantity, memory capacity, and disk size; the computing power requirement type includes two categories: model training and deep learning inference. In step S1, the generated uniquely bound container identifier is PodID, and the user identifier is UserID.

3. The GPU-capable containerized billing analytics method of claim 1, wherein, In step S2, the container's full lifecycle status events specifically include PodCreated, PodRunning, PodPaused, and PodDeleted events. The event information includes the event type, trigger time, container identifier, and user identifier.

4. The containerized billing analysis method for GPU computing power according to claim 3, characterized in that, Event information is pushed to the computing power metering layer in real time via a standardized API interface, enabling the linkage between container status and the triggering of the computing power metering process. Specifically: When the PodCreated event is detected, the association mapping between user, container, and resource specification is pre-established. The computing power metering and billing process is started when the PodRunning event is detected; the computing power metering and billing process is paused in real time when the PodPaused event is detected. Upon detecting the PodDeleted event, the computing power metering and billing process is immediately terminated, and a complete computing power consumption detail statement is generated to achieve complete synchronization between container status and billing status.

5. The containerized billing analysis method for GPU computing power according to claim 4, characterized in that, In step S3, the computing power consumption is measured using a computing power conversion algorithm. This algorithm converts the computing power consumption into DCU / degree standard GPU computing power units based on the hardware resource specifications requested by the container and its actual operating status. The calculation formula is as follows: In the formula, This represents the total GPU computing power consumed by the container during its corresponding runtime cycle. The preset standard computing power parameters for the corresponding GPU model applied for for the container are fixed baseline values; The number of GPUs requested for the container; The cumulative actual runtime of the container in the PodRunning state; This is a correction factor dynamically calculated based on the real-time GPU utilization during container operation.

6. The containerized billing analysis method for GPU computing power according to claim 1, characterized in that, In step S4, the configurable billing rule engine adopts a plug-in design and presets multi-dimensional billing rules through a visual interface. The rule dimensions specifically include: Hardware resource specifications: Differentiated base unit prices for specific GPU models, CPU core counts, memory capacity, and disk size configurations; Computing power unit dimension: Configure corresponding unit price conversion factors for DCU and degree, two types of GPU computing power dedicated units; Package type dimension: Supports configuration and automatic switching of four billing modes: billing by time, billing by DCU quota, billing by amount quota, and deduction within the package + billing by usage for excess amount.

7. The containerized billing analysis method for GPU computing power according to claim 6, characterized in that, In step S4, the corresponding computing power bill is calculated. The specific execution logic is as follows: For users within the package: the remaining computing power quota within the corresponding package will be deducted first. When the quota is exhausted, the excess will be switched to the pay-as-you-go billing mode. Any unused quota within the package validity period will be carried over to the next cycle. For pay-as-you-go users: the total cost is calculated directly based on the total computing power consumption and the basic unit price of the corresponding hardware resource specifications.

8. The containerized billing analysis method for GPU computing power according to claim 6, characterized in that, In step S5, the software-based synchronous reset of computing resources and billing links is completed. The specific execution process is as follows: S51. Receive the computing power reset request submitted by the user through the user interaction layer, and parse the user identifier, container identifier and original hardware resource specifications corresponding to the request. S52. Send a container destruction command to the container resource management layer, simultaneously terminate the billing link corresponding to the current container, and clear all computing power consumption records generated by the container. S53. Restore the remaining computing power quota of the user's corresponding computing power package, and send a container reconstruction instruction to the container resource management layer based on the hardware resource specifications originally applied for by the user. S54. The container resource management layer creates a new container instance of the corresponding specification. After the new container starts, it triggers the start of a new computing power metering and billing link, completing the full process reset.

9. A containerized billing and analysis system for GPU computing power, employing the containerized billing and analysis method for GPU computing power as described in any one of claims 1 to 8, characterized in that, include: The GPU computing power resource application and container deployment module is used by the container resource management layer to receive GPU computing power resource application requests submitted by users, parse the hardware resource specifications, computing power requirement type and operating parameters in the GPU computing power resource application request, allocate GPU nodes and create container instances of corresponding specifications through Pod scheduling policies, and generate uniquely bound container identifiers and user identifiers as associated credentials for computing power metering and billing. The container lifecycle event listening and push module is used to trigger the linkage between container status and computing power metering. The container resource management layer uses a built-in event listener to capture the status events of the container lifecycle in real time and push the event information to the computing power metering layer in real time through a standardized API interface, so as to realize the linkage between container status and computing power metering process. The GPU computing power consumption measurement and detail generation module is used by the computing power measurement layer to parse the received event information, establish the association mapping relationship between users, containers, and requested resource specifications, and complete the measurement of corresponding computing power consumption based on the real-time running status of containers and the requested hardware resource specifications, and generate corresponding computing power consumption details. The multi-dimensional computing power billing and quota management module is used to receive the computing power consumption details in the multi-dimensional billing rule layer, match the type of computing power package purchased by the user through the built-in configurable billing rule engine, complete the calculation of the corresponding computing power bill, and update the remaining quota of the user's corresponding package in a synchronous manner. The software-based synchronous reset module for computing resources and billing links is used to simultaneously issue container destruction and reconstruction instructions to the container resource management layer when a user initiates a computing power reset request. This simultaneously terminates the current billing link, clears the corresponding computing power consumption record, and restores the user's remaining computing power quota, thus completing the software-based synchronous reset of computing resources and billing links.

10. The containerized billing and analysis system for GPU computing power according to claim 9, characterized in that, The software-based synchronous reset module for computing resources and billing links includes: The reset request receiving submodule is used to receive computing power reset requests submitted by users through the user interaction layer, and parse the user identifier, container identifier and original hardware resource specifications corresponding to the request. The container management instruction distribution submodule is used to send container destruction instructions to the container resource management layer, synchronously terminate the billing link corresponding to the current container, and clear all computing power consumption records generated by the container. The billing link and data reset submodule is used to restore the remaining computing power quota of the user's corresponding computing power package and send a container reconstruction instruction to the container resource management layer based on the hardware resource specifications originally applied for by the user. The reset process control submodule is used by the container resource control layer to create new container instances of the corresponding specifications. After the new container starts, it triggers the start of a new computing power metering and billing link, completing the full process reset.

Images